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

21–30 of 44 posts

Re: Software Engineering's Greatest Hits [video]

#21

Post by mpweiher »

dharmaturtle wrote: post #20
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'm a big fan of "Railway Oriented Programming" [1]. Basically your code has two paths - the "Ok" route and the "Error" route. Your code won't compile unless you handle the Error case. 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 m…

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

Re: Software Engineering's Greatest Hits [video]

#22

Post by bsenftner »

mikewarot wrote: post #17
bsenftner wrote: post #10

Earlier quoted context omitted.

After the "toy" languages of Basic and Pascal, my first real programming language was PDP11 Macro-11 Assembly. At the end of that programming class, the final assignment combined all the prior assignments and to the entire class's surprise we had a C compiler. From that laying a foundation experience, I felt extremely comfortable when learning and working in C for a good 20 years after graduation. C++ appeared first…

>the "toy" languages of Basic and Pascal What makes Pascal a toy language?

Too many guards and training wheel preventions? Lack of adherence to a loose standard causing incompatible language variations from different vendors? Pascal editors often enforced a code layout style, with different editors enforcing different styles? No serious work done in pascal?

Re: Software Engineering's Greatest Hits [video]

#23

Post by sidpatil »

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…

I agree. This is something I tried to explain to others in my last job, with little success.

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.

[1] https://en.wikipedia.org/wiki/Turing_tarpit

Re: Software Engineering's Greatest Hits [video]

#24

Post by netvarun »

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…

I agree and well articulated! Your comment reminds me of the quote, “Everything should be made as simple as possible, but no simpler.” (Einstein??)

Re: Software Engineering's Greatest Hits [video]

#25

Post by dharmaturtle »

mpweiher wrote: post #21
dharmaturtle wrote: post #20

Earlier quoted context omitted.

I'm a big fan of "Railway Oriented Programming" [1]. Basically your code has two paths - the "Ok" route and the "Error" route. Your code won't compile unless you handle the Error case. 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 m…

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

Re: Software Engineering's Greatest Hits [video]

#26

Post by preommr »

infocollector wrote: post #16
Erikun wrote: post #14

Earlier quoted context omitted.

It seems he took the title of a different Fucci 2016 paper, it should say "A Dissection of the Test-Driven Development Process: Does It Really Matter to Test-First or to Test-Last?" 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

Thanks! Seems like short cycles of development including interleaving testing - is the key in this paper. TDD might just achieve this by a fluke, but it should help that - unless you do this TLD or even test addition in cycles. Any thoughts on that?

> TDD might just achieve this by a fluke

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.

Re: Software Engineering's Greatest Hits [video]

#27

Post by therealdrag0 »

mpweiher wrote: post #21
dharmaturtle wrote: post #20

Earlier quoted context omitted.

I'm a big fan of "Railway Oriented Programming" [1]. Basically your code has two paths - the "Ok" route and the "Error" route. Your code won't compile unless you handle the Error case. 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 m…

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…

Scala has some nice containers around this with Either, Try, and Future. We’ve also made some custom hybrids like FutureEither. And then with basic for-comprehensions/maps you can chain together logic and if something fails it’ll return an either with a Left containing an error response, otherwise it’ll implicitly keep going with Right artifacts.

Re: Software Engineering's Greatest Hits [video]

#28

Post by frank_nitti »

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 determined student can master the material. There is overlap, but not enough to use a premise that GradesAbility

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.

Re: Software Engineering's Greatest Hits [video]

#29

Post by perlgeek »

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…

There's a huge bias towards the happy case in specifications, user stories and so on.

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.

Re: Software Engineering's Greatest Hits [video]

#30

Post by bwship »

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.
Post reply on HN