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

31–40 of 125 posts

Re: Another go at the Next Big Language

#31

Post by tikhonj »

tkahn6 wrote: post #28
tikhonj wrote: post #25

Earlier quoted context omitted.

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…

Good writeup. Haskell actually does have an Error type class and ErrorT monad transformer for more fine-grained error handling. Maybe gives you binary error handling, it either fails (Nothing) or succeeds (Just). Either gives you "stringly-typed" errors which is sometimes a good choice. http://hackage.haskell.org/packages/archive/mtl/1.1.0.2/doc/...

ErrorT is similar to EitherT, so I just used the latter to make the names less confusing.

Either doesn't have to be "stringly typed" per se thanks to sum types. You can write a type like:

    data ErrorType = SomeError
                   | OtherError String
                   | ...
The compiler can now check that you handle all possible errors and will give you a warning if you don't, so it's strictly better than using strings.

Coincidentally, this is one place where some sort of sub-typing would be nice, I think. This sort of type would be perfect using OCaml's polymorphic variants because then you could share different error cases around while specifying a very specific type for each computation.

Re: Another go at the Next Big Language

#32

Post by andrewflnr »

PuerkitoBio wrote: post #15

I believe Go is actually BSD-Licensed, not MIT. Though from what I understand these are very similar (permissive) licenses.

They're almost interchangeable. If I wasn't reading carefully I probably wouldn't notice the difference.

http://opensource.org/licenses/MIT http://opensource.org/licenses/BSD-2-Clause

Re: Another go at the Next Big Language

#33

Post by kzahel »

logn wrote: post #19

I have to agree with the commenters on that article that JavaScript is the next big language. With HTML5 it's pretty amazing what you can do with JS. It's reached the point of being nearly as powerful as any thick client technology yet with ubiquitous browser and OS support. It performs fairly well too: http://shootout.alioth.debian.org/u32/javascript.php . I'm not sure why one test is 100x slower, but the rest are <…

The lack of generators in javascript really kills it for me.

Re: Another go at the Next Big Language

#34

Post by technolem »

6ren wrote: post #30
krichman wrote: post #26

Earlier quoted context omitted.

I read this article last week, lost it, and was looking for it yesterday. You just saved me a long hour of guessing at terminology. This seems like a large step in the right direction for exception handling, but I think it still has the problems that the programmer writing the function that can throw needs to enumerate a number of cases to make it effective, and the programmer calling that function needs to have docu…

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?

Re: Another go at the Next Big Language

#35

Post by qxcv »

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…

You should really read Steve Yegge's original blog post[0] before reading this submission.

[0]: http://steve-yegge.blogspot.com.au/2007/02/next-big-language...

Re: Another go at the Next Big Language

#37

Post by rdtsc »

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

The Erlang process model seems like the closest thing to a panacea here. It forces you to write robust software automatically. I haven't used that approach enough to know if it gets you the whole way to shipped, though. (Note: Not specifically advocating Erlang The Language, just its approach to isolation and error recovery)

> Note: Not specifically advocating Erlang The Language,

Why not. If you have a panacea for robust error handling (they call it fault tolerance) coupled with auto-magic cross-CPU and (with some work) cross-machine scaling why not advocate the language.

Anyone else will just be re-implementing that in an incomplete way. So you can have say an OS process like an Erlang process. That's one way. But now need to implement a supervision hierarchy. Ok so talking about SIGCHILD, pids and what signal to use to kill the process (SIGTERM or SIGKILL). Then of course these processes have to talk to each other so must pick a distributed messaging system. Then need to pick a restart strategy (ok so the process failed but we restarted it but it keeps failing and we keep restarting so perhaps that in an of itself is a failure and a higher process in the chain should be restarted...). Stuff like that. By the time that's done and looking back at the code you'd wonder, why didn't I just used Erlang with all this built it...

Re: Another go at the Next Big Language

#38

Post by eckyptang »

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

You don't want a language to force error handling on you. Error handling is different in every case. Go only tries to force you to deal with errors instead of allowing you to ignore them until an exception is thrown. There is never going to be an all-purpose error handling answer. Its just a matter of deciding where your error handling code is placed.

This is the most sensible comment I've ever seen on error handling and one I agree with entirely.

When designing the architecture for an application, error handling is actually the first thing I look at. It's different depending on where it is, who needs to handle it and the context it applies in (technical or business domain). There is no "one size fits all" solution.

Re: Another go at the Next Big Language

#39

Post by fauigerzigerk »

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

Lisp had a condition system that was very clever. You still had to write the code, but you were able to separate the problem, the handling, and the restart. This is the problem that comes up in many languages and which needs to be dealt with: "Because each function is a black box, function boundaries are an excellent place to deal with errors. Each function--low, for example--has a job to do. Its direct caller--mediu…

A less flexible and less elegant way to avoid stack unwind in other languages would be to have a parameter that tells the invoked function what to do if an error occurs:

  def parse_log_entry(text, err_fn):
    entry = parse(text)
    if entry is None:
      entry = err_fn(text)
    return entry
Instead of passing a function, err_fn could also be some kind of resolver that finds a function for a condition name, or there could be a global recovery function:

  def parse_log_entry(text):
    entry = parse(text)
    if entry is None:
      entry = recover('invalid_log_entry', text)
    return entry

Re: Another go at the Next Big Language

#40

Post by zaptheimpaler »

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…

Great idea, I completely agree. Error-handling code is pretty much impossible to eliminate since often the compiler can't possibly know what you want to do when theres a certain error. I think the solution is to use a RoR kind of philosophy, "convention over configuration". Not exactly that, but basically sane defaults. Maybe this would get better if/when compilers get extremely intelligent.
Post reply on HN