Why Lisp Failed (2010) - <AUTHOR> https://locklessinc.com/articles/why_lisp_failed/ <comment><USER4> I think Lisp failed because it had no killer app. Most developers don't pick a language, they pick a project and the select the most appropriate language.

Web frontend -> Javascript

Unix / Linux -> C

Wordpress plugins -> PHP

Windows apps -> .Net

iOS -> Objective C / Swift

Android -> Java

In my entire career (25 years), I've never had a project that directed me towards learning Lisp. This pretty much leaves Lisp to the type of developer that seeks out new languages and is willing to spend the extra effort integrating, and that's a pretty small number of developers.

If Lisp was in the browser instead of Javascript, it would be popular no matter the complaints about the language.

<comment><USER5> That still doesn't explain Java's popularity as a backend language. Unless J2ME or Applets was the killer app.

<comment><USER6> Java features that have yet to show up in other languages: Scalability - <USER2> horizontal and vertical. Memory utilization (you can have humongous heaps without having to worry about managing all that memory). Managability - <USER3> to "divide and conquer": you can plop a jar and start using it right away. Something that's practically impossible in other languages. Third party ecosystem (both free/oss and paid). Speed. Java is one of the fastest managed languages.

Yes it is verbose, yes inexperienced developers do the wrong things, but it does a great job preventing you shooting yourself in the foot, and most importantly, once you have a stable codebase, it can keep running for months/years.

<comment><USER5> > you can plop a jar and start using it right away

I'm mostly a Java developer, so I think this explains why Docker always looked a little silly to me. I also write some Python, and once I have to set up a virtualenv, that's when Docker's existence makes more sense.

</comment></comment></comment></comment><comment><USER7> Lisp has never been noticeably better overall.

\- In the past, it was better at abstraction, but slow and niche and you needed to shell out for hardware.

\- In the present it is _not better_. Common Lisp is about on a par with Python in what it has built in, inferior in its ecosystem, and for some modern stuff (threads, sockets) you will have to go outside the language standard into the wild west of implementation extensions or third party libraries.

Lisp's one big selling point is macros. Macros are magic that lets you reprogram the language. Reprogrammed languages break the ability of a programmer to drop in and read the code. Languages that need reprogramming to get basic shit done are unfinished or academic (Scheme). Languages that can get stuff done, but tempt you to reprogram them are attractive nuisances (Common Lisp, Ruby). In use, they create incompatible tangles that don't mix well with other people's incompatible tangles. I have been bitten by this repeatedly in Ruby. But Ruby is still easier to get work done in than Common Lisp.

Basically it died of being meh with a side of footgun.

<comment><USER8> >Common Lisp is about on a par with Python in what it has built in, inferior in its ecosystem

about 20x+ faster than Python, too; speed in the same order of magnitude than C.

>and for some modern stuff (threads, sockets)

pretty amazing you bring out threads in this comparison, when Python doesn't even support true multithreading.

>Macros are magic that lets you reprogram the language. Reprogrammed languages break the ability of a programmer to drop in and read the code.

It's the other way around. Lisp macros allow to eliminate boilerplate and produce clearer code. This is obvious to any lisper.

<comment><USER7> For reference, I'm not holding up Python as a good language, I'm holding it up as a _comparable_ one. Python is warty and creaky, but more mainstream than CL, so it's a fair comparison.

A _good_ language would be Go.

<comment><USER9> As a Common Lisper (among others) interested in language design, I've just started reading up on Go, after I've been told it's "simple, robust, safe, well-designed".

Purely subjectively, alot of what I'm seeing in Go so far looks to me like a "2nd system design" for C programmers. I'm hoping that the concurrency model is where it shines through with some good new ideas and implementations because I've been relatively unimpressed with the rest of it so far. That's not to say it's bad per se, but I've seen nothing in it that makes it stand out from other languages design-wise, and it feels rather warty to me so far...

Purely my own subjective opinion.

<comment><USER10> > looks to me like a "2nd system design" for C programmers

That seems fairly accurate.

> I'm hoping that the concurrency model is where it shines

I'd say that channels aren't quite the magic thing they are made out to be and goroutines aren't that amazing. The real win of go for me is three things:

1\. Evented runtime with a synchronous interface. "Go is my favorite epoll library"

2\. A standard lib that has great http support (things like keepalive and connection pooling and http2)

3\. A build and test toolchain that makes coverage and race detection and memory and CPU and lock contention profiling trivial.

</comment></comment></comment></comment></comment><comment><USER11> Most of my day to day work is in python, but I have a number of projects in Racket and have been dabbling with common lisp. I think the author is simply incorrect here. Other algol like languages offer the illusion of understanding, but then you get things like 'patterns' where even though in principle you know what the atomic elements of the language mean you are confronted with an undocumented 'pattern' that you have to puzzle out to understand what the code is actually trying to do. Lisp provides structure for these patterns in the form of DSLs, and if that means someone has to confront that they don't know something, at least it whacks them in the face rather than giving them the illusion of understanding. More importantly lisps provide a way to formalize, specify, check, and document the pattern.

So if lisp failed for some internal reason then I don't think it was for the reason the author specifies. What should worry people more is that a language that is better in 99% of cases can fail for reasons that have nothing to do with its technical merits, but purely by accident of history or as a result of politics unrelated to those technical merits.

Trilobites were the most diverse clade in the history of the earth. Trying to rationalize why they went extinct by studying their anatomy is going to be fruitless. Same with LISP.

</comment><comment><USER12> This is a really loose definition of "failed". His definition of failed seems to be "didn't take over the world"... but most things don't. It'd be like saying "John Smith failed at life because he wasn't a billionaire by age 25". As a language it was (and is) used in a lot of places, had a lot of offspring, and brought a lot of influential ideas into the world. That doesn't seem like a failure!

<comment><USER13> Considering the number of people who have bemoaned over the years how Lisp never became mainstream, I think it's fair to say that it failed compared to what its enthusiasts wanted.

<comment><USER14> I think enthusiasts are separated from the mainstream by definition

</comment></comment></comment><comment><USER15> Did it? People seem to use Clojure a lot, other dialects are popular with hobbyists, and some of the most enduring computer science books of all time use it. How many other languages from the 50s can claim that kind of wide use?

Aside from that, as the author points out, ideas from Lisp have made their way into almost every widely-used language today. It's fingerprints are everywhere. That doesn't sound like a failure to me.

<comment><USER16> I often daydream about an alternate universe where the entire Lisp community unified behind Clojure, built other runtimes for it, etc. I wish we could do that, because it would become a force to be reckoned with. Clojure is perfectly designed and positioned for success in the industry, the real problem for lisp is that the community is so fragmented.

<comment><USER17> I too have a similar dream, though it already has a few good runtimes but the more the merrier, compiling to native via graalvm recently was too cool

<comment><USER16> Wow wait that's a thing? I haven't kept up with Clojure for about a year. What runtimes are available? Is there one that doesn't run on a VM?

<comment><USER17> Graalvm can compile a native binary for all major OSs that does not contain the JVM but does run the substratevm which generates binaries in the order of tens of megabytes (2 in my case) it eradicates JVM startup time so now things like scripting is viable without using JS

Runtimes for Clojure include JVM, JavaScript engines, .NET then there are less popular runtimes like Go Erlang python? realistically I'd use one of the first three till the community is bigger

I don't know another language with as much practical reach as Clojure has

<comment><USER8> >Runtimes for Clojure include JVM, JavaScript engines, .NET

Except that they don't support the same Clojure language.

ClojureScript is a success, and code written for the JVM Clojure won't necessarily run on ClojureCLR.

Clojure's overreliance on the JVM at the very core was a bad decision.

Take Common Lisp: the exactly same language runs on the JVM, native machine language (many platforms), and LLVM, with zero code changes required.

<comment><USER8> * typo: ClojureScript is a _subset_

It is also a success, on the other hand. It's a good alternative to Javascript.

We also have a subset of Common Lisp that can be statically compiled to javascript: Parenscript. And a subset of CL that runs on the browser as a lisp implementation: JSCL.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> > So what is the problem with creating domain-specific languages as a problem > solving technique? The results are very efficient. [...] It results in many > sub-languages all slightly different. This is the true reason why Lisp code > is unreadable to others.

> The reason Lisp failed was because it fragmented, and it fragmented because > that was the nature of the language and its domain-specific solution style.

The main points above can be solved with two things:

1\. A more opinionated base language with batteries (e.g. Clojure)

2\. A package manager shared by users of the language

Ruby is expressive and has the DSL failure modes as lisp (though usually not as low-level), but it starts with a more batteries-included base. If it wasn't for Rails and gems leading the way to normalized usage Ruby would not be as successful as it is today.

<comment><USER19> Sorry but that's just wrong. He is complaining about DSLs making things hard to read. That's not fixed by switching to another language or a package manager. That's purely a software engineering problem - nobody forces you to write code in that style.

And LISP code being unreadable to others - sorry, that's bull. Seen e.g. some "modern" Javascript stuff recently? Good luck making heads and tails out of some of the frameworks - it often doesn't even look like a Javascript anymore! And nobody seems to be claiming that it leads to the demise of the language. Or numerical calculations in Fortran - still a gold standard for scientific stuff.

To me the article is very much an output of someone who couldn't have been bothered to learn the language griping about things he doesn't really understand well and making huge generalizations based on that.

Why LISP isn't popular today is simply because that unlike for other languages, there hasn't been a free/cheap compiler and IDE for a PC for a very long time (except for the crippled LispWorks). LISP has always been an university/research thing running on either on specialized machines or later on Unix, not something "mere mortals" had access to.

Also most programmers have been taught languages like Pascal/C/Java, maybe Scheme in their introductory courses and have never been exposed to LISP, so they have no way to know about it unless they are themselves curious about it.

<comment><USER20> > there hasn't been a free/cheap compiler and IDE for a PC for a very long > time

CCL is a free Common Lisp compiler that runs on Mac, Windows, and Linux. On the Mac, it comes with an IDE. It's been around for about 20 years.

SBCL is another free compiler that uses Emacs/Slime as an IDE.

<comment><USER21> I agree that CCL and SBCL are superb on Linux and Mac. But until at least a few years ago, they were both poorly supported on Windows (requiring something like Cygwin). That may have changed now. Also, AFAIK, CCL is dying now. :(

<comment><USER8> >AFAIK, CCL is dying now

CCL is the 2nd most downloaded Lisp implementation, so it can't be called "dying."

You'll find that new lisp projects are almost invariably tested on CCL too.

<comment><USER21> The latest commit is 2 months ago.[1] I don't know how to define "dying," but it doesn't seem healthy.

It saddens me, as it is/was a great tool for me for many years. I hope SBCL can take it from here.

1\. [https://github.com/Clozure/ccl](https://github.com/Clozure/ccl)

</comment></comment></comment></comment></comment></comment><comment><USER22> Lisp hasn't failed. Software engineering has failed to reach the conceptual level that Lisp operates at.

<comment><USER20> This is precisely correct IMHO. Lisp was designed for single programmers managing their entire stack (including the compiler itself) rather than for teams mostly gluing libraries together. Modern software engineering practices are focused on lower-level languages that don't give programmers the power of Lisp.

[Herein I mostly mean Common Lisp when I talk about Lisp. I have no experience with large projects in Clojure or Scheme.]

Most modern software -- Lisp programs included -- is written by multiple programmers in both coordinated and uncoordinated teams. Lisp can easily adapt to team programming but SWE needs to be augmented to handle programming projects that operate at a meta-level, which is natural with Lisp. If you write code at a meta level with ordinary SWE it can lead to disaster.

SWE needs tooling, procedures, and policies to deal with macros, package naming, bootstrapping, multiple-inheritance classes and first-class methods, etc. before it can really support Lisp. Lisp projects that have added such SWE features manually tend to succeed; those that don't tend to have difficulty with Lisp. My point is the team has to do the SWE work; SWE tools operating in default mode tend not to be good enough for Lisp.

<comment><USER23> > Lisp was designed for single programmers managing their entire stack

Funky, McCarthy had a whole team working on and with Lisp.

<comment><USER20> So did Symbolics. And most of those programmers had full-stack mastery. That's not the case with modern software engineering projects. Nor did McCarthy or Symbolics have to deal with the manager-friendly buzzword salad that permeates most software projects today.

<comment><USER23> > those programmers had full-stack mastery.

After many years working in that environment...

</comment></comment></comment></comment></comment><comment><USER24> It's difficult to agree with the idea that VB displaced COBOL. Even if this were the case, it certainly wasn't because COBOL compilers were expensive compared to "a cheap interpreter" that came with the machine. COBOL compilers surely were expensive, but they were also intended for mainframes rather than PCs. Also, I don't remember VB ever coming packaged with Windows for free. VB has been a part of Visual Studio for as long as I can remember and I don't believe there was a free version of until around VS2005.

Lisp, it turns out, is a weird and challenging language. It takes a little extra before you start to see the exciting bits. Unfortunately, until you reach that point, it's a matter of struggling with the parts around it - namely the editor. Lisp and Emacs go hand in hand, and while today you can rely on other editors to competently work with Lisp code, 20 years ago I don't think this was the case.

So now a user has to pick up Lisp (challenging when viewed through the lenses of either VB and COBOL) and Emacs (positively baroque if your only experience is within a GUI and IDE). I'd venture to guess that getting a functional Lisp environment running on a 286/386 era PC was probably a challenge in itself for most people.

Now consider VB or Java, significantly more familiar languages that didn't effectively depend (at the time) on the features of their editor or IDE. Both were a mouse-click away as far as installation, and Java didn't cost anything. Both were backed by large organizations that had a lot of incentive to invest and convince people to use their particular thing.

Lisp was this weird, mostly academic, language intended to tackle relatively esoteric rather than business problems, that was Unix only at a time when PCs and Windows were taking off. It doesn't seem unusual to me that it didn't take over the world. Frankly, I'm surprised and thankful that it's still around, actively used, and even sporting a significant community.

<comment><USER25> > _while today you can rely on other editors to competently work with Lisp > code, 20 years ago I don 't think this was the case._

I've been doing Lisp for just about that many years and have used nothing but Vim. Its Lisp support is built off :set lisp mode which is in the original Unix vi. It does a good job of syntax coloring, indentation and all that.

To reindent a block of code in Vim, I just put the cursor on one of the parentheses, then hit =% . The odd time there is a stylistic disagreement (like Vim wanting to align the arguments of something as if it were a function, rather than let-like).

My Lisp implementation, TXR Lisp, comes with a comprehensive Vim syntax file.

When you browse the sources using CGIT, all the syntax coloring you see is performed by Vim, being used on-the-fly as a back end for HTML generation.

E.g.: [http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/defset...](http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/defset.tl)

<comment><USER26> > =%

Yikes. I've been using vi forever and that never occurred to me. I just tried it on my own config and it works just as you say. I hope it is configurable, 'cos it doesn't fully agree with my habits (although maybe that's a fault of my own, and not vi(m)'s!)

Best thing about HN comment threads is that these gems keep happening.

<comment><USER25> I used that on C code before Lisp: jump from { to } or _vice versa_ , while reindenting.

Whether you get this alignment:

      (oper args
        blah blah)

or this one:

      (fun arg arg
           arg arg)

depends on one very simple configuration: the _lispwords_ variable. All the identifiers listed in _lispwords_ are given the former treatment.

Then there are minor squabbles like what happens with the _t_ clause in _cond_.

A lot of the time I just use visual select and =.

Also, in Vim, when you reindent multiple lines, it basically assumes that the first one is indented right; it will not move it relative to it predecessors.

You often have to hit == on the first line to get it into alignment, and then %= (or whatever) to reindent the range below it. E.g.:

       (let ((x y))
       (blah        ;; here we type ==
         blah blah
         (foo bar
              boo))

       (let ((x y))
         (blah      ;; now %=
         blah blah
         (foo bar
              boo))

       (let ((x y))
         (blah
           blah blah
           (foo bar
                boo))

</comment></comment></comment></comment><comment><USER27> The crust of the article is:

> The reason Lisp failed was that it was too successful at what it was > designed for. Lisp, alone amongst the early languages was flexible enough > that the language itself could be remade into whatever the user required. > [...] However, the process causes Balkanization. It results in many sub- > languages all slightly different. This is the true reason why Lisp code is > unreadable to others. In most other languages it is relatively simple to > work out what a given line of code does. Lisp, with its extreme > expressibility, causes problems as a given symbol could be a variable, > function or operator, and a large amount of code may need to be read to find > out which.

And I perfectly agree. You can see it in tutorials too. You can even see it in any Lisp-lover comments showing you a proud snippet of how "it can be solved better with lisp": it's too clever.

A little bit of clever is fun, it's good for the soul, it can even be productive. But Lisp is just a big pile of cleverness.

Being clever is so appealing to my geek nature. It's so cool. Yet experience (in coding and life) taught me it is not a good property to build a community around. Or a project for that matter.

At best, it's something that can emerge from a battle against long and arduous stream of problems. And then you can rest, you try to factor away the cleverness. But not as a goal. Not as a basic proposition.

<comment><USER28> Do you have examples of otherwise well regarded Common Lisp software that has the criteria you state?

People have used Lisp cleverly, but most modern libraries are a bunch of functions and classes. Sometimes more foreign features are used, like macros or even reader macros, but they do so to help one express him/herself. Even the open source Common Lisp compilers, written by arguably the lispiest of Lispers, don't have a lot of "cleverness". Check out SBCL, CCL, or ECL.

Some of the prolific library writers—Weitz, Fukamachi, Hafner (aka Shinmera), Strandh, Beane, etc.—all produce good libraries and good code, and aren't at all as you describe. Check out Hunchentoot (a web server), Clasp (a new CL compiler), CL-PPCRE (regex library), Radiance (a web framework), Quicklisp (package manager), ... These are all easy to jump into and relatively easy to understand if you know the domain.

Even if you go back and look at the Symbolics sources, there really isn't a lot of cleverness.

If the complaint is that some lone wolf programmers write obscure code, then I'm not sure what's to worry about. Somebody's lone wolf code isn't what you're going to be importing or depending on.

I hear this opinion you state somewhat often by drive-by comments, but I never see examples, just anecdotes.

<comment><USER26> Don't write clever. Write clear.

</comment></comment></comment><comment><USER29> I use Common Lisp for most of my development now that I am (mostly) retired, so I admit some bias. Given that:

Common Lisp tooling is very good and there is an active community of users. I argue that Haskell is really a Lisp language, at least it seems so to me. Also, so many good Lisp-y things are in Ruby, Python, modern JavaScript, etc.

I think language selection for a project is a process of making trade offs. I am happy that it is a free world to develop using whatever languages and tools we want. I try very hard to never judge anyone on their politics and I try to do the same in programming language wars.

</comment><comment><USER30> Are there examples of languages that were not popular for a long while before suddenly going mainstream (the definition of success from the article)? I feel like even a potential killer app is not enough, there were some interesting web frameworks for smalltalk (like seaside) but it wasn't enough to shake in any way the feeling that the language was a dead end for most people (and they can just wait for a reimplementation in a popular or new hyped language if it's really a good idea).

Phoenix/Ecto for example would probably not get the attention it gets (and deserves) if it focused on Erlang instead of a new language with some momentum. And Lisp seems to get it even worse when all of them (old and new, with as many programming paradigms as there can be) get grouped together as one 60 year old language family. Hopefully clojure, racket and other newcomers can turn this around.

<comment><USER31> Ruby was created in the mid-90s, long before Ruby on Rails became the killer app.

<comment><USER30> Yes, I was thinking about that case. While Ruby was comparatively still a modern language at that point, Rails used the metaprogramming of the language to effectively create a new unique language on top of it with it's opinionated design. It might be even a point in favor of Lisp, since even in an older language like Common Lisp it can still be possible to build a new language on top that feels modern, maybe some kind of tidyverse environment for handling the next AI wave paradigm whatever it may be.

</comment></comment></comment><comment><USER32> Paul Graham suggested in 2004 that not having an O'Reilly book was a real factor:

[http://www.andrewlangman.com/articles/the-missing-lisp- book....](http://www.andrewlangman.com/articles/the-missing-lisp-book.html)

<comment><USER33> Can you guess the animal that should have been on the cover?

[http://www.maclisp.info/animal/](http://www.maclisp.info/animal/)

[https://www.donhopkins.com/home/archive/lisp/animal.l](https://www.donhopkins.com/home/archive/lisp/animal.l)

<comment><USER32> Maybe given the age and longevity of the language and the creature, the tuatara would be the appropriate cover animal. (It is in the animal.l source.)

</comment></comment></comment><comment><USER34> 1\. The more I dig into Lisps, the more I find Lisp is not a language. 'Lisp' is more like the term 'C-like'.

Common Lisp, Scheme, and Emacs Lisp are way too different from each other. It's more like a comparison with C++, JavaScript, and Bash. Common Lisp is hardly a functional programming language. Emacs has no lexical scope (This really made me freak out). Clojure is a more qualified functional programming language.

2\. Lisps, for example, Scheme was superior to other languages decades ago. But now, as you can see JavaScript is basically a Lisp without macro (Yeah I know HN guys don't like JavaScript, but I choose JavaScript because it's a footgun language like Common Lisp and Emacs Lisp). Or just Elixir, basically a Lisp without paren syntax.

3\. Lisp never dies, there will be more. It will march forward as the industry moves. The Lisp syntax means the ease of parsing and macro design, and people will combine this feature with other features. There are already:

a) Functional Lisps like Clojure b) Carp, a Lisp without GC, there were also Linear Lisp c) WASM, an assembly with S-expression d) I have already seen other prototypes with static types/dependent types/monadic macro systems etc.

<comment><USER23> > Emacs has no lexical scope

it has now

[https://www.gnu.org/software/emacs/manual/html_node/elisp/Le...](https://www.gnu.org/software/emacs/manual/html_node/elisp/Lexical- Binding.html)

</comment></comment><comment><USER35> I've been using Lisp off and on for pretty much my entire adult life... at least since the mid eighties. It doesn't seem like a failure to me.

</comment><comment><USER36> LISP didn't fail. It released plenty of spores which modified the chromosomes of the rest of the language ecosystem.

The original LISP body then went into suspended animation, and may reappear in an evolved form at some point in the future.

</comment><comment><USER37> Add (2009) to this article.

[https://locklessinc.com/articles/](https://locklessinc.com/articles/)

</comment><comment><USER38> Right now I'm using Lisp for a hobby project. I find it actually really enjoyable. Lisp's metaprogramming support is super powerful. I'm the kind of developer who likes to explore different styles of programming. If you're like me, Lisp will not fail you. It really is a "programmable programming language".

For example, Lisp is not purely functional, but if you want to force yourself to program in a bit more of a functional style, you can make a macro that disallows the use of 'setf' (Lisp's assignment operator) in a function body, and it's actually quite easy to do that!

Maybe Lisp 'failed' because it's too flexible. You can solve your problem in a million different ways. Arguably, that is not a good thing in industry where it is preferred to have a language that enforces a single style on your code base for consistency across developers. However, I'd argue that it is very good thing for a creative individual. You want to have the freedom to do things your way.

From what I've experienced so far, Common Lisp offers a unique combination of customize-ability, utility, and interactivity. It's been around long enough for it to have a significant amount of libraries, and it has a multi-threaded REPL (so you can run your main loop and hot-reload your code-updates at the same time, how cool is that?!).

As for the parentheses... yes, I can see why Lisp code would be hard to read. On the other hand, with the right editor extensions (parinfer) it's really easy to edit, and you don't even need to think about the parenthesis when doing it. The documentation is alright I'd say, you can find plenty of stuff online.

Not sure what else I can say. I'm having a good time with CL... I'll try not turning into a 'smug lisp weenie'?

</comment><comment><USER39> Elephant in the room: the hostility of the LISP community. Is there any language community with quite the reputation for unwelcoming unpleasantness, combined with the opposite - no counterbalancing reputation for welcoming friendliness?

That people feel bad when they try to enter LISP world is much documented[1]. That Python and, say, Julia, managed to get reputations as welcoming communities long after Eternal September says the problem isn't "everyone" invading Usenet.

I'm expecting immediate downvotes for this comment, but what I really hope for is "yes I have that feeling about LISP world compared to other languages" or "no I feel LISP world is represented approximately the same as other languages".

[1] e.g. [https://eli.thegreenplace.net/2006/10/27/the-sad-state-of- th...](https://eli.thegreenplace.net/2006/10/27/the-sad-state-of-the-lisp- user-community) from which comes this

> " _And yes, I think it still represents the comp.lang.lisp group, even in > the post-Naggum area. Just look up the latest debate of the shortcomings of > Common Lisp that was incited by Steve Yegge. Lisp is as close to a perfect > programming language as any, and its zealots guard it rabidly. Criticism isn > 't tolerated. Ignorance isn't tolerated - which drives many newbies away > quite quickly. Lisp has been attacked so much before, that any post by a > newbie meekly seeking an advice on some arcane feature gets immediately > interpreted as criticism and turns into a flame war. True, Erik Naggum was > the main cause of such flame wars in the past, but he wasn't the only one. > Wake up, Common Lisp gurus - your language is so unpopular because of you - > there is no one else to blame. If you ever asked yourself why is CL much > less popular than the obviously "brain dead" Perl (paraphrasing Naggum's > favorite Perl quote), the answer is the community, that is you._"

<comment><USER39> A fun read about Common LISP community [https://github.com/exercism/common- lisp/issues/206](https://github.com/exercism/common-lisp/issues/206)

<comment><USER8> That "Hexstream" guy is a known mentally ill person who harasses other Lisp community members in various ways (github, twitter, his personal website, exposing other lispers' personal information, etc.)

He is alone and doesn't represent the community in any way.

</comment></comment></comment><comment><USER40> Typically what ends up in wide use is historical in nature. C became dominant because it closely maps to the hardware that was available when personal computing went mainstream. A whole generation of programmers learned it, and that influenced language design for decades to come. When everybody is used to doing things a certain way, it can take a long time for new ideas to gain popularity. People often get set in their ways and have a hard time adapting to new ideas.

A lot of the popular languages are fungible because they come from the same family. For example, Ruby, Perl and Python are all extremely similar in nature and offer no fundamental advantages over each other. Then we have system languages like C, C++, and Rust which offer better control over resource utilization.

As a long term trend what's going to drive language popularity is how well the language is suited to tackle popular problems. Functional languages are perfect example of this, as they have been around for many years, but they simply didn't fit well with the available hardware.

Back in the 70s you had single core CPUs coupled with very limited memory. Things like GC were simply not an option and you needed languages that were good at squeezing out every bit of performance possible. Imperative languages addresses this problem extremely well.

However, today we have different kinds of problems. In many cases raw performance is not the most important goal. We want to have things like reliability, scalability, and maintainability for large code bases. We want to be able to take advantage of multicore processors and network clusters.

The imperative paradigm is a very bad fit for these problems because it makes it very difficult to localize change. On the other hand, functional paradigm is a great fit for these problem thanks to its focus on immutability and composition. Today we're seeing a resurgence of interest in functional programming, and Clojure is a perfect example of a Lisp that's quite successful.

</comment><comment><USER41> I learned Lisp in the 80's and 90's because AutoCAD used that as it's internal scripting language. Was fun to play around with and I wrote code for a paying project to do election redistributing after the 1990 census. I'm out of that world now and have no idea what AutoCAD uses these days for scripting.

</comment><comment><USER42> Lisp failed? There are multiple articles about it on the front page of HN.

<comment><USER23> HN is even written in a Lisp dialect...

<comment><USER43> ...which arguably is the language's only real application.

</comment></comment></comment><comment><USER44> Languages that have achieved any degree of success, as Lisp did, never fail for just one reason, or two, or three. Lisp failed for many reasons; some are listed in the other comments. The article suggests one, and discounts others, but all contributed.

The hardest lesson to learn seems to be that GC is poison. Other languages that have avoided Lisp's other faults succumb to that one, and lock themselves out of the most demanding problems.

When embarking on a project, you do not often know everywhere it will take you. If you start with a language that won't go some places, your project can't go there. If it needs to go there to succeed, you have doomed it at the outset.

How many times do you need the lesson? Some need it more than others. Many never learn it.

<comment><USER45> > The hardest lesson to learn seems to be that GC is poison.

Perhaps that's a hard lesson to learn because it's obviously wrong.

<comment><USER46> I wouldn't call GC "poison", but in a lot of domains it is a severe limitation. I don't see any GC language unseating C/C++ very soon, and perhaps never.

Clearly GC has achieved a ton. However, I am starting to wonder whether it will hang on to that success, or whether new language designs that don't need it will gain a lot of ground back.

GC, in a way, seems like a shortcut to avoid reasoning about lifetimes, and sometimes taking that shortcut comes back to bite. If it becomes easy enough to get help from the compiler, maybe we just don't need GC any more?

Obviously far-fetched, but interesting to think about.

<comment><USER47> Yet C++ community has adopted RC on the standard library, COM/UWP uses RC, and the most sucessful AAA game engine middleware uses a C++ tracing GC.

And yes, RC is a GC implementation algorithm as per CS reference papers and notable books.

C might never come close to any form of authomatic memory management, but in a couple of decades it will be relegated to surviving UNIX clone deployments.

<comment><USER46> C might be diminished a lot, but the beachhead is being made with Rust, not a GC'd language.

<comment><USER47> The only holdouts left for C are UNIX clones and embedded.

C++ and managed languages have taken over everything else.

</comment></comment></comment></comment></comment></comment><comment><USER48> For me Lisp was a lot of fun to learn and play with, but I dont think it had a chance to survive in modern production environment because: 1\. Not typed 2\. Absence of a proper package mechanism and package managers like cargo or npm

<comment><USER8> >because: 1. Not typed

Umm... the long section on "Common Lisp: The language" describing the features of the type system disagree with you.

> 2\. Absence of a proper package mechanism and package managers like cargo or > npm

Quicklisp.

<comment><USER48> CL has some type checking features in some of its compilers, but this doesnt mean it is a typed language. Quicklisp is still in beta and is in no way even close to package managers like cargo or npm.

<comment><USER8> >but this doesnt mean it is a typed language

Custom data types can be defined

Data types can be checked,

Functions can be dispatched on the data type of the input parameters (see CLOS),

Variable types can be declared.

... so, Lisp isn't a "typed language"?

>Quicklisp is still in beta and is in no way even close to package managers like cargo or npm.

QL is already better than NPM and PIP. It says "beta" only because the author is modest; it already has years of releases and development.

Maven is a better package manager, though.

</comment></comment></comment></comment><comment><USER49> Lisp didn't fail. It went mainstream. Mostly.

(This article is full of errors; the author doesn't seem to know much about FORTRAN, BASIC, or LISP.)

Paul Graham wrote an article about this in 2001, "What Made Lisp Different": [http://www.paulgraham.com/diff.html](http://www.paulgraham.com/diff.html). He lists nine features: conditionals, first-class functions (though not, at first, closures), recursion, dynamic typing (and what I called the object- graph memory model in [http://canonical.org/~kragen/memory- models/](http://canonical.org/~kragen/memory-models/)), garbage collection, no distinction between functions and expressions, a symbol type, a notation for code using trees of symbols (and thus the ability to add macros), and the whole language always available (no strong distinction between compile-time and runtime, dramatically simplifying macros and other forms of metaprogramming).

As Paul points out, these features got adopted by other languages gradually over time, but in 1960 or 1970 or 1980 or even 1990, if you needed garbage collection and dynamic typing, or to pass around functions as values, or to do metaprogramming, your non-Lisp options were very limited. Prolog or Smalltalk might be a possibility, but usually they weren't. So Lisp was extremely popular. It was really the only reasonable candidate for an embedded scripting language in the 1980s, so that's what Emacs and AutoCAD used.

By contrast, consider the currently-popular crop of languages: Java, C, Python, C++, C#, VB.NET, JS, PHP, SQL, Objective-C, Ruby, assembly, Swift, Matlab, and Groovy, say. Let's omit SQL and assembly from what follows. All of them have conditionals; all of them have first-class functions (though in C, closures are a nonstandard GNU extension); all of them have recursion; all except C have some form of dynamic typing, and half of them are purely dynamically typed (except C, C++, Objective-C, C#, Java, VB.NET, and Swift), and even more of them use the Lisp object-graph memory model; all of them are garbage-collected (except C, C++, and sometimes Objective-C); many of them have a symbol or "atom" type (Python has intern(), Ruby has symbols, Objective-C has SEL, Swift has Selector, and JS just acquired Symbols in ES6); and most of them support Turing-complete metaprogramming in one way or another: templates in C++, "eval" in Python and JS and PHP and Ruby and Matlab, "Eval" in Groovy, and loading dynamically generated bytecode with a fresh ClassLoader in Java.

Metaprogramming merits special attention here; fully a third of Paul's items (symbols, representing source code as a tree of symbols, and the lack of compile-time–run-time distinction) are about metaprogramming, and those are the items that are not widespread today. The main use of metaprogramming is implementing embedded domain-specific languages, which you could reasonably argue is the most important part of the Lisp approach. (Certainly the article claims that it's what sunk Lisp.) But there are ways to implement EDSLs other than compile-time code evaluation to modify your source code while represented as a tree of symbols, and indeed the immense difficulty experienced in solving the hygienic macro problem in Scheme (getting to Macros That Work) suggests that it may not even be the best way. You can get a long way by using reflection instead of macros, and in Python you can override __dunder__ methods, implement iterators, and write metaclasses; in Java, in addition to firing up OW2 Asm and generating new classes, you have @annotations; in Ruby and Objective-C, you have method_missing and -doesNotUnderstand:; in object- oriented languages in general, you have virtual method dispatch (including but not limited to the Interpreter pattern); and in Ruby you have block arguments, and the ES6 => syntax is lightweight enough to be used in the same way. (I don't know several of these languages well enough to comment on their metaprogramming facilities.)

So the real story is that most of Lisp's features went mainstream, and every popular language has them, so they are no longer a reason to choose Lisp _stricto sensu_. They do differ in how to implement metaprogramming, Lisp's most radical feature, as did Lisp — fexprs are nowhere to be found in Common Lisp (or in McCarthy's 1959 Ur-Lisp), and Scheme hygienic macros are another game again, one which also doesn't provide an S-expression API to the macro- writer.

(The expression–statement dichotomy is an exception here. It's true that Lisp doesn't have it and most modern languages do. I think this is an example of the tradeoff between error detection and succinctness I described in [http://www.paulgraham.com/redund.html](http://www.paulgraham.com/redund.html) — the expression–statement dichotomy improves the reporting of parsing errors considerably, and the compensating expansion of your code is almost insignificant.)

FigBug argues in [https://news.ycombinator.com/item?id=20375596](https://news.ycombinator.com/item?id=20375596) that Lisp _stricto sensu_ failed because it had no killer app (other than, I suppose, Emacs and AutoCAD), because most developers don't pick a language, but are rather constrained to use the language demanded by their environment: JS in the browser, C for Unix, Java for Android. But that just poses the question of why Android uses Java instead of a purer Lisp, why the browser uses JS instead of a purer Lisp, and so on. It just reduces the adoption decision to a smaller group of programmers.

There were a couple of other historically contingent things that happened, which don't have anything to do with the merits of the languages as such: around 1988 the AI Winter and the workstation revolution wiped out the Lisp companies; around 1995 the internet went mainstream and for a while all the interesting development was in Perl 5, partly because of its Lispy qualities but also because its attitude toward Unix was the extreme opposite of Lisp's; and the microcomputer world developed its own programming traditions, despite the noble efforts of magazines like BYTE to bridge the gap. Presumably something similar is happening right now in Shenzhen.

<comment><USER50> > the currently-popular crop of languages: Java, C, Python, C++, C#, VB.NET, > JS, PHP, SQL, Objective-C, Ruby, assembly, Swift, Matlab, and Groovy, say

Did you get this list of 15 languages from TIOBE's July 2019 top 15 rankings at [https://www.tiobe.com/tiobe-index/](https://www.tiobe.com/tiobe-index/) ? It also says Apache Groovy has risen from #81 in July 2018 to #15 today. I do believe the #81 ranking but the rise to #15 only 12 months later is ludicrous. Someone's obviously spamming a search engine to get that ranking up. I know someone does the same thing with Groovy downloads from Bintray.

Now if Groovy's ranking has been fabricated over the past year, then surely some others of those languages have also been similarly fabricated for much longer, and their _popularity_ has been exaggerated.

<comment><USER51> > Groovy has risen from #81 in July 2018 to #15 today

The rise to 15 is probably not correct but 81 is probably as inaccurate the other way as 15 is today. Given how ubiquitous gradle has become and groovy being the basis of that. Especially when you consider the nature of tiobe, it is about search results, so even people migrating away from groovy will generate "groovy" traffic as they try to figure out how to do equivalent things in, say, kotlin.

<comment><USER50> > 81 is probably as inaccurate the other way as 15 is today

I can understand both how and why someone would push Apache Groovy's ranking higher up the Tiobe results, but I wouldn't know how you could push it down, let alone why anyone would. #81 is probably as accurate nowadays as the mid-40's has been for most of Groovy's life on Tiobe since 2006. Groovy's seen a significant drop in use (outside Gradle) over the past few years.

</comment></comment></comment></comment><comment><USER52> Lisp failed because its community failed to accommodate the beginner trying to do something _useful_.

Lisp has a zillion useful ways of doing things--that nobody ever taught.

Try finding a beginner book on Lisp (even today!) that actually teaches about vectors and hash tables instead of trying to do everything with recursion, lambda and singly-linked lists.

You don't attract a beginner trying to write a game, for example, that way.

<comment><USER23> > Try finding a beginner book on Lisp (even today!) that actually teaches > about vectors and hash tables instead of trying to do everything with > recursion, lambda and singly-linked lists.

I tried:

Practical Common Lisp by Peter Seibel

[http://www.gigamonkeys.com/book/collections.html](http://www.gigamonkeys.com/book/collections.html)

Also see Land of Lisp page 153ff: Arrays, Hash Tables, Structures, ...

[http://landoflisp.com](http://landoflisp.com)

Common Lisp Cookbook:

[http://cl-cookbook.sourceforge.net/hashes.html](http://cl- cookbook.sourceforge.net/hashes.html)

COMMON LISP: A Gentle Introduction to Symbolic Computation, from 1990

[http://www.cs.cmu.edu/~dst/LispBook/book.pdf](http://www.cs.cmu.edu/~dst/LispBook/book.pdf)

Chapter 13: Arrays, Hash Tables, And Property Lists

<comment><USER52> "Practical Common Lisp"\--Copyright 2012--gets it right and deserves to be called out for that. Hashes and Vectors appear _BEFORE_ lists in the book. They don't get the emphasis they deserve, but they are on par with the list coverage.

"COMMON LISP: A Gentle Introduction to Symbolic Computation, from 1990"\--Um, wow, a whopping _17 PAGES out of 500+_ ( _5_ for hash tables) on nominally the two most useful data structures in all computer programming. (Side note: I had an actual dead tree edition of Touretzky from CMU in 1986?--I don't remember hashes in it--I think that was an add-on later). And, even 1990 is after Lisp starts getting displaced (Tcl, Perl, Python, etc. are all coming online).

The Perl4 Camel Book cookbook section was practically an existence proof for "Show people how to do useful things in your language and they will flock to you."

In addition, "Hash all the things!" was practically Perl's motto, and it wiped the floor with everything else for a _VERY_ long time (something like 1994-2005--for 10+ years Perl was _dominant_ ).

<comment><USER23> > "Practical Common Lisp"\--Copyright 2012--gets it right and deserves to be > called out for that. Hashes and Vectors appear BEFORE lists in the book

Did you read the book?

The book is from 2005. Lists are introduced in chapter 3 with a practical example, a simple database.

The Touretzky edition I mentioned is from 1990.

Actually lists are the main fundamental data type in Lisp (well, it's also called as an abbreviation of 'List Processor'), which sets it apart from many other programming languages and is the reason of its existence. The basic idea of Lisp is that one can do many practical things with lists.

Let's look further in your claim that it would be hard to find introductory Lisp books with mentioning arrays.

Paul Graham wrote published in 1996 the book ANSI Common Lisp. Arrays appear in chapter 4 together with strings (1d arrays/ vectors), sequences (a data type joining lists and vectors), structures (records) and hash tables.

Winston&Horn, 3rd Edition of 1989. Arrays are in chapter 11. But from that book we get a good idea through practical examples that one can do a lot of interesting things with lists.

Another book, the 'Common Lisp Companion' from 1990. Vectors, strings, arrays, sequences, hash-tables appear in chapter 4.

> Perl was dominant

for text processing and early web server scripting...

For example I can't remember much in NeXTStep or MacOS that made use of Perl (or Lisp) in any crucial way. The OS and its applications were written largely in C, C++ and Objective C.

</comment></comment></comment></comment><comment><USER53> Oh the irony of finding this link and a discussion about it on a website driven by a lisp dialect :)

</comment><comment><USER54> I'm using it.

I'm having fun with it.

I'm building useful stuff with it.

It has not failed.

</comment><comment><USER55> I think Forth has a similar issue: despite the attempt to ANSI it, Forth is a family of idiosyncratic individuals. Chuck Moore even says that standardizing Forth is kind of doing it wrong, you're _supposed_ to custom build your own, for each application even. (Like if a Jedi knight built a lightsaber for each battle. (^_^) )

So on the one hand, Forth "failed", while on the other it's still used a lot.

</comment><comment><USER56> lisp never failed, our idea of success is wrong

</comment><comment><USER57> The OP makes a good case, but I don't agree with his dismissal of 'syntax' as a major problem.

I found the comment introducing [https://readable.sourceforge.io/](https://readable.sourceforge.io/) quite interesting. Deserves a submit of it's own.

</comment><comment><USER58> The "lack of a killer app" point made in the comments below is interesting in light of the Perl6 story today.

</comment><comment><USER59> Unpopular opinion, but I find readability really hard on lisp projects. Everything has to be read backward, and just because you can nest 10 lambdas doesn't mean that you need to nest 10 lambdas all over the place. So the code you end up with is write-only nested-over-nested-over-nested backward-reading code.

Can clean lisp be written? For sure, and it's magnificent. But in practice, it's a total shit show. Basically, what I'm saying is when it's great, it's amazing, and when it sucks it's the worst.. whereas other languages like java/javascript/python have less variance in code quality and range from ["pretty-meh to "good-enough"].

And what's happening these days is the great features of lisp are integrated with "good-enough" languages, and then they become "pretty-good" languages.

<comment><USER17> Threading macros -> and friends in Clojure change the ordering of reading and they're idiomatic, is that what you mean?

<comment><USER45> Easy to add to Common Lisp. In fact, the CL code base I work on currently uses these.

[https://github.com/hipeta/arrow-macros/](https://github.com/hipeta/arrow- macros/)

</comment></comment></comment><comment><USER60> Lisp didn't fail. There are several successful modern Lisps, like Clojure.

But, moreover†, there are also successful modern languages that don't look like Lisps at first glance, but which certainly are Lisps by most definitions—the best example I know of being Elixir.

Rather than a distinct compiler that does codegen to a distinct architecture target, languages like Elixir (and Clojure!) consist of two distinct components:

1\. A plain language grammar parser, which parses "syntactic literals" of the language into a Lisp-alike AST (and Lisp had one of these as well, even in its first incarnation—Lisp's "syntactic literals" were called [https://en.m.wikipedia.org/wiki/M-expression](https://en.m.wikipedia.org/wiki/M-expression) s.)

2\. A homoiconic runtime interpreter of this AST, with hygenic macro support, which evaluates macros at runtime with the _side-effect_ of producing a program. This "runtime" is called "compile time", but it's really just the same runtime that the compiled program runs in (and both have equal access to the machinery that produces programs.)

In any Lisp, the definition of a function or a module isn't a special form that the compiler does something with; rather, `defn`-like clauses are just references to an ordinary _macro_ , which the S-expression _interpreter_ invokes when attempting to reduce the AST that has `defn` as its head. The `defn` macro consumes a parameter list and an expression body, and has the _side effect_ of producing a compiled function in some way; and then the `defclass`-alike macro has the side-effect of collecting those compiled functions generated within its scope, and producing a compiled module from them.

And, in any Lisp, the M-expressions (like those of Clojure, or those of Elixir) are a convenient syntax to write code literals in, but you don't have to use them; you can just as well write "raw AST" as the M-expression representation of the AST's data-structure literals (since, in a Lisp, these data-structures are always ordinary stdlib data structures like lists or tuples, rather than compiler-specific data-structures); or, equally well, you can _generate_ and _build_ these AST data structures by writing functions to produce them, and then call these functions inside a macro body in place of where you'd write a quoted M-expression literal or a plain S-expression ADT literal. In est, there's no difference between the macros that a _user_ of such a language writes, and the macros that _define_ the language; both are just homoiconic AST->AST mapping functions. There are a few that do fancy side-effects involving invoking an object-code compiler... but you can write your own functions that do that as well. (This is why it's so easy to build a new language [like HN's runtime Arc language] on top of an existing Lisp—there's nothing stopping you from writing macros that call out to your own codegen machinery, and at that point you've bootstrapped your way out of the original language.)

——

† Note that, by this definition, there really _isn't_ any difference between Clojure and Elixir; I didn't need to distinguish "actual Lisps" and "languages that act like Lisps." Clojure and Elixir are both Lisps—both M-expression glosses on top of a "compile time"-runtime S-expression evaluation engine with compilation as a side-effect of certain "compile time"-runtime macro invocations.

Certainly, Elixir has special M-expression syntax for calling various macros (`if`, `for`, etc.), but adding such a thing to Clojure wouldn't make it any less Clojure.

The real contrast, if there is one, is that Elixir has no _homoiconic_ M-expression syntax for S-expressions (i.e. no equivalent to Lisp's parentheses), so you can't just write a low-level S-expression equivalent of an M-expression inline in a function in order to have that AST subtree be part of the function. Instead, you have to define a separate macro to declare your intent to inject a low-level S-expression, and call it at that point in the function body; and you have to write such ASTs in an alternate M-expression form (as tuple data-structure literals.)

This is less of a distinction between the languages _as languages_ , though, and more a distinction between the languages _as M-expression syntaxes_. You could define an alternate M-expression syntax for Elixir, which _did_ have direct inline S-expression support, and the resulting language—at least in my opinion—would still be Elixir.

</comment><comment><USER61> > Why Lisp Failed...

All Emacs users: "Are we a joke to you?"

</comment><comment><USER62> I think Mathematica is kind of a killer app for lisp.

<comment><USER63> Mathematica wasn't written in Lisp. You might be thinking of Macsyma.

<comment><USER20> My understanding is that Wolfram rewrote Macsyma in C but that Macsyma was his direct inspiration for Mathematica.

</comment></comment></comment><comment><USER64> I have a lot of gripes with the first part of this article regarding old languages that "failed" (which I detail below), but what follows is a pretty reasonable assessment of why Lisp never really "clicked" as an enterprise language. My opinion on the subject overlaps, but I would say that the biggest issue is not programmer understanding (it is easy to write unreadable code in any language), but problems with the language from a business owner or manager's perspective. Lisp programmers are less replaceable, and the trade off between the benefits in power of Lisp compared to what large businesses lose in terms of ability to replace employees quickly was not worth it to them and I honestly couldn't say whether their judgement was good or bad in regards to this.

Starting at the top:

> Other languages of similar heritage (to Lisp) are still widely used.

Which ones? Unless I'm very mistaken, there were virtually no languages which fit into a similar role as Lisps for at least 1-2 decades after Lisp (1958) came onto the scene. The only language I can think of that would accurately match this description is Prolog (1972), because although Basic (1964) was also a dynamic, symbolic language, it was really meant to be an easier alternative to Fortran II with instant feedback and simpler syntax for people with little to no computer science or math background.

> Some of the above languages are no longer quite as popular as they once > were. This will be the definition of "failure" we will use here. The > question is why did they fail? The first stand-out is COBOL.

COBOL failed?!? It is possibly one of the most successful languages ever. From a 2018 Reuters report on active COBOL use that continues today (and was even more prevalent in 2009 when this article was written):

\- 43% of banking systems \- 80% of in-person transactions \- 95% of ATM swipes \- 220 Billion LOC

> as time progressed fixed sized arrays as data structures became obsolete

According to who? Vast amounts of numerical computation software from weather and climate models to modern AI algorithms make use of fixed length arrays.

> The ALGOL language family succeeded. The reason for this is that these were > the languages written by programmers for programmers.

There is no doubt that the Algol (C, really) family of languages have absolutely dominated, but whether that was because they were well designed or something like that seems a questionable notion. K+R were essentially looking for a portable assembler with which to rewrite Unix, and many would argue that C's popularity stemmed primarily from it's use in Unixes, which spread to all main stream operating systems.

<comment><USER50> > active COBOL use that continues today [...] 220 Billion LOC

That 220b LOC is because most newly-written COBOL programs today are copied and pasted from some other large existing program, then some small parts of it changed. I know in one large corp I once worked at, a manager ordered that instead of a new code being created for a new customer in the program suite as was usually done, every program in the suite was cloned and the new customer's name was hard-coded into the strings in the program text. That manager got the new system up and running in record time and was well regarded by his peers. The maintenance programmers and computer operators got some extra job security in the years ahead too.

</comment></comment><comment><USER65> If we're indulging in idle speculation, then here's my contribution.

I think Lisp failed for the same reason that ORMs exist, and to be even more provocative, for the same reason that women are underrepresented in programming: the Apple II.

Yes, yes, of course that isn't "the reason." "The reason", singular, is nonsense, as any outcome is a consequence of many interrelated causal factors. However, often a few or even one dominate, and in my view the Apple II[1] is a dominant factor for these outcomes.

Hear me out.

Evidently, there once was a time when women had a healthier representation within programming, and this roughly coincided with times both when there was an efflorescence of different programming models, and when "computers" was more a profession for adults. Then, the personal computer revolution occurred in the 1970s, which introduced inexpensive, under-powered computers into (upper) middle class homes, and this roughly occurred in tandem with the introduction of video games both in arcades and then in homes. In my unscientific observation, girls were shoved aside by their brothers, who swiftly moved those video game consoles and computers into their bedrooms, where just as swiftly we set about adapting games and writing our own games using the only language offered: BASIC. And so a baby boom of baby programmers occurred. Programming expanded beyond an adult profession and became also a province of adolescent hobbyists, whose first and only (for a long time) view of what it meant to program meant: an imperative language, with subroutines, standard control-flow operations, and mutable state. BASIC isn't usually put in the Algol family of languages, but it's a better candidate for a foster child of that family than the never-learned models of before: Prolog, SQL, Forth, Lisp, etc. It wasn't difficult to make the transition from BASIC to C, then to C++, and then to Java (picking up Perl and maybe Python along the way). Without even trying, that generation of boys became a generation of young men primed to program in a non-Lispy way, right around the time when the internet was creating a demand for programmers. What fruit did this yield?

* Boys and then men became overly-represented in programming, relative to decades before.

* The database was held at arm's length, and SQL was tolerated only by creating ORMs that permitted retreating to the comforting familiarity of imperative, mutable state, Algol-like languages.

* Languages like Lisp and Prolog were forgotten about, until being "rediscovered" decades later.

Of course, if any of this is true, it raises other questions

* Why did the early, cheap computer makers choose BASIC instead of Lisp?

* Why did later, more powerful computer makers choose C?

* Why was there a gender disparity in affinity toward games in kids and adolescents?

I can speculate on some of the reasons for these, but I've indulged in enough for now.

[1] "Apple II" is just a handy placeholder. Substitute Atari, Commodore 64, "personal computers", whatever, if you like.

</comment><comment><USER66> I wonder what is the most widely used, popular program, that has been written in Lisp? Is it Emacs?

Every time I sit down to try to learn Lisp, I end up wondering what the hell I'll use it for. Functional programming languages seem to have flipped a bit in my mind that predisposes me to be prejudiced against Lisp .. I find it very hard to do anything actually useful with it, whereas I can pick up c++ or Lua or Python and immediately get something running.

I'm not saying this is Lisps' fault, but I've been programming for 30 years and have tried many times to become a Lisp programmer.. its just never been effective.

<comment><USER67> Speaking to why a LISP newbie finds it tough to get things done... I think most people think in imperative terms. "I want to make a type. Now, given a thing of that type, change a thing here, change a thing here, and return the thing I want."

And most languages delineate a programmer's tasks clearly. For instance, in Python and Ruby, logical structure is expressed in blocks, control (mostly) transfers between statements, while calculation is performed in expressions, and these are all visually distinct.

LISP's idea that all structures can be expressed as lists doesn't visually demarcate the distinct "things" a programmer is trying to compose. You can absolutely learn it, but it makes it harder.

Now, since LISP does basically use an AST directly, it makes metaprogramming trivial. The beauty of extensive metaprogramming is that you can construct new languages cheaply. The curse is that you get a lot of cheaply constructed new languages.

If Python wants to add an "async" keyword, they go through weeks of debate and do a long writeup on it.[1] In LISP, someone writes a few macros and, boom, new syntax. The LISP community are smart people, they recognized this and I think the standardization efforts tried to mitigate it, and a ton of thought clearly went into Scheme.

But even this article doesn't get the problem. It's not "there are too many parens" but more that everything in LISP looks the same when you're new, it's a jumble of parens. Your brain isn't getting distinct markers to help learn the structures.

And LISP, shares a problem with most dynamic languages that anything can kind of go anywhere. It's not as bad for others, though, because if you _look_ at an example of Python code, you can generally _see_ the structure and that narrows down what can fit there. Whereas LISP is always a mess of parens and keywords; yes, it's usually obvious from looking at the docs, but it's just more research you have to do to get something done.

<comment><USER8> >But even this article doesn't get the problem. It's not "there are too many parens" but more that everything in LISP looks the same when you're new, it's a jumble of parens. Your brain isn't getting distinct markers to help learn the structures.

On a typical language you have "structures" you mention, like "if", "for", "switch". Lisp also has them, but they look more like function calls. The syntax has a lot of less noise.

Automatic indentation helps you visualize such "structures" in an easier way. It's not any more difficult than using a language like Python or C.

>And LISP, shares a problem with most dynamic languages that anything can kind of go anywhere.

Not really, because Common Lisp -the major Lisp dialect- is a strongly typed language, unlike the most popular dynamic languages: Javascript, PHP and Python and Ruby (Python & Ruby being 'duck typed' for the most part). And unlike the famous weakly-typed statically-typed language: C.

So no, "anything" _can 't go anywhere_, because a type mismatch will cause a runtime error. And in CL you can correct runtime errors by modifying the source code and resuming program execution (without having to restart the complete program), so no big deal either.

The most common data construct, the Lisp list, accepts any kind of data type inside, but Lisp also has structs, objects and arrays, all of which can be defined for specific data types. Note that the ANSI Common Lisp standard includes extensive support for type declarations.

Not to mention that Lisp, unlike other languages (Java, C++ -- i'm looking at you guys) don't erase types at runtime. Lisp works with values (not variables) , and values are typed. Any value, in Lisp, carries its type information at runtime.

<comment><USER67> > The syntax has a lot less noise.

Note here how you unconsciously use "has" instead of "have", that kind of grammatical noise exists because those small redundancies help us understand each other.

I think the reason very few computer languages use parens is because they're harder to read by virtue of having less grammatical redundancy.

(At the other end of the spectrum, languages like COBOL are hard to read because they're swamped in redundancy.)

> So no, "anything" can't go anywhere, because a type mismatch will cause a > runtime error.

I should have been clearer: it can go anywhere while you're writing it, so you have to run it to find out. That's the problem people also have with other dynamic languages when they're working on non-trivial codebases. Also, because types are rarely declared up front, you're often paging through code to figure out what type should go some place.

> And in CL you can correct runtime errors by modifying the source code and > resuming program execution (without having to restart the complete program), > so no big deal either.

I agree that's an amazing feature few langauges have been able to copy, but it seems like it wasn't enough.</comment></comment></comment></comment>


WoW Microsoft announces new Azure G family VMs and premium storage feature - <AUTHOR> http://thenextweb.com/microsoft/2014/10/20/microsoft-announces-new-azure-g-family-virtual-machines-premium-store/ <comment><USER2> world of warcraft ?</comment>


How the News Took over Reality - <AUTHOR> https://www.theguardian.com/news/2019/may/03/how-the-news-took-over-reality <comment><USER2> > We marinate in the news. We may be familiar with the headlines before we > have exchanged a word with another human in the morning; we kill time on the > bus or in queues by checking Twitter, only to find ourselves plunged into > the dramas of presidential politics or humanitarian emergencies. By one > estimate, 70% of us take our news-delivery devices to bed with us at night.

 _Some_ people do this. And I'm guilty of having been one of them. But I realized that the constant negative news cycle started to shape my outlook on the world around me.

Earlier this year I decided that the cycle of indulging in consumption of (usually negative) news, worrying about it, and then repeating is a waste of time and probably takes away from who I am rather than adding anything of real value. I don't check Twitter, I trying to avoid Facebook. I don't even watch my favorite late night talk show hosts (sorry Colbert). I've replaced them with audiobooks and podcasts.

I am significantly happier for it. And minor anxieties I had that were unrelated to current events seem to have gone away too.

<comment><USER3> Do you realize that you are posting your comment on a website having the word « news » in its name ? Just saying :)

<comment><USER4> I'm in a similar boat.

The reason I visit hn is because it's typically technical news. Other news stories do make it to the front page occasionally, but they're normally big stories or tangentially related to tech. That's a trade-off I'm willing to make.

</comment></comment></comment><comment><USER5> Twice, now, I've written a story--and deleted--about local TV news people I'm close to compared to when I worked in TV news in the early 1970s. There is no comparison and I wish I could leave what I wrote here.

Back then, the TV news reporters were former newspaper reporters who spent days digging political underhandedness. I once had a TV reporter call me, recently, cause someone referred her saying I had knowledge of a topic. Misunderstanding what she asked, I called back 30 minutes later I did have the information she needed but she said it was too late and they weren't going to run the story.

A few days ago, a news producer was reviewing dog toys.

</comment><comment><USER6> It might help if filtering were better in more places.

On YouTube, I mostly see accordion videos and that's the way I like it. On Twitter, even if I follow people who don't talk about politics, they will "like" other people's tweets that then show up in my feed.

On Facebook, there should be a way to turn off reshares for someone you're friends with.

</comment><comment><USER7> Judging by the author's article history, there is good money to be made in playing on other people's insecurities.

We should look at articles like this for what it is: the 2010s version of self-help. And as with most self-help, the author is more interested in heightening awareness of the things that are 'holding you back' than providing any meaningful solution.

</comment><comment><USER8> How do you solve that dilemma between disconnecting from news because it can make you happier and less stressed and disconnecting from news because you're privileged to do so? the parts of the article about the "need" to stay aware of what's happening at the very least certainly ring true for me.

<comment><USER9> What causes that need? Your job requires it? Or your social group will ostracize if you don't keep up?</comment></comment>


Baking the Most Average Chocolate Chip Cookie - <AUTHOR> https://pudding.cool/2018/05/cookies/ <comment><AUTHOR> Here's the data: [https://github.com/polygraph- cool/data/tree/master/cookies](https://github.com/polygraph- cool/data/tree/master/cookies)</comment>


Braintree Launches Instant Approval Product - <AUTHOR> http://finance.yahoo.com/news/braintree-launches-instant-approval-product-140000075.html

<comment><USER2> It is interesting how Braintree, Paypal, Stripe, WePay* all offer 2.9% + $0.30 as their pricing model for processing credit cards.

Why is it exactly the same across all of these providers?

Credit card companies must be setting their prices so that all these companies need to compete on the same level.

What happens when one of them decides to do 2.89% or $0.29? Everyone is fighting over portions of pennies these days.

* WePay originally had 3.5% to try to buck the trend, but even they are now moving towards the 2.9+.30 model.

<comment><USER3> Unless you process an enormous amount of payments, you're going to be dealing with a reseller, because the banks don't want to deal directly with small fries, and $250 million USD per year can still be seen as a small fry in the payments industry.

So the reseller is going to mark it up a bunch. Plus, there are multiple rates (called interchange): a plain credit card is one rate, a card with points/miles is a slightly higher rate, a corporate card, - still higher, and a corp card with points/miles - higher still.

That's just one card type (say MVS/VISA), there's another set of interchange rates for AMEX, another for Discover, etc.

If you want to see this in action, talk to the people at you local bank about processing credit cards, or call intuit about one of their dongles. The interchange rates are part of the contracts.

The per tx fees (the $0.30 part) are built up out of several layers of the transaction including fraud review, and there may only be a nickel of profit built in on that side.

I think that all the providers are charging the same because they are trying to attract small businesses (SBs) SBs are notoriously price conscious, and if you go a tenth of a point higher, or three extra cents per tx, they'll use your competitor. So all the processors are priced about as low as they can go, and are trying to compete on features. They might all use the same reseller.

</comment></comment><comment><USER4> Why haven't I heard of Braintree before? In every Stripe thread people are complaining about it being US&Canada only, and I've never heard someone suggest this instead (this works for businesses in Canada, UK, EU, AUS). Could someone give a quick overview how Braintree compares to Stripe overall?

Edit: Well, it seems that Braintree didn't compare to Stripe's offering before this Instant product. So, this is really great news.

<comment><AUTHOR> BrainTree was more of a traditional solution, requiring a separate merchant account and a full underwriting process before approval. They also did not have 100% flat rates.

Now the have both.

<comment><USER3> The hidden truth is that the "approval process" will have to happen before you can move any serious money through any of these payment processors.

This comes from the Payment Card Industry, and their idea that you should "Know Your Customer," and US Treasury Department, which has zero tolerance for payment processors who take a cavalier attitude towards money laundering, and they go directly after the owners of the company, and press criminal charges.

So while you're selling 100 a month, you're not really on anybody's radar, but start processing in earnest, and they will want all of the info that a traditional merchant account process requires.

Believe me when I say that "Instant Approval" ruffled a lot of feathers with more traditional processors who were forced into long, involved approval processes by PCI.

So you can start immediately at an instant approval processor, but they'll want all the same into before you can get your money. If you search for horror stories, you'll find lots of merchants who signed up for these services who didn't read the fine print about their money being tied up, and complain loudly that the processor should have told them something that important.

You can get out in front of the process with these processors by talking to them. let them knwo that you're about to launch, or offer discounts or whatever, so your spike in volume doesn't look suspicious. That the in-depth approval process as soon as you can. They want to be your partner, but there are rules and laws that they're not going to bend or break for you.

BONUS: one of the reasons that credit cards don't like to be used for crowdsourced funding sites is that there is no guarantee that a good or service will change hands, and therefore they have a harder time telling legit crowdfunding from money laundering "oops, sorry guys, or idea flopped. thanks for the $200 thousand dollars!"

<comment><USER5> Michael from Braintree, here. I helped build our instant signup process.

You make an astute observation here. PayPal (and other folks who imitate their business model) have a earned a poor reputation for servicing startups whose businesses actually grow. Braintree has been winning clients away from PayPal for years on this score, and we absolutely will not embrace their model.

We are actually doing something quite different with our instant approval process. We've combined an easy signup form with years of experience and data from working with fast-growing startups. The result is truly a full underwriting process that helps us to understand your business, and can approve most merchants to accept credit cards online instantly. With an instant approval from Braintree, you will have your own merchant account and the assurance that when your startup takes-off we will be cheering for you, not witholding your funds.

<comment><USER3> Can you answer this question: Why do you need to look at the applicant's credit report?

<comment><USER5> For us, that's part of getting to know our client. Your question implies that you don't think it's necessary for us to check a credit report - I would be curious to learn why. Feel free to send me an email at firstname.lastname@example.com if you want to discuss.

</comment></comment></comment></comment></comment></comment><comment><USER6> Instant Approval with a personal credit check... doesn't say if it's a hard or soft pull.

</comment><comment><USER7> Damn. Instant is only US customers at the moment...

<comment><USER8> Kristi from Braintree here. We're working pretty furiously to make the sign-up experience just as seamless for our international customers. Can't offer specific timing yet, but working hard to get there.

While the sign-up isn't quite as seamless on the international front, it is the same great software and APIs that our US clients use. So in the meantime, we'd love to work with you to get you up and running with us as quickly as possible.

</comment></comment><comment><USER9> One thing definitely not helping their cause is their crappy domain name. No offense as I'm sure their product is lovely, but stripe has a big advantage in terms of branding

<comment><USER10> In terms of branding Braintree has been around for a long time and is a very trusted name. They're very well known for being developer friendly and having great customer service.

I'm using Stripe right now but a brand goes well beyond the name...especially when you're talking about financial services companies.

<comment><USER9> No doubt</comment></comment></comment>


Crunch Awesome PNG Image Optimizer - <AUTHOR> https://github.com/chrissimpkins/Crunch <comment><USER2> Those examples are stunning!

There is a ticket explaining where it works well and where it doesn't:

[https://github.com/chrissimpkins/Crunch/issues/15](https://github.com/chrissimpkins/Crunch/issues/15)

</comment><comment><USER3> Keep in mind that this is lossy compression.

      The following examples demonstrate the benefits and
      disadvantages of the current iteration of this aggressive
      space saving lossy transformation strategy. In many cases,
      optimization with Crunch will lead to excellent space
      savings and an imperceptible decrease in image quality.

</comment><comment><USER4> Does it have to be specific to OSX, would it be hard to make it available on Linux as well?</comment>


Hotel maids challenge the placebo effect  - <AUTHOR> http://www.npr.org/templates/story/story.php?storyId=17792517&sc=emaf

<comment><USER2> Another interesting finding:

You gain less weight if you liquefy your food in a blender than you would eating the same quantity of that food prepared normally. Your body absorbs less calories because it doesn't taste as good. There was a good writeup of this in Emotional Intelligence, and the people who advocate the Shangri La diet mention it in a lot of their writing as well.

</comment><comment><USER3> "The researchers say that it holds promise for mind set related weight loss. However, since you now know about the study, it'll never apply to you. Sorry. "

<http://www.zefrank.com/theshow/archives/2007/03/030207.html>

<comment><USER4> I don't know about that. Whenever I take aspirin, I feel the effect of it immediately, well aware that it hasn't had the time required to enter my bloodstream. I once even repeated the words "placebo effect, placebo effect" aloud as my headache vanished.

</comment></comment><comment><USER5> _For example, Brody notes one study where researchers gave asthmatic patients a drug that actually makes asthma worse. When they gave the drug to the patients, they told them that it relieves asthma._

Nice, just nice. Remind me never to participate in a research study.

<comment><USER6> yeah that is just mean.

</comment></comment><comment><USER7> Similar effect to what Guy Kawasaki's highlighted: <http://blog.guykawasaki.com/2007/12/how-to-not-chok.html>

</comment><comment><USER6> OR, alternatively, the US Surgeon General's advice is not really that great, and/or the minimum wage working poor maids can't possibly eat healthy in their money and time poor lifestyles.

<comment><USER8> That doesn't explain why one group lost weight and the other didn't.

</comment></comment><comment><USER9> great find dood</comment>


If I Sleep for an Hour, 30 People Will Die (2016) - <AUTHOR> https://www.nytimes.com/2016/10/02/opinion/sunday/if-i-sleep-for-an-hour-30-people-will-die.html <comment><USER2> The article is about a person who forged papers starting in WW2 and up to the 70s to get people out of dire situations. It ends in ""I did all I could when I could. Now, I can't do anything," he said. Surely, though, the rest of us can."

Not so easy anymore, with all the biometrics and cryptographically secure data on a microchip embedded in today's passports.

<comment><USER3> I think the point isn't "now it's time for someone to forge papers" but "there are plenty of ways to help and other people with more energy can take them up"

From raising awareness, convincing governments, running for office, donating money and/or labor...just volunteering on a crisis line is a huge help.

<comment><USER4> In the context of the original article, and the current world, it appears that far fewer are willing to bring personal risk than in the past.

My guess - and it is a guess - is rather than signing an online petition, forwarding a meme, or attending a demo, in the past direct action, civil disobedience, underground networks and activism was more often used. I suspect that in today's world many of those would be viewed as terrorism or at the very least imprisonable.

<comment><USER5> > _in today 's world many of those would be viewed as terrorism_

I'm involved in local politics. The problem is a low give-a-shit factor. Older Americans will reliably show up to vote, stop to sign petitions (real ones, not online ones), donate to candidates and show up for town halls and protests. Young, well-educated, technically-savvy urbanites are a predictably anodyne bunch. (To be fair, I'm those things.)

The risk isn't higher. The cost just is. When activism competes with brunch, Instagram time, and the necessity of a high-paying job to settle student loans, it's a tougher sell.

<comment><USER6> I used to go to the planning board meetings for my neighborhood. They were at 4:00 on weekdays - I wonder why I was the only one under 60 there?

Even then it was only because I was trying to bootstrap a startup and setting my own hours.

Also, "When activism competes with brunch, Instagram time, and the necessity of a high-paying job to settle student loans, " -

good points, but remember also that those old people largely could have one person working (and actually getting of at 5 with no bullshit emails/slack/other crap to follow them home) and the other doing childcare/household work/civic things, instead of 2 people working 8-6:00, rushing to childcare, and getting home tired as dogs.

<comment><USER7> I take a bit of an issue with the tech crowd claiming that a single income family is infeasible. Single parents get by all the time. People in tech make well above the median income in most cases. It's absolutely possible to live a nice middle class life on a single tech income. It's just not possible to keep up with the spending of a dual income family. All about priorities.

<comment><USER8> > People in tech make well above the median income in most cases.

But have to live/work at places where the costs of living are enormous.

<comment><USER9> As war1025 noted, this is not true. People in tech are the most likely to have access to remote work that pays very well. I bring in the only income while my wife stays home with our two boys (6 and 3). I live in Pittsburgh, PA and worked remotely for a startup based out of SF until they ran out of money late last year and picked up a job in downtown Pittsburgh pretty quickly after that. I wouldn't say we're swimming in money but we are comfortable and don't have to check our balance for most purchases.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> _Though he was a skilled forger — creating passports from scratch and improvising a device to make them look older — there was little joy in it. "The smallest error and you send someone to prison or death," he told me. "It's a great responsibility. It's heavy. It's not at all a pleasure." Years later he's still haunted by the work, explaining: "I think mostly of the people that I couldn't save."_

Hero.

</comment><comment><USER11> It's interesting to consider the parallels between the power/responsibilities carried by Kaminsky, and our own lives. It is estimated that we can save a human life for $2000. Which means that each of us faces a similar dilemma even if we don't realize it: " _If I go on an international vacation, 1 person will die "_

This is not to say that we should live a spartan life and donate every dollar to charity. I wouldn't expect Kaminsky to forego sleep entirely either. But it's a tradeoff that is worth being conscious of, the next time we spend money on things we don't truly want or need.

[https://www.givewell.org/giving101/Your-dollar-goes- further-...](https://www.givewell.org/giving101/Your-dollar-goes-further- overseas)

<comment><USER12> It is undoubtedly clear to me that a human life is less valuable to me than my having a MacBook Pro because I am both fully aware of how much it costs to save people and consciously choose not to do so.

So life isn't really precious. It is only precious in terms of its relationship to me. My family is precious and my friends are precious. Life? Life is cheap.

Things I value more than life for life's own sake:

* The aforementioned MacBook Pro

* A trip to Switzerland

* Two months of my personal trainer's sessions

* My bicycle

* One month of rent in SF

* Having my car for a couple of months

* A celebratory lunch for my team

The real disconnect isn't that we're imperfectly choosing our spending. It's that we tell the lie that life is precious. It is not.

I will buy my parents a computer and a tablet soon. I will do this for them knowing it brings them some small pleasure. I will do this knowing that doing so will doom a child.

<comment><USER13> This is so egocentric. Do you really believe your choices can have such an impact ? Actually it has not, and you can sleep well knowing than buying a computer to your parents won't harm anyone, because your choices alone cannot change the world. If you're not giving money to charities, then someone else will do. If no one gives money, then there will still be some people trying to save childs anyway, using their skills and their guts, not their money.

Now imagine this theoretical situation : you have the choice between buying a new computer _or_ save an unknown child for certain death (let's imagine a psychopath taking a child in hostage and asking you randomly). Would you still buy the computer ? Would you still consider that human life is less valuable for you than having a new computer ? I certainly hope not

<comment><USER14> Posing hypotheticals like this and passing judgment on their character for their answer is not a good-faith way of discussing a topic. It's just not a realistic scenario and someone's answer to the hypothetical indicates nothing about how they would actually act in a real situation where they were able to help someone.

<comment><USER13> You did not understand my point. My point was that you cannot pretend to not value life just because you prefer to buy a new computer rather than giving 2000$ to a charity. There is no direct connection, if it would be that easy then Bill Gates would be the savior of humanity.

<comment><USER14> Sure. I mean I think the whole discussion, right back to the root comment, is an unrealistic hypothetical.

The $2,000 refers to the estimated average cost of saving a malaria sufferer in certain countries.

But that's based on the cost of running a comprehensive program in which many people donate, many people help on the ground and many lives are saved.

In some other contexts it could cost much less to save a life. In others, no amount of money could save a particular person's life.

But many people give something to humanitarian charities from time to time and most people are comfortable that some of their taxes - probably more than $2000/year for most people in rich countries - are used for medical services, welfare systems and aid programs that save lives.

What I've written above is a reality-based comment on the way most people actually do expend funds that lead to lives being saved.

And I think it's related to the point you were trying to make at the start of your comment.

But veering into implausible hypotheticals about child hostages, and then passing character judgment based on an answer, starts turning a silly discussion into a toxic one.

</comment></comment></comment></comment></comment></comment><comment><USER15> The comments about the dangers of moving toward un-forgeable documents remind me of the xkcd about spacebar heating. [https://xkcd.com/1172/](https://xkcd.com/1172/)

Official documents being susceptible to forgery is a bug. Like many bugs, it can be exploited for noble purposes, but it's still a bug. The right way forward isn't to keep this bug around so our systems can remain vulnerability- compatible with their 1940s versions, it's to find a way to support the use cases you want to keep.

I don't know how to do that exactly, but on the other hand, I bet none of you know how to convince governments to stick with forgeable paper documents either.

</comment><comment><USER16> And if he sleeps too little, he'll create lousy forgeries that will also cause people to die.

</comment><comment><USER17> Discussion from 2016:

[https://news.ycombinator.com/item?id=12621548](https://news.ycombinator.com/item?id=12621548)

</comment><comment><USER18> Reminds me of "Portrait of a Young Forger" by Marian M. Pretzel

</comment><comment><USER19> > By his 19th birthday, he had helped save the lives of thousands of people by > making false documents to get them into hiding or out of the country.

What an immense privilege it must have been to be in a position to help so many people.

</comment><comment><USER20> I wonder how his documents would compare to listings on Oasis and Alphabay these days.

</comment><comment><USER21> First glance at the headline: maybe about sleepy driving.

Another glance at the word "Opinion" above it: probably just clickbait.

Onward to the first paragraphs: Oh shit. A very touching story, about a real hero in dark times.

(Why is this under "opinion"?)

<comment><USER22> (It's a book review.)</comment></comment>


Corner Detection with OpenCV - <AUTHOR> http://glowingpython.blogspot.com/2011/10/corner-detection-with-opencv.html The post explains of to perform a corner detection in Python using the OpenCV library. <comment><USER2> I can see that being really useful combined with depth data for creating 3D models.</comment>


GNU Awk has TCP/IP support - <AUTHOR> https://www.gnu.org/software/gawk/manual/gawkinet/gawkinet.html

<comment><USER2> Is netcat not enough for most such tasks?</comment>


Got a sweet tooth? Blame your liver - <AUTHOR> http://exactlyscience.com/archives/12114.html <comment><USER2> "How do we decide what and how much to eat? Maybe satiety consists of different pathways that control different types of nutrients,"

This is a pet theory of mine. That, vastly simplifying, our bodies try to make us eat until we have a sufficient amount of whatever number of elements they need to function. The more varied you eat, the less you need to eat, conversely, the more homogeneous your sources of food (bread, rice...), the more you'll need to eat to try to get what is hardly there.

I have no idea whether this idea is mainstream between researchers but it always seemed to me as feasible as a satiety mechanism as just counting calories, and it explained quite well the observations I've made about myself. Anybody here could point to the current state of the art in the field ?

<comment><USER3> I'd expect multivitamins to have a strong effect on general satiety if that's true. Do they?

<comment><USER4> There's evidence that multivitamins are useless, and that they actually cause health problems [1].

As for OPs theory, it's strange to think of such a thing happening during an obesity epidemic, but many people do seem to be lacking basic nutrients in their diet. I'm not sure how much we can trust our own guts when it comes to seeking out nutritious foods; the majority of people go for sugar and fats when they're hungry, instead of the fruits and vegetables that contain the nutrients they're lacking. It seems our stomachs are not looking out for our best interests.

[1] [https://hub.jhu.edu/2013/12/17/vitamins-might-be- harmful/](https://hub.jhu.edu/2013/12/17/vitamins-might-be-harmful/)

<comment><USER5> > many people do seem to be lacking basic nutrients in their diet

What's the evidence of that?

<comment><USER6> [https://www.ncbi.nlm.nih.gov/m/pubmed/22364157/](https://www.ncbi.nlm.nih.gov/m/pubmed/22364157/)

Note that 'required' likely means "less than the RDA" and that RDAs are often set on the basis of "having less than this much will imminently lead to some sort of dysfunction" as opposed to "the amount that actually makes your body happy".

</comment></comment></comment></comment></comment><comment><USER7> I've got a real sweet tooth and excessively eat sweet things.

I also have a 23andMe account and looked up to see if I have the FGF21 gene?

I found that I have 2 SNP's on gene FGF21.

[http://i.imgur.com/qnRD5M4.png](http://i.imgur.com/qnRD5M4.png)

Any idea what this means relative to the study?

<comment><USER7> Delved further into the cited study.

"This revealed statistically significant associations between FGF21 rs838133 and increased consumption of candy, as well as nominal associations with increased alcohol intake and daily smoking."

rs838133 is the first one in the table shown in image I linked to.

<comment><USER7> If you find this interesting and are interested in 23andMe please use my referral link. ;)

[https://refer.23andme.com/s/jbacontrol](https://refer.23andme.com/s/jbacontrol)</comment></comment></comment>


Explore Fractals in HTML5 with Google's New "Julia Map" - <AUTHOR> http://www.hackeducation.com/2011/01/31/explorefractals/ <comment><USER2> Seems broken at level 55, though in fairness that's pretty deep.

<comment><USER3> That's probably the precision limit of 64-bit floats.</comment></comment>


The 99% (A conference in NYC) - <AUTHOR> http://www.the99percent.com/

<comment><AUTHOR> Has anybody has been to a conference like this before? Was it worth the price- tag ($300-500)?

Anybody going to this?

</comment><comment><USER2> So THAT is what the bottom half of seth godin's face looks like...</comment>