[HN Gopher] Lisp as an Alternative to Java (2000)
___________________________________________________________________
Lisp as an Alternative to Java (2000)
Author : susam
Score : 114 points
Date : 2021-08-02 14:07 UTC (8 hours ago)
(HTM) web link (www.norvig.com)
(TXT) w3m dump (www.norvig.com)
| mark_l_watson wrote:
| He wrote this around the same time that he kindly reviewed and
| gave me comments on the first edition of my Java AI book. A year
| later we had lunch: I was using Common Lisp and Java for my work
| and I think that Peter was mostly using Python by then.
|
| Which programming language you choose really doesn't matter very
| much. Since 1982 Common Lisp has been my favorite language, but I
| have recently learned to also love Swift.
| abhinav22 wrote:
| Lisp is a wonderful language (Common Lisp in particular, but I am
| dabbling in Scheme now too), and absolutely fantastic for web
| development - seriously people should give it a chance in that
| space, I would totally develop any SPA in Lisp[1].
|
| QuickLisp is simply a joy to use, and the language is very
| portable with a fantastic specification and many top notch
| compilers.
|
| IMO, what holds it back is a lack of a top notch IDE. It took me
| a year of love & hate with Emacs, I can now make pretty good use
| of the amazing software that is Emacs (where everything can be
| changed), but honestly at times I want a simple point & click
| free IDE which is polished and does most things well and out of
| the box. Portacle is a step in the right direction, but the Emacs
| dependency IMO does make the language a bit more niche and lose
| out to other languages for beginners. If some big corporation can
| mix sublime with slime with paredit with some of the customize
| ability of Emacs, then Common Lisp could explode in popularity.
|
| Don't get me wrong - I LOVE Emacs and everything about Emacs & CL
| combined, but it took me a year to get to this point.
|
| [1] For those interested, I wrote this article covering the
| basics: https://ashok-khanna.medium.com/lisp-the-web-4c00c88d11f9
| neilv wrote:
| BTW, there's a small small-world coincidence, between a desire
| for an Emacs-based super IDE, and the original article...
|
| The desire for an Emacs-based out-of-box power-user IDE was how
| we got Lucid Emacs, aka XEmacs (which was one of the two big
| forks of GNU Emacs with GUI innovations that GNU took a while
| to catch up with)...
|
| ...from JWZ, et al.'s work on the Lucid Energize IDE for C++...
|
| ...and JWZ worked for Norvig early on...
|
| ...and Norvig was at Harlequin...
|
| ...and Harlequin acquired at least some of Lucid's IP.
| 37ef_ced3 wrote:
| I want to see an article:
|
| "Go as an Alternative to C"
| coliveira wrote:
| I think the whole issue of having a great programming language is
| a mute point in the current software industry, because average
| programmers don't know how to use it. That's why the winners have
| always be languages that appeal to the minimum common
| denominator, just the bare enough for people to write programers
| in the simple way they know. Lisp provide a lot of flexibility
| and power, but if programmers don't know how to use it, it is
| instead viewed as a liability.
| eric4smith wrote:
| No way. The ecosystem is just not there.
|
| All the libraries - both open source and commercial that do a
| million things - do not exist in the Lisp ecosystem.
|
| Even in 2000
| eatonphil wrote:
| Armed Bear Common Lisp (Common Lisp on the JVM) may be the most
| obvious choice if you prioritize ecosystem above all else
| (which isn't a bad thing).
|
| https://abcl.org/trac/
| gumby wrote:
| So true, but this class of comment always amuses me as in the
| 1980s one of the (many) criticisms leveled at Common Lisp was
| that its library support was _too big_.
| lmilcin wrote:
| The ecosystem is a function of popularity.
|
| Lisp isn't very popular because, at least in my opinion, it
| requires a relatively high level of maturity and experience to
| be used effectively on nontrivial projects.
|
| Every single project in Lisp (Common Lisp, Clojure) that I have
| observed ended in a disaster mostly because developers could
| not figure out what the strengths of Lisp are to realize the
| benefits and then killed themselves with too much freedom.
|
| Absent large enough number of success stories companies will
| default on Java because it is good enough language to be able
| to effectively realize typical enterprise application and dumb
| enough to be used by a beginner dev, even at the cost of
| boilerplate.
|
| At least that's the official story. It is really difficult to
| explain to business that you could do whatever they want with
| 1/5th or 1/50th of the amount of code if you just used a good
| language for it.
| coliveira wrote:
| I think it is a matter of education. Software developers
| learn to program in traditional languages, and Lisp is just
| an add on. So they really don't know how to use Lisp well.
| Languages like Python and Java benefit from all the formal
| education programmers have received in the concepts they use.
| mypalmike wrote:
| I think it's more fundamental than that. Reading and
| writing Lisp means turning your brain into an AST analyzer.
| Some programmers love this. Most don't.
| dimitar wrote:
| Now you have Clojure which runs on the JVM and interops nicely
| Scarbutt wrote:
| I wouldn't call it "nicely", there is lot of stuff that makes
| it really tedious.
|
| The bigger issue though is wasting time wrapping Java
| libraries and most comments I see about Clojure interop talk
| as if there is no cost to it.
|
| Clojure has good foundations but the ecosystem never really
| developed.
| dimitar wrote:
| You are not forced by the language to wrap libraries. In
| fact "Programming Clojure" by some of the authors says the
| following:
|
| "Clojure embraces java and its libraries. Idiomatic Clojure
| code calls Java libraries directly and doesn't try to wrap
| everything under the sun to look like Lisp. This surprises
| make new Clojure developers but is very pragmatic. Where
| Java isn't broken, Clojure doesn't fix it"
|
| So the ecosystem is a superset of the Java and JS
| ecosystems, which are pretty developed.
|
| I do agree that the cost of required to know 2 or 3
| languages is real though.
| finalfantasia wrote:
| > The bigger issue though is wasting time wrapping Java
| libraries and most comments I see about Clojure interop
| talk as if there is no cost to it.
|
| You are not forced to "waste time" wrapping Java libraries.
| As a matter of fact, thanks to the interop features that
| are well thought out, using Java libraries directly via the
| interop is encouraged and preferred to wrappers (Java Time
| API is a good example.) You may _choose_ to write wrappers
| for Java libraries if they make consuming these libraries
| in your code a bit nicer.
|
| > Clojure has good foundations but the ecosystem never
| really developed.
|
| There's no separate ecosystem for Clojure(Script). The
| established ecosystems such as JVM, .NET, and JavaScript
| _are_ the Clojure ecosystem. The creator of Clojure(Script)
| realized that it would be practically impossible to build
| an ecosystem from scratch without significant investment
| (Sun spent billions of marketing dollars alone in Java) and
| thus deliberately chose to make Clojure(Script) a language
| hosted on well-developed platforms such as JVM, .NET, and
| JavaScript. Also because of this focus on being a hosted
| language, he went to great lengths to ensure the interop
| with its hosting platforms is as seamless as possible. If
| you need an example for awkward interop with Java, try
| Scala.
| adamc wrote:
| Thank you for articulating my (limited) experience. It was
| a very leaky abstraction. I remember thinking "If this is
| it, Python wins."
| elwell wrote:
| And ClojureScript to interop with JS ecosystem.
| antonvs wrote:
| The year after he wrote this, Norvig joined Google and decided
| that Python was a good enough alternative. He posted a web page
| about it, but I can't find it rn. However, here's a comment of
| his on HN about it:
|
| https://news.ycombinator.com/item?id=1803815
| Jtsummers wrote:
| https://norvig.com/python-lisp.html
|
| This essay starts with the context of his choosing Python to
| express what was formerly pseudocode.
| dreamcompiler wrote:
| The philosophy of Lisp encourages writing your own libraries
| because it's so easy to do. You're expected to know how to
| program if you use Lisp; not to depend on tiny prewritten
| functions in the npm universe that may or may not solve your
| problem, that may or may not be written in a secure or
| efficient fashion, and that possibly pull in a million
| transitive dependencies you don't need.
|
| That said, Common Lisp itself includes many of the more useful
| but difficult-to-write features like hash tables, sort/merge,
| bignums, complex numbers, etc.
|
| The most-used stuff that's not in Common Lisp itself like
| multithreading and sockets are well-covered by external
| libraries. The lesser-needed stuff is also quite well covered
| by the quicklisp library infrastructure [0] as well.
|
| So the statement "libraries...do not exist in the Lisp
| ecosystem" is plainly false and it marks the speaker as someone
| not very familiar with Lisp.
|
| [0] https://www.quicklisp.org/beta/releases.html
| [deleted]
| [deleted]
| throw_m239339 wrote:
| > The philosophy of Lisp encourages writing your own
| libraries because it's so easy to do
|
| That statement could be said of any language the programmer
| is comfortable with. It's no more a LISP philosophy than a
| C++ one. The difference is that way more people are working
| with C++ (or Java) thus opensourcing their libraries for
| others to be used.
| jhgb wrote:
| I think the argument there was that lots of things were so
| much easier to do in Lisp that people wrote their own
| implementation, then they thought "what's the big deal
| about it?", and then they didn't share their library
| because they didn't think they've accomplished something
| meaningful to share. So you end up with people doing things
| in C++ and Java and publishing it and getting their code
| reused because 1) the authors of the code were more likely
| to think of publishing their code as a useful thing, and 2)
| due to some things being harder in those languages, other
| people were more likely to shop for libraries rather than
| to think "I can do this myself".
| coliveira wrote:
| But you just touched on the reason programmers don't like
| Lisp: they prefer a language that has a lot of little bits of
| available functionality that they can mix and match, without
| having to do any real programming. Programming, as we knew
| it, is a dead art, modern developers only want to reuse some
| library that was created by someone else. Languages like
| Python and Java are bad to program, but ideal for this kind
| of lego-based development.
| stormking wrote:
| This is ridiculous! When you want to write a book or just
| take some notes, do you want to make your own paper all the
| time? Mix your own ink? I see the appeal to do this once or
| from time to time, but if I have to scribble something
| down, I'm glad these are ready-made for me. Guess I'm just
| a lego-based author.
| AnimalMuppet wrote:
| Sure, libraries exist in Lisp. The claim that they don't was
| a fairly ridiculous statement. But...
|
| Do libraries exist in Lisp on the same scale as they exist in
| Java? Especially, do they exist with the same level of
| quality, professionalism, and maintenance as they exist in
| Java? I'm guessing that the answer is no.
| tralarpa wrote:
| > So the statement "libraries...do not exist in the Lisp
| ecosystem" is plainly false and it marks the speaker as
| someone not very familiar with Lisp.
|
| Sorry to be so blunt but this is ridiculous. You are
| mentioning hash tables and multithreading to prove your
| point. I am pretty sure this is not what parent meant when
| they wrote "The ecosystem is just not there". And what does
| "writing your own libraries because it's so easy to do" even
| mean? You still have to do it and it takes a lot of time and
| money. A library that talks a specific protocol to a medical
| devices. A library that writes some obscure data format used
| by some government somewhere on earth. This is the real
| world.
| andi999 wrote:
| Writing your own library also has the disadvantage that
| 100% of the new hires have never seen how to use that
| library.
| jhgb wrote:
| As opposed to "a library that talks a specific protocol
| to a medical devices" or "a library that writes some
| obscure data format used by some government somewhere on
| earth" which new hires wouldn't know how to use either
| because only a hundred people on Earth have ever used
| either of those?
| ashtonkem wrote:
| > The philosophy of Lisp encourages writing your own
| libraries because it's so easy to do.
|
| Having professionally worked in CL and Java, this is true and
| completely misses the point. Of course you can write your own
| libraries, the question isn't whether you can but whether or
| not that's a wise usage of your time and energy. Java gives
| me a ton of fantastic libraries out of the box that let me
| focus on my domain, which is a good thing!
|
| > You're expected to know how to program if you use Lisp; not
| to depend on tiny prewritten functions in the npm universe
| that may or may not solve your problem, that may or may not
| be written in a secure or efficient fashion, and that
| possibly pull in a million transitive dependencies you don't
| need.
|
| Sneering at people who use different languages is both a bad
| look, and a bad way to convince people that you're right. I'd
| recommend staying way clear of any suggestion that your peers
| don't know how to program.
|
| > The most-used stuff that's not in Common Lisp itself like
| multithreading and sockets are well-covered by external
| libraries. The lesser-needed stuff is also quite well covered
| by the quicklisp library infrastructure [0] as well.
|
| This is a pretty drastic understatement of how far behind
| Java CL is. Forget multithreading, think more about metrics,
| logs, configuration, A/B testing, retries/bulkheads/circuit-
| breakers, feature flags, and secrets management. All of this
| stuff I get for free out of Java libraries, often in
| automatically self configuring ways.
|
| Configuring a Kafka reader in my app and seeing that it
| automatically discovered Micrometer on my class path and
| started emitting metrics is a lovely experience. Switching
| metrics servers from InfluxDB to Datadog with a single code
| change was damn near nirvana.
|
| If CL wants to be a compelling alternative to Java for
| industrial use, it's got to catch up on all this stuff.
| jhgb wrote:
| > Sneering at people who use different languages is both a
| bad look, and a bad way to convince people that you're
| right.
|
| I'm pretty sure that this was a criticism of NPM rather
| than of any language.
|
| > Forget multithreading, think more about metrics, logs,
| configuration, A/B testing, retries/bulkheads/circuit-
| breakers, feature flags, and secrets management.
|
| I could understand logs and secrets management (if it's
| what I think you mean by that), but how do the other things
| relate to the language? Except for retries which I would
| have thought were much better integrated into CL then they
| could be in Java, given resumable conditions.
|
| > Configuring a Kafka reader in my app and seeing that it
| automatically discovered Micrometer on my class path and
| started emitting metrics is a lovely experience.
|
| Is this a thing that something like asdf-system-connections
| would solve in Lisp? (IMO also much more elegantly than by
| "discovering X on my class path".)
| ashtonkem wrote:
| > I'm pretty sure that this was a criticism of NPM rather
| than of any language.
|
| > You're expected to know how to program if you use lisp.
|
| Why would they say this if they weren't implying that NPM
| users can't program?
|
| > I could understand logs and secrets management (if it's
| what I think you mean by that), but how do the other
| things relate to the language?
|
| They don't, not directly. But it's the community for that
| language that makes and supports these things, and
| comparisons between these communities (and the libraries
| they share) is a fair area of analysis.
|
| > Except for retries which I would have thought were much
| better integrated into CL then they could be in Java,
| given resumable conditions.
|
| They could, but they have not to my knowledge. In my
| opinion the language's capability is far less important
| than a community that values creating and maintaining
| these libraries.
|
| (I also think functional programming aficionados
| drastically underrate how much Java has changed. There
| are still issues I personally whine about, but they've
| fixed a _lot_ of warts since the 1.6 days)
|
| Retries in particular are one of those things that seem
| obviously standalone, but are not. Having my retries
| automatically expose micrometer counters has been a
| godsend for monitoring. I'd like to see them
| automatically expose opentracing information too, which
| is an obvious area of opportunity for r4j.
|
| > Is this a thing that something like asdf-system-
| connections would solve in Lisp?
|
| The technical ability to make libraries auto-configure
| together is meaningless if the community doesn't have the
| will to take regular advantage of it.
|
| Frankly, Java the language is incredibly weak for this
| kind of stuff, yet the Java _community_ is busy doing it
| anyways. I'll remain unimpressed by interoperability
| improvements to CL so long as the culture of "roll your
| own libraries!" remains in place.
| jhgb wrote:
| > Why would they say this if they weren't implying that
| NPM users can't program?
|
| I'm pretty sure that numerous Quicklisp users can't
| program either, but Quicklisp is manually curated while
| NPM (AFAIK?) isn't so their code won't end up in
| Quicklisp.
|
| > You tell me.
|
| I'm not sure what there is to say. The ASDF extension in
| question allows you to write systems that get loaded when
| a specific combination of other systems gets loaded, so
| when there's some room for collaboration of multiple
| systems, all such code naturally belongs into that
| autoloaded system. It can assume the presence of all
| required systems and hook them up together. Is this
| something like what you're describing? Except for the
| "discovered Micrometer on my class path" part of course
| since you're not concerning yourself with any paths here
| (that feels a bit brittle to me) but the notion of doing
| something special when combining specific multiple
| libraries is supported on system loading level.
| ashtonkem wrote:
| > I'm pretty sure that numerous Quicklisp users can't
| program either, but Quicklisp is manually curated while
| NPM (AFAIK?) isn't so their code won't end up in
| Quicklisp.
|
| This interpretation of GP's comments strains credulity.
|
| As for the rest, I edited and expanded my unnecessarily
| glib response. The technical ability you mentioned is
| nice, but I will remain unimpressed until it sees wider
| use. This is a shortcoming in the CL community, not a
| shortcoming in the CL language.
|
| I'll change my opinion once I see evidence of the CL
| community coming together to value shared, reusable code
| to accomplish common tasks.
| jhgb wrote:
| I guess I'm just a very credulous person, then.
|
| Regarding asdf-system-connections, it would probably help
| if this were core functionality of ASDF. I don't get why
| it isn't yet, since it perfectly fits Lisp's overarching
| concept of independently defined things cooperating (cf.
| classes and generic functions, or multimethods). I might
| want to ask some people about that.
| ashtonkem wrote:
| It might, but I doubt it will. "Roll your own libraries"
| is so core to the CL community's self identity, that I
| doubt it will ever change within my lifetime.
|
| Honestly, if you want a modern Lisp experience, I'd
| recommend Clojure. Clojure doesn't philosophically align
| with my own preferences, but that community is very
| active and very invested in solving common problems as a
| community.
| jhgb wrote:
| I find Clojure awful both conceptually _and_
| implementation-wise (the imposition of lowest common
| denominators by JVM dependency really sucks here,
| starting with lack of tail calls, but not ending there),
| so that 's most likely not going to happen. I don't see
| why the good things in Clojure should be impossible to
| achieve in CL as libraries. You might argue that CL
| community should be working on those, and you'd be
| completely right.
| ashtonkem wrote:
| > I find Clojure awful both conceptually and
| implementation-wise (the imposition of lowest common
| denominators by JVM dependency really sucks here,
| starting with lack of tail calls, but not ending there),
| so that's most likely not going to happen.
|
| You do you, but I personally would do some thinking on
| why Clojure has eaten CL's lunch, despite your belief in
| its inferior design and implementation.
|
| (Edit: for the record I've worked professionally in CL,
| Clojure, Java, and some others. I think Java is best, but
| I think that your argument about Clojure being inferior
| to CL is incorrect).
|
| Also, tail calls? Really? Genuinely can't remember the
| last time that mattered to me.
|
| > I don't see why the good things in Clojure should be
| impossible to achieve in CL as libraries.
|
| I don't see why "impossible" would be a factor here. It's
| not technology that's holding CL back here, but rather
| what the community values and spends its collective time
| on.
| jhgb wrote:
| > but I personally would do some thinking on why Clojure
| has eaten CL's lunch, despite your belief in its inferior
| design and implementation.
|
| It's largely a similar reason why Java has eaten
| Smalltalk's lunch (upfront environment costs have been
| disastrous in the past for both Smalltalk and CL, and in
| many ways they continue to be - Allegro, LispWorks,
| VisualWorks are still expensive), plus the fact how
| Clojure latched itself onto Java's large ecosystem. For a
| large user base, inferior design and implementation don't
| matter as much, as PHP has demonstrated amply, so why
| should they matter here for a similarly large number of
| people? They won't mind, although some other might.
|
| > Also, tail calls? Really? Genuinely can't remember the
| last time that mattered to me.
|
| It's not the only thing deficient in Clojure, but I've
| noticed that many fairly common patterns get
| significantly more convoluted without them. If there's no
| drawback to having them, why not have them? Oh, wait, I
| forgot, JVM does not support them...
| dkarl wrote:
| > Of course you can write your own libraries, the question
| isn't whether you can but whether or not that's a wise
| usage of your time and energy. Java gives me a ton of
| fantastic libraries out of the box that let me focus on my
| domain, which is a good thing!
|
| This was a bug in the Common Lisp community in the early
| 2000s when I was getting started with it and looking to the
| community for help identifying libraries for common
| functionality. People were friendly and helpful, but they
| gently pushed me to accept that reaching for libraries was
| a habit I was bringing from other languages, and in Lisp I
| could (and should) write my own implementations for things
| like logging and date formatting. Sharing code was for big
| hard stuff, not easy stuff.
|
| Since then, it seems like people have put a lot of work
| into moving the community forward from that romantic
| approach to a more pragmatic one, but if I wanted to use
| Lisp now, I would scrutinize that aspect of Common Lisp
| very closely before getting back into it. I would lean
| heavily towards Clojure instead.
| nerdponx wrote:
| > The philosophy of Lisp encourages writing your own
| libraries because it's so easy to do. You're expected to know
| how to program if you use Lisp; not to depend on tiny
| prewritten functions in the npm universe that may or may not
| solve your problem, that may or may not be written in a
| secure or efficient fashion, and that possibly pull in a
| million transitive dependencies you don't need.
|
| Some people love to point out how stupid JS programmers are
| because of the left-pad incident.
|
| The reality is that, in almost every domain, there are _many_
| things which are either difficult and /or time-consuming to
| implement, or common across several projects and tasks. Do
| you _really_ want to waste your own time and the time of your
| teammates reimplementing these things for every project if
| you don 't need to?
|
| Even if the underlying implementation is "easy", having a
| handful of well-tested libraries with thoughtfully-designed
| APIs is important for productivity in many (most?)
| programming tasks. Yes, there might always be a specific case
| when you can't use the popular library for X, but that's the
| exception and not the norm.
|
| "It's easy to write your own libraries" is true in _any_
| professional-grade language. Arguably it 's one of the things
| that makes a professional-grade language professional-grade.
| It's not a justification for having a bad library ecosystem,
| it's a rationalization.
|
| As a side note, I think the Lisp library ecosystem in 2021 is
| pretty good, considering how unpopular it is in industry.
| lisper wrote:
| Actually they pretty much do, much more so now than in 2000.
| QuickLisp has been a real game-changer.
| nabla9 wrote:
| How many of those 1500 QuickLisp libraries work together
| without extra work?
|
| I seriously tried to use Common Lisp for numerical
| programming 10 years ago. It was faster and would have been
| better platform for numerical programming than Python, R or
| Julia. Just a great language. (Ross Ihaka had plans to port R
| into Common Lisp to make R fast at one point)
|
| The real problem was the lack of convergence of data
| structures and conventions above the language standard.
|
| Python has pandas tables and numpy arrays. R has Data frame.
| Every numerical library for CL had their own conventions, and
| ways to implement the basic data structure, Some used lists,
| some just arrays, some had list of vectors, classes, structs,
| property lists.
|
| The impedance mismatch was not worth it. Either implement
| numpy equivalent on your own or half of your code is data
| massaging data between libraries.
|
| --
|
| Perlis epigram: "9. It is better to have 100 functions
| operate on one data structure than 10 functions on 10 data
| structures."
| jhgb wrote:
| > How many of those 1500 QuickLisp libraries work together
| without extra work?
|
| I'm pretty sure that due to the curated nature of code in
| QuickLisp, there's really no problem with that. If
| something doesn't load properly, it's a bug that you should
| report.
| varjag wrote:
| > How many of those 1500 QuickLisp libraries work together
| without extra work?
|
| I'm not sure what kind of question is that. A whole bunch
| of them? Certainly not worse ratio than many contemporary
| or even modern languages. There's a lot less friction to
| get any random GitHub CL project working than say a Swift
| one.
| dreamcompiler wrote:
| >Either implement numpy equivalent on your own or half of
| your code is data massaging data between libraries
|
| I haven't tested this but here you go:
|
| https://github.com/numcl/numcl
| agumonkey wrote:
| There was an article in the 2000s from a dude looking at a
| graph library, java had 3 major players, non of them did what
| he needed (generics issues or similar). He ended up rolling his
| own.
|
| Things are not so simple
| neilv wrote:
| > _the directions said to code as you would professionally, and
| that means I should comment my work._
|
| Were this a "professional" component/service, in perhaps the
| majority of situations today, he'd probably separate his docs
| into _two_ kinds of documentation: the committed interface /API
| _what_ , and the internal maintenance _how_.
|
| The docstring for `print-translations`, for example, conflate
| these two kinds.
|
| Incidentally, by 2000, Java had emphasized reuse API
| documentation for a few years, with how it presented Javadoc for
| both the core Java API and layered development, from the start.
|
| By contrast, Lisp environments that exposed docstrings in IDE
| hypertext, like Emacs did, did some doc things better than Java
| for decades before, and are still really well-suited to army-of-
| one genetically-enhanced supersoldier Lisp hackers.
|
| Enterprise development, SaaSes, microservices, large systems with
| multiple teams, etc., were arguably better off heading in the
| more software engineering direction that Java was going.
|
| (Which is not to say that Lisps can't do the what&how docs
| separation. I've done a few embedded API docs things for Scheme
| and Racket that initially were inspired by Javadoc, Perl, and
| some of the less-commonly-used embedded docs setups for other
| languages. And have worked on a couple large Lisp systems that
| arguably wouldn't have been possible in a language without some
| of the Lisp family's other still-unusual strengths, nor without
| the highly-skilled developers that Lisps seem to attract
| disproportionately.)
| dang wrote:
| Some past threads:
|
| _Lisp as an alternative to Java (2000)_ -
| https://news.ycombinator.com/item?id=26720403 - April 2021 (94
| comments)
|
| _Lisp as an Alternative to Java - Faster, More Productive_ -
| 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 - July 2016 (103
| comments)
|
| _Lisp as an Alternative to Java (2000) [pdf]_ -
| 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 - Oct 2014 (55
| comments)
|
| _Lisp as an Alternative to Java_ -
| https://news.ycombinator.com/item?id=3447101 - Jan 2012 (37
| comments)
|
| _Lisp as an Alternative to Java [PDF]_ -
| https://news.ycombinator.com/item?id=61320 - Sept 2007 (9
| comments)
| sophacles wrote:
| Thanks dang - i appreciate when you post these, particularly on
| perennial topics: it's interesting to look back and see how the
| crowd's wisdom has(n't) changed.
| [deleted]
___________________________________________________________________
(page generated 2021-08-02 23:01 UTC)