Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm waiting for more than a few cherry-picked examples of people who talked their boss into letting them use it, and academic papers, to be interested. Clojure start-ups using it as a competitive advantage to make money competing against others trying to solve similar problems would be very very interesting. Some people seem to believe that its constructs for dealing with concurrency have such potential, but on the other hand I can't tell if any of this is real or cult-like hype. (Flame bait: look how excited people were about Haskell a couple of years ago, and to some extent still are.)

My suspicion is that it is as close to a proven fact as you get in technology that real-world business programmers don't want Lisp. Yet it creates unequaled excitement and enthusiasm, as it has for half a century. A whole generation of top programmers trained at places like MIT were trained in Lisp from the very beginning. It had a firm foothold in places like Nasa. Yet how many of these programmers now use Lisp in the industry? I don't think very many, especially relative to the amount of enthusiasm people have for it. Lack of education and exposure and trials has most emphatically not been the issue here. Do the lead engineers at Google let their employees use Lisp? No. Now do all of you know something they don't or is it the other way around? Was Paul Graham's genius (as a programmer who spent his formative years learning BASIC) to use Lisp or was he a brilliant person with an ingenious idea to build a customizable online store in the mid 1990s and could have succeeded in any language? It seems to me that Lisp is so old and has failed to maintain a real foothold in the industry for so long that these questions demand answers. Postulating that maybe there are companies using Lisp in secret doesn't cut it here.

As a side note, one of Paul Graham's famous essays has a bizarre pieces of logic that goes "If Lisp makes you a better programmer, why not use it all the time?" It does not follow. Swinging a weighted bat might make you a better hitter, a ballroom bar might make you a better dancer, training at high altitudes might improve your cardio.

I close with this interesting quote from Tim Sweeney:

"Of course, it's easy to see how this undercurrent arises. When you release a language, you receive complaints from users about all the things they want to do and can't, and the ultimate way to satisfy all of these requests is to expose all metadata: make it extensible, make objects dynamic, and allow the possibility of completely dynamic typing. The end of the road here looks an awful lot like LISP and SmallTalk.

"If you go this route, one day you'll realize you evolved the ultimate hacker language, and it became a godawful mess for writing real programs."



"If you go this route, one day you'll realize you evolved the ultimate hacker language, and it became a godawful mess for writing real programs."

A Stradivarius (a kind of ultimate hacker tool) in the hand of a master can change people lives. A Stradivarius in the hand of a lesser musician will probably still sound pretty good. A master with a second hand violin can still move us. A busted up violin can't be made to sound good.

There's a lot of coders out there with second-hand violins. I wonder what they could do if they all had the Stradivarius. In real life there is physical scarcity, in the world of code the scarcity is a product only of our lack of curiosity and drive.


You'd think experienced engineers would know better than to say language A is categorically better than language B when the one thing real-world programming experience should teach you is that context is everything. Any engineering solution is a careful balance of tradeoffs and language design is no different.

In order to take this conversation in a more adult direction we should ask this: What the advantages and disadvantages of s-expr syntax, a jvm foundation and a pure functional core? What problems are made easier to solve by these features? What problems are made more difficult to solve by these features? What are the key tradeoffs vs the alternatives?

If you're one of those people that think FP is a silver bullet you're a missionary, not an engineer.


It's just a metaphor, take or leave it.


My question is not about art, but about who is using Lisps to make fantastic profit, against competitors trying to solve the same problem, in a way that would not be possible with more mainstream languages. If very few, it's not interesting in the industry. This is a shallow and narrow view but it also has the benefit of being observable and objective.


observable, objective ... and boring. As a software engineer I'm looking for me and my team. Not the industry.


Well, I think this is interesting: http://www.linkedin.com/jobs?viewJob=&jobId=1022663


ITA's product backing the Orbitz system used Lisp heavily. They were just bought by google for a large sum of money. This isn't cherry picking, this is one of many real world examples you've never bothered to research.

Just because you don't pay attention to something doesn't mean it doesn't exist.


Using anecdotes to prove a point is precisely what I mean by cherry picking. I know that Lisp projects can be successful, but is there some systematic way to show that they're in fact more successful? Google and others throw money around at a lot of non-Lisp shops too. Because it's possible to succeed with method B does not mean that there is a reason to switch if what I value is success.

If it makes programming more fun for you, great, but I think even that (if it's systematic for lots of different programmers) should impact the bottom line in some way that I could imagine measuring?

It just seems to me from casual observation that the success of Lisps is disproportionately low (not to be straw-manned into zero) compared to the enthusiasm and the exposure so many programmers have had to it through means like SICP at MIT. This is admittedly unscientific.


> but is there some systematic way to show that they're in fact more successful?

Please define "successful." If "success" is wide use, then you have defined your success in the most un-profound of manners.

> It just seems to me from casual observation that the success of Lisps is disproportionately low (not to be straw-manned into zero)

I'm not going to play this game with you. You've defined nonsensical metrics and then demand we play by them. Any specific examples I give (of which you could easily get for yourself with 5 minutes and a search engine) will be dismissed as "anecdotes" as you move your goalposts.

I do not care what you think, because I do not think you're interested in considering what I have to say. Let's enjoy our mutual indifference.


> Please define "successful."

"Profitable", compared to using another language. There are many objective ways this could be shown that wouldn't be vulnerable to being shot down by a non-falsifiability engine (i.e. any data I don't like is just an anecdote). For example, someone could attempt to sample startups at different time periods and look at financial growth over some timeframe.

Basically I'm looking for a metric that would show that pure functional language choices matter in a positive way. Any metric would fascinate me. Even success in contest problems of some type, when others had a chance to compete on equal footing would be something.


> There are many objective ways this could be shown that wouldn't be vulnerable to being shot down by a non-falsifiability engine (i.e. any data I don't like is just an anecdote). For example, someone could attempt to sample startups at different time periods and look at financial growth over some timeframe.

Can you show these for any other language? In a way that's not arbitrary and self-selecting.

> For example, someone could attempt to sample startups at different time periods and look at financial growth over some timeframe.

Thanks for the laugh.


> Can you show these for any other language? In a way that's not arbitrary and self-selecting.

I suspect you could have sampled Java web startups vs those still using C, Perl and CGI back during the time of Java's explosive growth and seen a systematic difference in profitability.

> Thanks for the laugh.

So any idea that there could be some statistical correlation between language choice and any kind of measured success is, on the face of it, absurd?


I suspect you could have sampled Java web startups vs those still using C, Perl and CGI back during the time of Java's explosive growth and seen a systematic difference in profitability.

Amazon.com has made a lot of money, hasn't it?

So any idea that there could be some statistical correlation between language choice and any kind of measured success is, on the face of it, absurd?

A relevant statistical correlation? Yes.


At this point you are simply being a troll. You are using a classic troll script, i.e. a variant of "You suck. Prove to me that you don't." Are you actually looking to get something out of this conversation?


I take a Devil's Advocate style sometimes where I make a case and then learn by someone shooting me down in a logical manner, and when that happens I change my mind. (And that is one of the great pleasures of life). I am being sincere here. I am confrontational but I do learn things from conversations quite frequently.

I think it isn't explored enough why Lisp, as such, (not to be straw-manned into the many brilliant and pioneering ideas that originated from it), has just not caught on very much. E.g. why does Google, with an army of PhDs, very consciously not let their top engineers use Lisps?

I postulate that, like Tim Sweeney's quote implies, that there really is a great cost (in terms of the problems that industrial programmers face) to the sort of extreme dynamicism that Lisps offer. Now some of the largest of those problems include what a company should do when their lead engineer quits in the middle of a project, managing extreme changing requirements, managing staff writing automated testing and creating documentation, and other things that may not be considered in pure academic study but where language choices and methodologies may make a large difference.


I think it isn't explored enough why Lisp, as such...has just not caught on ...

This has been the #1 troll on any lisp forum for 30 years. It has been explored ad nauseum. If you're being sincere (which I doubt) read Richard Gabriel


Looks like Google is using Lisp (a Scheme dialect, to be precise) as part of their Android App Inventor:

http://appinventor.googlelabs.com/about/


In response to the Sweeney quote, I would call this a call program:

http://www.gemstone.com/pdf/OOCL_SuccessStory.pdf

I know many people who work on 'real programs' written in lisp and smalltalk. Just because usage of the language isn't common doesn't mean you can't write real programs in it.

I've heard plenty of horror stories about how you can write real programs in php yet, people do ( witness facebook ). IMO, you can write real programs in any language- it is just that each make different things easier to do than others.


For me and many others to take interest we need more than "can write", we need a "better" in there, in a way that translates to "more money".


Using Lisp in education generates surprisingly few Lisp programmers. The few are often very good, but they are still few. Using Lisp with SICP teaches quite a bit almost practical computer science, but not so much about writing 'real world' applications. Often students, after taking courses which use Lisp, get the impression that one calculates numbers using church numerals or that everything is done via hairy multiple recursive functions. Learning to reverse a list also does not leave a lasting impression on students.

Then people discover that during learning and experimenting one can create a huge mess using Lisp. There are many degrees of freedom. Additionally via meta-programming one can turn things upside down. That creates not much confidence for some people who like a more straight forward tool that provides one obvious way to do things.

Next one discovers that Lisp comes with its own ideas of deployment and runtimes. Numbers can be fixnums or bignums. Dividing two integers creates a rational number and the sauare root of -1 is not an error, but a complex number. There is an 'image' and it generates garbage that needs to be collected.

Lisp still is unique when seen at in its full incarnation, but for many it is not clear why they need its feature set and why they should live with the consequences its design choices bring.

Lisp is best, when one needs a symbolic language often using interactive tools for exploratory programming. Lisp is also fine, when one needs a programmable language for example offering macros. Once people get to like that, Lisp is a choice for domains where it would not be the first choice, just because these people like the tool.

For many other developers meta-programming, code as data, symbolic representations etc. is sounding more like baggage. Often intellectual baggage, which simply adds more layers to worry about.

But there is also a bunch of people coming to Lisp who used other tools, are fully understanding them and are looking for a new intellectual challenges. Some might go to the more theoretically pleasing languages (like Haskell), but some might be attracted by code as data and simple meta programming.

Thus I don't think Lisp will ever be a wide-spread first choice (because it is slightly too complicated for many users), but it will offer for a long time an alternative view of software development. Often you see people just taking from Lisp what they find useful (functions, macros, code as data, interactive use, ...) and bring those to the tools they use. That often creates the impression that most Lisp features are now available in other languages (like GC, virtual machines, self-hosting compilers, ...) and often in improved forms.

Fortunately Lisp still has areas and tools that are used to write interesting applications - it may just be that some of those applications are not that important for many people. Who cares about scheduling the use of space telescopes? Still planning and scheduling is a domain where Lisp is used and for example the usage of the Hubble Space Telescope is planned with a Lisp system (SPIKE). There we have symbolic representations of plans and a software that can create those. Sounds like a great core domain for using Lisp. Others, may find it fun hacking web sites using Lisp. It is for some a tool that they like to use, often because it fits their style of thinking.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: