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

61–70 of 125 posts

Re: Another go at the Next Big Language

#61

Post by m00natic »

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…

Thanks for the link!

Re: Another go at the Next Big Language

#62

Post by Swizec »

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.

Re: Another go at the Next Big Language

#64

Post by kombine »

"Two years later however, D was still stuck in 2007. This was in part due to the infighting between the standard library camps who had failed to learn from the mistakes of the Java class library and were busily adding bloat and verbosity to Phobos and Mango."

This was never a case for Phobos. D still lacks a lot, but Phobos is a pretty lean library. It's built around the concepts that were introduced by Alexander Stepanov and STL and refined them to the great extent. Go on contrary has no support for generic programming, therefore I can only imagine how full of ad-hoc algorithms the typical Go code is. So yes, for me it's definitely not the NBL but just a niche language. D still has a lot of issues, but as a language it's better than Go.

Re: Another go at the Next Big Language

#65

Post by eckyptang »

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…

Perhaps I simplified a bit too much. I agree with you entirely.

The browser provies an API and canvas on which you can build a user interface much as X provides it to Linux, GDI/WPF does for Windows and Quarts of OS-X. It's a medium, not the solution.

I also agree about a lot of sites on the internet being a bloody UX mess.

Re: Another go at the Next Big Language

#66

Post by kristianp »

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

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

Re: Another go at the Next Big Language

#67

Post by dbaupp »

technolem wrote: post #34
6ren wrote: post #30

Earlier quoted context omitted.

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…

Don't most browser history systems support this on their own?

I think this allows one to do a full-text search, essentially. I.e. search for content on the page, rather than just URL/title.

Re: Another go at the Next Big Language

#68

Post by pshc »

The NBL requires a Next Generation Editor. We can't escape from this local maxima of code expressiveness, readability, amenability to change, richness of types, etc. without a truly better programming environment.

Working on it...

Re: Another go at the Next Big Language

#69

Post by tensor »

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…

Go was created in part by Ken Thomson, and supported by Google Inc. In other words, completely the opposite of what you are talking about.

Further, anyone who uses the "ivory tower" identifies themselves immediately as someone incredibly biased and political. There are politics in science to be sure, but overall it's frowned on.

Understand first principles. Understand your needs and the needs of others. Build something based on that. If you continually follow what is popular you will continue to be below average. By definition, popular is average.

Re: Another go at the Next Big Language

#70

Post by Peaker »

tikhonj wrote: post #25
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 always liked the Haskell approach of using a monad like Maybe or Either. Maybe is a special case where rather than having an error you have a null--perfect for functions like indexOf--but since it is isomorphic to Either (), all my points apply to both. The most important point is that in Haskell these errors are reified as first-class types. So the type `Either err val` is just like Go's method of returning eit…

Nitpick:

   EitherT err Logic a
   LogicT (Either err) a
(The monad transformer takes the monad and the value type, not the monad applied to the value type)
Post reply on HN