|
There is also a patent on saving what's displayed on a screen before overlaying it, so that it can be easily restored without redrawing what was there before.
This kind of thing is why I think all software patents should be cancelled and replaced by copyrights.
|
|
|
|
|
Thankfully having a patent and upholding it aren't the same thing. There certainly are lots of patents granted in the past that certainly wouldn't be granted today, and some patents have also been reversed as upholding them would stifle entire industries.
|
|
|
|
|
|
Specially the last paragraph   
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Experience tells me building an API is often more work than building the guts. And it often involves more creativity.
Now, do I want to preclude someone being able to assert a copyright over something that is unique and imbued with creativity and a lot of work? Gotta say "no".
One good thing might come out of this: Licenses should cover implementation and API as separate items.
|
|
|
|
|
sorry if this dates me too much, but I kind of miss the pre-internet days working as a dev.
Technology didn't move that fast, a new compiler would be available every great once in awhile. You could keep most libraries in your head because they rarely ever changed. Most of the time you were only limited by imagination and memory (ram).
So you would subscribe to any tech magazine to get the latest info. there would be code samples of something clever, articles on the pitfalls of a language feature, or work progress of getting a new complier up and running.
My shelves were packed with any books I could get ahold of and every magazine that had something interesting.
The internet is the first tool I have to reach for now. there is just soo much to know and it's almost impossible to keep it all in your head. For me to remain a dev until retirement is going to be a stretch, so I'm thinking of going into education to tech software development.
I've notice that many of the younger devs out there can slap something together that works, but don't any have the fundamentals on how any of it works underneath: they can put gas in the car, but have no idea what's under the hood that makes it go, and that bothers me.
any other gray beards out there seeing the same thing?
|
|
|
|
|
I definitely see this going on, but I think a lot of new devs know they are missing out on things too.
I have here Jeff Prosise's great book, Programming Windows with MFC and it weighs in at over 1200 pages.
I also have the Petzold Programming Windows 95 and it is around that length also.
But, the Internet has ruined strong focus. Read the book, The Shallows: What the Internet is doing to our brains[^].
Petzold went into specifc details and you had to learn how things were really built up.
But a lot of people didn't like that. It is somewhat of the Engineering Mindset.
Some people just want to get a thing working and forget about it. They want the end result.
Others (with Engineering Mindset) want to know exactly how things work.
I find that when I want a PRODUCT I want to get the thing working.
But most of the time I want to know exactly how the thing works. It's two different mindsets really.
|
|
|
|
|
thanks for the book recommendation, I just put that in my cart.
raddevus wrote: But most of the time I want to know exactly how the thing works. It's two different mindsets really.
I think you summed that up perfectly.
I worked for someone once that was the quickest person I've ever seen to refactor code, 1000's of lines of code in a day. It was garbage of course, he didn't know how to debug so everything was in a try/catch/fail -> send to log file. this code went in to production without ever testing locally, and he would wait for logs to appear, then change something upload to customer and watch the logs again. and again, and again.
Another had no idea what bit wise operations were and was confused on exactly what an integer was, let alone the size of integer and how much it could hold. But he was still putting Apps together.
[head shake]
|
|
|
|
|
|
Matt McGuire wrote: Another had no idea what bit wise operations were and was confused on exactly what an integer was, let alone the size of integer and how much it could hold. But he was still putting Apps together.
Yep, I've worked with the same kind of people.
We had a guy who didn't seem to know what a function was used for.
He had a bug in a for loop that was copy pasted into his code dozens of times. It failed in production when he was out of town and unavailable so we had to fix it. Had to search thru for dozens of instances of the bug and replace them. If it were wrapped in one function call...
Oy!
|
|
|
|
|
raddevus wrote: He had a bug in a for loop that was copy pasted into his code dozens of times. It failed in production when he was out of town and unavailable
I would hope that his boss contacted him, and told him not to bother coming back...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: I would hope that his boss contacted him, and told him not to bother coming back...
Boss didn't take action because this employee represented head-count to the boss and kept his Management Kingdom larger than if he started getting rid of people. 
|
|
|
|
|
A code review should have caught the duplication.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Matt Bond wrote: A code review should have caught the duplication.
Yes, but this was a long while ago now -- around 2000 -- and this particular place allowed developers to work autonomously. Each dev managed his/her own services.
That's good and bad, I know.
That was a great thing if you were apt to do it all and "own" your stuff.
This guy was not up for that though and it became obvious in production some time after midnight.
|
|
|
|
|
I'm with you on that. One of the things that I find frustrating with some so-called devs, is not that the lack the fundamentals, but they seem not to have any idea what to do if things go wrong. If their code does not run or throws an error they are incapable of doing some basic diagnosis. There have also been three questions posted here in the last few days from people who are trying to use third-party products. They don't know the product, or some part does not do what they want, so rather than going back where they got it from and asking people who would know, they post a question here. Similarly with homework questions under "what have I done", we see things like, "nothing because I don't know how to start". I just hope that all the developers who never post a question here are of a much higher calibre.
|
|
|
|
|
Yes, a sea change from the days when I used to debug in hex, over the phone.
Eliminating possible causes of a bug until, to steal a phrase, what remains must be the truth, requires the ability to think deductively, which is rooted in logic. In an age where emotions are treated like facts, the ability to debug this way is severely compromised.
|
|
|
|
|
I got a job after debugging by phone.
I was working in Germany using software from a company in the US. There was an intermittent bug that was driving us crazy and the company could not fix it. The president of the company had me describe the bug in detail to one of his developers so they "could better fix it". I ended up describing to him the steps it must have gone through and the kind of code it must be running at the point the bug came up - he found the appropriate code and I said something like:
"...and then it will have a pointer to a block that it constructs the message string in before adding the terminating null at the end of the string";
"Yes, there is a pointer for the message";
"Has it allocated enough memory for the block? Perhaps it didn't allow for the terminator.";
"Allocated memory?";
...at which point the problem was solved! The president had been listening in on the call and immediately offered me a job.
Ah, the good old days!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
|
Richard MacCutchan wrote: what have I done", we see things like, "nothing because I don't know how to start".
You are correct about many devs not being able to debug. It is probably why the ability to debug, or just get something going again when it is stuck, is probably the number one ability to look for in a dev.
- Brian W. Kernighan "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
|
|
|
|
|
|
DerekT-P wrote: we learned how to dismantle things!
I did much the same at home. Like you I did not always understand how the things worked but I did learn how to try and find out.
|
|
|
|
|
Funny. My uncle and some of his other retired buddies took over the science department at a private school. Labs include multi week disassembly of small 4 cycle engines, using long cables like jump ropes to detect Earth's magnetic field, etc. Sounds like a similar mindset.
|
|
|
|
|
My elder brother loved to dismantle things to see how they worked. 
I had to figure out how they worked so I could out them back together again - a skill my brother never quite got the hang of.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
My elder brother was too busy chasing skirt to care about the internal workings of any machine.
|
|
|
|
|
I dismantled a lot of things before I learned how to put them back together. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
