com.lang.lisp isn't "the Lisp community". There may be reasons to suspect "Lisp will never win", but comp.lang.lisp has nothing to do with them.
Personally, I don't even know what it means for a language to 'win'. I would be fine with Lisp/Scheme being marginally popular and acceptable when you're in the company of clever colleagues that could reasonably be expected to grok Lisp after a short while. Nevertheless it isn't. The reasons why that is currently the case would go a longer way towards explaining why that may never be the case.
It is "the Lisp community" in the sense that there is no other widely known, recommended way to get in touch with people using Lisp. The community may exist somwhere else, but they are hidden from newbies, whose first contact with the community still is the cesspit that is c.l.l, often by the spam ridden Google Groups interface.
I really don't think many newbies have even heard of usenet, these days, let alone are all that likely to turn to comp.lang.lisp for help.
A college kid looking for assistance with lisp these days is likely to hit up StackOverflow or /r/lisp or /r/scheme or one of the clojure communities depending on what they're using. Any of these are less 'hidden' than usenet, which happily has fallen into enough obscurity that c.l.l.'s toxicity will slowly die for lack of new blood.
I think the general attitude of lispers is frequently a large turn off. There is a lot of elitism, but it is often a needy Mensa-like elitism. There is almost a hidden plea attached "please respect us as the smartest" and the problem is, of course, that they can't point to any tangible, quantifiable method for gauging intelligence with respect to a language. I guess PG's "let's see if anyone is using it in 50 years" is a good measure in some case, but that implies that lisp as a language is less of a "computer language" (e.g. a language that is made for making machines do what we humans want them to) and more of an artform or philosophical/mathematical depiction of some deeper truth obscured to normal people.
I think this is ultimately always a problem between ultra-smart people who live in something of an abstracted world that frequently approaches fantasy and the reality of industry, which generally doesn't care about how pretty something is unless someone will buy it because it is pretty. That's a pretty large gap, and, while in my opinion there is no need for arrogance, it is pretty clear why most of the smartest people in history end up on the former side of that divide. They want to contemplate some sort of eternal idea which usually they ascribe beauty to (e.g. Bohr, Einstein, etc.) -- and yet hackers, unlike theoretical physicists, are halfway between the people probing the mysteries of the universe and those putting together blueprints for the atom bomb.
In my opinion that's just life. Einstein hated the bomb and rightly so in my opinion -- but that doesn't mean that it was any less a necessity for the Manhattan project to go forward. The sad thing, however, is that lots of brilliant people trying to navigate this divide end up with a huge chip on their shoulder. PG talks about this in H&P; the jocks were popular and (surprise!) the nerds were not. So you go out and get a few million and say, "ha, screw the jocks." Fine, generally speaking I think that is a good idea, but let's not turn it into a wanker fest since there are lots of needed functions in the world that should probably be performed by those who can't understand Lisp -- and I don't just mean cleaning toilets, I mean politics.
Abstraction, which is really what lisp is about in many ways, is only ever IMO one pole. You have to zoom out to see the bigger picture and zoom in to address the minutia. Generally people miss the forest for the trees, so I have every sympathy for those who stick with the forest and ignore the trees. But when it comes down to it, someone has to re-write your code in blub to make a functional product (even true with Viaweb) so have some sympathy for the little man who has to do a sh't job, probably his mother never gave him fairy tales to read and he only vaguely knows who Godel, Escher, and Bach are. That's sad, but that's life and we who are Americans should especially expect it as an immigrant nation.
Anyways, I'm one who discovered Lisp rather late despite and not because of the Lisp community as it is usually presented. I think it is beautiful and esp. I think SICP is a fantastic book to introduce one to computer science concepts and I think that industry should serve great passions and ideas and not vice versa. Hell, I even think lisp machines are a great idea and hope someone builds new ones and they take over the world. But despite all of that, I would never hang out with "the Lisp community."
Why? I want to build great products. Great products need to scale. If you want to go to the moon you need a f'ing spaceship and not emacs and an open source notebook. Spaceships are big. They take a lot of people to run, and they have to be smart people. One mistake and you are smithereens at Cape Canaveral.
The thing that irks me the most about all of this whining is that America used to be capable of building automobiles and space shuttles and (omg!) computers. It was amazing. Now it is hello Taiwan, goodbye America. People talk about "Rework" and how they can't imagine being in a company with more than ten p...
> If you want to go to the moon you need a f'ing spaceship and not emacs and an open source notebook. Spaceships are big. They take a lot of people to run, and they have to be smart people. One mistake and you are smithereens at Cape Canaveral.
That site indicates they're attempting to launch a human on a suborbital trajectory. What does that have to do with either orbital flight or going to the moon?
If you can get to space, even a suborbital flight, you must have gotten most of the life support right. If you reach orbit, you got your rocket right. If you can change orbits, you got manevering right. If you can stay a week in space, the rest of your life support is OK. All you need now is a second booster to launch you to the Moon. You can either circle it in a free return trajectory, or brake an enter orbit.
Every single system you name is made up of a large number of complex sub-systems designed and built to exacting requirements, and any one of them can still break at any time. Thinking you "got it right" just because it didn't break one time in one set of circumstances is unbelievably naïve. There's a reason all man-rated launch systems have redundant backup systems, and even the fallbacks don't always work right.
By the way, let me know when you get micrometeoroid shielding "right" -- every space agency on Earth will want to talk to you. You might even win a Nobel Prize.
You're also completely ignoring navigation. Just because you can fire up a rocket doesn't mean shit if you're at the wrong point in your orbit, or pointed in the wrong direction.
You're also failing to distinguish between "I can get THIS rocket into orbit" and "I can get a rocket big enough to carry people and a useful payload into orbit and/or to the moon". Think you can just "scale up"? You're wrong. Effects that were too small to measure before will suddenly kill you. Materials that could handle the strain of the smaller rocket will crumble under the increased forces.
Oh, by the way, every time the weight or configuration of your spacecraft changes, you're gonna have to rework your navigation assumptions.
Might I suggest playing with Orbiter for a while? Once you've done that, spend a few minutes thinking about the fact that you've just been overwhelmed by a vastly simplified simulation in which nothing ever goes wrong. Now picture the real world.
Oh, by the way, your heat shield is cracked, but nobody noticed because your budget didn't allow for more than one guy to inspect it, and he was too drunk. Have fun getting home.
The original point is that, once you achieve LEO, a free-return tragectory to the moon is just a question of delta-v. And not that much - the Soyuz-based moon roundtrip being offered for US$ 100M is a Soyuz docked with a mini-bus-sized booster stage.
Micrometeorites? Did Apollo have that? I am not implying it's easy - I'm implying LEO is the hardest part when it comes to a moon-orbit trip.
And in the case of an unmanned craft, it's easier: you don't have to bother with life support, atmospheric braking and most of the radiation shielding.
Except that wasn't the original point at all. It started with Jd saying:
"If you want to go to the moon you need a f'ing spaceship and not emacs and an open source notebook. Spaceships are big. They take a lot of people to run, and they have to be smart people. One mistake and you are smithereens at Cape Canaveral."
Followed by sedachv saying some guys who are trying to launch humans on suborbital flights would disagree.
Nothing you've said explains what suborbital flights have to do with going to the moon. On the contrary, you seem to be admitting they have nothing to do with going to the moon, so I still have absolutely no idea what sedachv's point was.
Well... I maintain that the hardest part of going to the Moon is achieving Earth orbit. The rest is, comparatively, easy.
But, then, this discussion is completely unrelated to the point regarding emacs and an open source notebook (whatever that is). In general, Jd's rant felt confusing. I am not sure how Lisp and spacecraft are related, BTW. He (or she) implied somehow that you couldn't go to space with something simple and elegant like Lisp, but I can't be sure.
I'll make the relation very clear. There is a segment of the Lisp community, which most certainly includes Paul Graham, that maintains that projects with large team sizes are bad. There is a certain logic here, as it is hard to maintain a high average intelligence distributed across a large number of people. Most true geniuses were loners. Regardless, projects of a certain scope (i.e. building a space shuttle) require large teams. You simply can't do it with two guys in a basement.
In a certain sense the computer language employed is irrelevant, except that the lisp community has never, largely because of the facts that should be obvious but are apparently not to the introverted "genius" types they pray on, produced good and extensive enough libraries to be viable for most real world tasks. In case you didn't notice, for example, it took what, 4 years for Hacker News to get HTTPS support.
I don't want to rib anyone too badly, because I am a strong supporter of what YCombinator is doing in general and in the incorporation of lambdas and closures in newer languages, but I think generally speaking it is clear that the Lisp culture is not to cooperate but to position one's self as some sort of genius and thus to create one's own dialect, etc.
I'll give you an example that will probably irritate some people, but is relevant here. Microsoft Word is, in my opinion, one of the greatest architectural marvels of modern civilization. The feature set of that single app is truly extraordinary, and there are all sorts of wonky ways that you can do lots of tasks that makes millions (and potentially even billions) of people's lives better every day. I understand that there is a point to OpenOffice and "fighting the man" and whatever since Microsoft certainly crushed some competitors in mean ways, but realistically there is nothing in the world that competes.
Now you might say, oh sure but I can just use vim and use latex for formatting (or even google docs). And in a certain sense you might be right too, but sooner or later you will find a feature that is not accessible to you (I recently noticed that change tracking still absolutely blows in Google Docs compared to Word).
Why do I bring this up? Well, even if you are right that "the hardest part of going to the Moon is achieving Earth orbit," you still have to have all of those other things. You need life support or you dead; this is non-negotiable, just in the way that mail merge is not negotiable for millions of people at millions of office worldwide. And if you want life support (or mail merge), you need to work with the people who design these other systems.
By the way, I'm not saying you need to like any of this. I'm simply saying that if you want to build something great, you have to at times slog through the mud. My experience with Lispers is they are frequently afraid to get their hands dirty. And that doesn't cut it except in a pretty-ditty fantasy castle.
> Regardless, projects of a certain scope (i.e. building a space shuttle) require large teams.
The shuttles are not engineering successes. Most large projects (large as in "lots of brains required to think about how they are going to work") usually aren't either. I'll side with pg on this. Humans cannot organize that well and less ambitious steps are a better approach to solve really big problems.
Languages are tools you use to express and think about problems. There are problems that are more amenable to be expressed in terms of Lisp and others that are more suited for C. Or SQL, or Forth.
It may be hard to express mud in Lisp, but I don't think the whole thing is as bad as you do.
But I have to wonder... Does anyone still use mail merge?
What are the shuttles if not engineering successes? PR stunts? How would you categorize them? There are certainly problems (like providing a good and functional high-speed rail system) that are not really questions of "genius" and more practical questions of how to apply already developed technology, which, given the politics of our day, might require a different type of "genius" to approach.
It is interesting that you describe language as a tool to think about a problem. Is it really so? Is it only because you have the language that you think about the problem in terms of the language?
Humans cannot organize that well? Well, I guess Cape Canaveral in 1969 was smoke and mirrors -- or what do you mean? I think you probably mean that the cost of organizing at a large scale like that is not a cost you are personally (or, collectively in terms of the culture of elites in the West) willing to bear. I would even suggest that it very well could be in actuality an unwillingness to bear any sacrifice for the sake of a collective goal.
"Less ambitious steps" for "really big problems." Sounds great. What steps do you mean and what problems are you possibly hoping to solve? How the private sector might be able to get someone in space -- an "engineering success" that was already accomplished approximately 50 years ago, now potentially finally accomplished by the private sector, so long as individual Russian tycoons are able to pay for $100M tickets with money stolen from starving peasants.
A brave new world indeed. As for mail merge, I have very little interest in the common man. I live in Silicon valley and watch the world burn from a carefully-cultivated distance.
When you say that you would never hang out with "the Lisp community" because you want to build great products, I take that as an implication that the language, the community, or both, are incompatible with building great products.
That attitude, to me, is a large turn-off.
I disagree with your notion that Lisp code has to be re-written into another language to address the minutia. I address minutia in Scheme a lot.
"The only thing more amazing than the degree to which the author missed the point of the exercise here is the degree to which he seems unaware that he missed the point of the exercise."
No, what was amazing was how stupid the exercise was. The Common Lisp example was a perfectly reasonable translation of the AWK script, accounting for the fact that Common Lisp is a general purpose programming language that doesn't have the luxury of dedicating syntax to text-munging the way AWK does.
Also, the whole concept of Lisp "winning" is silly. Common Lisp isn't making a comeback. Nobody thinks that. But every day that passes, languages get more like Lisp. Take, e.g., Xtend. We've got:
I think you yourself have missed the point when you say, "Common Lisp is a general purpose programming language that doesn't have the luxury of dedicating syntax to text-munging the way AWK does". The whole idea was to make a dialect that did have that luxury as a gateway to Common Lisp.
The exercise was 'wouldn't it be neat if there was a lisp-based facility for doing things like this awk one-liner, since it might get people into using lisp' not 'translate this awk into CL'. Your response is almost identical to the one parodied in the slide.
So you thought the version written in a language you're familiar with was more readable than the version written in a language you're not familiar with?
But seriously, take a look at the two examples again. Are you really suggesting that the Lisp version is easier?
All you have to understand for the Awk example how field variables work, then you can read the whole thing at a glance. The Lisp version contains custom macros and is four lines long!
For someone who doesn't know either, but is familiar with programming generally, which is more readable?
I can guess what 'with-lines-from-file' does, I can guess what 'string-split' does, i can guess what 'string=' does, etc. The only thing I might not understand is 'aref'.
With the AWK example, I have no place to start. Symbol-oriented languages, rather than word-oriented languages, are like that. They tend to be more concise for things very specialized tasks, like this, but that limits their generality. Show me a matrix multiplication routine in AWK versus Common Lisp.
I think you're agonizingly close to the point the author is quoting Peter da Silva as trying to make in your last paragraph here. Roughly sketched -
1) text and file processing are very common tasks
2) Lisp is not especially suited at these tasks, though it is very well suited for some other tasks.
3) If a dialect of lisp more suited to these very common tasks were made, it would increase the popularity of Common Lisp for the tasks that it works well for by familiarizing people with it.
It is both strictly correct and irrelevant to the topic at hand that the Lisp is easier to read. Because that's like saying "Lisp sucks because WTF does 'cddadr' mean anyway?"
AWK is a purpose-built language for splitting lines into fields and doing stuff with the result, so of course there's not a lot of boilerplate for splitting lines into fields and doing stuff with the results.
Lisp for doing a lot of fancy work with s-expressions is going to be high density code that's a lot harder for newcomers to read than verbose, plodding Java code that is working with a simple LinkedList class or something.
Readability (Edit: to newcomers) just isn't the relevant benchmark here.
I don't think a linked list in Java is a good example. I took two CS intro courses in a row last year; the first one used Scheme and the second one concentrated on data structures and used Java. There were some completely inexperienced people taking the two courses along with me.
As far as I could tell they had much more difficulty with linked lists and trees in Java, which made them needlessly complex, than they did in Scheme. And this is with people who had actually learned about both concepts first in Scheme, so they had more experience when they came to Java.
At the same time, if you were writing a bunch of random awk-like one-offs as part of your normal lisp workflow, you wouldn't write 4 lines of code every time, right? You sit down and write some functions or macros that condensed it into something simple that allowed you to easily specify things like a split token, one or more filter-on fields and values (or better, a filter lambda), and one or more output fields, I bet. Because it's silly to write several lines for something you do a lot.
And while you might call it process-file-and-return-matching-results or something, the interface to the result might not be so different from the line of awk in the original post.
Never said I was familiar with Lisp, I've written more things in AWK (years ago)though not much and I don't use either at all anymore.
Like another poster mentioned, the lisp at least has recognizable functions, and an easy syntax structure which is easy to remember across infrequent visits to the language. AWK is so specialized and irregular, I'd have to consult a reference to do simple things even (and not just to lookup function names which is quick), which is why I eventually stopped using it.
Another reason to not use it is that it doesn't adapt readily to a problem that ends up being more difficult than first thought, or one that has additional requirements added. I've often regretted doing programming in specialized mini-languages (and I'd include bash in that category too), when requirements were added that made me wish I'd used a full power language from the start, like Python, so I wouldn't have to rewrite.
I've used awk here and there, and like programming in bash, I find it so irregular that I have to consult the manpage for simple things.
I think it does, actually. When I took a Scheme class based on SICP, we implemented a Scheme interpreter as well as looking at an OOP system using lambdas.
Writing that interpreter is the first time JavaScript's scoping rules made sense to me viscerally--they're exactly the same as Scheme's. The OOP system we used was also really similar to what you can do with JavaScript; it just used closures to save state. It wasn't exactly the same, but it was similar.
Ultimately, I find that JavaScript is much closer to Scheme than other dynamic scripting languages I've used like Python and Perl.
While it's true that Brendan Eich's development of JavaScript was influenced by Scheme, Netscape insisted that the language had to look like Java.
It's not just the syntax that's different, but the semantics as well. The hallmark of Lisp is code-as-data, data-as-code; JavaScript certainly can't claim that. I like JavaScript (for the most part), but it's wrong to call it "Lisp in C clothing".
Still, the XML JavaScript manipulates is data, not the program doing the manipulation or the language itself. When you understand what you can do if they are all the same thing, you'll be enlightened.
First off, the concept of a language #winning is a complete waste of time. Neither AWK nor Lisp is Charlie Sheen.
You use a particular language so that you can solve a problem. Some languages are better suited to solve certain problems than others. You also use a language because you like it. Using a language because it's popular, unless your job requires it, is probably the least sustainable situation.
Secondly, I'm inferring the author wants to spur Lisp's popularity by promoting new features, but encountered resistance by people on a newsgroup and gave up. This is pretty weak in my book. In what situation, both social or professional, would someone NOT encounter resistance to new ideas? To give up at the first sign of resistance, and call the people who didn't like your idea "sick" is the hallmark of a whiner.
If you want to do something, just do it. No one is stopping you. Fork the code. Make a prototype. Demonstrate it. See if you are right and they are wrong. You don't need the approval of a handful of faceless Usenet posters before you start a project.
You're inferring incorrectly (and seem to be conflating Mr. Dominus with Mr. da Silva), and also brought Charlie Sheen up for no apparent reason.
Also, there are plenty of good things that come with a language being popular. The availability of libraries, a community to bounce ideas off and get help from, etc.
Not to be rude, but that sounded like the kind of thing that a Perl programmer would say :-)
I am all for people have gut feeling likes/dislikes for what languages they personally use, but who cares what programming language, religion, politics, etc. that other people like?
I have been using Lisp since the early 1980s, and Lisp languages are great for some kinds of applications and research. Same can be said for many other languages.
I've been working on getting started in Scheme. It hasn't been easy. It seems like it's entirely married to Emacs, and I really, really don't want to learn Yet Another Editor. I'm finding the documentation to be very terse and unhelpful. Tutorials, guides, and documentation all drop terms casually which mean absolutely nothing to me. The key chording seems nonsensical. So far, I've spent about one hour learning Lisp, and many hours learning how to install and use the Scheme interpreter.
(I realize that it probably sounds silly to complain of learning "yet another" editor, when it's one of the two longest-lived for programming, but really, Emacs is extremely complex, and all I want to do is work through SICP)
As for the article, his description sounds like comp.lang.* .
Discoverability is an issue, definitely. Lisp is largely stuck in the C++ world of "multiple implementations, libraries are your problem" rather than the more modern GEM/CPAN/etc paradigm. Racket has a lot of libraries, though, and Quicklisp does the same for Common Lisp.
I believe when I was going to school we used DrScheme for Scheme development, and I think it was pretty straightforward. Suggest giving it a try - hope it helps you get to the fun part of learning Scheme (the code).
>I realize that it probably sounds silly to complain of learning "yet another" editor
Although I like Emacs and have used Emacs every day that I have not been out of town for the last 19 years, I do not think it sounds silly for a programmer to complain of learning Emacs!
Complaining about learning a text editor is hardly foolish. Takes time, and it's annoying. However, if it's genuinely "yet another", rather than merely "another", sounds like learning emacs might help with your larger problem ;)
(My tips would be: ignore the menu bar and ignore the scroll bar, spend time figuring out how the C-h help works, and don't (yet) try to fight its tendency to crap new windows everywhere. Oh, and overall, don't expect it to be any easier to learn than vim. It is just as bizarre and alien, in its own way...)
I was just thinking about something like this. The beauty of Lisp stems from the fact that you can take it as-is (as a general-purpose language) and add constructs that allow for such domain-specific code. The converse, making awk more general, would be a much more difficult task.
I think the only languages that will ever have won were C, cobol and fortran. Why do we get"scala is too complex" posts but not "partial differential equations are too complicated" posts? Anyway I'm just not going to read them but I will cut MJD slack cause his perl books are terrific.
Talking about things as broad and vague as "community" tends to obscure things more than it helps, in my opinion.
A more useful exercise is to consider the factors that go into people choosing a language in the first place. I don't think people usually think hard about how powerful or elegant the language is, at least when they're starting out, rather they pick it up when they need to solve a specific problem. For example, here's how I ended up using the languages I've learned in the past:
QBASIC - Because I wanted to make video games when I was a kid, and things like functions and classes and scopes confused 10 year old me. The idea of executing a sequence of commands was simple enough to grasp.
C - Because that's what all the "real" programmers used, and I had reached the limits of what I could do with basic.
VB - Because writing a GUI in C sucks.
Perl - Because that's just what you used for web pages at the time.
Java - Because of college.
C# - Because VB was pretty lame.
Python - Because I needed something better to write small programs in, and the entirety of perl would regularly fall out of my head because it's too complex.
F# - Because C#'s verbosity gets on my nerves and everyone was all up on functional programming; but I found the library support in most other functional languages lacking.
Ruby - Because it's kind of the lingua franca of web startups at the moment.
And on and on. I'd say about half the languages up there are actually pretty awful, and none of them are as good as LISP, but they did something specifically useful for me at the time I learned them. I can't really say that about LISP, because LISP doesn't really have a niche. The reason I ended up learning LISP (Clojure specifically) was because I wanted to be a better programmer, but I don't think that's really a strong enough argument for it if people want it to "win"
In the 60s the dominant ideology was that symbolic manipulation was all there is to AI (Society of Mind)[1]. Lisp (List Processing language) was the obvious choice for this as it is very good for string manipulation (emacs and elisp are proof of this). Also the ability to express code as lists or s-expressions made it possible to write program-writing-programs or macros which turned out to be very effective for text crunching.
Today, statistical learning is considered to be a better approach to building an AI. Much of the techniques of ML are expressed easily and efficiently using linear algebra for which Matlab (Matrix Labaratory) or Octave is much better suited.
I think Lisp fell out of favor as it is terrible when it comes to number crunching.
> Today, statistical learning is considered to be a better approach to building an AI. Much of the techniques of ML are expressed easily and efficiently using linear algebra for which Matlab (Matrix Labaratory) or Octave is much better suited.
The first statement is true: statistical learning is considered to be the leading edge of current AI research, especially since it attacks combinatorial explosion head-on. However, linear algebra is the baseline of current work, rarely the driving force. While the 'pull eigenvectors out of shitloads of data" method has been very effective and profitable, it is a very shallow approach to AI (especially considering the problems attacked in the 60s). Luckily, more intelligent algorithms are being developed that combine symbolic and probabilistic reasoning in a more direct way: compare LSA to LDA for example; LDA has a more cohesive and explanatory structure. These kind of things demand flexible programming environments (such as Lisp): Matlab is where algorithms go once they've been proven useful for 'normal people;' it is the domain of the analyst who cares about the data instead of the algorithm itself :).
Matlab is a very flexible and productive environment for doing exploratory programming. In my experience it even beats python (ipython + (emacs+auto-complete))[1]. The ability to execute small blocks of code in sequence using the %% notation for marking blocks was[2] a real joy to work with.
I thought C++ (.mex or .oct files) are where algorithms go once they've been proven useful for 'normal people'.
[2] How I miss the free Matlab license at the Uni. Last I checked a commercial license costs about $2000. So, now I've been forced to shift to Octave. Heck, if Octave is good enough for Andrew Ng, I guess its good enough for me.
AI itself fell out of flavor because of social forces, see the AI winter. I don't believe AI has really recovered socially or economically because even now there is a major financial crisis.
I must strongly disagree with this. Learning functional programming was one of the best things I ever did. It gave me a huge advantage when tackling certain problems, which helps me to this day. At my current workplace people call me in to help when they have tricky problems because they are aware I have a different skillset.
I started out in 'scripting' languages, and I can even say that learning Java, in a group with some very skilled OO gurus, was a mind-expanding experience.
I have even seen it happen, en masse, at a company which was composed of various language partisans uniting under one roof. After exposure to each others' ways, I think we all become better programmers for it.
I agree, knowing it can be huge. I'd even go so far as to say that at work, colleagues who know functional programming generally write code that is noticeably more efficient and maintainable. And on some platforms (.NET since 2006 comes to mind), you simply have to be comfortable with FP to be able to work effectively.
But on the other hand, the days where one could get away with treating 'LISP' as a proxy for 'Functional Programming' are long gone. Aside from the hoary old beasts from the 20th century such as Java, pretty much all the major languages have first-class procedures and suchlike nowadays. LISP is no longer distinguished by having good support for functional programming; it's distinguished by lacking good support for procedural programming.
I never really "learned" lisp (I read a library book about it as a teenager but I didn't have access to a computer that ran it.)
But I did learn Haskell later, and I think that made me worse at the job (C++) I was doing at the time, because it gave me the habit of trying to write C++ in a functional style and made me more frustrated with C++'s type system.
I learned Basic because I had a C64 (show of hands: anyone else?)
I learned Fortran because my Running Start advisor didn't think 8 credits of C in a term would fit into high school credits well and I had to match HS and college credits according to an arcane formula. Ok, I still shiver at the thought of Fortran....
I learned some C years later because it was a "serious" programming language. Not very well though.
PHP because it seemed like a good idea at the time.
Perl because I wanted to apply for jobs using it.,
Python because I was unemployed for a bit and bored.
Ruby because a customer asked me to teach them (yes, I objected saying I didn't know the language. I was told "that's ok!")
and so on.
However the things that have made me better have not been knowing all these languages but knowing the human side of the problems I am solving. I taught myself accounting to run my own business, never knowing that it would become my life (I now write open source accounting software).
So if I were to give a new programmer advice, it would be:
1) Learn a few languages, because then you can learn new ones easily.
2) Learn about databases, not just SQL, but also as much about the low level implementation as you can.
3) Learn about problems and other unrelated disciplines so you can better solve the problems. So yes, math, statistics, accounting, biology, chemistry, permaculture, etc. are all good things to study.
Two things keep coming up in language discussions. The first is the cry of "Lisp did it first", whenever a non-lisp language touts a new feature. The second is this concept of "winning".
If you combine these two ideas, you come to the conclusion that if any other language is seen to be "winning", it should be simple to port that language's syntax and stdlib onto a lisp environment - after all, every facility the other language might need can be provided by the lisp runtime, and reader macros might be a suitable way to avoid an explicit compilation step, depending on the language being tackled.
I cannot think of a single case of this happening. Instead, we see precisely the reverse - clojure is implemented on the JVM, CLR and JS runtimes, and there are scheme implementations everywhere.
What does this mean? It means that it isn't languages which "win" or "lose". It's plaforms. "Lisp" isn't a platform, therefore it cannot "win". The question is moot.
Your observation about platforms is spot on IMO. This is something that I want to work on - making Common Lisp a platform.
Having libraries that provide system programming features and work across a wide range of implementations is the first step. CL is underspecified in terms of a lot of systems programming stuff.
The #1 priority in this space is integration with the Unix shell - scripting, having executables, stdin and out, command-line arguments. Not really any good libraries that combine all this into one thing that works well everywhere.
The second big thing is packaging and distribution - Quicklisp addresses that well. Next step beyond making Quicklisp better is a script for Linux that finds the Common Lisp implementation on your system (and installs one if not present), and loads whatever software you need - essentially a common installer for CL applications that bootstraps off of Quicklisp.
Of the implementations on that list, only three are what I'd call "competitive imports": the JS, Python and JVM implementations. I'm intrigued as to why these are not generally considered to be viable first-class alternatives.
Since when have programming languages ever been about winning? Lisp solves problems in a certain way the works well in certain cases for some people. Same case with awk or Perl or Python or whatever. Lisp may not be the language everyone uses for everything, but I find myself writing code in Clojure, Scheme, or Emacs Lisp because it makes sense to me. So what if that awk example is 2.5 lines longer than the actual version? It may be more work for my fingers but I still get to write it in Lisp.
I'm going to be one of the "stupid argumentative people" that he says are on comp.lang.lisp (which I had never actually heard of before) and say that Lisp users don't want Lisp to win. People who understand Lisp, as mentioned in another comment, that _they_ are going to be the ones winning in the end. Maybe this person wins with Perl. I don't. Ruby, Clojure, Prolog, and JavaScript meet my needs so I use them. Languages don't compete for adoption they solve problems.
It might be worth pointing out, for readers who missed it, that this article was written in 2003. So instead of asking whether it correctly describes the situation today, you might find it more useful to ask whether it correctly described the situation in 2003, and whether things have changed, and if so how.
da Silva does have a completely valid point. CL needs a library to make it easy to run your favorite implementation with your software as a Unix shell script. And more reader macros. I use so many my code is starting to look like Perl. I don't think that's a bad thing. Adding an APL reader macro for array processing would IMO be a wonderful thing for a lot of the Common Lisp graphics libraries.
Hey, this is cool, using awk you can save a minute for every one-liner you write. Writing 2 one-liners per day on average, it's only half a year to make up for a day spent on learning awk!
More seriously, if I wanted to save few minutes per day, I'd rather remove Facebook account.
I was arguing with a lisper the other day about how lisp' power make it easy to go overkill and have too much nested lambdas.. while language like Java, forcing you to use vars, sometime makes the code easier to read.
He then told me to not blame my weakness at reading code on Lisp.
> JavaScript has the most important dynamic features of Lisp (GC, dynamic typing, first class functions, conditionals, eval, etc).
The reason this doesn't hold up is because there are a bunch of other languages that also have most of those features of Lisp, and some of them are older than JS. Python, Ruby, and Perl all have similar features. Every language has conditionals now so it's not even worth mentioning. Even Java has GC, broken closures, and reflection.
> JavaScript, is even a pretty solid tree processing language, because most JavaScript programs manipulate XML trees. XML is basically S-expressions with hundreds of pounds of useless clothing (end tags, attributes, etc) weighing it down.
You can manipulate XML in Java and C, does that also make Java Lisp in C's clothing, or C Lisp in C's clothing? Lisp macros manipulate code as trees, but that doesn't mean that any language that can manipulate trees is a Lisp. XML isn't JavaScript code, it's just data. The trees that Lisp macros manipulate is data and also Lisp code.
> Considering all this I think what Douglas Crockford said is completely accurate, JavaScript is Lisp in C's clothing.
It's not "completely accurate". It's mostly inaccurate. It's a cute pithy platitude, but it's not really helpful. Just Google "code is data" and see what kinds of confusion is out there about this.
Apology to Douglas Crockford, who does good work. I actually came back to Lisp through his JavaScript lectures, so I feel a bit bad being harsh.
You can do anything in any Turing-complete language. JavaScript not only can manipulate trees, it often does. Of course, rather or not you see Lisp in it depends upon how you are identifying Lisp.
99 comments
[ 0.23 ms ] story [ 181 ms ] threadPersonally, I don't even know what it means for a language to 'win'. I would be fine with Lisp/Scheme being marginally popular and acceptable when you're in the company of clever colleagues that could reasonably be expected to grok Lisp after a short while. Nevertheless it isn't. The reasons why that is currently the case would go a longer way towards explaining why that may never be the case.
It is "the Lisp community" in the sense that there is no other widely known, recommended way to get in touch with people using Lisp. The community may exist somwhere else, but they are hidden from newbies, whose first contact with the community still is the cesspit that is c.l.l, often by the spam ridden Google Groups interface.
A college kid looking for assistance with lisp these days is likely to hit up StackOverflow or /r/lisp or /r/scheme or one of the clojure communities depending on what they're using. Any of these are less 'hidden' than usenet, which happily has fallen into enough obscurity that c.l.l.'s toxicity will slowly die for lack of new blood.
I think this is ultimately always a problem between ultra-smart people who live in something of an abstracted world that frequently approaches fantasy and the reality of industry, which generally doesn't care about how pretty something is unless someone will buy it because it is pretty. That's a pretty large gap, and, while in my opinion there is no need for arrogance, it is pretty clear why most of the smartest people in history end up on the former side of that divide. They want to contemplate some sort of eternal idea which usually they ascribe beauty to (e.g. Bohr, Einstein, etc.) -- and yet hackers, unlike theoretical physicists, are halfway between the people probing the mysteries of the universe and those putting together blueprints for the atom bomb.
In my opinion that's just life. Einstein hated the bomb and rightly so in my opinion -- but that doesn't mean that it was any less a necessity for the Manhattan project to go forward. The sad thing, however, is that lots of brilliant people trying to navigate this divide end up with a huge chip on their shoulder. PG talks about this in H&P; the jocks were popular and (surprise!) the nerds were not. So you go out and get a few million and say, "ha, screw the jocks." Fine, generally speaking I think that is a good idea, but let's not turn it into a wanker fest since there are lots of needed functions in the world that should probably be performed by those who can't understand Lisp -- and I don't just mean cleaning toilets, I mean politics.
Abstraction, which is really what lisp is about in many ways, is only ever IMO one pole. You have to zoom out to see the bigger picture and zoom in to address the minutia. Generally people miss the forest for the trees, so I have every sympathy for those who stick with the forest and ignore the trees. But when it comes down to it, someone has to re-write your code in blub to make a functional product (even true with Viaweb) so have some sympathy for the little man who has to do a sh't job, probably his mother never gave him fairy tales to read and he only vaguely knows who Godel, Escher, and Bach are. That's sad, but that's life and we who are Americans should especially expect it as an immigrant nation.
Anyways, I'm one who discovered Lisp rather late despite and not because of the Lisp community as it is usually presented. I think it is beautiful and esp. I think SICP is a fantastic book to introduce one to computer science concepts and I think that industry should serve great passions and ideas and not vice versa. Hell, I even think lisp machines are a great idea and hope someone builds new ones and they take over the world. But despite all of that, I would never hang out with "the Lisp community."
Why? I want to build great products. Great products need to scale. If you want to go to the moon you need a f'ing spaceship and not emacs and an open source notebook. Spaceships are big. They take a lot of people to run, and they have to be smart people. One mistake and you are smithereens at Cape Canaveral.
The thing that irks me the most about all of this whining is that America used to be capable of building automobiles and space shuttles and (omg!) computers. It was amazing. Now it is hello Taiwan, goodbye America. People talk about "Rework" and how they can't imagine being in a company with more than ten p...
The moon is not that far away from orbital flight. These two guys might disagree with you: http://www.copenhagensuborbitals.com/
The orbit part seems the most complicated.
Every single system you name is made up of a large number of complex sub-systems designed and built to exacting requirements, and any one of them can still break at any time. Thinking you "got it right" just because it didn't break one time in one set of circumstances is unbelievably naïve. There's a reason all man-rated launch systems have redundant backup systems, and even the fallbacks don't always work right.
By the way, let me know when you get micrometeoroid shielding "right" -- every space agency on Earth will want to talk to you. You might even win a Nobel Prize.
You're also completely ignoring navigation. Just because you can fire up a rocket doesn't mean shit if you're at the wrong point in your orbit, or pointed in the wrong direction.
You're also failing to distinguish between "I can get THIS rocket into orbit" and "I can get a rocket big enough to carry people and a useful payload into orbit and/or to the moon". Think you can just "scale up"? You're wrong. Effects that were too small to measure before will suddenly kill you. Materials that could handle the strain of the smaller rocket will crumble under the increased forces.
Oh, by the way, every time the weight or configuration of your spacecraft changes, you're gonna have to rework your navigation assumptions.
Might I suggest playing with Orbiter for a while? Once you've done that, spend a few minutes thinking about the fact that you've just been overwhelmed by a vastly simplified simulation in which nothing ever goes wrong. Now picture the real world.
Oh, by the way, your heat shield is cracked, but nobody noticed because your budget didn't allow for more than one guy to inspect it, and he was too drunk. Have fun getting home.
Micrometeorites? Did Apollo have that? I am not implying it's easy - I'm implying LEO is the hardest part when it comes to a moon-orbit trip.
And in the case of an unmanned craft, it's easier: you don't have to bother with life support, atmospheric braking and most of the radiation shielding.
"If you want to go to the moon you need a f'ing spaceship and not emacs and an open source notebook. Spaceships are big. They take a lot of people to run, and they have to be smart people. One mistake and you are smithereens at Cape Canaveral."
Followed by sedachv saying some guys who are trying to launch humans on suborbital flights would disagree.
Nothing you've said explains what suborbital flights have to do with going to the moon. On the contrary, you seem to be admitting they have nothing to do with going to the moon, so I still have absolutely no idea what sedachv's point was.
But, then, this discussion is completely unrelated to the point regarding emacs and an open source notebook (whatever that is). In general, Jd's rant felt confusing. I am not sure how Lisp and spacecraft are related, BTW. He (or she) implied somehow that you couldn't go to space with something simple and elegant like Lisp, but I can't be sure.
I'll make the relation very clear. There is a segment of the Lisp community, which most certainly includes Paul Graham, that maintains that projects with large team sizes are bad. There is a certain logic here, as it is hard to maintain a high average intelligence distributed across a large number of people. Most true geniuses were loners. Regardless, projects of a certain scope (i.e. building a space shuttle) require large teams. You simply can't do it with two guys in a basement.
In a certain sense the computer language employed is irrelevant, except that the lisp community has never, largely because of the facts that should be obvious but are apparently not to the introverted "genius" types they pray on, produced good and extensive enough libraries to be viable for most real world tasks. In case you didn't notice, for example, it took what, 4 years for Hacker News to get HTTPS support.
I don't want to rib anyone too badly, because I am a strong supporter of what YCombinator is doing in general and in the incorporation of lambdas and closures in newer languages, but I think generally speaking it is clear that the Lisp culture is not to cooperate but to position one's self as some sort of genius and thus to create one's own dialect, etc.
I'll give you an example that will probably irritate some people, but is relevant here. Microsoft Word is, in my opinion, one of the greatest architectural marvels of modern civilization. The feature set of that single app is truly extraordinary, and there are all sorts of wonky ways that you can do lots of tasks that makes millions (and potentially even billions) of people's lives better every day. I understand that there is a point to OpenOffice and "fighting the man" and whatever since Microsoft certainly crushed some competitors in mean ways, but realistically there is nothing in the world that competes.
Now you might say, oh sure but I can just use vim and use latex for formatting (or even google docs). And in a certain sense you might be right too, but sooner or later you will find a feature that is not accessible to you (I recently noticed that change tracking still absolutely blows in Google Docs compared to Word).
Why do I bring this up? Well, even if you are right that "the hardest part of going to the Moon is achieving Earth orbit," you still have to have all of those other things. You need life support or you dead; this is non-negotiable, just in the way that mail merge is not negotiable for millions of people at millions of office worldwide. And if you want life support (or mail merge), you need to work with the people who design these other systems.
By the way, I'm not saying you need to like any of this. I'm simply saying that if you want to build something great, you have to at times slog through the mud. My experience with Lispers is they are frequently afraid to get their hands dirty. And that doesn't cut it except in a pretty-ditty fantasy castle.
The shuttles are not engineering successes. Most large projects (large as in "lots of brains required to think about how they are going to work") usually aren't either. I'll side with pg on this. Humans cannot organize that well and less ambitious steps are a better approach to solve really big problems.
Languages are tools you use to express and think about problems. There are problems that are more amenable to be expressed in terms of Lisp and others that are more suited for C. Or SQL, or Forth.
It may be hard to express mud in Lisp, but I don't think the whole thing is as bad as you do.
But I have to wonder... Does anyone still use mail merge?
It is interesting that you describe language as a tool to think about a problem. Is it really so? Is it only because you have the language that you think about the problem in terms of the language?
Humans cannot organize that well? Well, I guess Cape Canaveral in 1969 was smoke and mirrors -- or what do you mean? I think you probably mean that the cost of organizing at a large scale like that is not a cost you are personally (or, collectively in terms of the culture of elites in the West) willing to bear. I would even suggest that it very well could be in actuality an unwillingness to bear any sacrifice for the sake of a collective goal.
"Less ambitious steps" for "really big problems." Sounds great. What steps do you mean and what problems are you possibly hoping to solve? How the private sector might be able to get someone in space -- an "engineering success" that was already accomplished approximately 50 years ago, now potentially finally accomplished by the private sector, so long as individual Russian tycoons are able to pay for $100M tickets with money stolen from starving peasants.
A brave new world indeed. As for mail merge, I have very little interest in the common man. I live in Silicon valley and watch the world burn from a carefully-cultivated distance.
That attitude, to me, is a large turn-off.
I disagree with your notion that Lisp code has to be re-written into another language to address the minutia. I address minutia in Scheme a lot.
No, what was amazing was how stupid the exercise was. The Common Lisp example was a perfectly reasonable translation of the AWK script, accounting for the fact that Common Lisp is a general purpose programming language that doesn't have the luxury of dedicating syntax to text-munging the way AWK does.
Also, the whole concept of Lisp "winning" is silly. Common Lisp isn't making a comeback. Nobody thinks that. But every day that passes, languages get more like Lisp. Take, e.g., Xtend. We've got:
LAMBDA: http://www.eclipse.org/Xtext/xtend/#closures TYPECASE: http://www.eclipse.org/Xtext/xtend/#switchexpression FORMAT: http://www.eclipse.org/Xtext/xtend/#templateexpression Open methods: http://www.eclipse.org/Xtext/xtend/#extensionmethods Multimethods: http://www.eclipse.org/Xtext/xtend/#multipledispatch Also: Statements as expressions, etc, implicit return, etc.
----
[1] https://github.com/darius/awklisp
[2] http://awk.info/?AwkLisp
But seriously, take a look at the two examples again. Are you really suggesting that the Lisp version is easier?
All you have to understand for the Awk example how field variables work, then you can read the whole thing at a glance. The Lisp version contains custom macros and is four lines long!
I can guess what 'with-lines-from-file' does, I can guess what 'string-split' does, i can guess what 'string=' does, etc. The only thing I might not understand is 'aref'.
With the AWK example, I have no place to start. Symbol-oriented languages, rather than word-oriented languages, are like that. They tend to be more concise for things very specialized tasks, like this, but that limits their generality. Show me a matrix multiplication routine in AWK versus Common Lisp.
1) text and file processing are very common tasks 2) Lisp is not especially suited at these tasks, though it is very well suited for some other tasks. 3) If a dialect of lisp more suited to these very common tasks were made, it would increase the popularity of Common Lisp for the tasks that it works well for by familiarizing people with it.
AWK is a purpose-built language for splitting lines into fields and doing stuff with the result, so of course there's not a lot of boilerplate for splitting lines into fields and doing stuff with the results.
Lisp for doing a lot of fancy work with s-expressions is going to be high density code that's a lot harder for newcomers to read than verbose, plodding Java code that is working with a simple LinkedList class or something.
Readability (Edit: to newcomers) just isn't the relevant benchmark here.
As far as I could tell they had much more difficulty with linked lists and trees in Java, which made them needlessly complex, than they did in Scheme. And this is with people who had actually learned about both concepts first in Scheme, so they had more experience when they came to Java.
At the same time, if you were writing a bunch of random awk-like one-offs as part of your normal lisp workflow, you wouldn't write 4 lines of code every time, right? You sit down and write some functions or macros that condensed it into something simple that allowed you to easily specify things like a split token, one or more filter-on fields and values (or better, a filter lambda), and one or more output fields, I bet. Because it's silly to write several lines for something you do a lot.
And while you might call it process-file-and-return-matching-results or something, the interface to the result might not be so different from the line of awk in the original post.
Like another poster mentioned, the lisp at least has recognizable functions, and an easy syntax structure which is easy to remember across infrequent visits to the language. AWK is so specialized and irregular, I'd have to consult a reference to do simple things even (and not just to lookup function names which is quick), which is why I eventually stopped using it.
Another reason to not use it is that it doesn't adapt readily to a problem that ends up being more difficult than first thought, or one that has additional requirements added. I've often regretted doing programming in specialized mini-languages (and I'd include bash in that category too), when requirements were added that made me wish I'd used a full power language from the start, like Python, so I wouldn't have to rewrite.
I've used awk here and there, and like programming in bash, I find it so irregular that I have to consult the manpage for simple things.
Writing that interpreter is the first time JavaScript's scoping rules made sense to me viscerally--they're exactly the same as Scheme's. The OOP system we used was also really similar to what you can do with JavaScript; it just used closures to save state. It wasn't exactly the same, but it was similar.
Ultimately, I find that JavaScript is much closer to Scheme than other dynamic scripting languages I've used like Python and Perl.
It's not just the syntax that's different, but the semantics as well. The hallmark of Lisp is code-as-data, data-as-code; JavaScript certainly can't claim that. I like JavaScript (for the most part), but it's wrong to call it "Lisp in C clothing".
First off, the concept of a language #winning is a complete waste of time. Neither AWK nor Lisp is Charlie Sheen.
You use a particular language so that you can solve a problem. Some languages are better suited to solve certain problems than others. You also use a language because you like it. Using a language because it's popular, unless your job requires it, is probably the least sustainable situation.
Secondly, I'm inferring the author wants to spur Lisp's popularity by promoting new features, but encountered resistance by people on a newsgroup and gave up. This is pretty weak in my book. In what situation, both social or professional, would someone NOT encounter resistance to new ideas? To give up at the first sign of resistance, and call the people who didn't like your idea "sick" is the hallmark of a whiner.
If you want to do something, just do it. No one is stopping you. Fork the code. Make a prototype. Demonstrate it. See if you are right and they are wrong. You don't need the approval of a handful of faceless Usenet posters before you start a project.
Also, there are plenty of good things that come with a language being popular. The availability of libraries, a community to bounce ideas off and get help from, etc.
"People aren't using Lisp, so maybe we could make it usable for things AWK is good at and get people into it that way."
Ok.
"People aren't using Java, so maybe we could make it usable for things AWK is good at and get people into it that way."
Wait, they're not?
I am all for people have gut feeling likes/dislikes for what languages they personally use, but who cares what programming language, religion, politics, etc. that other people like?
I have been using Lisp since the early 1980s, and Lisp languages are great for some kinds of applications and research. Same can be said for many other languages.
(I realize that it probably sounds silly to complain of learning "yet another" editor, when it's one of the two longest-lived for programming, but really, Emacs is extremely complex, and all I want to do is work through SICP)
As for the article, his description sounds like comp.lang.* .
Although I like Emacs and have used Emacs every day that I have not been out of town for the last 19 years, I do not think it sounds silly for a programmer to complain of learning Emacs!
Easy GUI IDE with debugging, etc.
It's annoying to learn another IDE< yes, but Scheme just needs an IDE that understands how to highlight/indent it properly.
It's a little obtuse to learn unless you're following along a course text with it, but nowhere near emacs' learning curve.
It's a package to support some code in the book that is some what implementation specific, drawing graphics for the picture language, for instance.
(My tips would be: ignore the menu bar and ignore the scroll bar, spend time figuring out how the C-h help works, and don't (yet) try to fight its tendency to crap new windows everywhere. Oh, and overall, don't expect it to be any easier to learn than vim. It is just as bizarre and alien, in its own way...)
I didn't run it when I posted the comment. I just copied it from the article.
(The awk macro itself is an exercise left for the reader...)
A more useful exercise is to consider the factors that go into people choosing a language in the first place. I don't think people usually think hard about how powerful or elegant the language is, at least when they're starting out, rather they pick it up when they need to solve a specific problem. For example, here's how I ended up using the languages I've learned in the past:
QBASIC - Because I wanted to make video games when I was a kid, and things like functions and classes and scopes confused 10 year old me. The idea of executing a sequence of commands was simple enough to grasp.
C - Because that's what all the "real" programmers used, and I had reached the limits of what I could do with basic.
VB - Because writing a GUI in C sucks.
Perl - Because that's just what you used for web pages at the time.
Java - Because of college.
C# - Because VB was pretty lame.
Python - Because I needed something better to write small programs in, and the entirety of perl would regularly fall out of my head because it's too complex.
F# - Because C#'s verbosity gets on my nerves and everyone was all up on functional programming; but I found the library support in most other functional languages lacking.
Ruby - Because it's kind of the lingua franca of web startups at the moment.
And on and on. I'd say about half the languages up there are actually pretty awful, and none of them are as good as LISP, but they did something specifically useful for me at the time I learned them. I can't really say that about LISP, because LISP doesn't really have a niche. The reason I ended up learning LISP (Clojure specifically) was because I wanted to be a better programmer, but I don't think that's really a strong enough argument for it if people want it to "win"
Today, statistical learning is considered to be a better approach to building an AI. Much of the techniques of ML are expressed easily and efficiently using linear algebra for which Matlab (Matrix Labaratory) or Octave is much better suited.
I think Lisp fell out of favor as it is terrible when it comes to number crunching.
[1] The dramatic collapse of this ideology is chronicled in this wired article (Two AI Pioneers. Two Bizarre Suicides. What Really Happened?): http://www.wired.com/techbiz/people/magazine/16-02/ff_aimyst...
The first statement is true: statistical learning is considered to be the leading edge of current AI research, especially since it attacks combinatorial explosion head-on. However, linear algebra is the baseline of current work, rarely the driving force. While the 'pull eigenvectors out of shitloads of data" method has been very effective and profitable, it is a very shallow approach to AI (especially considering the problems attacked in the 60s). Luckily, more intelligent algorithms are being developed that combine symbolic and probabilistic reasoning in a more direct way: compare LSA to LDA for example; LDA has a more cohesive and explanatory structure. These kind of things demand flexible programming environments (such as Lisp): Matlab is where algorithms go once they've been proven useful for 'normal people;' it is the domain of the analyst who cares about the data instead of the algorithm itself :).
I thought C++ (.mex or .oct files) are where algorithms go once they've been proven useful for 'normal people'.
[1] http://bfrsblog.blogspot.com/2011/10/making-emacs-first-clas...
[2] How I miss the free Matlab license at the Uni. Last I checked a commercial license costs about $2000. So, now I've been forced to shift to Octave. Heck, if Octave is good enough for Andrew Ng, I guess its good enough for me.
Boy I think I took that advise from the wrong source.
Math can make me a better programmer.
Statistics can make me a better programmer.
Accounting can make me a better programmer.
Biology can make me a better programmer.
Chemistry can make me a better programmer.
Building Macros and DSLs are the new Ivory Tower of software architecture.
Spend a few months to find a reasonable ecosystem (NB: the libraries, tools and community, not just the language), then move on.
I started out in 'scripting' languages, and I can even say that learning Java, in a group with some very skilled OO gurus, was a mind-expanding experience.
I have even seen it happen, en masse, at a company which was composed of various language partisans uniting under one roof. After exposure to each others' ways, I think we all become better programmers for it.
But on the other hand, the days where one could get away with treating 'LISP' as a proxy for 'Functional Programming' are long gone. Aside from the hoary old beasts from the 20th century such as Java, pretty much all the major languages have first-class procedures and suchlike nowadays. LISP is no longer distinguished by having good support for functional programming; it's distinguished by lacking good support for procedural programming.
But I did learn Haskell later, and I think that made me worse at the job (C++) I was doing at the time, because it gave me the habit of trying to write C++ in a functional style and made me more frustrated with C++'s type system.
I learned Basic because I had a C64 (show of hands: anyone else?)
I learned Fortran because my Running Start advisor didn't think 8 credits of C in a term would fit into high school credits well and I had to match HS and college credits according to an arcane formula. Ok, I still shiver at the thought of Fortran....
I learned some C years later because it was a "serious" programming language. Not very well though.
PHP because it seemed like a good idea at the time.
Perl because I wanted to apply for jobs using it.,
Python because I was unemployed for a bit and bored.
Ruby because a customer asked me to teach them (yes, I objected saying I didn't know the language. I was told "that's ok!")
and so on.
However the things that have made me better have not been knowing all these languages but knowing the human side of the problems I am solving. I taught myself accounting to run my own business, never knowing that it would become my life (I now write open source accounting software).
So if I were to give a new programmer advice, it would be:
1) Learn a few languages, because then you can learn new ones easily.
2) Learn about databases, not just SQL, but also as much about the low level implementation as you can.
3) Learn about problems and other unrelated disciplines so you can better solve the problems. So yes, math, statistics, accounting, biology, chemistry, permaculture, etc. are all good things to study.
If you combine these two ideas, you come to the conclusion that if any other language is seen to be "winning", it should be simple to port that language's syntax and stdlib onto a lisp environment - after all, every facility the other language might need can be provided by the lisp runtime, and reader macros might be a suitable way to avoid an explicit compilation step, depending on the language being tackled.
I cannot think of a single case of this happening. Instead, we see precisely the reverse - clojure is implemented on the JVM, CLR and JS runtimes, and there are scheme implementations everywhere.
What does this mean? It means that it isn't languages which "win" or "lose". It's plaforms. "Lisp" isn't a platform, therefore it cannot "win". The question is moot.
Having libraries that provide system programming features and work across a wide range of implementations is the first step. CL is underspecified in terms of a lot of systems programming stuff.
The #1 priority in this space is integration with the Unix shell - scripting, having executables, stdin and out, command-line arguments. Not really any good libraries that combine all this into one thing that works well everywhere.
The second big thing is packaging and distribution - Quicklisp addresses that well. Next step beyond making Quicklisp better is a script for Linux that finds the Common Lisp implementation on your system (and installs one if not present), and loads whatever software you need - essentially a common installer for CL applications that bootstraps off of Quicklisp.
About other languages on Common Lisp, there is actually a large number: http://www.cliki.net/programming%20language
A lot of languages have been ported to run on various Scheme (Racket and Gambit) implementations.
I'm going to be one of the "stupid argumentative people" that he says are on comp.lang.lisp (which I had never actually heard of before) and say that Lisp users don't want Lisp to win. People who understand Lisp, as mentioned in another comment, that _they_ are going to be the ones winning in the end. Maybe this person wins with Perl. I don't. Ruby, Clojure, Prolog, and JavaScript meet my needs so I use them. Languages don't compete for adoption they solve problems.
da Silva does have a completely valid point. CL needs a library to make it easy to run your favorite implementation with your software as a Unix shell script. And more reader macros. I use so many my code is starting to look like Perl. I don't think that's a bad thing. Adding an APL reader macro for array processing would IMO be a wonderful thing for a lot of the Common Lisp graphics libraries.
More seriously, if I wanted to save few minutes per day, I'd rather remove Facebook account.
He then told me to not blame my weakness at reading code on Lisp.
The reason this doesn't hold up is because there are a bunch of other languages that also have most of those features of Lisp, and some of them are older than JS. Python, Ruby, and Perl all have similar features. Every language has conditionals now so it's not even worth mentioning. Even Java has GC, broken closures, and reflection.
> JavaScript, is even a pretty solid tree processing language, because most JavaScript programs manipulate XML trees. XML is basically S-expressions with hundreds of pounds of useless clothing (end tags, attributes, etc) weighing it down.
You can manipulate XML in Java and C, does that also make Java Lisp in C's clothing, or C Lisp in C's clothing? Lisp macros manipulate code as trees, but that doesn't mean that any language that can manipulate trees is a Lisp. XML isn't JavaScript code, it's just data. The trees that Lisp macros manipulate is data and also Lisp code.
> Considering all this I think what Douglas Crockford said is completely accurate, JavaScript is Lisp in C's clothing.
It's not "completely accurate". It's mostly inaccurate. It's a cute pithy platitude, but it's not really helpful. Just Google "code is data" and see what kinds of confusion is out there about this.
Apology to Douglas Crockford, who does good work. I actually came back to Lisp through his JavaScript lectures, so I feel a bit bad being harsh.