Software Engineering's Greatest Hits [video]
youtube.com
youtube.com
I've always believed that anyone can learn anything, if they and their teacher both believe it, and put in the effort. I'm glad to see that bias confirmed.
I was really surprised that nobody seems to actually handle errors. This does reflect my experience, in what I thought (until now) was an exception. In about 1985 I was taking a vendor taught course in PL/N at the Norand company (who made hand-held computers used for inventory management). We got to the section of the course about error handling. They described the syntax for checking errors, and how to format things, etc. I asked what happened when you got an error, and both instructors had never been asked that question, and both had ZERO clue about it.
For all the arguments here about in and out of band error handling, this was shocking, and definitely did not confirm any bias.
However, it requires language level support to use easily - you need mutually exclusive types like discriminated unions. It's harder to do in most OO languages like C#/Java/Javascript, but you can do it with some effort. Which is why most don't.
The fundamental problem, IMHO, with error-handling is the call/return nature of most of our programming languages. That means you have to return something from you function/procedure. If you have nothing to return (error) or nothing to return yet (async), you have a problem, particularly with intermediate functions that don't really know what happened below them and don't really have enough of the context from their callers to handle the error.
Exceptions allow you to skip the these intermediate layers. ROP makes you handle all those layers, but gives you some tools to help make sure you did it correctly.
Filters, on the other hand, do not return results. Instead they actively pass their results on to the next filter in line. That means that in the case of an error, they can do what functions/procedures cannot: simply not produce a result at all. The next filter will be none-the-wiser.
You can then have the filter have an out-of-band mechanism for actually dealing with the error, analogous to Unix stderr.
I actually consider this a benefit, not a problem. The alternative, as I see it, is to side effect... which 99% of the time is a bad idea if there's an alternative.
> particularly with intermediate functions that don't really know what happened below them and don't really have enough of the context from their callers to handle the error
If you write a `map` function, you can use it in your pipeline to map over the Ok case and your intermediate functions don't need to know they're taking an Ok|Error type. This is exactly the same as what occurs in the `map`/`select` higher ordered function that's on the `list` type. The function passed to map/select doesn't know that it's being used on a list. In the same way, the function being passed to `Ok.map` doesn't know that it's being used on a discriminated union.
> You can then have the filter have an out-of-band mechanism for actually dealing with the error, analogous to Unix stderr.
To me this is a side effect and should be avoided. Basically your filter is partitioning your list into two lists, one of OKs and one of Errors, logging the errors, and then not reporting anything back to the consumer. LMK if I'm misunderstanding.
> side effect... which 99% of the time is a bad idea
Nope. A filter does not have "side" effects. It has effects, as in what you want to achieve. And it turns out that having an effect is a good idea about 100% of the time, because otherwise your program is 100% useless. Now when your primary architectural style is call/return based, effects of the program that are not encoded in the return value do become "side" effects, but that's a limitation of call/return (which FP turns up to 11), not a problem of effects in general.
> > You can then have the filter have an out-of-band mechanism
> To me this is a side effect and should be avoided.
Why? Apart from the religious mantra of "it is a side effect"?
When I adopted this pattern, it turned out to be hugely beneficial. It keeps your happy-path happy, no need to pollute it at all with error handling concerns. And it lets you customise and centralise your error handling, which turns out to be what you usually want, but without the call-stack shenanigans of exceptions.
ROP kinda sorta attempts to do something similar, but due to the constraints of C/R, it turns out to be far more complex.
[1] https://dl.acm.org/doi/10.1145/3397537.3397546
[2] https://www.youtube.com/watch?v=Gel8ffr4pqw
[3] https://2020.programming-conference.org/details/salon-2020-p...
I try hard to discuss error cases, but often I only get a very unenthusiastic "well, show an error message, d'oh" as a response, which wears me out over time.
This is worse for non-interactive things, like event handling. There's no person to show the error to, usually logging and aborting are kinda the only possible actions, which is endlessly frustrating.
No comprendo. Did you mean, what was supposed to happen?
Sounds very context-dependent to me. Sometimes you'll pause and show the user the error, sometimes you'll log it and move on, and if it is fatal you'll shutdown immediately to prevent further harm.
In my experience, newbie students are working hard to get things working correctly in simple cases. So error handling feels like a luxury at that point.
What worried me more was when they said nobody had asked that kind of question before, across years of teaching.
But I don't find the study about grade distributions a convincing argument for that, unfortunately. Grades are a measure of student's ability to apply consistent effort on assignments and effectively study for an exam, often collaborating with a network of other students to find the correct solutions.
A determined student can earn a good grade. A determined student can master the material. There is overlap, but not enough to use a premise that Grades<=>Ability
A more convincing study would find a way of evaluating their individual ability to solve problems related to what they are supposed to have learned, not their grade in the course.
That does indeed seem like a faulty argument. Wouldn’t there be heavy selection bias? It seems incorrect to draw the conclusion that anyone can learn programming based on the grade distribution of a university level CS class.
Make something accessible to novices IMHO is a wrong goal in many cases. A tool like a programming language used day to day for many months or years. What important is how efficiently you can use it after spending enough time to learn it (I would say a month or two should be enough for most languages if you know already a few, but it depends).
Of course we cannot ignore how hard is to learn a language otherwise we will have languages like C++ which require years to master it (and even coders with years of experience fall pray to numerous hidden traps of the language).
I also think you may overestimate the depth of knowledge that the average programmer has about his most used programming language. Languages evolve a lot, sometimes faster than how you used them. People also don't use the same programming language during all their life.
Anyway, at the time Enterprise Java was developed, it was commonly believed that the best way to do large scale development is to hire busload of outsourced workers and give them tools that don't let them do too much damage. If you let them have C++, you'd end up with Series 60.
A person using a language long-term is only a novice for so long. After they've figured out the basics and become comfortable solving problems, they become interested in efficiency.
Designing a language to cater to novices is like designing a bicycle with only low gears—it's easy to get started, but increasingly difficult to move fast. I.e. the Turing tarpit [1].
I'm biased, and admittedly don't have a lot of perspective on this topic, but I have seen the effects of poorly-designed languages on the application development process and its output.
What makes Pascal a toy language?
Stefik is a hack fraud, and he claimed another victim with Wilson. HN readers, beware.
https://www.nu42.com/2013/11/are-perl-users-unable-to-write-... http://redd.it/39buec http://redd.it/38i1pr
In slide 18 Fucci2016 is referred for a replication study with 39 professionals. That study only uses students. That slide quotes Fucci2016, but I do not see that quote in the paper. He talks about TDD and hatemail and is not careful about references? Perhaps this was just a small error - the reference is incorrect. I am not sure.
It seems believable that Test-first vs Test-last might have similar impacts. I just checked one thing in this talk and it turned out to problematic. Has anyone else done fact-checking on his stories?
This paper contains both the quote and is done on 39 professionals. This seems like an easy mistake to make and not something I feel has an impact on the trustworthiness of his talk
I am confused by this comment and the overall sentiment in the video.
Short dev cycles isn't an accidental byproduct - it's literally one of the key parts of tdd.
The first google result for tdd has this:
> Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
It's like when you are playing an RPG. Quest that requires level 5 is pretty much impossible for level 4. Doable for level 5. Level 6 can pass one easy. Level 10 would zoom through it. He's not 10 times higher in level than level 5, but certainly would get the job done 10 times faster and more reliably. That's where this comes from. Small advantages can mean difference between failing the project, barely pulling the project, or acing one; all of which translates into business losing or making money.
Here's an anecdoate, not to dispute the empirical finding.
I recently discovered McCabe (cyclomatic) complexity and found it remarkably good! In a tiny experiment, I ran it on a 50k Python code base with a threshold of 8, and the output almost exactly matched all of the already existing `FIXME: refactor this` comments. According to McCabe the threshold to look out for is 10.
---
p.s: if you write Python, you already probably have the mccabe package installed through flake8. Use it like so:
$ python -m mccabe --min 8 foo.pyIt truly changed the way I think about not just software development, but it changed my entire view of the world, which is more than I can say of any other presentation. Granted, I was still at a fairly impressionable age of 17 when I listened to it, but still.
Definitely looking forward to listening to this one too.
Even if the quality is not the best, you should still be able to understand most of the presentation.