Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Engineering's Greatest Hits [video]

youtube.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Software Engineering's Greatest Hits [video]

#31

Post by mpweiher »

dharmaturtle wrote: post #25
mpweiher wrote: post #21

Earlier quoted context omitted.

While ROP is better than some current ways, I vastly prefer dataflow (pipes/filters) as a technique. 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 th…

> The fundamental problem, IMHO, with error-handling is the call/return nature of most of our programming languages 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 fro…

Well, I think you are filtering things through a lens that is so limiting that it might as well be misunderstanding. This lens, this filter, is so ubiquitous that as far as I can tell, most people can't recognise it. I call it The Gentle Tyranny of Call/Return [1][2][3]

> 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...

Re: Software Engineering's Greatest Hits [video]

#32

Post by mixmastamyk »

mikewarot wrote: post #18

Well, this has a lot of practical knowledge on offer, and I intend to watch it a few more times for it all to sink in. 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 excepti…

> 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.

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.

Re: Software Engineering's Greatest Hits [video]

#33

Post by amirkdv »

bwship wrote: post #30
mikewarot wrote: post #18

Well, this has a lot of practical knowledge on offer, and I intend to watch it a few more times for it all to sink in. 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 excepti…

In the systems I build, I always have the lambda's throw the error to Slack. I have been told many times, that is crazy, and that it doesn't scale. By guess what, when a developer's errors are blowing up a slack channel, they always get fixed.

Did this actually lead to better error handling? I'd be worried that it leads to silent idioms of "catch-and-drop" to silence the Slack blow up

Re: Software Engineering's Greatest Hits [video]

#34

Post by kova12 »

What he said about developer productivity might be technically wrong, but misleading. Certain types of work require one to be at certain level of mastery, not just in software by the way. One who performs at that level can do the job, but just barely. Below that level you are a burden, not an asset, whoever worked in the industry knows such people, they don't do anything productive, but mostly get in the way. If we then assume that this level is zero, then everything above it it is positive, and or measurement of how much one engineer is better than another is exaggerated.

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.

Re: Software Engineering's Greatest Hits [video]

#35

Post by amirkdv »

> Lots of code metrics have been proposed ... But nothing works better than counting lines of code [with citations]

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.py

Re: Software Engineering's Greatest Hits [video]

#36

Post by mikewarot »

mixmastamyk wrote: post #32
mikewarot wrote: post #18

Well, this has a lot of practical knowledge on offer, and I intend to watch it a few more times for it all to sink in. 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 excepti…

> 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. 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.

The language had error handling constructs, but in the years they'd been teaching the course, nobody had ever asked how the error handling actually was to be used in practice. I found it shocking that nobody cared about error handling, especially on a platform that generated programs to be used by non-computer literate civilians.

Re: Software Engineering's Greatest Hits [video]

#37

Post by bmn__ »

citrin_ru wrote: post #3

> Perl is as hard for novices to learn as a language with a randomly-designed syntax 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…

> > Perl is as hard for novices to learn as a language with a randomly-designed syntax

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

Re: Software Engineering's Greatest Hits [video]

#38

Post by bwship »

amirkdv wrote: post #33
bwship wrote: post #30

Earlier quoted context omitted.

In the systems I build, I always have the lambda's throw the error to Slack. I have been told many times, that is crazy, and that it doesn't scale. By guess what, when a developer's errors are blowing up a slack channel, they always get fixed.

Did this actually lead to better error handling? I'd be worried that it leads to silent idioms of "catch-and-drop" to silence the Slack blow up

There is a risk with it that you just ignore it. We always put it into a separate room for dev staging and prod. So, what will often happen is you might start to see more errors occurring once you push to staging and your tests are running. It doesn't replace tests and the like, and isn't a cure all in terms of how to handle errors, but I have found it pretty helpful. Especially with serverless, because observability is one of the hardest parts of this paradigm.

Re: Software Engineering's Greatest Hits [video]

#39

Post by phazy »

kqr wrote: post #8

I was very impressed by Greg Wilson's 2009 presentation, which seems to have disappeared from Video, but I think corresponds to these slides: https://www.slideshare.net/gvwilson/bits-of-evidence-2338367 It 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 impressionabl…

I managed to find an archived audio recording of his talk: https://web.archive.org/web/20120118143443/http://craigagree...

Even if the quality is not the best, you should still be able to understand most of the presentation.

Re: Software Engineering's Greatest Hits [video]

#40

Post by rbjorklin »

frank_nitti wrote: post #28
mikewarot wrote: post #18

Well, this has a lot of practical knowledge on offer, and I intend to watch it a few more times for it all to sink in. 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 excepti…

I also believe anyone can learn anything, exactly as you said! 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 determin…

> I also believe anyone can learn anything, exactly as you said! > But I don't find the study about grade distributions a convincing argument for that, unfortunately.

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.

Post reply on HN