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
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
-
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
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
-
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
None of our fifteen contestants knew how to scan an input file, never mind how to parse one. Of course you can facade a stream filter over a file system stream backend, bridge it to a an adapter that composites facades to regexp web services created by a factory so we can easily choose between the best regexp SAS providers. The factory should be a singleton, because it's an important pattern I couldn't work in. I have no idea how to actually write a regexp that can tell a for from a fork, but that should be easy, there are books for that.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
None of our fifteen contestants knew how to scan an input file, never mind how to parse one. Of course you can facade a stream filter over a file system stream backend, bridge it to a an adapter that composites facades to regexp web services created by a factory so we can easily choose between the best regexp SAS providers. The factory should be a singleton, because it's an important pattern I couldn't work in. I have no idea how to actually write a regexp that can tell a for from a fork, but that should be easy, there are books for that.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchySerializing data is very common in business applications (data persistence/communication), so nowadays I would expect someone to be able to write simple serializers/deserializers (parsers). But writing your own stack implementation to me falls in the uncommon category.
Wout
-
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
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.
-
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
Bram van Kampen wrote:
Why are the basics No longer taught!
I don't know! I'm studying CS right now, and the basics are indeed skipped over. However, I'd like you to know that this does not automatically mean that every student is lame like that. I've written parsers by hand before, and I've written non-trivial programs in z80 assembly (but not a parser, I did that in C#) - because I'm interested in that kind of thing. OTOH I have no certifications and I've never worked with MFC :) edit: and I can, of course, do binary and hexadecimal math without getting a calculator. Even xor, which seems hard to many people (even though it's just addition without carry, and therefore easier than addition)
-
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
