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.
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.
> 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.
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).
> 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.
> 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.
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)
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.
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.
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.
