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.
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.
The real advantage of sticking to something like Postman for me is that it's easier to share with other people. You can offer somebody a Swagger definition and get blank stares and shrugs, but everybody seems to have access to Postman. Like it's become a de-facto standard for sharing your working API calls rather than a hit-and-miss standard that may or may not actually work compared to the actual system.
The problem is that your API then doesn't have a clear specification. Or maybe it does, but this doesn't communicate it.
Showing some examples can still lead a team to run into an edge case when they find a different behavior for a different value passed in the API body. At least OpenAPI has a way of documenting such behaviors.
Btw, thought of something else. With OpenAPI you can actually embed examples in the spec. I believe there are tools to generate postman requests from these also.
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.
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 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.
When I was a college student in the US, a classmate of mine wanted my help automating an online poker site. Slightly more "victimless," but not necessarily any more ethical.
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.
specially in crisis torn places, one finds only gloom and sadness; the future looks dark and bleak, if a pedagogical approach is found where kids and youngsters can learn on mobile itself, something like Programming, which could help them in a better future, that could help many.
Unfortunates those who are forced to migrate, may be can learn enough to start a new beginning.
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).
This is one of the first in the series. Post October, I am going to work as a waiter at one of the beach shacks here and based on my experience, I intend to write a novel and also publish my research on "How to get maximum tips, working as a waiter".
Both creative writing and story telling are very close to me, off late I have written 17 short stories, they can be read on https://medium.com/@realmccoy
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, ...
First things first. Set up a VM with Arch Linux, Slackware, Gentoo or if you are feeling adventurous Linux From Scratch. It'll go a long way to help you learn how Linux systems work. (Don't install a graphical environment, plain X server is OK though).
Now to your original question:
If you want bleeding edge packages go with either Arch Linux, Gentoo, openSUSE or Solus. I haven't used openSUSE as extensively I'd like to but haven't had any issues with it yet. The package format is a bit too much if you want to create your own packages though. openSUSE ticks all the marks in your checklist too.
Other than that I will suggest to keep your local dev environment as close to production as SANELY possible. Fedora and openSUSE are good bets.
Personally for rolling releases I've found Arch Linux to be the best (not because they are rolling release but because they generally keep the packages without any modifications from upstream). There is a huge selection of packages. But it suffers with the problem that it's not used in production and hence some issues can't be caught on it.
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.
I haven't used FreeBSD on laptops. openSUSE is the best best for you I'd say. It's stable enough, had very good package repositories and is used by quite a lot of people. Fedora has the same issues regarding up to date packages.
I can't vouch for the package breakages on any system other than Fedora. I've just had a single package breakage on Arch in over a year. It was fixed by simply moving a file and making a symlink.
Thank you for the comments. I've learned more from reading the comments.