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

81–90 of 125 posts

Re: Another go at the Next Big Language

#81

Post by DeepDuh »

Swizec wrote: post #62
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…

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

As someone who has tried Genetic Programming I can tell you that we're quite far from this becoming a reality. However, maybe there is something to that concept: I can imagine that it's possible to generate a good part of the usual boilerplate (interfaces, function parameters, data initialization, library initializations) knowing the tests. The programmer would still have to choose the names of inner functions and variables and then do the actual implementation. You do not want to leave the implementation itself to an AI, at least not any AI we know right now.

Although, maybe a Watson-like AI fed with knowledge from stack overflow and official code examples might change that in the future ;).

Re: Another go at the Next Big Language

#82

Post by DeepDuh »

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've found that the least amount of mental overhead is still achieved by doing all the necessary tests right where the 'useful' code is taking place, raising a standard Exception but with a good error description and doing a Pokemon-catch somewhere in main(). Not good enough for system programming of course, but for everything you want to fail early it's fine.

If we do talk about system programming: Error handling IMO is its main difference to 'other' programming. The necessity of deciding (and in case of security relevant systems testing) for all eventualities is why only veteran programmers should do that job.

Re: Another go at the Next Big Language

#83

Post by jhuni »

batista wrote: post #78
jhuni wrote: post #46

Earlier quoted context omitted.

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

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

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

http://wiki.theory.org/YourLanguageSucks#C_sucks_because:

Re: Another go at the Next Big Language

#84

Post by yxhuvud »

vrotaru wrote: post #56
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 t…

Ruby already does that implicitly. Each method have an implicit begin, allowing you to write code like

def hello return do_someting rescue FooError return :fail end

Re: Another go at the Next Big Language

#85

Post by jhuni »

batista wrote: post #77
tensor wrote: post #71

Earlier quoted context omitted.

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 'nosq…

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

The popularity of the language and the applications built in it are irrelevant to the quality of the language itself.

Re: Another go at the Next Big Language

#86

Post by seanmcdirmid »

qznc wrote: post #53
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

Unless your language research focuses on debugging, IDE, standard library; I don't bother with multi-platform, performance, and deployment, but I know others that do. Really, we are just single people, we are not out to create the NBL, we are out to push things forward and create well-thought-out ideas that could be included in the next NBL, and we realize that most of our ideas will fail to make it big time. But perhaps some of them will survive and have an impact (so is the depressing life of an academic programming language design researcher).

Re: Another go at the Next Big Language

#87

Post by [deleted] »

qznc wrote: post #53
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

[deleted]

Re: Another go at the Next Big Language

#88

Post by jhuni »

RivieraKid wrote: post #80
jhuni wrote: post #27

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…

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).…

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

Re: Another go at the Next Big Language

#89

Post by batista »

jhuni wrote: post #85
batista wrote: post #77

Earlier quoted context omitted.

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

The popularity of the language and the applications built in it are irrelevant to the quality of the language itself.

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

Re: Another go at the Next Big Language

#90

Post by jhuni »

batista wrote: post #89
jhuni wrote: post #85

Earlier quoted context omitted.

The popularity of the language and the applications built in it are irrelevant to the quality of the language itself.

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

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.
Post reply on HN