11 ms·

Lisp as an alternative to Java (2000)

156 points by azhenley 6y ago

demonshreder 6y ago
I have been using Clojure as a solo developer for about two years now, there is definitely a productivity increase. It always feels like the amount of time required to do the next thing is incrementally decreasing (like Ologn?) While all that is fun, Clojure is still a very enterprise ecosystem, where participants don't share as much elementary code as in Python ecosystem. Participants are also quite experienced, thus I have to sit, read through and make architectural decisions for the entirety of the project. When we add this thinking time into the measurement, the time taken for a Clojure 'project' (not a piece of code) is definitely more than Python or Java (IMO).
- stingraycharles 6y ago
  You mean the steep learning curve, and lack of “starter pack” type of frameworks (for lack of a better description) is holding you back being more productive with Clojure? I’ve been doing Clojure professionally for over 5 years now and it’s definitely a known issue that Clojure is very expert-friendly.
  - demonshreder 6y ago
    Getting a 'hang' of clojure as a language is quite easy, my colleague and I took only two weeks to jump into things. Even today, specific code development is order of times faster than we can do in Python. However, lack of general 'all-purpose' libraries for numerous use cases means we have to implement that API or library in a general way (if only for our use case) then integrate it into the system. This approach has worked quite well, creating our own template code (as everything is functional) helps reuse across many projects, however the initial investment of time/labour is something we would like to avoid for the sake of finishing the work fast.
    - thu2111 6y ago
      Are you counting Java libs as part of that ecosystem? It seems odd to describe the JVM as lacking all purpose libraries.
      - demonshreder 6y ago
        Java libs are definitely helpful, the time I mentioned includes wrapping Object oriented code into functions. This is easy if all that is required is one or two methods from the Java, however for more than immediate usage, it feels like building a library just because I need to use it. In Python ecosystem, that labour already done by someone else, preferably who didn't start writing a library just to deliver code within a week. One good thing about writing libraries in Clojure is the immense stability and composibility it offers. We can use the same code many years later without fearing breakage,a 'primitive' function can also be easily squeezed into numerous other functions which means reusability is quite high. However, it is still an impediment for shops less than 5 devs.
        thu2111 6y ago
        So the issue is, you want some sort of bindings rather than directly invoking the Java API. I'm curious, isn't that the sort of thing macros are supposedly good at - could the bindings not be auto generated to a large extent?
  - cabite 6y ago
    Being expert-friendly is not a problem per se for a language. What matters is the ratio between sufficient wage and productivity increase as compared to other languages. By "sufficient wage" I mean paying your experts enough so that they become less rare. I wouldn't mind paying someone 3 times as much if its expertise in the given language means he can be 10x more productive than an average programmer in an average context. (I personally have measured a 30x incrase in productivity by switching from ruby to clojure and have observed the same phenomenon with other people).
- ccortes 6y ago
  My experience has been the same. I do enjoy clojure very much but I've spent hours and even days just searching for examples on how to do X or Y and most of the sources are not beginner friendly at all. If it wasn't because of my huge desire to use datomic I think I'd switch to some other language. On the plus side I've learned a lot.
  - cabite 6y ago
    As an advanced Clojure programmer I never look for examples on the web, which is not the case for other languages. The reason behind this is that since Clojure is data-oriented, API interfaces are clear, minimal and self-documenting. With object orientation or anything that relies on datatypes, I always end up browsing docs looking for what's possible to do with the given list of methods. Never in Clojure.
    - ccortes 6y ago
      I didn't look for examples on how to code something, I looked for examples on how to engineer the code I wrote. Clojure just assumes you have the engineering knowledge and that you'll be able to figure on your own how to glue everything toghether and this exactly where I had the most trouble.
- kleiba 6y ago
  I have no hands-on experience with Clojure but it always appears to me that the language manages to get even complex computations done in relatively little code. This is because Clojure offers powerful abstractions, and this contributes to getting things done rather quickly once you've found the right way of representing data. However, it also makes me wonder if this advantage for writing code might later on turn into a shortcoming for reading, i.e., understanding code - either someone else's or your own code six months later. Complex computations that are highly compressed through the use of powerful abstractions seem to lean towards puzzle solving when you're trying to understand code that you're not already familiar with. Am I wrong? You mention Python and Java at the end of your post, and I think Python at least definitely has a mindset where readability is valued as a means for greater accessibility / maintainability.
  - simongray 6y ago
    > However, it also makes me wonder if this advantage for writing code might later on turn into a shortcoming for reading, i.e., understanding code - either someone else's or your own code six months later. Well, you're always at the mercy of whoever wrote the code, but I will just say that in my experience (as an intermediate Clojure developer, I learned it in 2018 and have been doing it professionally ever since) reading other people's Clojure code is quite easy, since basically every line of code builds on the same core abstractions (mainly the seq abstraction) and uses the same handful of functions from Clojure core (the standard library). And obviously it's mostly pure functions and immutable data, so you get the benefit of being able to isolate the code and test it out in the REPL. The main advantage of Clojure's particular data-oriented style is that there are no classes and associated methods to learn. Clojure basically defaults to using data literals for pretty much everything and the same custom is respected by most of the popular libraries (even many of the Java and JS wrappers). That's also part of why the code is pretty simple to read and why you tend to use the same few functions and macros for absolutely everything you do: you're literally just manipulating the same few kinds of data structures all the time.
    - mumblemumble 6y ago
      For my part, I am rather disillusioned with data-oriented programming. I admit I haven't spent a lot of time using Clojure professionally, but, in a recent experience of having to learn a large pre-existing codebase, I found that the difference between, "everything is a map," and, "the application's entire data model is a big indistinguishable ball of mud," seems to be commenting discipline. And commenting discipline is always terrible. Officially, by the book, you're supposed to use data access functions to give everything distinguishable names and keep it clean. What I ran into is that some nice language features for writing code quickly and tersely, such as map destructuring, actively discourage you from doing that. And without that, the difference between a map full of data and a class is that a class has a single file you can read to find out what's in it, while a map may have been built up in a completely ad-hoc manner. I think the code maintenance story may have actually been a little bit better back when I was using lisp, because lists. It's actively painful to use raw functions like cdadr to unpack your data structures. Whereas assoc-in is a fun toy and encapsulating it so you don't get to use it as much would be a bummer.
- fulafel 6y ago
  Yep, I think the readily usable examples are so bountiful on the Python side because people tend to use it for smaller self contained things (more scripting, data ETL code, cli utilities). Plus the focus on Jupyter notebooks and teaching programming, often as a first programming language. There are a bunch of grown up largish open source clojure apps up on github though and pretty good discussion forums with people bounce off ideas from on slack, zulip, the official forum, r/clojure etc. And consultancies if you have a budget.
dang 6y ago
If curious, related past threads (some with comments by norvig! https://news.ycombinator.com/posts?id=norvig https://news.ycombinator.com/posts?id=norvig): Lisp as an Alternative to Java – Faster, More Productive - https://news.ycombinator.com/item?id=21899854 https://news.ycombinator.com/item?id=21899854 - Dec 2019 (1 comment) Lisp as an Alternative to Java (1999) - https://news.ycombinator.com/item?id=12197131 https://news.ycombinator.com/item?id=12197131 - July 2016 (103 comments) Lisp as an Alternative to Java (2000) [pdf] - https://news.ycombinator.com/item?id=9045574 https://news.ycombinator.com/item?id=9045574 - Feb 2015 (21 comments) Lisp as an alternative to Java (2000) [pdf] - https://news.ycombinator.com/item?id=8446368 https://news.ycombinator.com/item?id=8446368 - Oct 2014 (55 comments) Lisp as an Alternative to Java - https://news.ycombinator.com/item?id=3447101 https://news.ycombinator.com/item?id=3447101 - Jan 2012 (37 comments) Python as an Alternative to Lisp or Java, Peter Norvig revisited - https://news.ycombinator.com/item?id=2032743 https://news.ycombinator.com/item?id=2032743 - Dec 2010 (95 comments) Ask PG: Lisp vs Python (2010) - https://news.ycombinator.com/item?id=1803351 https://news.ycombinator.com/item?id=1803351 - Oct 2010 (192 comments) Lisp as an Alternative to Java [PDF] - https://news.ycombinator.com/item?id=61320 https://news.ycombinator.com/item?id=61320 - Sept 2007 (9 comments)
- lisper 6y ago
  Worth noting that last link is to a different article. It is in fact the original work that norvig's post was based on.
  - dang 6y ago
    Oh yes! I remember ;) Will add 'related' to my comment above.
neolog 6y ago
Feels like we're 5-10 years away from "Lisp as an alternative to Go".
- szopa 6y ago
  I'm waiting for "Lisp as an alternative to Rust." :)
  - modderation 6y ago
    Why not get the best (?) of both worlds with the macro-lisp crate: https://github.com/JunSuzukiJapan/macro-lisp https://github.com/JunSuzukiJapan/macro-lisp A small snippet from the project's examples shows minimal boilerplate between Rust and a native-looking Lisp experience: lisp!(defun factorial ((n i32)) i32 (if (<= n 1) 1 (* n (factorial (- n 1)))));
  - bitwize 6y ago
    Orange crab bad!
- erik_seaberg 6y ago
  There are several abandoned Clojure/Go projects out there, and I can’t be the only one thinking about how Common Lisp displaced arrays and multiple values and exported package symbols resemble core Go features. The catch is using type declarations to drive codegen, when so many types can be passed by value or reference. And single dispatch for methods, when CL tends to choose CLOS or nothing. But my north star is to write REMOVE-IF-NOT and get the dozen lines of noise it takes to bubble errors and fill a new slice.
- closeparen 6y ago
  As a large, mature Go shop we have several “macros” that are now quite load-bearing. They’re based on Bazel rules and text/template. Get support for these workflows (which are increasingly common) into the upstream toolchain, combine with the “AST” package and pretty printer, and Go is well on its way to being a Lisp.
jayd16 6y ago
So where's all the error handling? File IO in Java would be rife with exception handling and not without reason.
- fiddlerwoaroof 6y ago
  (with-open-file ...) is roughly equivalent to the java try-with-resources pattern. `(loop for num (readline stream nil) while num ...` means, roughly, "loop through the lines of 'stream', exiting the loop on EOF". If you're assuming the input files are well-formed, CL is just much more concise with a roughly equivalent level of robustness to what a Java programmer would right for this.
  - EdwardDiego 6y ago
    Yeah, I'd be interested to see a modern comparison, I'm thinking Java may have evolved somewhat to make up some of the distance to Lisp of the 2000s :D
  - jayd16 6y ago
    > If you're assuming the input files are well-formed Seems like a big if. Lots of failure cases like file not found or bad permissions are handled with Java checked exception. The minimum Java app would have to cover those cases in some way. Does CL just silently ignore these types of issues when you "code as you would professionally"? Seems like a lot of code is missing but maybe I'm just used to the verbosity.
    - lispm 6y ago
      In Common Lisp implementations these conditions are usually reported by default in some way. CL-USER > (with-open-file (s "~/foo.lisp") (read s)) Error: The file #P"/Users/joswig/foo.lisp" does not exist. 1 (continue) Try opening "~/foo.lisp" again. 2 (abort) Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. A non-interactive program might bring up such a dialog automatically. When one would do actually application specific error handling, this could (depending on how much comfort is wanted) be much more complex, since Common Lisp has more features to handle and repair errors.
EdwardDiego 6y ago
Would be keen to see a similar comparison after 21 years of language and VM/runtime (depending on your Lisp, I guess it doesn't apply to Chicken Scheme) evolution.
RcouF1uZ4gsC 6y ago
One of the biggest productivity boosts, even more so than the language is ecosystem and libraries. Having libraries that do json, interface to AWS S3, interface to Postgress/MySQL, OAuth, etc is a huge productivity boost, versus having to roll your own. Many times in software development, more work is spent in glue code and wiring stuff together than actual algorithmic development. And speaking of algorithmic development, I would bet, that just about any common algorithm, and likely many esoteric algorithms have easily available, high quality implementations that you can plug into your code without too much hassle.
- kimi 6y ago
  That's where Clojure(Script) shines.
- murukesh_s 6y ago
  True that. I wonder why there is so much fuss about programming languages as such and not much about the ecosystem. Especially in web development backend. In my anecdotal observation, we spend most of the time in glue code and exploring documentation for various services/libraries. Thats why middleware tools like Data and Application Integration solutions sell like hot cakes in enterprises.
  - pjmlp 6y ago
    Because many devs have it wrong. It should be "I want to use ecosystem X => language YWZ", while many do "I have language YWZ => what can I do?". Hence why language wars based on grammar/semantics are pointless.
- vindarel 6y ago
  Just confirming these libraries are there for CL. (https://github.com/CodyReichert/awesome-cl/ https://github.com/CodyReichert/awesome-cl/ for a start)
  - diragon 6y ago
    Well, some of them are. With a rather large probability, libraries I would need are not.
vbsteven 6y ago
Is there a modern equivalent to the mentioned research test program that allows browsing submissions? I would love to have a known problem set with browseable submissions in different languages. To see if I can get close to the optimal solution with my own preferred languages. But also to learn what an idiomatic solution in another language looks like. The research problem from the article is interesting because it encompasses IO, some data structures and an algorithm for generating output. edit: aside from single-binary problem sets like this, it would be nice to also have a more open category for "distributed systems" or "concurrency-related" problems to solve with modern coroutines/fibers/greenthreads or even AMQP-style message queues.
- tdfirth 6y ago
  I think this fits what you are looking for: http://www.rosettacode.org/wiki/Rosetta_Code http://www.rosettacode.org/wiki/Rosetta_Code There is a listing of 'tasks' (explore > tasks in the topnav) and each one features submissions in many different languages.
Ciantic 6y ago
We programmers are very picky sometimes. I wonder if the Lisp would have taken off better if it had parentheses free syntax. It could have been easier to sell for uninitiated that way. I just found out that there exists Wisp [1], that basically removes the parentheses for indentation. https://www.draketo.de/software/wisp https://www.draketo.de/software/wisp
- rscho 6y ago
  The Racket people are attempting to do that in a new way with the Honu language, to truly have Lisp powers with an alternate syntax. It's probably going to replace racket as the main language on the racket runtime: https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.cs.utah.edu/plt/publications/gpce12-rf.pdf&ved=2ahUKEwick4jWguzvAhUEGewKHe3BDO4QFjAEegQIBhAC&usg=AOvVaw0AAI1ZXywmm01mdjzo2Q8N https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...
  - mark_l_watson 6y ago
    I hope not. My mind works well with the syntax of Lisp languages. BTW, at Racketfest two weekends ago, I heard no mention at all of the alternative syntax.
    - rscho 6y ago
      I also find myself at home with lisp syntax. However it would be very interesting to have a well-supported mainstream syntax regarding the accessibility of the runtime. Incidentally, this was the main stated goal: be more accessible to students and beginners. This could bring people to the racket environment, which would definitely be a win for OSS projects hosted on racket.
      - mikelevins 6y ago
        Some folks at Apple made the same argument in favor of giving Dylan a non-Lisp syntax. In fact, I was one of them. In hindsight, I think we were wrong. The infix syntax didn't serve its purpose of growing Dylan's user base, and it made the surface language clumsier to work with. I strongly prefer its original s-expression syntax.
mabbo 6y ago
I think the lesson to learn from Java was that we, developers, were evaluating languages on the wrong parameters. Java is too verbose! (But that can reduce the need for so many comments, and comments can often mislead as software changes. Also, Java 8 was 2014 and it changed the game massively.) Java runs slowly because of the JVM! (But the JVM evolves and improves, giving free upgrades to all Java programs over time. Also, I have a multi-GHZ processor now.) Java takes longer to write! (But the first time you write a program is never the hard part- it's continuous evolution of software that matters.) Norvig's code is beautiful and very good Lisp. But it's so dense that it requires more lines of explanatory comments than actual functionality. The code's functionality isn't self-evident. And sure, you can write Java code that has the same flaws, but I find it's easier to write readable Java code than it is to write readable Lisp. I think Python's success is further evidence of this perspective.
- b3kart 6y ago
  > Norvig's code is beautiful and very good Lisp. But it's so dense that it requires more lines of explanatory comments than actual functionality. I've thought the same. Just look at the comment for the `print-translations` function. Like yeah, the code is short, and I am sure it didn't take Peter long to write it: he's one of the best out there after all. But if this were real software, how long until the comment becomes out-of-sync with the implementation, due to negligence or simple laziness? Is it not safer, and a better use of time, to write code that itself reads more like that comment, which I'd guess would be the case with Java, and even more so with Python?
- tincholio 6y ago
  > but I find it's easier to write readable Java code than it is to write readable Lisp. I think that depends a bit on the style. Pattern-heavy, "clean" Java is a mess of boilerplate that makes it very hard to find where things actually happen, let alone get an"idea at a glance" of what the code is about. Concise code might be harder to get started with, but in the end tends to be easier (for me, at least) to grok. In any case, the main difference here, beyond the languages, is Norvig being a genius.
- wtetzner 6y ago

156 points by azhenley 6y ago

I have been using Clojure as a solo developer for about two years now, there is definitely a productivity increase. It always feels like the amount of time required to do the next thing is incrementally decreasing (like Ologn?) While all that is fun, Clojure is still a very enterprise ecosystem, where participants don't share as much elementary code as in Python ecosystem. Participants are also quite experienced, thus I have to sit, read through and make architectural decisions for the entirety of the project. When we add this thinking time into the measurement, the time taken for a Clojure 'project' (not a piece of code) is definitely more than Python or Java (IMO).

stingraycharles 6y ago
You mean the steep learning curve, and lack of “starter pack” type of frameworks (for lack of a better description) is holding you back being more productive with Clojure? I’ve been doing Clojure professionally for over 5 years now and it’s definitely a known issue that Clojure is very expert-friendly.
- demonshreder 6y ago
  Getting a 'hang' of clojure as a language is quite easy, my colleague and I took only two weeks to jump into things. Even today, specific code development is order of times faster than we can do in Python. However, lack of general 'all-purpose' libraries for numerous use cases means we have to implement that API or library in a general way (if only for our use case) then integrate it into the system. This approach has worked quite well, creating our own template code (as everything is functional) helps reuse across many projects, however the initial investment of time/labour is something we would like to avoid for the sake of finishing the work fast.
  - thu2111 6y ago
    Are you counting Java libs as part of that ecosystem? It seems odd to describe the JVM as lacking all purpose libraries.
    - demonshreder 6y ago
      Java libs are definitely helpful, the time I mentioned includes wrapping Object oriented code into functions. This is easy if all that is required is one or two methods from the Java, however for more than immediate usage, it feels like building a library just because I need to use it. In Python ecosystem, that labour already done by someone else, preferably who didn't start writing a library just to deliver code within a week. One good thing about writing libraries in Clojure is the immense stability and composibility it offers. We can use the same code many years later without fearing breakage,a 'primitive' function can also be easily squeezed into numerous other functions which means reusability is quite high. However, it is still an impediment for shops less than 5 devs.
      - thu2111 6y ago
        So the issue is, you want some sort of bindings rather than directly invoking the Java API. I'm curious, isn't that the sort of thing macros are supposedly good at - could the bindings not be auto generated to a large extent?
- cabite 6y ago
  Being expert-friendly is not a problem per se for a language. What matters is the ratio between sufficient wage and productivity increase as compared to other languages. By "sufficient wage" I mean paying your experts enough so that they become less rare. I wouldn't mind paying someone 3 times as much if its expertise in the given language means he can be 10x more productive than an average programmer in an average context. (I personally have measured a 30x incrase in productivity by switching from ruby to clojure and have observed the same phenomenon with other people).
ccortes 6y ago
My experience has been the same. I do enjoy clojure very much but I've spent hours and even days just searching for examples on how to do X or Y and most of the sources are not beginner friendly at all. If it wasn't because of my huge desire to use datomic I think I'd switch to some other language. On the plus side I've learned a lot.
- cabite 6y ago
  As an advanced Clojure programmer I never look for examples on the web, which is not the case for other languages. The reason behind this is that since Clojure is data-oriented, API interfaces are clear, minimal and self-documenting. With object orientation or anything that relies on datatypes, I always end up browsing docs looking for what's possible to do with the given list of methods. Never in Clojure.
  - ccortes 6y ago
    I didn't look for examples on how to code something, I looked for examples on how to engineer the code I wrote. Clojure just assumes you have the engineering knowledge and that you'll be able to figure on your own how to glue everything toghether and this exactly where I had the most trouble.
kleiba 6y ago
I have no hands-on experience with Clojure but it always appears to me that the language manages to get even complex computations done in relatively little code. This is because Clojure offers powerful abstractions, and this contributes to getting things done rather quickly once you've found the right way of representing data. However, it also makes me wonder if this advantage for writing code might later on turn into a shortcoming for reading, i.e., understanding code - either someone else's or your own code six months later. Complex computations that are highly compressed through the use of powerful abstractions seem to lean towards puzzle solving when you're trying to understand code that you're not already familiar with. Am I wrong? You mention Python and Java at the end of your post, and I think Python at least definitely has a mindset where readability is valued as a means for greater accessibility / maintainability.
- simongray 6y ago
  > However, it also makes me wonder if this advantage for writing code might later on turn into a shortcoming for reading, i.e., understanding code - either someone else's or your own code six months later. Well, you're always at the mercy of whoever wrote the code, but I will just say that in my experience (as an intermediate Clojure developer, I learned it in 2018 and have been doing it professionally ever since) reading other people's Clojure code is quite easy, since basically every line of code builds on the same core abstractions (mainly the seq abstraction) and uses the same handful of functions from Clojure core (the standard library). And obviously it's mostly pure functions and immutable data, so you get the benefit of being able to isolate the code and test it out in the REPL. The main advantage of Clojure's particular data-oriented style is that there are no classes and associated methods to learn. Clojure basically defaults to using data literals for pretty much everything and the same custom is respected by most of the popular libraries (even many of the Java and JS wrappers). That's also part of why the code is pretty simple to read and why you tend to use the same few functions and macros for absolutely everything you do: you're literally just manipulating the same few kinds of data structures all the time.
  - mumblemumble 6y ago
    For my part, I am rather disillusioned with data-oriented programming. I admit I haven't spent a lot of time using Clojure professionally, but, in a recent experience of having to learn a large pre-existing codebase, I found that the difference between, "everything is a map," and, "the application's entire data model is a big indistinguishable ball of mud," seems to be commenting discipline. And commenting discipline is always terrible. Officially, by the book, you're supposed to use data access functions to give everything distinguishable names and keep it clean. What I ran into is that some nice language features for writing code quickly and tersely, such as map destructuring, actively discourage you from doing that. And without that, the difference between a map full of data and a class is that a class has a single file you can read to find out what's in it, while a map may have been built up in a completely ad-hoc manner. I think the code maintenance story may have actually been a little bit better back when I was using lisp, because lists. It's actively painful to use raw functions like cdadr to unpack your data structures. Whereas assoc-in is a fun toy and encapsulating it so you don't get to use it as much would be a bummer.
fulafel 6y ago
Yep, I think the readily usable examples are so bountiful on the Python side because people tend to use it for smaller self contained things (more scripting, data ETL code, cli utilities). Plus the focus on Jupyter notebooks and teaching programming, often as a first programming language. There are a bunch of grown up largish open source clojure apps up on github though and pretty good discussion forums with people bounce off ideas from on slack, zulip, the official forum, r/clojure etc. And consultancies if you have a budget.

dang 6y ago

If curious, related past threads (some with comments by norvig! https://news.ycombinator.com/posts?id=norvig https://news.ycombinator.com/posts?id=norvig): Lisp as an Alternative to Java – Faster, More Productive - https://news.ycombinator.com/item?id=21899854 https://news.ycombinator.com/item?id=21899854 - Dec 2019 (1 comment) Lisp as an Alternative to Java (1999) - https://news.ycombinator.com/item?id=12197131 https://news.ycombinator.com/item?id=12197131 - July 2016 (103 comments) Lisp as an Alternative to Java (2000) [pdf] - https://news.ycombinator.com/item?id=9045574 https://news.ycombinator.com/item?id=9045574 - Feb 2015 (21 comments) Lisp as an alternative to Java (2000) [pdf] - https://news.ycombinator.com/item?id=8446368 https://news.ycombinator.com/item?id=8446368 - Oct 2014 (55 comments) Lisp as an Alternative to Java - https://news.ycombinator.com/item?id=3447101 https://news.ycombinator.com/item?id=3447101 - Jan 2012 (37 comments) Python as an Alternative to Lisp or Java, Peter Norvig revisited - https://news.ycombinator.com/item?id=2032743 https://news.ycombinator.com/item?id=2032743 - Dec 2010 (95 comments) Ask PG: Lisp vs Python (2010) - https://news.ycombinator.com/item?id=1803351 https://news.ycombinator.com/item?id=1803351 - Oct 2010 (192 comments) Lisp as an Alternative to Java [PDF] - https://news.ycombinator.com/item?id=61320 https://news.ycombinator.com/item?id=61320 - Sept 2007 (9 comments)

lisper 6y ago
Worth noting that last link is to a different article. It is in fact the original work that norvig's post was based on.
- dang 6y ago
  Oh yes! I remember ;) Will add 'related' to my comment above.

neolog 6y ago

Feels like we're 5-10 years away from "Lisp as an alternative to Go".

szopa 6y ago
I'm waiting for "Lisp as an alternative to Rust." :)
- modderation 6y ago
  Why not get the best (?) of both worlds with the macro-lisp crate: https://github.com/JunSuzukiJapan/macro-lisp https://github.com/JunSuzukiJapan/macro-lisp A small snippet from the project's examples shows minimal boilerplate between Rust and a native-looking Lisp experience: lisp!(defun factorial ((n i32)) i32 (if (<= n 1) 1 (* n (factorial (- n 1)))));
- bitwize 6y ago
  Orange crab bad!
erik_seaberg 6y ago
There are several abandoned Clojure/Go projects out there, and I can’t be the only one thinking about how Common Lisp displaced arrays and multiple values and exported package symbols resemble core Go features. The catch is using type declarations to drive codegen, when so many types can be passed by value or reference. And single dispatch for methods, when CL tends to choose CLOS or nothing. But my north star is to write REMOVE-IF-NOT and get the dozen lines of noise it takes to bubble errors and fill a new slice.
closeparen 6y ago
As a large, mature Go shop we have several “macros” that are now quite load-bearing. They’re based on Bazel rules and text/template. Get support for these workflows (which are increasingly common) into the upstream toolchain, combine with the “AST” package and pretty printer, and Go is well on its way to being a Lisp.

jayd16 6y ago

So where's all the error handling? File IO in Java would be rife with exception handling and not without reason.

fiddlerwoaroof 6y ago
(with-open-file ...) is roughly equivalent to the java try-with-resources pattern. `(loop for num (readline stream nil) while num ...` means, roughly, "loop through the lines of 'stream', exiting the loop on EOF". If you're assuming the input files are well-formed, CL is just much more concise with a roughly equivalent level of robustness to what a Java programmer would right for this.
- EdwardDiego 6y ago
  Yeah, I'd be interested to see a modern comparison, I'm thinking Java may have evolved somewhat to make up some of the distance to Lisp of the 2000s :D
- jayd16 6y ago
  > If you're assuming the input files are well-formed Seems like a big if. Lots of failure cases like file not found or bad permissions are handled with Java checked exception. The minimum Java app would have to cover those cases in some way. Does CL just silently ignore these types of issues when you "code as you would professionally"? Seems like a lot of code is missing but maybe I'm just used to the verbosity.
  - lispm 6y ago
    In Common Lisp implementations these conditions are usually reported by default in some way. CL-USER > (with-open-file (s "~/foo.lisp") (read s)) Error: The file #P"/Users/joswig/foo.lisp" does not exist. 1 (continue) Try opening "~/foo.lisp" again. 2 (abort) Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. A non-interactive program might bring up such a dialog automatically. When one would do actually application specific error handling, this could (depending on how much comfort is wanted) be much more complex, since Common Lisp has more features to handle and repair errors.

EdwardDiego 6y ago

Would be keen to see a similar comparison after 21 years of language and VM/runtime (depending on your Lisp, I guess it doesn't apply to Chicken Scheme) evolution.

RcouF1uZ4gsC 6y ago

One of the biggest productivity boosts, even more so than the language is ecosystem and libraries. Having libraries that do json, interface to AWS S3, interface to Postgress/MySQL, OAuth, etc is a huge productivity boost, versus having to roll your own. Many times in software development, more work is spent in glue code and wiring stuff together than actual algorithmic development. And speaking of algorithmic development, I would bet, that just about any common algorithm, and likely many esoteric algorithms have easily available, high quality implementations that you can plug into your code without too much hassle.

kimi 6y ago
That's where Clojure(Script) shines.
murukesh_s 6y ago
True that. I wonder why there is so much fuss about programming languages as such and not much about the ecosystem. Especially in web development backend. In my anecdotal observation, we spend most of the time in glue code and exploring documentation for various services/libraries. Thats why middleware tools like Data and Application Integration solutions sell like hot cakes in enterprises.
- pjmlp 6y ago
  Because many devs have it wrong. It should be "I want to use ecosystem X => language YWZ", while many do "I have language YWZ => what can I do?". Hence why language wars based on grammar/semantics are pointless.
vindarel 6y ago
Just confirming these libraries are there for CL. (https://github.com/CodyReichert/awesome-cl/ https://github.com/CodyReichert/awesome-cl/ for a start)
- diragon 6y ago
  Well, some of them are. With a rather large probability, libraries I would need are not.

vbsteven 6y ago

Is there a modern equivalent to the mentioned research test program that allows browsing submissions? I would love to have a known problem set with browseable submissions in different languages. To see if I can get close to the optimal solution with my own preferred languages. But also to learn what an idiomatic solution in another language looks like. The research problem from the article is interesting because it encompasses IO, some data structures and an algorithm for generating output. edit: aside from single-binary problem sets like this, it would be nice to also have a more open category for "distributed systems" or "concurrency-related" problems to solve with modern coroutines/fibers/greenthreads or even AMQP-style message queues.

tdfirth 6y ago
I think this fits what you are looking for: http://www.rosettacode.org/wiki/Rosetta_Code http://www.rosettacode.org/wiki/Rosetta_Code There is a listing of 'tasks' (explore > tasks in the topnav) and each one features submissions in many different languages.

Ciantic 6y ago

We programmers are very picky sometimes. I wonder if the Lisp would have taken off better if it had parentheses free syntax. It could have been easier to sell for uninitiated that way. I just found out that there exists Wisp [1], that basically removes the parentheses for indentation. https://www.draketo.de/software/wisp https://www.draketo.de/software/wisp

rscho 6y ago
The Racket people are attempting to do that in a new way with the Honu language, to truly have Lisp powers with an alternate syntax. It's probably going to replace racket as the main language on the racket runtime: https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.cs.utah.edu/plt/publications/gpce12-rf.pdf&ved=2ahUKEwick4jWguzvAhUEGewKHe3BDO4QFjAEegQIBhAC&usg=AOvVaw0AAI1ZXywmm01mdjzo2Q8N https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...
- mark_l_watson 6y ago
  I hope not. My mind works well with the syntax of Lisp languages. BTW, at Racketfest two weekends ago, I heard no mention at all of the alternative syntax.
  - rscho 6y ago
    I also find myself at home with lisp syntax. However it would be very interesting to have a well-supported mainstream syntax regarding the accessibility of the runtime. Incidentally, this was the main stated goal: be more accessible to students and beginners. This could bring people to the racket environment, which would definitely be a win for OSS projects hosted on racket.
    - mikelevins 6y ago
      Some folks at Apple made the same argument in favor of giving Dylan a non-Lisp syntax. In fact, I was one of them. In hindsight, I think we were wrong. The infix syntax didn't serve its purpose of growing Dylan's user base, and it made the surface language clumsier to work with. I strongly prefer its original s-expression syntax.

mabbo 6y ago

I think the lesson to learn from Java was that we, developers, were evaluating languages on the wrong parameters. Java is too verbose! (But that can reduce the need for so many comments, and comments can often mislead as software changes. Also, Java 8 was 2014 and it changed the game massively.) Java runs slowly because of the JVM! (But the JVM evolves and improves, giving free upgrades to all Java programs over time. Also, I have a multi-GHZ processor now.) Java takes longer to write! (But the first time you write a program is never the hard part- it's continuous evolution of software that matters.) Norvig's code is beautiful and very good Lisp. But it's so dense that it requires more lines of explanatory comments than actual functionality. The code's functionality isn't self-evident. And sure, you can write Java code that has the same flaws, but I find it's easier to write readable Java code than it is to write readable Lisp. I think Python's success is further evidence of this perspective.

b3kart 6y ago
> Norvig's code is beautiful and very good Lisp. But it's so dense that it requires more lines of explanatory comments than actual functionality. I've thought the same. Just look at the comment for the `print-translations` function. Like yeah, the code is short, and I am sure it didn't take Peter long to write it: he's one of the best out there after all. But if this were real software, how long until the comment becomes out-of-sync with the implementation, due to negligence or simple laziness? Is it not safer, and a better use of time, to write code that itself reads more like that comment, which I'd guess would be the case with Java, and even more so with Python?
tincholio 6y ago
> but I find it's easier to write readable Java code than it is to write readable Lisp. I think that depends a bit on the style. Pattern-heavy, "clean" Java is a mess of boilerplate that makes it very hard to find where things actually happen, let alone get an"idea at a glance" of what the code is about. Concise code might be harder to get started with, but in the end tends to be easier (for me, at least) to grok. In any case, the main difference here, beyond the languages, is Norvig being a genius.
wtetzner 6y ago