Comment by oblio | Hacker News Reader

Comment by oblio | Hacker News Reader

I’d take advantage of this opportunity to start a discussion about a somewhat related article, the famed Blub article:

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

> The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.

17 years later and I still don’t see all those Lisp startups :)

I’d argue that 8) will never happen because the gap between human parsing and computer parsing is too big. Except for a minority of human compilers that enjoy Lisp, most people don’t, so this notation will always be a niche for mainstream programming.

>17 years later and I still don’t see all those Lisp startups :)

Just survivorship bias from PG side (lots of Lisp based companies just gone nowhere) and gross extrapolation of the sole example his one Lisp company as some universal truth (and even for his company, it was more the idea, timing, skills, execution and luck, than Lisp of course).

Click on this link and search for Clojure: https://news.ycombinator.com/item?id=16052538

I should expand then: 17 years later, where are the successful Lisp (ok, and Clojure) startups fighting the Microsofts (C++, .Net), Facebooks (PHP!!), Apples (Objective-C, Swift), Amazons (Java, C++, Perl), Googles (C++, Java, Python, Go), Twitters (Ruby, Java, Scala), Dropbox (Python, C++), etc.?

Clojure is a Lisp. One of the distinctive things about Lisp is that it has dialects. You wrote your comment using software written in another of them.

The youngest of the companies you list was founded in 2007. The first stable Clojure release was in 2009.

> Clojure is a Lisp. One of the distinctive things about Lisp is that it has dialects. You wrote your comment using software written in another of them.

I also wrote other comments on other sites using software written in PHP, what does that have anything to do with anything mentioned here? I guess it proves that you can use Lisp to write forum software. Still, not really related to my main question.

Slightly off-topic, I should mention that I've read most of pg's articles several times over the years. I know about Arc, Viaweb, etc. I'm asking about this topic after having read all those articles.

> The youngest of the companies you list was founded in 2007. The first stable Clojure release was in 2009.

Ok, then some other big company founded since 2009. It's been already about 9 years, there should be some around. I can wait for examples. Those companies can use any dialect of Lisp invented since the 50's :)

I know quite a few people employed working on Clojure. It's true that none of them are spectacularly large corporations, but there are quite a few companies out there using it day to day.

> Clojure is a Lisp. One of the distinctive things about Lisp is that it has dialects.

When one of those dialects is completely source-incompatible with every other dialect (the rest of them share non-trivial programs freely), and doesn't share the same core features as every other dialect (like list structure), then why is it still a dialect and not a different language? Calling all the other Lisps that share core features and run the same code different versions of one language makes sense to me; I don't see the point in applying it to any language that borrowed a couple ideas.

If I have a large codebase written in (any) Lisp, will porting it to Clojure be significantly easier than porting it to Javascript or Ruby or any other modernish language? Not really; it's a complete rewrite either way. That sounds to me like it might just be a different programming language.

> the rest of them share non-trivial programs freely

Heh. Most Scheme dialects don't even have source compatibility despite implementing the same standards.

Common Lisp lets you write portable (between different CL implementations) applications, but it's easy to end up doing something that is implementation-dependent if you're not careful.

> it's easy to end up doing something that is implementation-dependent if you're not careful.

I wouldn't say that. I've done a fair amount of porting code between CL implementations, and it's usually pretty straightforward. Implementation dependencies tend to be found only in code doing OS-y things like threads, external processes, network sockets, etc. This code is usually not difficult to find, and I would think that the authors would have expected it to be implementation-dependent. Computational code usually ports with zero effort, even when the machine word size changes.

Says the guy who wrote an interactive C compiler for Lisp machines! ;)

"C combines the power and performance of assembly language with the flexibility and ease-of-use of assembly language."

https://github.com/navoj/clisp-c

>>Not really; it's a complete rewrite either way.

Most languages are a evolutionary dead end. They won't even get this far.

>Clojure is a Lisp

Almost. It deviates a lot from all the other Lisps, in particular the two main branches: Common Lisp and Scheme.

However it is still a Lisp family language, and thus with its advantages.

Is it really? If we go back to the roots, lisp is made of what John McCarthy calls the Primary S-Functions which are atom, cons, car, cdr, and eq (a.k.a =). Of these five, clojure only has two (atom and eq)

> Of these five, clojure only has two (atom and eq)

You can't have atom without conses (well, it would just be (lambda (x) t)); which Clojure function are you thinking of?

Clojure has an ATOM function, but it does something completely different from Lisp's ATOM function.

Clojure is sufficiently different from typical Lisp dialects and their implementations, that it forms its own language family.

Ok, Clojure is a lisp-1 like Scheme, CL is a lisp-2.

Clojure is not based on CONSes but you have CAR and CDR they are first and rest. Processors are no more based on accumulator and decrement registers... :D

Cons exists but it works only on lists as CONSes doen't exists in Clojure, only lists.

Empty list != nil.

Clojure is based on immutability like Scheme, CL is often used in a mutable way (see the shameful f-set).

{}, [], #{} are syntactic sugars and have already been implemented in CL.

Clojure is an hosted language, so Clojure, ClojureScript, ClojureCLR can be somewhat different, but the core language is the same (same base Clojure library).

Lisp also has first and rest.

Scheme isn't based on immutability.

R7RS:

> Literal constants, the strings returned by symbol->string, and possibly the environment returned by scheme-report-environment are immutable ob jects. All objects created by the other procedures listed in this report are mutable.

> {}, [], ...

These characters are reserved for the user in CL and have been used for a bunch of different things.

> Clojure is not based on CONSes but you have CAR and CDR they are first and rest.

CAR and CDR are operations on conses, so you can't have them without conses; that's like having sqrt without numbers. Lisp has FIRST and REST for operating on lists, and so does Clojure. Lisp also has CAR and CDR for operating on conses, but as Clojure doesn't have conses, it doesn't have CAR and CDR, either.

> Processors are no more based on accumulator and decrement registers

CAR and CDR were named for 'contents of address part of register' and 'contents of decrement part of register', not anything about accumulator or decrement registers. I'm not sure where you heard that processors don't have accumulators anymore, but that's definitely not true. The reason Clojure doesn't have CAR and CDR doesn't have anything to do with obsolete processors, though.

> Clojure is based on immutability like Scheme

Scheme is not based on immutability.

> CL is often used in a mutable way (see the shameful f-set).

Do you mean SETF? FSet[0] is an immutable data structure library for Common Lisp. A lot of Schemes have SETF, too, by the way, there's even an SRFI[1]. But SETF is just so that you can have one generic assignment operator; standard Scheme has plenty of commonly-used, destructive assignment operators like set-car!, set-cdr!, vector-set!, etc.

0: https://common-lisp.net/project/fset/Site/FSet-Tutorial.html

1: https://srfi.schemers.org/srfi-17/srfi-17.html

Few comes in my mind: iRobot[1], Grammarly, D-wave. I feel there is something in common but it is hard to describe.

[1] If you call iRobot is a venture company. It is actually 30 yrs old.

Some people say Python is a good enough Lisp.

But macros?

There are a few cool macros in Python, e.g. decorators. It's just that you can't define your own without making it past Guido.

(To be clear, decorators aren't macros, "decorator" is a macro)

You kinda can, through the file encoding specifier. It'll let you write reader macros that programmatically modify the AST, essentially.

>Some people say Python is a good enough Lisp.

After a full year writing Python professionally, and then Common Lisp, i can confidently say this is not true.

What do you find is missing?

I do like Python, a lot, but you asked for it... the list is long!

- true, effortless metaprogramming

- speed close to C by use of type declarations and fixed arrays; this means up to 100x faster than CPython. No, PyPy, Jython and Cython don't get quite there.

- no Global Interpreter Lock!

- the condition-restarts error handling system, which is deluxe error handling and recovery from errors.

- a very flexible type system, plus very strong typing.

- an extremely powerful object oriented system (CLOS) -- light years ahead of most OOP systems including Python. This means, having multimethods/multiple dispatch, method combinations, around/after/before methods, multiple inheritance, and a MOP.

- true lambdas, not Python's one-line joke lambdas.

- true interactive development, able to compile functions on the fly and thus change them while the code is running. Able to redefine classes while the code is running.

- able to call Java libs and C libs at the same time, with ABCL

- will run on many platforms and in the JVM without modifications to the code

- separate namespaces for functions, vars, keywords and everything

- tail call optimizations

- something like Quicklisp (pip isn't as good)

- built-in rational numbers, complex numbers, using the same operators for regular numbers

- the LOOP macro, which I find better than Python's list comprehensions.

Thank you, this is very interesting.

In what way are Python's lambdas restricted? Do they literally have to fit on one line?

Do you have to use a separate version of + to add complex numbers in Python?

Do you prefer loop because it's more concise or because you can say things you can't say in Python? Can you give me a couple examples of things that work better with loop?

(As you can tell from my questions, I don't know much about Python, but as a Lisp hacker I'm curious about other Lisp hackers' view of it.)

Python lambdas cannot contain statements, only expressions. Typical python contains a lot of statements, so that's a bit annoying.

You can define inner functions and so on, and most of the times that I want to use lambdas it's just because I've been stuck in a language without *-comprehensions for too long.

+ works fine on complex numbers.

I'm not super familiar with the loop macro, but it lets you do both things similar to a python comprehension and to a python for loop. I don't think it does anything you can't do in python.

Erlang is not Lisp but it is very similar. Erlang is widely used in telecommunication industry.

Ruby and Python, at least at the time of Twitter and Dropbox foundings, fell more on the side of the hackerish languages.

Objective-C is only a mainstream language now because Apple is the most successful company on Earth. No one besides Apple was seriously using it at the time, and they used it to develop the most popular product in the history of computing. And of course, then bet their development future on an entirely new language, Swift, which of course no one else was using, because Apple invented it.

True, it's crazy Facebook had so much success with PHP. But they are also one of the biggest corporate users of Haskell, I think.

True, on the surface Amazon and Google are on the stodgy side with their "supported" languages. But I believe Google internally is rife with custom, proprietary DSLs to drive a lot of their infrastructure? And they invented Go. Which is in many ways the opposite of Lisp in terms of design. But the larger point PG was making was that the dangerous technology companies evaluate technology decisions on the real potential productivity gains, and not on the number of job postings for that technology.

EDIT: Saw Erlang mentioned elsewhere in this thread, which reminded me of WhatsApp, which led to 50 engineers supporting 900 million users and a $19 billion payday from Facebook! That's the perfect example of the kind of company PG would have been worried about.

If you don’t limit the conversation to startups, Walmart seems to use Clojure extensively: https://github.com/walmartlabs?tab=repositories

"In 30 years Lisp will likely be ahead of C++/Java (but behind something else)"

- Peter Norvig

https://en.wikiquote.org/wiki/Lisp_(programming_language)

The quote is dated 1999. 11 years to go, and I'm rather skeptical that it will happen.

> 17 years later and I still don’t see all those Lisp startups :)

I don't see where in the article he is claiming that you would see many Lisp startups in the future.

Not everything has to be spelled out. He wrote an article 17 years ago declaring Lisp a secret weapon. If it were, wouldn’t you expect the passage of time to prove his point? Or it would mean that everybody else is kind of dumb for not noticing this secret weapon in almost 2 decades :)

Just trying not to ignore what is spelled out:

>But I don't expect to convince anyone (over 25) to go out and learn Lisp. The purpose of this article is not to change anyone's mind, but to reassure people already interested in using Lisp-- people who know that Lisp is a powerful language, but worry because it isn't widely used. In a competitive situation, that's an advantage. Lisp's power is multiplied by the fact that your competitors don't get it.

Heh, I forgot that part.

I’d argue that today libraries and super used code (more bugs already found and fixed, more answers on Google) > powerful language.

> more bugs already found and fixed

I'd argue that libraries that used to have bugs found and fixed tend to have many more of them to catch you by surprise later. They also tend to have less stable interfaces.

> more answers on Google

Also, the libraries complex enough to need many questions on Stack Overflow are normally the same as the ones above.

I think the main things that's happened is that many languages and frameworks coalesced to fill the void PG and Morris probably used lisp to such great advantage; ie building featureful, performant web apps. In the mid 90's there was perl I guess. Nowadays there's python, php, ruby/rails, etc.. with all their frameworks and environments. Mak

Reply on news.ycombinator.com