Where Lisp Fails: at Turning People into Fungible Cogs(loper-os.org)
loper-os.org
Where Lisp Fails: at Turning People into Fungible Cogs
http://www.loper-os.org/?p=69
6 comments
libraries should be n times faster to make or duplicate
Oh, they often are... and that's why nearly everyone just builds their own. Ease of building it yourself compared to learning someone else's system is a major reason Lisp is languishing, in my opinion.
Oh, they often are... and that's why nearly everyone just builds their own. Ease of building it yourself compared to learning someone else's system is a major reason Lisp is languishing, in my opinion.
Oddly, it can also be a downside. A language that makes reinventing the wheel too easy means that people can spend more time saying, "Psh, I could do that in a couple hours" than sharing. Then, when people want to know what the library is to use for parsing HTTP headers (or whatever), everybody and their nephew shows up to suggest their own half-assed framework. It doesn't inspire confidence.
Take that to its logical extent, and ... wait, which Lisp implementation do you use again? Mine only works with SBCL, crap, nevermind.
When somebody has a really thoroughly debugged C library, it can be like huddling everyone together by a fire for warmth in the tundra. If you don't share, man, that's just cruel.
Take that to its logical extent, and ... wait, which Lisp implementation do you use again? Mine only works with SBCL, crap, nevermind.
When somebody has a really thoroughly debugged C library, it can be like huddling everyone together by a fire for warmth in the tundra. If you don't share, man, that's just cruel.
I agree - I really think that when it comes down to it, Lisp isn't popular because it's harder to read. Even if it's more terse and far more elegant, the mental tax of trying to understand another person's code is far higher than C, where there's only "the dumb way" to do something.
If people can't understand the code, they can't contribute, so you don't end up with the network effect of F/OSS contributions that make a language popular (note that I say popular, not better)
If people can't understand the code, they can't contribute, so you don't end up with the network effect of F/OSS contributions that make a language popular (note that I say popular, not better)
As a person who started learning Lisp after years and years of using mostly mainstream languages, I have to at least partially disagree. I will say this, however: Lisp is, at first, difficult to read for many people. But I think it is mainly difficult to read for people who are used to reading programs written in languages with Algol-like syntax (C, C++, Java, Perl, etc). If you've been writing programs for 5, 10, or 15 or more years mostly in languages that all have that common ancestry, it is understandable that your brain will (at first) work against you when reading something like Lisp. However, after using it for a reasonable period of time, I found that it became much easier to read. And now I don't find it any more difficult to read than any of the mainstream languages that I have used in the past.
I think that, in fairness to Lisp, if you take two people who have never programmed in their life, and if each of the two has a reasonable and approximately equal amount of skill and potential for being a decent developer, and taking those two individuals, you teach one to develop in Lisp, and one in, say Java. Given that situation, I don't think the Lisp developer will find his code more difficult to read really at any stage of his learning (more difficult that is, than the Java developer finds his code to read at a similar stage of learning).
It seems to me, from every testimony I've read from developers who have come to Lisp after extensive careers using other more popular languages, that there is a "breaking in" period where it takes some time to get used to things. However, anyone I've read about who put in any reasonable effort to learn a Lisp (or a language related to Lisp, like Scheme) seems to repeat what others like him or her have said -- you get used to the syntax after a while, and then at the very least it no longer bothers you or gets in your way.
I think that, in fairness to Lisp, if you take two people who have never programmed in their life, and if each of the two has a reasonable and approximately equal amount of skill and potential for being a decent developer, and taking those two individuals, you teach one to develop in Lisp, and one in, say Java. Given that situation, I don't think the Lisp developer will find his code more difficult to read really at any stage of his learning (more difficult that is, than the Java developer finds his code to read at a similar stage of learning).
It seems to me, from every testimony I've read from developers who have come to Lisp after extensive careers using other more popular languages, that there is a "breaking in" period where it takes some time to get used to things. However, anyone I've read about who put in any reasonable effort to learn a Lisp (or a language related to Lisp, like Scheme) seems to repeat what others like him or her have said -- you get used to the syntax after a while, and then at the very least it no longer bothers you or gets in your way.
I program in C++/etc but also in SQL. SQL is terse logical language. Everyone may has SQL but I think given constraints of being a logical language SQL is far more readable than lisp - but I've only read bits of lisp online.
I find CSS to be far more readable than SQL.
I'm not clear what point you're making. CSS isn't a logical language, and they don't really have enough in common to compare them. (And FWIW, I find SQL clearer than Nahuatl.)
> CSS isn't a logical language, and they don't really have enough in common to compare them.
s/CSS/Lisp/
s/CSS/Lisp/
Lisp isn't popular because it's harder to read. Even if it's more terse and far more elegant, the mental tax of trying to understand another person's code is far higher than C
I am deeply suspicious of explanations that boil down to, Lisp isn't popular because the average programmer isn't smart enough. Let me tell you, anyone smart enough to use C++ in anger is smart enough to use any language.
The real world is highly competitive, and organizations that think they can win by using niche languages, do. There's APL at Morgan Stanley, Ocaml at Jane Street Capital, K at Lehman's (OK, maybe that's not so good an example), F#, Haskell, blah blah. Lisp isn't even on the radar, anywhere. What does that tell you?
I am deeply suspicious of explanations that boil down to, Lisp isn't popular because the average programmer isn't smart enough. Let me tell you, anyone smart enough to use C++ in anger is smart enough to use any language.
The real world is highly competitive, and organizations that think they can win by using niche languages, do. There's APL at Morgan Stanley, Ocaml at Jane Street Capital, K at Lehman's (OK, maybe that's not so good an example), F#, Haskell, blah blah. Lisp isn't even on the radar, anywhere. What does that tell you?
Mathematica is widely used in the financial sector. Don't let the square brackets, prefix notation and fugly symbolic shortcuts fool you: Mathematica is lisp.
Well, yes, you could argue that Python is Lisp too, but my point stands: if Lisp, as in, CL, really was a huge productivity boost, organizations that have demonstrated their willingness to adopt niche languages where well-suited to their problem domain would have adopted it, but that isn't actually happening. If anything Haskell and APL are nichier (if that's even a word).
The big Lisp success stories all start from the premise of a bunch of programmers who are already hugely experienced in Lisp happening to do this project in it (e.g. Viaweb, Orbitz). But when people with 20 years experience in C complete a project successfully, it isn't blogworthy news...
The big Lisp success stories all start from the premise of a bunch of programmers who are already hugely experienced in Lisp happening to do this project in it (e.g. Viaweb, Orbitz). But when people with 20 years experience in C complete a project successfully, it isn't blogworthy news...
Python is a primarily imperative/OO language. Good python code consists of writing loops and building objects. Syntactic abstraction consists primarily of looking up strings in obj.__dict__. Whenever more complicated metaprogramming is needed, strings are parsed.
http://reference.wolfram.com/mathematica/guide/Patterns.html
I've programmed Python and Lisp, and have begun writing some projects of reasonable size in Mathematica. There are only a couple of major differences between Mathematica and lisp. One is syntax: f[a,b,c] vs (f a b c), as well as some infix syntactic sugar. The other is that arrays are used far more widely in Mathematica than in lisp (but that may be due to the problem domain of mathematica).
"obj__parent__name_eq"=foo
obj.parent.name == foo.
http://reference.wolfram.com/mathematica/guide/Patterns.html
I've programmed Python and Lisp, and have begun writing some projects of reasonable size in Mathematica. There are only a couple of major differences between Mathematica and lisp. One is syntax: f[a,b,c] vs (f a b c), as well as some infix syntactic sugar. The other is that arrays are used far more widely in Mathematica than in lisp (but that may be due to the problem domain of mathematica).
But you haven't answered the question. Why Mathematica and not Lisp + some libraries? Or (+ Lisp Libraries). Again, there are many organizations willing to adopt any language that will give them some extra leverage. Lisp just doesn't appear. The explanation that the average programmer just isn't smart enough is easily demolished by pointing out the C++ (and APL, and Haskell) users. So either we're all missing something or the elephant in the corner is that Lisp just isn't that useful for commercially relevant problems. Which is not to say it's a bad language, but that it's not the "secret sauce" everyone's looking for.
Actually, the question you are asking is "Why mathematica and not Common Lisp or Scheme + some libraries?"
Mathematica is lisp + a bunch of a math libraries + vendor support + slightly different syntax + renamed functions. The syntactic differences:
Mathematica is lisp + a bunch of a math libraries + vendor support + slightly different syntax + renamed functions. The syntactic differences:
{a b c} -> '(a b c)
f[a,b] -> (f a b)
a == b -> (Equals a b)
(* comment *) -> ;;comment
i agree with your main point (python isn't lisp because it doesn't have macros). but the language nerd in me can't resist commenting on your example from django. that's a very special case. it's hard to think of any other package that uses that approach. rather, the way people solve problems in python that you would solve in lisp with macros is by late binding, introspection, and higher order functions. none of these replace macros entirely, but together they can be hacked into a solution.
You'll get a productivity boost with good people. Those are rare and expensive.
Lisp is a bit remote from machines and their operating system: GC, data formats, ...
Lisp has many degrees of freedom. It is much harder to control. It is designed for flexibility (even at runtime).
The original Lisp was done for 'symbolic computation with recursive functions': Theorem provers, machine translation, computer algebra systems, knowledge representation, planning systems, ...
If your problem domain fits into above list, then Lisp is likely to be a good candidate language to use. Then there are related domains where Lisp has been used with success: expert systems, algorithmic composition, language implementation (compilers, ...), deductive databases. Again, Lisp may be very useful in these domains.
There are lots of domains where it does not fit that well or is mostly useless. From the domains above you can see that those are not domains that many people work in (compared to web development, database apps, accounting apps, ...). Lisp is quite useful in those domains, but they tend to be a bit remote from the current mainstream.
Viaweb and Orbitz are exceptions. Most Lisp applications are relatively unknown and they are not widely published. Huge successes were for example DART and SPIKE. DART was a logistics system for the military (it is said to have repaid all the government expenses for AI research made) and SPIKE is s scheduling system for telescopes (originally for the Hubble Space Telescope). These applications were not written because some guys knew only Lisp, but because lots of the research applications in planning and scheduling systems were written in Lisp - because in this domain these applications work with symbolic representations of plans.
Lisp is a bit remote from machines and their operating system: GC, data formats, ...
Lisp has many degrees of freedom. It is much harder to control. It is designed for flexibility (even at runtime).
The original Lisp was done for 'symbolic computation with recursive functions': Theorem provers, machine translation, computer algebra systems, knowledge representation, planning systems, ...
If your problem domain fits into above list, then Lisp is likely to be a good candidate language to use. Then there are related domains where Lisp has been used with success: expert systems, algorithmic composition, language implementation (compilers, ...), deductive databases. Again, Lisp may be very useful in these domains.
There are lots of domains where it does not fit that well or is mostly useless. From the domains above you can see that those are not domains that many people work in (compared to web development, database apps, accounting apps, ...). Lisp is quite useful in those domains, but they tend to be a bit remote from the current mainstream.
Viaweb and Orbitz are exceptions. Most Lisp applications are relatively unknown and they are not widely published. Huge successes were for example DART and SPIKE. DART was a logistics system for the military (it is said to have repaid all the government expenses for AI research made) and SPIKE is s scheduling system for telescopes (originally for the Hubble Space Telescope). These applications were not written because some guys knew only Lisp, but because lots of the research applications in planning and scheduling systems were written in Lisp - because in this domain these applications work with symbolic representations of plans.
Maybe that generalizes, to say that it's the code that lisp doesn't turn into "Fungible Cogs", and so it can't be used by others in a standardized way.
Standardization seems to be anathema to the individuals who are attracted to lisp's power and flexibility. If lisp ever achieved code fungibility, lispers would hate it.
Standardization seems to be anathema to the individuals who are attracted to lisp's power and flexibility. If lisp ever achieved code fungibility, lispers would hate it.
6. And the LORD said, Behold, the people is one, and they have all one language; and this they begin to do: and now nothing will be restrained from them, which they have imagined to do.
7. Go to, let us go down, and there confound their language, that they may not understand one another's speech.
Genesis 11:6-7 http://www.omniglot.com/babel/english.htm#kj
7. Go to, let us go down, and there confound their language, that they may not understand one another's speech.
Genesis 11:6-7 http://www.omniglot.com/babel/english.htm#kj
And here I thought that was talking about perl...
I think a bigger factor is the amount of prior knowledge required before you can be productive.
In C (and c-like languages) that barrier is relatively low, a handful of concepts and a very limited subset of library modules and you can go a long long way.
In C (and c-like languages) that barrier is relatively low, a handful of concepts and a very limited subset of library modules and you can go a long long way.
Indeed. Lisp programmers with 20 years experience are more productive than Java programmers with 2 years experience. That doesn't say anything about Lisp vs Java (or, not nearly as much as some would claim it does).
This is a testable hypothesis due to the number of popular open source projects around we can draw from.
Ease of building new stuff brings fragmentation:
http://news.ycombinator.com/item?id=1013716
http://news.ycombinator.com/item?id=1013716
Ease of building it yourself compared to learning someone else's system is a major reason Lisp is languishing, in my opinion.
Oh, that why Perl is languishing too. Well, the problem is how hard it is to learn someone else's system in Perl. If Lisp has that problem, well, there you are.
Oh, that why Perl is languishing too. Well, the problem is how hard it is to learn someone else's system in Perl. If Lisp has that problem, well, there you are.
I don't think Lisp has that problem. Rather, it has the "problem" that it's easier to build the 20% you need of that library than to find the library, understand enough to do the bit you need in the face of that inevitable impedance mismatch between your abstractions and the library author's, figure out how including it impacts the rest of your system including the dependencies...
In other languages, this is just something everyone has to live with, and because of that, libraries face strong selection pressure to be one or more of simple, fast, standard, etc. There is no particular pressure like that in Lisp, since there's a much smaller domain where it's easy to understand why you need a thing, and troublesome to build it. To a much greater degree than mainstream languages, then, there are almost as many "language + standard library" sets as there are Lisp developers. You can see this same effect at work in Python web frameworks, I think.
In other languages, this is just something everyone has to live with, and because of that, libraries face strong selection pressure to be one or more of simple, fast, standard, etc. There is no particular pressure like that in Lisp, since there's a much smaller domain where it's easy to understand why you need a thing, and troublesome to build it. To a much greater degree than mainstream languages, then, there are almost as many "language + standard library" sets as there are Lisp developers. You can see this same effect at work in Python web frameworks, I think.
Perl is definitely not languishing. It just gets a bad rap from fans of other languages that are competing with it (particularly from the fans of Python and Ruby, the two upstarts trying to take its place).
Let's look at the number of jobs advertised for Perl, Python, Ruby, and Lisp over the last 5 years:
http://www.indeed.com/jobtrends?q=perl%2Cpython%2Cruby%2Clis...
The number of Perl jobs is more than those of Python and Ruby put together. Lisp has so few jobs it doesn't even really show up on the chart.
Then there's Perl's CPAN archive, with over 17,000 modules, with about 30 modules updated or added per day. That much development is a sign of an active, alive community.
So the rumors of Perl's demise are greatly exaggerated.
Let's look at the number of jobs advertised for Perl, Python, Ruby, and Lisp over the last 5 years:
http://www.indeed.com/jobtrends?q=perl%2Cpython%2Cruby%2Clis...
The number of Perl jobs is more than those of Python and Ruby put together. Lisp has so few jobs it doesn't even really show up on the chart.
Then there's Perl's CPAN archive, with over 17,000 modules, with about 30 modules updated or added per day. That much development is a sign of an active, alive community.
So the rumors of Perl's demise are greatly exaggerated.
Curiously, it's inherently impossible to compare what I think matters most for languages: solving new problems. To compare two languages you have to have people solve the same problem, and that means it has to be a predefined one.
I agree. Predefined problems are one way people compare languages; code snippet comparisons are the other. Neither touches the important thing, which is how languages differ as a medium for thought. Different languages give rise to different ideas, which give rise to different programs.
The other problem with studying this question formally is that it is so psychologically rooted that people almost invariably "find" that their favorite language turns out the best.
The other problem with studying this question formally is that it is so psychologically rooted that people almost invariably "find" that their favorite language turns out the best.
This is what statistics are for, and is exactly the same situation that many other disciplines find themselves in where treatment a influences treatment b.
Not the easiests of problems though. Do you know what statistics you would apply?
IQ measurements seem to have a similar problem: doing test a, influences your score on test b, because you get more used to the problems presented.. but doing test a and b just marginally increases your general intelligence, which is what you are trying to measure, while it might have a big influence on someone's score in these tests.
With IQ tests, you can expect that doing test c till z will eventually saturate someone.. but that might only work because you generally do not get the answers. In coding, you do get the answer back (whether your code compiles/works or not), so eventually both programmers will just be limited by the speed with which they type.
IQ measurements seem to have a similar problem: doing test a, influences your score on test b, because you get more used to the problems presented.. but doing test a and b just marginally increases your general intelligence, which is what you are trying to measure, while it might have a big influence on someone's score in these tests.
With IQ tests, you can expect that doing test c till z will eventually saturate someone.. but that might only work because you generally do not get the answers. In coding, you do get the answer back (whether your code compiles/works or not), so eventually both programmers will just be limited by the speed with which they type.
>Not the easiests of problems though. Do you know what statistics you would apply?
There are many ways. Off the top of my head:
- to focus on speed of development you could use a practice or warm-up
> provide each with a practice in another language
> provide a sample solution in pseudocode in both functional and imperative style
- To focus on speed of problem solving you could use topcoder data + research of participants programming language backgrounds.
The important thing is that if the effect is large it's easy to spot. According to some, the difference is an order of magnitude. If that's true, it will be trivial to spot.
There are many ways. Off the top of my head:
- to focus on speed of development you could use a practice or warm-up
> provide each with a practice in another language
> provide a sample solution in pseudocode in both functional and imperative style
- To focus on speed of problem solving you could use topcoder data + research of participants programming language backgrounds.
The important thing is that if the effect is large it's easy to spot. According to some, the difference is an order of magnitude. If that's true, it will be trivial to spot.
Perhaps one source of data is YC startups. What's the success rate of lisp vs. non-lisp?
Yes, of course, many things contribute to success other than language choice. That's my point.
Yes, of course, many things contribute to success other than language choice. That's my point.
> Surely if lisp makes a programmer N times more efficient then it would be easy to study scientifically. Have there been any studies comparing productivity?
I began to write a reply to your question, but decided that it deserved its own post:
http://www.loper-os.org/?p=85
I began to write a reply to your question, but decided that it deserved its own post:
http://www.loper-os.org/?p=85
"I began to write a reply to your question, but decided that it deserved its own post"
That isn't really a reply to the question posed. Just more ranting and raving.
Sample: "Yes, my dear bean counters, you can measure productivity. I would no more ask you to stop in your attempts at its measurement than I would ask mosquitoes to stop sucking blood. You can measure productivity – even of Lisp; even of political philosophies. You will simply need to secure a very large bag of beans – one deep enough to hold a bean for every twist and turn of a century of tinkering, politicking, and everything else associated with the messy business of successfully thinking new thoughts."
The best interpretation of this drivel is that you want people to accept your claims of superior productivity just on your say so but not ask for any evidence because asking you back up your unsubstantiated claims of superiority would be "bean counting".
Forget the scientific studies. There is another kind of "evidence" in programming - write code that is evidently superior. The best way to show that (say) Linux is an "inferior" operating system is to build one better. Not talk about making one sometime in the misty future. Build. Then talk.
Endless rants aren't as good. As silentbicycle says elsewhere
"I just take issue with how some particularly vocal Lispers have been sitting on the sidelines going, "Our language is THE BEST LANGUAGE" for decades. ("Sick of being a blub programmer and working in Blub? Try our Language For Smart People.") They're so used to being smug because their language was thirty years ahead of its time, fifty years ago."
That isn't really a reply to the question posed. Just more ranting and raving.
Sample: "Yes, my dear bean counters, you can measure productivity. I would no more ask you to stop in your attempts at its measurement than I would ask mosquitoes to stop sucking blood. You can measure productivity – even of Lisp; even of political philosophies. You will simply need to secure a very large bag of beans – one deep enough to hold a bean for every twist and turn of a century of tinkering, politicking, and everything else associated with the messy business of successfully thinking new thoughts."
The best interpretation of this drivel is that you want people to accept your claims of superior productivity just on your say so but not ask for any evidence because asking you back up your unsubstantiated claims of superiority would be "bean counting".
Forget the scientific studies. There is another kind of "evidence" in programming - write code that is evidently superior. The best way to show that (say) Linux is an "inferior" operating system is to build one better. Not talk about making one sometime in the misty future. Build. Then talk.
Endless rants aren't as good. As silentbicycle says elsewhere
"I just take issue with how some particularly vocal Lispers have been sitting on the sidelines going, "Our language is THE BEST LANGUAGE" for decades. ("Sick of being a blub programmer and working in Blub? Try our Language For Smart People.") They're so used to being smug because their language was thirty years ahead of its time, fifty years ago."
The best interpretation of this drivel is that you want people to accept your claims of superior productivity just on your say so but not ask for any evidence because asking you back up your unsubstantiated claims of superiority would be "bean counting".
The obvious interpretation is that he's saying something like "the usual definition of productivity is flawed and myopic, and gets in the way of realizing the power of Lisp". The paragraph you quoted (implied as a representative sample) is indeed pretty much content-free, because it was a gratuitous flourish at the end.
Of course there is indeed a lot of assertion couched in flowery language there, but that's not the same as "because I say so and if you disagree you're a poopyhead" which is what you seem to have gotten from it. You also seemed to miss the part where he argued that multiple major concepts in modern software originated on the Lisp Machine, which would seem to more than qualify as "building something better".
I'm assuming you're not naive enough to think that "better" equates to "successful", which is another issue entirely.
The obvious interpretation is that he's saying something like "the usual definition of productivity is flawed and myopic, and gets in the way of realizing the power of Lisp". The paragraph you quoted (implied as a representative sample) is indeed pretty much content-free, because it was a gratuitous flourish at the end.
Of course there is indeed a lot of assertion couched in flowery language there, but that's not the same as "because I say so and if you disagree you're a poopyhead" which is what you seem to have gotten from it. You also seemed to miss the part where he argued that multiple major concepts in modern software originated on the Lisp Machine, which would seem to more than qualify as "building something better".
I'm assuming you're not naive enough to think that "better" equates to "successful", which is another issue entirely.
"The obvious interpretation is that he's saying something like "the usual definition of productivity is flawed and myopic, and gets in the way of realizing the power of Lisp". "
Just the fact of him sayng something like that doesn't make it true. More logic, supporting arguments and evidence is called for to support such claims. Besides He isn't offering any (lucid) alternative definition. Just rant after rant , over a period of years. Which makes the whole post (and link to it on HN) very content free (imo, feel free to disagree and vote accordingly).
Yes , sure Lisp is cool. There I said it. But hey Linux is cool too. So is C. So are a lot of things.
Just the fact of him sayng something like that doesn't make it true. More logic, supporting arguments and evidence is called for to support such claims. Besides He isn't offering any (lucid) alternative definition. Just rant after rant , over a period of years. Which makes the whole post (and link to it on HN) very content free (imo, feel free to disagree and vote accordingly).
Yes , sure Lisp is cool. There I said it. But hey Linux is cool too. So is C. So are a lot of things.
> The best way to show that (say) Linux is an "inferior" operating system is to build one better.
One of the most valued metrics of "better" is "how does it fit into the ecosystem". Plan 9 is clearly superior to Linux. It has cleaner interfaces, one person can understand it, lot's of things are unified that were disparate etc. etc. Everyone who uses both extensively berates Linux at every turn.
Mention it in more general spaces as HN, Reddit, Slashdot etc. and you will be told it is a failure, flop, doesn't have program X so it's useless, etc. etc.
Popularity means nothing
http://www.tiobe.com/content/paperinfo/tpci/index.html
The previous winners of the "Language of the Year" award are shown below.
One of the most valued metrics of "better" is "how does it fit into the ecosystem". Plan 9 is clearly superior to Linux. It has cleaner interfaces, one person can understand it, lot's of things are unified that were disparate etc. etc. Everyone who uses both extensively berates Linux at every turn.
Mention it in more general spaces as HN, Reddit, Slashdot etc. and you will be told it is a failure, flop, doesn't have program X so it's useless, etc. etc.
Popularity means nothing
http://www.tiobe.com/content/paperinfo/tpci/index.html
The previous winners of the "Language of the Year" award are shown below.
Year Winner
2008 C
2007 Python
2006 Ruby
2005 Java
2004 PHP
2003 C++"Plan 9 is clearly superior to Linux. It has cleaner interfaces, one person can understand it, lot's of things are unified that were disparate etc. etc. "
I have no argument with this,
"Everyone who uses both extensively berates Linux at every turn."
I seriously doubt this. Please provide any evidence you have.
If the makers of plan 9 were to say "Linux is crap" at least they have the credibility to say so. It is noteworthy that they would never say something so stupid. Linux (and yes Plan 9) aren't the acme of perfection. But neither are the "lisp os" es. Raising ancient lisp systems to some unreachable pedestal of perfection , especially by people who've never seen or used on and have just read about them, is dubious
This is just a blogger with lots of crummy blog posts and no code. At best he is incoherent and at worst deluded.
To repeat my point was not that Linux is the best OS ever. But for me (or anyone else) to go around screaming that everything that is popular is all delusion is pointless (and strictly imo) shouldn't be paid any attention.
"The previous winners of the "Language of the Year" award are shown below.
"Popularity means nothing"
Popularity is not everything but it sure isn't "nothing" either.
I have no argument with this,
"Everyone who uses both extensively berates Linux at every turn."
I seriously doubt this. Please provide any evidence you have.
If the makers of plan 9 were to say "Linux is crap" at least they have the credibility to say so. It is noteworthy that they would never say something so stupid. Linux (and yes Plan 9) aren't the acme of perfection. But neither are the "lisp os" es. Raising ancient lisp systems to some unreachable pedestal of perfection , especially by people who've never seen or used on and have just read about them, is dubious
This is just a blogger with lots of crummy blog posts and no code. At best he is incoherent and at worst deluded.
To repeat my point was not that Linux is the best OS ever. But for me (or anyone else) to go around screaming that everything that is popular is all delusion is pointless (and strictly imo) shouldn't be paid any attention.
"The previous winners of the "Language of the Year" award are shown below.
Year Winner
2008 C
2007 Python
2006 Ruby
2005 Java
2004 PHP
2003 C++"
"Popularity means nothing"
Popularity is not everything but it sure isn't "nothing" either.
> Please provide any evidence you have.
Only the power of my own ear at Plan9 conferences from people who know a damn sight more about such things than I. I could pull various mailing list posts out, such as the big argument of Rob Pike with Linus but what's the point.
> If the makers of plan 9 were to say "Linux is crap" at least they have the credibility to say so. It is noteworthy that they would never say something so stupid.
From the Plan9 fortune file : "Linux: written by amateurs for amateurs." - D. Presotto
> And the point is?
That the technical merit of the language doesn't determine it's popularity. So choosing what is the "better language" is rendered pointless.
>Popularity is not everything but it sure isn't "nothing" either.
Yes, I read that back after the edit time ran out and wanted to change it. Popularity and userbase isn't the correct metric for quality.
Only the power of my own ear at Plan9 conferences from people who know a damn sight more about such things than I. I could pull various mailing list posts out, such as the big argument of Rob Pike with Linus but what's the point.
> If the makers of plan 9 were to say "Linux is crap" at least they have the credibility to say so. It is noteworthy that they would never say something so stupid.
From the Plan9 fortune file : "Linux: written by amateurs for amateurs." - D. Presotto
> And the point is?
That the technical merit of the language doesn't determine it's popularity. So choosing what is the "better language" is rendered pointless.
>Popularity is not everything but it sure isn't "nothing" either.
Yes, I read that back after the edit time ran out and wanted to change it. Popularity and userbase isn't the correct metric for quality.
""Linux: written by amateurs for amateurs." - D. Presotto"
This is (in a strict sense) true and is not the same as "linux is crap". Linus was certainly an amateur when he wrote the first version of the kernel in the sense that was the first OS kernel he wrote) and many people who contribute are not tenured professors(or whatever your definition of "professional" happens to be). The fact remains that an "amateur" teenager in Finland ran rings around the "professionals".
"That the technical merit of the language doesn't determine it's popularity. So choosing what is the "better language" is rendered pointless."
I agree. But that is the point isn't it? You can't choose "the better language" anyway. The mythical Lisp OS isn't really "better" either unless you've made up your mind up front. So why go on and on for years (the blogger not you)about "everything popular is crap and Lisp is the ultimate leet cool thing forever and forever and anyone who doesn't accept this is an idiot" instead of focussing on actually writing some code?
This is (in a strict sense) true and is not the same as "linux is crap". Linus was certainly an amateur when he wrote the first version of the kernel in the sense that was the first OS kernel he wrote) and many people who contribute are not tenured professors(or whatever your definition of "professional" happens to be). The fact remains that an "amateur" teenager in Finland ran rings around the "professionals".
"That the technical merit of the language doesn't determine it's popularity. So choosing what is the "better language" is rendered pointless."
I agree. But that is the point isn't it? You can't choose "the better language" anyway. The mythical Lisp OS isn't really "better" either unless you've made up your mind up front. So why go on and on for years (the blogger not you)about "everything popular is crap and Lisp is the ultimate leet cool thing forever and forever and anyone who doesn't accept this is an idiot" instead of focussing on actually writing some code?
We are in agreement, mostly :).
I don't know which professionals rings around were run, but again, who cares, that's just conjecture, the conjuncture was between a need for a free Unix, BSD sat in court, the GPL, LAMP. The result was the cartesian product that remains today.
In the world of worse is better, Plan9 wasn't bad enough !
I don't know which professionals rings around were run, but again, who cares, that's just conjecture, the conjuncture was between a need for a free Unix, BSD sat in court, the GPL, LAMP. The result was the cartesian product that remains today.
In the world of worse is better, Plan9 wasn't bad enough !
"In the world of worse is better, Plan9 wasn't bad enough !"
ha! Great comment! :-) I wish someone would write a book on Plan9 (like the Lion's Commentary book for Unix).
ha! Great comment! :-) I wish someone would write a book on Plan9 (like the Lion's Commentary book for Unix).
There's this http://lsub.org/who/nemo/9.pdf
and the intro to plan9 http://lsub.org/who/nemo/9.intro.pdf
and, tbh, I've read the kernel source code and it isn't that hard to follow - which is one of the goals - there's even an LXR http://fxr.watson.org/fxr/source/?v=PLAN9
and the intro to plan9 http://lsub.org/who/nemo/9.intro.pdf
and, tbh, I've read the kernel source code and it isn't that hard to follow - which is one of the goals - there's even an LXR http://fxr.watson.org/fxr/source/?v=PLAN9
I refer you to:
http://news.ycombinator.com/item?id=1016762
What's wrong with that as evidence for lisps superiority?
http://news.ycombinator.com/item?id=1016762
What's wrong with that as evidence for lisps superiority?
What's wrong is that they measured the performance of Lisp programmers vs Java/C++ programmers. This is fine but you're not comparing the merits of the programming language. The Lisp programmers would win even if they were forced to program in Java.
Maybe it's not that lisp makes any programmer more productive, but that it offers the anecdotal "order of magnitude more productive" programmer features that Java, being designed for the "interchangeable cog" programmer, does not.
[deleted]
Paul Graham writes about this extensively in http://www.paulgraham.com/avg.html
It's computer science not computer woo. I'm asking for evidence not anecdote :)
Surely, there has to be at least some evidence in it's 50 years? Especially given the claimed huge effect size.
Surely, there has to be at least some evidence in it's 50 years? Especially given the claimed huge effect size.
It's simply impossible to isolate and control all of the important variables involved in developing any software of any significant size. There's a reason for the lack of productivity data for programming in general.
One impossible study:
http://news.ycombinator.com/item?id=1016762
http://news.ycombinator.com/item?id=1016762
Do you think if it were repeated today with a recent version of the JDK Java development time might be less? Probably not as low as Lisp but things have improved in Java land since 1.2.
That synopsis of a study is nice but I'm still not convinced all the important variables were isolated.
That synopsis of a study is nice but I'm still not convinced all the important variables were isolated.
Eclipse + java6 would make a marked difference, agreed.
That sounds like a lisp proponent's problem, quoting stats he can't back up.
There are a dozen reasons the data would be bogus but I only need to state the most obvious: you can't use the same person in 2 comparable tests because the tasks would be either too trivial or too similar; likewise you cannot use different people in groups for the tests because people are too different.
Smart and dumb people have succeeded with all kinds of languages on all kinds of platforms that are widely viewed as amazing and terrible and everywhere in between, on all kinds of projects.
Smart and dumb people have succeeded with all kinds of languages on all kinds of platforms that are widely viewed as amazing and terrible and everywhere in between, on all kinds of projects.
trapper, this study might be in the flavor of what you are seeking. http://www.flownet.com/gat/papers/lisp-java.pdf (2000)
There has never been a rigorous scientific study done, no, but there's plenty of anecdotal evidence, and, to quote Paul Krugman's tongue-in-cheek title, "the plural of anecdote is data"
That's the same explanation psychics give. If the effect size is large (as is claimed), it should be an extremely simple study. So why has no one done it?
Why don't the lispers organize a RAD competition between lisp and all-comers, surely if lisp is that much more productive you would see the top ten places being lisp dialects.
Would you agree?
Why don't the lispers organize a RAD competition between lisp and all-comers, surely if lisp is that much more productive you would see the top ten places being lisp dialects.
Would you agree?
Extremely simple in principle, obscenely difficult in implementation. The real difficulty is the confounding variables. Being unable to accurately measure or predict things like level of language familiarity, programming experience, domain knowledge, or intelligence means that it'd be impossible to tie any visible effects to something as simple as language choice.
So, no, I wouldn't agree.
The best study I could think of off hand would be a randomized study of programming productivity (measured somehow) of programming naïve high schoolers. Each subject gets an incentive to learn some language over the course of X weeks and then program something. The sample size would have to be magnificent even to prove a large effect because you'd need to demonstrate control for intelligence/drive and regressing out math scores (or anything similar) would not be convincing really. At the end, you'd still not be able to talk too much about working productivity, but you might have a chance of talking about... anything at all.
Actually, this is an extraordinarily difficult study I think.
So, no, I wouldn't agree.
The best study I could think of off hand would be a randomized study of programming productivity (measured somehow) of programming naïve high schoolers. Each subject gets an incentive to learn some language over the course of X weeks and then program something. The sample size would have to be magnificent even to prove a large effect because you'd need to demonstrate control for intelligence/drive and regressing out math scores (or anything similar) would not be convincing really. At the end, you'd still not be able to talk too much about working productivity, but you might have a chance of talking about... anything at all.
Actually, this is an extraordinarily difficult study I think.
Perhaps high-school or college students are poor evaluators of a language. I am not only interested in how productive you are after 1 year of using a language, I'm also interested how productive you are after 10 years using that language, or with 10 years of legacy code.
Well, I'm not sure a RAD competition would necessarily be considered scientific. For one, the sample size is small. It also ignores properties such as maintainability, assuming "first to finish" is your only criteria. Finally, it's necessarily a fairly small application I would think.
As for studies, a quick search on google came up with this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117...
Which concludes that "Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++."
I couldn't find much more in a short time. Perhaps my search terms, "functional programming imperative productivity" were inappropriate.
As for studies, a quick search on google came up with this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117...
Which concludes that "Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++."
I couldn't find much more in a short time. Perhaps my search terms, "functional programming imperative productivity" were inappropriate.
Now that is interesting. I personally agree with the hypothesis that lisp is a step forward, but often wonder why it's an anecdotal argument than one that is data backed.
This paper although makes me think they compared programmers not languages, as the imperative language programmers didn't have any functional experience. It would be interesting to see a comparison between programmers of roughly equal competency.
This paper although makes me think they compared programmers not languages, as the imperative language programmers didn't have any functional experience. It would be interesting to see a comparison between programmers of roughly equal competency.
Mostly it's due to a lack of good, controlled, data. The ideal study would need to be of a large and complex system that was recreated several times in several languages. You'd need to verify each system behaved the same, and that the teams on each version were nearly equally competent in their respective languages. Even that would be poor, since it would be a single data point. Perhaps a particular language was simply good at that problem!
Despite that complaint, the above is nearly impossible to do in practice. So you have to settle for smaller problems, which can be done in several months perhaps. Even at that, it would take some very difficult collaboration, and would still be a single data point.
Further complicating issues is the academic world vs. industry. Again, ideally you'd want to do the test in industry, with an appropriate team of programmers and managers. But industry doesn't want to waste time with such academic matters, nor does it want to open it's code for analysis.
In other words, it's a very difficult problem to address, despite being seemingly simple on the surface.
Despite that complaint, the above is nearly impossible to do in practice. So you have to settle for smaller problems, which can be done in several months perhaps. Even at that, it would take some very difficult collaboration, and would still be a single data point.
Further complicating issues is the academic world vs. industry. Again, ideally you'd want to do the test in industry, with an appropriate team of programmers and managers. But industry doesn't want to waste time with such academic matters, nor does it want to open it's code for analysis.
In other words, it's a very difficult problem to address, despite being seemingly simple on the surface.
This paper is another interesting anecdote, unfortunately. They're not really claiming anything quantitatively.
Also, though it's not explicit, I feel it's obvious that the researchers had a prior bias toward functional languages.
Also, though it's not explicit, I feel it's obvious that the researchers had a prior bias toward functional languages.
A competition to solve a toy problem wouldn't necessarily say much, though. So the question is, how big of a problem would you need, and where are you going to find enough programmers (of reasonable and roughly similar competence) who don't have anything better to do than spend multiple hours participating in a glorified programming language pissing match?
In other words, the reason why not is probably "because organizing things is hard work".
In other words, the reason why not is probably "because organizing things is hard work".
If the effect size is large (i.e. the magnitude of difference between the means of lisp vs non-lisp programmers) the size of problem should be irrelevant.
Many thousands of programmers spend hours each week in pissing matches online. Why is it none of them feel like truly putting their money where their mouth is?
Many thousands of programmers spend hours each week in pissing matches online. Why is it none of them feel like truly putting their money where their mouth is?
If the effect size is large (i.e. the magnitude of difference between the means of lisp vs non-lisp programmers) the size of problem should be irrelevant.
Writing a "Hello, world" is going to take about the same amount of time in any language that isn't a turing tarpit. At issue is generally some sort of asymptotic advantage, not a guarantee of "language X will always be superior every time always". In fact, for any pair of one easy and one hard problem, I'm pretty confident I could find (or invent, if necessary) two languages that each beat the other for solving one of the problems.
The claimed benefits of a more expressive language generally involve things like better management of application complexity, or greater ability to modify and restructure late in the project. Hammering out a program of a scale such that the programmer can keep an accurate model of the entire thing in mind at one time, and that is only written and never modified, would be more a measure of the programmer's typing speed and the sophistication of the IDE used than anything else.
Writing a "Hello, world" is going to take about the same amount of time in any language that isn't a turing tarpit. At issue is generally some sort of asymptotic advantage, not a guarantee of "language X will always be superior every time always". In fact, for any pair of one easy and one hard problem, I'm pretty confident I could find (or invent, if necessary) two languages that each beat the other for solving one of the problems.
The claimed benefits of a more expressive language generally involve things like better management of application complexity, or greater ability to modify and restructure late in the project. Hammering out a program of a scale such that the programmer can keep an accurate model of the entire thing in mind at one time, and that is only written and never modified, would be more a measure of the programmer's typing speed and the sophistication of the IDE used than anything else.
If a problem is so trivial that creating a domain-specific language isn't worth the effort, the best solution will be equally ugly in any language and Lisp loses its advantages.
I think the comments here about the free software community, and particularly the Linux example, are really off base.
Consider Linux: the poster child of successful free software. It is a knockoff of a 1970s operating system well past its sell-by date.
What does that even mean? Linux (as a kernel) does an excellent job at what it is designed to do. I don't know what is meant by "innovation" here. If the author has a fundamentally different kernel design that is actually better, do tell.
On the other hand, at the subsystem level, there is lots of innovation in the Linux kernel. The Completely Fair Scheduler (CFS) is a good recent example.
This is because a herd simply cannot innovate, whether for fun or for profit. Every innovative work of mankind has been the product of one – sometimes two, rarely three – minds.
Linux development is not driven by a "herd". It's driven by a group of pretty elite programmers known as the subsystem maintainers.
All the major patches are done by one expert, and many of them are fairly innovative. Ingo Molnar did CFS. Ted Ts'o does a lot of really high profile work on filesystems. There are many more examples.
The Linux development process is lightyears ahead of the typical industrial development process. Git, which was created by and for Linux kernel hackers, has been instrumental in helping Linux get ahead.
Distributed version control is a fundamental innovation in software development, and Git is the most successful DVCS by far.
(Other than that, I think the author makes a great point, and I agree with him 100%. That's why I have so far avoided working for big software companies.)
Consider Linux: the poster child of successful free software. It is a knockoff of a 1970s operating system well past its sell-by date.
What does that even mean? Linux (as a kernel) does an excellent job at what it is designed to do. I don't know what is meant by "innovation" here. If the author has a fundamentally different kernel design that is actually better, do tell.
On the other hand, at the subsystem level, there is lots of innovation in the Linux kernel. The Completely Fair Scheduler (CFS) is a good recent example.
This is because a herd simply cannot innovate, whether for fun or for profit. Every innovative work of mankind has been the product of one – sometimes two, rarely three – minds.
Linux development is not driven by a "herd". It's driven by a group of pretty elite programmers known as the subsystem maintainers.
All the major patches are done by one expert, and many of them are fairly innovative. Ingo Molnar did CFS. Ted Ts'o does a lot of really high profile work on filesystems. There are many more examples.
The Linux development process is lightyears ahead of the typical industrial development process. Git, which was created by and for Linux kernel hackers, has been instrumental in helping Linux get ahead.
Distributed version control is a fundamental innovation in software development, and Git is the most successful DVCS by far.
(Other than that, I think the author makes a great point, and I agree with him 100%. That's why I have so far avoided working for big software companies.)
The success of Linux deserves serious consideration, but breathless marvel at Linux and its development practices is entirely misplaced.
All the major patches are done by one expert, and many of them are fairly innovative. Ingo Molnar did CFS. Ted Ts'o does a lot of really high profile work on filesystems. There are many more examples.
Linux is full of examples of poorly designed systems being slipshod replaced for slightly better designed systems that are well behind the state of the art.
In the same time Linux has gone through multiple schedulers (and scheduler flamewars), FreeBSD developers have designed, implemented, tested, and iterated on ULE, and then ULE2, finally (after much review, testing, and careful consideration) merged it and made ULE2 the default scheduler.
The scheduler wasn't adopted until it was investigated from all angles over years, and found to not introduce any significant performance regressions.
The kicker? The previous scheduler was on par with Linux, ULE2 seems to perform considerably better for many workloads (eg, MySQL) on many-core machines.
Innovation isn't magic -- it involves a lot of hard work and careful design by a lot of people.
The Linux development process is lightyears ahead of the typical industrial development process. Git, which was created by and for Linux kernel hackers, has been instrumental in helping Linux get ahead.
Really? I'm not sure what innovations you're thinking of here.
All the major patches are done by one expert, and many of them are fairly innovative. Ingo Molnar did CFS. Ted Ts'o does a lot of really high profile work on filesystems. There are many more examples.
Linux is full of examples of poorly designed systems being slipshod replaced for slightly better designed systems that are well behind the state of the art.
In the same time Linux has gone through multiple schedulers (and scheduler flamewars), FreeBSD developers have designed, implemented, tested, and iterated on ULE, and then ULE2, finally (after much review, testing, and careful consideration) merged it and made ULE2 the default scheduler.
The scheduler wasn't adopted until it was investigated from all angles over years, and found to not introduce any significant performance regressions.
The kicker? The previous scheduler was on par with Linux, ULE2 seems to perform considerably better for many workloads (eg, MySQL) on many-core machines.
Innovation isn't magic -- it involves a lot of hard work and careful design by a lot of people.
The Linux development process is lightyears ahead of the typical industrial development process. Git, which was created by and for Linux kernel hackers, has been instrumental in helping Linux get ahead.
Really? I'm not sure what innovations you're thinking of here.
- Solaris' ZFS vs (incomplete) btrfs
- *BSD's kqueue vs. epoll/inotify/dnotify/
- Solaris' zones vs ?
- FreeBSD vimage (network stack virtualization) vs ?
OK I'm confused now..
I think what the commenter meant was the cathedral vs the bazaar model of development. Would'nt FreeBSD, NetBSD, etc all be in the same boat as Linux? Granted that Linux has a benevolent-dictator-aka-linus, but that does not make it deviate too much from the bazaar model.
For all its flaws, git (and github) are becoming the preferred choice of hackers everywhere - I'm not staunchly one of them yet, but I can see the charm. Git only enhances the distributed development model that all *nixes are built upon.
If any, Solaris is the only counter-example to Linux - not FreeBSD.
I think what the commenter meant was the cathedral vs the bazaar model of development. Would'nt FreeBSD, NetBSD, etc all be in the same boat as Linux? Granted that Linux has a benevolent-dictator-aka-linus, but that does not make it deviate too much from the bazaar model.
For all its flaws, git (and github) are becoming the preferred choice of hackers everywhere - I'm not staunchly one of them yet, but I can see the charm. Git only enhances the distributed development model that all *nixes are built upon.
If any, Solaris is the only counter-example to Linux - not FreeBSD.
I think what the commenter meant was the cathedral vs the bazaar model of development. Would'nt FreeBSD, NetBSD, etc all be in the same boat as Linux? Granted that Linux has a benevolent-dictator-aka-linus, but that does not make it deviate too much from the bazaar model.
Most other kernel development teams operate with a considerably more conservative approach ("the cathedral") than is engendered by Linux and specifically enabled by dvcs/git ("the bazaar").
In Eric Raymond's essay, he contrasted the two development models as such (quoting wikipedia):
The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC are presented as examples.
The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.
http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
I'd say just about every other kernel available today is developed in "the cathedral", although even then I think that Raymond's comparison (and judgments) are a vast oversimplification.
For all its flaws, git (and github) are becoming the preferred choice of hackers everywhere
Some very vocal people, but not what I'd say "hackers everywhere". As a regularly user of hg and git, I'm not particularly convinced that dvcs provides significantly compelling advantages outside of Linux's development model.
If any, Solaris is the only counter-example to Linux - not FreeBSD.
I'm not sure why you'd say that is.
Most other kernel development teams operate with a considerably more conservative approach ("the cathedral") than is engendered by Linux and specifically enabled by dvcs/git ("the bazaar").
In Eric Raymond's essay, he contrasted the two development models as such (quoting wikipedia):
The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC are presented as examples.
The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.
http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
I'd say just about every other kernel available today is developed in "the cathedral", although even then I think that Raymond's comparison (and judgments) are a vast oversimplification.
For all its flaws, git (and github) are becoming the preferred choice of hackers everywhere
Some very vocal people, but not what I'd say "hackers everywhere". As a regularly user of hg and git, I'm not particularly convinced that dvcs provides significantly compelling advantages outside of Linux's development model.
If any, Solaris is the only counter-example to Linux - not FreeBSD.
I'm not sure why you'd say that is.
If any, Solaris is the only counter-example to Linux - not FreeBSD.
>I'm not sure why you'd say that is.
That was my attempt at classifying the corporate umbrella of Solaris to be THE cathedral vs the bazaar of Linux ... and, as you say, the middle ground of FreeBSD.
I dont have context here, but it was very surprising to read your comment about FreeBSD being closer to the cathedral model. I was aware of GCC and Emacs being unapologetically so, but I thought BSD had a more open development model - the myriad flavors of BSD being a proof of that.
>I'm not sure why you'd say that is.
That was my attempt at classifying the corporate umbrella of Solaris to be THE cathedral vs the bazaar of Linux ... and, as you say, the middle ground of FreeBSD.
I dont have context here, but it was very surprising to read your comment about FreeBSD being closer to the cathedral model. I was aware of GCC and Emacs being unapologetically so, but I thought BSD had a more open development model - the myriad flavors of BSD being a proof of that.
I agree with what sandGorgon said.
I'm not defending the Linux kernel in comparison to other FOSS projects, especially really excellent ones like FreeBSD and possibly Solaris. Linux and FreeBSD have different comparative advantages over each other. My point is that both are way ahead of your typical Java shop, and way ahead of Windows, and that FOSS and Linux do not deserve the beating given to them by the author of the blog post.
AFAIK CFS is considered >= ULE2 by most people, and I'm not aware of significant regressions introduced by CFS, so the high degree of conservatism you pointed out in the FreeBSD project wouldn't have been warranted in this case. I don't have the background to argue the finer points of this issue, but it's off topic for this thread, anyway.
Also, you quote me talking about Git, and then say, "I'm not sure what innovations you're thinking of here." I'm thinking about git and the large-scale distributed development model that was pioneered by the Linux community.
I'm not defending the Linux kernel in comparison to other FOSS projects, especially really excellent ones like FreeBSD and possibly Solaris. Linux and FreeBSD have different comparative advantages over each other. My point is that both are way ahead of your typical Java shop, and way ahead of Windows, and that FOSS and Linux do not deserve the beating given to them by the author of the blog post.
AFAIK CFS is considered >= ULE2 by most people, and I'm not aware of significant regressions introduced by CFS, so the high degree of conservatism you pointed out in the FreeBSD project wouldn't have been warranted in this case. I don't have the background to argue the finer points of this issue, but it's off topic for this thread, anyway.
Also, you quote me talking about Git, and then say, "I'm not sure what innovations you're thinking of here." I'm thinking about git and the large-scale distributed development model that was pioneered by the Linux community.
My point is that both are way ahead of your typical Java shop, and way ahead of Windows, and that FOSS and Linux do not deserve the beating given to them by the author of the blog post.
I think that's a bit unfair to Java shops. =)
AFAIK CFS is considered >= ULE2 by most people, and I'm not aware of significant regressions introduced by CFS, so the high degree of conservatism you pointed out in the FreeBSD project wouldn't have been warranted in this case. I don't have the background to argue the finer points of this issue, but it's off topic for this thread, anyway.
CFS is based on knowledge gleaned from years of work on earlier schedulers by Con Kolivas and Ingo Molnar. In the meantime, the scheduler was replaced several times in the "stable" tree while they "figured it out". It took just as long, made a bigger mess, and ultimately cost more to produce (not to mention all the flamewars and bad blood engendered in the process).
Whether CFS >= ULE2 is a very nuanced question, but it's fair to say that the schedulers are much closer.
I think that's a bit unfair to Java shops. =)
AFAIK CFS is considered >= ULE2 by most people, and I'm not aware of significant regressions introduced by CFS, so the high degree of conservatism you pointed out in the FreeBSD project wouldn't have been warranted in this case. I don't have the background to argue the finer points of this issue, but it's off topic for this thread, anyway.
CFS is based on knowledge gleaned from years of work on earlier schedulers by Con Kolivas and Ingo Molnar. In the meantime, the scheduler was replaced several times in the "stable" tree while they "figured it out". It took just as long, made a bigger mess, and ultimately cost more to produce (not to mention all the flamewars and bad blood engendered in the process).
Whether CFS >= ULE2 is a very nuanced question, but it's fair to say that the schedulers are much closer.
Um, the distributed development model was pioneered by BitKeeper, not Linux.
MySQL ought to get more credit, they were in BitKeeper long before Linux was.
MySQL ought to get more credit, they were in BitKeeper long before Linux was.
It's true that the FreeBSD process is far more likely to result in an ideal design, but Linux's approach of "build it fast, replace it fast" might average as a win in terms of total number of tolerably performing features per development time, and volume of the search space explored.
Distributed version control is a fundamental innovation in software development, and Git is the most successful DVCS by far.
Is this is the same git that Torvalds tossed together as a quick hack to replace the proprietary BitKeeper DVCS after the company stopped offering free licenses to Linux developers?
Is this is the same git that Torvalds tossed together as a quick hack to replace the proprietary BitKeeper DVCS after the company stopped offering free licenses to Linux developers?
It started out that way, but as I said, Git is now by far the leading DVCS, and AFAIK, the Linux community was the first to do DVCS on a grand scale. Furthermore, Git is surely a tremendous improvement over BitKeeper.
That's innovation in software development process.
That's innovation in software development process.
Why do you think it's a tremendous improvement over BitKeeper? Have you used it?
I suspect s/he thinks Git is better because it is open source.
I've used both a lot and Git is faster at some things but BitKeeper gets some things right that Git does not, such as renames, per file comments, digging around in the history.
I think the right answer is that we're all better off because of both. BitKeeper was the original DSCM and paved the way, Git is open source, they are both actively moving forward, hard not to like that.
I've used both a lot and Git is faster at some things but BitKeeper gets some things right that Git does not, such as renames, per file comments, digging around in the history.
I think the right answer is that we're all better off because of both. BitKeeper was the original DSCM and paved the way, Git is open source, they are both actively moving forward, hard not to like that.
Nah, I think it's the git that Torvalds wrote when he decided that Monotone had some pretty cool ideas (the whole distributed VCS thing) but was slow and written in icky C++.
Both statements are true- it was a hack to replace BitKeeper after the Tridgell disaster, and it was inspired by monotone, which he deemed irreparably slow.
Yeah. He caught monotone at a bad time. Graydon had just gone on sabbatical...
Also, 'disaster' is a bit...harsh. As I heard, he just telnet'd and asked for "help".
Also, 'disaster' is a bit...harsh. As I heard, he just telnet'd and asked for "help".
Well... it was a disaster in the sense that it caused a row and meant they had to switch versioning systems.
I enjoyed reading the article but don't really agree with quite a bit of it. I do agree that single individuals or very small teams most often make great breakthroughs, and that languages like Java do yield more "fungibilty."
I don't really agree with the Lisp-centric discussion because I have worked with many fine programmers who used several different languages. The right person makes a bigger impact than language selection.
As far as productivity goes, building a web portal in rails is far faster than using Lisp, and in my opinion will yield more maintainable code.
That said, I am using Common Lisp a lot right now because I am working on a book about AllegroGraph. (BTW, one good "home" for Lisp is back end services.)
I don't really agree with the Lisp-centric discussion because I have worked with many fine programmers who used several different languages. The right person makes a bigger impact than language selection.
As far as productivity goes, building a web portal in rails is far faster than using Lisp, and in my opinion will yield more maintainable code.
That said, I am using Common Lisp a lot right now because I am working on a book about AllegroGraph. (BTW, one good "home" for Lisp is back end services.)
I am surprised this piece of trashy fanboi writing is so high on the HN front page. The whole site is full of "lisp is the coolest. Everything else sucks" type borderline trollish posts, endlessly recycling the "lisp is better than everything else" meme. As usual, the HN discussion is better than the crummy article, which may be the desired end result aftr all.
As a hiring manager, who has managed and fired lisp people, I sort of see both sides of this.
If the problem domain fits lisp, yup, no argument, lisp rocks. I used the Xerox lisp machines and it was really cool in the sense that there was no user land or kernel, it was all one thing. Cool for debugging, cool for performance, very cool when it is a fit.
On the other hand, many problem domains are not a good lisp fit. In fact, most fall into that category, in my not so humble opinion.
As a manager, I look at the technology used to produce a product, I think about development costs (a little) and support costs (a lot). One hot shot lisp hacker that can do whatever is cool, but that's in the "little" category. The "lot" is about support and the hotshots aren't that excited about support, it's boring.
There are other threads all over the intertubes about reading and supporting code and the funny thing is that very few, if any, talk about lisp. All the lisp ones are about "how I can do this cool shit really fast and it makes me feel oh so powerful". Yeah, whatever. I'm happy you are happy. But what I, as a manager, need is the ability to take your cool shit and ship it and debug it and support it for the next decade or two and do all that when you, the studly lisp hacker, have moved on.
Not really liking the prospect of doing that with a big steaming pile of lisp.
If the problem domain fits lisp, yup, no argument, lisp rocks. I used the Xerox lisp machines and it was really cool in the sense that there was no user land or kernel, it was all one thing. Cool for debugging, cool for performance, very cool when it is a fit.
On the other hand, many problem domains are not a good lisp fit. In fact, most fall into that category, in my not so humble opinion.
As a manager, I look at the technology used to produce a product, I think about development costs (a little) and support costs (a lot). One hot shot lisp hacker that can do whatever is cool, but that's in the "little" category. The "lot" is about support and the hotshots aren't that excited about support, it's boring.
There are other threads all over the intertubes about reading and supporting code and the funny thing is that very few, if any, talk about lisp. All the lisp ones are about "how I can do this cool shit really fast and it makes me feel oh so powerful". Yeah, whatever. I'm happy you are happy. But what I, as a manager, need is the ability to take your cool shit and ship it and debug it and support it for the next decade or two and do all that when you, the studly lisp hacker, have moved on.
Not really liking the prospect of doing that with a big steaming pile of lisp.
Lisp is the Ron Paul of programming languages.
Why is it that in RAD application competitions, "mainstream" languages often win?
Also, if it were truly n times better the library disparity wouldn't exist; libraries should be n times faster to make or duplicate.
I'm asking for evidence here: how can something be so much better and have such a paucity of evidence for it's efficacy? If there really is such scientific evidence for lisps effectiveness I would love to read it & and distribute it to my colleagues in charge of large development teams.