Looking at this "periodic table" of operators reinforced my view that perl is not going to last much longer as a real player in computer languages. There is a complexity threshold in computer languages which, once exceeded, makes people not want to use the language any more. Perl 5 was already pushing that threshold pretty hard, and now perl 6 has just got right off the deep end. Most people are just going to switch to python (I did a long time ago, and never looked back). And even python is getting too complicated!
I think what language designers forget is that humans have to learn that massive rule set before they can use the language effectively (not to mention in order to read other peoples' code). What they should do instead of piling on features is to provide ways for users to add their own features if necessary (provide meta-features if you will). So, for instance, in Haskell you can define your own operators, which have to consist of characters from a predefined operator set. If you are reading Haskell code and see an operator which is not familiar, it's probably part of the application and you know where to look for its definition. Also, you can use any binary function as an operator by surrounding it with backticks. Simple, and no periodic table needed. In lisp or scheme this issue doesn't even come up, because there is no difference between functions and operators at all.
I think computer languages should be judged not so much by how many features they have but by how many features they allow users to add for themselves.
This "article" reminds me of the song "Alice's Restaurant", by Arlo Guthrie, where he describes a police officer who "talked for forty-five minutes, and nobody understood a word that he said." I mean, I greatly respect Larry Wall and what he's accomplished, but that had to be *the* lamest speech I have ever read. If he had nothing to say, he could at least have tried to say it more succinctly.
Thanks very much for the tip. I wasn't aware of this option (So shoot me). BTW when I went to my comment preferences I saw only numerical modifiers, so I'm not sure what you mean by "-ve".
Nothing personal against you or your joke (which is good), but I really wish that/. had a filter to delete all posts that have been modded up because they're funny. I filter at a high level and it seems that a huge chunk of the 5 scores are just jokes, which I would rather skip.
Don't get me wrong -- I think Forth is beautiful, surely one of the most elegant conceptions in the history of programming languages. HOWEVER, to argue that Forth is "incredibly fast" is simply false. It's only incredibly fast if you write a lot of your words in assembly language. Otherwise, the overhead from the threaded interpreter totally kills speed. In addition, a stack-based computational model as opposed to a register-based one limits the possibilities for instruction-level parallelism, so more modern processors don't help you nearly as much as they would with (say) C. Forth gets some speed back by being 100% untyped (no run-time or compile-time type checking), but this is a very dubious "feature" when the rest of the computing world is moving towards more secure environments.
I've done some informal tests using Gforth, and I typically find that Forth is no better than 1/5 of the speed of C with that implementation. I've been informed that other Forths (e.g. Bigforth) can do better, and some Forths can even dethread the code, which might in principle put them in the same ballpark as C. This is not common practice, though, and makes the implementation quite a lot more complicated.
That said, Forth code *is* very compact, and Forth's niche has consequently always been in embedded systems. In such a system, the notion of the programming language being the same as the OS also makes more sense than it does in a more traditional computing environment.
Indeed. I teach in the Caltech CS department, and this is the first I've heard of this competition. And Caltech is a small place; the Hum department is two buildings over.
OK, you can like RMS or not, but for crying out loud, act more respectful! I doubt that most of us could accomplish in ten lifetimes than he has in his (so far). Personally, I have no problems referring to GNU/Linux as such. I wonder where I'd be if there were no gcc, emacs, or any of the *dozens* of GNU tools I use every day... probably using Windoze and hating computers. And I pay exactly *nothing* for this. And RMS started a movement which encouraged others to contribute to the same pool. And all he wants for all of this is for you to add a single syllable to the name of your OS. So do it! Show some respect!
I second this. I've read a lot of computer books, but SICP is the only one that I can call a classic. Every page is packed so full of useful information it's almost scary. I find myself re-reading it from time to time to make sure I've understood all the concepts that are presented (there are a LOT of them). As a conceptual introduction to programming, it really has no competition. Heck, I like it so much that I got Gerry Sussman to autograph it when I met him;-)
1. Read Abelson and Sussman's "Structure and Interpretation of Computer Programs" and learn scheme. Learning to program in languages with a higher level of abstraction is a great cure for the programming doldrums. The downside is that you may never want to program in java or C++ again.
2. Finish school and start contributing to an open-source project that interests you. Nothing sucks the fun out of any activity more than having some authority figure tell you you have to do it or else. I never took a single CS course in college and now I'm teaching computer science at Caltech. I love CS and programming largely because I learned it on my own.
why emacs is *obviously* better :-)
on
VIM 6.0 is Out
·
· Score: 1
... because vi can't do "meta-x psychoanalyze-pinhead", which pipes random Zippy quotations to an Eliza-like psychotherapy program. Minutes of entertainment...
In fact, as far as I know, emacs and emacs-derived editors are the *only* text editors with this feature.
Historically, Forth has been strong in environments such as embedded systems where small code size was of paramount importance. In such environments, as in color Forth, the OS is also written in Forth. Do you see any role for Forth (color Forth or any other dialect) as a language that can be used productively on top of a standard OS e.g. Linux? Or does Forth have to control the whole show in order for its strengths to show themselves?
OK, I don't want to put down the Cyc project itself, which may result in some very useful software. But for the less historically-minded, here are some quotes from the history of AI that are worth repeating.
... in three to eight years we will have a machine with the general intelligence of an average human being... The machine will begin to educate itself with fantastic speed. In a few months it will be
at genius level and a few months after that its powers will be incalculable...
-- Marvin Minsky, LIFE Magazine, November 20, 1970
and:
It is not my aim to surprise or shock you... . But the simplest way I can summarize is to say that there are now in the world machines that think, that learn and that create. Moreover, their ability to do these things is going to increase rapidly until -- in a visible future --
the range of problems they can handle will be coextensive with the range to which the human mind has been applied.
-- Herbert Simon, 1958
I could also give examples from the neural network community to the same effect. So we've been down this road before. There's something about working on AI that seems to cause gross ego-expansion in its participants. Personally, I'd consider Cyc a wild success if all it ever did was show the limitations of this particular approach to AI.
Great comment, but... python? smalltalk? These are *dynamically-typed* languages, like lisp and (pre-perl6) perl. Yes, they have a type system, but there are no declarations. Actually there has been a lot of talk in the python community about adding such declarations, and it's also been done in smalltalk (strongtalk). Lisp and Dylan try to have it both ways, but there's no perfect solution that I've seen yet.
Type systems are complex because the notion of "type" can be extended to any level of complexity you want, and knowing where to get off the train is difficult and perhaps even domain-dependent.
OK, I was wrong. After doing some more digging, I found out several interesting facts:
1. Clisp code, when compiled, is substantially faster than python.
2. CMUCL (http://www.cons.org/cmucl) had its last release on Dec. 25th, 2000.
Also, as a test of Graham's arguments about lisp,
I took a simple numerical speed test I use to compare languages and tried it on both CMUCL and the trial version of Allegro Common Lisp. Both versions achieved speeds within a factor of 2 of hand-optimized C code; the CMUCL code was actually *faster*; it was about 3/4 the speed of C. So the arguments about lisp being slow don't seem to have much merit.
I freely admit to being a lisp fan, and wish I could do a large portion of my own programming in lisp. However, the sad fact is that the best common lisp implementations are proprietary (e.g. Allegro Common Lisp) and expensive. The two free implementations I've used (clisp and cmucl) both have serious problems. Clisp is quite slow (slower than python even with compiling), and the latest version couldn't pass its own test suite on my machine. Plus, there are a few warts in the compile (minor hacking required). CMUCL is much faster, but chews up a lot of memory and cannot be compiled from C source AFAICT. Also, neither implementation appears to have much of a user base, and CMUCL seems stagnant; I haven't seen a new version in a while.
This is a shame, because I think a top-notch open source common lisp implementation (of the same quality as ACL) would be a great thing. It would allow curious hackers to experiment with the language and get over lisp's rather long learning curve, which would increase the pool of lisp hackers, which might even make the language a practical choice for internet startups. As others have mentioned, what Graham conveniently forgets to mention in his article is the difficulty of finding (or training) qualified CL programmers; for a startup company, this is a show-stopper.
if you like ruby, you'll love squeak!
on
Programming Ruby
·
· Score: 1
Ruby is conceptually a cross between perl, python, and smalltalk. If you find these languages interesting, you owe it to yourself to check out
squeak, which is a modern open-source version of smalltalk that is written in smalltalk. It's a completely different way (or ways) of thinking about programming, so Prepare To Be Enlightened (TM). Find it at http://www.squeak.org.
A commercial, proprietary language with no source code that is available only for Windoze that allows me to do stuff I can already do with free languages. Where do I sign up?:-)
You'd think that supposedly smart people would stop making the same stupid mistakes over and over again. If you want a new computer language to become popular, regardless of its niche, you have these options:
Give the language away and include source code.
Include an incredible computing environment which is worth a hundred times more than the language (e.g. Matlab, Mathematica).
Be Microsoft and ram Visual Basic down everyone's throats:-)
Otherwise, forget it. Don't believe me? Look at how popular Rebol and Eiffel are compared to python and java.
Seriously, I like the idea of having a good/great language with a kick-ass IDE. The danger is that a mediocre/bad language with a kick-ass IDE will survive because of the IDE. When the limitations of the programming language become a real problem, there will be too much time and effort invested in the project to back out. This is what happens with a lot of VB programmers; people I know who have used VB (I'm not one of them) hate it with a passion. A better approach is to develop the IDE around a good language like python (which I use all the time); everyone I know that knows python loves it, and it scales well with increasing project complexity.
The only way to get functional languages accepted is by a grassroots effort similar to those that have resulted in the popularity of perl and python. There is NO WAY that a commercial programming shop is going to go with obscure languages, much less obscure languages that go against the dominant programming paradigms, for good practical reasons that have been summarized elsewhere in this thread. So don't waste your time! Instead, look at tasks where functional or functional-friendly languages can serve useful purposes.
In my opinion, working with "pure" functional languages like Haskell which do not allow any form of imperative updating (and yes, I know about monads) is too difficult for most programmers at this point in time. Therefore, I advocate languages like Objective CAML and guile scheme which support imperative programming as well as functional programming. These languages have different niches:
-- Objective CAML is an extremely fast dialect of ML with full static type checking and an object system (and, AFAIK, the only statically-typed functional language that has any object system at all). Timing tests have shown that ocaml can compile to within 25% of hand-optimized C code for many computationally-intensive tasks. Thus, many tasks that would normally be done in C++ can be done in ocaml.
-- guile scheme is a dialect of scheme which is targeted at the python niche: a scripting/extension language. There is no good reason why scheme can't be a superb extension language.
Unfortunately, as of this moment it's not possible AFAIK to build an application using ocaml on the bottom and guile as an extension language, but hopefully this will happen in time. Regardless, the point is to use these languages for your own pet programming projects, get the source out there, spread the word, and let functional programming grow organically, instead of trying to force it down people's throats.
The author states: "Perl itself is a testimony to the OpenSource mindset - it's a gruesome mishmash of inconsistent syntax and function calls - definitely a product designed by committee - but one wherein each member clearly wasn't listening to anyone else." This is completely off the mark for at least two reasons: 1) Lots of Open Source advocates (myself included) don't even like or use perl, preferring cleaner languages like python to do the same tasks. The author seems to think that if you advocate Open Source software, you must necessarily like baroque, confusing tools. There is that subset of the OS community, but it doesn't represent all of us, and IMO that subset is becoming smaller. 2) I see no evidence that perl was ever "designed by committee" unless the existence of perl newsgroups which Larry Wall reads and whose opinion is considered before changing the language counts as a committee. The author makes some good points, but he should check his facts first.
"Microsoft development tools are always substantially less expensive than anybody else's"? Have you tried gcc on Linux (or, for that matter, on Windows) lately? Free is about as cheap as you can get.
Slashdot Mirror
Looking at this "periodic table" of operators reinforced my view that perl is not going to last much longer as a real player in computer languages. There is a complexity threshold in computer languages which, once exceeded, makes people not want to use the language any more. Perl 5 was already pushing that threshold pretty hard, and now perl 6 has just got right off the deep end. Most people are just going to switch to python (I did a long time ago, and never looked back). And even python is getting too complicated!
I think what language designers forget is that humans have to learn that massive rule set before they can use the language effectively (not to mention in order to read other peoples' code). What they should do instead of piling on features is to provide ways for users to add their own features if necessary (provide meta-features if you will). So, for instance, in Haskell you can define your own operators, which have to consist of characters from a predefined operator set. If you are reading Haskell code and see an operator which is not familiar, it's probably part of the application and you know where to look for its definition. Also, you can use any binary function as an operator by surrounding it with backticks. Simple, and no periodic table needed. In lisp or scheme this issue doesn't even come up, because there is no difference between functions and operators at all.
I think computer languages should be judged not so much by how many features they have but by how many features they allow users to add for themselves.
This "article" reminds me of the song "Alice's Restaurant", by Arlo Guthrie, where he describes a police officer who "talked for forty-five minutes, and nobody understood a word that he said." I mean, I greatly respect Larry Wall and what he's accomplished, but that had to be *the* lamest speech I have ever read. If he had nothing to say, he could at least have tried to say it more succinctly.
Oh, duh, -ve = negative.
Thanks very much for the tip. I wasn't aware of this option (So shoot me). BTW when I went to my comment preferences I saw only numerical modifiers, so I'm not sure what you mean by "-ve".
Nothing personal against you or your joke (which is good), but I really wish that /. had a filter to delete all posts that have been modded up because they're funny. I filter at a high level and it seems that a huge chunk of the 5 scores are just jokes, which I would rather skip.
I've done some informal tests using Gforth, and I typically find that Forth is no better than 1/5 of the speed of C with that implementation. I've been informed that other Forths (e.g. Bigforth) can do better, and some Forths can even dethread the code, which might in principle put them in the same ballpark as C. This is not common practice, though, and makes the implementation quite a lot more complicated.
That said, Forth code *is* very compact, and Forth's niche has consequently always been in embedded systems. In such a system, the notion of the programming language being the same as the OS also makes more sense than it does in a more traditional computing environment.
Indeed. I teach in the Caltech CS department, and this is the first I've heard of this competition. And Caltech is a small place; the Hum department is two buildings over.
I second this. I've read a lot of computer books, but SICP is the only one that I can call a classic. Every page is packed so full of useful information it's almost scary. I find myself re-reading it from time to time to make sure I've understood all the concepts that are presented (there are a LOT of them). As a conceptual introduction to programming, it really has no competition. Heck, I like it so much that I got Gerry Sussman to autograph it when I met him ;-)
1. Read Abelson and Sussman's "Structure and Interpretation of Computer Programs" and learn scheme. Learning to program in languages with a higher level of abstraction is a great cure for the programming doldrums. The downside is that you may never want to program in java or C++ again.
2. Finish school and start contributing to an open-source project that interests you. Nothing sucks the fun out of any activity more than having some authority figure tell you you have to do it or else. I never took a single CS course in college and now I'm teaching computer science at Caltech. I love CS and programming largely because I learned it on my own.
In fact, as far as I know, emacs and emacs-derived editors are the *only* text editors with this feature.
The fame, the free drugs, the hot chicks begging for my autograph... that's the life of a typical Open Source hacker. Who cares about money?
Historically, Forth has been strong in environments such as embedded systems where small code size was of paramount importance. In such environments, as in color Forth, the OS is also written in Forth. Do you see any role for Forth (color Forth or any other dialect) as a language that can be used productively on top of a standard OS e.g. Linux? Or does Forth have to control the whole show in order for its strengths to show themselves?
-- Marvin Minsky, LIFE Magazine, November 20, 1970
and:
It is not my aim to surprise or shock you ... . But the simplest way I can summarize is to say that there are now in the world machines that think, that learn and that create. Moreover, their ability to do these things is going to increase rapidly until -- in a visible future --
the range of problems they can handle will be coextensive with the range to which the human mind has been applied.
-- Herbert Simon, 1958
I could also give examples from the neural network community to the same effect. So we've been down this road before. There's something about working on AI that seems to cause gross ego-expansion in its participants. Personally, I'd consider Cyc a wild success if all it ever did was show the limitations of this particular approach to AI.
Type systems are complex because the notion of "type" can be extended to any level of complexity you want, and knowing where to get off the train is difficult and perhaps even domain-dependent.
1. Clisp code, when compiled, is substantially faster than python.
2. CMUCL (http://www.cons.org/cmucl) had its last release on Dec. 25th, 2000.
Also, as a test of Graham's arguments about lisp, I took a simple numerical speed test I use to compare languages and tried it on both CMUCL and the trial version of Allegro Common Lisp. Both versions achieved speeds within a factor of 2 of hand-optimized C code; the CMUCL code was actually *faster*; it was about 3/4 the speed of C. So the arguments about lisp being slow don't seem to have much merit.
This is a shame, because I think a top-notch open source common lisp implementation (of the same quality as ACL) would be a great thing. It would allow curious hackers to experiment with the language and get over lisp's rather long learning curve, which would increase the pool of lisp hackers, which might even make the language a practical choice for internet startups. As others have mentioned, what Graham conveniently forgets to mention in his article is the difficulty of finding (or training) qualified CL programmers; for a startup company, this is a show-stopper.
Mike
You'd think that supposedly smart people would stop making the same stupid mistakes over and over again. If you want a new computer language to become popular, regardless of its niche, you have these options:
Otherwise, forget it. Don't believe me? Look at how popular Rebol and Eiffel are compared to python and java.
_If2(_sCz11d2,4562,s32,s32){{if((GETDATAMEM_s32((( GETCODEMEM_s32(R_PC+2))+R_PC)))<( GETD ATAMEM_s32(((GETCODEMEM_s32(R_PC+6))+R_PC)))){R_PC =((GETCODEMEM_s32(R_PC+10))+R_PC);}else R_PC+=14;};;}_If2E;
This hardly counts as open source. Try harder, guys.
Basic BAD, python GOOD.
Basic BAD, python GOOD.
Basic BAD, python GOOD.
There now, was that so bad? :-)
Seriously, I like the idea of having a good/great language with a kick-ass IDE. The danger is that a mediocre/bad language with a kick-ass IDE will survive because of the IDE. When the limitations of the programming language become a real problem, there will be too much time and effort invested in the project to back out. This is what happens with a lot of VB programmers; people I know who have used VB (I'm not one of them) hate it with a passion. A better approach is to develop the IDE around a good language like python (which I use all the time); everyone I know that knows python loves it, and it scales well with increasing project complexity.
Mike
In my opinion, working with "pure" functional languages like Haskell which do not allow any form of imperative updating (and yes, I know about monads) is too difficult for most programmers at this point in time. Therefore, I advocate languages like Objective CAML and guile scheme which support imperative programming as well as functional programming. These languages have different niches:
-- Objective CAML is an extremely fast dialect of ML with full static type checking and an object system (and, AFAIK, the only statically-typed functional language that has any object system at all). Timing tests have shown that ocaml can compile to within 25% of hand-optimized C code for many computationally-intensive tasks. Thus, many tasks that would normally be done in C++ can be done in ocaml.
-- guile scheme is a dialect of scheme which is targeted at the python niche: a scripting/extension language. There is no good reason why scheme can't be a superb extension language.
Unfortunately, as of this moment it's not possible AFAIK to build an application using ocaml on the bottom and guile as an extension language, but hopefully this will happen in time. Regardless, the point is to use these languages for your own pet programming projects, get the source out there, spread the word, and let functional programming grow organically, instead of trying to force it down people's throats.
Mike
The author states: "Perl itself is a testimony to the OpenSource mindset - it's a gruesome mishmash of inconsistent syntax and function calls - definitely a product designed by committee - but one wherein each member clearly wasn't listening to anyone else." This is completely off the mark for at least two reasons: 1) Lots of Open Source advocates (myself included) don't even like or use perl, preferring cleaner languages like python to do the same tasks. The author seems to think that if you advocate Open Source software, you must necessarily like baroque, confusing tools. There is that subset of the OS community, but it doesn't represent all of us, and IMO that subset is becoming smaller. 2) I see no evidence that perl was ever "designed by committee" unless the existence of perl newsgroups which Larry Wall reads and whose opinion is considered before changing the language counts as a committee. The author makes some good points, but he should check his facts first.
"Microsoft development tools are always substantially less expensive than anybody else's"? Have you tried gcc on Linux (or, for that matter, on Windows) lately? Free is about as cheap as you can get.