Hacker News new | comments | show | ask | jobs | submit login

None of these applies to Clojure, and by and large Clojure basically obsoletes Ruby and Python unless you have concerns about the jvm startup time (which you can work around with Nailgun, but many people don't). No, seriously, Clojure is a uniform attack on everything of value in the Ruby, Python and Node.js world, only with fantastic performance and more flexible syntax.

Indeed, criticizing "lisp" is difficult because it isn't really clear what you mean. Common Lisp? Well that has a lot of work done for you. Scheme? That's deliberately minimalist because it's not meant for everyday work until you go outside the core spec (e.g., PLT Scheme's libraries). Clisp? MacLisp? What?

Lisp didn't take off because it didn't take off. There isn't some deep unconscious wisdom being tapped by the masses that we can read with tea leaves and subtlety. These things are random. There is a parallel universe not far from this one where Anic is a big deal and Pike took off in place of Python.

Because to assume otherwise that would imply that everyone knows every language and some are uniform winners over others. Do you know every language you have rejected? Heck, do you even know the general characteristics of Lisp, or Haskell, or ML, or Anic, or Pike, or APL? No, and to really try and learn all of them would take a lot of time unless you're quite gifted. So the premiere and popular programming languages are as unpredictable as fashion.

All you and I can do in our quest to be great software engineers is try and choose tools that split the difference between The Best For the Job and the Best We Can Manage.




"Clojure basically obsoletes Ruby and Python" "Clojure is a uniform attack on everything of value in the Ruby, Python and Node.js world"

This kind of smugness[1] is one reason why Clojure will never take over the world. It seems to be some kind of unwritten rule that every Clojure evangelist has to knock another language in any post anywhere [2]. Ugh.

I am a great admirer of Rich Hickey (the man is a genius), and am happily using Clojure in my present project, but this kind of triumphalist rhetoric is a big turn off. I don't think Clojure "obsoletes" Ruby or Python, anymore than Haskell or Erlang "obsoletes" the various lisps.

[1] This attitude seems particularly endemic amongst people who've moved to Clojure from the early Ruby on Rails community, where sneering at alternative frameworks was part of the culture.

Rich Hickey, while justifiably proud of his language, as he should be, never makes silly statements like this.

[2] see http://news.ycombinator.com/item?id=4272186 for an embedded gratuitous swipe at Scala in an otherwise insightful post.


I am not going to be your proxy for every perceived irritant in the course of discussing lisp. Asking me to be this is unfair.

You can say I am some sort of hater and now it's Rails's turn, but I've been consistent with this even when I was a full time rails programmer [1]. You can find essays by me on the inadequacies of Rails dating back years now [2]. The very things I was complaining about in 2007 are now the glaring flaws in modern Rails. So I made the decision to strike out for tools that don't have a cultural bias against progress in areas I believe important.

So, if I am a Smug Lisp Weenie, then surely I am also a Smug Scala Weenie. And a Smug Erlang Weenie. And a Smug Haskell Weenie. And a Smug Ruby Weenie. And a Smug Hadoop Weenie. And a Smug C weenie... Because one thing I've made very clear is that I think attachment to tools is the problem. We should always aim to use the best tools at our disposal, and I think the place where Python and Ruby are the best tools are shrinking under the onslaught of the competition. Argument from familiarity is something I simply cannot bear to listen to anymore.

If believing this makes me smug then I guess I am smug.

[1] http://www.oreillynet.com/ruby/blog/2007/06/multicore_hardwa...

[2] http://dave.fayr.am/posts/2008-11-20-the-opposite-of-momentu...


"You can say I am some sort of hater and now it's Rails's turn"

Oh but that's not what I said. I said that claims of Clojure "obsoleting" Ruby/Python reek of smugness once prevalent in RoR and Common Lisp communities, and do turn off intelligent people. You can like and evangelize Clojure without making such rabid claims, especially when they are unsupported by data or strong arguments.

"We should always aim to use the best tools at our disposal,"

This is a non controversial position. The "smugness" is in going beyond such sane positions and declaring Clojure to be some kind of uber Ruby/Python killer without any supporting data or arguments.

"and I think the place where Python and Ruby are the best tools are shrinking under the onslaught of the competition."

This is more dubious. Do you have any supporting data? What do you see as "competition" to Ruby or Python? Clojure? in terms of deployed systems, Clojure is barely a blip (wrt RoR, say). I know many intelligent devs using and liking Clojure, but also other intelligent devs using and liking Python and Ruby. I even know (horror!) people who know all three and don't always choose Clojure.

Also, it is pretty hard to characterize Clojure as an "onslaught" on Ruby in any fashion (afaik Rich Hickey doesn't have such an onslaught as part of his goals for Clojure development), or as an "obsoleting" language, which is a very strong claim. Strong claims require strong supporting evidence.

In fairness to you, you did say " I think that .. " which brings me to

"Argument from familiarity is something I simply cannot bear to listen to anymore."

Totally agreed. Now apply that to your Clojure evangelism/praise. ;-)

Fwiw I am working on a Clojure project, and quite like the language. It is extremely well designed and (given the limitations of the JVM) very elegant.

But I don't have a stake in proclaiming it to "obsolete" Ruby/Python etc - at least not without some very convincing arguments - certainly not just "argument from familiarity" ;-)

All that said, I gladly concede that Clojure is some kind of ultra uber language in your experience, in the interest of stopping this thread from expanding fruitlessly.

PS: Decent essays btw. Now apply the same critical eye to Clojure :)


I've found the Clojure community at large to be well reasoned in general and very intelligent. KirinDave's posts may be a little hot, but I think it is a sign of growth for Clojure. Ruby/Rails also had (has? ;-) ) a problem with smugness as it was gathering rabid following. Let's hope that this is a sign that Clojure is also building up a gathering of all sorts of interesting characters :-)


> Oh but that's not what I said.

Actually, it is. Basically when someone says, "____ is smug," what they're really doing is making a soft, attitude based argument for dismissing the more substantive arguments. Same as calling someone a hater.

> You can like and evangelize Clojure without making such rabid claims, especially when they are unsupported by data or strong arguments.

I can support the arguments quite well. And I can make the same argument for Go, Scala, Erlang, and Dart. We simply haven't had the space or opportunity to really expound on it here, since the context is a post that attacks "lisp" with spurious complaints.

> Strong claims require strong supporting evidence.

This is true, but what you're doing is ignoring the context of the conversation after the fact to try and weaken my position. I can make a case for these claims, and in fact in many of my blog posts I have made a case for these claims. Saying I never have in this thread is a little disingenuous.

> I even know (horror!) people who know all three and don't always choose Clojure.

You then have the horror of knowing me, the person you have mischaracterized as a Clojure evangelist instead of a modern software tools evangelist.

> at least not without some very convincing arguments

Allow me to just list out Clojure's strong points with respect to Ruby, since that's close at hand. Because you keep acting like I an a Clojure fanatic, dedicated with laser-like precision to the cause of promoting Hickey's work, let me re-iterate: _I COULD DO THE SAME WITH A HALF-DOZEN OTHER TOOLKITS._

1. Ruby and Clojure are both dynamic langages with a variety of beyond-the-Java features but... a. Clojure's answer to the "expression problem" is safer, faster, and cleaner [1]. b. Clojure has explicitly modeled multi-methods, something that observations of the industry suggest would be useful for clarifying a lot of existing code [2]. c. Clojure can support functional programing and OO programming directly. It often ends up having "cleaner" (less punctuation and repetition) expressions of OO call stacks than its host language, Java. [3]

2. Clojure and Ruby both have rich collection libraries, but... a. Clojure's core data structure libraries are somewhat richer (e.g., better set support, some better numerics), and safer in multi-threaded use because of their persistent design. b. Clojure's libraries implement the same "pass in a block" pattern as Ruby, but with more universal names in most cases, and with more consistency (which is important due to the thrush combinators). c. When the standard persistent data structures cannot meet your performance needs, high performance mutable structures are available from the Java toolkit. Ruby usually has to appeal to C to get faster results, the binding process of which is fraught with peril even with 1.9 (and is excruciatingly difficult in 1.8 due to fundamental design mistakes).

3. Both languages support concurrency primitives but.... a. Ruby's concurrency primitives never allow for parallel processing except in a tiny minority of implementations, whereas in all but a tiny minority of implementations Clojure's primitives do. b. Ruby's concurrency primitives are basic, whereas Clojure not only offers the Java primitives (themselves ranging from basic atomic references to the contents of java.util.concurrent) but also offers a Software Transactional Memory implementation which emphasizes reasonable performance and ease of use.

4. Both communities value brevity and meta-programming, but... a. Clojure's half-hygenic macros with quasi-quoting provide an approachable way to make arbitrary syntax extensions to the language; in this Lisp is only challenged by other Lisps and perhaps the Haskell and ML world. b. Many similar abstractions like Sinatra vs. Compojure exist in the "Ruby and Clojure"-verse, but because of macros the Clojure side can always go further. In the context of the above points, Clojure almost always has a significant performance advantage, too.

5. Both languages have excellent deployment strategies... a. Ruby has a suite of integrated in-language tools and a lot of service vendors that directly support it for distributed software projects. b. Clojure is deployable almost anywhere Java is deployable, which is "almost almost" everywhere. c. Clojure has a mixed blessing in that it has access to ".war" and "uberjar" type deployments. These can be more confusing, but often eminently more easy for an operations (or devops) team.

I'll stop for now, but I want to re-iterate I could make cases against many popular languages for a variety of other languages when the situation warrants. For example, when correctness and ease of distributed processing is your goal, Erlang is unmatched.

[1] http://kirindave.tumblr.com/post/658770511/monkey-patching-g... for more on this.

[2] http://homepages.ecs.vuw.ac.nz/~alex/files/MuscheviciPotanin...

[3] http://java.ociweb.com/mark/clojure/article.html and grep for "noisy" for a casual treatment.


You make some decent arguments pro Clojure as compared to Ruby in this post.

Whether they actually prove anything like your conclusion, I'll leave to the judgement of the other readers.

(rest of this too long reply deleted as too snarky and not worthy of HN. Sorry guys)


I don't think these things are as random as you would like to believe. A large number of people tried for a large number of years to get lisp to take off. It isn't just bad luck that lisp didn't take off, and I think this article does a good job of outlining some reasons why.

I don't have to personally know every language. Languages grow in popularity by picking up users. It is clear lisp was and is very popular with certain segments of programmers, and ever caught on with others.


> A large number of people tried for a large number of years to get lisp to take off.

You know, it was fairly popular for a time.

> I don't have to personally know every language. Languages grow in popularity by picking up users.

This is a tautology.

But let's pretend for a second what you meant to say was "Languages deserve the usership they gain in a sort of mindshare stock exchange." Then let's rewind 10 years and show you Clojure, Ruby, Java, and Javascript.

Can you ever imagine someone from 2002 picking Javascript over those alternatives? Someone sane, I mean. All praise to the pragmatism of the 'net, but Javascript's popularity is a function of its largely unrequested deployment and the failure of competing products (mostly due to artificial and non-technical business-enforced nonsense).

And yet here we are with Javascript being so popular that startups are raising $9m just to build frameworks in them. And yet by any reasonable metric Javascript is a "worse" language. The most highly-recommended starter book for javascript is "The Good Parts", because a whole lot of the language is just so bad it has to be ignored or worked around.

All we're really doing is appealing to popularity as a justification for using perceived popularity instead of real technical metrics. Which is–to some extent, anyways–fine and good; it certainly is traditional for people to do this. But let's not pretend we have access to some deeper insight while we're doing it.


Kirin, I think you pretty much hit the nail on the head. More of this stuff is due to luck and randomness than most people admit. We look back and find a few contributing factors, put them in a pile, and call it a theory, and believe we understand it.

But does that theory actually limit what we'd predict about the future? Does it retroactively predict all the past data that we've seen? As you pointed out, Lisp was quite popular for a bit.

What if we just said, Lisp isn't popular because it didn't get/stay lucky?

That anti-theory isn't quite as satisfying, but at least it doesn't pretend at knowledge that it doesn't have.

One really nice thing, in my opinion, about JavaScript programmers is that they don't sit around kvetching about why the wrong language won. We all know it was a fluke, but the fluke happened, and here we are, so you can either squawk about languages, or get real things done instead, and improve the tools and software that you have.


> You know, [Lisp] was fairly popular for a time.

I'm afraid I have to dispute this. I'm about as dedicated a Lisper as you'll find -- learned it at the feet of Bernie Greenberg, Gerry Sussman, and David Moon in the late 1970s, and still use it when I get the chance. (Oh and I think my Symbolics machine still works, though I haven't fired it up in several years.) I was around during the time you're probably thinking of -- the AI bubble of the mid-1980s -- and even then, Lisp was the language a lot of people loved to hate, if they knew anything about it at all.

There was some interest in Lisp, to be sure, but I think "fairly popular" is putting it too strongly. It has always been a fringe language.

On another note -- it struck me the other day that if history had gone a little differently, we might be using Dylan instead of JavaScript. Oh well...


I grant it may not be quite as important in the industry, but got a lot of popularity in Academia, and some very modest inroads in the industry.

But you're right, it never had the singular popularity that Javascript, Java, or Python now enjoy. Sorry if in my haste I gave a false impression. Not what I meant to imply.


What's with the strawman? CJefferson didn't even mention Javascript.

Javascript is not the only language that surpassed Lisp in popularity, far from it.


It's more of a case-in-point than a straw man. Javascript is a great example of how unpredictable language popularity can be. The implicit argument, "Languages deserve the userbase they attract," is what's under attack.


One could use Javascript to argue that while midlevel languages tend to live in a sort of meritocracy that the very top level of languages always have some sort of immensely-powerful backer that they ride on. JS rode on top of Netscape at time when they were just that powerful. Java rode on Sun. C# and Objective C are there because of their powerful backers Microsoft and Apple.


An interesting idea. I wonderf if this means Go is destined for "greatness".


I think if they wanted to make it happen, they could. They don't seem to care to at the moment, but it's not hard to create plausible scenarios over the next few years where that changes.


I'm pretty sure the canonical example should be PHP. Javascript had a lot of things interesting about it and consistent function names. It's actually not a bad language.


It's a pretty bad language. There may be worse, but it's pretty bad.


Out of curiosity, who are you referencing as the $9m funded startup building Javascript frameworks?


I'm guessing Meteor.

Their rise has been <sunglasses> meteoric.


> by and large Clojure basically obsoletes Ruby and Python

Care to qualify how Clojure obsoletes Ruby or Python? Both of those languages have great tools (rails, for example) that those in the Clojure communities have great respect for. As a Clojure and Ruby/Rails programmer, I share your enthusiasm for Clojure and lisp, but I can't see Clojure pushing either Ruby or Python out of the water any time soon.


> Both of those languages have great tools (rails, for example)

I am surprised a Clojure programmer would have much respect for Rails. Its aggressive share-nothing approach leads to inconsistency, poor performance, awkward architectures, and over-reliance on external state management.

Perhaps one might admire it for making a bold claim about configuration vs. convention, but a valid criticism of Rails is that they went so far along the convention line in rebellion of bad tools like Spring that now they get accused of excessive magic.

> But I can't see Clojure pushing either Ruby or Python out of the water any time soon.

Like I said, success is fashion. But then, people said this to me about Git Vs. SVN after I gave a tech talk to a bunch of ruby folks about how git would take over the world. Two people left that talk and went on to found Github, so... "High Fashion."

Clojure has all the power of Ruby's dynamism, but with a better solution to the expression problem (protocols are namespace contained, allowing for monkey-patching that doesn't taint the world). It has access to a lot of fantastic high-performance libraries. It can safely deal with high degrees of parallelism with a degree of ease few environments can claim. It has a minimalist syntax which can compete with even the most terse and convention-driven ruby syntax (i.e., Compojure vs. Sinatra).

Similar complaints can be leveled at Python with less of a performance angle and more of a power angle; Clojure gives you access to many of those features that the python community feels are "too awkward" to use in the OO world, but are entirely natural in the Lisp world.

So yeah, every time someone writes a server in Node.js I think to myself, "You could have done it in Clojure and had just as much dynamism during development, just as easy a deployment story, and also perform easily an order magnitude faster under load, and you don't have to run like a scared child from parallelism."


> I am surprised a Clojure programmer would have much respect for Rails. Its aggressive share-nothing approach leads to inconsistency, poor performance, awkward architectures, and over-reliance on external state management.

When evaluating what tool to use for a project, there are many things to take into account other than the technical superiority of the tools. Relevance Inc, one of the strongest backer of Clojure, still make use of Rails for client projects. Rails' huge web dev ecosystem really made many common tasks as simple as importing a gem here and there and making a few method calls. It all comes down to the right tool for the right job. I'm interested in your take on how Rails' "share-nothing approach", awkward architectures etc.

> Clojure has all the power of Ruby's dynamism

Yes, and then some. Without repeating what you have already said, I would add efficient persistent data structure to the Clojure's list of awesome tricks. Doing functional programming in ruby and python, for example, will force you to trade value immutability with efficiency -- a penalty that one does not have to pay in Clojure.

Clojure is definitely gathering a lot of following. Like many others, I have picked it up, played with it, and never looked back.

But going back to what was said before. Yes, Clojure is awesome. No, Clojure is not obsoleting Ruby or Python any more than those obsoleted PHP, at least not now.


I enjoyed programming in Clojure, but chose Python once more for a new project because w/ Clojure I don't know which projects are doing well. (Templating? Web app library? Postgresql?).

Wrt Python I know I'll do fine w/ Django, Flask, Jinja2, Psycopg2, Tornado...


You have successfully gotten me to commit myself to looking into Clojure. Any good resources on learning/setting up, or should I go by the seat of my pants?


I find Clojure Programming (http://www.clojurebook.com/) to be an easy and practical introduction of the language. It often compare and contrast the Clojure way of doing things vs scripting languages like Ruby. After that, Joy of Clojure (http://joyofclojure.com/) dives deep into the whys of the language. Even though it was written against Clojure 1.2, it covers advanced topics like continuation passing style that were left out of Clojure Programming.


Cheers; this is going to be fun weekend :)


There are some great books out there, so pick a few and go to town.


Indeed, is there a Clojure equivalent of Scipy / Numpy / Matplotlib? These are invaluable for scientific computing.


Clojure arithmetic is fast enough if you add optional type annotations or otherwise take advantage of unboxed values. Ordinary calculation-intense code will be hundreds of times faster than in Python which might be enough in most cases.

If you need deeper support for vector math, scientific calculations, and the like then Incanter is probably what you want. It does all the complicated fast math stuff that always benefits from carefully planned and hand-tuned libraries.


To be clear... the benefit of Scipy / Numpy / Matplotlib that I'm alluding to is not (necessarily) runtime efficiency -- though, given that many of the linked libraries are standards (eg. LAPACK) and compiled C / Fortran, it is efficient for many operations.

The benefits to scientists are the developer efficiency (rapid prototyping), comprehensive libraries (scientific functions and plotting), interfaces similar to MatLab (eg. slicing), and its standing in the scientific community. It would sort of defeat the purpose to spend valuable research time to reinvent the wheel in another language -- though I would switch to a LISP variant in a heartbeat if there was comparably functionality.


Take a look at Incanter:

http://incanter.org/


Why do you think it obsoletes Ruby&Python? It does target Ruby developer with borrowing some syntax, but the paradigm shift needed to jump on the "functional" train is quite big. It is nice language but it solves the problem that I don't have (performance&concurrency) so I am not all that eager to make a switch.


Everyone has performance and concurrency problems, eventually. What's great about Clojure is it gives you a path to ease into them.

Compare a Noir or even bare Compojure web service vs. a Sinatra web service. Is there really a big winner on brevity?


I didn't try Compojure, but Noir seems succinct enough. It's just that functional programming doesn't blend well with my brain. For some problem it does, for some it doesn't. Since you mention performance, I am wondering and was not able to find any benchmarks in Noir vs. Sinatra for rest server for example.


Noir is a series of extensions on Compojure.

Anyways, I can give you bullshit benchmarks if you want. The numbers are sort of meaningless, the benchmark synthetic, the methodology poor but it's almost all against the server's favor.

    (GET "/hello" [] {:status 200 :body "Yo!"}))
And then let's just httperf that from the same box like that is meaningful (it is not):

    ~ > httperf --hog --server localhost --port 9999 --uri=/hello --num-conn 5000 --num-calls 1

    ... 

    Connection rate: 4769.8 conn/s (0.2 ms/conn, <=1 concurrent connections)
    Connection time [ms]: min 0.2 avg 0.2 max 3.8 median 0.5 stddev 0.1
    Connection time [ms]: connect 0.0
    Connection length [replies/conn]: 1.000

    ...

    Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
    Reply time [ms]: response 0.2 transfer 0.0
    Reply size [B]: header 98.0 content 3.0 footer 0.0 (total 101.0)
    Reply status: 1xx=0 2xx=4999 3xx=0 4xx=0 5xx=0
Similar benchmarks put a static sinatra responder at 3ms on my box.

Again, these numbers are not precise or useful. They're just there to put some flags in the ground for further exploration should you want to do a rigorous comparison.


Did I understand you correctly?

3ms vs. 0.2ms

So we might be talking about order of a magnitude here?


I agree, some algorithms didn't translate well from Python to Clojure. Also, I wouldn't want to process mp3 files in Clojure... but that is probably a good match for Java.


>Because to assume otherwise that would imply that everyone knows every language and some are uniform winners over others. Do you know every language you have rejected? Heck, do you even know the general characteristics of Lisp, or Haskell, or ML, or Anic, or Pike, or APL? No, and to really try and learn all of them would take a lot of time unless you're quite gifted. So the premiere and popular programming languages are as unpredictable as fashion.

That's quite a jump to an (invalid) conclusion.

Sure, no programmer has knows of all the languages he does not use or has rejected. But that doesn't mean that there is not a reason some language gain traction and get to be known by lots of programmers and others do not.

You seem to have the simple minded view that simply because I haven't heard of all the languages I don't use, it is random which ones I do use. That's not how it works.

It works by statistics and aggregates. I may not know language X I do not use, and I might know Y, which I do use. But this is not random, it's because of various forces at play, that made Y more widely known and X less so. For example, C provided raw speed with less memory use at a time it was very crucial, was easy to learn, had free/cheap compilers available, it was the language UNIX was written in, and it was simple enough. Oh, and portable. Those things got it traction. Lisp was mostly used in academia-AI, was slow at the time, compilers cost an arm and a leg and Lisp Machines even more so, and was associated with the "AI winter". Those are some reasons it did not do well.


> You seem to have the simple minded view that simply because I haven't heard of all the languages I don't use, it is random which ones I do use. That's not how it works.

But then:

> But this is not random, it's because of various forces at play, that made Y more widely known and X less so.

Where "various forces" is furious handwaving for the sheer randomness that made that set available to you. And let's say in a slightly different history that set is slightly different (but still contains your current choice), how do you know you would have ended up the same?

But perhaps I am being lamentably simple minded. Every decision you make is deliberate and justifiable.


>Where "various forces" is furious handwaving for the sheer randomness that made that set available to you.

You keep using that word, random. I don't think it means what you think it means.

A coin toss is random. C picking up for the stuff we did in the eighties is not random. Lisp losing traction after the AI winter is not random. Javascript gaining traction with the web is not random.

That the creation of C was effected by random events (the experiences of Ken Thompson, the position of AT&T, the decision to provide the source, etc), does not mean that the success was random.

The success was logical and repeatable given the needs of the era and how the language came to be. To put it in another way, if another language had taken the role of C in the industry at the time, it would have been pretty similar to C, and with external qualifications (availability of source, portability, etc) similar to C.

From this aspect, the (random) fact that it was C after all and not some other C-like language, doesn't matter at all. The language that would have filled C's role would have quacked like C, and that is the non-random, and substantial part.

Read the "Worse is better" for some background.


> A coin toss is random. C picking up for the stuff we did in the eighties is not random. Lisp losing traction after the AI winter is not random. Javascript gaining traction with the web is not random.

Why is a coin toss any more random than a specific language gaining traction? It's called "(extreme) sensitivity to initial conditions." Many of which are neither observable nor predictable.


>Why is a coin toss any more random than a specific language gaining traction? It's called "(extreme) sensitivity to initial conditions." Many of which are neither observable nor predictable.

Because my argument was not about a "specific" language.

It was about C-capability language gaining and Lisp-capability language losing ground at that era.

That the C-capability language was C itself, well, that be more or less random.

But that people DID need a portable, close to the metal, constrained with regards to memory use, pointer using, simple to create compilers for, close to assembly language at the time because CPUs and memory were constrained, that was not random, that was a necessity.

And, no, there wasn't "extreme sensitivity to initial conditions" to that. The initial conditions varied at the ten odd years it took for the language to gain traction. And Lisps (including CL, Clojure etc) have been going up and down since the early sixties. It's not like some initial condition set the tone, tons of decisions, several of them important and with predictable consequences set the tone.


> It was about C-capability language gaining and Lisp-capability language losing ground at that era.

And why didn't Fortran win? It meets these requirements. Didn't Forth exist back then too? That meets these requirements.


Perhaps you missed the part of my comment where I SPECIFICALLY addressed that issue.

That is, the part where I wrote:

my argument was not about a "specific" language. It was about C-capability language gaining and Lisp-capability language losing ground at that era. That the C-capability language was C itself, well, that be more or less random.

Either the languages competing were close to what was needed for the machines of the era and the dynamics of the marker (in which case they were more or less similar and which one won was random) or the languages had very different characteristics (in which case which "style" of languages won can be explained).

Languages close together (e.g C and Pascal) won or lost for less significant and more random reasons than the ones that led whole language families to win or lose.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: