7 ms·
If you are looking for a new language you are not looking for the right thing. We already have the language of mathematics and the homoiconic programming langua
by jhuni 14y ago
If you are looking for a new language you are not looking for the right thing. We already have the language of mathematics and the homoiconic programming language Lisp. What we need isn't a new language, its a new platform which uses Lisp all the way down. Unfortunately, I don't see that happening anytime soon.
> Rule #1: C-like syntax
Just what we need! Another programming language with C-syntax! Its not like we don't already have thousands of those, none of them better then the other. I think this new language should be renamed from the next big language to just another C-based language.
> Personally I had hopes for Clojure, but I realise that the same people who think that knowing what a Monad is makes them mathematicians also think they’re being hip and edgy by pointing out that Lisp has a lot of parentheses.
A more accurate statement would be that Lisp code has a lot of links (pointers between data structures). Lisp code is a linked data structure, it doesn't have any parenthesis. However, Lisp code is sometimes presented with S-expressions which do have parenthesis.
- qxcv 14y agoYou should really read Steve Yegge's original blog post[0] before reading this submission. [0]: http://steve-yegge.blogspot.com.au/2007/02/next-big-language.html http://steve-yegge.blogspot.com.au/2007/02/next-big-language...
- batista 14y ago>If you are looking for a new language you are not looking for the right thing. We already have the language of mathematics and the homoiconic programming language Lisp. What we need isn't a new language, its a new platform which uses Lisp all the way down. Unfortunately, I don't see that happening anytime soon. Because you just (presumably) discovered the hammer of Lisp, it doesn't mean anything has to be Lisp like. Even more so that the supposed superiority of Lisp is mostly anecdotal -- no actual studies on developer productivity, product robustness, etc: all anecdotes. Where is your PROOF for what you say, computer SCIENTIST? If anything, empirical data favor languages with C like syntax. More programs we CAN'T DO without have been written in those (from OSs, to office applications, to embedded systems that power almost everything, to servers of all kinds) than in Lisps. In fact, the ratio is incredibly small for Lisp-made world changing programs (Emacs --which is partly C, and then what?).
- fauigerzigerk 14y agoI would love to see a scientific method to measure developer productivity that isn't ridiculously flawed in completely obvious ways. So far I haven't seen one. What I care about is primarily what makes me productive. I don't care if it makes anyone else productive but there is a good chance that it might. Call it proof by induction based on an admittedly shaky prior ;-)
- slurgfest 14y agoAlthough I agree, I also think some numbers are somewhat better than no numbers. Even in the worst case, at least there is something to argue with other than opinions. I won't be shocked if data shows that people do better with things they know well and feel happy about, however
- batista 14y ago>I would love to see a scientific method to measure developer productivity that isn't ridiculously flawed in completely obvious ways. So far I haven't seen one. Well, just use the good old empirical method then. Of all the programs out there that people and businesses need to have, in what languages was the majority written? Do proponents of older, supposedly superior languages have an equal body of work to show for it? >What I care about is primarily what makes me productive. I don't care if it makes anyone else productive but there is a good chance that it might. I'm fine with that, what I tried to counter-argue was the statement "What we need isn't a new language, its a new platform which uses Lisp all the way down.".
- fauigerzigerk 14y agoOf all the programs out there that people and businesses need to have, in what languages was the majority written? Do proponents of older, supposedly superior languages have an equal body of work to show for it? The obvious flaw of this approach is that the majority of people might have written their software in a less than optimal language for reasons unrelated to productivity. Proponents of niche languages, almost by definition, never have a body of work to show that is equal to that of the mainstream languges. If they did, they would _be_ the mainstream. Or to put it more succinctly: The majority can be wrong.
- RivieraKid 14y agoI started with Clojure a few days ago. I mostly like it but: 1. I often need to do something like a = foo; b = bar; c = combine(foo, bar). Using "let" for this in Clojure results in nested and realatively less readable code. 2. Are macros such a nice feature that they justify S-expressions? How useful macros are in your experience? ML-like syntax would be some ways better (e.g. infix arithmetic operators, no parens). 3. When working on non-trivial projects, I find static typing and OOP really useful. Are functional programming languages suitable for bigger real world projects (e.g. a desktop application)?
- jhuni 14y ago> Using "let" for this in Clojure results in nested and realatively less readable code. Why would you have to have nested code? Why can't you just do this: (let [a foo, b bar, c (combine foo bar)]) > Are macros such a nice feature that they justify S-expressions? I'd say S-expressions are the nicest looking syntax, which justifies them regardless of their considerable practical advantages. The only reason you might think that need to be "justified" is that you are still to used to C syntax. Try using S-expressions for a few years first to get used to them. > When working on non-trivial projects, I find static typing and OOP really useful. Again, I think you are just used to mainstream static OOP languages like Java and C++. If you try Clojure for long enough you can get used to its way of programming, which is arguably nicer then the mainstream static OOP way.
- RivieraKid 14y agoWhat I meant was this: (let [x (math/sqrt (+ 256 (* a a))) y (math/log (- (+ a b) (/ 1 (+ a (* b b b))))] (* 2 (+ x y))) In other languages I would do something like this: x = math/sqrt(256 + a * a) y = math/log((a + b) - (1 / (a + (b * b * b)))) 2 * (x + y) As for static typing - in combination with IDE support, it's really useful in larger projects.
- saurik 14y agoI made a reader macro (not technically supported by Clojure, but I don't care) for these situations that provides something I call the "scoping operator". #>a 6 #>(let [b 7]) #>(while true) ... Using this operator, the above code is then equivalent to the below code, which I find much easier to deal with for code that is strictly linear in execution semantics. (let [a 6] (let [b 7] (while true ...))) I don't use it for most functions, however, only those where I find myself otherwise ending up in nested expression hell. When I do, however, it works perfectly with other language features (example: doing a syntax quote on a #> works exactly as one would hope; it is conceptually just a fancy macro). (...and where breaking up the logic into smaller functions would just obfuscate the process, as the steps fundamentally could only be called from a single place anyway, turning the nesting into an even-worse problem of broken apart logic.)
- wazoox 14y ago> just another C-based language. That would be Jacbl, or even if we changed it to "Just another C-like language" we could call it "Jacll" (pronounce like "Jackal"). Now I want this language :)
- mlvljr 14y agoIntentional Programming was once admitted to be the new lisp, btw.