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
-
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 have the very inverse problem. I seldom have trouble learning new programming languages and understanding programming constructs, but learning frameworks takes me forever. --- Btw, my standard for "having actually learnt a programming language" means... 1. Understanding all language constructs, especially those that allow you to deal with code/references to code as data: function pointers, function parameters, delegates, metaclasses (à la Delphi's
TClass), lambdas, closures, etc. 2. Implementing efficiently a mini-framework abstracting the following data types: vector, simple linked list, double linked list, stack, queue, binary search tree, AVL tree, red-black tree, generic B-tree, hash table, dense matrix, dense graph, sparse graph, sparse matrix, in that order. (Of course, if the language provides built-in versions of some of these data types, I will just use them and not bother implementing them myself.) And only then do I bother learning frameworks. And still does learning frameworks take me longer.Eduardo León
-
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.
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... :) :) :) :)
Code4Fun&&$$$
-
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.
I don't know about this particular endeavor; but for me; I've hit topics that blew my brain into pieces; then came back and revisited them and be able to grasp it fully.
Know way too many languages... master of none!
-
Do you mean they did not know how to write a lexer and parser?
I've tried... and succeeded on a smaller scale.. like programs that interpret home brew script to make a set up application source code I could compile. Does that count?
Know way too many languages... master of none!
-
I have no idea, but I'm happy to report that, having spent two evenings on the project, I'm now parsing like a demon all the quirky input .csv files I have to import to my latest project. :-D
Will Rogers never met me.
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 just convert to binary or decimal... before performing the math... though I could probably work through carrying a 1 on a base 16 $f + 1 = $10 :)
Know way too many languages... master of none!
-
To some extent it's understandable, what's the chance you have to write an RPN Stack in a real world project? I've even never seen one in my 15 year career. With the number of technologies expanding every day you have to be selective about what you're learning. In today's world I'd stick with knowing how to design a class model (know about is/has relationships), database connectivity, serializing data, building web/non-web interfaces and web services.
Wout
Here Here - good points!
Know way too many languages... master of none!
-
Bram van Kampen wrote:
Why are the basics No longer taught!
Because MFC, .NET, Silverlight, Wxx, etc., are all supposed to do the thinking for you? ;) Marc
MFC, .Net, Silverlight are very targeted programming systems; all from one vendor. I find by developing with more than one vendor's technology and more than one OS my exposure to things and understanding increases greatly. Things learned in one often help when using another. Example: I've done a ton of low level IP communication; but not in .Net.. I pick up .Net to do similiar task and I knew what to hunt for, the pieces I'd need.. and within an hour.. code was working fine... with a modification to the .Net config file so that .Net wasn't expecting Microsoft "style" protocall packets... but yeah.. got it working. --Jason
Know way too many languages... master of none!
-
I have the very inverse problem. I seldom have trouble learning new programming languages and understanding programming constructs, but learning frameworks takes me forever. --- Btw, my standard for "having actually learnt a programming language" means... 1. Understanding all language constructs, especially those that allow you to deal with code/references to code as data: function pointers, function parameters, delegates, metaclasses (à la Delphi's
TClass), lambdas, closures, etc. 2. Implementing efficiently a mini-framework abstracting the following data types: vector, simple linked list, double linked list, stack, queue, binary search tree, AVL tree, red-black tree, generic B-tree, hash table, dense matrix, dense graph, sparse graph, sparse matrix, in that order. (Of course, if the language provides built-in versions of some of these data types, I will just use them and not bother implementing them myself.) And only then do I bother learning frameworks. And still does learning frameworks take me longer.Eduardo León
And this is exactly why I personally don't jump on every new thing that comes out. You can never master a framework if you keep switching all the time.. Note my signature's sentiment is similar. --Jason
Know way too many languages... master of none!
-
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.
