Live data from Hacker News

Criticizing Hare language approach for generic data structures

ayende.com

161–170 of 272 posts

Re: Criticizing Hare language approach for generic data structures

#161

Why do people spend so much energy shooting down a language nobody uses? If you don’t like it you don’t have to use it. I would hate to be the creator of Hare and get so much crap for simply daring to exist. He is making a language he likes and wants to use. There are probably some people who like it and find it useful. Good for them! A lot of us have dreams of building our own language. He is following his passions…

> I would hate to be the creator of Hare and get so much crap for simply daring to exist. Certainly. Since the announce of Hare I've seen __too__ much criticism IMHO. I think the authors have stated clearly the intentions and the features of the language: They just want a slightly better C. Of course you may not like it, but no need to be that harsh...

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 someone completely unaware of his ignorance.

Re: Criticizing Hare language approach for generic data structures

#162

Earlier quoted context omitted.

Not sure what you mean. Rust has no functional programming either ...

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.

I can not agree with Rust being a functional programming language. I don’t think it has NO functional style idioms, but the borrow checking does not make it functional. That would imply that the only characteristic of functional programming is some sort of ‘variable’ mutability constraint. I may not be up to defining functional programming by exclusion, I think any definition of functional programming includes things Rust does not have.

Re: Criticizing Hare language approach for generic data structures

#163

Earlier quoted context omitted.

What's with this obsession about what other people do? You don't have to use a memory unsafe language, but others might.

Because software is generally written so that people use it. Memory unsafe languages have proven it's impossible to write secure software in, even by the best of the best developers. That's why I made the comparison with seatbelts. If you want to drive your car on public roads(deliver production software to users) you are not allowed to use memory unsafe languages(you must use a seatbelt). If you just make software f…

I can assure you, the automotive industry uses more C/C++ than you've ever seen. C is used precisely because it's a mature and verifiable language.

Re: Criticizing Hare language approach for generic data structures

#164
post #141

Earlier quoted context omitted.

I’m allowed to have opinions about what tools should be used for what. I think it’s fair to say you shouldn’t write a production HTTP service in assembly, for example.

The problem with this is that you're now the Ministry Of Truth of programming tools.

You're allowed to disagree with me. I don't claim to be the ultimate authority and I have no power to enforce my opinions. If I were your tech lead and you wanted to use Hare for something I would probably say no but we could have a discussion about it and you might convince me otherwise. But that's not the context here. This is a programming forum, so I will speak my mind.

Re: Criticizing Hare language approach for generic data structures

#165
post #141

Earlier quoted context omitted.

I’m allowed to have opinions about what tools should be used for what. I think it’s fair to say you shouldn’t write a production HTTP service in assembly, for example.

The problem with this is that you're now the Ministry Of Truth of programming tools.

[deleted]

Re: Criticizing Hare language approach for generic data structures

#166

Earlier quoted context omitted.

What's with this obsession about what other people do? You don't have to use a memory unsafe language, but others might.

Because software is generally written so that people use it. Memory unsafe languages have proven it's impossible to write secure software in, even by the best of the best developers. That's why I made the comparison with seatbelts. If you want to drive your car on public roads(deliver production software to users) you are not allowed to use memory unsafe languages(you must use a seatbelt). If you just make software f…

It’s also massively unsafe to drive in general, so we should probably ban the usage of cars wherever possible.

Re: Criticizing Hare language approach for generic data structures

#167
post #17

It’s unfortunate that people are trying to revive a better version of the past, when the world has moved on and the past ultimately really wasn’t that great. C is a terrible language for building things in the modern world. Not including the progress over the last 4 decades in your new language is a mistake.

Agreed, I don't know how writing anything in C today would be considered a productive use of time besides low level / embedded work.

> besides low level / embedded work

And this is where Hare is meant to be used, is it not?

Re: Criticizing Hare language approach for generic data structures

#168
post #128

Earlier quoted context omitted.

> Why do people spend so much energy shooting down a language nobody uses? If you don’t like it you don’t have to use it. Because this language isn't made by a nobody. It's made by a popular person with a following, so the language _will_ get used by a non-insignificant number of people. And those people _will_ (re)implement all the things that you want a language to have (database connections, networking libraries,…

> And those people _will_ (re)implement all the things that you want a language to have (database connections, networking libraries, (de)serialization libraries, etc.). And these things, which can be performance/security-critical, will be impacted by the issues people are pointing out. This language is only available on platforms where you are free to choose whatever software you want. If you think a Hare program is…

What happens when your financial institution or your doctor, whose IT departments run Linux on their servers to handle your personal data, install such insecure software?

Re: Criticizing Hare language approach for generic data structures

#169
post #128

Earlier quoted context omitted.

> Why do people spend so much energy shooting down a language nobody uses? If you don’t like it you don’t have to use it. Because this language isn't made by a nobody. It's made by a popular person with a following, so the language _will_ get used by a non-insignificant number of people. And those people _will_ (re)implement all the things that you want a language to have (database connections, networking libraries,…

> And those people _will_ (re)implement all the things that you want a language to have (database connections, networking libraries, (de)serialization libraries, etc.). And these things, which can be performance/security-critical, will be impacted by the issues people are pointing out. This language is only available on platforms where you are free to choose whatever software you want. If you think a Hare program is…

Usually we like for replies here to reply what the person above wrote.

Re: Criticizing Hare language approach for generic data structures

#170
post #61

Earlier quoted context omitted.

Something like this: struct cmp { hash: *fn(_:*void) u64, eq : *fn(_:*void, _:*void) bool, free: *fn(_:*void) void } With maybe some default options should be enough for at least the basics. Note that the indirection overhead would be significant, but without generics or something similar, you don't really have a choice.

The problem here is *void, which is not great. You lose type safety with this approach, and the allocation problems are still present. Rolling your own can be both more type safe and better suited to your problem area, and it's not particularly difficult.

What about a use case where you want to use a hashmap to store 3 different types of keys independently. Would you implement the hashmap once and just store a union of the 3 types and then assert the correct type has been stored at each call site? Would you implement the hash map 3 different times? What happens if later on, some years later, the code needs to change and another type needs to be stored in a map? Generalizing a map via void pointers is the most pragmatic solution.
Post reply on HN