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 leave your home again, as safety is your own concern.

Like and subscribe for other posts like “knife handles? What an idiot” and “never wear a helmet you coward”.

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

> Every time there’s a new kind of bug, we add a language feature to prevent that kind of bug.

That's why learning more academic, 'non-practical' aspects of computer science is sometimes beneficial. Otherwise very few will naturally develop the abstract thinking that allows them to see uncaught exception and null pointer are exactly the same 'kind of bug.'

Anyway the author got it completely upside down. The stricter mental model of static typing came first (in more academic languages like Haskell and Ocaml). Then Java etc. half-assed them. Then we have Swift and Kotlin and whatever trying to un-half-ass them while keeping some terminology from Java etc. to not scare Java etc. programmers.

I could not agree less. The line of reasoning here is: relying on the type system to prevent error lets people writer fewer tests. Tests are the only way to assure quality. Therefore fewer tests is bad, and powerful type systems are bad too, because they cause you to act against software quality.

Furthermore, Uncle Bob sets up this weird opposition between the programmer and the type system, as if the latter is somehow fighting the former, rather than being a tool in their hand.

I think that sadly this is just the narrative of a man whose life’s work consists of convincing people that there is a silver bullet, and it is TDD.

While I consider Uncle Bob a bad programmer, there is some merit to this article. This paragraph was particularly prescient:

>But before you run out of fingers and toes, you have created languages that contain dozens of keywords, hundreds of constraints, a tortuous syntax, and a reference manual that reads like a law book. Indeed, to become an expert in these languages, you must become a language lawyer (a term that was invented during the C++ era.)

And this was written before Swift gained bespoke syntax for async-await, actors, some SwiftUI crap, actor isolation, and maybe other things, honestly, I don't even bother to follow it anymore.

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

I understand what the author says, but in my experience, "Nullable Types" and "Open/Sealed Classes" are two different subjects and...

1) For "Nullable Types", I see that it is VERY good to think about if some type can be null or not, or use a type system that does not allow nulls, so you need some "unit" type, and appropriately handle these scenarios. I think it is ok the language enforces this, it really, really helps you to avoid bugs and errors sooner.

2) For "Open/Sealed Classes", my experience says you never (or very rarely) know that a class will need to be extended later. I work with older systems. See, I don't care if you, the original coder, marked this class as "sealed", and it does not matter if you wrote tons of unit tests (like the author advocates), my customer wants (or needs) that I extend that class, so I will need to do a lot of language hacks to do it because you marked as sealed. So, IMHO, marking a class as "open" or "sealed" works for me as a hint only; it should not limit me.

    return when (val result = something()) {
      Result.Success -> // ...
      Result.Failure -> // ...
    }

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

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 happening in the first place?

So obviously it's an opinion and he's entitled to it, but (in my own opinion) it is so so so, on-its-face, just flat out wrong, I'm concerned that that it's creating developers who believe that writing so many tests (that languages and compilers save you time (and bugs) in writing) is a valid solution to preventing null pointer defeferences.

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.

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.

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?

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

Surely needing to change some class declarations is better than bugs that take all day to track down? And sure as a programmer i can consider every npe case along with all the others but if the language can take car3 of that for me, I’ll let it

I disagree with the article, but also some of these examples are complete straw-men. In Kotlin you have nullable types, and the type checker will complain if you use it as a non-nullable type. But you can always just append !! after your expression and get exactly the same behavior as in Java and get a null pointer exception, you don't have to handle it gracefully as the author is suggesting. Tests checking that you gracefully handle nulls in a language without null types are fucking tedious and boring to write. I would take a language with null types over having to write such tests any day.

Kotlin's final-by-default is also just that - a default. In Java you can just declare your classes `final` to get the same behavior, and if you don't like final classes then go ahead and declare all of then open.

I also disagree with the author's claim that languages with many features requires you to be a "language lawyer", and that more simplistic languages are therefore better. It's of course a balance, and there are examples of languages like C++ and Haskell where the number of features become a clear distraction, but for simpler things like null types and final-by-default, the language is just helping you enforce the conventions that you would anyway need when working with a large code base. In dynamically typed languages you just have to be a "convention lawyer" instead, and you get no tool support.

> Now, ask yourself why these defects happen too often. ... It is programmers who create defects – not languages.

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

I get the point of the article. However, you can have both: programmers that write tests and don't override safety measures AND safety measures.

"The Blub Paradox", the article.

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

Between this and the debate about ideal method length with Ousterhout, my respect for Uncle Bob is plumbing new depths.

Isn't that the classic argument "Real C programmers don't write defaults!" ?

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.

> For example, in Swift, if you declare a function to throw an exception, then by God every call to that function, all the way up the stack, must be adorned with a do-try block, or a try!, or a try?.

Funnily enough, Uncle Bob himself evangelised and popularised the solution to this. Dependency Inversion. (Not to be confused with dependency injection or IOC containers or Spring or Guice!) Your call chains must flow from concrete to abstract. Concrete is: machinery, IO, DBs, other organisation's code. Abstract is what your product owners can talk about: users, taxes, business logic.

When you get DI wrong, you end up with long, stupid call-chains where each developer tries to be helpful and 'abstract' the underlying machinery:

  UserController -> UserService -> UserRepository -> PostgresConnectionPoolFactory -> PostgresConnectionPool -> PostgresConnection

(Don't forget to double each of those up with file-names prefixed with I - for 'testing'* /s )

Now when you simply want to call userService.isUserSubscriptionActive(user), of course anything below it can throw upward. Your business logic to check a user subscription now contains rules on what to do if a pooled connection is feeling a little flakey today. It's at this point that Uncle Bob 2017 says "I'm the developer, just let me ignore this error case".

What would Uncle Bob 2014 have said?

Pull the concrete/IO/dependency stuff up and out, and make it call the business logic:

  UserController:
      
      user? <- (UserRepository -> PostgresConnectionPoolFactory -> PostgresConnectionPool -> PostgresConnection)
      // Can't find a user for whatever reason? return 404, or whatever your coding style dictates

      result <- UserService.isUserSubscriptionActive(user)

      return result

The first call should be highly-decorated with !? or whatever variant of checked-exception you're using. You should absolutely anticipate that a DB call or REST call can fail. It shouldn't be particularly much extra code, especially if you've generalised the code to 'get thing from the database', rather than writing it out anew for each new concern.

The second call should not permit failure. You are running pure business logic on a business entity. Trivially covered by unit tests. If isUserSubscriptionActive does 'go wrong', fix the damn code, rather than decorating your coding mistake as a checked Exception. And if it really can't be fixed, you're in 'let it crash' territory anyway.

* I took a jab at testing, and now at least one of you's thinking: "Well how do I test UserService.isUserSubscriptionActive if I don't make an IUserRepository so I can mock it?" Look at the code above: UserService is passed a User directly - no dependency on UserRepository means no need for an IUserRepository.

I was rewriting a mod for Rimworld recently. As Rimworld is built on Unity, it's all some sort of C#. I heard people say it's a wrong kind of C#, but since a) I had no choice and b) I never wrote any C# before I cannot tell.

First, C# proudly declares itself strongly-typed. After writing some code in Zig (a project just before this one, also undertaken as a learning opportunity, and not yet finished), I was confused. This is what is called strong-typed? C# felt more like Python to me after Zig (and Rust). Yes there are types. No, they are not very useful in limiting expression of absurdity or helping expression of intent.

Second, test. How do you write tests for a mod that depends on an undocumented 12 year old codebase plus of half a dozen of other mods? Short answer - it's infeasible. You can maybe extract some kind of core code from your mod and test that, but that doesn't help the glue code which is easily 50-80% in any given mod.

So what's left? I have great temptation to extract that core part and rewrite it in Zig. If Unity's C#-flavor FFI would work between linux and windows, if marshalling data would not kill performance outright, if it won't scare off potential contributors (and it will of course), if, if...

I guess I wanted to say that the tests are frequently overrated and not always possible. If language itself lends a hand, even as small and wimpy as C#'s, don't reject it as some sort of abomination.

I lean on types heavily as my vehicle for change.

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<User>? Promise<User>? 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.