25 ms·

Another go at the Next Big Language

117 points by iand 14y ago

kombine 14y ago
"Two years later however, D was still stuck in 2007. This was in part due to the infighting between the standard library camps who had failed to learn from the mistakes of the Java class library and were busily adding bloat and verbosity to Phobos and Mango." This was never a case for Phobos. D still lacks a lot, but Phobos is a pretty lean library. It's built around the concepts that were introduced by Alexander Stepanov and STL and refined them to the great extent. Go on contrary has no support for generic programming, therefore I can only imagine how full of ad-hoc algorithms the typical Go code is. So yes, for me it's definitely not the NBL but just a niche language. D still has a lot of issues, but as a language it's better than Go.
pshc 14y ago
The NBL requires a Next Generation Editor. We can't escape from this local maxima of code expressiveness, readability, amenability to change, richness of types, etc. without a truly better programming environment. Working on it...
rogerbinns 14y ago
My kingdom for someone who can figure out how to solve error handling. My code consists of some reasonably straightforward sequence of actions with a random smattering of error handling significantly distracting from that. That error handling code is tedious to write, very time consuming to test (and often virtually impossible) and usually not run very often. Exceptions at least let you put the handling code somewhere other than the normal sequence (although you may still have some finallys), continuations are quite nice, and the Go/C model pollutes the code but puts the error handling right next to the error detection. None of these really solve the problem though. How can I have the least amount of error handling code possible, how can I test it, and how can I be sure it is correct, and all while spending my mental efforts on the code that actually does useful things?
- kevingadd 14y ago
  The Erlang process model seems like the closest thing to a panacea here. It forces you to write robust software automatically. I haven't used that approach enough to know if it gets you the whole way to shipped, though. (Note: Not specifically advocating Erlang The Language, just its approach to isolation and error recovery)
  - pcwalton 14y ago
    Rust uses the Erlang model. Generally failing the task on error has worked well in practice, although there are times when we have to use result types and pattern matching (basically error codes, but more reliable since the compiler forces you to use them correctly). The vast majority of errors are handled either locally or by failing the task.
  - rdtsc 14y ago
    > Note: Not specifically advocating Erlang The Language, Why not. If you have a panacea for robust error handling (they call it fault tolerance) coupled with auto-magic cross-CPU and (with some work) cross-machine scaling why not advocate the language. Anyone else will just be re-implementing that in an incomplete way. So you can have say an OS process like an Erlang process. That's one way. But now need to implement a supervision hierarchy. Ok so talking about SIGCHILD, pids and what signal to use to kill the process (SIGTERM or SIGKILL). Then of course these processes have to talk to each other so must pick a distributed messaging system. Then need to pick a restart strategy (ok so the process failed but we restarted it but it keeps failing and we keep restarting so perhaps that in an of itself is a failure and a higher process in the chain should be restarted...). Stuff like that. By the time that's done and looking back at the code you'd wonder, why didn't I just used Erlang with all this built it...
- yanatan16 14y ago
  You don't want a language to force error handling on you. Error handling is different in every case. Go only tries to force you to deal with errors instead of allowing you to ignore them until an exception is thrown. There is never going to be an all-purpose error handling answer. Its just a matter of deciding where your error handling code is placed.
deleted 14y ago
[deleted]
nyan_sandwich 14y ago
I was really excited about Go. Designed by some gurus, seemed to get everything right, google app engine supported it. Then I tried to build something. Java-like verbosity. Meh, I can deal with it. []byte and string aren't the same. Whatever, a few extra lines and thot cycles here and there, no big deal. Overly complex library functions. Let me explain this one. In Lua, markdown (discount) is a single function. In Go, there was a bunch of extra stuff that just seemed like noise. Likewise for cypto, Base64, stringwriters, bunch of other stuff. A bunch of little annoying stuff like that adds up. Eventually I just said fuck it. Maybe I'm not hardcore enough or something, but now I'm back with LuaJIT. Goroutines are cool, tho. Lua's synchronous threads aren't quite the same. Also google's app engine datastore is sweet. Nice and simple, no screwing around with SQL. If I had to do systems stuff, I'd reach for Go. LuaJIT is faster anyways.
- encoderer 14y ago
  > LuaJIT is faster anyways. This man speaks the truth. Well, actually, I know nothing about Lua. But I do know that Go currently isn't very fast. I mean, compared to highly dynamic languages the performance is fine. But compared to C++ or even modern JVM it's meh. I feel like there's going to be improvement here, though, and I wouldn't be surprised if the versions of golang used internally at Google aren't faster. My take has been to use it the way I imagine Google does. If I'm not building something that uses protobuffs and goroutines I do it in Python.
  - kristianp 14y ago
    When you say that Go currently isn't very fast, maybe you should try coding something in it. I found it to be suprisingly fast. I think if you are doing a lot of memory allocation, then the garbage collection may slow you down, but I wouldn't be suprised if it's still faster than a jitted language like LuaJIT.
    - batista 14y ago
      >When you say that Go currently isn't very fast, maybe you should try coding something in it. I found it to be suprisingly fast. I've tried in in 2-3 things which I re-implemented afterwards in C and had before in Python. In all cases it has about 2x the speed of Python, which I consider meh. (The tasks where mostly parsing some huge files and doing some filtering and computations, and C made it IO bound while Python/Go both had it CPU bound).
PuerkitoBio 14y ago
I believe Go is actually BSD-Licensed, not MIT. Though from what I understand these are very similar (permissive) licenses.
- andrewflnr 14y ago
  They're almost interchangeable. If I wasn't reading carefully I probably wouldn't notice the difference. http://opensource.org/licenses/MIT http://opensource.org/licenses/MIT http://opensource.org/licenses/BSD-2-Clause http://opensource.org/licenses/BSD-2-Clause
  - qznc 14y ago
    From http://producingoss.com/en/license-choosing.html http://producingoss.com/en/license-choosing.html : There is perhaps one reason to prefer the revised BSD license to the MIT/X license, which is that the BSD includes this clause: Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. It's not clear that without such a clause, a recipient of the software would have had the right to use the licensor's name anyway, but the clause removes any possible doubt. For organizations worried about trademark control, therefore, the revised BSD license may be slightly preferable to MIT/X. In general, however, a liberal copyright license does not imply that recipients have any right to use or dilute your trademarks — copyright law and trademark law are two different beasts.
ecolak 14y ago
It's a pity that we are still talking about things like syntax in the context of a next big language. Programs are still full of bugs, especially concurrent programs, lots of time and effort is still spent on testing. At this day and age, the NBL should be a language that helps or guides a programmer write correct concurrent programs with good performance. It should prevent programmers from making mistakes as much as possible. I think the NBL will be in the same school as Erlang and Scala.
- dsymonds 14y ago
  Syntax is very important for a programming language. It's in your face all the time. A serious downside to many programming languages is their awful or inconsistent syntax, and that results in code that is hard to read and comprehend even before trying to understand what the code is doing.
  - ecolak 14y ago
    It sure is important but who is to say C-style syntax is better than Lisp-style syntax and vice versa. Obviously the NBL should have a sensible and consistent syntax but it has to have a lot more than that to be the NBL. C-style syntax is definitely NOT a must have.
logn 14y ago
I have to agree with the commenters on that article that JavaScript is the next big language. With HTML5 it's pretty amazing what you can do with JS. It's reached the point of being nearly as powerful as any thick client technology yet with ubiquitous browser and OS support. It performs fairly well too: http://shootout.alioth.debian.org/u32/javascript.php http://shootout.alioth.debian.org/u32/javascript.php . I'm not sure why one test is 100x slower, but the rest are < 10x slower than Java.
- james4k 14y ago
  I don't know, I'd say JavaScript is pretty close to reaching its peak at this point, if it hasn't already.
  - davidw 14y ago
    It's got tons of room to grow outside the browser where it's never been used all that much.
- kzahel 14y ago
  The lack of generators in javascript really kills it for me.
- igouy 14y ago
  >>I'm not sure why one test is 100x slower<< See http://stackoverflow.com/questions/7025286/why-does-this-v8-javascript-code-perform-so-badly http://stackoverflow.com/questions/7025286/why-does-this-v8-...
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 ago
  You 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?).
batista 14y ago
[while checking Yegge's list the NBL should have:] >The final tally is 11 affirmative, 7 negative Yes, but among the negative are items with far most importance than among the affirmative.
- eckyptang 14y ago
  I disagree. The negative items are things that people are used to but not necessarily the best solution to the problem: Perl regex: it covers most perl RE features that are important. The RE engine is the only real weak point I see in Go at the moment but that will change in time and it's "good enough" now. Strings and streams as collections: String is a collection of runes - you can get the rune at an index fine. The latter is just wrong - A stream is not byte addressable by nature. Iterators: for not good enough for you? You can build an iterator interface over any type if you desire that but it's really not needed. If it makes you comfortable... Generics: These are really not needed. This is a common misconception. I've come from a heavy OO C# background (DDD, 1000 class models etc) into Go and I've not missed them for a second. In fact I think I've probably been freed from a million bad design decisions and many refactor sessions. Standard OOP: I'm not even going down that route. The hacks you have to do to get proper composite models or some level of dynamicity using "standard OO" is horrible. I wish it would go away. CLOS is the nearest thing to something usable - not what C++, Java, C#, PHP force upon everyone. An there is a cross platform GUI for Go - it's called a web browser. The only nicety I'd like to see is dynamic loading as it'd allow composite, modular applications to be built without compilation but that has its own pitfalls.
  - tsahyt 14y ago
    > An there is a cross platform GUI for Go - it's called a web browser. A web browser is NOT a replacement for a proper GUI library. Writing web GUIs is rather hard in comparison because that was not it's original intention. They're rather slow in comparison because they were not originally intended. The list goes on like this. Everything we did to HTML/CSS/JS in order to "support" those features better of the last decade were just workarounds and things to cover up the fact that we're still dealing with a Markup Language here which is supposed to add semantic meaning to a text or some other piece of information in order to display it. GUI libraries on the other hand were designed to do GUIs. They're designed not just to display information but to handle user input, handle widgets and components of user interfaces. Most importantly though they're designed to be consistent. Consistency is one of the most important aspects of user interface design and ultimately user experience. For example, look at Apple: The whole OSX experience and all the apps it comes with are consistent in look and feel. They've got the same polish on top and the same usability features that come with it. That is what takes most of the burden from users. You learn how to use it once and then you're able to apply that knowledge across many other applications. That is how things start to feel "intuitive". That is what all the UX designers are ultimately aiming for. HTML/CSS/JS enable us to build wildly different GUIs that do their job well but are not consistent for the most part of it. It has enabled designers to go on a rampage, each of them trying to improve on certain aspects. That's good, that's progress but it also comes at a great cost because things stop to feel intuitive and the paradigms of interaction you once learned are rendered invalid. Every site these days is trying to be different to stand out from the crowd and eventually it's all a bloody mess concerning overall UX. The only real use case for web GUIs are GUIs on the web, not native apps. Introducing the same mess we've got on the web nowadays to native desktop apps is not the right way to do it. A proper GUI library is the way to go both for the developer as well as for the user.
spullara 14y ago
What I want is somewhere in the middle of Java, Scala and JavaScript. I have no idea what that looks like exactly though. Maybe Kotlin? Dart?
- joneil 14y ago
  I haven't used much Scala, but Haxe (haxe.org) sits somewhere between Javascript and Java. I enjoy it, ymmv.
zedzedzed 14y ago
Yeah, go is in compition, but Rust is in competion too.
InclinedPlane 14y ago
Here's the core problem with next generation languages. Languages that come out of academia focus too much on syntax and computer science level functionality, and it's extremely rare for a language of that sort to make it in the real world. The languages we use today either come from big companies with the ability to promote anything long enough to get traction on any language that is at least "good" or they come from the "streets". From extremely small teams who create incredibly flawed languages that are immimently practical and go on to rule the world. Perl, Ruby, Javascript, PHP. It's "worse is better" again in spades. Ivory tower language designers try to come up with perfection when what we really need is to improve on the basics. The next big language is probably not going to be something like Haskell (as nice as all that functional purity is) it'll be something that builds profiling and unit testing and better source control support right into the language, compiler, and tools. Edit: if you look at where the average developer is spending most of their time and especially where the majority of the pain is it's typically in things like testing, debugging, performance profiling and optimization, and deployments. And if you look out there in the field you'll see lots and lots of awesome tools and systems helping peoplee tackle those problems. But it's exceedingly rare to see a new language which approaches those problems or tries to codify those tools into first class language features.
- tensor 14y ago
  Go was created in part by Ken Thomson, and supported by Google Inc. In other words, completely the opposite of what you are talking about. Further, anyone who uses the "ivory tower" identifies themselves immediately as someone incredibly biased and political. There are politics in science to be sure, but overall it's frowned on. Understand first principles. Understand your needs and the needs of others. Build something based on that. If you continually follow what is popular you will continue to be below average. By definition, popular is average.
- Swizec 14y ago
  What would be really cool is a language where I just write the tests and the compiler writes the actual code. That would be awesome. Something like what Critticall attempted ten years ago: http://www.critticall.com/ http://www.critticall.com/ The idea there was that an evolutionary algorithm wrote the core code, you just had to give it an environment and some way of knowing the results were still okay.
tosh 14y ago
Dart almost exactly matches what Yegge wrote about a few years back.
cageface 14y ago
I still think that the ability to generate self-contained, static binaries is potentially a huge advantage for Go vs the scripting languages. Instead of installing an interpreter and a bunch of libraries and fiddling with search paths you just copy a single file and go (as it were). Think about what it takes to get something like a PHP photo gallery going vs what it would take with Go, for instance.
jongraehl 14y ago
> I have no hesitation in recommending Go to displace any programming task which would previously have been targeted towards Java. Java is faster and has more libraries.
ankurdhama 14y ago
This comment is for all those people who have written against Lisp in this thread. Lisp was designed to represent/design/play with/experiment with advanced and complex algorithms. Now, when was the last time you wrote a code that was algorithmic or was about some new cool algorithm, try to remember, let me tell you the answer: most probably never ever in your life (and there is no hope in future as well). What you people do is stitch APIs, or more precisely, iOS API, Android API, Some web framework API, DOM API, API API API... look at your code and see it is just a bunch of APIs call thrown in a mix. This is absolutely fine because what you guys build is "Application" (not "Technology") which grab some data from here and there, store it in some shiny DB and when user want it show him in a shiny new UI, that all you do and for this purpose go ahead and use whatever language those APIs are in, no problem at all, but please don't rant about something that you don't understand.

117 points by iand 14y ago

"Two years later however, D was still stuck in 2007. This was in part due to the infighting between the standard library camps who had failed to learn from the mistakes of the Java class library and were busily adding bloat and verbosity to Phobos and Mango." This was never a case for Phobos. D still lacks a lot, but Phobos is a pretty lean library. It's built around the concepts that were introduced by Alexander Stepanov and STL and refined them to the great extent. Go on contrary has no support for generic programming, therefore I can only imagine how full of ad-hoc algorithms the typical Go code is. So yes, for me it's definitely not the NBL but just a niche language. D still has a lot of issues, but as a language it's better than Go.

pshc 14y ago

The NBL requires a Next Generation Editor. We can't escape from this local maxima of code expressiveness, readability, amenability to change, richness of types, etc. without a truly better programming environment. Working on it...

rogerbinns 14y ago

My kingdom for someone who can figure out how to solve error handling. My code consists of some reasonably straightforward sequence of actions with a random smattering of error handling significantly distracting from that. That error handling code is tedious to write, very time consuming to test (and often virtually impossible) and usually not run very often. Exceptions at least let you put the handling code somewhere other than the normal sequence (although you may still have some finallys), continuations are quite nice, and the Go/C model pollutes the code but puts the error handling right next to the error detection. None of these really solve the problem though. How can I have the least amount of error handling code possible, how can I test it, and how can I be sure it is correct, and all while spending my mental efforts on the code that actually does useful things?

kevingadd 14y ago
The Erlang process model seems like the closest thing to a panacea here. It forces you to write robust software automatically. I haven't used that approach enough to know if it gets you the whole way to shipped, though. (Note: Not specifically advocating Erlang The Language, just its approach to isolation and error recovery)
- pcwalton 14y ago
  Rust uses the Erlang model. Generally failing the task on error has worked well in practice, although there are times when we have to use result types and pattern matching (basically error codes, but more reliable since the compiler forces you to use them correctly). The vast majority of errors are handled either locally or by failing the task.
- rdtsc 14y ago
  > Note: Not specifically advocating Erlang The Language, Why not. If you have a panacea for robust error handling (they call it fault tolerance) coupled with auto-magic cross-CPU and (with some work) cross-machine scaling why not advocate the language. Anyone else will just be re-implementing that in an incomplete way. So you can have say an OS process like an Erlang process. That's one way. But now need to implement a supervision hierarchy. Ok so talking about SIGCHILD, pids and what signal to use to kill the process (SIGTERM or SIGKILL). Then of course these processes have to talk to each other so must pick a distributed messaging system. Then need to pick a restart strategy (ok so the process failed but we restarted it but it keeps failing and we keep restarting so perhaps that in an of itself is a failure and a higher process in the chain should be restarted...). Stuff like that. By the time that's done and looking back at the code you'd wonder, why didn't I just used Erlang with all this built it...
yanatan16 14y ago
You don't want a language to force error handling on you. Error handling is different in every case. Go only tries to force you to deal with errors instead of allowing you to ignore them until an exception is thrown. There is never going to be an all-purpose error handling answer. Its just a matter of deciding where your error handling code is placed.

deleted 14y ago

[deleted]

nyan_sandwich 14y ago

I was really excited about Go. Designed by some gurus, seemed to get everything right, google app engine supported it. Then I tried to build something. Java-like verbosity. Meh, I can deal with it. []byte and string aren't the same. Whatever, a few extra lines and thot cycles here and there, no big deal. Overly complex library functions. Let me explain this one. In Lua, markdown (discount) is a single function. In Go, there was a bunch of extra stuff that just seemed like noise. Likewise for cypto, Base64, stringwriters, bunch of other stuff. A bunch of little annoying stuff like that adds up. Eventually I just said fuck it. Maybe I'm not hardcore enough or something, but now I'm back with LuaJIT. Goroutines are cool, tho. Lua's synchronous threads aren't quite the same. Also google's app engine datastore is sweet. Nice and simple, no screwing around with SQL. If I had to do systems stuff, I'd reach for Go. LuaJIT is faster anyways.

encoderer 14y ago
> LuaJIT is faster anyways. This man speaks the truth. Well, actually, I know nothing about Lua. But I do know that Go currently isn't very fast. I mean, compared to highly dynamic languages the performance is fine. But compared to C++ or even modern JVM it's meh. I feel like there's going to be improvement here, though, and I wouldn't be surprised if the versions of golang used internally at Google aren't faster. My take has been to use it the way I imagine Google does. If I'm not building something that uses protobuffs and goroutines I do it in Python.
- kristianp 14y ago
  When you say that Go currently isn't very fast, maybe you should try coding something in it. I found it to be suprisingly fast. I think if you are doing a lot of memory allocation, then the garbage collection may slow you down, but I wouldn't be suprised if it's still faster than a jitted language like LuaJIT.
  - batista 14y ago
    >When you say that Go currently isn't very fast, maybe you should try coding something in it. I found it to be suprisingly fast. I've tried in in 2-3 things which I re-implemented afterwards in C and had before in Python. In all cases it has about 2x the speed of Python, which I consider meh. (The tasks where mostly parsing some huge files and doing some filtering and computations, and C made it IO bound while Python/Go both had it CPU bound).

PuerkitoBio 14y ago

I believe Go is actually BSD-Licensed, not MIT. Though from what I understand these are very similar (permissive) licenses.

andrewflnr 14y ago
They're almost interchangeable. If I wasn't reading carefully I probably wouldn't notice the difference. http://opensource.org/licenses/MIT http://opensource.org/licenses/MIT http://opensource.org/licenses/BSD-2-Clause http://opensource.org/licenses/BSD-2-Clause
- qznc 14y ago
  From http://producingoss.com/en/license-choosing.html http://producingoss.com/en/license-choosing.html : There is perhaps one reason to prefer the revised BSD license to the MIT/X license, which is that the BSD includes this clause: Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. It's not clear that without such a clause, a recipient of the software would have had the right to use the licensor's name anyway, but the clause removes any possible doubt. For organizations worried about trademark control, therefore, the revised BSD license may be slightly preferable to MIT/X. In general, however, a liberal copyright license does not imply that recipients have any right to use or dilute your trademarks — copyright law and trademark law are two different beasts.

ecolak 14y ago

It's a pity that we are still talking about things like syntax in the context of a next big language. Programs are still full of bugs, especially concurrent programs, lots of time and effort is still spent on testing. At this day and age, the NBL should be a language that helps or guides a programmer write correct concurrent programs with good performance. It should prevent programmers from making mistakes as much as possible. I think the NBL will be in the same school as Erlang and Scala.

dsymonds 14y ago
Syntax is very important for a programming language. It's in your face all the time. A serious downside to many programming languages is their awful or inconsistent syntax, and that results in code that is hard to read and comprehend even before trying to understand what the code is doing.
- ecolak 14y ago
  It sure is important but who is to say C-style syntax is better than Lisp-style syntax and vice versa. Obviously the NBL should have a sensible and consistent syntax but it has to have a lot more than that to be the NBL. C-style syntax is definitely NOT a must have.

logn 14y ago

I have to agree with the commenters on that article that JavaScript is the next big language. With HTML5 it's pretty amazing what you can do with JS. It's reached the point of being nearly as powerful as any thick client technology yet with ubiquitous browser and OS support. It performs fairly well too: http://shootout.alioth.debian.org/u32/javascript.php http://shootout.alioth.debian.org/u32/javascript.php . I'm not sure why one test is 100x slower, but the rest are < 10x slower than Java.

james4k 14y ago
I don't know, I'd say JavaScript is pretty close to reaching its peak at this point, if it hasn't already.
- davidw 14y ago
  It's got tons of room to grow outside the browser where it's never been used all that much.
kzahel 14y ago
The lack of generators in javascript really kills it for me.
igouy 14y ago
>>I'm not sure why one test is 100x slower<< See http://stackoverflow.com/questions/7025286/why-does-this-v8-javascript-code-perform-so-badly http://stackoverflow.com/questions/7025286/why-does-this-v8-...

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 ago
You 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?).

batista 14y ago

[while checking Yegge's list the NBL should have:] >The final tally is 11 affirmative, 7 negative Yes, but among the negative are items with far most importance than among the affirmative.

eckyptang 14y ago
I disagree. The negative items are things that people are used to but not necessarily the best solution to the problem: Perl regex: it covers most perl RE features that are important. The RE engine is the only real weak point I see in Go at the moment but that will change in time and it's "good enough" now. Strings and streams as collections: String is a collection of runes - you can get the rune at an index fine. The latter is just wrong - A stream is not byte addressable by nature. Iterators: for not good enough for you? You can build an iterator interface over any type if you desire that but it's really not needed. If it makes you comfortable... Generics: These are really not needed. This is a common misconception. I've come from a heavy OO C# background (DDD, 1000 class models etc) into Go and I've not missed them for a second. In fact I think I've probably been freed from a million bad design decisions and many refactor sessions. Standard OOP: I'm not even going down that route. The hacks you have to do to get proper composite models or some level of dynamicity using "standard OO" is horrible. I wish it would go away. CLOS is the nearest thing to something usable - not what C++, Java, C#, PHP force upon everyone. An there is a cross platform GUI for Go - it's called a web browser. The only nicety I'd like to see is dynamic loading as it'd allow composite, modular applications to be built without compilation but that has its own pitfalls.
- tsahyt 14y ago
  > An there is a cross platform GUI for Go - it's called a web browser. A web browser is NOT a replacement for a proper GUI library. Writing web GUIs is rather hard in comparison because that was not it's original intention. They're rather slow in comparison because they were not originally intended. The list goes on like this. Everything we did to HTML/CSS/JS in order to "support" those features better of the last decade were just workarounds and things to cover up the fact that we're still dealing with a Markup Language here which is supposed to add semantic meaning to a text or some other piece of information in order to display it. GUI libraries on the other hand were designed to do GUIs. They're designed not just to display information but to handle user input, handle widgets and components of user interfaces. Most importantly though they're designed to be consistent. Consistency is one of the most important aspects of user interface design and ultimately user experience. For example, look at Apple: The whole OSX experience and all the apps it comes with are consistent in look and feel. They've got the same polish on top and the same usability features that come with it. That is what takes most of the burden from users. You learn how to use it once and then you're able to apply that knowledge across many other applications. That is how things start to feel "intuitive". That is what all the UX designers are ultimately aiming for. HTML/CSS/JS enable us to build wildly different GUIs that do their job well but are not consistent for the most part of it. It has enabled designers to go on a rampage, each of them trying to improve on certain aspects. That's good, that's progress but it also comes at a great cost because things stop to feel intuitive and the paradigms of interaction you once learned are rendered invalid. Every site these days is trying to be different to stand out from the crowd and eventually it's all a bloody mess concerning overall UX. The only real use case for web GUIs are GUIs on the web, not native apps. Introducing the same mess we've got on the web nowadays to native desktop apps is not the right way to do it. A proper GUI library is the way to go both for the developer as well as for the user.

spullara 14y ago

What I want is somewhere in the middle of Java, Scala and JavaScript. I have no idea what that looks like exactly though. Maybe Kotlin? Dart?

joneil 14y ago
I haven't used much Scala, but Haxe (haxe.org) sits somewhere between Javascript and Java. I enjoy it, ymmv.

zedzedzed 14y ago

Yeah, go is in compition, but Rust is in competion too.

InclinedPlane 14y ago

Here's the core problem with next generation languages. Languages that come out of academia focus too much on syntax and computer science level functionality, and it's extremely rare for a language of that sort to make it in the real world. The languages we use today either come from big companies with the ability to promote anything long enough to get traction on any language that is at least "good" or they come from the "streets". From extremely small teams who create incredibly flawed languages that are immimently practical and go on to rule the world. Perl, Ruby, Javascript, PHP. It's "worse is better" again in spades. Ivory tower language designers try to come up with perfection when what we really need is to improve on the basics. The next big language is probably not going to be something like Haskell (as nice as all that functional purity is) it'll be something that builds profiling and unit testing and better source control support right into the language, compiler, and tools. Edit: if you look at where the average developer is spending most of their time and especially where the majority of the pain is it's typically in things like testing, debugging, performance profiling and optimization, and deployments. And if you look out there in the field you'll see lots and lots of awesome tools and systems helping peoplee tackle those problems. But it's exceedingly rare to see a new language which approaches those problems or tries to codify those tools into first class language features.

tensor 14y ago
Go was created in part by Ken Thomson, and supported by Google Inc. In other words, completely the opposite of what you are talking about. Further, anyone who uses the "ivory tower" identifies themselves immediately as someone incredibly biased and political. There are politics in science to be sure, but overall it's frowned on. Understand first principles. Understand your needs and the needs of others. Build something based on that. If you continually follow what is popular you will continue to be below average. By definition, popular is average.
Swizec 14y ago
What would be really cool is a language where I just write the tests and the compiler writes the actual code. That would be awesome. Something like what Critticall attempted ten years ago: http://www.critticall.com/ http://www.critticall.com/ The idea there was that an evolutionary algorithm wrote the core code, you just had to give it an environment and some way of knowing the results were still okay.

tosh 14y ago

Dart almost exactly matches what Yegge wrote about a few years back.

cageface 14y ago

I still think that the ability to generate self-contained, static binaries is potentially a huge advantage for Go vs the scripting languages. Instead of installing an interpreter and a bunch of libraries and fiddling with search paths you just copy a single file and go (as it were). Think about what it takes to get something like a PHP photo gallery going vs what it would take with Go, for instance.

jongraehl 14y ago

> I have no hesitation in recommending Go to displace any programming task which would previously have been targeted towards Java. Java is faster and has more libraries.

ankurdhama 14y ago

This comment is for all those people who have written against Lisp in this thread. Lisp was designed to represent/design/play with/experiment with advanced and complex algorithms. Now, when was the last time you wrote a code that was algorithmic or was about some new cool algorithm, try to remember, let me tell you the answer: most probably never ever in your life (and there is no hope in future as well). What you people do is stitch APIs, or more precisely, iOS API, Android API, Some web framework API, DOM API, API API API... look at your code and see it is just a bunch of APIs call thrown in a mix. This is absolutely fine because what you guys build is "Application" (not "Technology") which grab some data from here and there, store it in some shiny DB and when user want it show him in a shiny new UI, that all you do and for this purpose go ahead and use whatever language those APIs are in, no problem at all, but please don't rant about something that you don't understand.