| General > General Technical Chat |
| I find "programming" a constant distraction from electronics in some "tutorials" |
| << < (10/10) |
| Nominal Animal:
--- Quote from: steviefaux on September 24, 2020, 04:09:53 pm ---So you ask How do I do A, I know I can do it other ways but how would I do it this way. And annoyingly get "You shouldn't be doing it that way you should be doing it this way blah blah". It's annoying. Just answer my question first then added "But, really you should be doing it this way". --- End quote --- In 97% of the cases of this I've seen (at SO and elsewhere), A is incorrect. If you were to ask me the question via e-mail, I'll answer the way you suggested (ie., the description of how to do A, followed by why it is the wrong way). On the web, on forums where you have dozens or hundreds of lurkers to each asker/answerer, doing that leads to misunderstanding and spreading false knowledge. That is why I for one won't do it in public; I'll always start with "No, that's the wrong way, because Z." It has very little to do with the asker, and a lot to do with those others who read the question and answer. The 3% of the cases are where the OP names the correct method, and gives a sane reason why they don't want/cannot do it that way. In 2% of cases, their belief is incorrect, and the reason they believe they cannot do it the correct way actually does not preclude them from doing it the right way, they just believe so for wrong reasons. The 1% of cases are nefarious (in programming, meaning intrusion or hacking attempts without any real-world use cases). In my experience (of a few tens of thousands of programming questions in the last decade), that leaves only an occasional exception to the rule. (I recall exactly two of such exceptions, both of which lead to a private e-mail exchange to solve the actual issue.) I claim that while this (not answering questions with incorrect A in public) may annoy you, overall it leads to a better world, and is therefore preferable. As to myself and teaching materials, I prefer modularity over a fixed lesson plan (or a "tutorial" video). Just like when giving a (good) presentation, you must tailor the content to best fit the audience. A good work log, in my opinion, would consist of a "tree" of content, with detail videos split into 1-2 minute clips. For those who want to view all the videos at once, one can provide a playlist. |
| Nominal Animal:
As a practical example of such an incorrect question, here is one that I once again encountered today: I need to implement a C function, that reads a file into memory. It works perfectly in Windows, but fails in Linux, BSDs, and Mac OS with character devices, FIFOS (named pipes), proc/sys pseudofiles, etc. How can I fix fseek() to work with character devices and FIFOs and pseudofiles? The answer is, you don't. You cannot. The entire approach is completely wrong. You cannot and should not expect to always know the exact size of your input beforehand; that is unrealistic in general. You can only determine it for static files (files not being modified concurrently). That approach may suffice in Windows because of its device/filesystem model, but it definitely does not suffice in most other operating systems. The correct answer is to simply read the incoming data into a dynamically allocated and reallocated buffer, until you either determine there is too much data to process, or you encounter EOF (end of input). Here is an example implementation written in ANSI/ISO C89 (with intent on understandability and maintainability, not efficiency). If you look at the above question, and its accepted answer, you'll see it implements the fseek()/lseek() approach, which is unreliable. (Not only will it fail for non-file filesystem objects like character devices, it will also fail if the file is modified or appended to while being read.) If everyone did like steviefaux demanded and just answered the question without pointing out the error in the question, we'd all still live in third world conditions, eating mud and slinging excrement at each other. |
| bsfeechannel:
--- Quote from: greenpossum on September 25, 2020, 05:36:12 am ---Ha, I turned on the universe at the big bang and it will blink out in a few tens of billion years. Top that. :-DD --- End quote --- OK, God. --- Quote from: rstofer on September 24, 2020, 09:38:11 pm ---We can do things with uCs that simply weren't possible 50 years ago --- End quote --- Yeah. We have to go with the times. Although I love old school electronics, in my computer I have for free now things that I could only dream of a few decades ago as it would have cost me an arm and a leg. And even though I can have them for cheap these days, now they're obsolete, I wouldn't (with a few exceptions) because they're cumbersome compared to what I can have with the modern technology. This trend of having programming alongside "pure" electronics is not new. Back in the 1970s, formal high school electronics education already included programming as part of the curriculum. |
| Navigation |
| Message Index |
| Previous page |