Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hurl, a terrible (but cute) idea for a language

ntietz.com

Post reply on HN
Print view View original

31–40 of 84 posts

Re: Hurl, a terrible (but cute) idea for a language

#32

Post by smt88 »

duped wrote: post #23

While cute this is really close to call/cc and/or algebraic effects as an abstraction for control flow, which isn't as much "cute" as it is "a powerful way to express programs in as few expressions as possible"

> express programs in as few expressions as possible

I don't find this appealing on its face. Extreme terseness, even when done very elegantly, makes programs very hard to read and sometimes also hard to maintain.

I suspect that's one of the reasons Lisps (and functional languages in general) haven't caught up in popularity even as it becomes much easier to adopt one for any target and in any organization.

Re: Hurl, a terrible (but cute) idea for a language

#33

Post by alexisread »

Exceptions as the underpinning of such a lang is interesting, but I think you might be better off with push-prompt, and an implementation of delimited dynamic binding to allow eg. Process migration.

Wat is a very small language which does fexprs (vau calculus), delimited continuations, delimited dynamic binding, custom algebraic effects (try catch, fibres) on top of them, modules, types, and has a metacircular VM in a few hundred LOC. It's missing a native implementation but it's very impressive.

https://github.com/GiacomoCau/wat-js

Links to the formal research are in the readme.

http://axisofeval.blogspot.com/?m=1 Has several good discussions on the topics, and are more accessible than the papers.

Re: Hurl, a terrible (but cute) idea for a language

#34

Post by duped »

smt88 wrote: post #32
duped wrote: post #23

While cute this is really close to call/cc and/or algebraic effects as an abstraction for control flow, which isn't as much "cute" as it is "a powerful way to express programs in as few expressions as possible"

> express programs in as few expressions as possible I don't find this appealing on its face. Extreme terseness, even when done very elegantly, makes programs very hard to read and sometimes also hard to maintain. I suspect that's one of the reasons Lisps (and functional languages in general) haven't caught up in popularity even as it becomes much easier to adopt one for any target and in any organization.

> Extreme terseness, even when done very elegantly, makes programs very hard to read and sometimes also hard to maintain.

The advantage to something like call/cc is not that you can make code extremely terse but rather that there is one code path for analyzing control flow and each variant of control flow isn't a special case. It's also not more terse at all, but rather more explicit.

You don't need to force users to use it, but it is useful to define more useful mechanisms like if/else if, match/switch, throw/catch/finally, coroutines, etc in terms of an abstraction that doesn't break type checking or codegeneration.

All that said "call/cc considered harmful" is an old take

Re: Hurl, a terrible (but cute) idea for a language

#35

Post by alexisread »

firstlink wrote: post #20
ntietz wrote: post #11

Earlier quoted context omitted.

Hmm interesting, if anyone can help me track down why I would greatly appreciate it!

I trust you already obtained the proper licenses from your local authorities before designing and implementing a new programming language? And those licenses are on file with the major security vendors?

I did find the licences in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.

Re: Hurl, a terrible (but cute) idea for a language

#39

Post by compscigirl »

btown wrote: post #28
duped wrote: post #23

While cute this is really close to call/cc and/or algebraic effects as an abstraction for control flow, which isn't as much "cute" as it is "a powerful way to express programs in as few expressions as possible"

Yep! Everyone should read https://overreacted.io/algebraic-effects-for-the-rest-of-us/ for how powerful this can be in practice. The caller gets to pause execution on the raising/hurling of an event - which makes many crazy things possible.

I feel like I must be missing something. It seems to me (just from reading this post) that if you need algebraic effects you’ve probably painted yourself into a corner and should probably reconsider your program’s architecture. It seems like a good way obscure what the code is really doing and end up with poorly organised spaghetti code. In the post he’s effectively making a function async while pretending it’s not, or calling a callback but making the top level code’s problem instead of encapsulating in the associated type. I’m sure there’s uses for algebraic effects down the line I haven’t thought of, but I don’t understand why these would be desired outcomes?
Post reply on HN