News for hackers. Stuff that matters.
Re:Running Lisp in Production (2015) by dirtnugget on Sunday May 24, 2020 @02:59PM (#23293736)
I seriously don’t get why lisp is so popular on HN, it’s basically unreadable to very most of developers. It’s an ivory tower.
Re:Running Lisp in Production (2015) by TeMPOraL on Sunday May 24, 2020 @05:53PM (#23295182)
"Unreadable" is a choice at this point.

Here's a simple trick to make Lisp instantly readable. Take a line of code from an algol-like language:

  foo(bar(), baz(quux))
then, shift every opening parenthesis one token to the left:

  (foo (bar), (baz quux))
and drop the commas:

  (foo (bar) (baz quux))
Now you have an equivalent piece of Lisp code.
Re:Running Lisp in Production (2015) by klyrs on Sunday May 24, 2020 @09:23PM (#23296743)
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 ;)
Re:Running Lisp in Production (2015) by dwheeler on Monday May 25, 2020 @01:18AM (#23298094)
If you prefer to use Lisp with a more conventional syntax, check out "readable Lisp: https://readable.sourceforge.io/

It has three levels of notation, depending on what you want. There is even a quick lisp library.

Re:Running Lisp in Production (2015) by TeMPOraL on Monday May 25, 2020 @04:15AM (#23299121)
Personally, I like Lisp the way it is. I fully agree with this image:

https://www.reddit.com/r/lisp/comments/e2e5o/lispovision/

Re:Running Lisp in Production (2015) by matvore on Sunday May 24, 2020 @03:54PM (#23294209)
> 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.

And it's not intrinsically less readable than say, something like: https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a0111...

Re:Running Lisp in Production (2015) by doublesCs on Sunday May 24, 2020 @05:01PM (#23294726)
> 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.

[1] https://docs.python.org/3.8/library/ast.html

[2] https://docs.julialang.org/en/v1/manual/metaprogramming/inde...

Re:Running Lisp in Production (2015) by ken on Sunday May 24, 2020 @09:24PM (#23296749)
"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:

    >>> parse("2 + 2")
    ['eval_input', ['testlist', ['test', ['and_test', ['not_test', ['comparison',
     ['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr', ['term', 
      ['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term', ['factor',
       ['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']]
"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."

-- Peter Norvig, https://norvig.com/python-lisp.html

Re:Running Lisp in Production (2015) by kgwgk on Sunday May 24, 2020 @05:17PM (#23294900)
That's not code as data, that's parsed code as data.

  julia>      :(a + b*c + 1)       ==
         Meta.parse("a + b*c + 1") ==
         Expr(:call, :+, :a, Expr(:call, :*, :b, :c), 1)
  true
Why not just use a single representation (+ a (* b c) 1) ?
Re:Running Lisp in Production (2015) by doublesCs on Tuesday May 26, 2020 @03:29AM (#23308352)
> 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.

Re:Running Lisp in Production (2015) by kgwgk on Wednesday May 27, 2020 @08:51AM (#23322380)
You've convinced me, there is no difference.

Why wouldn't anyone want to write code like this:

  Expr(:call, :+, :a, Expr(:call, :*, :b, :c), 1)
Re:Running Lisp in Production (2015) by snicker7 on Thursday May 28, 2020 @01:51PM (#23340241)
If you remove the Expr, you get something that kind of looks like Lisp.
Re:Running Lisp in Production (2015) by kgwgk on Thursday May 28, 2020 @02:29PM (#23340650)
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.

Re:Running Lisp in Production (2015) by voldacar on Sunday May 24, 2020 @10:31PM (#23297139)
python and julia's way of accomplishing this is infinitely uglier and more adhoc than lisp's
Re:Running Lisp in Production (2015) by protomyth on Sunday May 24, 2020 @08:02PM (#23296146)
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.

Re:Running Lisp in Production (2015) by mark_l_watson on Sunday May 24, 2020 @11:27PM (#23297497)
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.

Re:Running Lisp in Production (2015) by ByteJockey on Sunday May 24, 2020 @10:57PM (#23297305)
So, emacs?

We are talking lisp here. I don't think there's anything that compares.

Re:Running Lisp in Production (2015) by DoreenMichele on Sunday May 24, 2020 @03:40PM (#23294076)
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.

Re:Running Lisp in Production (2015) by _emacsomancer_ on Sunday May 24, 2020 @07:25PM (#23295868)
HN itself is written in a lisp.

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.

What makes it unreadable for you? The parentheses? (https://i.redd.it/9gwghrz9rcs11.jpg)

Re:Running Lisp in Production (2015) by mypalmike on Sunday May 24, 2020 @06:18PM (#23295380)
The reason is arguably this essay, written by a founder of ycombinator who many here wish to emulate or get the attention of.

http://www.paulgraham.com/avg.html

Re:Running Lisp in Production (2015) by egl2020 on Sunday May 24, 2020 @03:43PM (#23294103)
You're completely right, there's nothing for you in lisp. Nothing to see here. Just move on.
Re:Running Lisp in Production (2015) by Koshkin on Sunday May 24, 2020 @06:06PM (#23295272)
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).
Re:Running Lisp in Production (2015) by ByteJockey on Sunday May 24, 2020 @10:58PM (#23297318)
I haven't done C++ in a very long time.

That's a lambda that does nothing, right?

Re:Running Lisp in Production (2015) by Koshkin on Monday May 25, 2020 @09:25AM (#23300782)
Correct.
Re:Running Lisp in Production (2015) by pritovido on Sunday May 24, 2020 @04:27PM (#23294416)
I will explain it for you.

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.

Re:Running Lisp in Production (2015) by goto11 on Monday May 25, 2020 @05:22AM (#23299444)
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.

Re:Running Lisp in Production (2015) by avalys on Sunday May 24, 2020 @04:41PM (#23294512)
Could you give me an example of a real-world software engineering task which takes “weeks” in Python and minutes in Lisp?
Re:Running Lisp in Production (2015) by flavio81 on Monday May 25, 2020 @10:31AM (#23301487)
>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.

Re:Running Lisp in Production (2015) by srean on Sunday May 24, 2020 @05:34PM (#23295020)
Not weeks to minutes, but still, try writing an Airlines booking, scheduling application which gets the traveler the best route given his/her requirements.
Re:Running Lisp in Production (2015) by goto11 on Monday May 25, 2020 @05:06AM (#23299377)
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.

Re:Running Lisp in Production (2015) by lispm on Monday May 25, 2020 @07:28AM (#23300020)
The flight search was designed 20 years ago with the goal to disrupt mainframe-based flight search systems domain:

Here is some background on that particular application:

https://www.msri.org/people/members/sara/articles/airfares.p...

http://www.paulgraham.com/carl.html

> I suspect the issue is that a flight booking system is basically the only significant commercial system written in Lisp

How would you know that?

Re:Running Lisp in Production (2015) by goto11 on Monday May 25, 2020 @11:19AM (#23301960)
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.

Re:Running Lisp in Production (2015) by lispm on Monday May 25, 2020 @11:23AM (#23301986)
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.

Re:Running Lisp in Production (2015) by srean on Monday May 25, 2020 @09:48AM (#23301057)
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.

Re:Running Lisp in Production (2015) by andi999 on Sunday May 24, 2020 @07:20PM (#23295837)
Other people tried (and succeeded). Like Sabre (seems to be c++, but most is actually SQL it seems), or Amadeus.

Well, what I mean: can you elaborate a bit more?

Re:Running Lisp in Production (2015) by pge on Sunday May 24, 2020 @07:28PM (#23295892)
The reference is to ITA Software who wrote their code in lisp. The company was acquired by google.

https://en.m.wikipedia.org/wiki/ITA_Software

Re:Running Lisp in Production (2015) by andi999 on Monday May 25, 2020 @03:25AM (#23298848)
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.
Re:Running Lisp in Production (2015) by srean on Monday May 25, 2020 @09:49AM (#23301082)
ITA software would definitely be worth looking at, but you would need to get hired by the right team.

More details here http://www.paulgraham.com/carl.html you can also glean more information by searching over older discussions about ITA on HN.

Re:Running Lisp in Production (2015) by andi999 on Tuesday May 26, 2020 @03:07AM (#23308239)
This is really interesting. I am amazed by the circumvention of the GC for large data; this thought would have never occured to me.
Re:Running Lisp in Production (2015) by rbanffy on Sunday May 24, 2020 @07:29PM (#23295893)
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.
Re:Running Lisp in Production (2015) by rjsw on Sunday May 24, 2020 @08:20PM (#23296276)
I interviewed for a job working on Sabre in the late 80s, I was told it was written in C.
Re:Running Lisp in Production (2015) by rbanffy on Monday May 25, 2020 @07:52AM (#23300125)
I suppose it no longer runs on IBM mainframes either. The original 360 port was in assembly and a dialect of PL/1.
Re:Running Lisp in Production (2015) by andi999 on Sunday May 24, 2020 @04:34PM (#23294470)
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)

Re:Running Lisp in Production (2015) by jiyinyiyong on Tuesday May 26, 2020 @11:41AM (#23312511)
See S-expressions in another way like this http://cirru.org/ .
Re:Running Lisp in Production (2015) by fractallyte on Monday May 25, 2020 @04:32AM (#23299201)
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!

Re:Running Lisp in Production (2015) by memexy on Wednesday June 03, 2020 @06:13PM (#23409493)
Well said.
Re:Running Lisp in Production (2015) by fetbaffe on Sunday May 24, 2020 @03:15PM (#23293866)
I think you answered your own question.
Re:Running Lisp in Production (2015) by dirtnugget on Sunday May 24, 2020 @03:23PM (#23293926)
There is no good reason to use an esoteric language in production except in order to make yourself irreplaceable.
Re:Running Lisp in Production (2015) by capableweb on Sunday May 24, 2020 @03:26PM (#23293948)
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.
Re:Running Lisp in Production (2015) by dirtnugget on Sunday May 24, 2020 @03:28PM (#23293961)
The author himself says it’s esoteric
Re:Running Lisp in Production (2015) by lispm on Sunday May 24, 2020 @03:43PM (#23294104)
He didn't.

He wrote: 'Contrary to popular opinion, Lisp is an incredibly practical language for building production systems.'

[dead]
Re:Running Lisp in Production (2015) by lispm on Monday May 25, 2020 @06:52AM (#23299852)
I've read it.

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.

Re:Running Lisp in Production (2015) by dirtnugget on Sunday May 24, 2020 @03:31PM (#23293990)
Also, if you’re really willing to go into it you could be productive in Brainfuck. Doesn’t mean it applies to the general crowd.
Re:Running Lisp in Production (2015) by justbaker on Sunday May 24, 2020 @10:36PM (#23297169)
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
Re:Running Lisp in Production (2015) by dang on Sunday May 24, 2020 @03:35PM (#23294024)
Please don't do programming language flamewars on HN. They're tedious.
Re:Running Lisp in Production (2015) by mapcars on Sunday May 24, 2020 @05:57PM (#23295210)
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.
Re:Running Lisp in Production (2015) by bitwize on Sunday May 24, 2020 @11:54PM (#23297611)
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.

Re:Running Lisp in Production (2015) by zelphirkalt on Monday May 25, 2020 @03:15AM (#23298800)
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.

Re:Running Lisp in Production (2015) by mapcars on Monday May 25, 2020 @09:40AM (#23300963)
>Lisp is only used in niche applications

Which niche btw?

Re:Running Lisp in Production (2015) by pritovido on Sunday May 24, 2020 @04:33PM (#23294464)
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.

Re:Running Lisp in Production (2015) by potta_coffee on Sunday May 24, 2020 @04:38PM (#23294494)
How can one write C for example using lisp? Are you talking about compiling to C?
Re:Running Lisp in Production (2015) by lispm on Sunday May 24, 2020 @05:04PM (#23294765)
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.

https://web.archive.org/web/20150307034829/http://blogs.msdn...

Re:Running Lisp in Production (2015) by potta_coffee on Tuesday May 26, 2020 @12:25PM (#23313093)
Interesting, I was not aware of this, thank you.
Re:Running Lisp in Production (2015) by erik_seaberg on Sunday May 24, 2020 @04:43PM (#23294519)
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.
Re:Running Lisp in Production (2015) by Redoubts on Sunday May 24, 2020 @05:50PM (#23295155)
There's also onanism.
Re:Running Lisp in Production (2015) by dirtnugget on Sunday May 24, 2020 @03:23PM (#23293932)
And that’s the epitome of selfishness
Re:Running Lisp in Production (2015) by dirtnugget on Sunday May 24, 2020 @03:27PM (#23293953)
Re:Running Lisp in Production (2015) by bluefox on Sunday May 24, 2020 @03:52PM (#23294184)
Re:Running Lisp in Production (2015) by jlarocco on Sunday May 24, 2020 @04:37PM (#23294488)
Is it so hard to click "hide"?