Criticizing Hare language approach for generic data structures

Post by Doxin » Fri, May 06, 2022, 8:34 AM UTC

wheelerof4te wrote: post #231

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…

"Because C makes implementing generic data structures tedious. Is it a good idea to replicate that model?" A lot of so called "modern" languages make a choice for you. Here is a hash map, over there is a class, have a tuple, set, etc. And they all have a specific way to be used. In implementing all that, many languages lose on flexibility while gaining general utility. Hare seems to go in the opposite direction, one…

I think the main thing is that e.g. python allows you to reimplement all of its most basic data structures in python if you so desire. There's no real way to reimplement e.g. an array in C. The result being that python could still be useful if it wouldn't come with a bunch of data structures built-in.

Post by ahmedalsudani » Fri, May 06, 2022, 10:36 AM UTC

veltas wrote: post #182

ahmedalsudani wrote: post #133

Earlier quoted context omitted.

Keep in mind that - those hash maps are optimized for large sets - they work around several edge cases - they implement way more features than an in-house implementation - they need to support many types of hardware A decent engineer can beat the std collections in a day on performance. But to do that in production over a decade with shifting requirements is a different ball game.

The one I cooked up was used to test some kind of game solver, so a 'large set' and it happily beat std::unordered_map, was a tiny bit slower than a Google hash map implementation. But I do believe in edge cases, I'm sure there are some pathological edge cases (that don't usually matter, but deserve consideration). I'm interested to know what 'way more features' are for hash maps/sets, because AFAIK C++ just supports…

"Features" was probably the wrong word for me to use. What I was referring to is interface + customizability.

The STL map allows you to:

- specify the key/value types

- specify the equality predicate

- specify which hash function to use

- iterate over values

along with a host of other things that most users don't initially need but they might need in the future.

You could implement something that has feature parity in C++ or ideally find a battle-tested library that does.

Using C, however, you'd have to sacrifice type safety and possibly readability. Yes it can be done, and yes it can be done correctly. But it's tricky and difficult to ramp up on for the new developer. This is the one that you should be careful about adopting.

My philosophy is to use the STL containers because they're familiar and they're more than good enough for 99% of the use cases out there. Developer time has a premium, and this saves developer time.

If you need performance because you're constrained by CPU cycles or if you're running at scale (Google for example), by all means reach for something better.

Re: Criticizing Hare language approach for generic data structures

Re: Criticizing Hare language approach for generic data structures