Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clean Coder: The Dark Path (2017)

blog.cleancoder.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Clean Coder: The Dark Path (2017)

#31

Post by hmry »

moring wrote: post #29
hmry wrote: post #25

Earlier quoted context omitted.

Not OP, and not sure about OCaml and Haskell, but one example where Java's type system is unhelpful/incorrect is mutable subtyping. E.g. Java assumes Cat[] is a subtype of Animal[]. But this only holds when reading from the array. The correct behavior would be: - `readonly Cat[]` is a subtype of `Animal[]` - `writeonly Cat[]` is a supertype of `Animal[]` - `readwrite Cat[]` has no relationship with `Animal[]` But Jav…

Did you mean arrays instead of lists? Arrays behave as you describe (with ArrayStoreException when you write a wrong value to an array). List is invariant WRT its type parameter.

Yeah, sorry, you're right. I have edited my comment. Thanks for the correction!

Re: Clean Coder: The Dark Path (2017)

#32

Post by repelsteeltje »

hmry wrote: post #25
direwolf20 wrote: post #18

Earlier quoted context omitted.

Explain how

Not OP, and not sure about OCaml and Haskell, but one example where Java's type system is unhelpful/incorrect is mutable subtyping. E.g. Java assumes Cat[] is a subtype of Animal[]. But this only holds when reading from the array. The correct behavior would be: - `readonly Cat[]` is a subtype of `Animal[]` - `writeonly Cat[]` is a supertype of `Animal[]` - `readwrite Cat[]` has no relationship with `Animal[]` But Jav…

Another issue is that Java's initial containers were type-less and were then type generics were retro fitted as erasures.

Re: Clean Coder: The Dark Path (2017)

#33

Post by Surac »

for me there is a clear problem in all those languages. The exception paradigma opens a second way to exit a function. This is clearly a burden for every programmer. it is also a burden for the machine. you have to have RTTI, Inconvinient stack undwindings and perhaps gerneric types. Also nullable types are a but of a letdown. first we specify a "reference" kind type to neverhave to deal with null violations, then we allow NULL to express a empty state. Better have Result return types that carry a clear message: Result and Value. Also have real Reference type with empty and value. by accessing a empty value you get back the default value. i think c# has mastered that realy nice, but far from perfect

Re: Clean Coder: The Dark Path (2017)

#34

Post by forkerenok »

direwolf20 wrote: post #22
virtualized wrote: post #16

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."

[flagged]

Re: Clean Coder: The Dark Path (2017)

#35

Post by seanwilson »

> 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 with a “T”. Yeah. You got it. TEST!

> You test that your system does not emit unexpected nulls. You test that your system handles nulls at it’s inputs.

Am I reading or quoting this wrong?

Just some pros of static type checking: you can't forget to handle the null cases (how can you confirm your tests didn't forget some permutation of null variables somewhere?), it's 100% exhaustive for all edge cases and code paths across the whole project, it handholds you while refactoring (changing a field from being non-null to null later in a complex project is going to be a nightmare relying on just tests especially if you don't know the code well), it's faster than waiting for a test suite to run, it pinpoints to the line where the problem is (vs having to step through a failed test), and it provides clear, concise, and accurate documentation (instead of burying this info across test files).

And the more realistic comparison is most programmers aren't going to be writing lots of unhappy path tests for null edge cases any way so you'll be debugging via runtime errors if you're lucky.

Static typing here is so clearly better and less risky to me that I think expecting tests instead is...irresponsible? I try to be charitable but I can't take it seriously anymore if I'm honest.

Re: Clean Coder: The Dark Path (2017)

#36

Post by raverbashing »

torben-friis wrote: post #3

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…

C programmers non-ironically believe this

And of course they only believe this because they don't lose a finger when they write outside of bounds or they don't fall down the shaft once a pointer was accidentally null

Re: Clean Coder: The Dark Path (2017)

#37

Post by mrkeen »

direwolf20 wrote: post #18
theCodeStig wrote: post #17

Earlier quoted context omitted.

There are many, but one particular example is the type syatem.

Explain how

I can't make a Mappable interface, and have my classes implement map(f). Because map(f) will necessarily return Mappable, not my class itself. So no method chaining for me.

Also null. Yeah I know it's contentious. People don't want to let go of it. Since learning to hate null, I've also lost any nuance in my ability to explain why it's bad. Because I know longer see it as 'subtly-bad' or 'might lead to bugs'. It's just plain, on-the-surface-wrong. One might as well have named it 'wrong' rather than 'null'.

'Null' is the thing which it isn't. I can write business logic that says every Person has a Name. Once you admit null into the mix, I can no longer make that simplest of statements. My autocomplete now lies to me, because person may or may not implement the method .name().

"But how will I half-arse instantiate a Person? I don't have a Name, yet I want to tell the computer I have a Person?" It makes me happy that you can't.

"I wrote a function that promises to return a Person. I was unable to return a Person. How can I tell the computer I'm returning a Person even though I'm not?" Glad that you can't.

Re: Clean Coder: The Dark Path (2017)

#38

Post by checkmatez »

torben-friis wrote: post #3

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.

Re: Clean Coder: The Dark Path (2017)

#39

Post by SebastianKra »

seanwilson wrote: post #35

> 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…

The idea that tests can replace a type system (and vice versa) is a known fallacy.

Discussed here, two years before this article was written: https://www.destroyallsoftware.com/talks/ideology

Re: Clean Coder: The Dark Path (2017)

#40

Post by mrkeen »

Surac wrote: post #33

for me there is a clear problem in all those languages. The exception paradigma opens a second way to exit a function. This is clearly a burden for every programmer. it is also a burden for the machine. you have to have RTTI, Inconvinient stack undwindings and perhaps gerneric types. Also nullable types are a but of a letdown. first we specify a "reference" kind type to neverhave to deal with null violations, then we…

I was recently switched from Java to C# at work.

Initially I was impressed by the null detection. Then I found out about defaults. Way worse than null.

C and Go can demand a bit of ceremony with manual error checks. Things get bad if you forget to do the checks.

Java and Checked exceptions forced error-checking, which is a little verbose, and most of the time you can't 'handle' (for any meaning other than log) them, so you just rethrow.

C# went with unchecked exceptions. But with default values, there's no need to throw! Avoid Java's messy NPE encounters by just writing the wrong value to the database.

Post reply on HN