[HN Gopher] Running Lisp in Production (2015)
___________________________________________________________________
Running Lisp in Production (2015)
Author : lisper
Score : 102 points
Date : 2020-05-24 16:55 UTC (6 hours ago)
(HTM) web link (www.grammarly.com)
(TXT) w3m dump (www.grammarly.com)
| jgwil2 wrote:
| From 2016
| cpach wrote:
| 2015, no?
| jgwil2 wrote:
| Yep, I guess I saw June 26, 2015, and flipped the 5 and the
| 6. Thanks.
| dirtnugget wrote:
| 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.
| matvore wrote:
| > 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...
| doublesCs wrote:
| > 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/i
| nde...
| kgwgk wrote:
| 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) ?
| jlarocco wrote:
| Is it so hard to click "hide"?
| Koshkin wrote:
| 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).
| DoreenMichele wrote:
| 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.
| mypalmike wrote:
| 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
| egl2020 wrote:
| You're completely right, there's nothing for you in lisp.
| Nothing to see here. Just move on.
| fetbaffe wrote:
| I think you answered your own question.
| dirtnugget wrote:
| There is no good reason to use an esoteric language in
| production except in order to make yourself irreplaceable.
| pritovido wrote:
| 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.
| potta_coffee wrote:
| How can one write C for example using lisp? Are you
| talking about compiling to C?
| lispm wrote:
| 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.m
| sdn...
| erik_seaberg wrote:
| 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.
| dang wrote:
| Please don't do programming language flamewars on HN.
| They're tedious.
| Redoubts wrote:
| There's also onanism.
| mapcars wrote:
| 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.
| dirtnugget wrote:
| And that's the epitome of selfishness
| dirtnugget wrote:
| Remember Rick:
|
| https://link.medium.com/iRs4xvGXK6
| bluefox wrote:
| Here you go https://plaster.tymoon.eu/view/678
| capableweb wrote:
| 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.
| dirtnugget wrote:
| The author himself says it's esoteric
| lispm wrote:
| He didn't.
|
| He wrote: 'Contrary to popular opinion, Lisp is an
| incredibly practical language for building production
| systems.'
| dirtnugget wrote:
| 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.
| TeMPOraL wrote:
| "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.
| pritovido wrote:
| 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.
| andi999 wrote:
| 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)
| avalys wrote:
| Could you give me an example of a real-world software
| engineering task which takes "weeks" in Python and minutes in
| Lisp?
| srean wrote:
| Not weeks to minutes, but still, try writing an Airlines
| booking, scheduling application which gets the traveler the
| best route given his/her requirements.
| [deleted]
| rusabd wrote:
| 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 :)
| phoe-krk wrote:
| Previous discussions:
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
| dang wrote:
| You can add "comments>0" to get the ones with comments:
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
| [deleted]
| capableweb wrote:
| 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?
| dang wrote:
| 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:
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&qu
| e...
|
| The latter creates much cleaner search results if you want
| to match just on title and URL.
| naveen99 wrote:
| Finally read the reference on lisp reader macros :
| http://www.lispworks.com/documentation/HyperSpec/Front/X_Mas...
|
| Now I sort of get what #+unix means...
| reikonomusha wrote:
| #+foo A B
|
| 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 #ifdef foo A
| #endif B
|
| The opposite is #-. #-unix A B
|
| is roughly #ifndef unix A
| #endif B
|
| So you can write portable source code this way.
| (defvar path-separator #+unix "/" #+windows
| "\\" #-(or unix windows) (error "idk"))
|
| This will define a variable called PATH-SEPARATOR which is /
| for UNIX, \ for Windows, and a compile-time error otherwise.
|
| The rabbit hole goes deep on this. There's a reason it uses
| '#', and as you pointed out, it has to do with built-in
| (dispatching) reader macros.
| gumby wrote:
| 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).
| lisper wrote:
| #+ 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:
|
| http://flownet.com/ron/lisp/djbec.lisp
|
| for an example. Scroll down to the definition of xpt-add.
| jlarocco wrote:
| 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.
| TeMPOraL wrote:
| The common thing done with it is: #+nil(this
| expression (won't be read))
|
| (Also done with #+and, and #+or.)
|
| 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.)
| dang wrote:
| See also:
|
| 2019 https://news.ycombinator.com/item?id=20814511
|
| 2018 https://news.ycombinator.com/item?id=16860646 and
| https://news.ycombinator.com/item?id=16679963
|
| Discussed at the time:
| https://news.ycombinator.com/item?id=9785944
|
| Edit: also https://news.ycombinator.com/item?id=23231701 from a
| few days ago.
| faq125 wrote:
| Thank you for the links, what a nice discussion back in 2015.
|
| Everything has gotten more corporate. I hardly dare to make a
| Lisp comment now, because people from $BIGCORP would jump on
| it.
| dang wrote:
| 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 then connect the
| dots with material drawn 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:
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que.
| ..
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que.
| ..
| [deleted]
| ngcc_hk wrote:
| 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.
| codersfocus wrote:
| 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.
| dirtydroog wrote:
| Earlier? I still get them
___________________________________________________________________
(page generated 2020-05-24 23:00 UTC)