New Generation does not realy understand computers
-
We had occasion of late to write a small interpreter, complete with expression evaluation, i.e. a RPN Stack. These things are mostly already hidden inside the nuts and bolts of compilers and interpretors. Meet a Custom Stack, and, No, You have to write your own! We advertised a position for an MFC/CPP Program writer, with learning experience of MFC and the general Windows Interface. None of our fifteen contestants knew how to scan an input file, never mind how to parse one. All passed with glowing terms in the various MS Certification schemes. Why are the basics No longer taught! Regards
Bram van Kampen
-
I can't write an MFC application :sigh: I tried many years ago, and maybe I was spoiled by NeXT / ObjectiveC at the time (and then later Java) but I found it way too difficult! :(( Maybe I should try again, the maturity will help perhaps?!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
MFC is way harder than it should be. I've come to the conclusion that it's mainly because the documentation is inadequate. Look up an MFC topic and the documentation you get is lacking in both depth and breadth. Much functionality isn't even discussed in the abbreviated documentation, and the context, i.e. HOW it's used is barely touched on in the simplistic example. One quick example: Using the documentation of CDC::CreateCompatibleDC () (http://msdn.microsoft.com/en-us/library/kwxzck32%28VS.80%29.aspx[^]), how do you use this to work with an 8-bit-per-pixel bitmap? THERE'S ABSOLUTELY NO CLUE! Sure, it's POSSIBLE, but it's a goddamn research project to do something that should only take a few minutes with adequate documentation. I find this to be true in general for Microsoft documentation.
-
We had occasion of late to write a small interpreter, complete with expression evaluation, i.e. a RPN Stack. These things are mostly already hidden inside the nuts and bolts of compilers and interpretors. Meet a Custom Stack, and, No, You have to write your own! We advertised a position for an MFC/CPP Program writer, with learning experience of MFC and the general Windows Interface. None of our fifteen contestants knew how to scan an input file, never mind how to parse one. All passed with glowing terms in the various MS Certification schemes. Why are the basics No longer taught! Regards
Bram van Kampen
Dude... the basics were never taught. Languages are taught - programming is not. It is an instinct, and some people are born with it and some people aren't. The problem you're seeing today is, it's possible for someone without the instinct, to just work really hard and get a CS degree - now they have degrees in subjects they really don't know... which only makes them the same as every other college grad out there. This isn't a new issue. In the 80s it was "why don't people know basic electronics" - what? You can't build a flip-flop multi-vibrator with these paper clips?!
-
Bram van Kampen wrote:
None of our fifteen contestants knew how to scan an input file, never mind how to parse one.
Is it fair to say none of these 15 have a CS degree from a decent CS program? Even the most basic course in compiler construction would require the student to create a parse tree for a formal language. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Everyone here, raise your hand if you even "..care.." about compiler construction. How many hands did you count? Me too, just you. If that is your cup of worms, try Microsoft, Borland, Google, and... .
-
Everyone here, raise your hand if you even "..care.." about compiler construction. How many hands did you count? Me too, just you. If that is your cup of worms, try Microsoft, Borland, Google, and... .
Ron Richins wrote:
if you even "..care.." about compiler construction
I think you may have missed the point. It's the same reason it's important to have studied the concepts of assembly language, although only a small percentage of folks program in it on a daily basis. The same goes for the subject of geometry. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I thought Windows Phone 7 only supported managed code (for now), that does not mean that MS will change their mind. Also, don't forget the negatives of MFC vs. managed. Bad pointers! memory leaks, etc. I did not think that MFC offered too much advantage over the native Windows API. I did prefer the message maps over the old giant switch statements, but you also payed a lot of over head for the map lookup.
Windows Phone 7 probably does. Too bad.
Know way too many languages... master of none!
-
Are MFC Applications that much faster to build than using the Win32 API? I have written a hand full (by hand full I mean 4 or 5) of MFC apps and would prefer the straight Win32 API. Perhaps I just haven't given MFC a chance. Course Win32 is just that Windows, but I didn't realize MFC could be compiled for other OSs.
No - I'm basically saying .Net - Last Choice, MFC - is at least Binary in the end. Direct using C++ or Pascal or whatever to get at Windows API itself? Preferred! :) Managed? Eh... Binary? Ya! :)
Know way too many languages... master of none!
-
Everyone here, raise your hand if you even "..care.." about compiler construction. How many hands did you count? Me too, just you. If that is your cup of worms, try Microsoft, Borland, Google, and... .
I spent 20 years writing & running various IT projects, using tools from various big name companies. They always had bugs (I anded up contacting the source developers of compilers, databases, GIS's, etc). Without a solid understanding of both OS & compiler theory, I would never have been able to identify the bugs, either for workarounds or to actually persuade the people that there was something wrong with their code. Did my bosses care? Well, I did keep getting projects, and raises, so I guess so.
-
MFC is way harder than it should be. I've come to the conclusion that it's mainly because the documentation is inadequate. Look up an MFC topic and the documentation you get is lacking in both depth and breadth. Much functionality isn't even discussed in the abbreviated documentation, and the context, i.e. HOW it's used is barely touched on in the simplistic example. One quick example: Using the documentation of CDC::CreateCompatibleDC () (http://msdn.microsoft.com/en-us/library/kwxzck32%28VS.80%29.aspx[^]), how do you use this to work with an 8-bit-per-pixel bitmap? THERE'S ABSOLUTELY NO CLUE! Sure, it's POSSIBLE, but it's a goddamn research project to do something that should only take a few minutes with adequate documentation. I find this to be true in general for Microsoft documentation.
WHS!
-
MFC is way harder than it should be. I've come to the conclusion that it's mainly because the documentation is inadequate. Look up an MFC topic and the documentation you get is lacking in both depth and breadth. Much functionality isn't even discussed in the abbreviated documentation, and the context, i.e. HOW it's used is barely touched on in the simplistic example. One quick example: Using the documentation of CDC::CreateCompatibleDC () (http://msdn.microsoft.com/en-us/library/kwxzck32%28VS.80%29.aspx[^]), how do you use this to work with an 8-bit-per-pixel bitmap? THERE'S ABSOLUTELY NO CLUE! Sure, it's POSSIBLE, but it's a goddamn research project to do something that should only take a few minutes with adequate documentation. I find this to be true in general for Microsoft documentation.
Visual C 6.0 had great documentation for MFC classes. After that, Visual Studio 7 had the most terrible help.