Another go at the Next Big Language • Hacker News Board

Re: Another go at the Next Big Language

#91

Post by nacker » Mon, Sep 03, 2012, 12:10 PM UTC

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…

Paradoxically, Lisp depletes the ego. Too many choices.

http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

Re: Another go at the Next Big Language

#92

Post by nacker » Mon, Sep 03, 2012, 12:18 PM UTC

tsahyt wrote: post #49

eckyptang wrote: post #42

Earlier quoted context omitted.

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

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

Have you looked at http://pyjs.org ? I can't understand why it has got so little traction. Is GWT not considered a "proper" GUI library?

Re: Another go at the Next Big Language

#93

Post by batista » Mon, Sep 03, 2012, 12:35 PM UTC

jhuni wrote: post #90

batista wrote: post #89

Earlier quoted context omitted.

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

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

Re: Another go at the Next Big Language

#94

Post by wazoox » Mon, Sep 03, 2012, 12:53 PM UTC

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…

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

Re: Another go at the Next Big Language

#95

Post by vrotaru » Mon, Sep 03, 2012, 1:37 PM UTC

viraptor wrote: post #76

vrotaru wrote: post #56

Earlier quoted context omitted.

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…

I don't think it would be that nice. For good error reports back to the user, you'd have to have a fairly large amount of logic in the catch block. If you have a function that copies data from one file to the other and catch some sort of IOException, you'd end up trying to analyse what it is to report it properly. After all, it could be either one of the files, while opening, closing, reading, writing, ...

_For good error reports back to the user, you'd have to have a fairly large amount of logic in the catch block._

Serious question. How is that a reason to have that _amount of logic_ in the function body?

Having IDE/editors which can fold blocks of code and having the catch blocks collapsed by default will make code reading/understanding of code easier. IMO.

Actually, I may try something like makng the try-cacth the body of the function on a small to medium size project just to see the tradeoffs.

Re: Another go at the Next Big Language

#96

Post by Dn_Ab » Mon, Sep 03, 2012, 1:47 PM UTC

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…

There is still something to be said about languages that try to reduce the amount of time you spend Testing, debugging, profiling and optimization. Where the goal is to aid you in getting as much of the concept intact to the computer with as little effort as possible. End goal is of course AI.

Re: Another go at the Next Big Language

#97

Post by fauigerzigerk » Mon, Sep 03, 2012, 2:07 PM UTC

batista wrote: post #74

fauigerzigerk wrote: post #45

Earlier quoted context omitted.

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

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

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.

Re: Another go at the Next Big Language

#98

Post by RivieraKid » Mon, Sep 03, 2012, 2:17 PM UTC

jhuni wrote: post #88

RivieraKid wrote: post #80

Earlier quoted context omitted.

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

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

Re: Another go at the Next Big Language

#99

Post by pdw » Mon, Sep 03, 2012, 2:34 PM UTC

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…

I don't know which paper you read, but C++ supports exactly that syntax. It's rarely seen in the wild as many older compilers didn't implement it and honestly, who wants to remember yet another oddball C++ syntax variation?

Re: Another go at the Next Big Language

#100

Post by cageface » Mon, Sep 03, 2012, 3:25 PM UTC

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…

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.