Hacker Newsnew | comments | show | ask | jobs | submit | pavelludiq's comments login

Yes, abandon something that's been making money for 30 years and throw away decades of domain expertise because it's not fashionable. Great idea.

Not that clojure is a bad language(I actually like it quite a bit), but compared to the professional common lisp world, it's a baby. CL has an extremely high-quality and stable specification, dozens of very good implementations for pretty much every platform(whit several ones that are decades old, and several ones that are brand new), a community that simply refuses to die, and use cases where clojure would be completely inadequate. Not to mention the assertion that non-clojure lisps are not going anywhere is completely false, both common lisp and racket(hell, even elisp) are growing in their niches and developing their ecosystems. Books and libraries are being written, products are being developed, conferences and meetups are organized, businesses are started and research is being done.


With zero snark, because I've never had the (apparent) pleasure of working with a lisp, what are the use cases for Common Lisp? It barely registers when talking about building APIs and production cloud platforms for game services, which is my current wheelhouse. Clojure comes up, of course...


A few cases I've seen CL used for:

1. Decision systems for stock and commodities trading.

2. Flight scheduling and flight price optimization.

3. Social network analysis and advertising impact analysis.

What all of these problems have in common is that they involve crunching a fuckton (the technical term) of data, sometimes in real time, and making decisions based on it. Some of the problems are NP complete and use genetic algorithms and other techniques to approximate ideal solutions. These are extremely hard problems.

It's also worth noting that many of these systems were started in the 80s and 90s and encode a lot of research and business logic which simply isn't yet available elsewhere.

I'd love to work on one of these systems, but unfortunately I've only been working in industry a mere decade and the competition in that area has mostly 2-3 times that level of experience.


Specific domains where clojure might not do so well are probably the same domains where the JVM is impractical, for example embedded or low-level programming, anything where you have to interact heavily with the world outside of the JVM and have a small footprint.

Obviously mobile looks like an area where common lisp has better options(with this announcement that makes two commercial implementations, the other one being mocl: https://wukix.com/mocl).

How about crazy experimental operating systems? https://github.com/froggey/Mezzano

If you want to write native(non-swing) guis LispWorks has that covered, and the open source gtk/qt bindings, while a bit unlispy work very well. Racket has a pretty cool framework too.

There is also the fact that a lot of programmers, rationally, or irrationally, simply dislike the JVM. Pretty much everything I dislike about clojure has more to do with the JVM than the core design itself.

Both lispworks and franz maintain success lists, so you can look at some of these projects if you want to see some areas where lisp has done fine:

http://www.lispworks.com/success-stories/index.html http://franz.com/success/


My understanding (as a Lisp beginner but with 15+ years commercial development experience) is that Common Lisp has more powerful macro systems, better tooling and better error handling. Some commercial Common Lisp implementations are also known for good, portable GUI frameworks.

Clojure has better support for concurrency, very good JVM integration, and a better story around Javascript courtesy Clojurescript (vs. Common Lisp's parenscript).

While some people seem quite strongly averse to Clojure (see e.g. http://www.loper-os.org/?p=42) my opinion - again, that of a Lisp beginner - is that they both have their uses.

It's certainly possible to build web front-ends and API-based back-ends using Common Lisp. I know because I'm doing it now :)


Common Lisp hits some kind of sweet spot for developing very specialized software. If you think you need to build huge specialized software framework or special programming language from ground up to start solving the problem, you might need Common Lisp.

Common Lisp is very programmable language that can still deliver decent speed.





So that's several variants of lisp, as well as fortran, c, pascal, prolog and ada. Thats pretty much most of the languages in use in the 80s.


My favorite example would have to be CLOS the Common Lisp object system. Although it's a bit hairy in certain places, it essentially transforms a procedural/functional language into on of the most powerful object oriented languages around. Macros play a small, but crucial part of it, subverting the rules of lisp in order to add another dimension to the language.

Another great example might be Postmodern and CLSQL, both of which include SQL DSLs, much better than concatinating strings or muddling around with ORMs. CL's loop macro basically ads an algol like language to lisp(if you dislike loop, there exist lispier alternatives like iterate).

Macros take care of the case between writing a function and writing an interpreter, and with judicious use, they can help build much cleaner abstractions that give a qualitative improvement to a code base.


As a lisper, I can say that this insight is very true, but it is still just a simplification. Most lisps deal with it in different ways.

In the scheme world, the way they deal with this is by wasting a decade on making decisions about the language that should have been done in the 80s. The result is that scheme essentially split into scheme and racket. Now we have an awesome language and a nice little ecosystem thats good for teaching and research, and possibly even real work(tm). Classic scheme unfortunately is fragmented into implementations who all do things slightly differently and occupy their own niches.

In the clojure world, they have a) a BDFL who sets the course of the language. b) A very strong core community of very smart people who managed to build a nice culture based on common ideas about software and design.

In the common lisp world, because we have a very high-quality standard, implementations are almost completely compatible. Compatibility libraries make it easy to write very portable code, avoiding the scheme problem. At the same time implementations are free to experiment. The other problem of everybody developing their own little universe tends to be rare. Because common lisp is so old, we have a long history and traditions that guide future design, but don't constrict it. There is a subtle balance here. We have a lot of old examples to learn from, but we are not locked in by too many bad old decisions(not always the case, but good enough in practice).

A few examples where this does not work include utility libraries and things like json libraries, libraries for outputing html etc. Since we don't have a BDFL we are left to figure things out amongst our selves and sometimes, like with utility libraries(there are dozens such, which is ridiculus) it doesn't work. In other cases, it works very well, for example quicklisp, ASDF, bordeaux-threads, closer-mop, hunchentoot etc. are either de-facto standards, or sufficiently popular to be a very good default. As with clojure, there are a lot of common ideas about what is good design in the community, we have a lot of examples to learn from, as I mentioned.

In the end, at least in the case of common lisp and clojure, I see it as an advantage to have this "level of possible diversity", it's what has kept lisp alive for 50+ years! The fact that lisp can adopt to each new era of software development philosophy is a great reason to study it. It will be with us for many more decades because of this.


At this point we can safely say that any programming language will be with us for many decades. Cobol (http://en.wikipedia.org/wiki/Cobol#COBOL_20XX), Fortran (http://en.wikipedia.org/wiki/Fortran#Fortran_2015), Basic (http://en.wikipedia.org/wiki/Visual_Basic_.NET#2013_.28VB_12...) are still evolving. Heck, Python is already 23 years old and I don't see it going anywhere. I'm not even going to talk about the ubiquitous C/C++ or Java, as they'll probably be around long after we're dead.

Adaption is neat, but I don't see this argument as being a very solid argument in favor of Lisp - it's just the norm.


I think you're just conveniently forgetting all the languages that didn't go anywhere. https://en.wikipedia.org/wiki/Timeline_of_programming_langua...


To me, "almost completely compatible" sounds similar to "just a tiny bit pregnant". In practice, either it is compatible, or it isn't.


Show me a language with >1 implementation where at least two are completely compatible. Common Lisp has one of the best track records in this aspect. C, C++ and JavaScript are all far worse.


Not necessarily.

Java 6 and 7 are "almost completely compatible".

Most programs written in Java 6 will run in Java 7, and vice versa. But not all.


C++ is similar with regards to C code. They're compatible enough that a lot of people will write "C/C++", but they're still incompatible enough that you'll get yelled at by a lot of people if you write "C/C++".


Geiser is great, but SLIME is much better mostly because Common Lisp was designed with interactive programming in mind(the condition system, the object system, dynamic variables ect. are all features that help with interactive programming). You get an almost smalltaskesque feeling with slime.


All the major lisp dialects are rather different and encourage different styles. My own opinion is that no one is a better first lisp, as long as you check out the others eventually. Racket is an excellent start. I always advise people interested in lisp to check out racket, clojure and Common Lisp in whatever order they wish. I started with scheme in 2008, moved to clojure in 2009 and I've been a happy Common lisper since 2010/11. Depending on your own style as a programmer you might choose a different main dialect you like best, but only after you try them all :)

Happy Lisping!


History is weird that way. I recommend listening to Dan Carlin's Hardcore History series on the Mongols[1] where he talks about how historians often justify unspeakable horrors because in hindsight there are a lot of benefits to modern civilization. He balances it out by saying that the benefits don't look so good if you have to ask the people who actually have to pay the bill. Millions of Chinese, Muslims, Russians and Hungarians who actually had to pay for the benefits of Genghis Khans conquest would probably not see it as a good trade off to endure literally the end of the world.

He also talks about how sometime in the future, when the pain isn't as fresh as it is now, some historian will write a book about all the benefits of Hitlers regime, like they do for Caesar or Alexander(All butchers of similar caliber). But thats pretty much impossible currently because you need the historical distance from such hard topics.

[1] http://www.dancarlin.com/disp.php/hharchive It's caller "Wrath of the Khans" and is essentially an audio book, find a couple of free evenings and listen to it if you can handle hours and hours of horror. There are also a bunch of old episodes(only recent episodes are free) on WW2 that are definitely worth the money. The most recent series is on WW1, it's still unfinished, and in fact after many hours it's barely one month into the war, you need an entire mini-audio book to set up the context for an audio book on WW1, thats insane. Fans of history will become addicted to this podcast. BE WARNED!


The Mongols are an example where I don't see nearly as much upside. I admit I don't know much about their impact on China, but pre-Mongol Russia (Novgorod and Kiev) were quite democratic and free. The Mongols moved the seat of power to Moscow and installed authoritatian regimes, and Russia has always remained very autocratic ever since.

But even without that, of course we shouldn't go about causing terrible evil hoping some good will come of it. The Holocaust and everything Hitler did will always be terrible. It was the response to this evil, and the memory of it, that hopefully keeps driving us towards good for a long time to come. These are the lessons of history that we need to learn: that it's everybody's duty to ensure that this kind of evil can never happen again.


The mongol conquest was almost certainly a net negative for humanity(Baghdad recovered only in the 20th century as just one example). But the standard argument is that suddenly you had chinese culture spread to the west somewhat. Not to mention after all the killing was over, trade was more free and safe for a while. If you had the Khans permission to travel in the empire, you didn't have to worry too much about a random tribe looting your caravan. Mongols were also very tolerant of other religions as long as you submitted to their rule. Marco Polo probably wouldn't have made it to china without that region being "passified". The same argument could be used in the case of Alexander or Caesar or Napoleon. You could also say that the conquista was a good thing for the American continents, but that would depend on who you ask. This is a fairly complex topic well beyond my knowledge as a fan of history, not to mention I touched on a subject thats very sensitive to a huge portion of the population of the world. Most of us have ancestors who were conquered and few of us view it as a good thing.

In summary, humans did horrible things to each other, and we survived and endured, so now with the danger out of the way we can play these games, I don't wish to continue though. I've probably stepped on a few land mines with this comment already. The whole thread is a mine field. I wish everybody pleasant evenings with history books/podcasts.


I'll certainly give lighttable.el a try when somebody decides to write it :)


actually, it was javascript and the file contained:



Well, people do say Javascript is a Lisp in C clothes, and for a good reason. Well, for a bad reason too, as in this case.


I used to say that too until I read http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt...


It is not, but there are reasons some people say that. Keep in mind this is a posting about jokes. By the way, someone managed to downvote the parent -- what a strange reaction to a joke! Kind of sad, really.


(I'm not from the US)

My brain pattern matched it as two numbers that have some relationship with each other, but It didn't even occur to me that it was a date until I visited the page. If it was written 16/11 I might have gotten it(the bigger number on the left makes it unlikely that it's a ratio of some sort which is how I read it intuitively). But what if it was 5/11 or 11/5, still no idea what it means without context. If it said "on 11/16" I would get that it's a date, but it would still take me slightly more energy to figure out which is the month as I don't associate the right number with the day, but the opposite.

Keep in mind, if I look at it for more than 2 seconds I will figure it out, but if I need to spend more than a fraction of a second parsing a date, you have a UI problem.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact