For the record parent is the only non-stupid post in this entire thread.
If I really wanted to read arguments about why Lisp sucks from people who don't program in Lisp, and complaining about issues that have been solved half a dozen years ago from people who can't be bothered to check a web page, I'd go read comp.lang.lisp archives.
The rest of you can go back to trolling about how Lisp sucks and Clojure will solve all its problems even though you've never used Lisp and have no plans to ever use Clojure.
Yeah, if only Microsoft had promoted Lisp the way they had Xenix, or the Zune, then _everybody_ would be using Lisp! Or if Sun had picked up the cause, then Lisp would be used in all those set-top boxes the way Java is today. Oh, wait...
Microsoft actually did have a diversity approach for their language tools division in the 1980s -- ever heard of MuLISP? The problem was that Lisp on MS-DOS or Windows 3 was not really a good fit for most (any?) personal computer at that time. Certainly not when compared with the likes of Turbo Pascal, say.
It seems to me that programming languages get their moment in the sun if they offer some significant technical advantage for that particular time and market. Perl took off because it did seem better for some things at the time, for example, while the latest versions have seemed (to me, at least) as a desperate cry for attention when other dynamic languages have gotten most of the programmer love.
If there's anything the last dozen years of language adoption have shown us, it is that "promotion" is only part of the equation and it can manifest in either a top-down or bottom-up fashion. (See Python or Ruby for examples of the latter.)
Not trying to sound hostile here, but your comparisons seem a little disingenuous. You're equating Lisp with an ancient operating system and a music player? Lisp is a programming language. Microsoft has other products in the category of programming languages. The ones it has pushed — Visual Basic, C# and (to a lesser degree, since it's NIH) C++ — have all been tremendously successful. This is because Microsoft has a monopoly on Windows dev tools and APIs that it can exploit to get developers using things. This monopoly is less useful for pushing Zunes.
And to try and argue that Java is unsuccessful because it isn't used in set-top boxes? I don't even know what to say to that. The fact that Java's successes were in other domains than the one you hand-picked for your comparison does not somehow make them disappear. You may as well say that C was never very popular because no Ruby on Rails apps were ever written in it.
The fact is that Lisp has not had any major backers since the AI craze fizzled out. If a Lisp had received the same kind of support as Java, C#, Objective-C or JavaScript, the language landscape might very well look quite different.
Well, I'm willing to entertain data that contradicts my thesis, but I'm unconvinced by either attacking my motives or distorting what I wrote.
My point with the Microsoft language products of the 1980s was that they were willing to sell a variety of products if people were willing to buy them. They had Microsoft versions of Fortran, C, and Pascal as well. Xenix was their server solution back then, but that didn't really matter for that state of the market. The mention of the Zune was intended to highlight that the technical merits are dwarfed by right-place-and-time effects. I knew plenty of people who thought J++ was the wave of the future because, you know, that API lock-in is such a determinant for success.
As to Java, I never said that it was unsuccessful. But Sun kept trying to flog Java as an embedded systems solution and it was an exercise in futility, whether it was the original set-top boxes, JINI, or those incredibly useful Java personalization ID rings like the one I have somewhere in a desk drawer. Having a major player pitch still didn't make it popular in embedded markets.
Woulda-coulda-shoulda arguments about Lisp only lacking major backers are arguments based on a lack of data. If major backers are so key, then why were Python and Ruby so successful?
Jini is a set of distributed system building tools, it had nothing to do with embedded systems. For what it's worth the core ideas of Jini are actually really great and robust, the problem is that it's not J2EE. No one wants to rewrite their shit for Jini, they'd rather try to throw the mess at things like Terracotta or bigger servers (for what it's worth, I've never seen a Java application that wasn't a piece of shit, so I can't really blame anyone).
There was some research into applying the services model to mobile and wireless systems, which makes a lot of sense, but it was research as neither the market nor the underlying routing technology has yet to emerge.
Also, Java has been immensely successful in smart cards and cellphones. You are seriously wrong about Java not being used in embedded systems.
Jini has nothing to do with embedded systems? Really? Well, de facto, sure. But how did Sun originally pitch it? Let's do a little search and, oh, here's Bill Venners talking about the same topic in 2006: <http://www.artima.com/weblogs/viewpost.jsp?thread=150666>..., the Summary starts with "Sun's original marketing message that positioned Jini as a technology for devices backfired in 1999..."
Perhaps we have different notions of embedded systems. I'm thinking of self-contained computers/microcontrollers that are part of a larger system/product with a significant incentive to keep hardware costs to a minimum. As in, use the cheapest processor and least amount of RAM as you can. Now that covers a large range, from 8-bit microcontrollers to high-end systems running real time OSs. The last time I was seriously following that field, however, the hands down favorite language was C. I would be greatly surprised if Java had even risen in usage to rival Forth in the embedded domain. If you have some contrasting data to provide, feel free.
I'll give you partial credit for thinking of J2ME in mobile phones. But there's still a significant difference between programming games in J2ME or Flash for a phone and using Jave to program the phones themselves (ie, the underlying embedded system). Why do you think Nokia's recommendation for application builds was either gcc or, for those building their own phone ROMs, the proprietary ARM compiler?
"Jini has nothing to do with embedded systems? Really? Well, de facto, sure. But how did Sun originally pitch it? Let's do a little search and, oh, here's Bill Venners talking about the same topic in 2006: <http://www.artima.com/weblogs/viewpost.jsp?thread=150666>..., the Summary starts with "Sun's original marketing message that positioned Jini as a technology for devices backfired in 1999...""
That link is giving me a Java stack trace, but let's put the quote in context from people who actually worked on promoting Jini:
"Probably the biggest misconception is that it is concerned primarily with devices. This was, unfortunately, the original marketing message used for Jini technology, so this misconception is to a large extent our own fault. It was one of those cases where an illustration of what Jini technology could do -- attach a device and it's found and used, detach the device and it disappears -- was mistakenly thought of as all that the technology could do."
"For an example of the power of a good story, consider the one developed for the Jini project. As described earlier, Jini technology is a thin layer built on top of Java that allows applications to be written as remote services that can be dynamically deployed and located over a network. The obvious story is that Jini is another middleware framework for distributed applications. But this story has a technology focus that would have severely limited the spread of the Jini message--indeed the term middleware causes even developers to yawn. Instead, the Jini marketing team built a story around what Jini technology would mean to users; that story generated lots of excitement in developers, the press, and the marketplace."
I don't see how that's a message pitching it as an embedded systems solution. Something like network plug and play/Apple Bojour, sure.
"I'll give you partial credit for thinking of J2ME in mobile phones. But there's still a significant difference between programming games in J2ME or Flash for a phone and using Jave to program the phones themselves (ie, the underlying embedded system). Why do you think Nokia's recommendation for application builds was either gcc or, for those building their own phone ROMs, the proprietary ARM compiler?"
Thank you for completely ignoring my mention of smart cards. That's about as embedded as it gets, and Java Card is one of the leading technologies there.
The Nokia example is horrible. Symbian is dead despite having the largest market share - most apps running on Symbian are J2ME. The iPhone might be a better counter-example. But then you have Android, which is a de-facto JVM.
So you have the two biggest categories of consumer devices, cellphones and smart cards, and J2ME runs on over 80% of the former, and I don't know how many smart cards use Java Card, but it seems to be a very significant percentage.
Saying Java hasn't been successful in embedded systems is completely false.
OK, I'll grant you the smart card example. I have no experience with those guy; there are what, a half-dozen vendors? For obvious reasons they don't talk about the details of their software much.
The nub of our disagreement: the definition of an embedded system. Per Wikipedia, "An embedded system is a computer system designed to perform one or a few dedicated functions often with real-time computing constraints."
So a cheap MP3 player counts as an embedded system, because playing audio is what its hardware and software is designed for. A personal computer, in whatever physical form, that runs a variety of applications, including audio players, is not an embedded system. And therefore, no, I don't count smart phone applications as embedded systems software. If you're writing device drivers that are burned into a smart phone's ROM, on the other hand, then I'd consider it embedded software.
When you find hardware running Android that's designed to be dedicated to a single task, such as, say, a climate control system, then you can count it as an embedded system. A tablet PC or an application running on it that sends commands to your existing climate control system, not so much.
Would we really be having this conversation if Sun or Microsoft had promoted Lisp?