Imagine if we’d had the opportunity to complain about PHP or JS back in their early days, and had the opportunity to fix some of their awful decisions _before_ they became practically set in stone?
There is a distinct difference between PHP, JS and Hare. Hare is being developed and designed with a particular point of view by a developer and early adopters who are passionately supportive of that POV. PHP and JS were both thrown together with minimal direction and to achieve specific goals in as fast a time as possible (if I am remembering both languages begins correctly). It could be possible that another language in the position of JS and PHP at its inception might be amenable to deep and fundamental changes; however, I do not think Hare fits this scenario.
If Drew and Co want to make Hare the way it is, awesome! If you don’t want to use share and prefer something else, great!
Simply, it is a bad point of view, and deserves discouragement in exact proportion to the amount of promotion it gets. He wants it both ways, and does not deserve that.
What particularly are you objecting to about Devault’s POV? I mean most of this thread and the article are based on the lack of generic data structures or complaints that Hare is not Rust. The complaint about lack of built-in data structures seems to be focused mostly on developer comfort, with a sprinkling of issues concerning possibility of bugs in implementations of specific structures. With regard to the continual comparisons to Rust, ala ‘memory safety’, if any model of software development outside of Rust’s limited paradigm is ‘bad’ then nearly all code in use today is ‘bad’. That seems to be an unsupportable position in the extreme.
I understand some people will not want or value any given piece of software or infrastructure, but the blanket pessimism is not proportional to the alleged detriments proposed by Hare’s mere existence.
Maybe I am just being overly sensitive to what I see as over reaction to someone’s programming language preference, but this is the reason I have never, and probably will never, release the language I made and use day to day to the public.
You cite a list of trivial cavils, which I have no truck with.
Hare's problems are much deeper. They stem directly from Drew's fundamental misunderstanding of the nature of software development. Drew is correct that managing complexity is central to the problem of software development. He is 100% wrong on how a programming language can contribute to solving that central problem.
There has been a great deal of progress, in the past five decades since C burst on the scene, on managing complexity in programming tasks, with programming language design taking a big bite. Hare adopts exactly none of that success, setting users straight back to the 1970s again. That might have been fine if demands on programmers were no greater than in the 1970s (although the bugginess of software coded then argues otherwise), but anyway we do not live in that world anymore. The programs we want to run don't fit in 64K of RAM and run single-threaded with no network connections, anymore. Where a 1970s language is used for programs today, we all suffer from the failings the language almost unavoidably invites into them.
The fundamental insight that Drew has wholly missed is that essential complexity demands more attention to get right than is typically available for one use case. We have learned that pulling complexity into a library component, or (better) a Standard Library component, or failing that a programming language feature, enables attention to be paid to it amortized across all the programs and libraries that depend on it. All the meaningful progress in programming languages since been in finding ways to bring more of what must be expressed into one place so it may be more widely usable, and able to command correspondingly more attention to its performance and correctness. Standard library components in our modern languages successfully remove their complexity from what programmers must manage.
The ways we have discovered to help with this process include powerful type systems that have been put to work doing heavy lifting far beyond mere "type checking". We have generics to work with types the way types work with values. Certain languages provide extra tools such as destructors/Drop traits that enable automating resource management. Many languages assert direct responsibility for pieces of that task, imposing borrow checking or GC. There is much left to do.
Hare provides exactly none of the tools that have been discovered to encapsulate complexity into carefully correct and generally useful components, or to enable using such a component in all the different places and ways it would be useful. This failing is painfully evident in the library components it does attempt.
In the 1970s, Hare might have competed with C and Pascal to express the then newly valued "structured programming". Today it is a toy. Evaluated as a toy, there is nothing wrong with it. But it is not presented as a toy. As a tool for programming in the modern world, it is sorely lacking everywhere that C is sorely lacking, that make C directly responsible for the massive suffering documented in the litany of CVEs, botnets, database exposures, and ransom events.
"Hare provides exactly none of the tools that have been discovered to encapsulate complexity into carefully correct and generally useful components, or to enable using such a component in all the different places and ways it would be useful."
I would be very cautious when calling anything that encapsulates complexity "carefully correct" or "generally useful". Hiding such complexity behind language features is how we ended up with new generations of programmers who have no idea how to code anything themselves.
If generations and generations of stack overflow copy-pasters are the future of programming, then I don't want to be a part of it.
"In the 1970s, Hare might have competed with C and Pascal to express the then newly valued "structured programming". Today it is a toy."
Excuse me? The most useful, the most endured, the most sane and the most understood coding paradigm is a toy to you? You know, some of us really like to think of our programs as many procedures being called one after the other.
That's the most logical way to think about them, because it's the exact way the CPU sees them.
Yes, a toy: inadequate for professional work. You can cut grass with scissors, but nobody who understands the task will hire you to do it.
CPUs do not, in fact, see procedures. They execute machine instructions. Your "procedures", exactly, 'encapsulate complexity behind a language feature'. A rudimentary feature, true, but one identically the same as is found in modern languages, among their more powerful features.
I am, indeed, always cautious about calling things "carefully correct and generally useful". Still, I am aware of many language features and standard library components in modern languages that fully satisfy those criteria.
Who pastes code copied from stack overflow? I assume that was a ham-handed attempt at an insult. You are welcome to continue fooling with toy languages, old and new. Pretending they are adequate tools for serious work says more about you than about them.
"Yes, a toy: inadequate for professional work. You can cut grass with scissors, but nobody who understands the task will hire you to do it."
Can you explain what you mean here? In the context of structured programming.
"CPUs do not, in fact, see procedures. They execute machine instructions. Your "procedures", exactly, 'encapsulate complexity behind a language feature'."
That's right, CPUs execute instructions. Those instructions are executed one after another, with jumps when a certain operation should be repeated or skipped. This is the definition of structured programming. Structured programming is a simple abstraction over how CPUs execute machine instructions.
I don't see any objects with methods there. Nor do I understand how would a CPU understand a lambda function or care if something is immutable or not.
"I assume that was a ham-handed attempt at an insult."
No insult there. It is just a sad reality how many developers rely on Stack overflow instead of using their own head a little.
It is not, in fact, the definition of structured programming.
Structured programming was defined by Edsger Dijkstra, and consisted originally of a model of programming with restrictions on where branches may go. Later programming language constructs if/then/else and while implemented this model. It does not address subroutines.
I describe C and similarly primitive languages as toys because they do not provide the expressive power needed to enable the levels of productivity and reliability demanded of serious work.
I think the critique is more valuable for other readers like the non-Hare users in these comment threads and in particular language designers, than at Hare developers. If it can inform Hare development to make a better language that's great too. If they choose their path ignoring it, that's their prerogative, but at least it was expressed and given a chance for adapting.
