Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Another go at the Next Big Language

dave.cheney.net

Post reply on HN
Print view View original

51–60 of 125 posts

Re: Another go at the Next Big Language

#51

Post by InclinedPlane »

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.

Re: Another go at the Next Big Language

#52

Post by qznc »

andrewflnr wrote: post #32
PuerkitoBio wrote: post #15

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

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/BSD-2-Clause

From 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 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.

Re: Another go at the Next Big Language

#53

Post by qznc »

InclinedPlane wrote: post #51

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 fro…

The main problem of academic languages is that they improve one or two aspects and neglect the rest. Real world languages must improve one or two aspects without hurting the rest too bad.

The rest means for example: debugging, IDE, multi-platform, standard library, performance, deployment

Re: Another go at the Next Big Language

#54

Post by krichman »

6ren wrote: post #30
krichman wrote: post #26

Earlier quoted context omitted.

I read this article last week, lost it, and was looking for it yesterday. You just saved me a long hour of guessing at terminology. This seems like a large step in the right direction for exception handling, but I think it still has the problems that the programmer writing the function that can throw needs to enumerate a number of cases to make it effective, and the programmer calling that function needs to have docu…

Google's web history, with its toolbar, allows you to search the pages you've visited before (not just their titles, as in browser history). That is, you can search the subset of web that you've seen http://support.google.com/accounts/bin/answer.py?hl=en&a... NB: Google will then have all your base, and people on HN have recommended turning off google web history altogether (let alone the toolbar!). I mention it, bec…

It is much better than using browser tabs for an archive - I'd rather not let Google have all my base, though. I'm thinking I'll do a bookmarking solution one of these weekends that syncs to a webserver I own.

Re: Another go at the Next Big Language

#55

Post by buu700 »

nyan_sandwich wrote: post #6

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…

In Lua, markdown (discount) is a single function

https://github.com/buu700/upskirt.go

Re: Another go at the Next Big Language

#56

Post by vrotaru »

rogerbinns wrote: post #2

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 somewher…

I remember reading a paper proposing error handling to be done only at function not block boundaries. A minimal change from the normal exceptions will be something like this:

    function foo(bar, quux, zut) try {
        var a = frobincate(bar, quux);
        return bubinate(a, zut);
    } catch (e) {
        // Stuff        
    } finally {
        // Stuff
    }
Whether such a change will make code easier to write, read and maintain is hard to say. Writing a language that compiles to JavaScript and uses that syntax shouldn't be that hard. I'm partly tempted, but I almost never program in JS

Re: Another go at the Next Big Language

#57

Post by pcwalton »

InclinedPlane wrote: post #51

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 fro…

Languages that come out of academia don't really focus on syntax much (unless you count research into macros for Racket/Template Haskell/etc). If anything, the lack of attention paid to syntax tends to hurt research languages' adoption.

Re: Another go at the Next Big Language

#59

Post by davidw »

james4k wrote: post #22
logn wrote: post #19

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 . I'm not sure why one test is 100x slower, but the rest are <…

I don't know, I'd say JavaScript is pretty close to reaching its peak at this point, if it hasn't already.

It's got tons of room to grow outside the browser where it's never been used all that much.

Re: Another go at the Next Big Language

#60

Post by arnsholt »

kleiba wrote: post #29
nyan_sandwich wrote: post #6

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…

* []byte and string aren't the same. ...and how could they be?

Despite Unicode being something like 20 years old, people still expect strings to be byte arrays and other assorted lunacy, like reading from file not requiring stuff like encodings. "How hard can it be" to just figure out which encoding the file has, after all...
Post reply on HN