10 ms·

Where my mouth is

134 points by momo-reina 13y ago

momo-reina 13y ago
Jao's old blog[1] is a treasure trove of information. Modern Lisp hackers like him, Zach Beane and Edi Weitz are great representatives for the Lisp community: incredibly talented and yet very humble and more than willing to help out those just starting out in Lisp. [1] http://programming-musings.org/ http://programming-musings.org/
mynameisme 13y ago
Saying Clojure is a counter example kinda ignores the big reason companies don't want to use Lisp/Haskell/etc. When you're on the JVM, you get to use that gigantic collection of Java libraries and Java community for almost no downside. With Common Lisp/Scheme, so much time is spent reinventing wheels due to smaller communities that they're not worth using for larger projects, in my opinion. Also with Clojure, you always fairly easily port to Java if you decide things aren't going as planned a couple of years down the line, as CodeHaus did with Scala. Don't get me wrong, I think Clojure is by far the best Lisp to choose out there for a product, but that's mainly because it has its big "Java ogre" brother standing behind it. edit: And also, you don't need to write Java in a factories on top of factories style just because some choose to do that. The same is even more true of xml configuration.
- lalc 13y ago
  I have to admit I'm ignorant as to what Java libraries I'm missing out on by not using a JVM language. I hear about this advantage a lot though! What are some examples of good Java libraries that aren't as good in other common languages?
  - elbear 13y ago
    If you're using another "common" language, you're probably not missing out on anything. The distinction he was making was between Java and a "not common" language, like Common Lisp, for example.
  - threeseed 13y ago
    The best Java libraries from my perspective are the ones for large scale projects. You can leverage proven techniques and technologies. e.g. http://twitter.github.io http://twitter.github.io or http://netflix.github.io http://netflix.github.io
    - Derbasti 13y ago
      Is it a syntax error to talk Java without playing buzzword bingo? "Leverage proven techniques and technologies"? What does that even mean?
      - threeseed 13y ago
        What do you mean what does it mean ? Leverage = take advantage of Proven = demonstrated to have worked Techniques = using one approach versus another Technologies = existing code
        Derbasti 13y ago
        Right..... So you're saying that your code works? Like, it doesn't crash? That's... awesome... Buzzword bingo does not add value. It only obscures meaning. Of course your code works. Of course you use existing technologies. That work. In existing code. That you leveraged. Using techniques. And technologies. Jesus, I hate this kind of language.
        Drakim 13y ago
        Java does seem to have some sort of strange connection to the business world (which just can't get enough of buzzwords).
        roblev 13y ago
        I think the OP's point was clear, Java has a big library of tested, debugged, robust libraries.
        hughw 13y ago
        He wasn't saying that his code doesn't crash. He was saying many other people have contributed java libraries his programs can use, so that he doesn't have to hire an expert in HTTP, or computational geometry, or many problem domains that aren't the direct concern of his application, yet are necessary for it to work. He said it in a compact way. It's a form of compression.
  - amouat 13y ago
    I think the point is that most of the time when you think "I need something that does x", there is a library for that; whether it is a core library or not. In Lisp I guess you often find something very specific that doesn't quite solve the problem you have. Having said that, I really liked the Google Guava library, although a good bit of that stuff is working around or solving problems with Java itself. https://code.google.com/p/guava-libraries/ https://code.google.com/p/guava-libraries/
    - trimbo 13y ago
      Guava is fantastic. So many times in the last few years, I've pointed people to Guava in code reviews "hey, this thing you just wrote, Guava already has that."
  - jbrechtel 13y ago
    Natural Language Processing libraries https://opennlp.apache.org/ https://opennlp.apache.org/ http://nlp.stanford.edu/ http://nlp.stanford.edu/ Cloud provider automation libraries http://jclouds.incubator.apache.org/ http://jclouds.incubator.apache.org/ Distributed stream computing https://incubator.apache.org/s4/ https://incubator.apache.org/s4/ Asynchronous event driven IO, battle tested, mother recommended http://netty.io/ http://netty.io/ In-process webserver http://www.eclipse.org/jetty/ http://www.eclipse.org/jetty/ ....to name a few. It's probably useful to take some thing that you'll need and look in ecosystem X for it (say... .NET) and then compare what's available there to what's available on the JVM. In my experience, the JVM wins out almost every time when it comes to number of options and maturity of options.
- 616c 13y ago
  Wish I could up this one more. I am in the process of playing with Lisp (in my case, Common Lisp, the SBCL variant to be specific) and I would love to see people with production services in any Lisp, or even Scheme. I have been very attracted to the idea of Lisp, specifically as I discovered teepeedee and teepeedee2 as being some of the first truly fast web servers [0], and now I found wookie,[1] an evented web server running on top of libevent. I really want to play with that. The closest thing I know of to people running "prod services on Lisp" are the Untyped guys in the Racket Scheme community [2], and not much else. I know pg and company became famous on Viaweb and Lisp, but since then there are scarce examples. However, the amount of bitching libraries and cool books (pg's book included) make me want to buck the trend and do it anyway, even if no one watches and I end up in my own ditch writing code to dig my way out for the all the unstable or non-existent pieces of code waiting for me. [0] https://github.com/vii/teepeedee2 https://github.com/vii/teepeedee2 [1] https://github.com/orthecreedence/wookie/ https://github.com/orthecreedence/wookie/ [2] https://github.com/untyped https://github.com/untyped
  - momo-reina 13y ago
    Without mentioning the usual Emacs, AutoCad(AutoLISP), and ITA: [0] Google App Inventor http://googleresearch.blogspot.com/2009/08/under-hood-of-app-inventor-for-android.html http://googleresearch.blogspot.com/2009/08/under-hood-of-app... [1] Quickdocs is written in Lisp http://quickdocs.org/ http://quickdocs.org/ [2] Jak and Daxter http://www.gamasutra.com/view/feature/2985/postmortem_naughty_dogs_jak_and_.php http://www.gamasutra.com/view/feature/2985/postmortem_naught... [3] Maxima http://maxima.sourceforge.net/ http://maxima.sourceforge.net/ [4] Prime Trader (Lisp Works) http://www.lispworks.com/success-stories/netfonds-primetrader.html http://www.lispworks.com/success-stories/netfonds-primetrade... [5] Franz success stories http://www.franz.com/success/ http://www.franz.com/success/
    - 616c 13y ago
      Thanks for the list (pun kind of intended). I am well aware of Emacs (who does Lisp without SLIME, that seems painful) and Autocad. Your list is very cool, but I meant people writing production web services and startups that are often featured here. Of them all, the most interesting one I saw a month or so ago was someone writing production services in Haskell. That generated a lot of interest, and I have not heard of anyone brave enough to do it with a Lisp, save Clojure. I was unaware of Jak and Daxter, but I would hope people who use Common Lisp, manage their packages in Quicklisp, and do other CL stuff know what Quickdocs. I am in that camp. :-)
- klibertp 13y ago
  > With Common Lisp/Scheme, so much time is spent reinventing wheels due to smaller communities I'm not sure, but I think that C and C++ ecosystem has at least the same amount of libraries available as Java. And the reason why I mention this is that many Lisps have FFI which makes integrating those libraries almost seamless. Aside from Gambit-C, which compiles Scheme code to C and so supports inline C code, for example Racket has very nice DSSL for FFI, which reduces the need for glue code to one or two lines of code per imported function. Integration with native Java libraries is easier from JVM languages, of course, but then there are many Lisps for JVM too. And for CLR, where tail call elimination exists. So if you want to write in Lisp, but are worried about lack of libraries, you really have many options. Clojure is alright, but saying that it's the only choice if you need access to libraries is not quite true.
  - coolsunglasses 13y ago
    >I'm not sure, but I think that C and C++ ecosystem has at least the same amount of libraries available as Java. Uh, no. Not for the kind of applications and systems that get built these days.
- LanceH 13y ago
  That doesn't explain the original adoption of Java, though. Put a billion dollars of marketing into Clojure and see where that gets you. Just the marketing effort alone. Do you guys remember all the managers, directors, secretaries taking Java courses because it was going to change everything? Java rode a big wave of stupid that was the internet boom.
pron 13y ago
Far be it from me to say that the choice of programming language doesn't matter, or that picking one slightly off the trodden path is not a sign of a certain openness of mind. I also think that Clojure is particularly enjoyable, elegant and beautiful, while at the same time extremely practical, easy to learn, and well suited to modern application development; it is the best designed programming language I have encountered in my almost-two-decades-long programming career (with Julia giving it a run for its money if only it had been implemented on top of the JVM as well). However, I've seen a clear inverse correlation between the magnitude of technical challenge and the emphasis on the choice of programming language. It is usually web application developers that spend the time and effort picking what they deem to be a modern, or "more productive" programming language. It is as it should be, because most productive languages, Clojure included, are usually more productive for applications – not complex basic algorithms, or the development of novel data structures. Application developers spend 90% or more of their time writing and debugging production code, so they'd better spend some time picking and learning a language that makes their work easier. But people in the fields of computer vision, artificial intelligence, machine learning, concurrent data-structures and others – very smart, very forward thinking people – would pick Java or C/C++ nine times out of ten, and not only because these languages are better suited to their task performance-wise, but because they have other, more important things to think about. If your challenge is not translating a business model into code, but solving a real algorithmic or technical problem, then the programming language really doesn't matter, and you're better off sticking with the one(s) you know best. If 95% of your time is spent thinking anyway, it doesn't matter if your language can reduce the remaining 5% of actual development by a factor of two or more. IBM's Watson would not have come about sooner if its engineers had chosen Haskell over Java. ADD.: "Productive" programming language are better when you need to solve the same problem over and over (say retrieve data from a database and generate HTML). But when your problem is more or less one-of-a-kind, these productivity boosts either disappear or don't matter. When you're handcrafting a magnificent chair, picking the best assembly line is irrelevant. Chances are it's been designed to solve other problems and retrofitting it to your requirements is extra work, and even if it wasn't, this chair need only be made once. Mass production tools are unnecessary.
- melling 13y ago
davexunit 13y ago
Jao is awesome. He is the author of Geiser, an Emacs mode like SLIME for GNU Guile and Racket. Geiser is an invaluable tool when working with Scheme. Best of luck to him.
sklivvz1971 13y ago
Language choice is mostly a reliability, sustainability, maintainability and team-scalability issue. I agree that people can learn, bugs in the language can be fixed, lack of libraries can be worked around and unknown pattern space can be navigated. As with any choice this is a trade off, in this case between time and convenience. Those ugly C-like languages have tons of cheap or free libraries, support communities with real, large scale experience and so on. Smaller languages are much more of an adventure - fun with company (your own?) money. It is not the correct choice in many cases. None of these problems seems to matter in the beginning, when the team is small and awesome, but they do massively matter later on. The author seems to completely avoid this point, and I urge them to consider it. Finally, having always been a deeply language agnostic developer, I find all these language-religious arguments to be a bit childish and tiresome.
- wiml 13y ago
  > Language choice is mostly a reliability, sustainability, maintainability and team-scalability issue Yes, but aside from that, Mrs Lincoln, how was the play?
educating 13y ago
> Deep down, the people in charge either didn’t think languages make any difference or, worse, bought into the silly “availability of programmers” argument. I’m still surprised anyone would believe such a thing. If i guy came telling me that he wanted to program only in, say, Java because that’s what he knows best and that he doesn’t really feel prepared or interested in learning and using, say, Clojure (or any other language, really), i wouldn’t hire him in a million years, no matter what language my project were using, and no matter how many thousands of candidates like this one i had at my disposal. The problem is not willingness to learn, the problem is the risk of going into a job, becoming less fluent in a language for which there are more job opportunities, and then being able to get paid as much or more with the new skills they learned. I am very interested in learning Clojure, Scheme, Lisp. But, these languages do not provide job security unless I want to move. Companies want .Net (C# or VB), Java, and JavaScript- w/ other various associated frameworks and libraries. So I have little incentive to opt to use Lisp at work, even if given the opportunity. I was a long time Java developer, but have been using Ruby for the past several years. It is really not as easy to find Ruby jobs locally as it is in Java or .Net, but I think it will be worth it because the # of Ruby jobs is growing. I don't see that for Clojure, though I really do wish it well. For a language to gain in the job market have, it doesn't need to be the best, it has to be fun, easy, and safe enough to use for the ecosystem to grow around it. C++ was more fun than Fortran/Cobol. Java was more fun than C++/.Net was more fun than Visual C++. Groovy, JavaScript, Python and Ruby are more fun than Java. PhP was more fun than HTML + CGI. Ruby/Rails is more fun than PhP. Note: when I say "fun" I don't mean it in the "challenging" sense of fun like Haskell. I mean writing great, cool things quickly and understanding it easily.
- mgkimsal 13y ago
  You nailed it. Company X chooses... ocaml, in this case. Someone taking a job there either needs to know it already, or have a 'willingness to learn'. OK - I'm willing to learn it, but at what expense? I dig in to ocaml for a few years, get really good at it, and find, say, 4 years from now, that the market for ocaml developers is really bad. I've gambled and lost, even if it "paid off" for the company. Most developers are making rather rational choices, regardless of what tech company founders would like to think. I do run in to people who are ".net or die" and "java for everything", and they'll never ever consider bothering to learn a new tech stack. And... they chose wisely enough that they may not have to over the next 10-15 years - almost anything you'll want or need to do for a large majority of computing/development needs will probably have .net/java equivalents (whether they're the best implementations or not is irrelevant to these people). But... choosing Haskell as a sole focus... they may end up having to uproot a family to move to another location to get another equivalent Haskell job in a few years, which most people don't want to have to do.
gnuvince 13y ago
People who are nervous about hiring people in a relatively unpopular language should watch this video[1] at the 1:01.00 mark by Yaron Minsky. [1] http://www.youtube.com/watch?v=hKcOkWzj0_s http://www.youtube.com/watch?v=hKcOkWzj0_s
- Cyranix 13y ago
  Imprecise transcript: Q: Are you convinced that you're more successful because of OCaml? A: <jokingly> I certainly have job security! But seriously, I think the answer is yes, for many reasons that are difficult to tease apart. One of the big reasons is that it became easier to hire great programmers. We hired many great programmers before we switched to OCaml (and they have since adopted OCaml) but it took more effort to find them than it took to find great functional programmers. It's hard to describe how significant the effect was, but I believe it was important; our language choice impacted our tools and results in a positive way.
  - gnuvince 13y ago
    Oops, that's not the passage I was thinking of. I'll try to find it again, but basically he says that when they needed to hire programmers, instead of using a site like monster.com or jobboom.com, they went on the OCaml mailing lists, posted the offer there. They got a few responses (~15 I believe?) and of those, 10 were worth a phone interview and 5 were worth flying in to NYC for a face-to-face interview. I think they ended up hiring 2 or 3 of those candidates. He described the process as being very easy because 1) OCaml programmers are interested in working with OCaml, 2) the typical OCaml programmer is better (or at least more curious) than the average programmer, because they went ahead and learned a relatively unpopular language that's unlikely to help them get a job in 99.9% of workplaces.
sramsay 13y ago
"I also think that Clojure is particularly enjoyable, elegant and beautiful, while at the same time extremely practical, easy to learn, and well suited to modern application development; it is the best designed programming language I have encountered in my almost-two-decades-long programming career . . ." I am absolutely with you there, but after writing a reasonably serious, production-level system in Clojure, I suddenly realized a fatal flaw in this and in many other hip and cool languages. It is very, very difficult to write clear, readable code. I accept that it might just be my lack of skill, but as the stuff I was writing became more complicated, I found myself writing the Lord's prayer on the head of a pin more and more. In the end, I started to actually long for a language that had fewer language features -- something that allowed far, far less flexibility in the way ideas are expressed. C is far from perfect, but more and more I see the wisdom of one of the early statements in the K&R in which they say that figuring out what to remove is part of the art of creating programming languages (or something like that). There's no language in which you can't write unreadable gibberish, granted, but some of these newer languages make it damn hard to write non-trivial programs that are easily read by others.
- ww520 13y ago
  Amen. People often don't realize we read code far far more than we write code.
- tikhonj 13y ago
  C has quite a few features, and the language design is pretty arbitrary. (Yes, it's often based on (old) hardware, but then hardware design is pretty arbitrary.) I haven't used Clojure much, so I'll mostly talk about Scheme. I suspect the two are similar in all important ways. If you look at the matter critically, you'll find that Scheme (and, I suspect, Clojure) are actually simpler and smaller languages than C. Neither has nearly as much syntax. There is far less undefined behavior. C has way more corner cases than Scheme: there are a ton of C quizzes out there which basically nobody can solve; I couldn't imagine much of that for Scheme. You just have to memorize the relatively obscure rules for what types get automatically coerced to each other. C has whole classes of hard-to-solve bugs that other languages simply do not. Bus errors, segmentation faults, buffer overflows... All the exposed low-level details obscure the meaning of the code; unless they're important to your application, they just make your code harder to follow. Moreover, common C idioms (some of which are just workarounds for missing features) make code much harder to follow than it should be. Thanks to the use of out parameters, you never really know where the result from a function is, without reading the documentation. I recently wrote some code that depended on ioctl--that single function sometimes returned the result as the return value and sometimes modified fields inside the struct you passed into it! Hard to follow is an understatement. Errors are signalled as integers instead of some semantically meaningful data type. Of all the languages I know, C is the one that makes it the hardest to write non-trivial programs that are easily read by others. I suspect you're just making the common mistake of confusing familiarity for some sort of innate quality.
nemesisj 13y ago
"...and was finally in a position to really influence our development decisions at every level. Even at the most sensitive of them all: language choice" When people say that "programming language doesn't matter", they mean it doesn't matter within the broader context of the company. And they're right. Language choice is never the key to success for the reason for failure that we in the tech field might wish it was. Yes, it'll matter to programmers to some extent, but just like the author talks about how quality programmers will be open to new language choices, those same programmers will be open to getting things done, regardless of language. Fixating on a programming language choice is premature (and worse, even irrelevant) optimisation for a whole host of problems that just don't affect a startup's success that much. Things like finding the best people, getting customers, and scaling will always be the harder, more critical aspects of running a successful company.
hnha 13y ago
oh come on mods. this was well titled. you removed the mention of lisp, leaving the title as guesswork about the contents. there is no rule for keeping original titles. please don't butcher them when someone actually adjusted them well.
microcolonel 13y ago
I think he's hit the supply nail right on the head. Programmers which are more costly are more productive(as a general rule), so finding a few highly-productive professionals willing to make the right decisions, is better than hiring a gaggle of newborns who figure public static is the only way to initialize data.
derefr 13y ago
> Give me programmers willing to learn and eager to use Lisp or Haskell (or Erlang, ML, OCaml, Smalltalk, Factor, Scala...) any day, even if we happen to be using C++, for goodness sake! Those are the ones one needs, scanty as they might be. Does anyone hire with "eager to learn new languages" as a criterion? It'd be interesting to come up with a technical interview that would test for that. Maybe it'd go something like: "Okay, I trust you got the email yesterday with the syntax of the three languages we made up for the purposes of this test--Blub, Cruft, and Wheeze? Good. Now, we want you to code A* in Blub, and then translate this code sample from Cruft to Wheeze. You've got a half-hour."
brianpgordon 13y ago
> If i guy came telling me that he wanted to program only in, say, Java because that’s what he knows best and that he doesn’t really feel prepared or interested in learning and using, say, Clojure (or any other language, really), i wouldn’t hire him in a million years Between JSF, JSP, JMS, JPA, JTA, JCA, JMX, JNA, servlets, SecurityManager, AWT/Swing, and countless other frameworks and technologies, Java is so big that it would take an entire career to become an expert. I think it's reasonable for someone who has invested a lot of their career in getting experience in some of these things to want to continue working in Java rather than let those skills go fallow.

134 points by momo-reina 13y ago

Jao's old blog[1] is a treasure trove of information. Modern Lisp hackers like him, Zach Beane and Edi Weitz are great representatives for the Lisp community: incredibly talented and yet very humble and more than willing to help out those just starting out in Lisp. [1] http://programming-musings.org/ http://programming-musings.org/

mynameisme 13y ago

Saying Clojure is a counter example kinda ignores the big reason companies don't want to use Lisp/Haskell/etc. When you're on the JVM, you get to use that gigantic collection of Java libraries and Java community for almost no downside. With Common Lisp/Scheme, so much time is spent reinventing wheels due to smaller communities that they're not worth using for larger projects, in my opinion. Also with Clojure, you always fairly easily port to Java if you decide things aren't going as planned a couple of years down the line, as CodeHaus did with Scala. Don't get me wrong, I think Clojure is by far the best Lisp to choose out there for a product, but that's mainly because it has its big "Java ogre" brother standing behind it. edit: And also, you don't need to write Java in a factories on top of factories style just because some choose to do that. The same is even more true of xml configuration.

lalc 13y ago
I have to admit I'm ignorant as to what Java libraries I'm missing out on by not using a JVM language. I hear about this advantage a lot though! What are some examples of good Java libraries that aren't as good in other common languages?
- elbear 13y ago
  If you're using another "common" language, you're probably not missing out on anything. The distinction he was making was between Java and a "not common" language, like Common Lisp, for example.
- threeseed 13y ago
  The best Java libraries from my perspective are the ones for large scale projects. You can leverage proven techniques and technologies. e.g. http://twitter.github.io http://twitter.github.io or http://netflix.github.io http://netflix.github.io
  - Derbasti 13y ago
    Is it a syntax error to talk Java without playing buzzword bingo? "Leverage proven techniques and technologies"? What does that even mean?
    - threeseed 13y ago
      What do you mean what does it mean ? Leverage = take advantage of Proven = demonstrated to have worked Techniques = using one approach versus another Technologies = existing code
      - Derbasti 13y ago
        Right..... So you're saying that your code works? Like, it doesn't crash? That's... awesome... Buzzword bingo does not add value. It only obscures meaning. Of course your code works. Of course you use existing technologies. That work. In existing code. That you leveraged. Using techniques. And technologies. Jesus, I hate this kind of language.
        Drakim 13y ago
        Java does seem to have some sort of strange connection to the business world (which just can't get enough of buzzwords).
        roblev 13y ago
        I think the OP's point was clear, Java has a big library of tested, debugged, robust libraries.
        hughw 13y ago
        He wasn't saying that his code doesn't crash. He was saying many other people have contributed java libraries his programs can use, so that he doesn't have to hire an expert in HTTP, or computational geometry, or many problem domains that aren't the direct concern of his application, yet are necessary for it to work. He said it in a compact way. It's a form of compression.
- amouat 13y ago
  I think the point is that most of the time when you think "I need something that does x", there is a library for that; whether it is a core library or not. In Lisp I guess you often find something very specific that doesn't quite solve the problem you have. Having said that, I really liked the Google Guava library, although a good bit of that stuff is working around or solving problems with Java itself. https://code.google.com/p/guava-libraries/ https://code.google.com/p/guava-libraries/
  - trimbo 13y ago
    Guava is fantastic. So many times in the last few years, I've pointed people to Guava in code reviews "hey, this thing you just wrote, Guava already has that."
- jbrechtel 13y ago
  Natural Language Processing libraries https://opennlp.apache.org/ https://opennlp.apache.org/ http://nlp.stanford.edu/ http://nlp.stanford.edu/ Cloud provider automation libraries http://jclouds.incubator.apache.org/ http://jclouds.incubator.apache.org/ Distributed stream computing https://incubator.apache.org/s4/ https://incubator.apache.org/s4/ Asynchronous event driven IO, battle tested, mother recommended http://netty.io/ http://netty.io/ In-process webserver http://www.eclipse.org/jetty/ http://www.eclipse.org/jetty/ ....to name a few. It's probably useful to take some thing that you'll need and look in ecosystem X for it (say... .NET) and then compare what's available there to what's available on the JVM. In my experience, the JVM wins out almost every time when it comes to number of options and maturity of options.
616c 13y ago
Wish I could up this one more. I am in the process of playing with Lisp (in my case, Common Lisp, the SBCL variant to be specific) and I would love to see people with production services in any Lisp, or even Scheme. I have been very attracted to the idea of Lisp, specifically as I discovered teepeedee and teepeedee2 as being some of the first truly fast web servers [0], and now I found wookie,[1] an evented web server running on top of libevent. I really want to play with that. The closest thing I know of to people running "prod services on Lisp" are the Untyped guys in the Racket Scheme community [2], and not much else. I know pg and company became famous on Viaweb and Lisp, but since then there are scarce examples. However, the amount of bitching libraries and cool books (pg's book included) make me want to buck the trend and do it anyway, even if no one watches and I end up in my own ditch writing code to dig my way out for the all the unstable or non-existent pieces of code waiting for me. [0] https://github.com/vii/teepeedee2 https://github.com/vii/teepeedee2 [1] https://github.com/orthecreedence/wookie/ https://github.com/orthecreedence/wookie/ [2] https://github.com/untyped https://github.com/untyped
- momo-reina 13y ago
  Without mentioning the usual Emacs, AutoCad(AutoLISP), and ITA: [0] Google App Inventor http://googleresearch.blogspot.com/2009/08/under-hood-of-app-inventor-for-android.html http://googleresearch.blogspot.com/2009/08/under-hood-of-app... [1] Quickdocs is written in Lisp http://quickdocs.org/ http://quickdocs.org/ [2] Jak and Daxter http://www.gamasutra.com/view/feature/2985/postmortem_naughty_dogs_jak_and_.php http://www.gamasutra.com/view/feature/2985/postmortem_naught... [3] Maxima http://maxima.sourceforge.net/ http://maxima.sourceforge.net/ [4] Prime Trader (Lisp Works) http://www.lispworks.com/success-stories/netfonds-primetrader.html http://www.lispworks.com/success-stories/netfonds-primetrade... [5] Franz success stories http://www.franz.com/success/ http://www.franz.com/success/
  - 616c 13y ago
    Thanks for the list (pun kind of intended). I am well aware of Emacs (who does Lisp without SLIME, that seems painful) and Autocad. Your list is very cool, but I meant people writing production web services and startups that are often featured here. Of them all, the most interesting one I saw a month or so ago was someone writing production services in Haskell. That generated a lot of interest, and I have not heard of anyone brave enough to do it with a Lisp, save Clojure. I was unaware of Jak and Daxter, but I would hope people who use Common Lisp, manage their packages in Quicklisp, and do other CL stuff know what Quickdocs. I am in that camp. :-)
klibertp 13y ago
> With Common Lisp/Scheme, so much time is spent reinventing wheels due to smaller communities I'm not sure, but I think that C and C++ ecosystem has at least the same amount of libraries available as Java. And the reason why I mention this is that many Lisps have FFI which makes integrating those libraries almost seamless. Aside from Gambit-C, which compiles Scheme code to C and so supports inline C code, for example Racket has very nice DSSL for FFI, which reduces the need for glue code to one or two lines of code per imported function. Integration with native Java libraries is easier from JVM languages, of course, but then there are many Lisps for JVM too. And for CLR, where tail call elimination exists. So if you want to write in Lisp, but are worried about lack of libraries, you really have many options. Clojure is alright, but saying that it's the only choice if you need access to libraries is not quite true.
- coolsunglasses 13y ago
  >I'm not sure, but I think that C and C++ ecosystem has at least the same amount of libraries available as Java. Uh, no. Not for the kind of applications and systems that get built these days.
LanceH 13y ago
That doesn't explain the original adoption of Java, though. Put a billion dollars of marketing into Clojure and see where that gets you. Just the marketing effort alone. Do you guys remember all the managers, directors, secretaries taking Java courses because it was going to change everything? Java rode a big wave of stupid that was the internet boom.

pron 13y ago

Far be it from me to say that the choice of programming language doesn't matter, or that picking one slightly off the trodden path is not a sign of a certain openness of mind. I also think that Clojure is particularly enjoyable, elegant and beautiful, while at the same time extremely practical, easy to learn, and well suited to modern application development; it is the best designed programming language I have encountered in my almost-two-decades-long programming career (with Julia giving it a run for its money if only it had been implemented on top of the JVM as well). However, I've seen a clear inverse correlation between the magnitude of technical challenge and the emphasis on the choice of programming language. It is usually web application developers that spend the time and effort picking what they deem to be a modern, or "more productive" programming language. It is as it should be, because most productive languages, Clojure included, are usually more productive for applications – not complex basic algorithms, or the development of novel data structures. Application developers spend 90% or more of their time writing and debugging production code, so they'd better spend some time picking and learning a language that makes their work easier. But people in the fields of computer vision, artificial intelligence, machine learning, concurrent data-structures and others – very smart, very forward thinking people – would pick Java or C/C++ nine times out of ten, and not only because these languages are better suited to their task performance-wise, but because they have other, more important things to think about. If your challenge is not translating a business model into code, but solving a real algorithmic or technical problem, then the programming language really doesn't matter, and you're better off sticking with the one(s) you know best. If 95% of your time is spent thinking anyway, it doesn't matter if your language can reduce the remaining 5% of actual development by a factor of two or more. IBM's Watson would not have come about sooner if its engineers had chosen Haskell over Java. ADD.: "Productive" programming language are better when you need to solve the same problem over and over (say retrieve data from a database and generate HTML). But when your problem is more or less one-of-a-kind, these productivity boosts either disappear or don't matter. When you're handcrafting a magnificent chair, picking the best assembly line is irrelevant. Chances are it's been designed to solve other problems and retrofitting it to your requirements is extra work, and even if it wasn't, this chair need only be made once. Mass production tools are unnecessary.

melling 13y ago

davexunit 13y ago

Jao is awesome. He is the author of Geiser, an Emacs mode like SLIME for GNU Guile and Racket. Geiser is an invaluable tool when working with Scheme. Best of luck to him.

sklivvz1971 13y ago

Language choice is mostly a reliability, sustainability, maintainability and team-scalability issue. I agree that people can learn, bugs in the language can be fixed, lack of libraries can be worked around and unknown pattern space can be navigated. As with any choice this is a trade off, in this case between time and convenience. Those ugly C-like languages have tons of cheap or free libraries, support communities with real, large scale experience and so on. Smaller languages are much more of an adventure - fun with company (your own?) money. It is not the correct choice in many cases. None of these problems seems to matter in the beginning, when the team is small and awesome, but they do massively matter later on. The author seems to completely avoid this point, and I urge them to consider it. Finally, having always been a deeply language agnostic developer, I find all these language-religious arguments to be a bit childish and tiresome.

wiml 13y ago
> Language choice is mostly a reliability, sustainability, maintainability and team-scalability issue Yes, but aside from that, Mrs Lincoln, how was the play?

educating 13y ago

> Deep down, the people in charge either didn’t think languages make any difference or, worse, bought into the silly “availability of programmers” argument. I’m still surprised anyone would believe such a thing. If i guy came telling me that he wanted to program only in, say, Java because that’s what he knows best and that he doesn’t really feel prepared or interested in learning and using, say, Clojure (or any other language, really), i wouldn’t hire him in a million years, no matter what language my project were using, and no matter how many thousands of candidates like this one i had at my disposal. The problem is not willingness to learn, the problem is the risk of going into a job, becoming less fluent in a language for which there are more job opportunities, and then being able to get paid as much or more with the new skills they learned. I am very interested in learning Clojure, Scheme, Lisp. But, these languages do not provide job security unless I want to move. Companies want .Net (C# or VB), Java, and JavaScript- w/ other various associated frameworks and libraries. So I have little incentive to opt to use Lisp at work, even if given the opportunity. I was a long time Java developer, but have been using Ruby for the past several years. It is really not as easy to find Ruby jobs locally as it is in Java or .Net, but I think it will be worth it because the # of Ruby jobs is growing. I don't see that for Clojure, though I really do wish it well. For a language to gain in the job market have, it doesn't need to be the best, it has to be fun, easy, and safe enough to use for the ecosystem to grow around it. C++ was more fun than Fortran/Cobol. Java was more fun than C++/.Net was more fun than Visual C++. Groovy, JavaScript, Python and Ruby are more fun than Java. PhP was more fun than HTML + CGI. Ruby/Rails is more fun than PhP. Note: when I say "fun" I don't mean it in the "challenging" sense of fun like Haskell. I mean writing great, cool things quickly and understanding it easily.

mgkimsal 13y ago
You nailed it. Company X chooses... ocaml, in this case. Someone taking a job there either needs to know it already, or have a 'willingness to learn'. OK - I'm willing to learn it, but at what expense? I dig in to ocaml for a few years, get really good at it, and find, say, 4 years from now, that the market for ocaml developers is really bad. I've gambled and lost, even if it "paid off" for the company. Most developers are making rather rational choices, regardless of what tech company founders would like to think. I do run in to people who are ".net or die" and "java for everything", and they'll never ever consider bothering to learn a new tech stack. And... they chose wisely enough that they may not have to over the next 10-15 years - almost anything you'll want or need to do for a large majority of computing/development needs will probably have .net/java equivalents (whether they're the best implementations or not is irrelevant to these people). But... choosing Haskell as a sole focus... they may end up having to uproot a family to move to another location to get another equivalent Haskell job in a few years, which most people don't want to have to do.

gnuvince 13y ago

People who are nervous about hiring people in a relatively unpopular language should watch this video[1] at the 1:01.00 mark by Yaron Minsky. [1] http://www.youtube.com/watch?v=hKcOkWzj0_s http://www.youtube.com/watch?v=hKcOkWzj0_s

Cyranix 13y ago
Imprecise transcript: Q: Are you convinced that you're more successful because of OCaml? A: <jokingly> I certainly have job security! But seriously, I think the answer is yes, for many reasons that are difficult to tease apart. One of the big reasons is that it became easier to hire great programmers. We hired many great programmers before we switched to OCaml (and they have since adopted OCaml) but it took more effort to find them than it took to find great functional programmers. It's hard to describe how significant the effect was, but I believe it was important; our language choice impacted our tools and results in a positive way.
- gnuvince 13y ago
  Oops, that's not the passage I was thinking of. I'll try to find it again, but basically he says that when they needed to hire programmers, instead of using a site like monster.com or jobboom.com, they went on the OCaml mailing lists, posted the offer there. They got a few responses (~15 I believe?) and of those, 10 were worth a phone interview and 5 were worth flying in to NYC for a face-to-face interview. I think they ended up hiring 2 or 3 of those candidates. He described the process as being very easy because 1) OCaml programmers are interested in working with OCaml, 2) the typical OCaml programmer is better (or at least more curious) than the average programmer, because they went ahead and learned a relatively unpopular language that's unlikely to help them get a job in 99.9% of workplaces.

sramsay 13y ago

"I also think that Clojure is particularly enjoyable, elegant and beautiful, while at the same time extremely practical, easy to learn, and well suited to modern application development; it is the best designed programming language I have encountered in my almost-two-decades-long programming career . . ." I am absolutely with you there, but after writing a reasonably serious, production-level system in Clojure, I suddenly realized a fatal flaw in this and in many other hip and cool languages. It is very, very difficult to write clear, readable code. I accept that it might just be my lack of skill, but as the stuff I was writing became more complicated, I found myself writing the Lord's prayer on the head of a pin more and more. In the end, I started to actually long for a language that had fewer language features -- something that allowed far, far less flexibility in the way ideas are expressed. C is far from perfect, but more and more I see the wisdom of one of the early statements in the K&R in which they say that figuring out what to remove is part of the art of creating programming languages (or something like that). There's no language in which you can't write unreadable gibberish, granted, but some of these newer languages make it damn hard to write non-trivial programs that are easily read by others.

ww520 13y ago
Amen. People often don't realize we read code far far more than we write code.
tikhonj 13y ago
C has quite a few features, and the language design is pretty arbitrary. (Yes, it's often based on (old) hardware, but then hardware design is pretty arbitrary.) I haven't used Clojure much, so I'll mostly talk about Scheme. I suspect the two are similar in all important ways. If you look at the matter critically, you'll find that Scheme (and, I suspect, Clojure) are actually simpler and smaller languages than C. Neither has nearly as much syntax. There is far less undefined behavior. C has way more corner cases than Scheme: there are a ton of C quizzes out there which basically nobody can solve; I couldn't imagine much of that for Scheme. You just have to memorize the relatively obscure rules for what types get automatically coerced to each other. C has whole classes of hard-to-solve bugs that other languages simply do not. Bus errors, segmentation faults, buffer overflows... All the exposed low-level details obscure the meaning of the code; unless they're important to your application, they just make your code harder to follow. Moreover, common C idioms (some of which are just workarounds for missing features) make code much harder to follow than it should be. Thanks to the use of out parameters, you never really know where the result from a function is, without reading the documentation. I recently wrote some code that depended on ioctl--that single function sometimes returned the result as the return value and sometimes modified fields inside the struct you passed into it! Hard to follow is an understatement. Errors are signalled as integers instead of some semantically meaningful data type. Of all the languages I know, C is the one that makes it the hardest to write non-trivial programs that are easily read by others. I suspect you're just making the common mistake of confusing familiarity for some sort of innate quality.

nemesisj 13y ago

"...and was finally in a position to really influence our development decisions at every level. Even at the most sensitive of them all: language choice" When people say that "programming language doesn't matter", they mean it doesn't matter within the broader context of the company. And they're right. Language choice is never the key to success for the reason for failure that we in the tech field might wish it was. Yes, it'll matter to programmers to some extent, but just like the author talks about how quality programmers will be open to new language choices, those same programmers will be open to getting things done, regardless of language. Fixating on a programming language choice is premature (and worse, even irrelevant) optimisation for a whole host of problems that just don't affect a startup's success that much. Things like finding the best people, getting customers, and scaling will always be the harder, more critical aspects of running a successful company.

hnha 13y ago

oh come on mods. this was well titled. you removed the mention of lisp, leaving the title as guesswork about the contents. there is no rule for keeping original titles. please don't butcher them when someone actually adjusted them well.

microcolonel 13y ago

I think he's hit the supply nail right on the head. Programmers which are more costly are more productive(as a general rule), so finding a few highly-productive professionals willing to make the right decisions, is better than hiring a gaggle of newborns who figure public static is the only way to initialize data.

derefr 13y ago

> Give me programmers willing to learn and eager to use Lisp or Haskell (or Erlang, ML, OCaml, Smalltalk, Factor, Scala...) any day, even if we happen to be using C++, for goodness sake! Those are the ones one needs, scanty as they might be. Does anyone hire with "eager to learn new languages" as a criterion? It'd be interesting to come up with a technical interview that would test for that. Maybe it'd go something like: "Okay, I trust you got the email yesterday with the syntax of the three languages we made up for the purposes of this test--Blub, Cruft, and Wheeze? Good. Now, we want you to code A* in Blub, and then translate this code sample from Cruft to Wheeze. You've got a half-hour."

brianpgordon 13y ago

> If i guy came telling me that he wanted to program only in, say, Java because that’s what he knows best and that he doesn’t really feel prepared or interested in learning and using, say, Clojure (or any other language, really), i wouldn’t hire him in a million years Between JSF, JSP, JMS, JPA, JTA, JCA, JMX, JNA, servlets, SecurityManager, AWT/Swing, and countless other frameworks and technologies, Java is so big that it would take an entire career to become an expert. I think it's reasonable for someone who has invested a lot of their career in getting experience in some of these things to want to continue working in Java rather than let those skills go fallow.