351–357 of 357 posts
Earlier quoted context omitted.
Ada has this ability to define ranges for subtypes. I wish language designers would look at Ada more often.
And I wish people would remember Pascal and Modula-2 had it before Ada. :)
Earlier quoted context omitted.
It's strongly typed, but it's also duck typed. Also, in ruby everything is an object, even the class itself, so type checking there is weird. Sure it stops you from running into "'1' + 2" issues, but won't stop you from yeeting VeryRawUnvalidatedResponseThatMightNotBeAuthorized to a function that takes TotalValidatedRequestCanUseDownstream. You won't even notice an issue until: - you manually validate - you call a me…
You just described why I fell out of love with Ruby.
Earlier quoted context omitted.
FWIW, I extensively use strong enums in C++[1] for exactly this reason and they are a cheap simple way to add strongly typed ids. [1] enum class from C++11, classic enums have too many implicit conversions to be of any use.
> classic enums have too many implicit conversions They're fairly useful still (and since C++11 you can specify their underlying type), you can use them as namespaced macro definitions Kinda hard to do "bitfield enums" with enum class
Earlier quoted context omitted.
Depends which is quicker. If I catch a trivial bug on the first run, I just saved myself writing the type system to find it ahead of time.
When a bug like this can cause real world harm, we can't just bumper car program our way out of things. As engineers we should be able to provide real guarantees.
But I don’t think we are engineers. Software dev isn’t like engineering. You can’t change the structure of a bridge after it has been built by deploying code to prod in a minute. Software dev is just software dev, it’s not engineering or science. It has some parallels with craftsmanship, but it’s unique.
An adjacent point is to use checked exceptions and to handle them appropriate to their type. I don't get why Java checked exceptions were so maligned. They saved me so many headaches on a project where I forced their use as I was the tech lead for it. Everyone hated me for a while because it forced them to deal with more than just the happy path but they loved it once they got in the rhythm of thinking about all the…
Checked exceptions work well for occasional major "expectable" failures -- opening a file, making a network connection.
They work extremely poorly when required for ongoing access or use of IO/ network resources, since this forces failures which are rare & impossible to usefully recover from to be explicitly declared/ caught/ rethrown with great verbosity and negative value added.
All non-trivial software is composition, so the idea of calling code "recovering" from a failure is at odds with encapsulation. What we end up with is business logic which can fail anywhere, can't recover anything, yet all middle layers -- not just the outer transaction boundary -- are forced to catch or declare these exceptions.
Requiring these "technical exceptions" to be pervasively handled is thus not just substantially invalid & pointless, but actually leads to serious rates of faulty error-handling. Measured experience in at least a couple of large codebases is that about 5-10% of catch clauses have fucked implementations either losing the cause or (worse) continue execution with null or erroneous results.
https://literatejava.com/exceptions/checked-exceptions-javas...
Earlier quoted context omitted.
You have it backwards from where I'm standing. 'null' (and to a large extent mutability) drives a gigantic hole through whatever you're trying to prove with correct-by-construction. You can sometimes annotate against mutability in OO, but even then you're probably not going to get given any persistent collections to work with. The OO literature itself recommends against using constructors like that, opting for static…
Nullability doesn't have anything to do with object-oriented programming.
But I'm going to keep conflating the two until they release an OO language without nulls.