= 27d567bc2d48d9f40e9ccc20ea370b15)
gwern comments on Open Thread, June 16-30, 2012 - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (344)
For a certain value of "the Lisp experience", Emacs may be considered more or less mandatory. In order to recommend for or against it I would need more precise knowledge of your goals.
I tried Emacs and decided that I dislike it. I understand the reason why it is like that, but I refuse to lower my user interface expectations that low.
Generally, I have noticed the trend that a software which is praised as superior often comes with a worse user interface, or ignores some other part of user experience. I can understand that a software with smaller userbase cannot put enough resources to its non-critical parts. That makes sense. But I suspect there later appears a mindkilling thread of though, which goes like this: "Our software is superior. Our software does not have a feature X. Therefore, not having a feature X is an advantage, because <rationalization>." As in: we don't need 21st-century-style user interface, because good programmers don't need such things.
By wanting a "Lisp experience" I mean I would like to experience (or falsify the existence of) the nirvana frequently described by Paul Graham. Not to replicate 1:1 Richard Stallman's working conditions in 1980s. :D
A perfect solution would be to combine the powerful features of Lisp with the convenience of modern development tools. I emphasize the convenience for pragmatic reasons, but also as a proxy for "many people with priorities similar to me are using it".
Consider an equilibrium of various software products none of which are strictly superior or inferior to each other. Upon hearing that the best argument someone can make for software X is that it has feature Y (which is unrelated to UI), should your expectation of good IU go up or go down?
(To try it a different way: suppose you are in a highly competitive company like Facebooglazon and you meet a certain programmer who is the rudest most arrogant son of a bitch you ever met - yet he is somehow still employed there. What should you infer about the quality of the code he writes?)
This is a nice example how with different models the same evidence can be evaluated differently.
My model is that programming languages are used for making programs, and for languages used in real production part of that effort goes to the positive-feedback loop of creating better tools and libraries for given language. So if some language makes the production easier -- people like Paul Graham suggest that Lisp is 10 times more productive than other languages --, I would expect better everything.
In other words, the "equilibrium of various software products none of which are strictly superior or inferior to each other" is an evidence against the claim that a language X is 10 times more productive than other languages. Or if it is more productive in some areas, then it must have a huge disadvantage somewhere else.
Fast, reliable, undocumented, obfuscated. :D
Or he is really imployed for some other reason than writing code.
Yup! It's the old 'if you're so good, why aren't you rich' question in more abstract guise. Of course, in the real world, new languages are being developed all the time, so a workable answer is already 'I'm not rich because I'm so new, but I'm getting richer'. This is the sort of answer an up and coming language like Haskell or Scala or Go can make.