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

101–110 of 125 posts

Re: Another go at the Next Big Language

#101

Post by moderation »

pcwalton wrote: post #57
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.

Probability that pcwalton turns up in a Go thread and conversation turns to Rust? 1

Re: Another go at the Next Big Language

#102

Post by rogerbinns »

Chris_Newton wrote: post #18
rogerbinns wrote: post #13

Earlier quoted context omitted.

I agree that zero lines of error handling is the perfect solution. Even getting error handling and testing to be a trivial percent of the actual useful code would be a major improvement. At the moment my testing code is around the same size as the useful code plus error handling, and error handling is around 10% to 50% of the code. I think part of the problem is error reporting is still somewhat shaky. To a certain e…

Using fdr's example of a cat program, it consists of an open, a sequence of read followed by write and a close. I would like to point the language/environment at that and say "test it" with no further effort. OK, so I suppose the next question becomes what “test it” means. Perhaps you want your test system to make some kinds of automatic deductions about the intended behaviour of your code and then to verify that the…

> OK, so I suppose the next question becomes what “test it” means.

It would be something similar to all possible code paths being executed with the program in all possible states. Heck right now I'd settle for even a small subset of this.

> Or maybe you’re thinking of some sort of automatic simulation of possible failure cases when you get to the open/read/write/close operations, serving a similar roles to things like mocks and stubs in unit testing?

That is closest to it. It is already known that open/read/write/close can fail. They are quite difficult to force to fail, so currently you have to write a lot more code to make that happen. And it gets really tedious once you look at all the combinations. eg open has to fail, open has to succeed and then read fails, open succeeds and the 3rd read fails and on and on. This is for a single ~5 line function! And then if my cat() is made available to a library, how to they test for it failing.

I'm quite happy using supervisory programs to detect rule violations. For example valgrind does an excellent job for memory allocation and usage, and I've never used helgrind but assume it works well too.

Re: Another go at the Next Big Language

#103

Post by pcwalton »

moderation wrote: post #101
pcwalton wrote: post #57

Earlier quoted context omitted.

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.

Probability that pcwalton turns up in a Go thread and conversation turns to Rust? 1

I like to reply to Rust comments, for obvious reasons. Rust usually gets brought up around here in Go threads, unfortunately. I try not to do language advocacy -- like I said, Go is a great language, and it's in a different space from Rust and the languages are not competing -- but if I've crossed the line somewhere I apologize.

To avoid derailing, I'll try to refrain from commenting on anything not immediately related to Rust in other languages' threads in the future.

Re: Another go at the Next Big Language

#104

Post by mlvljr »

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…

Intentional Programming was once admitted to be the new lisp, btw.

Re: Another go at the Next Big Language

#105

Post by Chris_Newton »

rogerbinns wrote: post #102
Chris_Newton wrote: post #18

Earlier quoted context omitted.

Using fdr's example of a cat program, it consists of an open, a sequence of read followed by write and a close. I would like to point the language/environment at that and say "test it" with no further effort. OK, so I suppose the next question becomes what “test it” means. Perhaps you want your test system to make some kinds of automatic deductions about the intended behaviour of your code and then to verify that the…

> OK, so I suppose the next question becomes what “test it” means. It would be something similar to all possible code paths being executed with the program in all possible states. Heck right now I'd settle for even a small subset of this. > Or maybe you’re thinking of some sort of automatic simulation of possible failure cases when you get to the open/read/write/close operations, serving a similar roles to things lik…

It is already known that open/read/write/close can fail. They are quite difficult to force to fail, so currently you have to write a lot more code to make that happen. And it gets really tedious once you look at all the combinations. eg open has to fail, open has to succeed and then read fails, open succeeds and the 3rd read fails and on and on.

OK, I’m following you so far.

Assuming that

(a) our language lets us specify the possible failure modes for each function, and

(b) we have a test tool that can systematically simulate various possible combinations of success and failure,

what would you want to do in each test case?

Put another way, when we run our test tool and our magic replacement I/O functions simulate, say, success on the open and first two reads but then failing on the third read, what happens next? What’s the result we’re looking for to determine whether the test passes or fails?

Re: Another go at the Next Big Language

#106

Post by batista »

pcwalton wrote: post #103
moderation wrote: post #101

Earlier quoted context omitted.

Probability that pcwalton turns up in a Go thread and conversation turns to Rust? 1

I like to reply to Rust comments, for obvious reasons. Rust usually gets brought up around here in Go threads, unfortunately. I try not to do language advocacy -- like I said, Go is a great language, and it's in a different space from Rust and the languages are not competing -- but if I've crossed the line somewhere I apologize. To avoid derailing, I'll try to refrain from commenting on anything not immediately relat…

Please don't (refrain).

It's not like ANY and ALL HN conversations don't get derailed in some sub-thread or another.

Plus, it is insightful to here comments from a language designer/implementor in language related threads.

Re: Another go at the Next Big Language

#107

Post by batista »

kristianp wrote: post #66
encoderer wrote: post #7

Earlier quoted context omitted.

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

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.

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

Re: Another go at the Next Big Language

#108

Post by Chris_Newton »

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…

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

Is that really a problem, or do they simply have a different goal to the languages you want to use?

Plenty of language concepts that enter industrial programming were born in academia and went through the mill in so-called academic languages long before they found their way into mainstream tools. Just look at all the ideas from the functional programming world that have become almost universal in recent years.

That doesn’t necessarily mean that the academic languages where these ideas matured are themselves good tools for industrial applications. To be successful in industry, a language needs a lot more going for it: a good set of developer tools and a critical mass of users, for a start. This often creates a chicken-and-egg situation that can sink a new language regardless of its potential or technical merit, particularly if the approach to programming is very different to what most practitioners are used to at the time.

Anyway, I think you’re being rather unfair with the “ivory tower” characterisation. If you look up Simon Peyton-Jones’s comments on “programming language nirvana”, for example, it’s pretty obvious that he understands these issues and the roles of different kinds of language just fine.

Re: Another go at the Next Big Language

#109

Post by burntsushi »

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…

> it'll be something that builds profiling and unit testing and better source control support right into the language, compiler, and tools.

I think Go does an excellent job at this. The go tool comes with an excellent profiler, is version control aware and works with the `testing` package to make unit testing and benchmarking pretty easy.

Re: Another go at the Next Big Language

#110

Post by batista »

fauigerzigerk wrote: post #97
batista wrote: post #74

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

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

I'm not expecting equal bodies of work. Just show something.

Forget the enterprise, big companies and such. How about lone wolf programmers? Where are the Lisp gurus "beating the averages" and producing some killer stuff? 3-4 apps would suffice. For Lisp I can see very few things, statistical noise almost. Heck, even Erlang has Riak.

One way to see it is: "of course Lisp doesn't have a large body of A-list programs written in it, since it has less programmers". This is your reading of the situation.

Another way, though, is:

"there is a reason Lisp doesn't have as much A-list programs written in it, and it's not adoption. The reason goes deeper and it also explains adoption".

One explanation: Lisp was too high level for the machines of past era to run sufficiently. That explains why it didn't caught on in the past. It means that despite being conceptually better, it was a bad language for the problems most people were trying to solve (squeeze the last trace of CPU and memory juice from very constrained hardware).

And now? Now other languages have the most essential of the high level features it used to have, so other factors weight more in using them over Lisp (e.g available programmers, libraries, etc). Which means again that despite being conceptually better, it is a bad language for the things people do now (front end web stuff needs JS, enterprise needs Java/.NET and Oracle/MS support, embedded needs C, web apps need Node/RoR/Django/PHP, etc).

Not a single niche where Lisp is the best option.

Consider eg that: Productivity = LanguageProductivity + EnvironmentProductivity.

And let's take the scientific computing field. Even if Lisp, the language, has 70 productivity points over 50 for Python, the Environment for Python has 80 points (NymPu, Scipy, Sage, etc) over 20 for Lisp.

So, Lisp = 70 + 20, Python = 50 + 80, hence Python wins.

(The numbers are out of my ass, but you can make a similar thought experiment and, people that make it come to similar conclusions when they pick their tools. Even PG if he had to build something today he would have picked RoR, not CL).

Lisp guys tend to argue that Lisp has "language productivity" of 100, but I don't think so. And even it it has it's not 2-10 times the productivity of something like Python the language. Maybe 20-30% better.

In the grande scheme of things, macros don't matter that much.

Post reply on HN