This is semi-related to one of the killer features of Eclipse that never really made it into any large-scale systems: the ability to run incomplete or broken code. The Eclipse Compiler for Java had a special feature that it could generate bytecode for nearly any file, including those that were utterly broken. It would mostly work, and you could incrementally work on unit tests alongside the code being developed.
It was honestly one of the most productive environments I ever worked in, and I'm somewhat sad nobody else has implemented this.
Generally, it's a very pragmatic thing like being able to quickly run something to make sure it's working but some other part of the code is temporarily broken because I'm currently changing things and don't care that that part is currently broken. In IntelliJ I have to stop doing what I'm currently thinking about and go over to that other part of the code and comment out some things or otherwise fix it up (usually in a way that won't be permanent because it's broken for a reason) before I can run the code I'm working on.
In an ideal world, the codebase would be modular and testable and all those good things but I work in a large enterprise dev team and some of the codebase is many (many) years old and it's no longer feasible to refactor it into anything like what would be needed to allow the code to be modularized in such a way that would obviate the necessity to do the above.
I don't think they want to have thing broken in the steady state, but anything that relies on things building for analysis etc.,. Could benefit from this.
I have never heard about this before. What exactly would happen to broken code? For example, would it skip the equivalent of the broken source line, or would it stub out a function altogether or what?
I only used that feature inadvertently a long, long time ago. As I remember, the program would throw a Throwable exception when it would enter code that wasn't translatable. There was some sort of hot reloading, too. So you could try to fix the code and continue.
The really neat thing was that the Ecliose Java compiler is built specifically to support the IDE, so all the the warning and error annotations in the editor come from the actual compiler even while you are typing. There is no separate parser and linter just for the editor. I believe that the ability to translate broken source files on a best effort basis is actually an offshoot from that functionality.
Literally that, it would throw exceptions with the compiler error. And as a sibling comment mentioned and I had forgotten -- it would allow for hotpatching code at runtime as you fixed compiler errors.
You could literally start the skeleton of a webserver and gradually add functionality to it without recompiling and it would mostly "just work". Certain changes would require the app to be restarted.
Typescript has a hole type too implemented in fp-ts and effect-ts.
Super useful for when you don't know what are you missing and get a type signature for it.
It's mostly useful for when you declare some `const foo: (bar: Bar) => Whatever` and in the midst of your implementation you don't know what you're missing.
Requires an advanced level in TS to be used to the max.
we (team hazel) recently used that device in our typescript version of a hazel setup for typed-hole-contextualized code completion as described in https://dl.acm.org/doi/10.1145/3689728
happy to answer hazel questions; ive been working on hazel as cyrus' phd student for the last four years, and am currently working on moldable projectional interfaces for live programming in hazel. here are some of the things ive added to hazel: https://github.com/hazelgrove/hazel/pulls?q=is%3Apr+author%3...
we have ~ another year of basic type system and editor features prior to the 'doing something' phase. there are early-stage feature branches with stuff for web GUI programming & data science applications, but parts are awkward without in-progress basics like implicit polymorphism, a module system, and more sophisticated type inference.
This seems like an attempt to stir up a flame war. Hazel is written in ReasonML and uses OCaml-style syntax, and the Elm influence is in the design of an interactive programming environment based on running the program as you edit it. I think they could have said SLIME/ML and conveyed a similar idea. I strongly doubt the authors have anything against Haskell.
yes. also keen on first class modules (coming soon to Hazel). syntax could have easily been more haskell-like, current team is pretty ecumenical wrt surface syntax, excepting that i have as yet been unable to convert anyone to the gospel of s-expressions.
biggest reason more haskelley syntax didnt/hasnt happen/ed is the current syntax engine does not support significant indentation. hazel concrete syntax isn't stable yet though we're also thinking seriously about semi-colons
This is semi-related to one of the killer features of Eclipse that never really made it into any large-scale systems: the ability to run incomplete or broken code. The Eclipse Compiler for Java had a special feature that it could generate bytecode for nearly any file, including those that were utterly broken. It would mostly work, and you could incrementally work on unit tests alongside the code being developed.
It was honestly one of the most productive environments I ever worked in, and I'm somewhat sad nobody else has implemented this.
Isn’t this possible with any untyped language?
It does sound like a good feature though - very few languages have opt-out type checking. This is much better than opt-in IMO.
I use IntelliJ now and I definitely miss this feature of Eclipse.
Why? What did you miss about it?
I'm asking as I prefer strict compilers that force me to handle all cases.
Generally, it's a very pragmatic thing like being able to quickly run something to make sure it's working but some other part of the code is temporarily broken because I'm currently changing things and don't care that that part is currently broken. In IntelliJ I have to stop doing what I'm currently thinking about and go over to that other part of the code and comment out some things or otherwise fix it up (usually in a way that won't be permanent because it's broken for a reason) before I can run the code I'm working on.
In an ideal world, the codebase would be modular and testable and all those good things but I work in a large enterprise dev team and some of the codebase is many (many) years old and it's no longer feasible to refactor it into anything like what would be needed to allow the code to be modularized in such a way that would obviate the necessity to do the above.
I don't think they want to have thing broken in the steady state, but anything that relies on things building for analysis etc.,. Could benefit from this.
I have never heard about this before. What exactly would happen to broken code? For example, would it skip the equivalent of the broken source line, or would it stub out a function altogether or what?
I only used that feature inadvertently a long, long time ago. As I remember, the program would throw a Throwable exception when it would enter code that wasn't translatable. There was some sort of hot reloading, too. So you could try to fix the code and continue.
The really neat thing was that the Ecliose Java compiler is built specifically to support the IDE, so all the the warning and error annotations in the editor come from the actual compiler even while you are typing. There is no separate parser and linter just for the editor. I believe that the ability to translate broken source files on a best effort basis is actually an offshoot from that functionality.
Literally that, it would throw exceptions with the compiler error. And as a sibling comment mentioned and I had forgotten -- it would allow for hotpatching code at runtime as you fixed compiler errors.
You could literally start the skeleton of a webserver and gradually add functionality to it without recompiling and it would mostly "just work". Certain changes would require the app to be restarted.
CRTL-SHIFT-F9 (IntelliJ) works for me on most Java and Kotlin code in IntelliJ, as long as no method/class signatures are changed.
Haskell has type holes. There are plugins that give you code actions to complete them, split case, etc. I love type holes.
Agda has them too and they're more powerful there: https://agda.readthedocs.io/en/latest/language/lexical-struc...
Typescript has a hole type too implemented in fp-ts and effect-ts.
Super useful for when you don't know what are you missing and get a type signature for it.
It's mostly useful for when you declare some `const foo: (bar: Bar) => Whatever` and in the midst of your implementation you don't know what you're missing.
Requires an advanced level in TS to be used to the max.
https://gcanti.github.io/fp-ts/modules/function.ts.html#hole
https://effect-ts.github.io/effect/effect/Function.ts.html#h...
there's this hacky quick way of partially emulating typed holes sans library too: https://dev.to/gcanti/type-holes-in-typescript-2lck
we (team hazel) recently used that device in our typescript version of a hazel setup for typed-hole-contextualized code completion as described in https://dl.acm.org/doi/10.1145/3689728
I’m struggling to understand the use, do you have a concrete example?
For me Idris has best type holes.
Related. Others?
Hazel: A live functional programming environment featuring typed holes - https://news.ycombinator.com/item?id=24299852 - Aug 2020 (14 comments)
Also:
Tylr: Demo of tile-based editing, a new kind of structure editing - https://news.ycombinator.com/item?id=27926758 - July 2021 (40 comments)
happy to answer hazel questions; ive been working on hazel as cyrus' phd student for the last four years, and am currently working on moldable projectional interfaces for live programming in hazel. here are some of the things ive added to hazel: https://github.com/hazelgrove/hazel/pulls?q=is%3Apr+author%3...
and here's me speaking last week about using typed holes and the hazel language server to help provide code context for LLM code completion: https://www.youtube.com/watch?v=-DYe8Fi78sg&t=12707s
I like the way the code examples work: A live editor with documentation that shows up on the right hand side (click the Play with Hazel) button.
But does it any more than a live editor and type checker? Can you actually create a program that does something?
we have ~ another year of basic type system and editor features prior to the 'doing something' phase. there are early-stage feature branches with stuff for web GUI programming & data science applications, but parts are awkward without in-progress basics like implicit polymorphism, a module system, and more sophisticated type inference.
I always loved hazel, probably a great tool to teach. What has been build with it?
Elm/ML is an interesting choice of mis-mash & a subtle slap in the face of Haskell? (Which on the surface is far more like Elm than ML is).
This seems like an attempt to stir up a flame war. Hazel is written in ReasonML and uses OCaml-style syntax, and the Elm influence is in the design of an interactive programming environment based on running the program as you edit it. I think they could have said SLIME/ML and conveyed a similar idea. I strongly doubt the authors have anything against Haskell.
My reading is:
* Elm because Elm focused on making the language pleasant to use, and Hazel is in the same tradition of combining HCI + PL
* ML because Hazel is a strict / eager language, and people talk of ML family languages, of which Haskell is one.
So I don't think omitting Haskell is meant to be a slap in the face.
I thought the same thing. "Hazel" sounds like a play on words, a "Hazy Haskell"? Or is it because hazels and elms are trees.
I would take that to mean "strict evaluation" and "simple type system"
yes. also keen on first class modules (coming soon to Hazel). syntax could have easily been more haskell-like, current team is pretty ecumenical wrt surface syntax, excepting that i have as yet been unable to convert anyone to the gospel of s-expressions.
biggest reason more haskelley syntax didnt/hasnt happen/ed is the current syntax engine does not support significant indentation. hazel concrete syntax isn't stable yet though we're also thinking seriously about semi-colons