Criticizing Hare language approach for generic data structures • Hacker News Board

Re: Criticizing Hare language approach for generic data structures

#211

Post by HelloNurse » Wed, May 04, 2022, 5:09 PM UTC

darthcoder1010 wrote: post #185

HelloNurse wrote: post #161

Earlier quoted context omitted.

A hash table that compares hashes instead of keys, doesn't support deletion, doesn't distribute keys evenly etc. is not even wrong ; criticizing it is definitely not "crap for daring to exist", especially in the polite tone of the linked article. If Hare is intended to be a deliberately Spartan C replacement, so be it; but pretending that writing a hash table is easy looks like the immature and arrogant opinion of so…

> A hash table that compares hashes instead of keys, doesn't support deletion, doesn't distribute keys evenly etc. I agree, that implementation is definitely flawed. Probably the author do not consider that important a proper hashtable. > looks like the immature and arrogant opinion of someone completely unaware of his ignorance. This is what I'm referring to when I say "harsh" criticism. Maybe he is wrong, but I thi…

Everybody can have a bad day and write terrible code, but blogging about it as a positive example and as evidence that a practically useful programming language doesn't need high quality generic data structures suggests a deeper problem at understanding the needs of programming language users.

Wrong questions (focusing on the narrow case of unique, overspecialized application-specific data structures), not only forgivable wrong answers (that hashtable from the Hare compiler, after all, could be close to good enough for its specific usage).

Personally, I think abstract data types based on some kind of macros or templates would be a valuable feature for Hare, even if their use in the standard library is limited, because someone will want to write reusable libraries.

Even within the confines of an application, there is a practical need to deal with different uses of a data structure in the same way and make changes in one place (e.g. "the generic hashtable in our ORM" ) rather than in possibly numerous quasi-duplicates (e.g. 250 different struct to struct hashtables representing database query results in a large business application).

C++ templates, a good example of what could be realistically offered by Hare, allow to upgrade a definition from "do X with one type" to "do X with any suitable type", which is a useful abstraction even without reuse (what's actually expected or not of the type parameters becomes explicit), a technique to write general libraries "for free" (e.g. you can put whatever you want in our hashtable), a technique to define general language foundations (e.g. you can have smart pointers to anything).

Re: Criticizing Hare language approach for generic data structures

#212

Post by netr0ute » Wed, May 04, 2022, 5:27 PM UTC

tonyg wrote: post #180

netr0ute wrote: post #160

Earlier quoted context omitted.

> Such as not wearing a mask, for example. That's pretty rich

How so? I'm sure you take my point: that by indulging selfish wants, we can harm others. Private situations, do what you like; shared or social contexts, not so much.

Masks don't even work for many of the things people want them to work for.

Re: Criticizing Hare language approach for generic data structures

#213

Post by specialist » Wed, May 04, 2022, 5:34 PM UTC

My future perfect "practical" programming language will have type inference, strong typing, and intrinsics for misc data structures. In other words, looks kinda like JavaScript, behaves kinda like Java.

This:

  foo = { "apples" : 100, "bananas" : 20 }
  bar = [ 100, 200, "oops" ] // error

Instead of this:

  foo = new hashmap
  foo.put( "apples", 100 )
  foo.put( "bananas", 20 )
  bar = new array
  bar.add( 100 )
  bar.add( 200 )
  bar.add( "oops" ) // error

I believe, but cannot yet prove, this would eliminate 98% of the (popular) pressure (desire for concision) for adding generics.

Re: Criticizing Hare language approach for generic data structures

#214

Post by tonyg » Wed, May 04, 2022, 5:44 PM UTC

netr0ute wrote: post #212

tonyg wrote: post #180

Earlier quoted context omitted.

How so? I'm sure you take my point: that by indulging selfish wants, we can harm others. Private situations, do what you like; shared or social contexts, not so much.

Masks don't even work for many of the things people want them to work for.

Oh, hey! That makes them an even more perfect analogy. They help, massively, protecting others by removing many forms of transmission; but they don't prevent all transmission. Likewise, memory safety helps, massively, protecting others by removing many forms of security vulnerability; but it doesn't prevent all security vulnerability. And, crucially, not to get too far distracted from the original point: both are things we try to make use of where we can, not for ourselves, but for others and for the health of our overall communities. To really spell it out in words of one syllable: that's why people care about whether other people use memory safe languages.

Re: Criticizing Hare language approach for generic data structures

#215

Post by zozbot234 » Wed, May 04, 2022, 5:51 PM UTC

amelius wrote: post #190

zozbot234 wrote: post #125

Earlier quoted context omitted.

Rust is a functional programming language, that's exactly what's implemented in the basic borrow checking rules. Interior mutability is added to that featureset, so as to support procedural programming with shared mutable state.

You can't do proper functional programming without garbage collected closures. There is a reason why Haskell has a garbage collector ... and it's not "the borrow checker wasn't invented yet".

Haskell uses a garbage collector to enable closures to extend the lifetimes of values they capture within their context. You can do the exact same thing in Rust by using Rc or Arc, it just isn't required in most cases because the borrow checker can verify that the value is not outlived by the closure.

Re: Criticizing Hare language approach for generic data structures

#216

Post by zozbot234 » Wed, May 04, 2022, 5:57 PM UTC

dgb23 wrote: post #187

zozbot234 wrote: post #125

Earlier quoted context omitted.

Rust is a functional programming language, that's exactly what's implemented in the basic borrow checking rules. Interior mutability is added to that featureset, so as to support procedural programming with shared mutable state.

It borrowed some FP concepts, it's influenced by FP but it's definitely not an FP language. It's very much a language about imperative, explicit control. And that's a good thing for the use-cases that Rust targets. It doesn't have in-built immutable data structures, most basic data structures and types are mutable and have mutate in place methods as their primary way of interaction. Struct fields being private by def…

> It doesn't have in-built immutable data structures

Immutable data structures by default would involve avoidable overhead, so that's why they aren't a built in. There are well-known crates that do provide persistent data structures in Rust.

> Struct fields being private by default is a dead giveaway (unnecessary in an FP language).

Data hiding is just as useful in functional programming; in particular, it enables you to expose an interface to data that stays valid under any isomorphism, while preserving desired invariants. Structs with generally accessible and updatable fields are a special case.

Re: Criticizing Hare language approach for generic data structures

#217

Post by samhw » Wed, May 04, 2022, 6:35 PM UTC

HL33tibCe7 wrote: post #146

samhw wrote: post #111

Earlier quoted context omitted.

> for code that’s supposed to be used in production it’s useless Then ... don't use it. Others can use it and see what they learn from it, or even whether they find it productive to build stuff with. Even Brainfuck and Malbolge have devoted users who enjoy the challenges they pose, so I can promise you there's room enough in the world for this language. Let's just have some camomile tea and calm down a little.

Except maybe one day I'll be using some software written in Hare which will mess up and have negative implications for me. Furthermore, it could be argued that our time could be spent more productively than on a language like Hare.

Then don't use that software. If you're right, software made with it will be worse - if even producible - and it won't take off. I'm sorry, but the ship has sailed: it is already possible to create bad software. The Hare language is not opening some hitherto-unopened Pandora's box. The same forces carrying good software to the top, and bad software to the bottom - and with them the tools used to make both the former and the latter - will continue to function.

As for whether our lives could be used better, well, let's leave that to each individual. I heartily encourage you to live your life as I do, worrying about what I myself am spending time on (currently: this inane conversation), rather than whether other people might be spending their own time in some supposedly-slightly-suboptimal manner.

Re: Criticizing Hare language approach for generic data structures

#218

Post by bigbillheck » Wed, May 04, 2022, 6:48 PM UTC

ddevault wrote: post #49

eptcyka wrote: post #32

Earlier quoted context omitted.

> There are three key problems: finding a good way of hashing arbitrary data structures (or arbitrarily limiting the kinds of keys the map can store), finding a good way of determining equality of arbitrary data structures, and dealing with memory allocation semantics. It's not unheard of or unreasonable to have collections that have take an allocator as an argument. And a comparator and a hash function as arguments.…

Aye, we would have probably gone with a design similar to what you suggest... if we had generics, but we do not. Generics simply don't fit with the core values of the language. I still believe that there is room for languages without them.

> I still believe that there is room for languages without them.

In the same sense that there's room for languages without, say, for-loops.

Re: Criticizing Hare language approach for generic data structures

#219

Post by pjmlp » Wed, May 04, 2022, 6:55 PM UTC

one-more-minute wrote: post #41

formerly_proven wrote: post #2

"Bring your own datastructures" is likely one of the C carry-overs for Hare. If you think about many "classic" C applications, a lot of them basically only exist around/for one or a few data structures (e.g. most servers, many utilities etc.). In that context BYODS is somewhat defensible: If you don't care to implement the data structure, why does your application exist in the first place? But that's not "modern" app…

Rust and Go seemed to initially want to target C programmers [1], but ended up capturing users from higher level languages – even Python and such – who wanted better performance and more control, because they had so many affordances. Hare clearly isn't like that: it's _actually_ aimed at (FOSS) C programmers, almost stubbornly so, and isn't going to appeal to many others. But for those people I can see C-with-tagged-…

Mostly because writing compilers, linkers, GC implementations, GPU debuggers, OS emulation layers, distributed orchestration systems, unikernels, isn't considered systems programming by the crowd that is allowed to judge it.

Re: Criticizing Hare language approach for generic data structures

#220

Post by pjmlp » Wed, May 04, 2022, 7:22 PM UTC

mumblemumble wrote: post #81

lawl wrote: post #76

Earlier quoted context omitted.

> But you are correct about go, it doesn’t give the programmer enough control to be used at that level. What I like about go is that I can go full unsafe.Pointer if i want to, and do whatever I want. The other thing I really like, is that they did such a good job discouraging it that i frequently hear people complain about go having pointers but not even letting you have fun with them. The problem isn't that go doesn…

I think that being garbage collected is exactly the control problem in question. I'm no a systems programmer unless you count hobby microcontroller projects, but my understanding is that, when a systems programmer is talking about control, they tend to be talking first and foremost about keeping tight limits on memory usage. Pointers and suchlike just happen to be key tools that help you do that.

One doesn't prevent the other,

https://www.withsecure.com/en/solutions/innovative-security-...