Since this is a blatant popularity contest, I will submit my own, very biased, favorites. These are all ways of normalizing lambda-calculi.
call-by-name evaluation
call-by-need evaluation
call-by-value evaluation
Lambda-calculi are abstract models of computation which lie at the heart of functional programming languages. Terms of the lambda-calculus are programs, and present computable functions. A normalization algorithm lets you decide whether two terms (programs, basically) are equivalent---not merely syntactically (which is trivial), but semantically, i.e., whether or not they give the same results on the same inputs. This is an extremely important problem in the field of programming languages because it affects program reliability.
The normalization methods mentioned below are important because they are decision procedures on closed terms of typed lambda-calculus, i.e., terms without any free variables. Call-by-name (cbn) is also a "semi"-decision procedure for untyped lambda-calculus (dynamically typed functional languages). This means that if two programs terminate, then they will reduce to the same thing using cbn.
To put this in context: When you program in ML or Scheme or, more or less, LISP, you are using the call-by-value evaluation procedure, since arguments are evaluated before calls. When you program in Haskell (or Scheme with suspensions), you are using the call-by-need procedure, since arguments are evaluated on demand. And, if you are using Algol 60, you are using call-by-name, since arguments are evaluated every time they are demanded.
Other candidates for `deep algorithms' in this vein are Gentzen's "Hauptsatz", or cut elimination procedure and the Hindley-Milner type inference algorithms.
Jef: I remember one client of mine who boasted about his customizable desktop and how he never had to reboot his software. I set the system font to red and the background to red. You couldn't see a thing. He spent a few minutes trying to find and open the now-invisible menus that would let him change one of the colors.
He had to reboot. His system was good in that it automatically saved the user preferences, so it came up red on red. He had not only to reboot, but to reload the software, losing all his demo data.
Can you believe the gall of this guy?
Perhaps a way to make your system easier to use is not to make the UI more consistent, but rather never to let Jef Raskin near the keyboard!
Bemer's claim to escape sequences is even more absurd than BT's claim to hyperlinking. (Thankfully, he's using it to subvert BT's claim, and not pressing it independently.) The notion of "escapes" is so abstract and general that you could apply it to almost anything, even outside the realm of computers. For example, the idea of interrupting someone in the middle of a conversation, or the idea of changing lanes on the freeway, or any kind of multiplexing.
These sorts of concepts which are being pressed at the patent office may be new to some people, but they are not new. In particular, this idea of escapes would have been completely obvious to anybody with a little mathematical training, in 1950 or 1900 or even 100BC.
You could argue that the application of the idea is novel, but differentiating an abstract notion from its collection of concrete instances is a tricky thing, and properly the subject of philosophy and metamathematics, not the patent office's incompetent review staff.
Just wanted to add my vote for ring-bound books. This would be a significant plus for me. I only have two ring-bound books on my shelf right now, The TeX Book and The MetaFont Book, and I wish I had more. (Is it any surprise that the best typesetting system is bound in the most useful way? Knuth has a lot of class.) It really does make a difference for reference works.
Another good thing about these books is that the back cover folds in, so you can use it to hold your place, and when you're not doing that, you can fold it all the way around to the front, to protect the pages if you're carrying it around in a bag.
Oh, BTW, it's pretty funny to hear someone object to English-speakers making a travesty of Japanese, when anyone who has lived in Japan knows that the Japanese take far, far greater liberties with English (though mostly unintetionally)!
This reminds me of a story someone told me a once about a certain banner they had raised in Tokyo, soon after the war during the occupation. Apparently MacArthur was running for some public office, and some Japanese who were supporting him hung a banner across a street. It read:
"Oogatana"? I don't think so. I have two dictionaries ("Shinkokugo Ziten" from Kadokawa, and Hadamitzky and Spahn, "Kanji & Kana") that list "daitou". Nelson doesn't mention either reading under "tou(katana)".
Though it's reasonable to assume that words relating to Japanese swords would be read with the Japanese reading, it isn't always the case. These things are not readily predictable, and there are plenty of exceptions. Besides, there are plenty of words which mix Chinese and Japanese readings of characters, particularly among words starting with "dai". (OTOH, it is a good rule of thumb.)
I've been looking at it, and it is quite nice. Hard to believe it's a Java application. But I can't find any links to available plugins. Are these only mentioned in the newsgroup?
You can move windows around in Ion just like in conventional window managers. Ion lets you divide the screen into a number of frames. Each frame holds one or more applications, whose titles are displayed in a title bar divided into tabs. When you want to move an application to another frame, you just drag it over, and the window gets remapped to the new frame's size.
I've been using Ion for a few months now. Another reader said that Ion was a restriction in the user interface, since you can arrange windows in any conventional window manager so that they don't overlap. Of course this is true, but conventional window managers don't ensure that windows don't overlap either; managing overlapping windows takes a couple seconds, and this adds up over time. Anyway, you have to be pretty narrow-minded to insist that window managers must be evaluated on a linear scale, from "good" to "bad"; they all have their merits and demerits.
Personally, I like Ion, and that's why I'm still using it. I've been looking for a non-overlapping window manager for a while, and Ion is the one I've found which suits me best. It doesn't force me to use the keyboard exclusively (for example, I can still resize with the mouse); it supports tabbing, which I've found to be almost essential in the context of a non-overlapping manager.
The main problem is, I think, simply that most applications are written with the overlapping windows paradigm in mind. For example, they are written to be rendered in a window of a particular size; or they take a long time to re-render their contents when you change the ratio of window sizes (Netscape 4.7x in particular is serious culprit); or they create lots of dialogs (which is a bit ugly, since some dialogs do overlap in Ion, or they get expanded to the parent window size, with the effect that most of the space being wasted).
Still, I'm fairly happy with Ion. For the most part, it stays out of my way. And that is the best compliment you can pay to a user interface.
The saddest part is that von Neumann knew his namesake architecture was bogus in just this way, and
expressed hope that future architectures would move toward more robust approaches.
Boy, you sound nervous! If this were the "Object-oriented programming language contest," and C++ and Python and Eiffel won, I wonder if you wouldn't be saying just the opposite.
No one (at least, no one associated with the contest) is saying this is an objective comparison of programming languages or that the winners are the best programming languages for any and all purposes. Indeed, the prize-winners' appelations ("language for discriminating hackers") are so laughable, no one in his right mind would take it seriously.
This contest is about having fun, taking pride in your favorite language, giving a few kudos where they are deserved, and a little bit of advocacy for a class of programming languages that are overlooked by the programmer community at large. It's not a pissing contest.
BTW, what is an "objective" language comparison anyway? I am a programming language researcher, and I can think of a few theoretical ways to compare programming languages, but I would think that most programmers-in-the-trenches would be more satisfied with tests that compare languages on real life problems, and these contest problems are not far off from that. So what are you so unhappy about?
Autoduel, you mean. That was a fun game, but hard as all hell. I think Chuckles was the lead on that one, not Garriott. Also, (correct me if I'm wrong) I think it was not directly based on Car Wars, although obviously the idea came from there. They must have been trying to avoid license fees to Steve Jackson Games, much as Black Isle, who dropped the GURPS system for Fallout in favor of their own S.P.E.C.I.A.L.(?) for those reasons.
Speaking of Fallout, does anyone remember a game called Wasteland? It resembled Bard's Tale/Wizardry but with a post-apocalyptic setting. Is Fallout somehow descended from that?
Good point, but trying to force people to be honest about their email address by legislating it is a poor solution; it can't be realistically enforced, for one thing.
The right solution is to recognize that the reply address is easily forgeable, and figure out a technical solution (say, a separate header which includes some kind of certificate) which guarantees the email's origin is accurate. Then the public will learn to accept and reply to only emails with such a certificate of origin, and may ignore ones which are otherwise questionable.
In my view, technological solutions are usually superior to legal ones. I'm not an anarchist, but I think the law is easy for large corporations and other organizations to bend, and, though new laws may make some things better for the public in the short run, ultimately a large body of laws just complicates all our lives and it is mostly the lawyers and people who can afford to retain them who benefit. Technological solutions at least are not subject to interpretation or ambiguity.
Personally, when I program, I'm not looking for my code to fit some elegant
theory. I'm looking for the job to get done as succinctly as possible.
Spoken like a true hacker. But perhaps you are overlooking the fact that brevity and maintainability are two of the most important criteria for "elegance".
I found it ironic you say that because Perl has
problem undergone the most intensive language development of any (and the new process probably blows efforts for other languages
out of the water)
I don't know what you mean by "language development". To me, developing a language means increasing our understanding of its behavior, or increasing its expressiveness. Perl has been the subject of many superficial enhancements, but practically no rigorous analysis. There is no doubt in any informed person's mind that the best understood programming language is the lambda-calculus, which is a mathematical system that forms the core of all functional languages, incl. particularly Scheme and ML. As for expressiveness, I'm not aware of any Perl feature which cannot be macro-defined in lambda-calculus, and thus, e.g., Scheme as well.
Perl is designed so that you can write it like you almost would speak it
Spoken language is so complex and ambiguous that finding denotational models of even tiny subsets is still and will continue to be for many years a focus of research. When you write a program, you want to be sure that its semantics are well-defined and unambiguous.
But this is really beside the point. What makes you think Perl resembles spoken language is mostly to do with the surface syntax anyway. All serious research into linguistic semantics is done with mathematical models which do not resemble Perl in any way and, indeed, lambda-calculus is one of them!
This is what trademarks were invented for in the first place.. products in competing spaces should have different names.
Yeah, but KIllustrator is not a product, meaning it is not being sold commercially. One might argue that trademark laws ought not to apply in such cases. The problem as I see it is where to draw the line at which a free software project becomes popular enough that, if it were commercial it would infringe on someone else's trademark. For example, if I decided to just put up a file called "Illustrator" (regardless of content) on my website, is that infringing? I doubt it. If I tell a few of my friends about it on a public forum, is that infringing? Probably not. But now if/. runs a story on it and a few thousand people grab it as a result, is that infringing? Probably yes. So what is the magic number, and how do you decide which forums are "public" enough to make a pet project a formal competitor to some company's product?
If infringing materials must be commercial, then the dividing line is very clear. Otherwise, it seems disquietingly hazy to me.
BH
Re:Some Annoying Features of Ruby
on
Why not Ruby?
·
· Score: 1
In theory, languages are not libraries. In practice, I'm sorry, they are. How many people do you know using Java that don't use the
classes in java.lang and java.util?
I'm not saying libraries are unimportant, or that the availability of libraries for a particular language is not an important factor for many users. What I am saying is simply that libraries have nothing to do with the quality of a language design.
But anyway, if your language has a foreign function interface, then lack of libraries is not a big deal anyway.
BH
Re:Some Annoying Features of Ruby
on
Why not Ruby?
·
· Score: 2
I'm not a Ruby advocate, but your post illustrates issues which are common to nearly all of the/. posts on programming language issues.
You don't distinguish between a language and its libraries. The handling of strings, time zones, FP and so on are library issues. Proviso: if these are not library issues for the language in question, then the language is poorly designed.
You focus on syntactic details which are provably irrelevant. If a language has a sizeable following, then that fact is already proof that its syntax is usable. All your criticisms amount to is that "Ruby has a different syntax than the one I'm used to." This also holds for other languages with non-C-like syntaxes, such as Scheme, Python, Smalltalk and ML.
I suspect you made your post after what was a 20 minute investigation of the language.
Another thing I often see on/. is people praising language X because it has an IDE, or a debugger, or a profiler, or fast garbage collection, or good error messages, or dynamic linking, or an interactive interpreter or a fast compiler. These are properties of the language implementation, not the language itself, and thus say nothing of interest about the quality of the language design.
Lastly, if you choose one language over another solely on the basis of surface issues such as the size of its available libraries, its syntax or the quality of its implementation, then that suggests that there really is not much difference between the two.
The only solid criterion I know for comparing languages which does not revolve around holy issues (e.g., static vs. dynamic typing) is locality. Language X is better than language Y with respect to feature F if in X you can use F to write code localized to one part of the program, which in Y you would be forced to spread globally all over the program to get the same effect. Features which satisfy this criterion are things like objects, higher-order functions, first-class continuations, logical constraint variables, etc. It can be shown that, thanks to such a feature F, programs of language X may be exponentially smaller than programs of language Y. Features which don't satisfy this criterion will lead at wost to linear size differences in the lengths of programs, and can thus be adequately addressed by macro-processing. (Not that I advocate macros...)
Slashdot Mirror
Since this is a blatant popularity contest, I will submit my own, very biased, favorites. These are all ways of normalizing lambda-calculi.
Lambda-calculi are abstract models of computation which lie at the heart of functional programming languages. Terms of the lambda-calculus are programs, and present computable functions. A normalization algorithm lets you decide whether two terms (programs, basically) are equivalent---not merely syntactically (which is trivial), but semantically, i.e., whether or not they give the same results on the same inputs. This is an extremely important problem in the field of programming languages because it affects program reliability.
The normalization methods mentioned below are important because they are decision procedures on closed terms of typed lambda-calculus, i.e., terms without any free variables. Call-by-name (cbn) is also a "semi"-decision procedure for untyped lambda-calculus (dynamically typed functional languages). This means that if two programs terminate, then they will reduce to the same thing using cbn.
To put this in context: When you program in ML or Scheme or, more or less, LISP, you are using the call-by-value evaluation procedure, since arguments are evaluated before calls. When you program in Haskell (or Scheme with suspensions), you are using the call-by-need procedure, since arguments are evaluated on demand. And, if you are using Algol 60, you are using call-by-name, since arguments are evaluated every time they are demanded.
Other candidates for `deep algorithms' in this vein are Gentzen's "Hauptsatz", or cut elimination procedure and the Hindley-Milner type inference algorithms.
Perhaps a way to make your system easier to use is not to make the UI more consistent, but rather never to let Jef Raskin near the keyboard!
Sounds like snake oil to me.
These sorts of concepts which are being pressed at the patent office may be new to some people, but they are not new. In particular, this idea of escapes would have been completely obvious to anybody with a little mathematical training, in 1950 or 1900 or even 100BC.
You could argue that the application of the idea is novel, but differentiating an abstract notion from its collection of concrete instances is a tricky thing, and properly the subject of philosophy and metamathematics, not the patent office's incompetent review staff.
Another good thing about these books is that the back cover folds in, so you can use it to hold your place, and when you're not doing that, you can fold it all the way around to the front, to protect the pages if you're carrying it around in a bag.
This reminds me of a story someone told me a once about a certain banner they had raised in Tokyo, soon after the war during the occupation. Apparently MacArthur was running for some public office, and some Japanese who were supporting him hung a banner across a street. It read:
True story, or so I hear. :)
Though it's reasonable to assume that words relating to Japanese swords would be read with the Japanese reading, it isn't always the case. These things are not readily predictable, and there are plenty of exceptions. Besides, there are plenty of words which mix Chinese and Japanese readings of characters, particularly among words starting with "dai". (OTOH, it is a good rule of thumb.)
This is false. I saw the ads, and I'm running Netscape 4.78.
And this is under Solaris on a SPARC, I should add.
This is false. I saw the ads, and I'm running Netscape 4.78.
I've been looking at it, and it is quite nice. Hard to believe it's a Java application. But I can't find any links to available plugins. Are these only mentioned in the newsgroup?
You can move windows around in Ion just like in conventional window managers. Ion lets you divide the screen into a number of frames. Each frame holds one or more applications, whose titles are displayed in a title bar divided into tabs. When you want to move an application to another frame, you just drag it over, and the window gets remapped to the new frame's size.
I've been using Ion for a few months now. Another reader said that Ion was a restriction in the user interface, since you can arrange windows in any conventional window manager so that they don't overlap. Of course this is true, but conventional window managers don't ensure that windows don't overlap either; managing overlapping windows takes a couple seconds, and this adds up over time. Anyway, you have to be pretty narrow-minded to insist that window managers must be evaluated on a linear scale, from "good" to "bad"; they all have their merits and demerits.
Personally, I like Ion, and that's why I'm still using it. I've been looking for a non-overlapping window manager for a while, and Ion is the one I've found which suits me best. It doesn't force me to use the keyboard exclusively (for example, I can still resize with the mouse); it supports tabbing, which I've found to be almost essential in the context of a non-overlapping manager.
The main problem is, I think, simply that most applications are written with the overlapping windows paradigm in mind. For example, they are written to be rendered in a window of a particular size; or they take a long time to re-render their contents when you change the ratio of window sizes (Netscape 4.7x in particular is serious culprit); or they create lots of dialogs (which is a bit ugly, since some dialogs do overlap in Ion, or they get expanded to the parent window size, with the effect that most of the space being wasted).
Still, I'm fairly happy with Ion. For the most part, it stays out of my way. And that is the best compliment you can pay to a user interface.
The saddest part is that von Neumann knew his namesake architecture was bogus in just this way, and expressed hope that future architectures would move toward more robust approaches.
Please provide a reference for this.
It wasn't strongly typed (is there such a lisp?)
Yes, it's called ML. See Ocaml or Standard ML (this link is to Moscow ML, an SML implementation), for example.
and the singular type of syntax (lists) make many aspects of the code difficult to unravel.
ML has algebraic datatypes, which might be regarded as a cross between unions and structures in C.
You neglect to mention the significant fact that the ranking on that page only takes into account the first round results.
Boy, you sound nervous! If this were the "Object-oriented programming language contest," and C++ and Python and Eiffel won, I wonder if you wouldn't be saying just the opposite.
No one (at least, no one associated with the contest) is saying this is an objective comparison of programming languages or that the winners are the best programming languages for any and all purposes. Indeed, the prize-winners' appelations ("language for discriminating hackers") are so laughable, no one in his right mind would take it seriously.
This contest is about having fun, taking pride in your favorite language, giving a few kudos where they are deserved, and a little bit of advocacy for a class of programming languages that are overlooked by the programmer community at large. It's not a pissing contest.
BTW, what is an "objective" language comparison anyway? I am a programming language researcher, and I can think of a few theoretical ways to compare programming languages, but I would think that most programmers-in-the-trenches would be more satisfied with tests that compare languages on real life problems, and these contest problems are not far off from that. So what are you so unhappy about?
Autoduel, you mean. That was a fun game, but hard as all hell. I think Chuckles was the lead on that one, not Garriott. Also, (correct me if I'm wrong) I think it was not directly based on Car Wars, although obviously the idea came from there. They must have been trying to avoid license fees to Steve Jackson Games, much as Black Isle, who dropped the GURPS system for Fallout in favor of their own S.P.E.C.I.A.L.(?) for those reasons.
Speaking of Fallout, does anyone remember a game called Wasteland? It resembled Bard's Tale/Wizardry but with a post-apocalyptic setting. Is Fallout somehow descended from that?
Good point, but trying to force people to be honest about their email address by legislating it is a poor solution; it can't be realistically enforced, for one thing.
The right solution is to recognize that the reply address is easily forgeable, and figure out a technical solution (say, a separate header which includes some kind of certificate) which guarantees the email's origin is accurate. Then the public will learn to accept and reply to only emails with such a certificate of origin, and may ignore ones which are otherwise questionable.
In my view, technological solutions are usually superior to legal ones. I'm not an anarchist, but I think the law is easy for large corporations and other organizations to bend, and, though new laws may make some things better for the public in the short run, ultimately a large body of laws just complicates all our lives and it is mostly the lawyers and people who can afford to retain them who benefit. Technological solutions at least are not subject to interpretation or ambiguity.
Interesting how, on the one hand, you advocate anonymity, yet, on the other, you think anonymization should be outlawed.
The fact that a machine can come up with patentable software only goes to show how banal most software patents are.
Personally, when I program, I'm not looking for my code to fit some elegant theory. I'm looking for the job to get done as succinctly as possible.
Spoken like a true hacker. But perhaps you are overlooking the fact that brevity and maintainability are two of the most important criteria for "elegance".
I found it ironic you say that because Perl has problem undergone the most intensive language development of any (and the new process probably blows efforts for other languages out of the water)
I don't know what you mean by "language development". To me, developing a language means increasing our understanding of its behavior, or increasing its expressiveness. Perl has been the subject of many superficial enhancements, but practically no rigorous analysis. There is no doubt in any informed person's mind that the best understood programming language is the lambda-calculus, which is a mathematical system that forms the core of all functional languages, incl. particularly Scheme and ML. As for expressiveness, I'm not aware of any Perl feature which cannot be macro-defined in lambda-calculus, and thus, e.g., Scheme as well.
Perl is designed so that you can write it like you almost would speak it
Spoken language is so complex and ambiguous that finding denotational models of even tiny subsets is still and will continue to be for many years a focus of research. When you write a program, you want to be sure that its semantics are well-defined and unambiguous.
But this is really beside the point. What makes you think Perl resembles spoken language is mostly to do with the surface syntax anyway. All serious research into linguistic semantics is done with mathematical models which do not resemble Perl in any way and, indeed, lambda-calculus is one of them!
Yeah, but KIllustrator is not a product, meaning it is not being sold commercially. One might argue that trademark laws ought not to apply in such cases. The problem as I see it is where to draw the line at which a free software project becomes popular enough that, if it were commercial it would infringe on someone else's trademark. For example, if I decided to just put up a file called "Illustrator" (regardless of content) on my website, is that infringing? I doubt it. If I tell a few of my friends about it on a public forum, is that infringing? Probably not. But now if /. runs a story on it and a few thousand people grab it as a result, is that infringing? Probably yes. So what is the magic number, and how do you decide which forums are "public" enough to make a pet project a formal competitor to some company's product?
If infringing materials must be commercial, then the dividing line is very clear. Otherwise, it seems disquietingly hazy to me.
BH
In theory, languages are not libraries. In practice, I'm sorry, they are. How many people do you know using Java that don't use the classes in java.lang and java.util?
I'm not saying libraries are unimportant, or that the availability of libraries for a particular language is not an important factor for many users. What I am saying is simply that libraries have nothing to do with the quality of a language design.
But anyway, if your language has a foreign function interface, then lack of libraries is not a big deal anyway.
BH
I'm not a Ruby advocate, but your post illustrates issues which are common to nearly all of the /. posts on programming language issues.
Another thing I often see on /. is people praising language X because it has an IDE, or a debugger, or a profiler, or fast garbage collection, or good error messages, or dynamic linking, or an interactive interpreter or a fast compiler. These are properties of the language implementation, not the language itself, and thus say nothing of interest about the quality of the language design.
Lastly, if you choose one language over another solely on the basis of surface issues such as the size of its available libraries, its syntax or the quality of its implementation, then that suggests that there really is not much difference between the two.
The only solid criterion I know for comparing languages which does not revolve around holy issues (e.g., static vs. dynamic typing) is locality. Language X is better than language Y with respect to feature F if in X you can use F to write code localized to one part of the program, which in Y you would be forced to spread globally all over the program to get the same effect. Features which satisfy this criterion are things like objects, higher-order functions, first-class continuations, logical constraint variables, etc. It can be shown that, thanks to such a feature F, programs of language X may be exponentially smaller than programs of language Y. Features which don't satisfy this criterion will lead at wost to linear size differences in the lengths of programs, and can thus be adequately addressed by macro-processing. (Not that I advocate macros...)
BH