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.
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 :)
I 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)?
> 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.
I 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.)
In the C-based languages that you apparently familiar with there are several control statements that aren't expressions like for, if, while, and do. For example, here is how you can use the if statement in C:
if (a >= 0) {
printf("Positive");
} else {
printf("Negative");
}
The if control statement in C can only be used to induce side effects, such as printing to stdout, it can not be used for functional programming. On the other hand, Lisp is an expression oriented language, so expressions such as if can be used as values for functional programming:
(if (<= 0 a)
"Positive"
"Negative")
The same principle applies to the let statement. It is an expression so that you can use it without ever resorting to creating mutable state or inducing side effects. If you allow emacs to automatically handle the nesting involved with your statements, then there it shouldn't really be an inconvience. However, when you need global mutable state use def:
(def x (Math/sqrt (+ 256 (* a a)))
(def y (Math/log (- (+ a b) (/ 1 (+ (* b b b))))
(prn (* 2 (+ x y)))
Clojure encourages good practices like avoiding local mutable state. That said, if you want to you can always create your own local environment to declare local mutable state:
>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?).
Going by popularity, C syntax is indeed king. In the 16th century, going by popularity, it was best not to shower or otherwise clean yourself.
Popularity is not a useful metric. It would be nice to see studies of languages and productivity, I agree. However, it's made incredibly difficult by those who adhere to popularity. The result, languages like php, frameworks like node.js, and misunderstood movements like 'nosql.'
>Going by popularity, C syntax is indeed king. In the 16th century, going by popularity, it was best not to shower or otherwise clean yourself.
Only I didn't go by popularity, I went by results: most of the must-have programs the world uses every day are written in C/C++, and almost none of them are written in Lisps (in the order of statistical noise).
Saying that that is just due to popularity ("C is more popular so offcourse more programs are written in it") is not really valid. Lisp has the headstart on C, it had a chance (AI, the Lisp Machine era), etc.
In the very least, you would expect the Lisp advocates to have a few killer-apps to show for all that superiority, the kind of stuff lone-worf team-of-one C/C++ programmers churn out (and a lot of them are mighty popular).
>The popularity of the language and the applications built in it are irrelevant to the quality of the language itself.
This borders on the mystical. There is no intrinsic quality that a language has if that quality can not be measured in some way.
A "better quality" language that does not account for it in more useful programs being written in it, is like a "good man" that never did any good deeds. Even if in some mystical, esoteric way, it was true, it would be of no consequence. Only what has actual consequence in the outside world matters in engineering (and programming).
(I didn't wrote "in more better programs being written in it" because that would be a vicious circle).
Programming languages are standalone products, that can evaluated regardless of their environment. For example, anyone reasonable can see that is brainfuck is a deeply flawed language regardless of the applications written it. If you cannot evaluate a language on its own merits, there is really no point in talking to you about this.
>Programming languages are standalone products, that can evaluated regardless of their environment.
Only in some abstract way, that is of no consequence to the practice of programming.
Because in the real world the environment very much matters, and the best proof that "it works and gives results" it to see it, er, working and giving results.
>For example, anyone reasonable can see that is brainfuck is a deeply flawed language regardless of the applications written it.
Only the C/Lisp issue is not that trivial. Brainfuck was designed to be "deeply flawed", whereas C/Lisp were designed to have different, specific, constraints and strengths.
Or, reversely, it is because there are NO applications written in in brainfuck that we can safely deduce that it has some problems (empirical observation). If hundreds of killer apps were written in it we would have to reexamine our assumptions about it (but of course, it would have to be a different language for that). So cause and effect are lined in a feedback circle in these evaluations.
>If you cannot evaluate a language on its own merits, there is really no point in talking to you about this.
Languages are not works of art. They are tools. Tools are not to be evaluated "on their own merits", they are to be evaluated by their results.
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.
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 ;-)
Although 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
>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.".
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?
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.
>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.
I'm not expecting equal bodies of work. Just show something.
Forget the enterprise, big companies and such. How about lone wolf programmers? Where are the Lisp gurus "beating the averages" and producing some killer stuff? 3-4 apps would suffice. For Lisp I can see very few things, statistical noise almost. Heck, even Erlang has Riak.
One way to see it is: "of course Lisp doesn't have a large body of A-list programs written in it, since it has less programmers". This is your reading of the situation.
Another way, though, is:
"there is a reason Lisp doesn't have as much A-list programs written in it, and it's not adoption. The reason goes deeper and it also explains adoption".
One explanation: Lisp was too high level for the machines of past era to run sufficiently. That explains why it didn't caught on in the past. It means that despite being conceptually better, it was a bad language for the problems most people were trying to solve (squeeze the last trace of CPU and memory juice from very constrained hardware).
And now? Now other languages have the most essential of the high level features it used to have, so other factors weight more in using them over Lisp (e.g available programmers, libraries, etc). Which means again that despite being conceptually better, it is a bad language for the things people do now (front end web stuff needs JS, enterprise needs Java/.NET and Oracle/MS support, embedded needs C, web apps need Node/RoR/Django/PHP, etc).
And let's take the scientific computing field. Even if Lisp, the language, has 70 productivity points over 50 for Python, the Environment for Python has 80 points (NymPu, Scipy, Sage, etc) over 20 for Lisp.
(The numbers are out of my ass, but you can make a similar thought experiment and, people that make it come to similar conclusions when they pick their tools. Even PG if he had to build something today he would have picked RoR, not CL).
Lisp guys tend to argue that Lisp has "language productivity" of 100, but I don't think so. And even it it has it's not 2-10 times the productivity of something like Python the language. Maybe 20-30% better.
In the grande scheme of things, macros don't matter that much.
There certainly are other factors than a language's productivity. I don't dispute that at all, or I wouldn't be writing so much code in C++.
But I think language popularity has very little to do with productivity or any other rational factor. Languages mostly piggyback on platforms that emerge rapidly at some point in history.
C came with Unix. JavaScript and Java came with Web browsers. SQL came with relational databases. Objective-C became widely used (if not poplar) with the iPhone. PHP came preinstalled with shared web hosting. C# comes with Windows. VBA comes with Office, etc.
Developers mostly just choose platforms not languages. Whoever makes the platform decides on the language and it will be "popular" regardless of how atrocious it may be.
> Because you just (presumably) discovered the hammer of Lisp, it doesn't mean anything has to be Lisp like.
I didn't "just discover the hammer of Lisp", I discovered it quite a while ago and I haven't looked back since. For example, I have been posting Lisp code in this blog for at least a couple of years: http://lisp-ai.blogspot.com/.
> Where is your PROOF for what you say, computer SCIENTIST?
The burden of proof is not on the Lisp community to prove the worth of its fifty year old technology. Lisp outdates C-based languages by at least a decade, so it really should be up to C and the other new languages to prove their worth.
So the burden of proof isn't on me, its up to YOU to prove to me that there is a new language that has advantages over Lisp. And if your designing the "next big language" please prove to me that there is any reason Lispers should be interested in it.
>The burden of proof is not on the Lisp community to prove the worth of its fifty year old technology. Lisp outdates C-based languages by at least a decade, so it really should be up to C and the other new languages to prove their worth.
The burden of proof doesn't change sides based on ...age. Algol68 is older than Haskell, but still most experts will agree that Haskell is better.
As for it being "up to C and the other new languages to prove their worth." that's what I just said. By ratio of useful, must have programs (including code used in space missions), C wins, and Lisp doesn't have much (if anything) to show for.
I discovered a long time ago that the benefits of Lisp are more than outweighed by the frothing zealotry of a lot of the members of the Lisp community that just can't see that almost every single language design decision is about tradeoffs and not about right or wrong.
Lisp seems to attract people that are a little mentally imbalanced.
> By ratio of useful, must have programs (including code used in space missions), C wins, and Lisp doesn't have much (if anything) to show for.
Those programs may as well as have been written in brainfuck for all I care. You can write as many programs you want in a language, that doesn't make that language better.
At the very earliest stage in their functioning, C programs go through a pre-processor that is so horribly stupid it was completely removed from D. Thats just the start of it...
> 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.