While typing is a good way to reduce programmer errors, specially for large scale programs, it's much like autocomplete in a word processor. It's cool to have but also a bad habit to form. The quality of prgrams would improve if such aids were reduced and the programmer was expected to form good programming habits instead.
The power of Result types in Swift
11–20 of 77 posts
Re: The power of Result types in Swift
#12While typing is a good way to reduce programmer errors, specially for large scale programs, it's much like autocomplete in a word processor. It's cool to have but also a bad habit to form. The quality of prgrams would improve if such aids were reduced and the programmer was expected to form good programming habits instead.
Maybe a quick spell check would've caught the misspelling of prgrams or maybe more proof reading is the answer.
/s :D
Types are a tool just like auto spell checking. Why not leverage them to reduce cognitive load?
Re: The power of Result types in Swift
#13While typing is a good way to reduce programmer errors, specially for large scale programs, it's much like autocomplete in a word processor. It's cool to have but also a bad habit to form. The quality of prgrams would improve if such aids were reduced and the programmer was expected to form good programming habits instead.
What would a typeless language look like?
Re: The power of Result types in Swift
#14While typing is a good way to reduce programmer errors, specially for large scale programs, it's much like autocomplete in a word processor. It's cool to have but also a bad habit to form. The quality of prgrams would improve if such aids were reduced and the programmer was expected to form good programming habits instead.
I assume you mean the static typing that Swift has, in favor of something like Python or Ruby, where the type of thing in a variable is both implicit and unfixed. Saying that there should be no types at all is...well, maybe it's just a failure of my imagination, but I don't even know how you could write a program. Even assembler has types.
Re: The power of Result types in Swift
#15While typing is a good way to reduce programmer errors, specially for large scale programs, it's much like autocomplete in a word processor. It's cool to have but also a bad habit to form. The quality of prgrams would improve if such aids were reduced and the programmer was expected to form good programming habits instead.
We should also remove airbags and seatbelts in automobiles. Surely then better driving habits would form.
Re: The power of Result types in Swift
#16While typing is a good way to reduce programmer errors, specially for large scale programs, it's much like autocomplete in a word processor. It's cool to have but also a bad habit to form. The quality of prgrams would improve if such aids were reduced and the programmer was expected to form good programming habits instead.
This seems like some bizarre luddite-esque argument. We should use computers to aid our work, but not too much!!
Re: The power of Result types in Swift
#17It's a very well written article. I'm just a bit surprised there is no mention of the origins of this paradigm as it originated in functional languages (Maybe monad in Haskell).
Re: The power of Result types in Swift
#18I've seen this referred to as "railway programming", and there's a wealth of explanation over at https://fsharpforfunandprofit.com/rop/ . In particular, the slide deck from the FP eXchange contains a diagram (slide 75 out of 154) with a happy path along the top, and a sad path along the bottom, and at every stage when you `bind` a Result into an existing Result, you have the opportunity to divert into the sad path. N…
It's not exactly the same as railway programming as in Swift it's typically not used to connect functions together but rather to replace separate callbacks with one "result" function and to hard type certain results. One typical case in Objective-C style API's would be:
- (void)fetchData whenDone finished: [a block] ifFails failed: [another block]
- (void)fetchData whenDone finished: [a block that has nullable Data and nullable error as parameters]
* Stop the spinner
* Enable the send button again
This often lead to repetitive code or a maze of function calls.
The second one made you basically duck type for the kind of response it really was. Does it have an error? It probably failed. Does it have data? It probably worked. But what if it has both data and an error (error data?) or simply both values were nil? Brittle code.
While I really like the railroad approach the typical problem area Swift is applied to (often web API driven iOS and macOS applications) simply don't lead to these huge chains of functions. I'm definitely going to try it for backend code though.
Re: The power of Result types in Swift
#19While typing is a good way to reduce programmer errors, specially for large scale programs, it's much like autocomplete in a word processor. It's cool to have but also a bad habit to form. The quality of prgrams would improve if such aids were reduced and the programmer was expected to form good programming habits instead.
We should also remove airbags and seatbelts in automobiles. Surely then better driving habits would form.
Removing protective padding and helmets might help in American Football. Rugby doesn't use them and it's actually a safer sport.
But apart from that: the guy is wrong of course! Working in JavaScript still drives me crazy because I don't have decent autocomplete and no IDE warnings I'm using an API wrong.
Re: The power of Result types in Swift
#20While typing is a good way to reduce programmer errors, specially for large scale programs, it's much like autocomplete in a word processor. It's cool to have but also a bad habit to form. The quality of prgrams would improve if such aids were reduced and the programmer was expected to form good programming habits instead.
I assume you mean the static typing that Swift has, in favor of something like Python or Ruby, where the type of thing in a variable is both implicit and unfixed. Saying that there should be no types at all is...well, maybe it's just a failure of my imagination, but I don't even know how you could write a program. Even assembler has types.
Well I think basic data types are enough to express what the variable is expected to hold. Any highewr level types above that, such as what higher level languages provide are, I think a luxury for lazy programmers