Back in Amazon I found some ancient code written in Common Lisp. Doubt any production services left, but I updated the build system to support Clozure CL. My contribution in $BIGCORP :)
Really? Please dare. I don't think $BIGCORP is so dominant here, or that things have changed so much since 2015.
Most changes that people notice on HN are random fluctuation. Note that I don't say all changes—just most. The trouble is that it's hard to figure out which ones are vs. aren't, and none of us really tries. We just notice the data points we notice (which, btw, are the ones we're primed to notice—usually whatever we dislike the most) and connect the dots with material from our imagination. It's an amazing thing! Randomness plus cognitive bias equals narrative.
There's a thread about this on the front page right now: https://news.ycombinator.com/item?id=23293462. I've been saying the same thing about people's interpretations of HN for years:
For normal small team it might be hard to get advise. More diverse users in other eco-system. Even clojure is hard. At least the code is easier to read.
This says if the Lisp supports “foo” as a “feature” (a precise term in Common Lisp), the A will be included. Otherwise A will be treated as a comment. B will be included regardless. It’s roughly equivalent to
For the benefit of everybody else, #+ does feature checking.
The Common Lisp standard defines a standard "special variable" (kind of like a global) named * features * (shouldn't be spaces, but HN italicizes it otherwise), and #+ (and #-) take a "feature expression" and conditionally execute the expression that immediately follows it when the feature expression is true. If the feature check is false, the next expression is ignored.
For example:
#+freebsd(print "This is FreeBSD")
#+(not (and 64-bit linux))(print "This is not 64-bit Linux.")
#+quicklisp (ql:quickload :some-library)
The CL standard lists a few standard features (:common-lisp, :ieee-floating-point, etc.) but for the most part implementations and libraries define their own.
It's not perfect, but works well enough in practice.
This is an unofficial Common Lisp s-expression level comment. One of these incredibly nice things that's missing in most programming languages. It comments out a single s-expression, no matter how complex. It's like a #|block comment|# in that it can span multiple lines, and like ; line comment in that you only put something at the beginning. Have a complex expression within a function, that you need to temporarily shut down? Just shove #+nil in front of it.
(The #+nil version is discouragd because there's a remote chance somebody will define a * feature * called :nil for some reason.)
A less-common thing done with it is library interop. Many libraries tend to add a tag to * features * to indicate they've been loaded, so in your library, you can use #+library_tag to detect that another library is a part of the same project, and conditionally compile-in some extensions or interoperability code.
(@dang, I think HN could use a way to escape the * * formatting marks. For a site and community that has a soft spot for Lisp, not being able to type in the "earmuffs" is something that always bewildered me.)
#+ is only one of many, many standard reader macros (as you can see from that link). You can also define your own, which makes Lisp syntax almost infinitely malleable. For example, it's possible to change the Lisp reader so that it natively reads infix syntax. See:
The important thing about reader macros is that they happen at read time. It causes code to be executed at tokenizing time (so you can make your own syntax, e.g. #{ ... } could return a JSON object directly) even before evaluation or macroexpansion.
So #+ and #- really only scratch the surface. Someone wrote a comment about using #+ to define the path delimiter (/ or \), but that is something that could be looked up at runtime. Read-time extension is unusual in programming languages (C++ has such a feature for a more limited set of cases).
Interesting, seems the "comments>0" op is undocumented, couldn't find it anywhere on the algolia page. Is there a page with all the different operators you can use?
It's documented here: https://hn.algolia.com/help. You have to click 'help' at the bottom of the search page, I guess.
Another option I use, which doesn't appear on that page, is storyText=none, if you want to exclude matches from text posts. That one has to go in the URL, though. Note the difference between the link in my GP comment vs. this one:
This is officially the hardest I've laughed at a grammar mistake. At the end of the third line, there's a missing space between "years." and "We". Petty, I know, but I expect a grammar company who took over my Youtube ads earlier about writing perfect emails and blog posts to have perfect blog posts.
Hard agree. I don't use lisp, but people in an adjacent department do (yes, in prod). It takes a few minutes to learn to read lisp. Arithmetic takes a lil bit to grok, but short expressions are easy. I wouldn't share lisp that I've written with my coworkers ;)
> it’s basically unreadable to very most of developers
The ubiquity of parenthesis has a purpose - it lets you treat code as data. Your argument only makes sense if syntax choice were 100% based on taste. But it's not (simplicity of syntax brings with it practical features), so it's great that some people are exploring other options.
> The ubiquity of parenthesis has a purpose - it lets you treat code as data. Your argument only makes sense if syntax choice were 100% based on taste. But it's not (simplicity of syntax brings with it practical features), so it's great that some people are exploring other options.
Are you sure? Plenty of languages[1,2] allow you to treat code as data and they don't need that many parenthesis.
"Python does have access to the abstract syntax tree of programs, but this is not for the faint of heart. On the plus side, the modules are easy to understand, and with five minutes and five lines of code I was able to get this:
"This was rather a disapointment to me. The Lisp parse of the equivalent expression is (+ 2 2). It seems that only a real expert would want to manipulate Python parse trees, whereas Lisp parse trees are simple for anyone to use."
> That's not code as data, that's parsed code as data.
I would say: you can execute it, therefore it's code. What am I missing?
> Why not just use a single representation (+ a (* b c) 1) ?
Are you saying you don't like the default print? You can write a println method for type Expr which prints it any way you want. Seems like a miniscule thing to nitpick.
Yes, if you remove a few elements you get (+ a (* b c) 1), as I said a few messages back, which is lisp code and is also lisp data. So you can treat code as data!
You can of course parse code in any language and treat it as data (and it may resemble lisp code!) but it’s not quite the same thing.
I find languages like MUMPS unreadable, but I also know a few folks that love it and truly confused why I don't. I programmed a lot of production code with Perl, and that confuses the heck out of a lot of programmers. I loved Postscript and Forth, but I keep running into people that think they are complicated and hard to follow when the rules are so simple. People are hateful of selector-syntax in Smalltalk and Objective-C, but I think its the most easily understandable syntax out there because the what the variables are for is right there instead of just a comma separated list of variables with no hints. I truly wonder if the C family of languages gets so ingrained that anything else is just seen as crappy?
Lisp benefits greatly from a decent text editor, but it is quite readable.
Indeed, I have a friend who totally loved Mumps. I have almost 40 years with Common Lisp, love the language, but I have always been fairly open to what customers want. I know people who do amazing things with Python or Java.
I don’t much care about other peoples’ preferences for politics, programming language selection, or religion (or lack thereof).
It seems best for a team to choose a stack by some form consensus, and stick with it.
I have read the linked article several times in the 5 years since it was written, and I enjoy the shared experience. But the article could also have been about using Clojure, or Ruby, etc., etc. And also been interesting.
HN is written in Lisp. So anyone interested in cloning HN, better understanding HN, etc, would have reason to be interested in reading up on it, even if it's not something they work with normally.
Humans being human, I would think it strange if a forum written in Lisp failed to have some sort of pro-Lisp bias.
But I don't understand the unreadability claim: lisp syntax is extremely simple, and therefore (for me, someone is not a developer by profession) extremely readable.
To be fair, bracket abuse is pretty widespread. Lisp, at least, is honest and very consistent in their use. And I don’t find things like [](){} particularly readable (that was valid C++ syntax, BTW).
Lisp is hard to master, like playing the violin, but if you master it you can get enormous rewards.
Other languages are more like "playing guitar hero", most of the work is done for you and it it way easier to learn.
HN is like a musician network but for programmers. It attracts lots of people around the world that master lisp like musicians master an instrument.
I will tell you about myself, I had a lisp master that did teach me that what had taken me weeks in c, c++ and python code he could do it in lisp in minutes.
As I saw this man "play his instrument" it was obvious that if I wanted to be a good programmer I should master it myself.
Because I had this master teaching me, I could learn it fast.
The "secret" of Lisp is that you can automate your code writing, making you tens or hundred of times more capable with your code.
"Ivory tower" means it is not related to reality. Lisp is very real, like violins are real.
This sounds like a metaphor designed to stroke the ego of Lisp programmers but quite disconnected from the realities of the various programming languages.
> Other languages are more like "playing guitar hero", most of the work is done for you and it it way easier to learn.
What does that even mean? Python might be easier to learn than Lisp, but surely C++ is much harder to learn and impossible to master. And if you talk about "batteries included", Python may have more but C has obviously much less than Lisp.
Lisp is a fine language, but the ridiculous claims is hurting it more than helping it. I do not believe claims about the amazing productivity of Lisp from someone who doesn't know the difference between C++ and Python.
>Could you give me an example of a real-world software engineering task which takes “weeks” in Python and minutes in Lisp?
Not "weeks vs hours" but let me offer my personal experience. I already had around 3 years of professional experience in Python and about the same in Common Lisp.
Last year I had to create a small utility to help some document scanning process, this included doing some OCR. I had the choice to do this in Lisp or Python or whatever language (I also could as well have written the stuff in Java, C#, C, JS, etc.)
Initially I thought "ok, i have good tesseract binding and PDF output libs in Python, where as the Lisp bindings look unmaintained" so i chose Python.
Well, back into Python's antiquated way of working: No compiler-time checking of anything, and, even worse, upon finding an error, there was no way of correcting the offending function and restarting program execution at that point (restarting a stack frame). No sir, I had to run my whole program again (this was an interaction heavy program) to test it again.
So MANY hours were lost in just having to restart the program again and do all the clicks needed to bring back the program to a specific state.
Where with Common Lisp those hours would be reduced to zero, since I can modify the program while it's running and I can always inspect all stack frames and restart them at will. Not to mention other benefits in terms of being able to write code that is way higher in abstraction level. Not to mention I can actually SAVE the current program's state to disk and resume it back at a later date.
And not to mention that the Lisp program would probably had executed 20 to 30 times faster as well.
So far, that's the last time I chose to use Python for non-trivial tasks.
Not weeks to minutes, but still, try writing an Airlines booking, scheduling application which gets the traveler the best route given his/her requirements.
That is just an algorithm, isn't it? I cant see how it would be simpler to implement in Lisp that Python.
I suspect the issue is that a flight booking system is basically the only significant commercial system written in Lisp, which is why it is always dragged out in these discussions.
The claim was that something which would take weeks in say Python would take minutes in Lisp. Then this flight search system is presented as evidence.
I just don't see how it is any form of evidence for that rather extraordinary claim? It just shows it is possible to write complex software in Lisp, but I wasn't disputing that. I'm disputing the claim of 100 x productivity.
I was addressing your 'That is just an algorithm, isn't it?', in case you would be interested what that application is actually about.
There was no general claim of 100x productivity. The commenter wrote: "I had a lisp master that did teach me that what had taken me weeks in c, c++ and python code he could do it in lisp in minutes"
That was his personal impression, not a general claim. I can't also imagine how this could be a general claim.
Yes the sauce is in the algorithm and its a non-trivial one. Its a NP hard problem of searching through a combinatorial explosion of possible configuration. I am not aware of any other product that comes close to what ITA offered.
The feature of Lisp that was heavily used in the code was the use of macros and metaprogramming. These are the kinds of problems were lisp excels. ITA made use of the fact that Lisp is a programmable programming language and they adapted programming language to the domain.
I am not doubting that Lisp is a language with which can be used to write succesful commercial applications. I am questioning the claim that it is vastly more productive for commercial applications.
Of course it is not really possible to say how somebody else in a different language would have needed, so maybe a compromise would be to see some 'magical'lisp code examples.
If it runs on C++ now, it's been rewritten. Sabre predates C by many, many years and it almost predates Bjarne Stroustrup himself. I suspect a lot of it got moved to IBM assembly when they moved to S/360 mainframes in the early 70's. TPF is a descendant of that project.
Thats the story beeing told. Since I havent seen it, my critical mind starts to think, that this is actually a myth. Do you know of any published (in the sense one can reas the code) examples that show this claim (and the reddit v1 is not such an example)
(Of course anybody can chime in, it should be actually easy, if the claim that here the experts are lingering around)
I have a complaint. Each comment from the parent poster has been downvoted, so much so that I struggle to read them.
Is this what we do now? Instead of agreeing to disagree, or (better!) explaining our viewpoint, we make comments fade into the background? Whatever happened to edification?
Because, these are valid comments! The real world bears them out! I strongly disagree, but that does not make me (or anyone else) right. This is a forum for discussion, so - discuss!
I wouldn't say Common Lisp is a esoteric language. Esoteric makes me think Brainfuck and other similar languages. Common Lisp and lisps in general are languages you can be productive in, in a "building a product" sense, which you cannot say about most esoteric languages.
It says: 'We’ve built an esoteric application (even by Lisp standards)'
The application was considered by the author to be esoteric in 2015, not the programming language.
Quote: "Our Lisp services are conceptually a classical AI application that operates on huge piles of knowledge created by linguists and researchers. It’s mostly a CPU-bound program, and it is one of the biggest consumers of computing resources in our network."
The application is the compute core of a cloud-based grammar checker with lots of complex lingustic knowledge, which generates a lot of processing load.
And "(even by Lisp standards)" just means that there are other applications in the Natural Language Processing domain, which were written in Lisp, like software to do machine translation between language or text content checking systems for technical documents.
It’s not a good comparison at all. Learning lisp or understanding it is a good base knowledge regardless of your primarily language. It’s not a language that’s truly esoteric and difficult to reason about by nature. Metaprogramming/macros can be difficult for those inexperienced, but not impossible. Esoteric languages are often created to either use unfamiliar syntax compared to common languages or unfamiliar paradigms to those. In the end, a lot of things are very similar in nature with esoteric languages, just a very different way, with syntax that’s not as readable as common languages. Lisp is certainly readable and easy to grin even if you have little knowledge of the language
Erm, Lisps were used back in time for many production systems when C++ wasn't even started. Looks like your definition of esoteric and production is based on couple of years of cheap CS courses.
Oxford's definition of esoteric: "intended for or likely to be understood by only a small number of people with a specialized knowledge or interest."
Today, C++ is a dominant programming language. Lisp is only used in niche applications. Therefore, it is likely only to be understood by a small number of people with specialized knowledge -- hence, it is esoteric.
Upon conception it was neither "intended" nor "likely" "to be understood by only a small number of people with a specialized knowledge or interest" and it is still not intended that way nor likely, that only few people _can_ understand it. It is just that people choose not to take time and understand it.
I don't agree with the conclusion you draw from a definition of esoteric, that is without context anyway, taken from a natural language dictionary.
You are ignorant of reality, and the first thing that you ignore is that you are ignorant.
With Lisp you don't even need to write lisp code. You can write java, c++,c, swift code... using lisp.
That is , you can write lisp code without people realizing you are writing lisp code. The only thing they will notice is that your code looks almost too perfect, too well formatted and justified, are extremely productive and never make mistakes.
Sometimes people write Lisp code and use translators to C or C++. Some of that code then will be maintained in C / C++. Some of these tools were custom developed, but there existed also specialized Lisp to C translators, which produced 'maintainable' code.
For example the first version of the .net garbage collector was written in Common Lisp and then translated to C++. Since then it was maintained and enhanced in the C++ version.
Languages have strengths and weaknesses. Learning the right language to express a solution is easier than doing it the hard way in the wrong language just because you happen to know it.
