"The message you requested is temporarily unavailable because this group has exceeded its download limit. Please try again later." kind of blows my mind. This is yahoo, not some weird server running on a 4.77MHz processor in Turkmenistan.
There is a tone of defeatism here. As Alan Kay said, Smalltalk and Lisp tend to eat their young. Common Lisp is a testament to how great Lisp is but it's no end game. Alan Kay always said he expected people to make something way, way, way better. And yet no one did for such a long time.
Luckily there are some Lisps today that are no longer sitting around twiddling their thumbs.
It's hard to motivate people to work in terrible old languages that won't contribute to their market value in the future. But I can believe that people make exceptions for languages that they love and wish weren't dead.
Subject: Re: [feyerabend-project] An introduction to Lisp
From: "Richard P. Gabriel"
Date: Tue Aug 27, 2002 1:03 pm
At 22:23 +0200 8/25/02, Dirk Riehle wrote:
>Choosing CLOS or the like:
>
>- you don't get enough people
>- those people you get cost too much
>- you are incompatible with the rest of the world
>- adapters and bug-fixes will always be last for you
Though it's not relevant, I would argue like this:
My team will be able to program circles around everyone else. They will be able to construct rapidly a language specific to the problem we are solving rather than using a language designed by computer scientists worrying about their place in history and a herd of library writers working in cubicles a thousand miles from our business. My team will be able to use a language without training wheels. Strong typing is for weak minds, and it's exactly like they say at MIT: Our current popular languages are designed to help losers lose less.
I will be able to point to various examples where Lisp programmers have written not only 3-5 times faster, but they wrote things other programmers thought were impossible. In this regard, I'd tell the CEO, our competitors will be spending all their time trying to figure out that it's really possible we're doing what we're doing, because they will be thinking in terms of customization at compile time or link time, not at runtime.
Moreover, we will be operating where the CEO is focusing on his or her specialty and not imposing his or her knuckleheaded view on technology.
Because Lisp is dead, I'll get better programmers for less money. I'll be able to guarantee 50 more IQ points for the same pay. And my guys will be able to spend their time typing in value not book keeping overhead and typing in type descriptions because their guys are too stupid to know when they type + numbers are involved.
Because no one uses Lisp, I'll have my pick of thousands of great, experienced programmers looking to work for someone with a non-zero IQ, not the ones fresh out of college with 10 programs under their belts.
I'll be compatible with everything because it is right now. And if someone throws me a bug, I can code around it in a few minutes. Being a niche market means we're more proprietary. People will not use Lisp to compete with us because they are lamebrains listening to the latest fashion statement from Sun or Microsoft.The open source crowd isn't even smart enough to notice C++, so they are especially nowhere in the picture.
Of course, no CEO will belive this because every one of them is stupid.
When I first read the comments here, I imagined Gabriel knocking his head on the wall, Charlie Brown-style. But the more I think about it, the more I think he might appreciate the layers of absurdity.
That post is hilariously arrogant and off-the-mark. "Strong typing is for weak minds?" Really? I suppose this guy compiles his code by hand too. I would go out of my way not to work with someone so cocky.
Here's a tip I often use for myself. When my argument relies upon "everyone being stupid". I really should take a second look at my argument.
And I agree, working with someone so cocky is a bad idea. Because if you ever do follow his advice (against your better judgment) and the projects fails (as it likely will), it won't be because of his idea, but its because you were stupid too.
I don't think that strong typing is bad, but I would like to point out that from his point of view, arguments FOR strong typing are based on the premise that "everyone is stupid."
Orthogonally, you don't have assume that everyone is stupid for it to be a good idea to design things as though everyone is stupid, because the fractional slice of attention and working memory that the user can easily spare is effectively a moron. This argument applies easy to issues of usability, but for programming, it may equate to driving a car with blinders on. I don't really know.
From my point of view, the main arguments for strong typing are that everyone makes mistakes, and that your tests might not be as complete as you would like (due to time pressure, or whatever else).
We're all losers. Even the best programmers in the world have difficulty writing bug-free code. Whatever tools we can leverage to make us lose less should be welcomed with open arms.
I consider myself a fairly strong programmer. I have worked with literally hundreds of programmers over my career. None have been better than me. Now I'm not the smartest person on the planet, I'm not even smarter than say Sheldon Cooper, but despite the article author's assertion, you cannot hire someone who has an IQ 50 points higher than mine.
All that said, I've recently done a couple of months of programming (in a very restrictive environment) in Javascript, and I yearn for a compiler.
Perhaps these tools do help "losers lose less"... but a tool is a force multiplier (bad tools are multipliers with a value less than one, and truly bad tools have negative multipliers :D Not all tools are bad.)
In the hands of an expert, the right tool can become a powerful weapon.
"I have worked with literally hundreds of programmers over my career. None have been better than me."
Really? In every aspect of programming? In every language? This is the typical prima donna bullshit that pervades this industry. I pity anyone who has to deal with you on a daily basis.
A negative-multiplier tool would allow you to apply negative force to get a positive result. So if you hire a bunch of those guys who make the code worse every time they touch it, and give them a negative-multiplier tool, then they'll make forward progress. And you can pay them almost nothing! You can hire day laborers who would otherwise be picking cabbage!
It is, in itself. His point is that if you're not a loser, then it's not particularly relevant to you. If you're a winner you'd presumably prefer to use a language intended to help winners win.
First you have to define what "popular" means. Do you only allow, say, C# and Java? I use Scala quite a lot. It has a vibrant community, increasing popularity, and it sure doesn't hold back on the advanced features.
Hey both states the advantages and implies the disadvantages of working with Lisp. Advantages: dynamic typing, macros ("customization at compile time or link time, not at runtime.") dealing with bugs, etc. He really knows his shit, too, especially with regards to how Lisp compiles. So the good news is, he's right.
But that's the bad news, too. He's right, but not tactful.
This that holds Lisp back in a business setting: the tech is awesome, the people skills aren't. Entrepreneurs considering doing a Lisp startup would be wise to address this as part of your strategy.
That dynamic typing and Lisp-style macros are advantages is highly debatable. Most programmers I've worked with (some of whom are probably in the top 1% of coders in the world, these include the guys who developed PLT Scheme) would in fact consider both those features to be disadvantages.
Example counterarguments:
Static typing is far better than dynamic typing. There is nothing you can express in a dynamically typed language which you cannot express in a statically typed language, and most of those things can be expressed just as succinctly thanks to type inference. Further, to use your own words, static typing provides debugging "at compile time or link time, not at runtime."
Hygienic macros (i.e., macros which gracefully handle identifier collisions) provide all the same "language-building" features of Lisp-style macros without mysterious bugs caused by namespace clashes. Furthermore, the "customization" use case you point out is far better served by either higher-order modules (a.k.a. functors), which enforce provides-requires relationships at compile time; and by compile-time inlining of static code (also known as partial compilation), thus allowing the same language to be used for compile-time and run-time code.
I'm going to agree with you about dynamic typing. I spend most of my time programming in dynamic languages, but I spend a lot of that time pretending I have static types. I waste a lot of CPU cycles making up for the safety difference between static and dynamic typing. Then I waste even more to be able to store "hello world" and 42 in the same variable, even though I never need to do this.
Fortunately, if I care about CPU time, I just use Haskell, which gives me the syntactic sugar and expressiveness of Lisp with the type safety of ... well ... Haskell.
The question isn't whether you want static types while running or debugging (or testing). The question is whether you want static types while developing.
>Static typing is far better than dynamic typing. There is nothing you can express in a dynamically typed language which you cannot express in a statically typed language, and most of those things can be expressed just as succinctly thanks to type inference. Further, to use your own words, static typing provides debugging "at compile time or link time, not at runtime."
Most things require little change but when you need to add a method to a class, static typing starts to get in the way. Node.js express framework could not have been made in a static language nor could rails find_by_* method system.
Loop is a fucking mess and, in Common Lisp, is not strictly implemented. But while I wouldn't recommend it to anybody, for any given implementation (clisp, say), yes, you can.
Well most of the arguments are the same, Richard Gabriel is just less tactful than pg.
What I want to know is whether Richard P. Gabriel ever had business success with LISP rather than just academic success. A quick scan of wikipedia doesn't mention any modern businesses.
He raised by my count over 4 million dollars back in the 80s (back when that was real money), and the company lasted 10 years. If that isn't getting a business "off the ground", I think your criteria is far too harsh!
But (if I understand the timeline) by the time he wrote that, the prior business had been dead and buried for 7 or 8 years. Reading between the lines, I think they attached themselves to a platform that looked good (symbolics) at the time, but which failed to capitalise on it's potential. Essentially they were in the accessories aftermarket... and if that market disappears you'll go down with it.
Lucid was the disruptive competitor to Symbolics: rather than building expensive hardware to run Lisp fast, they built expensive software to make mainstream hardware (e.g. SPARCs) run Lisp fast. AFAIK they never had a product that ran on LispMs.
