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

Hazel: A live functional programming environment featuring typed holes

hazel.org

Post reply on HN
Print view View original

81–88 of 88 posts

Re: Hazel: A live functional programming environment featuring typed holes

#81

Post by conartist6 »

disconcision wrote: post #68
conartist6 wrote: post #50

Earlier quoted context omitted.

Nice to make your acquaintance! I've spent the last four years working on similar tech, though I'm not affiliated with any school or company. I've gone over to the Hazel implementation many times for inspiration and just to check in on the progress. Here are some of the biggest questions I have: Do you have any plans to bring editor gaps to languages other than Hazel? Why is the Hazel editor first a text editor? E.g.…

good questions! both will be addressed soon with david moon's new tylr version (tylr being the underlying syntactic engine for hazel). the new tylr is designed to take a grammar as a parameter; we have a javascript grammar and a partial rust grammar, and are planning editor integrations. the new model also eschews the backpack (the yellow thing that contains matching delimiters) in lieu of inserting missing delimiter…

The homepage assures me that Hazel's mission is to take semantic editing and ensure that the core of the experience is text editing in the most literal sense, for example by allowing you to make selections that cross-cut the tree. I just don't understand why!!! Both the current UX and the proposed UX are less useful and less semantic than the editing tools I already use.

For example in VSCode if I type ( the editor inserts () -- it's actually not a text edit in the sense that the code I produced doesn't map 1:1 to the keys I pressed. No, what actually happened there was already a semantic edit. It was quick and efficient. One keypress. Having a busted document is a worse experience than that, and having a document which is in a sort-of-busted-ghost-mode is also a worse, less semantic experience than I already have. Why would I want either of those experiences for myself or others?

Re: Hazel: A live functional programming environment featuring typed holes

#82

Post by yencabulator »

School-Cotton wrote: post #61
TwentyPosts wrote: post #58

Earlier quoted context omitted.

All of this could've been prevented if Go just had two ways to compile. Debug and release. The go devs decided against this since they didn't want to build a highly optimizing (read: slow) compiler, but that is missing the point of developer ergonomics.

It could be prevented in an even simpler way: emitting warnings. Most people nowadays ban building with warnings in CI and allow them during local development. But “CI” was barely a thing when go was developed so they just banned them completely. And now they are probably too stubborn to change.

The Go decision was explicitly to not have warnings, and the unused identifier thing complained about is merely a consequence of that.

https://go.dev/doc/faq#unused_variables_and_imports

Re: Hazel: A live functional programming environment featuring typed holes

#83

Post by disconcision »

conartist6 wrote: post #81
disconcision wrote: post #68

Earlier quoted context omitted.

good questions! both will be addressed soon with david moon's new tylr version (tylr being the underlying syntactic engine for hazel). the new tylr is designed to take a grammar as a parameter; we have a javascript grammar and a partial rust grammar, and are planning editor integrations. the new model also eschews the backpack (the yellow thing that contains matching delimiters) in lieu of inserting missing delimiter…

The homepage assures me that Hazel's mission is to take semantic editing and ensure that the core of the experience is text editing in the most literal sense, for example by allowing you to make selections that cross-cut the tree. I just don't understand why!!! Both the current UX and the proposed UX are less useful and less semantic than the editing tools I already use. For example in VSCode if I type ( the editor i…

re: the first: this is in contrast to traditional structured editors which actively prevent you from doing edits that break the tree structure, even if the next edit would immediately restore them. users tend to do these often when refactoring; we looked at some examples versus a trad structured editor (MPS) here: https://hazel.org/papers/teen-tylr-vlhcc2023.pdf

in general though i have mixed feeling about making structured editing more text-like; the above is just about trying to patch a hole in existing structured editors, which doesn't in-itself improve on text. i think we can do better than that; we're exploring more radical directions in a separate project. but i do think it is interesting to see how close to regular text entry we can stay while always maintaining a well-formed (though incomplete) parse state which we can use to constantly run type-checking and evaluation.

the current model partially succeeds in the above, but at some significant usability cost, including the fact the the backpack obscures what the actual underlying parse state is. the ghost model i'm describing can basically be thought of a generalization of the vscode parentheses insertion you describe; it just works for every multi-delimiter form (eg when you insert 'let' you get ghosts '=' and 'in', with appropriate holes inserted). the utility is (A) the same as an incremental parser in a language server (you get semantic feedback in every state), but because of the ghost/hole insertions it's crystal clear what the parse state is that you're getting feedback from. but yeah the current version doesn't live up to that standard

Re: Hazel: A live functional programming environment featuring typed holes

#84

Post by conartist6 »

disconcision wrote: post #83
conartist6 wrote: post #81

Earlier quoted context omitted.

The homepage assures me that Hazel's mission is to take semantic editing and ensure that the core of the experience is text editing in the most literal sense, for example by allowing you to make selections that cross-cut the tree. I just don't understand why!!! Both the current UX and the proposed UX are less useful and less semantic than the editing tools I already use. For example in VSCode if I type ( the editor i…

re: the first: this is in contrast to traditional structured editors which actively prevent you from doing edits that break the tree structure, even if the next edit would immediately restore them. users tend to do these often when refactoring; we looked at some examples versus a trad structured editor (MPS) here: https://hazel.org/papers/teen-tylr-vlhcc2023.pdf in general though i have mixed feeling about making str…

If you have holes, I would think you should generally be able to make arbitrary structural edits without ever passing through any outright invalid states, not unlike taking Lego bricks apart and reassembling them in a different configuration.

Recovering from bad parses is the state of the art in the industry right now, but it suffers from the "garbage in garbage out" problem because the user's intent is lost. In point of fact it is never captured in the first place! When you say that typing `let` ghosts out should all that other stuff, that's based on pure assumption. The state of the editor would look just the same if the user was part way through typing out the word `letter` which they intended to use as an identifier. No technology in the world can make things right after the user's intent has been lost.

The real way forward, the direction nobody is looking, is how to make tools that are more like musical instruments. An instrument doesn't guess at your intention and then aim to please you, but rather it amplifies the importance of each decision and impulse that go into playing it, making the player more expressive then they could have been otherwise.

Re: Hazel: A live functional programming environment featuring typed holes

#85

Post by dleary »

yencabulator wrote: post #82
School-Cotton wrote: post #61

Earlier quoted context omitted.

It could be prevented in an even simpler way: emitting warnings. Most people nowadays ban building with warnings in CI and allow them during local development. But “CI” was barely a thing when go was developed so they just banned them completely. And now they are probably too stubborn to change.

The Go decision was explicitly to not have warnings, and the unused identifier thing complained about is merely a consequence of that. https://go.dev/doc/faq#unused_variables_and_imports

As an outsider to Go, it feels to me like this basic pattern comes up over and over again in Go:

Q. Why can’t I have feature X?

A. We thought of that already, and your opinion is wrong.

Q. But basically every other language in existence supports this. And it makes development easier. We would really, really like it. Please?

A. Apparently you don’t get it. Here’s a pointer to a 15 year-old post on a mailing list where the first time someone asked for this, we said no. Your opinion is wrong.

Re: Hazel: A live functional programming environment featuring typed holes

#86

Post by School-Cotton »

Joker_vD wrote: post #79
School-Cotton wrote: post #63

Earlier quoted context omitted.

The good news is if you use Nix or Guix it’s relatively easy to hack your local build of the compiler to demote the unused variables hard error to just a warning.

Well, it's about as easy without neither Nix not Guix.

It's really not. Yes it's possible to figure out how to build and install the Go compiler, but then you have to repeat that process every time you want to upgrade to a new version. With Guix (I assume Nix is similar) you just save the patch somewhere and then run `guix install --with-patches=go=/path/to/patch go` and everything just works (including reapplying the patch on upgrade).

Re: Hazel: A live functional programming environment featuring typed holes

#87

Post by School-Cotton »

yencabulator wrote: post #82
School-Cotton wrote: post #61

Earlier quoted context omitted.

It could be prevented in an even simpler way: emitting warnings. Most people nowadays ban building with warnings in CI and allow them during local development. But “CI” was barely a thing when go was developed so they just banned them completely. And now they are probably too stubborn to change.

The Go decision was explicitly to not have warnings, and the unused identifier thing complained about is merely a consequence of that. https://go.dev/doc/faq#unused_variables_and_imports

> And now they are probably too stubborn to change.

Sounds like we agree!

Re: Hazel: A live functional programming environment featuring typed holes

#88

Post by politician »

Joker_vD wrote: post #80
politician wrote: post #70

Earlier quoted context omitted.

This example isn't particularly good code. If you've got "lots of code" that names a bunch of variables (e.g. using ':=') that are never referenced AND you have a good reason not to do so (which I doubt: given this context it looks like an incomplete test), then predeclare these 'excess' variables: func TestWhatever(t *testing.T) { var resp3, resp4, fooBefore, subFoo, bar2, barNew, zap2 theirType // ...lots of code }…

This is not a piece of code I would commit, obviously! It's a piece of code in the middle of being written and re-written (and re-run, a la REPL), and constantly replacing "resp2" with "_" and back again with "resp2" is friction. Go doesn't have REPL but having a TestWhatever(t *testing.T) function is a mostly good enough replacement, except for this one small problem.

Whew, that's a relief! If I understand correctly, then I think you'll have a better experience if you practice doing something like this when writing tests:

  foo, fooErr := doit()
  require.NotNil(foo)
  require.NoError(fooErr)
  _, _ = foo, fooErr // alternative if you don't want the asserts for some reason, remember to come back later and delete though

  // ...repl churn code...
Using the stretchr/testify/require package. This code defines both variables, gives the error a unique name in the scope, and then references the names in two asserts. You won't have to deal with unreferenced name errors in the "repl churn", so you can comment/uncomment code as you go.
Post reply on HN