3 ms·

Seems like this approach fits a rather narrow band of stuff that is not really that hard. Learning programming, or even programming in general (the middle of th

by ksk 11y ago

Seems like this approach fits a rather narrow band of stuff that is not really that hard. Learning programming, or even programming in general (the middle of that bell curve is your typical line of business app written in Java/C#) is in my opinion several orders of magnitude easier compared to say, developing reliable vaccines or building a modern reliable car engine. Also, this kind of technique is biased towards "building stuff" rather than holding off on building stuff till you can release software with zero bugs - which I would definitely categorize as hard. (Sure, for a hobby project, we don't really care about that kind of quality) Its a shame that even top tier true-blue software companies like Google/IBM/Oracle/Apple/Microsoft continue to hire below average programmers who churn out code that needs to be constantly patched and fixed. It seems like nobody teaches people to value code that can run for a year without crashing or leaking memory.

rafaquintanilha 11y ago
Apples vs oranges comparison. Nobody creates vaccines alone and from scratch, neither big and reliable software. It's clear for me that the author states a way to getting things done. It wasn't a tutorial in "how to become a pro in everything in only 5 minutes".
- ksk 11y ago
  I believed the title and was disappointed. (I agree with your larger point though)
chris11 11y ago
So what's an effective way to learn to develop well engineered code? I'm at the point currently where I would not be able to predict how well a program will do running continuously.
- ksk 11y ago
  It might seem weak to not have a good alternate solution when criticizing someones attempt at one, but I don't have a ready answer. Well, okay so I'll try and give you advice anyway :P What kind of program is it? Is it a library, console/gui app? Does it have a variable workload? What are the ways in which people interact with the code? Is it primarily a desktop or server side application? What kind of test framework do you have in place? Do you have any instrumentation that would allow you to generate code coverage numbers? Can you run fault injection/fuzzing/etc type testing on it? Is the program resource limited? If so, do you have a CPU/Mem budget that you regularly check against? How many libraries does your program interact with? Do you keep track and test those libraries for failures? Do you try to freeze third party library/SDKs to minimize external bugs harming your own software's reliability? Do you always hard-crash at every bug or do you need to keep the software limping along till shit really hits the fan? Do you regularly (when there is no bug to track) run your software under a debugger to get a good feel for what the call stack, arguments, etc look like in a practical scenario (so that you can train yourself to catch it when things seem out of place). Its a lot about asking yourself what your blind spots are. Sometimes you have to think super-practically and just "look at the bits" and sometimes you have to try to see the forest. It all depends on what you're doing. And sure experience is a mean teacher. Nothing like getting a call at midnight and someone asking you why your embedded code running on-site in another state isn't working right after 5 months of no issues :P
- sitkack 11y ago
  Typing on tablet, apologies for terseness. * simple machines * highly regular, not littered with corner cases * state isolation, fast and easy to restart * linguistically and semantically simple The affordances of Erlang are a good starting point, as they encourage simple machines with isolated state while the language lacks the ability paint oneself into a corner semantically.

by ksk 11y ago

rafaquintanilha 11y ago

Apples vs oranges comparison. Nobody creates vaccines alone and from scratch, neither big and reliable software. It's clear for me that the author states a way to getting things done. It wasn't a tutorial in "how to become a pro in everything in only 5 minutes".

ksk 11y ago
I believed the title and was disappointed. (I agree with your larger point though)

chris11 11y ago

So what's an effective way to learn to develop well engineered code? I'm at the point currently where I would not be able to predict how well a program will do running continuously.

ksk 11y ago
It might seem weak to not have a good alternate solution when criticizing someones attempt at one, but I don't have a ready answer. Well, okay so I'll try and give you advice anyway :P What kind of program is it? Is it a library, console/gui app? Does it have a variable workload? What are the ways in which people interact with the code? Is it primarily a desktop or server side application? What kind of test framework do you have in place? Do you have any instrumentation that would allow you to generate code coverage numbers? Can you run fault injection/fuzzing/etc type testing on it? Is the program resource limited? If so, do you have a CPU/Mem budget that you regularly check against? How many libraries does your program interact with? Do you keep track and test those libraries for failures? Do you try to freeze third party library/SDKs to minimize external bugs harming your own software's reliability? Do you always hard-crash at every bug or do you need to keep the software limping along till shit really hits the fan? Do you regularly (when there is no bug to track) run your software under a debugger to get a good feel for what the call stack, arguments, etc look like in a practical scenario (so that you can train yourself to catch it when things seem out of place). Its a lot about asking yourself what your blind spots are. Sometimes you have to think super-practically and just "look at the bits" and sometimes you have to try to see the forest. It all depends on what you're doing. And sure experience is a mean teacher. Nothing like getting a call at midnight and someone asking you why your embedded code running on-site in another state isn't working right after 5 months of no issues :P
sitkack 11y ago
Typing on tablet, apologies for terseness. * simple machines * highly regular, not littered with corner cases * state isolation, fast and easy to restart * linguistically and semantically simple The affordances of Erlang are a good starting point, as they encourage simple machines with isolated state while the language lacks the ability paint oneself into a corner semantically.