41–50 of 71 posts
> The rules of the language insist that when you use a nullable variable, you must first check that variable for null. So if s is a String? then var l = s.length() won’t compile. ... > The question is: Whose job is it to manage the nulls. The language? Or the programmer? ... > And what is it that programmers are supposed to do to prevent defects? I’ll give you one guess. Here are some hints. It’s a verb. It starts wi…
Earlier quoted context omitted.
There are many, but one particular example is the type syatem.
Explain how
- People talked about null being an issues and that is a big one.
- The entire idea of OOP extremism Java implemented was a mistake - though just a consequence of the time it was born in. Much has been written about this topic by many people.
- Lacking facilities and really design for generic programming (also related to the OOP extremism and null issue
So much more more you can find out with Google or any LLM
Author argues against strong typing systems and language features to prevent classes of bugs and instead encourages developers to "writing lots of tests" for things that a type system would prevent. The authors thesis seems to be that it's preferable to rely on the programmer who wrote bugs to write even more bugs in tests in order to have some benefit over a compiler or type system that can prevent these things from…
I think you you're missing the point though, he did not say that adding those constraints was a bad idea per se, but they are leading to a bad path. If the path is "just add more guard-rails" then we will get to a point where we lose the "soft" part of "software" and you'll find yourself restarting each time you need to change something because at that point the language you chose was already the first wall of a bad…
My UserService doesn't know that it's talking to a UserDB (ironically I learned this from Uncle Bob).
All UserService knows is it has a dependency which, if passed a UserId, will return a User (+/- whatever the failure mode is .. Future? Promise? ReaderT m User?)
When I change my mind about what UserService requires or what UserDB provides (which I frequently do), I immediately look at all the red underlines that my compiler & static types tell me about.
What I read between the lines: “I have such a fragile ego that I feel offended when a tool points out a mistake I made. I feel intellectually rewarded by doing the same busywork over and over again. I don’t want to change the way I do my work at all. I feel left behind when people other than me have great ideas about language design.”
What I read between your lines: "I don't want to think about the code at all. It should only compile if it has no bugs. I don't like rapid prototyping. I feel stupid when people other than me feel they can program effectively with fewer safeguards."
The one that companies have spent billions of dollars fixing, including creating new restrictive languages?
I mean, I get the point of tests, but if your language obviates the need for some tests, it's a win for everyone. And as for the "how much code will I need to change to propagate this null?", the type system will tell you all the places where it might have an impact; once it compiles again, you can be fairly sure that you handled it in every place.
Your elevator should not have automatic doors, doors are restrictive. They stop you from quickly jumping out of the elevator if you decide that you actually want to stay at the first floor. Sure, we’ve seen some pretty gnarly accidents, and there is no reasonable situation where risking death is a sane choice. But ask yourself: is it the elevator's job to prevent an accident? If you think so, I suggest you never leav…
Did you even read the second half of the post? The author's answer to your concerns is testing. He suggests relying on tests rather than on strict type system that forces you to design everything upfront. Personally, I can see arguments for both approaches - stricter types or more tests.
It is a little weird to end an article calling for less safeguards in languages by a reference to a nuclear disaster caused by overriding safeguards.
Your elevator should not have automatic doors, doors are restrictive. They stop you from quickly jumping out of the elevator if you decide that you actually want to stay at the first floor. Sure, we’ve seen some pretty gnarly accidents, and there is no reasonable situation where risking death is a sane choice. But ask yourself: is it the elevator's job to prevent an accident? If you think so, I suggest you never leav…
Did you even read the second half of the post? The author's answer to your concerns is testing. He suggests relying on tests rather than on strict type system that forces you to design everything upfront. Personally, I can see arguments for both approaches - stricter types or more tests.
Types check the operation for many, and can be made for all possible input values.
The difference is:
None of these boxes contain bicycles because:
* With tests: we checked 3 of them and found no bicycles
* With types: all the boxes are too small to contain bicycles.
> And what is it that programmers are supposed to do to prevent defects? ... TEST!
Unfortunately, altering people's behavior by telling/commanding/suggesting that they do so, whether or not supported by perfect reasoning, rarely if ever succeeds.
It's overwhelmingly the case that people, including programmers, do what they do in reaction to the allowances and bounds of a system and so it is far more effective to alter the system than attempt to alter the people.
total yikes for the entire thing. "What if a function needs to return null" or "throw an error" is not a fundamentally different concept than "what if a function needs to return a totally different type".