"None of those languages give you the raw performance or low-level memory control of C++"
Really? That's funny, because entire OSes have been written in Lisp, and I am pretty sure that those systems needed low-level memory control. In fact, the Lisp compiler I use in my own work has support for low-level pointer operations and a form of inline assembly (which in the past was used to implement SSE intrinsics as an add-on library). I am not sure where people got this idea that all high-level languages were slow or robbed programmers of the ability to do low-level things.
"why none of them are used to write things like Chrome, Firefox, Ableton Live, Photoshop, AutoCad, the JVM etc."
I suspect that has more to do with the OSes that were targeted and the availability of C/C++ programmers who are familiar with programming for those OSes than with some hypothetical performance advantage of C or C++.
Which is more likely, billions of engineering dollars are being dumped into projects by people that just don't know any better or there are real, practical reasons why languages like Lisp and Java aren't suitable for these kinds of apps? I remember interviewing with ITA software when they were still tiny and was shocked to learn that even they had to write some of their software in C++ because Lisp didn't give them the speed or the control they needed.
Extraordinary claims require extraordinary proof and the onus is on Lisp advocates to explain why there are so few real-world Lisp success stories. Calling everybody else stupid isn't good enough.
"Extraordinary claims require extraordinary proof and the onus is on Lisp advocates to explain why there are so few real-world Lisp success stories. Calling everybody else stupid isn't good enough."
You seem to be suggesting that some technical shortcoming of Lisp held it back in the real world, while C and C++ had technical advantages that led to their success. I think the history of Lisp and the history of C tell a much different story.
While C was becoming the language of choice for OSes that ran on low-end computers (especially Unix), Lisp was confined to very expensive computers that were being targeted at a market that ultimately failed to materialize. C became popular by riding on the coattails of Unix, not because it is a great language or because it could compete with other languages on technical features, and C++ road on the coattails of C (maintaining some amount of compatibility etc.). Lisp, meanwhile, was held back by bad business decisions; no amount of technical superiority could have saved Lisp from the AI winter. By the time you could really talk about Lisp running on PCs or cheap hardware, it was too late: C was already widely used and there was already an enormous volume of C code that people were working with.
It is interesting that you mention ITA's use of C++. The big reason for that was the poor scalability of CMUCL's garbage collector, which they did not use at all, opting instead for memory-mapped arrays (hence C++, which was used to handle system calls and deal with pointers). Had ITA been developing for an OS written in Lisp (not unprecedented), C++ would never have entered the picture; but ITA was developing for an OS that exposed a C API and a C ABI, and using C or C++ to deal with system calls simply made the most sense. I suspect that if they were to try again today, they would use far less C++, if any; today's Lisp compilers come with (non-portable) extensions for POSIX system calls and for dealing with pointers, as well as disabling the garbage collector globally or on specific objects. It is not that Lisp itself was slow; just a specific feature of the Lisp systems they were using, and poor support for disabling or avoiding the use of that feature.
So which is more likely: that C and C++ are the best languages ever developed for the kinds of programs they are used for, or that they were just in the right place at the right time?
So which is more likely: that C and C++ are the best languages ever developed for the kinds of programs they are used for, or that they were just in the right place at the right time?
Or, they're better than any alternative for certain domains and the people that choose C++ know about Lisp, Haskell, Scala, Ocaml etc and still decide to use it despite its shortcomings?
It's a simple question - if Lisp really is superior for these kinds of apps then why isn't there some small, nimble team out there kicking ass with it?
HN is interesting because of the community and Y combinator's backing. The software behind it is laughably crude compared to other web forums. It could easily be replicated in any number of other languages, with better results. Maybe we'd even see the last of those "link expired" errors?
Surely you know the history to which the previous poster is referring? YC exists because pg and others build a company in Lisp and sold it for millions. They were a small team so they chose Lisp exactly because it helped them stay nimble.
They chose Lisp because they were comfortable with it - nimble is a social trait, not a language feature.
It's not like Lisp automatically makes everything successful - the market-trailing HN performance and UI iteration times are a strong argument that technical factors frequently do not determine success.
Lisp's problem has not been a lack of visibility, as a web full of smug Lisp advocates demonstrates. I've personally been hearing about how amazing it is, how everyone writing Lisp will be incredibly productive for at least 15 years — during which absolutely nothing of significance written in Lisp has shipped even while some ideas developed or popularized in Lisp have spread to many popular languages.
Almost every single time this has come up, someone has cited drawbacks: lack of a standard high-quality implementation, limited libraries and, somewhat less universally, highly idiosyncratic coding styles hurting interoperability.
This generally gets a mix of dismissal or vague promises that it'll get better real soon now. Meanwhile, the only claim Lisp has on mainstream status in 2013 runs on the JVM so it has credible tools, performance and libraries. I would argue that this is neither coincidental nor caused by lack of unidirectional advocacy.
There have been significant products shipped using Lisp. For instance, the original Reddit, ITA, Viaweb (the startup Paul Graham sold to Yahoo), Hacker News itself.
But it's true, many Lisps suffer the problem of fragmentation.
> There have been significant products shipped using Lisp. For instance, the original Reddit, ITA, Viaweb (the startup Paul Graham sold to Yahoo), Hacker News itself.
The aspect I was really thinking about was developer mindshare: there are a few sites which did use Lisp but it never seemed to develop an foundation which many other people would consider building a project on top of. From the mid-90s onward I don't recall anyone talking about learning Lisp so they could build a website; it was always a case of not wanting to learn something new or some sort of CS machismo ranking languages without concern for mere engineering tradeoffs.
The JVM is not as fast as C or C++ - there is no end of real-world data and benchmarks to validate this claim. It wins in microbenchmarks where the it's allowed to dynamically inline things and otherwise take advantage of just-in-time compilation (which, of course, kills startup time), and it's certainly fast enough for many applications, but in general it does not match the performance of C.
I don't know anything about your work Lisp compiler, but making code written in a dynamically typed language run as fast as code written in a statically typed language - outside of microbenchmarks - generally requires making a lot of assumptions about that code.
"I don't know anything about your work Lisp compiler, but making code written in a dynamically typed language run as fast as code written in a statically typed language - outside of microbenchmarks - generally requires making a lot of assumptions about that code."
Lisp supports a system of type "hints" to deal with that issue; with SBCL, those hints can be treated as assertions or can be assumed true, depending on compiler options (the "safety level"). A common suggestion for optimizing Lisp code is to use type hints, and the difference is usually pretty significant. You even get some amount of static type checking from this, in the form of warnings about declared types not matching inferred types. It's not as powerful as the ML type system, but it usually gives you what you need in terms of optimizing code.
Really? That's funny, because entire OSes have been written in Lisp, and I am pretty sure that those systems needed low-level memory control. In fact, the Lisp compiler I use in my own work has support for low-level pointer operations and a form of inline assembly (which in the past was used to implement SSE intrinsics as an add-on library). I am not sure where people got this idea that all high-level languages were slow or robbed programmers of the ability to do low-level things.
"why none of them are used to write things like Chrome, Firefox, Ableton Live, Photoshop, AutoCad, the JVM etc."
I suspect that has more to do with the OSes that were targeted and the availability of C/C++ programmers who are familiar with programming for those OSes than with some hypothetical performance advantage of C or C++.