The example is strange and contrived. I couldn't torture the logic enough to demonstrate how readability breaks down with exceptions. Reading through the comments, I realise that even if the code is unreadable with exceptions, it can be rewritten to be readable.
I updated the article to highlight not only readability, but also compositionality. I also tried to draw parallels with Promises (which are also monadic).
I tried to target the article to intermediate programmers that may not already know most of the concerns raised in the comments, and I surely can't cover enough space on error handling without writing a book.
Thank you for the comments. I've learned more from reading the comments.
Author here. Thank you for the link to Midori's error model. It's on my reading list for this week.
> So we should keep the door open, and not pretend we have already solved errors.
Very much this. Even with errors as values, the approach languages like Go take makes composition difficult. I presented the Kleisli approach instead. That recovers compositionality.
OCaml does something I find interesting. It makes exceptions performant by not capturing stack traces by default. But it's still too easy to forget handling the exception.
> btw, the article uses Rust, not Go, but anyway...
I actually used TypeScript. The Rust bit was meant to introduce the idea from Rust to TypeScript. It's not new in TypeScript, but it's not popular either. I have updated the article to clarify that.
Yes, this. Parse all input at the application boundaries and reject invalid input. For division by zero, the code path that leads to that should encode the input as a number greater than zero. But this may be clunky to do, depending on the language you're working with.
I agree with you. With OpenAPI you can be more specific about what your API does. You can add examples and refer to the output of an API call (useful if you need to point out relationships).
When I have time, I may work on more tooling for OpenAPI. I'm thinking of a way of specifying workflows by connecting APIs in a specification, then deriving tests for that workflow. A way of saying, "always call this operation first, then use the response to call this other operation." Then the tool can test entire workflows automatically.
I used OpenAPI exclusively on my previous job. But it was only me, the back-end developer. My colleagues appreciated the documentation. But when it was time for me to leave, the team moved to Postman. OpenAPI was another DSL to learn, and they didn't consider it worthwhile.
Although there are WYSIWYG editors for OpenAPI, they are not as popular as Postman. There's just a lot of inertia in the way of OpenAPI adoption.
Even though I like it, I find the DSL too verbose. A slimmer DSL would be great. Generating the spec from existing code worked sometimes, but it coupled the API design process to the implementation code. I'm not a fan of that.
I think OpenAPI's appeal is in tooling: provide a spec, then you get documentation, API consoles, mock servers, etc. for free. If it's for documentation only, people will continue using Postman. Postman already provides mock servers and consoles, so there you have it. It'll take more tools built on OpenAPI to make it very appealing.
When I gave this book an attempt, I appreciated the author's honesty about the difficulty of the material. I went with Real World Ocaml instead, intending to reattempt SoFP in the future.
Today I suggested an addition to a section in Real World OCaml, and the author pointed out that the section was already so dense that adding the extra content would require more explanation. I now appreciate the difficulty in making such a technical material approachable by a less technical audience, and a heads up is appropriate.
Edit: (in light of another reply that mentioned the lambda calculus). The addition to Real World OCaml that I suggested was to call out the implementation of the Y combinator in the section on Memoization. The explanation used the Y combinator to work up to an implementation of memoization, and it was so intuitive that I felt it should be noted, but that won't easily fit into an already dense chapter.
I don't mean to be pedantic, but, without the comma, I read it wrong twice.
I agree with you totally. I'm currently looking for a course I can volunteer for outside my day job.
That's quite like my experience. I started out with Emacs, but I learned Vim along the way and the key bindings are awesome. I use them in other editors, but often they conflict with the editor's defaults, or they're not emulated properly.
I don't use Vim exclusively (I couldn't get to customize it, couldn't get to learn vimscript), but the key bindings are great.
I sincerely hope you find something that works. It is a good pursuit. Will it be limited to learning programming only? There are many other skills that will be needed after such crises. One such skill is creative writing to bring the arts back to life (other arts are needed too). Another is story telling, because the story of the events will need to be told, preferably by those who were in the midst of it, not those who wish to write the victims' history (like the colonialists did to Africa).
I am a Nigerian, and I am an studying to take up a career in tech (focusing on software engineering, but I have interests in data science, and education). I see these stories of Nigerian scam artists presented in a stereotypical way that tends to casts a whole nation in that image, and it saddens me.
In 2016, and through the first quarter of 2017, at the peak of the ponzi schemes frenzy that caught Nigeria (did you hear of MMM and the likes?), some friends asked me to create a similar platform for peer-to-peer donations for them. They wanted a matrix scheme with themselves at the top; they'd later take the site down suddenly after making much money; whoever came in last or invested much would be wrecked.
I refused taking the job, and some other developer friends declined similar requests. I know some that took such jobs. So there are the dishonest ones, and there are the genuine ones.
While there are scammers raising the country's flag everywhere, I am certain many are not Nigerians.
As Chimamanda Adichie said, the problem with stereotypes is not that they are false, but that they are only half the truth.
TheRealmccoy's goal is commendable.
Many economies do not have favorably
balanced trade with the big nations, so an
effective way to learn on mobile will help
many persons.
But in a crisis where bombs and bullets
are flying around, will studying be really
important to survival? Will edX be of any
help to someone who likely does not have
internet access (I'd rather spend on
essential goods than pay an ISP that
doesn't care about me)?
His solution, if he finds one, will be of
benefit to the captive economies of the
third world, except the crisis-torn
economies.
I mentioned that stability is a concern for me. Don't you think Arch Linux feeding packages from upstream might not be ideal for me? That's the reason I highlighted Debian testing instead of Debian unstable.
I've used Slackware before, and it was an easy look into the system; except that package management is a bit stressful on Slackware, and its packages are not so up-to-date.
I'm running a VM with FreeBSD now; how suitable it can be for a laptop, I don't know yet. Battery life matters there too.
Fedora looks good; I already have a Fedora 24 disc, so I might go from there instead of Slackware. openSUSE tumbleweed looks great too. I'll probably try it.
How does openSUSE do compared against Fedora, FreeBSD and Debian (testing) for developers?
I'm currently running Ubuntu but the experience is not as smooth as I want: I've had several freezes and kernel panics, even though my laptop is well supported (from Ubuntu 14.04, at least).
I want something that's a bit stable with more recent packages.
FreeBSD seems to be semi-rolling release, comparing package versions in the 'current' release with that in the snapshot versions.
Debian testing has packages as recent as I can use, but I heard it's less stable than Ubuntu and bad things happen too.
I'm considering Fedora, but I prefer rolling release distros to fixed release ones (I don't want Rawhide for stability sake).
OpenSUSE has older packages in its repos: PHP < 7.0, gcc < 6, ...
> ""It is immature or silent for the first
several days after formation," Prof
Tonegawa said.
'Strong case'
The researchers also showed the long-
term memory never matured if the
connection between the hippocampus
and the cortex was blocked.
So there is still a link between the two
parts of the brain, with the balance of
power shifting from the hippocampus to
the cortex over time."
I have no good knowledge of neuroscience, so I'll be happy to read other thoughts on this.
Personally, it seems to me that this is an evolved technique to direct us to:
act on impulses at the moment of an event, instead of contemplating rational choices that may take too much time to arrive at (thus limiting our chances of survival);
pursue rational choices in calmer times, trusting us to draw on stored memories of similar events to help make better decisions (the purpose of Deja Vu?)
For the link between the hippocampus and the cortex being required to retrieve memories; maybe those memories are useless without the emotional context, and the hippocampus is needed to relive those emotions to have a more accurate recollection of the memories.
It might not make sense (I know almost nothing about neuroscience), but it's a thought.
I subscribed to your blog and your newsletter some months ago, and I must say I like what you do. Although I'm focused on C++ now for some courses I'm taking, I still hope to catch up on Go later, and I think your book will be helpful.
Personally, I wouldn't mind a hands-on exploration of a programming language having some pages, and links to good resources, on version control. Learning 'git' in such practical way (as part of a project) seems better to me (Harvard's CS50 now takes that approach too:
https://github.com/blog/2322-how-cs50-at-harvard-uses-github...).
The Linux Foundation may have just accepted a Trojan Horse (or rather, a Redmond Horse). I hope it turns out for good for all.
I'd love to see better contributions to Linux. If Microsoft can help make Wine better, then the playing field could be level. But it is scary to think that so many years of open source software available on Linux will eventually be available to Windows users without being ported to Windows, and then Linux suffers more. Hopefully it will be good for all.
I used Windows in 2015 (I never used it as my primary OS for more than a year) alongside some Linux distros (Ubuntu, Fedora, Debian, Slackware and a few others). I finally settled for Debian, at least for now. Whenever I need to do something with Windows, I just fire up VirtualBox and it's working well so far.
I miss games on Windows and I'm not aware of anything comparable (without SteamOS) on Debian.
I read "Internet Book Piracy" recently about this issue and the author, Gini Graham, has valid points and suggestions for reducing piracy; this was one of her suggestions.
I have no problem with Elsevier crying wolf when there's none. They had it coming. I'm concerned about the actual cost to authors.
We need a new model that puts the authors and their readers as first priorities and facilitates the movement of information, not hoarding it. Publishing companies did that for a while, then they declared themselves custodians of our common knowledge and hoarded it from us.
I'm thinking of ways publishing can be made what it should be. Gini Graham has good suggestions that I'd like to see tried out.
Thank you for the comments. I've learned more from reading the comments.