"I think it’s important to attract the programmers who Graham says are “the masses” or non-hackers. Without them, the real hackers won’t come to your language en masse either."
I'm not so sure about this conclusion. World-class hackers may be so preoccupied with deeper breakthroughs that one particular fledgling language isn't on their radar, sure. But the masses probably won't adopt a language unless their relatively nerdy friends, those who are willing to bend and break social norms to find better alternatives, have already used the language and recommend it.
First, you need people who want to buy a pain reliever. While it's a huge market, it's not for everyone. Once you find people who buy pain relievers, then you need people who want to buy a new kind of pain reliever. After all, plenty of people want the "original" kind, the kind they grew up with. Finally, you need to find the people who are willing to listen to what you have to say about your new pain reliever. The vast majority of folks are just too busy and will ignore you, regardless of how many ads you buy. So you just went from an audience of everyone to an audience a fraction of that size. Not only are these folks hard to find, they're picky as well.
[...]
The old rule was this: Create safe products and combine them with great marketing. Average products for average people. That's broken. The new rule is: Create remarkable products that the right people seek out.
[...]
Differentiate your customers. Find the group that's most profitable. Find the group that's most likely to influence other customers. Figure out how to develop for, advertise to, or reward either group. Ignore the rest. Cater to the customers you would choose if you could choose your customers.
[...]
Think small. One vestige of the TV-industrial complex is a need to think mass. If it doesn't appeal to everyone, the thinking goes, it's not worth it. No longer. Think of the smallest conceivable market and describe a product that overwhelms it with its remarkability. Go from there.
) ; end excerpt
There isn't much hard substance in this excerpt, just some philosophy and an appeal to authority. Nevertheless, it's at least as good as what I could have said. :-p
---
"Another problem for Lisp is that the rest of the world doesn’t think or work like Lisp."
Actually, when I look at how programmers of non-lisp languages get things done, I'm regularly surprised to see how much they behave like lisp programmers.
Programmers often make EDSLs and custom parsers and preprocessors to model their problem space. Just look at Ruby on Rails, C's Yacc, and Template Haskell.
Programmers often represent their code using ad hoc structured data instead of flat text. Just look at Ant's use of XML for build scripts and MongoDB's use of JSON for database queries.
---
"It’s not hard to realise that people expect [...] to be able to call fork and have a new operating-system–level process appear."
This is a case where I'm personally oblivious and might not know what I'm missing. :)
"This also means Lisps should have an object system."
That came out of left field. Based on the context, it sounds like the point of having an object system is to communicate with standard object-based APIs. But object-based APIs don't all use the same object system, so which one(s) should lisps have?
---
"This also means Lisps should have an object system. I think a basic Lisp on its own provides enough functionality to implement a good-enough object system, in much the same way that Perl’s bless gave way to frameworks like Moose. With lexical closures, a native symbol kind, and cons pairs, we can do everything any other language’s object system can do."
How does that justify adding an object system? If basic lisps already have all they need, that seems more like an argument against.
---
"[other factors] + following the Unix way = success"
I would suggest replacing that with "following the client-side Web way," but I'm afraid the result would be "success + ball of mud" either way. ;)
The rest of the world may have "pretty good reason[s] for doing things the way it does," but if a language designer fails to understand those reasons and blindly goes for standards-compliance, they won't just reap the benefits; they'll also propagate and entrench the existing defects. Admittedly, the benefits will often be worth the risk.
> "I would say Racket is exactly the language the article is begging for"
Racket does not provide any real depth for libraries. There's a lot of promoting for library depth, but as soon as you attempt to do anything practical you soon realize the available libraries are either really rough drafts or are largely out of date. So I don't believe racket meets this criteria highlighted in the article.
> "This also means Lisps should have an object system."
I'm guessing here, but I believe he's referring to an object system that incorporates high level features such as objects + instances with inheritance etc etc. He should probably read pg's Common Lisp book where I believe pg suggests that a oo-system is a great architecture that is well suited to a small set of projects and unfortunately programmers have learned to apply that system to everything they do simply because the oo-languages force them to do so (what they learn is what they know). He goes on to suggest that most projects would be more aligned with FP language paradigms (ie don't force extra layers of complexity where it's not required). And additionally that these oo features are easily implemented in FP languages should you want them ... Don't quote me on all this...I'm going off memory from reading his book over 5 years ago.
It also could be that he sees other FP languages having oo-systems ... I.e. Doesn't racket have the cobra or corba? for an oo-system? Never used it; so again I'm just going off memory here.
"Racket does not provide any real depth for libraries. There's a lot of promoting for library depth, but as soon as you attempt to do anything practical you soon realize the available libraries are either really rough drafts or are largely out of date."
I've gotten the same impression of Racket libraries, but going by the article, mass-marketing of Racket would be a good way to end up with active libraries: "In other words, if you have people who need libraries, hackers will write them. When you have more libraries, your language looks more attractive to people who need them, so hackers write more of them[...]"
This rings true for me. I think Arc has experienced this phenomenon firsthand.
Anyway, although Racket lacks a variety of libraries, it has an impressive selection of features out of the box.
---
"Doesn't racket have the cobra or corba? for an oo-system?"
Racket has at least a few systems for stateful values with user-defined fields:
I haven't used any of these systems (aside from hash tables, I guess). I rarely use Racket, and when I do, I'm still getting the hang of its module system, lol....
"if a language designer fails to understand those reasons and blindly goes for standards-compliance, they won't just reap the benefits; they'll also propagate and entrench the existing defects."
Replace 'language designer' with 'programmer' and that's my whole philosophy in a nutshell.
In fact, I'd like to even generalize this past software. I was in London over the break and found this really cool looking chair everywhere with a pocket in the seat back: http://i.imgur.com/rTO8O.jpg. It looks quaint, and it's everywhere, and I kept wondering, what's the use case? What misfits[1] did the designer consider in building it? I could try to think up a few scenarios, but it's deeply unsatisfying to me to not know.
I'd love to live in a world where I can query objects I interact with for their creators, their antecedents, the design process they went through. What was the designer optimizing for? I have no idea how to do this for the real world, but perhaps one can take a stab at this for software? I think if we were better at communicating and managing the design choices made by our various software 'abstractions' we wouldn't need them to be abstractions anymore[2].
To answer your question about the chair - it's seating for a church or chapel. Prayer books and hymnals are kept in the pocket on the back for the use of the people in the row behind.
Ah, many thanks! I now imagine one of the many ancient, stark, beautiful churches that dot London getting rid of their ancient chairs somehow, to be eventually purchased at discount by hipster coffee shops, resulting in unbelievers like me being able to enjoy them. This mental image connects up several memories of my trip, and immeasurably enriches my world.
Thanks! I woulda missed that if you hadn't posted this. It got me to finally post a long-gestating comment on arc's continuation-based webapp framework: https://news.ycombinator.com/item?id=5032739
"This process allows [many] continuations captured by your servlet to be serialized. This means they may be stored on the client’s browser or the server’s disk."
Oh, I was particularly responding to "It also turns out that there's at least one company trying to scale continuation-based servers," which you said afterward. Guess you chose the example you chose, no worries. ^_^
Ah, good point! I didn't think of it then (I think I even had the racket link in the textarea in a different context before I ended up dropping it to the floor.)
Well, at least you got a response from pg regarding Arc. Now, about that outdated Arc home and install page ... :)
EDIT
More seriously:
pg "In retrospect YC would have taken over my life no matter what. It has pushed out essays too, mostly.
I don't consider Arc to have died, incidentally. You used it to say that, and I'm using it to reply. If I ever retired from YC I'd probably start working on it more actively again." [1]
The thread was quite revealing. Or perhaps it just said what we all probably already knew.
