New Generation does not realy understand computers
-
Marc Clifton wrote:
Because MFC, .NET, Silverlight, Wxx, etc., are all supposed to do the thinking for you?
Those who think think to let others do the thinking for them. :rolleyes: Seriously, though, given that it's impossible to learn everything (our brains are surprisingly tiny), it seems wise to focus only on what will get the job done. Leaders delegate thinking to specialists and good programmers delegate low-level work to frameworks.
aspdotnetdev wrote:
our brains are surprisingly tiny
Speak for yourself! What's this "our"? ;P
-
Cool. Now save that code; and add it to your toolbox for the next go around. Knowing HOW is actually more important than doing it daily. At least that way regardless of the system you happen to be forced to work with - you understand the problem and know the basics of how to solve it. This is along the lines of software pattern recognition. Helps to know as many "patterns" as possible.
Know way too many languages... master of none!
I kind of give on MFC too! What's the point with all these beautiful C# API! :)
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.
-
I kind of give on MFC too! What's the point with all these beautiful C# API! :)
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 - Allows building applications that are truly binary; Binary Apps - Run Faster Binary Apps - More Secure Than Scripted Solutions Binary Apps - No Lag waiting for JUST-IN-TIME compiler to kick in. Natural Obfuscation of Source code.. Still reversable perhaps - but much more difficult as Assembly is what you get back; not C++ MFC - 3rd Party Vendors have C++ libraries for other popular OS that allows you to write MFC code that can be compiled for said OS's - .Net not far behind however MFC - Applications are faster, leaner, and highly flexible MFC - Applications have a small footprint and leverage code libraries that have been available on and for the os it self: Microsoft Windows - for many versions. MFC - Has a smaller footprint than .Net for infrastructure that would make for leaner and faster mobile phone applications on Microsoft mobile platforms - if they continue to support MFC that is. Just some thoughts on why bother...
Know way too many languages... master of none!
-
Because the
basicsas you call them are not required to build business applications which is where most developers are focused on (you can include me in that group). What surprises me is that you got 15 applicants (unless you went through an agency of course then 15 would seem low but the quality is about right).Never underestimate the power of human stupidity RAH
Agreed. For the vast majority of applications being developed, those "basics" are completely unnecessary, given that the languages in common use have all wrapped and encapsulated them to the point where you just call a few methods that do what 95% of applications need. I tend to agree that it's useful to know some of those basics, and even farther down the stack the OP brings up, but it's no longer essential, as it once might have been. Few people need to know how the registers on the CPU are used, virtually no one needs to know what happens when a read is made from a disk, and nobody really cares what the pin out is on a printer cable. We manage to produce value just the same.
Currently reading: "The Prince", by Nicolo Machiavelli
-
MFC - Allows building applications that are truly binary; Binary Apps - Run Faster Binary Apps - More Secure Than Scripted Solutions Binary Apps - No Lag waiting for JUST-IN-TIME compiler to kick in. Natural Obfuscation of Source code.. Still reversable perhaps - but much more difficult as Assembly is what you get back; not C++ MFC - 3rd Party Vendors have C++ libraries for other popular OS that allows you to write MFC code that can be compiled for said OS's - .Net not far behind however MFC - Applications are faster, leaner, and highly flexible MFC - Applications have a small footprint and leverage code libraries that have been available on and for the os it self: Microsoft Windows - for many versions. MFC - Has a smaller footprint than .Net for infrastructure that would make for leaner and faster mobile phone applications on Microsoft mobile platforms - if they continue to support MFC that is. Just some thoughts on why bother...
Know way too many languages... master of none!
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.
-
Do you mean they did not know how to write a lexer and parser?
I wrote a nice lexer/parser/compiler for my MSCS but I never used that skill beyond that. I learned a lot but just like a lot of the data structures, algorithm analysis hardware architecture, it's great to know and gives you an appreciation of how things work but does not really apply to what you are being paid to do. And who has the time to keep going back over that stuff if you aren't using it on a daily basis?
-
MFC - Allows building applications that are truly binary; Binary Apps - Run Faster Binary Apps - More Secure Than Scripted Solutions Binary Apps - No Lag waiting for JUST-IN-TIME compiler to kick in. Natural Obfuscation of Source code.. Still reversable perhaps - but much more difficult as Assembly is what you get back; not C++ MFC - 3rd Party Vendors have C++ libraries for other popular OS that allows you to write MFC code that can be compiled for said OS's - .Net not far behind however MFC - Applications are faster, leaner, and highly flexible MFC - Applications have a small footprint and leverage code libraries that have been available on and for the os it self: Microsoft Windows - for many versions. MFC - Has a smaller footprint than .Net for infrastructure that would make for leaner and faster mobile phone applications on Microsoft mobile platforms - if they continue to support MFC that is. Just some thoughts on why bother...
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.
-
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 think the software world is heading down two different paths: 1. Infrastructure software 2. Other software 1. Infrastructure software will be the software that is used to create other software Infrastructure software will be written in C++ or some other "tough" language to program in ... or have design patterns and data structure implementation that the general programming public doesn't know to (or doesn't care to) program. 2 will be easy to use and available for the "masses"... Just look at VB... already started down that path... try to debug a COM object in VB... yeah right. but consume a COM object and you are on your way in 30 seconds... Dumb it down so people with minimum education can program cheaply... that's what business wants NOTICE... I said wants... not what they need. that is a different story.
-
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.
