I think M$ tools and frameworks actually make developers dumber
-
no i am talking just among the subset of IT folks who actually do the coding.
Sincerely Yours, Brian Hart
-
True, and why not? Talent is expensive! It allows less talented (less educated, less passionate) developers to get stuff done! Ever wander to QA? :doh:
wizardzz wrote:
True, and why not? Talent is expensive! It allows less talented (less educated, less passionate) developers to get stuff done! Ever wander to QA?
Amen
VS2010/Atmel Studio 6.0 ToDo Manager Extension
Version 3.0 now available. There is no place like 127.0.0.1 -
Call me a Puritan, but I think that the MVC framework and the enhanced IDE tools, and LINQ etc actually remove developers from the pure algorithms they need to implement and make developers, on the whole, dumber. Don't get me wrong, these frameworks help make our jobs easier and make it easier to develop more quickly; however, should one have to revert to using a version of the IDE that is prior to the one that introduces novel database use features or hides implementation details and then develop according to the same pattern it makes it more difficult for skillsets to become backward compatible. For example, take the Entity Model framework and the MVC approach to using DbContexts to access the Database Connection etc. This dumbs away and hides connection details from the even the advanced developer behind a closed-source implementation so there is no way to Go To Definition and figure out what is behind the scenes so what if the next project is using, say, the old N-Tier Data Application model with the same data source and same model and now the task is, create an MVC app but using the old stuff. Shops can get pretty retarded at times with their insistance that developers go back to older frameworks and versions of the .NET framework, but sometimes it's necessary if the customer's machine infrastructure won't support the latest and greatest and customers necessarily can't be persuaded to upgrade due to the implementation and rollout logistics and cost limitations. So therefore, a developer who has been using .NET 4 and ASP MVC framework and Entities , may be unable to secure employment at a shop utilizing an earlier version of VS.
Sincerely Yours, Brian Hart
In my case, I find it harder to understand some of the more advanced frameworks as opposed to the more fundamental things. I like to understand code in terms of function calls which carry arguments, properties and such. Frameworks to me seem arbitrary and contrived, especially things like dependency properties and attached properties.
The difficult we do right away... ...the impossible takes slightly longer.
-
Call me a Puritan, but I think that the MVC framework and the enhanced IDE tools, and LINQ etc actually remove developers from the pure algorithms they need to implement and make developers, on the whole, dumber. Don't get me wrong, these frameworks help make our jobs easier and make it easier to develop more quickly; however, should one have to revert to using a version of the IDE that is prior to the one that introduces novel database use features or hides implementation details and then develop according to the same pattern it makes it more difficult for skillsets to become backward compatible. For example, take the Entity Model framework and the MVC approach to using DbContexts to access the Database Connection etc. This dumbs away and hides connection details from the even the advanced developer behind a closed-source implementation so there is no way to Go To Definition and figure out what is behind the scenes so what if the next project is using, say, the old N-Tier Data Application model with the same data source and same model and now the task is, create an MVC app but using the old stuff. Shops can get pretty retarded at times with their insistance that developers go back to older frameworks and versions of the .NET framework, but sometimes it's necessary if the customer's machine infrastructure won't support the latest and greatest and customers necessarily can't be persuaded to upgrade due to the implementation and rollout logistics and cost limitations. So therefore, a developer who has been using .NET 4 and ASP MVC framework and Entities , may be unable to secure employment at a shop utilizing an earlier version of VS.
Sincerely Yours, Brian Hart
Brian C Hart wrote:
Call me a Puritan, but I think that the MVC framework and the enhanced IDE tools, and LINQ etc actually remove developers from the pure algorithms they need to implement and make developers, on the whole, dumber.
A couple of thoughts about your post. #1: Whether a framework/model/etc makes someone else, or a lot of someone else, dumber is entirely irrelevant to me as I don't see myself as some sort of corporate intelligence policeman. #2: Re-writing pure algorithms may be a good learning excercise but there is no reason to substitute your own hackwork to fix a well known problem that has been already throughly addressed. Well, I mean, besides arrogance. #3: I'd like to know how M$ frameworks make people dumber but opensource Java frameworks don't also make their developers dumber - or is this just thinly veiled Microsoft hatred? (I'm pretending the M$ syntax didn't already answer that question). The truth is that frameworks don't make people stupd - laziness makes people stupid. I wish it was really complex enough to pin on a particular corporation, but it's not.
-
In my case, I find it harder to understand some of the more advanced frameworks as opposed to the more fundamental things. I like to understand code in terms of function calls which carry arguments, properties and such. Frameworks to me seem arbitrary and contrived, especially things like dependency properties and attached properties.
The difficult we do right away... ...the impossible takes slightly longer.
-
No they not make us dumber they make us a lot more productive, i think they make us more lazy because as programmers you make to a point where you dont want to reinvent the wheel
-
Call me a Puritan, but I think that the MVC framework and the enhanced IDE tools, and LINQ etc actually remove developers from the pure algorithms they need to implement and make developers, on the whole, dumber. Don't get me wrong, these frameworks help make our jobs easier and make it easier to develop more quickly; however, should one have to revert to using a version of the IDE that is prior to the one that introduces novel database use features or hides implementation details and then develop according to the same pattern it makes it more difficult for skillsets to become backward compatible. For example, take the Entity Model framework and the MVC approach to using DbContexts to access the Database Connection etc. This dumbs away and hides connection details from the even the advanced developer behind a closed-source implementation so there is no way to Go To Definition and figure out what is behind the scenes so what if the next project is using, say, the old N-Tier Data Application model with the same data source and same model and now the task is, create an MVC app but using the old stuff. Shops can get pretty retarded at times with their insistance that developers go back to older frameworks and versions of the .NET framework, but sometimes it's necessary if the customer's machine infrastructure won't support the latest and greatest and customers necessarily can't be persuaded to upgrade due to the implementation and rollout logistics and cost limitations. So therefore, a developer who has been using .NET 4 and ASP MVC framework and Entities , may be unable to secure employment at a shop utilizing an earlier version of VS.
Sincerely Yours, Brian Hart
Yes.
-
True, and why not? Talent is expensive! It allows less talented (less educated, less passionate) developers to get stuff done! Ever wander to QA? :doh:
Exactly -- Microsoft is actively working to reduce average salaries for developers world-wide and therefore reduce what they have to pay their own developers.
-
Brian C Hart wrote:
Call me a Puritan, but I think that the MVC framework and the enhanced IDE tools, and LINQ etc actually remove developers from the pure algorithms they need to implement and make developers, on the whole, dumber.
A couple of thoughts about your post. #1: Whether a framework/model/etc makes someone else, or a lot of someone else, dumber is entirely irrelevant to me as I don't see myself as some sort of corporate intelligence policeman. #2: Re-writing pure algorithms may be a good learning excercise but there is no reason to substitute your own hackwork to fix a well known problem that has been already throughly addressed. Well, I mean, besides arrogance. #3: I'd like to know how M$ frameworks make people dumber but opensource Java frameworks don't also make their developers dumber - or is this just thinly veiled Microsoft hatred? (I'm pretending the M$ syntax didn't already answer that question). The truth is that frameworks don't make people stupd - laziness makes people stupid. I wish it was really complex enough to pin on a particular corporation, but it's not.
MehGerbil wrote:
#1: Whether a framework/model/etc makes someone else, or a lot of someone else, dumber is entirely irrelevant to me as I don't see myself as some sort of corporate intelligence policeman.
I am all for using new technology and I am against laziness about not being concerned with what the guts are doing behind the scenes. The closed-source nature of M$ tech, though, makes this more difficult to do the higher-level stuff gets. My point is, you just never know what could be asked of you at your next job. For example, when one has done, e.g., .NET 1.1 way in the past, moved along with increasing technology like everyone else during their career and then finds themselves having to debug, enhance and maintain a .NET 1.1 codebase again as well as .NET 3.5 or .NET 4, if one is not careful certain skills can atrophy rendering such an employee impotent. I am aiming this scorn at M$ because their close source tech blocks the pathways to backward-skillset-propagation because as things are increasingly abstracted and then teh source is closed so you don't know what's going on under the hood, then you are more prone to forget skills you may need in a job further on. That's why it's imperative for computing professionals to always be somewhat familiar with the under the hood just in case you have to, next job you have, step back a bit in abstraction and still do the same tech but with a lower version.
Sincerely Yours, Brian Hart
-
Exactly -- Microsoft is actively working to reduce average salaries for developers world-wide and therefore reduce what they have to pay their own developers.
-
Call me a Puritan, but I think that the MVC framework and the enhanced IDE tools, and LINQ etc actually remove developers from the pure algorithms they need to implement and make developers, on the whole, dumber. Don't get me wrong, these frameworks help make our jobs easier and make it easier to develop more quickly; however, should one have to revert to using a version of the IDE that is prior to the one that introduces novel database use features or hides implementation details and then develop according to the same pattern it makes it more difficult for skillsets to become backward compatible. For example, take the Entity Model framework and the MVC approach to using DbContexts to access the Database Connection etc. This dumbs away and hides connection details from the even the advanced developer behind a closed-source implementation so there is no way to Go To Definition and figure out what is behind the scenes so what if the next project is using, say, the old N-Tier Data Application model with the same data source and same model and now the task is, create an MVC app but using the old stuff. Shops can get pretty retarded at times with their insistance that developers go back to older frameworks and versions of the .NET framework, but sometimes it's necessary if the customer's machine infrastructure won't support the latest and greatest and customers necessarily can't be persuaded to upgrade due to the implementation and rollout logistics and cost limitations. So therefore, a developer who has been using .NET 4 and ASP MVC framework and Entities , may be unable to secure employment at a shop utilizing an earlier version of VS.
Sincerely Yours, Brian Hart
If you've only ever worked with such things, then you would end up ignorant, sure... But just because I've been writing systems in WPF (.NET 4.5), and use EntityFramework for the system I've been developing for the past few months, doesn't mean I don't know what's going on underneath. Just because I make heavy use of LINQ doesn't mean I can't break those out into for or while loops and code them up manually... Sometimes I do, in those inner loops where I can shave off a few microseconds and speed up a calculation... But the other 95% of the time, my goal is to develop an easily-maintainable and robust system in a short amount of time. That's where the framework really shines. It's not going to be as efficient as if I did the whole thing in C++, but it'll be a lot easier to keep it running... And easier to decipher when I have to look back on it five years down the road. So, sure... I could have written my own database interface with raw SQL (Like I did with the system at my previous job, before I discovered EF), but it's just not worth the extra development and maintenance time. Sure, I could code out every Where/Group loop instead of doing it with LINQ, but it's just not worth the extra development and maintenance time. I could drop back to WinForms and code up every GUI control update manually, but I'm willing to pay the performance cost to let WPF binding keep everything in sync.
Brian C Hart wrote:
So therefore, a developer who has been using .NET 4 and ASP MVC framework and Entities , may be unable to secure employment at a shop utilizing an earlier version of VS.
If I got a job offer to program in VB6 and pre-.NET C++, it's THEY who would have trouble securing ME... I still occassionally maintain a legacy VB6 application that someone else started 20+ years ago, and I groan every time I have to load up VB6... Don't use new tools just for the sake of using new tools, but don't pass them up just because you're afraid they'll dull your edge. Right tools for the right job, remember?
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
If you've only ever worked with such things, then you would end up ignorant, sure... But just because I've been writing systems in WPF (.NET 4.5), and use EntityFramework for the system I've been developing for the past few months, doesn't mean I don't know what's going on underneath. Just because I make heavy use of LINQ doesn't mean I can't break those out into for or while loops and code them up manually... Sometimes I do, in those inner loops where I can shave off a few microseconds and speed up a calculation... But the other 95% of the time, my goal is to develop an easily-maintainable and robust system in a short amount of time. That's where the framework really shines. It's not going to be as efficient as if I did the whole thing in C++, but it'll be a lot easier to keep it running... And easier to decipher when I have to look back on it five years down the road. So, sure... I could have written my own database interface with raw SQL (Like I did with the system at my previous job, before I discovered EF), but it's just not worth the extra development and maintenance time. Sure, I could code out every Where/Group loop instead of doing it with LINQ, but it's just not worth the extra development and maintenance time. I could drop back to WinForms and code up every GUI control update manually, but I'm willing to pay the performance cost to let WPF binding keep everything in sync.
Brian C Hart wrote:
So therefore, a developer who has been using .NET 4 and ASP MVC framework and Entities , may be unable to secure employment at a shop utilizing an earlier version of VS.
If I got a job offer to program in VB6 and pre-.NET C++, it's THEY who would have trouble securing ME... I still occassionally maintain a legacy VB6 application that someone else started 20+ years ago, and I groan every time I have to load up VB6... Don't use new tools just for the sake of using new tools, but don't pass them up just because you're afraid they'll dull your edge. Right tools for the right job, remember?
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Ian Shlasko wrote:
Right tools for the right job, remember?
I wholeheartedly agree, but it's imperative to still be able to remember how to code those for and while loops. And sometimes, vis a vis a certain job, you can't afford to be choosy.
Sincerely Yours, Brian Hart
-
MehGerbil wrote:
#1: Whether a framework/model/etc makes someone else, or a lot of someone else, dumber is entirely irrelevant to me as I don't see myself as some sort of corporate intelligence policeman.
I am all for using new technology and I am against laziness about not being concerned with what the guts are doing behind the scenes. The closed-source nature of M$ tech, though, makes this more difficult to do the higher-level stuff gets. My point is, you just never know what could be asked of you at your next job. For example, when one has done, e.g., .NET 1.1 way in the past, moved along with increasing technology like everyone else during their career and then finds themselves having to debug, enhance and maintain a .NET 1.1 codebase again as well as .NET 3.5 or .NET 4, if one is not careful certain skills can atrophy rendering such an employee impotent. I am aiming this scorn at M$ because their close source tech blocks the pathways to backward-skillset-propagation because as things are increasingly abstracted and then teh source is closed so you don't know what's going on under the hood, then you are more prone to forget skills you may need in a job further on. That's why it's imperative for computing professionals to always be somewhat familiar with the under the hood just in case you have to, next job you have, step back a bit in abstraction and still do the same tech but with a lower version.
Sincerely Yours, Brian Hart
If I have to step back in abstraction I'll learn what I need to know at the time. I'm not going to go learn Cobol in the off chance my boss is going to ask for a Cobol based payment system. As for abstraction, I agree to an extent. I don't use Entity Framework because it looked like a non-starter to me.
-
It is all about productivity. I agree. But I am at a shop right now that supports factories that make packaging. We write the control software for their machinery and they aren't willing to spend the time and money very often to upgrade their whole plant and to re-train 30-year-veteran-union-worker machine operators on a new system except every 2-3 years. Therefore you are stuck with packaging plants (our customers) some of whom are still using WinXP and .NET 1.1 because their CEO wants more money for their next private jet and less to spend on software upgrading and training. So then when you have a developer who has been using .NET 4 and the latest and greatest, which holds their hands through wizards and does everything for them, they do not qualify for employment at our shop if they don't know how to access a DB the old-fashioned way, i.e., if they don't know what's going on behind the scenes. Then productivity actually DECREASES because there are so many layers of abstraction and hand-holding, now developers have only an idea of what's going on up on the surface as opposed to deep down in the bowels. I had professors in college and grad school who emphasized being intimately knowledgeable about what your computer system is doing on all levels, even if you have to work on the surface for increased productivity. Take for exmaple the statement
var q = list.Where(x => x.Property == true);in LINQ. How are you going to code that in .NET 1.1? Today's devs some of them fresh out of today's budget-cut "computer science" programs, won't know how to implement that with an ArrayList and no LINQ. Maybe that is a bad example, but what aboutvar q = list.Where(x => x.Property == true).GroupBy(x => x.IntegerProperty == 10).Selct(x => x.IntegerProperty).ToList();keep in mind the previous is pseudo-code; I am not going for correctness. There is a loss of productivity if someone has only been taught LINQ in computer science class and then they are at a desk in the 'real world' and they have only .NET 1.1 and ArrayList and have to do the same thing with an algorithm.Sincerely Yours, Brian Hart
Brian C Hart wrote:
How are you going to code that in .NET 1.1? Today's devs some of them fresh out of today's budget-cut "computer science" programs, won't know how to implement that with an ArrayList and no LINQ.
I suppose that the Net 4 shop that thinks that they can depend on the same programmer to produce their business critical code will find out how meaningless that statement is. It doesn't matter what API a new college grad learned about they still cannot program until they have experience.
-
I do agree. Between that, Mr. Gate's population control initiative, and his want to monitor our children, I might invest in some foil. Who has a nice hat template?
wizardzz wrote:
Between that, Mr. Gate's population control initiative, and his want to monitor our children, I might invest in some foil.
Given that the first would solve any number of world wide problems even being fanciful I find it a worthwhile goal. And its his money and his other initiatives do work. However it has nothing to do with this thread since Gates hasn't had any technological input into Microsoft for years.
-
wizardzz wrote:
Between that, Mr. Gate's population control initiative, and his want to monitor our children, I might invest in some foil.
Given that the first would solve any number of world wide problems even being fanciful I find it a worthwhile goal. And its his money and his other initiatives do work. However it has nothing to do with this thread since Gates hasn't had any technological input into Microsoft for years.
Apparently you aren't so good at identifying a joke.
jschell wrote:
However it has nothing to do with this thread since Gates hasn't had any technological input into Microsoft for years.
Yeah, he must have zero influence over everything MS does. He only owns a nice chunk of it.
-
The human mind has limits, such as being bound by limited time, limited capacity to learn, and limited capacity to retain information. As time goes on, programming environments will become more and more high level. After all, you wouldn't blame somebody for avoiding writing their entire business application in machine code, right? LINQ, MVC, and things of this sort are just another level that abstracts away the details and automates things which were previously manual. Sure, it may mean a developer can go some time without being exposed to some of the underlying fundamentals, but the time required to learn all those fundamentals may not be worthwhile. Another example of when this phenomenon applies is to an organization. You may have a Sharepoint developer who knows that tool really well, and a C++ guru who can do that well, and somebody who does LINQ/MVC, and they may share a manager, and that manager may have a department manager as their supervisor, and those managers may answer to VPs, CIOs, CEOs, and so on. Are you really going to blame the CEO for not knowing C++ or Sharepoint programming? If an abstraction layer is built well enough, you don't have to know about its implementatino details. That applies to people just as much as it applies to software. Sure, a developer may be better for knowing some of those details, but developers like all people have their limits and can't be expected to know everything.
AspDotNetDev wrote:
If an abstraction layer is built well enough, you don't have to know about its implementatino details
I see only the following possibilities. 1. The abstraction layer hides details such that they are no longer available. Thus the abstraction layer is only suitable for some subset of problems that the real layer solved. 2. The abstraction layer exposes all of the details and as such it is just as complex as what it intends to abstract. 3. There is some variation on the above depending on how 'good' each layer is. So if the abstracted layer was poorly done, a good layer on top, even with the same complexity, might help. But there are many variations possible.
-
Call me a Puritan, but I think that the MVC framework and the enhanced IDE tools, and LINQ etc actually remove developers from the pure algorithms they need to implement and make developers, on the whole, dumber. Don't get me wrong, these frameworks help make our jobs easier and make it easier to develop more quickly; however, should one have to revert to using a version of the IDE that is prior to the one that introduces novel database use features or hides implementation details and then develop according to the same pattern it makes it more difficult for skillsets to become backward compatible. For example, take the Entity Model framework and the MVC approach to using DbContexts to access the Database Connection etc. This dumbs away and hides connection details from the even the advanced developer behind a closed-source implementation so there is no way to Go To Definition and figure out what is behind the scenes so what if the next project is using, say, the old N-Tier Data Application model with the same data source and same model and now the task is, create an MVC app but using the old stuff. Shops can get pretty retarded at times with their insistance that developers go back to older frameworks and versions of the .NET framework, but sometimes it's necessary if the customer's machine infrastructure won't support the latest and greatest and customers necessarily can't be persuaded to upgrade due to the implementation and rollout logistics and cost limitations. So therefore, a developer who has been using .NET 4 and ASP MVC framework and Entities , may be unable to secure employment at a shop utilizing an earlier version of VS.
Sincerely Yours, Brian Hart
Wrong. It does not make programmers dumber. It's the dumber programmers that simply uses those tools and frameworks without knowing why or what the alternatives are. The good programmers will use it because they need it, because they know the alternatives and they know this is the best solution. Alternatively, the lesser programmers would write some horrible code to achieve the same thing if the tool or framework wasn't available to them. I guess these tools and frameworks protect the better programmers from the dumber programmers code, simply because there is less of it :D
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Call me a Puritan, but I think that the MVC framework and the enhanced IDE tools, and LINQ etc actually remove developers from the pure algorithms they need to implement and make developers, on the whole, dumber. Don't get me wrong, these frameworks help make our jobs easier and make it easier to develop more quickly; however, should one have to revert to using a version of the IDE that is prior to the one that introduces novel database use features or hides implementation details and then develop according to the same pattern it makes it more difficult for skillsets to become backward compatible. For example, take the Entity Model framework and the MVC approach to using DbContexts to access the Database Connection etc. This dumbs away and hides connection details from the even the advanced developer behind a closed-source implementation so there is no way to Go To Definition and figure out what is behind the scenes so what if the next project is using, say, the old N-Tier Data Application model with the same data source and same model and now the task is, create an MVC app but using the old stuff. Shops can get pretty retarded at times with their insistance that developers go back to older frameworks and versions of the .NET framework, but sometimes it's necessary if the customer's machine infrastructure won't support the latest and greatest and customers necessarily can't be persuaded to upgrade due to the implementation and rollout logistics and cost limitations. So therefore, a developer who has been using .NET 4 and ASP MVC framework and Entities , may be unable to secure employment at a shop utilizing an earlier version of VS.
Sincerely Yours, Brian Hart
-
Call me a Puritan, but I think that the MVC framework and the enhanced IDE tools, and LINQ etc actually remove developers from the pure algorithms they need to implement and make developers, on the whole, dumber. Don't get me wrong, these frameworks help make our jobs easier and make it easier to develop more quickly; however, should one have to revert to using a version of the IDE that is prior to the one that introduces novel database use features or hides implementation details and then develop according to the same pattern it makes it more difficult for skillsets to become backward compatible. For example, take the Entity Model framework and the MVC approach to using DbContexts to access the Database Connection etc. This dumbs away and hides connection details from the even the advanced developer behind a closed-source implementation so there is no way to Go To Definition and figure out what is behind the scenes so what if the next project is using, say, the old N-Tier Data Application model with the same data source and same model and now the task is, create an MVC app but using the old stuff. Shops can get pretty retarded at times with their insistance that developers go back to older frameworks and versions of the .NET framework, but sometimes it's necessary if the customer's machine infrastructure won't support the latest and greatest and customers necessarily can't be persuaded to upgrade due to the implementation and rollout logistics and cost limitations. So therefore, a developer who has been using .NET 4 and ASP MVC framework and Entities , may be unable to secure employment at a shop utilizing an earlier version of VS.
Sincerely Yours, Brian Hart
This is in part a "but of course" matter, and in part an inevitable consequence of technological advance. Software is not immune to such influences.
Yes, a tool that relieves you of part of what was once "your" work will make it unnecessary to understand (or be competent at) that part. And yes, I have argued in the past that many a young sofware engineer is intellectually and culturally poorer for never having been introduced to the demands and practices of earlier days. But to pursue that notion too far inevitably begins to sound like "You young folks don't know how lucky you are. Why, when I was your age, a byte only had two bits. And they were both ones! Zero hadn't been invented yet. We had to do everything in Roman numerals!"
The magnificent advances in tool technology pertinent to software development have made many things possible within practical bounds on time and cost that were previously unthinkable for a dollars-and-cents shop. They don't have a place in every sort of development -- the smallest, most resource-poor execution environments demand that we eschew such things as GUIs with 16 million colors and the .NET Frameworks -- but when they're applicable, they're Godsends.
Engineers are still responsible for choosing the right tool for the job. Not every tool is right for every job. But in a great many programming situations today, the feasibility of the project is founded on how much work the most advanced IDEs, frameworks, and similar conveniences have taken off our hands.
(This message is programming you in ways you cannot detect. Be afraid.)
