I am (now) a lisp programmer and find myself boring many people to tears about it. But perhaps I am first a language guy, and like to see new solutions to problems. None give me the satisfaction that Lisp has (smalltalk was close, however). But I like to see new well-designed languages and how well, or not, they address the engineering challenges.<p>For example, turbo pascal was written during the time that I was writing a pascal compiler. The Pascal standard was truly a harsh mistress, and turbo pascal made a lot of very useful engineering choices to make a fast, very useful compiler in a small environment. Anders went on to do C#, which itself was a good engineering feat.<p>I watch with interest Clojure and the ecocsystem that it plugs into and it has a REPL.<p>But it is a pragmatic fact of life that C is a very large force in the day-to-day world, along with a tool used by serious hackers (c.f. Coders At Work).<p>Python is very nicely designed and gets you to a higher level of programming with ease.<p>So I was curious when Go came along, as a language development observer, to see what were they coming up with.<p>It is clearly a language that has had a lot of thought put into it and it seems to be something that will challenge C on its own turf ultimately. Faster than Python, and possibly ultimately approaching C in speed, it has some useful new ideas. In particular, how it does goroutines and channels is quite refreshing. It addresses the admonition that "threads won't work if they are just libraries" with new language constructs.<p>So criticism of language ought to be tempered by some experience with the language. Having done enough of them, it seems that I often don't have a full appreciation for a language until I have done something significant in that language. So I feel comfortable offering severe criticism of languages like RPG-III and Fortran II and Altair Basic and Bliss-36.<p>I am probably to the point of being a lisp snob by now, but do appreciate the finer points of other languages.<p>I think Go is a step in the right direction for the problem that it wants to solve.
> "Programming language quality is usually inversely proportional to the number of special forms"<p>Programming language obscurity is also usually inversely proportional to the number of special forms. Church numerals?<p>The happy place is somewhere in the middle, where there's enough language such that you don't have to build it out of other pieces - and this also helps with performance, static analysis, tooling, debugging and lots of other areas - but there isn't so much that you end up with lots of methods to do the same thing, in similar but incompatible ways.
"I could show these poor imperative programmers how their problems could be solved much easier in Lisp if I wanted to." That to me (as an outsider) seems to be the main message of these Lisp blogs. But at some point, nobody will believe you could do it, unless you actually do.
OTOH the Go authors made it clear that it's intended to replace C for the basic system programs & libs. I think that's step in the right direction.<p>I started to earn money using Erlang & Clojure, so looks like I'm not only fan of new exciting high-level langs but also quite an adopter of them in the so-called real world. Still there are some uses when a VM of your Chosen One language brings an unacceptable overhead. Imagine your daily work using vi, grep, find as they were compiled into jars and each running via JVM. Nightmare with that 2 seconds delay of starting each little proggy, isn't it? (Have you ever used the original Amazon's EC2 commandline tools written in Java? You'd know what I mean).<p>Of course it could be solved by some kind of injecting of program to be run to some VM already running, but that's not an established practice of working with basic programs in your system. At some level fast binaries are needed.<p>Personally I think it's a pity that some language of SML family didn't get to the mainsteam for such system programming. Haskell is fun and people write things like text editors and window managers in it; but is still perceived as too academic for real tasks which isn't completely true.
"Ugh, look at all that syntax."<p>As a common lisp programmer it's sad to see somebody do to another language what people do to CL. One superficial glance at the syntax and write it off, without further criticism.<p>"Lisp has a lot of brackets, LOL"
It seems you (as well as several other people) can only imagine a future with Haskell or Lisp syntax as if anything else is inferior. I find that to be foolish and immature.<p>Go was specifically designed to be a systems language, period. Lisp was never designed as so, and perhaps that is why its hardly used as a systems language today. Personally, I like Lisp, Haskell, and Python but I also know C is a great systems language even though its not perfect and its a bit passed its prime. Thus Go seems to be a good progression from the C/C++ family (I never really saw Java being a systems language but that's my opinion).<p>Anyway, I agree I think you're becoming a bit of a lisp snob. It might suit you to be a bit more open minded and objective. Even if you don't fully understand the design of Go, you should be able to understand that it was designed by people who have credible experience and skill in designing languages and systems. And sorry to spoil things for you, but the last thing I can imagine is Clojure being the next systems language.<p>Your post essentially is a brief comparison of a selection of fruits without much substance.<p>Lastly, here's a piece of advice:<p>"That's why I reserve the right to match the language to the problem, and even - often - to coordinate software written in several languages towards solving a single problem."
"Sigh. (Programming language quality is usually inversely proportional to the number of special forms.)"<p>I tend to agree with this, and I'm not a lisp fanatic.
Snob or not, what increasingly pulls me to languages are the highly productive DSLs that seem to fall out of them. For example, I need to deliver a few lightweight web apps/services - and I stumble across Sinatra on Ruby (with a little Sequel thrown in mixed with the oci8 oracle gem), which seems to do all I need. My little ruby code snippets look just like that - snippets that are short and expressive of the what I'm trying to do.<p>Lisp seems to be the "godfather" of these things and I'm more and more interested in what makes <i>me</i> productive, without being surrounded by a team of enterprise programmers and all the boilerplate that seems to fall out of other languages.<p>I make my living hacking SQL. What I'm really looking for there is the ability to create a lambda on the fly for custom grouping (eg implementing a business rule dynamically). I've worked on at least three big enterprise projects where I could have eliminated thousands, if not tens of thousands of LOC with a feature like that. Maybe I should punt and roll with a Prolog engine in the Lisp of choice. Who knows.<p>I really enjoy the articles and comments on these topics here on HN. Keep 'em coming.
If you're truly passionate about hacking it would be hard to avoid becoming a LISP snob at some point in your development. But if you're pragmatic, you'd be able to transfer what you've learned from LISP to other environments, that may be better suitable for today's technological landscape. Is Google Go the way to go? Only time will tell. But there's little you can usefully do with LISP these days (unless the scope of the program you're working on is so restricted that you really only need the language purely).
Go just strikes me as profoundly boring.<p>"Uh, we do lots of C. Yeah, and lots of Python. Dude. Let's make a language that's like, uh ... C <i>and</i> Python! Yes! Awesome."<p>In a world where the only thing harder than Haskell is Google's interview questions, you'd think they would've come up with something more original.