Some of that may be artifacts of the experiments we've been working on to make it easier for good stories to surface from /newest. If you're interested, see https://news.ycombinator.com/item?id=10376064 and the links there.
"Jorf" is just an ugly word. It also evokes guttural body sounds like "barf" and "urgh", the kind someone makes when they're sick... It might be just from a native English speaker's perspective. I know English in general is not an appealing language to some ears from non-English speaking countries.
Thanks for shedding some light on it. Personally I quite like the sound of English (my native tongue being Polish), and "jorf" doesn't sound to me any worse than Jeff or Ralph :) but obviously I don't have the same sensitivity as native speakers.
Haha no I didn't. I just tried to think up an example of something phonetically similar but innocent, but there you go. Bad for Ralphs I guess.
We've got an old idiom that subtitutes vomiting for "going to Riga" (the Latvian capital). Not really aimed against Latvians, it just plays on certain phonetic similarity of Ryga and "rzygać" (to puke). Different languages, same bag of tricks.
i just extracted all the 3 zips into seperate dirs, the last contained a jorf.exe, which i started from a dosbox, spinned away flawless - have no idea about what's in what archive thou
Serf would be a nice marketing word today I think, you could make a little picture that depicts the language as being in serfdom to the user. ;) Maybe I've had too much coffee, or not enough, I forget how that works. Whatever the case, I haven't drunk the exact right amount.
"If he started Jorf in 1987, that means he started it around the same time Perl 1.0, (and the syntax is much nicer ;-). He started it around the same time Guido started Python."
This is quite interesting as it's not really clear a better syntax would automatically make it "win" over other languages, or even that it's a significant factor. Maybe a prerequisite in most cases, but I think here are a lot of other factors that can be more important:
* Surrounding library and tooling and documentation
* System requirements to comfortably run it
* Initial community
* Ability of the author to promote it
* The nature of the early adopter individuals and companies (thought experiment: young Mark Zuckerberg sits down one night and proceeds to write thefacebook v0.0.0.0.1 in Perl, not PHP)
"So, he became a suit ;-)"
I saw the emoticon ... but CTO of a startup != suit in many cases
Yes, but how do you get that library, tooling, documentation, initial community? Here, Google, Sun, Microsoft, Apple, Facebook(?), Mozilla have huge advantages, but for the individual, let's hope there's something more intrinsic than promotion ability!
Syntax plays some role at that early stage, of attracting that initial community.
If you look him up on LinkedIn his profile picture isn't even in a suit, and in his job description under CEO/CTO it says "Chief Grunt" so it doesn't sound like he changed much at all.
Apparently he's been the CEO/CTO of his company for as long as I've lived :)
(also.. I hardly think Mark Zuckerberg was an early adopter of PHP, it had been a dominant web programming language for years and was already being widely regarded as a bad idea even though alternatives either were very early or made by awful companies (asp.net))
> * The nature of the early adopter individuals and companies (thought experiment: young Mark Zuckerberg sits down one night and proceeds to write thefacebook v0.0.0.0.1 in Perl, not PHP)
A couple of points:
01) PHP was already very well established when Zuckerberg wrote thefacebook. As was Perl, Python, ASP.NET, Cold Fusion, and a few Java solutions (such as Tomcat) too. While it feels like Facebook has been around since forever, it's actually quite a recent development relative to the age of the web. My point being that it wasn't Facebook that made PHP big.
10) You theorise about what might have happened if early prototypes of thefacebook written in Perl but that was actually the original language Zuckerberg favoured (eg https://gist.github.com/philfreo/7257723).
1) True, I was a casual user of PHP before TheFacebook and remain so. The main point of the counterfactual is about Perl, ie that Perl probably would have retained a bigger part of the dev ecosystem. Though it's also true that a product like HHVM may never have happened.
I don't think it's fair to say that Perls lack of retention for any sizable part of the modern web development ecosystem was down to it's performance. Since the days of Apache 1.x Perl has had native C bindings for httpd via mod_perl, which unsurprisingly runs circles around FastCGI and the even slower standard CGI.
It's also worth remembering that Ruby didn't really take off as a major force for web development until around a decade ago - after Facebook was created - when the Rails framework was released. The reason I bring Ruby into the discussion is because Ruby's performance is roughly on a par with Perl's while having an arguably superior web framework (Rails) to Perl's CGI or mod_perl modules.
As much as I love Perl (it's genuinely one of my favourite languages), it really can be a complete pig to work with at times due to it's tendency to encourage code golfing and the many counterintuitive language features that were presumably inspired from shell scripting / awk. This weird and often unexpected complexity is what I think drove a lot of people away. PHP on the other hand, was purposely designed to be a simple language for web development. So while PHP did take some inspiration from Perl, it was more idiomatic to C than Perl was. Which meant it was an easier language for developers to adopt (also be in mind that ASP - which was predominantly VBScript - was heavily used and PHP was easier to adopt than Perl).
At least that's how I remember things back when I used to develop in the 90s
mod_perl and CGI are no longer recommended for modern perl development. We have Mojolicious, Dancer, Catalyst, Plack, and many other modern frameworks (and libraries). Most of these will run circles around mod_perl, without giving you the horror that is mod_perl's global variables + namespacing hacks and its propensity to segfault.
I'm aware mod_perl and CGI aren't recommended for modern projects (I spent a good few years as a Perl developer too). The reason I neglected to mention Catalyst et al was because my post was a historical piece and the frameworks you've discussed didn't exist back then.
As an aside, mod_perl's tendency to segfault was easily the single most frustrating thing about Perl development. I've lost count of the number of times I've ran strace against apache processes trying to trace whatever was causing the code to crash. Ugh, glad I don't have to do that any more.
Wow! Awesome story! And unfortunately yet another human-oriented tool which got dumped by the IT crowd in favor of obscurantist arcane machine-oriented engineerism-ridden hacks that break most of the possible principles of design and HCI and that are fantastically performant (i.e. have mind-boggling throughput) but often quite slow (i.e. take 300ms to react to key press and start for long seconds).
Intrigued, I did some googling and found this God-forgotten FTP :)
ftp://ftp.chatnfiles.com/Simtel-CDroms/Simtel-for-Ms-Dos-march-97-2-of-2/disc2/misclang/00_index.htm - jorf21_3.zip contains a manual :)
Some interesting constructs / keywords, eg.
For (Col = 0 thru 4) | Display B Music 5 times
And some insights:
The Windows culture is the culture of the WinProc; programs
dominated by massive unstructured switch statements that handle
esoteric message flags. As different products convert to Windows,
they unquestioningly adopt the WinProc culture. BASIC, the
language for the beginner, becomes Visual Basic, a language for
precious few. C programs become full of global values.
MS-Windows is so complicated that not even full time programmers
can learn every command and every subsystem. This leaves no time
for Windows programmers to learn about their customers. They are
doomed to write programs that cannot meet the particular needs of
these customer. The legacy of Windows threatens to be like the
legacy of UNIX; expensive techies, weak programs.
And design approaches:
Memory Management
Why is it my fault when my computer runs out of memory? It is
not my memory, why is it my fault? Why do I have to "Open" a
file just to read data from it? What exactly is "Opening"? Why
can't I have two records available at the same time?
The JORF language handles its own memory, and your reward is
freedom to allocate large structures, arrays and text. The JORF
memory can flush variables, methods, windows, internal values,
and even the program stack to disk whenever memory gets scarce.
Data is read from file when you reference it, so there is no need
to "Read" it, and no difference between a "memory variable" and a
field in a record.
WinProc programming was indeed pretty horrible. Didn't really program a lot in WinProc - but I've cut my teeth with MFC which was supposed to make it better.
They broke down the big switch in the program and created classes (the c in MFC) and macros.
The VCL of Borland was more abstracted, but we've used MFC.
I am pretty happy that I don't have to do this any more.
When I started with C# and Windows Forms it seemed like a revelation for me.
Coming from a Borland background, MFC was pretty bad when compared with any of its frameworks.
However in MFC's defense I think one can blame it on Microsoft's study group. I read somewhere that the Afx prefix came from their original design. A framework close in spirit to OWL, but their study group deemed it to high level.
So they made it a thin wrapper over Win16 instead.
On my case, the few cases I was forced outside OWL and MFC into pure C land, I use a set of macros from the Windows SDK.
They weren't properly documented, but with the Windows 3.1 SDK Microsoft created a kind of "type safe" handles and message dispatch macros, which relieved the WndProc pain.
I've heard the same thing about the Afx macros and the plan for another more ambitious framework.
In my opinion the biggest obstacles for MFC were:
* a pretty bad C++ compiler (the first good MS C++ compiler was the one with Visual Studio 2003 as much as i remember)
* that the core group were "old school" C guys that either couldn't design a better object oriented system or thought that it would be to hard for the "normal" developers
You know what's ridiculous? I totally agree that WndProc was horrible. But the web community is now reinventing it so directly that all I can do is bang my head repeatedly on my desk.
Have you seen Facebook's Flux/Dispatcher framework, for example? The Dispatcher is usually a massive switch statement that takes a single argument, which will be a record field that corresponds with the event type. It's exactly like switching on uMsg and then casting lParam to the relevant struct. And this is considered one of the absolute best web frameworks available right now.
On the bright side, I suppose we can look forward to equivalents of message crackers, OWL, and MFC for React soon enough.
Haha yes, this is so on point it makes me laugh and then want to cry a little bit. Also, they host conferences for these things, where the kool-aid is a-plenty.
It kinda frightens me too. Partly because reinvention at that scale is a bit sad, partly because it took me far too long to unplug myself from the current trends thrill and realize it.
Somehow it also says something, whatever the underlying structure, local and native VS remote and abstracted (dom/js), some patterns keeps coming back over and over.
I am creating this small library that can be described as "jquery for streams of heterogeneous schemaless messages" which pretty much could be a lean replacement for the ugly switch at flex-like architectures.
You can sneak a working barebones, very early preview at https://github.com/constructo/neurobus
> The Dispatcher is usually a massive switch statement that takes a single argument, which will be a record field that corresponds with the event type.
Stores have the switch, and you're supposed to break those up along model lines. In most the apps I've written, they never get beyond 4 or 5 branches.
Looks like he only has a short unshaven facial growth [1], that barely qualifies as a beard, which we all know are the true reason behind successful programming languages [2]
RESTRICTION ON THOSE WHO PROFIT BY ENCOURAGING WAR (MESSAGE 4 OF 4)
No JORF Company product may be used by any individual or organization
responsible for the production or storage of chemical, biological or
nuclear weapons. This product may not be used in any weapons system.
If you work for such a company, you are free to use JORF company
products at home for personal purposes, but you may not use this program
for you employer's benefit. If not now, when? If not you, who?
It always struck me as kind of odd. This was before the iphone, but even counting iphone apps I haven't been able to come up with a way using itunes to deploy WMDs that isn't horribly contrived.
Weapons of Mass Disco? Weapons of Mass Droppin beats?
In all seriousness, since we have used loud music against our enemies, and many consider it torture, and it was banned by the UN, there may be probable cause for the anti war clause.
In that same era, there were other proprietary programming languages just outside the mainstream that also attempted to abstract the low-level details of working with the Windows API.
Question- the article's premise seems to be that a language's popularity may be based on timing and language features, as opposed to language authors "selling" their language. How did Perl and Python gain "traction", if you will? Was it organic and due to people finding them and seeing they were better, or due more to Larry and Guido pushing the languages and getting the word out, or other factors, or a combination?
73 comments
[ 2.9 ms ] story [ 148 ms ] threadThere are multiple stories on the front page right now with less than 10 votes and only one story older than 9 hours.
I don't think "to Jeff" is anything yet.
We've got an old idiom that subtitutes vomiting for "going to Riga" (the Latvian capital). Not really aimed against Latvians, it just plays on certain phonetic similarity of Ryga and "rzygać" (to puke). Different languages, same bag of tricks.
Not being open-source wouldn't have helped either.
I'm sure the archive.org people would have a runnable version, and it could be distributed as a freedos package.
Three Jorf archives there, binaries, manual etc. could be the whole thing for all I know. Not tested : )
i just tested it and got ethically blewn away!
screener: http://mnml.is/hn/jorf_on_war.png
[1] https://www.youtube.com/watch?v=1o620WWho-o
This is quite interesting as it's not really clear a better syntax would automatically make it "win" over other languages, or even that it's a significant factor. Maybe a prerequisite in most cases, but I think here are a lot of other factors that can be more important:
* Surrounding library and tooling and documentation
* System requirements to comfortably run it
* Initial community
* Ability of the author to promote it
* The nature of the early adopter individuals and companies (thought experiment: young Mark Zuckerberg sits down one night and proceeds to write thefacebook v0.0.0.0.1 in Perl, not PHP)
"So, he became a suit ;-)"
I saw the emoticon ... but CTO of a startup != suit in many cases
Syntax plays some role at that early stage, of attracting that initial community.
Apparently he's been the CEO/CTO of his company for as long as I've lived :)
(also.. I hardly think Mark Zuckerberg was an early adopter of PHP, it had been a dominant web programming language for years and was already being widely regarded as a bad idea even though alternatives either were very early or made by awful companies (asp.net))
A couple of points:
01) PHP was already very well established when Zuckerberg wrote thefacebook. As was Perl, Python, ASP.NET, Cold Fusion, and a few Java solutions (such as Tomcat) too. While it feels like Facebook has been around since forever, it's actually quite a recent development relative to the age of the web. My point being that it wasn't Facebook that made PHP big.
10) You theorise about what might have happened if early prototypes of thefacebook written in Perl but that was actually the original language Zuckerberg favoured (eg https://gist.github.com/philfreo/7257723).
2) Nice! #TIL
It's also worth remembering that Ruby didn't really take off as a major force for web development until around a decade ago - after Facebook was created - when the Rails framework was released. The reason I bring Ruby into the discussion is because Ruby's performance is roughly on a par with Perl's while having an arguably superior web framework (Rails) to Perl's CGI or mod_perl modules.
As much as I love Perl (it's genuinely one of my favourite languages), it really can be a complete pig to work with at times due to it's tendency to encourage code golfing and the many counterintuitive language features that were presumably inspired from shell scripting / awk. This weird and often unexpected complexity is what I think drove a lot of people away. PHP on the other hand, was purposely designed to be a simple language for web development. So while PHP did take some inspiration from Perl, it was more idiomatic to C than Perl was. Which meant it was an easier language for developers to adopt (also be in mind that ASP - which was predominantly VBScript - was heavily used and PHP was easier to adopt than Perl).
At least that's how I remember things back when I used to develop in the 90s
As an aside, mod_perl's tendency to segfault was easily the single most frustrating thing about Perl development. I've lost count of the number of times I've ran strace against apache processes trying to trace whatever was causing the code to crash. Ugh, glad I don't have to do that any more.
I love the empty degrees of separation predicates, https://gist.github.com/philfreo/7257723#file-gistfile1-pl-L...
I can't help but to think he should have gone list monadic {and lisp too but well, enough dogma}:
http://dorophone.blogspot.com/2011/04/deep-emacs-part-1.html
Some interesting constructs / keywords, eg.
And some insights: And design approaches:WinProc programming was indeed pretty horrible. Didn't really program a lot in WinProc - but I've cut my teeth with MFC which was supposed to make it better.
They broke down the big switch in the program and created classes (the c in MFC) and macros.
The VCL of Borland was more abstracted, but we've used MFC.
I am pretty happy that I don't have to do this any more.
When I started with C# and Windows Forms it seemed like a revelation for me.
However in MFC's defense I think one can blame it on Microsoft's study group. I read somewhere that the Afx prefix came from their original design. A framework close in spirit to OWL, but their study group deemed it to high level.
So they made it a thin wrapper over Win16 instead.
On my case, the few cases I was forced outside OWL and MFC into pure C land, I use a set of macros from the Windows SDK.
They weren't properly documented, but with the Windows 3.1 SDK Microsoft created a kind of "type safe" handles and message dispatch macros, which relieved the WndProc pain.
Nevertheless, Xlib was even worse.
In my opinion the biggest obstacles for MFC were: * a pretty bad C++ compiler (the first good MS C++ compiler was the one with Visual Studio 2003 as much as i remember) * that the core group were "old school" C guys that either couldn't design a better object oriented system or thought that it would be to hard for the "normal" developers
The macros in the Windows 3.1 SDK were the strict header mode and message crackers.
https://support.microsoft.com/en-us/kb/83456
It made my life sane every time I had to use C instead of C++, and yet very few people knew about them.
Petzold never mentioned them in his books, I discovered them by chance in another book.
Nice to know that the Afx story might have not been a rumour, since other people heard the same.
My first Visual C++ was v5.0, by then it was already clear that Borland was on they way out as first choice. Sadly.
Have you seen Facebook's Flux/Dispatcher framework, for example? The Dispatcher is usually a massive switch statement that takes a single argument, which will be a record field that corresponds with the event type. It's exactly like switching on uMsg and then casting lParam to the relevant struct. And this is considered one of the absolute best web frameworks available right now.
On the bright side, I suppose we can look forward to equivalents of message crackers, OWL, and MFC for React soon enough.
Somehow it also says something, whatever the underlying structure, local and native VS remote and abstracted (dom/js), some patterns keeps coming back over and over.
Stores have the switch, and you're supposed to break those up along model lines. In most the apps I've written, they never get beyond 4 or 5 branches.
[1] http://assets.bizjournals.com/portland/print-edition/p%2019%... [2] http://www.wired.com/2012/06/beard-gallery/
Maybe it is removed by now, but I found it hillarious back in the day.
vs
an IDE - kinda...
In all seriousness, since we have used loud music against our enemies, and many consider it torture, and it was banned by the UN, there may be probable cause for the anti war clause.
The Whitewater Group's Actor:
https://en.wikipedia.org/wiki/Actor_(programming_language)
Liana ( the formatting for the article below renders strangely in my browser ):
http://www.drdobbs.com/cpp/the-liana-programming-language/18...