Denial of Senses
-
@cvi said in Denial of Senses:
The latter also includes being able to understand a problem/spec
And understanding the spec often involves a large dose of clairvoyance to figure out what the spec is actually intended to achieve versus the literal words, which may be utter nonsense.
-
@HardwareGeek That's the thing with computers: you have to make absolutely everything explicit (even if it is by using someone else's explicit instructions). Unlike pretty much every other field of human endeavour — with the possible exception of setting up a bureaucracy — you can't leave stuff out and have the system guess. You can have defaults and libraries and so on, but you can't just leave a void of nothing and expect stuff to work because it won't.
-
@dkf said in Denial of Senses:
@HardwareGeek That's the thing with computers: you have to make absolutely everything explicit (even if it is by using someone else's explicit instructions). Unlike pretty much every other field of human endeavour — with the possible exception of setting up a bureaucracy — you can't leave stuff out and have the system guess. You can have defaults and libraries and so on, but you can't just leave a void of nothing and expect stuff to work because it won't.
Sort of.
Everything that you wrote is absolutely true of computers, don't get me wrong.
But thinking through a problem algorithmically, and then writing sufficiently detailed/explicit instructions, and how to recognize gaps in instructions and places where they are vague, is a useful skill in other endeavors as well.
It's probably possible to teach this skill to schoolchildren by having them do computer programming exercises.
But then thing you're teaching them isn't "programming" in the sense that most people understand the term, and certainly not in the sense that the article means when it claims to refute that "programming is hard."
Ironically, algorithmic thinking is the hardest part of being a software engineer. It's certainly harder than actually programming.
-
@dcon said in Denial of Senses:
@Steve_The_Cynic said in Denial of Senses:
She couldn't find the icon for the email app on her smartphone because she couldn't remember what colour it was.
In her defense, it's likely an update changed the color! Graphic designers gotta graphic.
And yet the email app on my iPhone has been a white envelope on a blue square for as long as I can remember.
-
@GuyWhoKilledBear said in Denial of Senses:
But thinking through a problem algorithmically, and then writing sufficiently detailed/explicit instructions, and how to recognize gaps in instructions and places where they are vague, is a useful skill in other endeavors as well.
It's probably possible to teach this skill to schoolchildren by having them do computer programming exercises.
But then thing you're teaching them isn't "programming" in the sense that most people understand the term, and certainly not in the sense that the article means when it claims to refute that "programming is hard."
Ironically, algorithmic thinking is the hardest part of being a software engineer. It's certainly harder than actually programming.
This! Exactly this!
Coding is relatively easy, once you catch on to the syntax of the language you are working in. Most languages follow common paradigms, with minor variations as to syntax. If you can express an algorithm, you can code it. The hard part is in expressing that algorithm.
There's a vast difference between what people now call "programming" (but I would call "coding") and programming of old: we oldsters were, by circumstance and lack of the all-helpful toolkits now available, forced to learn how to think through a problem "algorithmically".
-
@toodle said in Denial of Senses:
@GuyWhoKilledBear said in Denial of Senses:
But thinking through a problem algorithmically, and then writing sufficiently detailed/explicit instructions, and how to recognize gaps in instructions and places where they are vague, is a useful skill in other endeavors as well.
It's probably possible to teach this skill to schoolchildren by having them do computer programming exercises.
But then thing you're teaching them isn't "programming" in the sense that most people understand the term, and certainly not in the sense that the article means when it claims to refute that "programming is hard."
Ironically, algorithmic thinking is the hardest part of being a software engineer. It's certainly harder than actually programming.
This! Exactly this!
Coding is relatively easy, once you catch on to the syntax of the language you are working in. Most languages follow common paradigms, with minor variations as to syntax. If you can express an algorithm, you can code it. The hard part is in expressing that algorithm.
There's a vast difference between what people now call "programming" (but I would call "coding") and programming of old: we oldsters were, by circumstance and lack of the all-helpful toolkits now available, forced to learn how to think through a problem "algorithmically".
When I write actual code, which my job doesn't require me to do very often, I use a super modern toolkit to do it.
Even with the modern tooling, it's just not gonna work unless you think through the program algorithmically.
Also, most of the stuff I do doesn't have a hard requirement for thinking through problems algorithmically, but it certainly works better than the bullshit a lot of other people do.
-
@GuyWhoKilledBear said in Denial of Senses:
most of the stuff I do doesn't have a hard requirement for thinking through problems algorithmically
I find most problems yield most easily to thinking mainly about what information needs to be where and when it needs to move. That drives data structures, algorithms, message patterns, the lot.
-
@GuyWhoKilledBear said in Denial of Senses:
Ironically, algorithmic thinking is the hardest part of being a software engineer. It's certainly harder than actually programming[dubious - discuss].
It depends.
Sometimes 90% of the job is designing the algorithm, and programming it is a piece of cake.
Sometimes the solution is pretty simple on paper, but 90% of the job is making it work in practice within the constraints you have (limited resources, not breaking backwards compatibility, brain-dead environments, and the myriad of other obstacles of Real Life™).It's like the old "once you have the physics figured out, engineering is trivial" fallacy.
-
@Zerosquare said in Denial of Senses:
@GuyWhoKilledBear said in Denial of Senses:
Ironically, algorithmic thinking is the hardest part of being a software engineer. It's certainly harder than actually programming[dubious - discuss].
It depends.
Sometimes 90% of the job is designing the algorithm, and programming it is a piece of cake.
Sometimes the solution is pretty simple on paper, but 90% of the job is making it work in practice within the constraints you have (limited resources, not breaking backwards compatibility, brain-dead environments, and the myriad of other obstacles of Real Life™).It's like the old "once you have the physics figured out, engineering is trivial" fallacy.
I guess I consider "selecting the algorithm that will work within your constraints" to be part of designing the program rather than part of writing it.
Selecting the algorithm that will work within your constraints isn't something that's affected by what language you're using because any Turing-complete language can express any algorithm to the processor.
The article that we're supposedly talking about, and that I wrote that statement about, is about how learning a programming language is hard, not learning the programming mindset of algorithmic thinking.
-
@GuyWhoKilledBear To a point, I guess.
We all know programming is inherently multi-discipline - there is the act of solving the problems ("programming") and there is the act of writing the implementation ("coding"). These both have sub-disciplines attached to them, one (or more) of which is fluency in a language in which to express a given solution.
As far as I interpret it, the article seems to start by pretending the two sets of challenges and disciplines are the same one and then asserting that moving away from 'character based language' to, for example, block based programming or low-/no-code paradigms makes programming easier.
There may even be some truth to this. It can absolutely be easier to visualise the algorithmic steps required in this fashion - for more trivial complexities of problem. And I'd suggest that for non-veterans, having a more visual style of describing the operations could absolutely be clearer to demonstrate what is going on.
Again, allow me to refer to Human Resource Machine. I'd absolutely encourage people who want to get into programming to give it a go because it does a great job of providing a set of slightly-absurd problems in a context that you can solve with a very visual solver where each step you take in your 'program' is dramatically visualised by a person actually doing the steps in your list of instructions.
That all said, I don't think the article's contention that 'programming is hard' is supported by the arguments it's trying to make. Programming can be hard when you're trying to juggle things that are inherently complex, and this is often overlooked by such proponents and advocates.
I cannot for the life of me imagine writing some of the things I've written in a block-based programming environment with coloured labels and so on. Past a certain non-trivial level of complexity these solutions just do not scale well.
Do I think that BBP/low-code/no-code solutions can be useful? Yes, provided one understands their limitations. They solve the same level of problem as Excel solves in lieu of a database; when you don't need the full power of a proper grown-up database with locks and relations and just need a simple table with filtering.
The sort of things you can wire up in Power Automate, or IFTTT or other similar systems are fantastic for some classes of problem - and if that's all you need, great, have fun, use it, go solve your problems. And as an introduction to the actually hard stuff again, sure, absolutely.
We have not figured out how to teach computer science. It is no surprise that the people who thrive are the people who, to at least some degree, figured this shit out for themselves.
I think BBP and its friends have a place in teaching the theory, teaching some of the dynamics of solving problems - which is the one set of critical skills not being taught. How to break a problem down into pieces you can actually tackle is not something we teach though perhaps we should figure out how to teach it.
But what the article fails to demonstrate that is programming is 'not always hard'. Some of the things we implement are hard and no amount of BBP or magical thinking is going to change that.
Anyone who thinks programming is easy should go play TIS-100 and get back to me.
-
Wanted to post about it in status thread but it seems relevant here right now. I spent part of yesterday evening and the entirety of today morning creating a drag-and-drop component in Unity. It took me about 8 hours in total (it's relatively simple yet very configurable and handles all possible edge cases). I started with absolutely no plan, so half the time was spent on figuring out what I want to do exactly. The other half was spent entirely on learning Unity and its idiotsyncracies (note that I did have some prior experience). I'm still not entirely sure how colliders work (or rather, when they don't work).
Of course immediately after finishing I've had several ideas how to make it even better and simpler. So I'll keep rewriting it some more.
-
@GuyWhoKilledBear said in Denial of Senses:
Selecting the algorithm that will work within your constraints isn't something that's affected by what language you're using because any Turing-complete language can express any algorithm to the processor.
Okay. Let's assume that you're using an interpreted language that's pretty slow and limited, but has a few built-in functions (written in native code) that have decent performance.
Do you:
- pick the mathematically-best algorithm and reimplement everything from scratch, or
- start with "hmm, can I leverage those built-in functions to solve my problem?".
On paper, option 2) is suboptimal.
In practice, option 2) can be both easier to write and have better performance for all cases you expect to handle.(I've probably been
ed while writing this post)
-
@Zerosquare said in Denial of Senses:
@GuyWhoKilledBear said in Denial of Senses:
Selecting the algorithm that will work within your constraints isn't something that's affected by what language you're using because any Turing-complete language can express any algorithm to the processor.
Okay. Let's assume that you're using an interpreted language that's pretty slow and limited, but has a few built-in functions (written in native code) that have decent performance.
Do you:
- pick the mathematically-best algorithm and reimplement everything from scratch, or
- start with "hmm, can I leverage those built-in functions to solve my problem?".
On paper, option 2) is suboptimal.
In practice, option 2) can be both easier to write and have better performance for all cases you expect to handle.(I've probably been
ed while writing this post)#2. Duh.
If one of the constraints/targets is that you're doing this professionally and you want to take all reasonable steps to maximize profit, you can decrease the cost of writing the program by using the prewritten/pretested implementation that comes in your standard library or whatever.
The wisdom of why to use the prewritten components in the library isn't usually taught in "learning to code" classes that this article is talking about.
-
@GuyWhoKilledBear said in Denial of Senses:
The wisdom of why to use the prewritten components in the library isn't usually taught in "learning to code" classes that this article is talking about.
No, what it teaches is to rely on other people to have done the hard work of implementing them so you don't have to.
Here's the comedy: for the web world, this is already surprisingly true, that there's libraries and helpers and things for most things, so that you're really doing almost block based programming, or in this case gluing APIs of libraries and frameworks together.
I've seen the people this paradigm produces: people that can deliver some business needs - but for anything complex they have no idea where to start if there isn't a library that's already fairly close to what they want, because they weren't taught how to think through it enough to get there themselves.
-
@Arantor said in Denial of Senses:
@GuyWhoKilledBear To a point, I guess.
We all know programming is inherently multi-discipline - there is the act of solving the problems ("programming") and there is the act of writing the implementation ("coding"). These both have sub-disciplines attached to them, one (or more) of which is fluency in a language in which to express a given solution.
As far as I interpret it, the article seems to start by pretending the two sets of challenges and disciplines are the same one and then asserting that moving away from 'character based language' to, for example, block based programming or low-/no-code paradigms makes programming easier.
There may even be some truth to this. It can absolutely be easier to visualise the algorithmic steps required in this fashion - for more trivial complexities of problem. And I'd suggest that for non-veterans, having a more visual style of describing the operations could absolutely be clearer to demonstrate what is going on.
Again, allow me to refer to Human Resource Machine. I'd absolutely encourage people who want to get into programming to give it a go because it does a great job of providing a set of slightly-absurd problems in a context that you can solve with a very visual solver where each step you take in your 'program' is dramatically visualised by a person actually doing the steps in your list of instructions.
That all said, I don't think the article's contention that 'programming is hard' is supported by the arguments it's trying to make. Programming can be hard when you're trying to juggle things that are inherently complex, and this is often overlooked by such proponents and advocates.
I cannot for the life of me imagine writing some of the things I've written in a block-based programming environment with coloured labels and so on. Past a certain non-trivial level of complexity these solutions just do not scale well.
Do I think that BBP/low-code/no-code solutions can be useful? Yes, provided one understands their limitations. They solve the same level of problem as Excel solves in lieu of a database; when you don't need the full power of a proper grown-up database with locks and relations and just need a simple table with filtering.
The sort of things you can wire up in Power Automate, or IFTTT or other similar systems are fantastic for some classes of problem - and if that's all you need, great, have fun, use it, go solve your problems. And as an introduction to the actually hard stuff again, sure, absolutely.
I'm with you on all this stuff. HRM isn't programming (in that it doesn't teach you a language) but it can be used to teach algorithmic thinking. The same is true, to an extent, of BBP and IFTTT.
In order to get a job as a software professional, you need both skills: algorithmic thinking and at least one language.
The article reads to me like they're combining the two skills, calling them "hard," then talking about new methods for teaching the easier of the two skills.
We have not figured out how to teach computer science. It is no surprise that the people who thrive are the people who, to at least some degree, figured this shit out for themselves.
I think the problem might be that it's called Computer Science.
Computer Science is the most popular major among software professionals who have college degrees. But what Computer Science actually is is specifically around designing algorithms and compilers and how computers work and how to push the state of the art ahead.
And while a basic level of knowledge of that is necessary, most people who do this for a living are using well established principles to create custom software that solves whatever business problem their client is paying them to solve rather than pushing the state of the art forward.
For most people, the job is a kind of engineering rather than a kind of science or math. But because it's called computer science, it's taught the way you teach science or math.
I think BBP and its friends have a place in teaching the theory, teaching some of the dynamics of solving problems - which is the one set of critical skills not being taught. How to break a problem down into pieces you can actually tackle is not something we teach though perhaps we should figure out how to teach it.
But what the article fails to demonstrate that is programming is 'not always hard'. Some of the things we implement are hard and no amount of BBP or magical thinking is going to change that.
It's not always hard in that there are some easy problems that people get paid to solve.
But your actual point is correct. There are some software problems that can't be reduced to a form where they're easy. Those problems are always hard, and they're always going to be hard.
The only way to solve them is to teach people how to do hard things like think algorithmically.
-
@Arantor said in Denial of Senses:
@GuyWhoKilledBear said in Denial of Senses:
The wisdom of why to use the prewritten components in the library isn't usually taught in "learning to code" classes that this article is talking about.
No, what it teaches is to rely on other people to have done the hard work of implementing them so you don't have to.
Here's the comedy: for the web world, this is already surprisingly true, that there's libraries and helpers and things for most things, so that you're really doing almost block based programming, or in this case gluing APIs of libraries and frameworks together.
I've seen the people this paradigm produces: people that can deliver some business needs - but for anything complex they have no idea where to start if there isn't a library that's already fairly close to what they want, because they weren't taught how to think through it enough to get there themselves.
Sure, there's a bell curve of people who are good at it and people who are bad at it.
But in the other hand, vanishingly few companies have anyone on staff capable of hand-rolling an encryption algorithm properly.
-
Again that's on a bell curve. Encryption is hard. It's a level of hard most people can't deal with - but I don't see a problem with that.
I'm not advocating that we shouldn't use libraries etc. if stable, mature ones exist for the task at hand and that do the job. Encryption is absolutely one of those fields where it's best left to the people who do understand the math (or, at least, can accurately and correct implement the algorithm that people who understand the math have invented).
I'm just outlining that over in web land we have a scary-high proportion of people who don't have CS qualifications (like me, I hold the equivalent of a high-school diploma in it, not a formal degree), and the reality is that over in web land most things are hacked together by people who don't really understand how it works.
I don't mean that they don't get how, say, memory allocation works. I mean 'they're building on a framework and if the framework doesn't react how the manual says, they have no idea how to deal with that unless the answer is to be found on Google'. These libraries and tools might as well be complete black boxes to such people.
And you'll note I'm not suggesting that encryption to pick a task is a black box, I'm talking about more fundamental stuff where you're trying to use a framework feature and it isn't behaving and you don't know if it's you doing it wrong or the library not working as intended. These people apparently cannot reason their way forward with this if the answer isn't worked out by someone else.
And this is the next generation of programmer.
-
@Zerosquare said in Denial of Senses:
@GuyWhoKilledBear said in Denial of Senses:
Selecting the algorithm that will work within your constraints isn't something that's affected by what language you're using because any Turing-complete language can express any algorithm to the processor.
Okay. Let's assume that you're using an interpreted language that's pretty slow and limited, but has a few built-in functions (written in native code) that have decent performance.
Do you:
- pick the mathematically-best algorithm and reimplement everything from scratch, or
- start with "hmm, can I leverage those built-in functions to solve my problem?".
On paper, option 2) is suboptimal.
In practice, option 2) can be both easier to write and have better performance for all cases you expect to handle.I used to work in a language where there was only one container type available and this container lacked a remove method. You could only add more elements. We worked around it by creating a utility function that created a new list and copied every element except the one that's supposed to be removed.
What makes it even sadder is that this language is an ISO standard.
-
@Arantor said in Denial of Senses:
I'm just outlining that over in web land we have a scary-high proportion of people who don't have CS qualifications (like me, I hold the equivalent of a high-school diploma in it, not a formal degree), and the reality is that over in web land most things are hacked together by people who don't really understand how it works.
I don't think there's too much of a correlation between those with CS qualifications (fair warning--I'm entirely self-taught; my degrees are in physics and the only formal training I had was in Matlab and LabView, and that was 15 years ago and extremely cursory) and those who know what's really going on in a way that matters.
From what I see and hear, CS curricula are great...if you're going to be a professor of CS or someone doing bare-metal (or close-to-it) algorithm design. But that's not what people need, and often that kind of specialization gets in the way of figuring out how to solve real problems (in much the same way that a deep physics training interferes with the ability to do practical engineering--overthinking the problem is a real danger) in ways that make any kind of business sense.
I saw this while teaching high-school-level programming (at a very intro level). Some people intuitively caught on to how to break down problems and figure stuff out by hacking around and poking at the black box and figuring out how to make it dance; others, equally intelligent and probably better educated were entirely stumped. It's a mindset, and it's a mindset that's really hard to teach.
-
@Benjamin-Hall said in Denial of Senses:
From what I see and hear, CS curricula are great...if you're going to be a professor of CS or someone doing bare-metal (or close-to-it) algorithm design. But that's not what people need, and often that kind of specialization gets in the way of figuring out how to solve real problems (in much the same way that a deep physics training interferes with the ability to do practical engineering--overthinking the problem is a real danger) in ways that make any kind of business sense.
In my college, the curriculum was IMO well-rounded between theory and practice, low- and high-level, academic purity and real-world-y bullshit. It also touched on several subjects that aren't directly related to programming but still good to know when working with computers. We had 2 or 3 courses that were entirely about project management and shit. That was only a few years ago, so fairly current experience. On the other hand, it was in Poland and we had nearly zero choice in picking our courses. I know this last part makes it not apply to USA and many other western countries where students have great freedom to pick and choose classes they like. I believe that may greatly upset the balance between the fun and the practically useful courses in one's education.
-
@Gąska It may be my very strong and entrenched bias, but I'd be very willing to believe that Polish universities actually realize that there is a universe outside of academia. I have no such illusions about US ones. At least most of them.
-
@Benjamin-Hall I can assure you half of my professors wouldn't survive a day outside the campus. The other half weren't actually professors. With a few notable exceptions in both groups.
The most annoying thing about college was how super pedantic the teachers were about using proper titles - we had to start every email with Honorable Mr. Professor for professors and Honorable Mr. Doctor for PhDs. Absolutely ungooglable and your passing grade hinged on getting it right.
-
@Gąska said in Denial of Senses:
@Benjamin-Hall I can assure you half of my professors wouldn't survive a day outside the campus. The other half weren't actually professors. With a few notable exceptions in both groups.
Compared to the equivalent at most hoity-toity US universities, where that number would be 98%? Ok, I'm biased. Academia should be burned to the ground, all the professors forced to find real jobs, and a new system built. Somewhere else. After salting the metaphorical ground that the former system was built on. Did I mention I'm biased?
The most annoying thing about college was how super pedantic the teachers were about using proper titles - prefacing every email with Honorable Mr. Professor for professors and Honorable Mr. Doctor for doctors. Absolutely ungooglable and your passing grade hinged on getting it right.
Tell me about it. The hair splitting about whether someone was a full professor, just an adjunct, or an assistant professor, etc was extremely tiresome. As a teacher, I only pulled the "PhD card" when parents were getting pushy or annoying. And as a TA, kids would call me Professor. Meh.
I found the tendency of most professors to believe that students were obviously only taking their class, so any amount of homework, deadlines, etc was acceptable to be obnoxious as well. But to be honest, school was easy. Yes, even up through grad school. I only learned how to study in about my second year of grad school. Which is something I've had cause to regret later--it's made it harder for me to persist at things that are annoying and difficult.
-
@Benjamin-Hall said in Denial of Senses:
And as a TA, kids would call me Professor. Meh.
I've had a couple teachers in high school who insisted on being called professors. Because that's how things were 50 years ago or something. Mofos didn't even try to get PhD, and only got Master's because the law requires it for raises.
-
@Gąska that's stupid. My line as a teacher was
You can call me Mr Hall, Dr Hall, or Dr Evil (because I'm both a PhD and evil). Just don't call me Mr Evil.
-
@Benjamin-Hall said in Denial of Senses:
From what I see and hear, CS curricula are great...if you're going to be a professor of CS or someone doing bare-metal (or close-to-it) algorithm design.
It varies a lot, especially if you have a global perspective. I think one of the marks of a good course is that it doesn't just talk about theory, but also about the ways in which just theory isn't enough, and about methods of dealing with that. You know, the things that mark the area out as not just a branch of Math but an Engineering discipline (with a wildly unusual cost profile, which explains the odd habits of software engineers relative to mechanical or civil engineers).
Also, there's not a lot of call for algorithm design these days, and most of that is in rather specialized areas. Algorithmic understanding is useful for all but the most basic programming, but actually developing new algorithms is just not that common; working programmers are much more likely to use something existing than make a new way of doing things. (It helps that things like searching and sorting are almost completely understood.)
-
@Gąska said in Denial of Senses:
What makes it even sadder is that this language is an ISO standard.
Don't be shy with the details...which one? So we know to avoid it.
-
@CodeJunkie TTCN-3. And since it's ISO standard for protocol validation, if you hear it, you can't avoid it since you're legally forced to use it. Thankfully, AFAIK it's only used in telecom industry.
-
@Gąska said in Denial of Senses:
@CodeJunkie TTCN-3. And since it's ISO standard for protocol validation, if you hear it, you can't avoid it since you're legally forced to use it. Thankfully, AFAIK it's only used in telecom industry.
Ha, the telecom industry...of course.
-
@Gąska said in Denial of Senses:
The most annoying thing about college was how super pedantic the teachers were about using proper titles - we had to start every email with Honorable Mr. Professor for professors and Honorable Mr. Doctor for PhDs. Absolutely ungooglable and your passing grade hinged on getting it right.
I called them by first name... Well, at least as a grad student.
@Benjamin-Hall said in Denial of Senses:
You can call me Mr Hall, Dr Hall, or Dr Evil (because I'm both a PhD and evil). Just don't call me Mr Evil.
-
Coming from a C background, for a long time I had been a proponent of "teach by reinventing the wheel". By now I've amended that to "First and foremost teach with the existing library wheels. Then as an exercise teach how to make one."
-
@Medinoc That's how many research projects work too. They start with a lot of time spent redoing existing work with an updated method, and then towards the end they push with that method into doing novel stuff with the now-validated method they've developed.
-
@dkf said in Denial of Senses:
@Medinoc That's how many research projects work too. They start with a lot of time spent redoing existing work with an updated method, and then towards the end they push with that method into doing novel stuff with the now-validated method they've developed.
That sounds like the reverse: First reinvent the wheel, then prove it's just as good as the wheels you've used in the past.
-
@Gąska said in Denial of Senses:
@CodeJunkie TTCN-3. And since it's ISO standard for protocol validation, if you hear it, you can't avoid it since you're legally forced to use it. Thankfully, AFAIK it's only used in telecom industry.
I just had an evil idea... Building something serious out of TTCN, and make the crime against humanity spread further. But it'd destroy what little if my mind that is left.
Nah, I don't need to become an alcoholic..
-
@PleegWat said in Denial of Senses:
First reinvent the wheel, then prove it's just as good as the wheels you've used in the past.
Usually you're trying to make a better wheel that can turn a few degrees further before falling apart.
