3 ms·

A lot of languages have been accused of "ignoring decades of PL research", an almost word-for-word criticism I've heard of a dozen languages or more. In fact, H

A lot of languages have been accused of "ignoring decades of PL research", an almost word-for-word criticism I've heard of a dozen languages or more. In fact, Hare includes a lot of innovations from newer PL research, but indeed not all of them, because different designers can approach a problem with different values and opinions. It's a deliberate design choice, not ignorance.

duped 4y ago
I can respect intentional and principled design choices, but some of the comments you've made on things like garbage collection, borrow checking, generic programming, compiler optimizations, etc don't come off as such. It would be interesting to read some of the modern design choices that Hare is making, for me most of what I understand about Hare are the things you've chosen not to do. Which is interesting, but not necessarily the most compelling all the time. I also think two of the principles you laid out - ease of implementation and transparency/explicitness of code are the hottest takes in Hare. I can see why people like or dislike those choices, and it's compelling to think about, but I'm not sure that the explicit choices to add or not add features from PL research reflect those. For example the paragraph on GC - I think there's a ton of reasons not to use a garbage collector in a language like Hare (for example, you have to write a GC in some language and not the one that is GC'd) but I'm not sure the reasoning you laid out is among them (concurrent and hard-realtime GCs are thing, whether removing the burden of manual memory management is more/less transparent to the intent of a programmer is very debatable).
- ddevault 4y ago
  I did not want to fill up an entire article about the garbage collector problem, but rather just wanted to use it as a brief example to illustrate the thinking around trade-offs when it comes to features like it. It might make sense to write a separate article talking about why Hare takes a conservative approach to language design, but this was not the article for that topic. > for example, you have to write a GC in some language and not the one that is GC'd This is not true.

duped 4y ago

I can respect intentional and principled design choices, but some of the comments you've made on things like garbage collection, borrow checking, generic programming, compiler optimizations, etc don't come off as such. It would be interesting to read some of the modern design choices that Hare is making, for me most of what I understand about Hare are the things you've chosen not to do. Which is interesting, but not necessarily the most compelling all the time. I also think two of the principles you laid out - ease of implementation and transparency/explicitness of code are the hottest takes in Hare. I can see why people like or dislike those choices, and it's compelling to think about, but I'm not sure that the explicit choices to add or not add features from PL research reflect those. For example the paragraph on GC - I think there's a ton of reasons not to use a garbage collector in a language like Hare (for example, you have to write a GC in some language and not the one that is GC'd) but I'm not sure the reasoning you laid out is among them (concurrent and hard-realtime GCs are thing, whether removing the burden of manual memory management is more/less transparent to the intent of a programmer is very debatable).

ddevault 4y ago
I did not want to fill up an entire article about the garbage collector problem, but rather just wanted to use it as a brief example to illustrate the thinking around trade-offs when it comes to features like it. It might make sense to write a separate article talking about why Hare takes a conservative approach to language design, but this was not the article for that topic. > for example, you have to write a GC in some language and not the one that is GC'd This is not true.