|
If you post an article with an code on screenshots - You do it wrong.
Those articles should never even be approved. Seriously. If I would have to type in, code from some place in a web, I would try to search something similar elsewhere with code you can actually copy.
Typing everything, to find out in the end that it does not even work, is just big waste of time. 
No more Mister Nice Guy... >: |
|
|
|
|
|
I agree with your sentiments and am glad to hear that one of the'fun' parts of days long past stays with us - namely, transforming images of text back into text only to find there's an error one is insufficiently skilled to locate.
I copied code from magazines page after page after dog-eared page, only to learn it was no good.
Patience training young-one, patience training. 
|
|
|
|
|
enhzflep wrote: Patience training
Do you think that putting my monitors or keyboard in danger of angry smashing, is good idea?
They are old not do not costs that much but I would rather keep them a little longer. 
No more Mister Nice Guy... >: |
|
|
|
|
|
n.podbielski wrote: Those articles should never even be approved
I'd be surprised if they do get approved. A line or 2 would be acceptable but huge chunks of imaged code would really piss me off.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
They do get approved. I saw at least two. From the same author
I noticed this particular one (funny it was best Web article of October; I think this was version pending for approval, when I see it for fist time). I do not read a lot of articles on CP (I know... I know... ) Maybe there are more, maybe not.
No more Mister Nice Guy... >: |
|
|
|
|
|
I suspect the authors do that to force you to download their zips (ack!) or make you follow a link to their blog to get the copy paste (ack!)
|
|
|
|
|
lol, that so true. Don't know why some people do that. If they don't want people to use the code better as well not post it. rubbish !!!
Bryian Tan
|
|
|
|
|
In the old days, before "open source" became fashionable, more or less free access to the source code of, say, the OS was not that uncommon. The Universiy where I got my M.Sci. had the OS for the Univac 1100 mainframe delivered as assembly code (noone thought of writing an OS in a high level language in those days). My first job was with a company making an OS that couldn't link in drivers dynamically, so the manufacturer had to tailor make (essentially, do the static linking of) the OS for each hardware configuration. The machine was shipped with a printout of the entire OS source code for that configuration.
A friend of mine was developing some medical equipment, writing the drivers for it. For every small change to the drivers he had to go to the computer manufacturer to have a new OS with the new driver linked in. So he asked if they would give him a machine readable copy of his OS. "Sorry, that is against our policy. But you've got the printout, haven't you? Why don't you type it in from that?" ... and he did. He typed in the entire source code for the entire OS (although limited to the OS modules linked in his configuration).
So I think noone should complain about having to type in a few screenfuls of code...
|
|
|
|
|
So if your friend lived through hell and was able to tell about it, others should too?
No more Mister Nice Guy... >: |
|
|
|
|
|
It earned him a job at with the computer manufacturer, when he decided that the Universty research center didn't pay him well enough... He ended up as one of the two super-gurus in the OS development group, very highly respected.
Which gives me an excuse for telling another story about him: I once detected a reproducible bug that crashed the OS, which I reported to him. He pulled out his printout of the OS source code and sat for fifteen minutes flipping pages back and forth, mumbelign to himself. Then he grabbed a pen and wrote a couple numeric values into the printout. "OK, you'll have it fixed next time you upgrade your OS".
The numeric values where the fix. He didn't write down the fix in the mid-level language of the OS (sort of like plain C). With some experience, you know which machine instructions the compiler will generate, but he didn't write down the assembly instructions. He wrote down the numeric codes for those machine instructions, so that he could poke them directly into the kernel memory of his development machine, while it was running, to verify that they had the desired effect.
You won't find many persons like that in the software houses of today!
|
|
|
|
|
I know how this works, but yeah I am the lazy one and never bothered to even try to remember those values.
Seems like his cool guy. Maybe we would paste some code images on CP
No more Mister Nice Guy... >: |
|
|
|
|
|
Member 7989122 wrote: You won't find many persons like that in the software houses of today!
I think you may mean there is little need for that level of intimacy with the OS these days. There are certainly a large group of people have a really deep knowledge of their chosen technology.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Sure - you can't expect everyone to know all the bottom level of all sorts of technology. Like, I know nothing of the theory of transistor technology - I can explain how an instruction code is decoded into signals to each logic unit of the CPU, but nothing below that.
But: Many years ago, I learned one rule: As a minimum, understand what's going on (at least) one level below the one you're working at yourself. When you ask for a service, you should always understand what needs to be done to provide that service, even if you don't have to implement it. Maybe the implementation you make use of do the details different from what you think, but you should know how the task could be done. You need to know that to make the right service request.
The opposite approach is the "just in time" knowledge. When a question is raised, google the answer (or look it up in Wikipedia), read the answer out loud, and forget it. No need to learn or understand; you can look it up a second time if you need it a second time.
My impression is that modern IT education covers so many sub-fields, has such a broad scope, that there is never the time to learn anything that's "not necessary" to know. You learn what to do, but not why that is the right thing to do. Lots of the newly-educated people have learned a lot of things that we never heard about when I was a student. Much too often, difficult problems are solved more or less by trial and error, and when it "works" (sort of), they believe they have found the "right" solution. Until I, or some other oldguy, explains to them what really happens when an external interrupt signal is processed. Or how overloading is realized. Or why most OO-systems are incapable of redefining a method at the instance level. Or ...
Even expertice can be skin deep. While I think Google and Wikipedia are great tools, they do corroborate the "Just in time" idea, rather than the "deep level of understanding" idea. Too often, broad but shallow knowledge (which certainly has its merits - but different ones!) are mistaken for being deep knowledge.
|
|
|
|
|
The irony to that is, when I write apps in FlowSharpCode, yeah, there's code behind the images, but it's actually the images (meaning shapes) that are more important than the code, as they organization of the shapes describes what's actually important about the code -- the flow, loops, decisions, etc.
So it's something I've been wondering about -- will people be annoyed when I write articles about FlowSharpCode which are screenshots of the shapes and their code-behind!
Marc
|
|
|
|
|
agree
|
|
|
|
|
"References to CLstCtrl" and "BACON".
No article is perfect without them.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
And no reference to the welsh rugby team either...(or sheep!)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
