Live data from Hacker News

Clean Coder: The Dark Path (2017)

blog.cleancoder.com

61–70 of 71 posts

Re: Clean Coder: The Dark Path (2017)

#61
post #40
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,…

Default value is only relevant for structs. You can setup an analyzer rule to ban this for structs which have, say, an empty constructor. It’s a similar problem to Go and C++ except it’s worse in the latter two.

Re: Clean Coder: The Dark Path (2017)

#62
post #53

Earlier quoted context omitted.

And there are countries where everyone rides a bike, and they are not usually the ones with mandatory helmets. When you hit someone with a bike you are less likely to kill them than when you hit them with a car, so more bike riding means less deaths, without even considering the effects of air pollution. Helmets are fine for sport riding, but inconvenient if you want to ride 5 minutes to the shops on a whim. And that…

Those countries also have a higher number of brain injury cases vs countries where people wear helmets. If you are hit by a car a helmet will do approximately nothing. However there are a lot of accidents that happen where you are not hit by a car where a helmet will help. (and even more when knee and elbow pads are what you need)

What if you're hit by a bike instead of a car because someone took the bike instead of the car?

Re: Clean Coder: The Dark Path (2017)

#63
post #37

Earlier quoted context omitted.

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

Avoiding null is one of those things the FA complains about — you'll make your language three times as complicated to avoid it, and that might not be a good trade-off.

Re: Clean Coder: The Dark Path (2017)

#64
post #53

Earlier quoted context omitted.

Those countries also have a higher number of brain injury cases vs countries where people wear helmets. If you are hit by a car a helmet will do approximately nothing. However there are a lot of accidents that happen where you are not hit by a car where a helmet will help. (and even more when knee and elbow pads are what you need)

What if you're hit by a bike instead of a car because someone took the bike instead of the car?

A helmet can make a big difference in saving your brain if you are hit by a bike. Or if you hit a slippery spot and fall off your bike. Or - hundreds of other things that happen.

cars are too big and heavy for a helmet to make a difference - but they are not all that can go wrong. Even in car heavy US there is more than a car that can harm you.

Re: Clean Coder: The Dark Path (2017)

#65
I think that it can sometimes be helpful to have some protective functions, as long as it is not excessive. It should not be mandatory and should not be too difficult to avoid. I program in C, and I do not use most of the warnings since they are excessive (in my opinion), but the warning about implicitly using a integer as a pointer is sensible (and should be an error) since you can easily explicitly override it (with the specific pointer type that you need) if that is really what you meant.

Tests are good regardless of what the programming languages tries to do, since not all bugs can be avoided by the programming language, and not all bugs should be avoided by the programming language. It should let you to write the program, instead of to stop you.

However, there are situations where due to the working of the implementation, there is no reasonable way to compile it when it specifies something which is then violated, or there might be certain extra things that may be required in the compiled code (making it bigger and/or slower in certain circumstances) when certain things are open. For example, consider if a different calling convention is needed for functions that can throw an exception (although in this case it should not require a try block if the function that calls it is also says it can throw an exception), or if some things in functions in a open class will need to be compiled in a special way to consider the possibility that other parts of the class will be overridden (both of these examples are hypothetical, I do not know whether or not any of this is actually true). It is also possible that certain optimizations are possible or not possible depending on if a class is open or something is nullable etc. Due to such things like that, specifying such features in the program might sometimes be necessary in order for the compiler to work correctly.

Re: Clean Coder: The Dark Path (2017)

#66
I like the idea of in-language control of loose/strict typing.

A project, "main", makefile or compiler parameters, should be able to set minimum strictness for everything it composes/references.

Individual modules should be able to set their looseness, and be parsed and implemented accordingly, with runtime dispatching, template expansion, etc. instead of compile time.

When the two collide, we get an error, and the developer decides which one needs to give way, or making an explicit exception, for the current state of development. So all typing choices are always clear and enforced.

Language highlighting of loose vs. strict would also be nice.

Not quite the same as safe/unsafe, but similar.

But I also like the idea of a typed Forth, so what do I know?

Re: Clean Coder: The Dark Path (2017)

#67
post #64

Earlier quoted context omitted.

What if you're hit by a bike instead of a car because someone took the bike instead of the car?

A helmet can make a big difference in saving your brain if you are hit by a bike. Or if you hit a slippery spot and fall off your bike. Or - hundreds of other things that happen. cars are too big and heavy for a helmet to make a difference - but they are not all that can go wrong. Even in car heavy US there is more than a car that can harm you.

Got it — helmets should be mandatory for pedestrians, in case they are hit by bikes.

Re: Clean Coder: The Dark Path (2017)

#68
> The question is: Whose job is it to manage the nulls. The language? Or the programmer?

> These languages are like the little Dutch boy sticking his fingers in the dike. Every time there’s a new kind of bug, we add a language feature to prevent that kind of bug. And so these languages accumulate more and more fingers in holes in dikes. The problem is, eventually you run out of fingers and toes.

I'm going to try to best to hide my rage with just how awful this whole article is, and try to focus my criticism. I can imagine that reasonable people can disagree as to whether `try` should be required to call a function that throws, or whether classes should be sealed by default.

But good god man, the null reference problem is so obvious, it's plain and simply a bug in the type system of every language that has it. There's basically no room for disagreement here: If a function accepts a String, and you can pass null to it, that's a hole in the type system. Because null can't be a String. It doesn't adhere to String's contract. If you try to call .length() on it (or whatever), your program crashes.

The only excuse we've had in the past is that expressing "optional" values is hard to do in a language that doesn't have sum types and generics. And although we could've always special-cased the concept of "Optional value of type T" in languages via special syntax (like Kotlin or Swift do, although they do have sum types and generics), no language seems to have done this... the only languages that seem to support Optionals are languages that do have sum types and generics. So I get it, it's "hard to do" for a language. And some languages value simplicity so much that it's not worth it to them.

But nowadays (and even in 2017) there's simply no excuse any more. If you can pass `null` to a function that expects a valid reference, that language is broken. Fixing this is not something you lump in with "adding a language feature for every class of bug", it's simply the correct behavior a language should have for references.

Re: Clean Coder: The Dark Path (2017)

#69
post #64

Earlier quoted context omitted.

A helmet can make a big difference in saving your brain if you are hit by a bike. Or if you hit a slippery spot and fall off your bike. Or - hundreds of other things that happen. cars are too big and heavy for a helmet to make a difference - but they are not all that can go wrong. Even in car heavy US there is more than a car that can harm you.

Got it — helmets should be mandatory for pedestrians, in case they are hit by bikes.

Well unironically you would be safer if you did that! Although it's a trade off between looking ridiculous and being safe. I personally don't think bike helmets should be mandatory because it puts people off riding a bike (including me), but do acknowledge that they do make an individual safer.

Re: Clean Coder: The Dark Path (2017)

#70
post #60
post #54

Earlier quoted context omitted.

Can't resist taking this bait, but I feel like the consensus is pretty much that as an individual, choosing to wear a helmet will make you safer, and as a society, mandating bike helmets (and other measures that will cause people to use transportation methods that are more dangerous to others) will make everyone less safe. Of course, it's hard to prove. But I think you'll generally find that, if you compare the numbe…

Comparing the Netherlands with some of the best, if not the best bike infrastructure to other countries without said infrastructure seems very reductionist. To get anywhere near an interesting number you would have to compare the number of injuries to the total number of accidents including cyclists in countries with comparable bike infrastructure and differing helmet policies.

Yeah that's why it's hard to prove. However, it does show that infrastructure experts who actually care about safety (and have achieved the safety numbers to support it) reach for a lot of other measures before they do helmet mandates.
Post reply on HN