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

71–80 of 125 posts

Re: Another go at the Next Big Language

#71

Post by tensor »

batista wrote: post #41
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…

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

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

Re: Another go at the Next Big Language

#72

Post by masklinn »

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.

Nor should it be. I've got plenty of issues with Go, but that most definitely isn't one. It's one of the few things Java got completely right (even though they fucked the String type itself): strings are not bytes.

Re: Another go at the Next Big Language

#73

Post by EdiX »

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?

BTW in go a string can be cast to []byte like this:

    []byte(aString)
it returns the utf-8 bytes, casting to []rune gives unicode codepoints.

Re: Another go at the Next Big Language

#74

Post by batista »

fauigerzigerk wrote: post #45
batista wrote: post #41

Earlier quoted context omitted.

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

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

Re: Another go at the Next Big Language

#75

Post by cageface »

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.

Re: Another go at the Next Big Language

#76

Post by viraptor »

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

Re: Another go at the Next Big Language

#77

Post by batista »

tensor wrote: post #71
batista wrote: post #41

Earlier quoted context omitted.

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

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

Can you point to any, preferably not Emacs?

Re: Another go at the Next Big Language

#78

Post by batista »

jhuni wrote: post #46
batista wrote: post #41

Earlier quoted context omitted.

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

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

Re: Another go at the Next Big Language

#79

Post by batista »

eckyptang wrote: post #42
batista wrote: post #36

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

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…

>I disagree. The negative items are things that people are used to but not necessarily the best solution to the problem

That's what you say, and it might be true or not, but you don't get to use Yegge's list and count positives/negatives when you don't agree with Yegge's priorities.

Re: Another go at the Next Big Language

#80

Post by RivieraKid »

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

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

Post reply on HN