Criticizing Hare language approach for generic data structures
1–10 of 272 posts
Re: Criticizing Hare language approach for generic data structures
#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" applications, which often deal with a ton of data structures. C applications that do so usually have a few "template headers" lying around (indeed, certain operating systems ship with them), though one of the most frequently used data structures in C is of course the intrusive linked list. Which is not a good data structure to use in most cases. Why is it used so much in C? Because it is easiest to implement. Why does that matter? Because C makes implementing generic data structures tedious. Is it a good idea to replicate that model?
qed.
Re: Criticizing Hare language approach for generic data structures
#3That reminds me that I had to reimplement basic hashmaps in C at least three times in my career. What a waste of time.
Re: Criticizing Hare language approach for generic data structures
#4No post body was provided.
Re: Criticizing Hare language approach for generic data structures
#5What's the problem? People will just use libraries. Why does it need to be part of the base language? Seems like that made C++ quite a mess in fact, while NPM-like ecosystems have done well.
Re: Criticizing Hare language approach for generic data structures
#6TreeMap as a fallback for bucket and/or some king of random salt for hashes had to be introduced due to security issues (DoS) - I doubt anybody would remember about such stuff when making own hashmap implementation.
Re: Criticizing Hare language approach for generic data structures
#7What's the problem? People will just use libraries. Why does it need to be part of the base language? Seems like that made C++ quite a mess in fact, while NPM-like ecosystems have done well.
> And the design of the Hare language doesn’t even allow me to provide that as a library. I have to fall down to code generation at best.
Re: Criticizing Hare language approach for generic data structures
#8What's the problem? People will just use libraries. Why does it need to be part of the base language? Seems like that made C++ quite a mess in fact, while NPM-like ecosystems have done well.
The entire post is a reply to [1], which mentions the exact code the OP criticizes. Drew said "Hare doesn’t provide us with a generic hash map, but we were able to build one ourselves in just a few lines of code", but the OP demonstrates that hash map is incorrect.
[1] https://harelang.org/blog/2021-03-26-high-level-data-structu...
Re: Criticizing Hare language approach for generic data structures
#9What's the problem? People will just use libraries. Why does it need to be part of the base language? Seems like that made C++ quite a mess in fact, while NPM-like ecosystems have done well.
The problem is that you can't properly implement data structures for a statically typed language in libraries without some kind of generics. You can try with explicit casting to void* or whatever Hare uses, but that comes at the cost of type safety.
Re: Criticizing Hare language approach for generic data structures
#10The primary reason I prefer working in C++ over C is that, for all of C++'s faults, it ships with a solid collection of containers and algorithms in the standard library. unordered_map may suck compared to other implementations, but it's a vast improvement over linked lists or home-grown hashmaps.
Anyone can write a hash map, in the same way that anyone can write an HTTP server over a weekend. Doesn't mean it will be production quality.
Glibc's obstack doesn't count, it's non-standard and the only type it supports is (of course) void*, which is a bad interface.