When some muppet pulled out in front of me in his 8 ton lorry doing approximately 60mph less than me on Tuesday, I was exceedingly glad I had ABS.
95 to 35 without skidding. Without loss of control. Without going sideways into the next lane, or the central barrier. Without hitting the idiot in front. In just over 2 seconds.
Sure, if I hadn't got ABS I'd have been able to do a lot to both avoid and control the skid. But I would have skid. I was losing too much speed too fast for me not to.
Modern cars stop in exceedingly shorter distances than cars of 20 years ago. They manage this despite ABS; the ABS gives them greater control and safety while doing so. My car also has various other acronyms dealing with redistributing the braking force to keep the car stable under such conditions.
It's also got an airbag. Hurrah for the modern brake technologies that avoided me needing it.
Yes, I could smell the brake pads burning afterwards..
>> what's wrong in MS demanding that you pay them for it when after all, you are trying to make money out of it?
It's their choice. But when I'm about to write software that'll cost companies a six digit sum in database, OS and other software licences to run, would you rather I wrote that software for your OS, your database, or your competitors'?
Just on that basis alone, Java has a massive head start. Free to get into, free to get a world class IDE, free for the OS to run it, free for the enterprise class application servers if you need them.
Of course, there are also commercial alternatives for all of them. Choice in the marketplace? Great joy.
>> But oh wait, you mean they ought to give it to you for free while you can make money out of it? Nice one, there.
I'm not going to pay them money to write software that by default generates them far more money. Especially when it's not (yet) a better solution choice.
On the whole I think you gave a balanced view. A couple of points
>> Unless you have the pleasure of running in an entirely Java/managed environment, those unsigned types are a life saver (or at least a sanity saver).
I've never yet had a problem with the lack of unsigned types in Java.
>> Operator overloading can also be useful, provided it's used carefully (and can cause no end of confusion if it's not).
This is why I hate it. There are too many utter muppets out there writing code, and given a tool that lets them completely bollocks up they'll take full advantage. Sure, they may write code that works - but I want code that's maintainable.
But as the top rated comment in the article says - pick either, and learn it well.
Re:It's not the techology, it's the people
on
Java Is So 90s
·
· Score: 1
I'm dealing with integration issues on a system written 30 years ago.
The authors of that code are dead. They grew old and died.
Had they been able to take advantage of the advances in software engineering over the past three decades, they may have used good application architecture to abstract out their interfaces, to properly decouple presentation logic from business logic from data storage, to make the simple maintainable.
Because they didn't, we're spending literally millions of pounds to achieve what takes us just a couple of weeks on our web platforms.
Proper software engineers don't think "after I write this nifty abstraction layer I'm never going to think about this facet of the problem again". They fully acknowledge and deal with the complexities of writing software that will be around for a long time, that will change extensively throughout its lifetime, and that will be worked on by people that didn't do the initial design/code.
Anybody writing database access code inside their web page needs educating.
Re:Why Java still isn't faster than C++
on
Java Is So 90s
·
· Score: 2, Interesting
>> Anything you can do with a flashy GC in Java, you can code up the same memory management algorithms in C++ if you really need it.
Why? I can download Java from Sun and it has this built in.
Performance hasn't been the issue with Java since 1.1, maybe 1.2. If you want to write embedded systems, device drivers, software with a small memory footprint, maybe Java isn't a good choice.
>> If the Java evangelists were right, and Java really was rivalling the performance of C++ and easier/safer/more productive today, then it's strange that the entire industry I work in, with all its R&D, hasn't noticed.
Ignoring performance, writing in Java _is_ easier/safer/more productive today than writing in C++.
People make fewer mistakes. People write better code. People don't have to spend weeks trying to write GC instead of just downloading something so efficient it's inadequate 1 time in 10,000.
I have deployed, at three companies now, Java based web applications handling millions of pounds of business, serving terabytes of dynamically created content, underpinning the leading websites in their industries.
Performance issues? Sure, we've had some. We've dealt with them. Good application design helps immensely, good hardware is cheap, basic measures such as caching data in memory, reducing network calls and writing stateless code all impact performance several orders of magnitude beyond the language used.
Is Java as performant as C++? In terms of money spent, on hardware, on developers, on design and analysis, to get web pages to users within 5 seconds? Yes.
A password in a configuration file is only visible to someone that can read that file.
Since that file exists only on your production server, only the system admin should have access to it. Since they're the person that sets the password, and the only person that needs to know it, nobody else ever gets to see it.
Why is this excessively insecure?
The point of the article is that these passwords never change, and that developers know them. Putting the password in a config file makes it possible to change it, and also means the developers don't know the production password. It is in fact more secure.
It also makes it much easier to deploy the same system in different environments - useful if you want clean separation of dev/test/prod, or are writing a product.
The good security people put in place security schemes that they can't bypass themselves.
If I know how to hack my web-app, I fix that vulnerability. Don't you?
Combine that with clear separation of development, test and production environments, with enforced policies mandating different passwords in each, keep the production passwords to the admin that set them, and change them whenever someone leaves that role and at regular intervals.
This isn't rocket science. The article highlights common bad practice, but the approaches and mechanisms to avoid the problem entirely are standard practice for more than a few.
Reverse engineering molecules is easy - how do you think we know what the common ones look like?
Recreating them.. that's the tricky part.
The hard bit's already been done - someone's thought of those molecules, designed them, created them for the first time. That was the raw genius. The rest is just engineering.
If the idea has no practical application, why are you complaining about a specific implementation of it?
Ten years ago digital cameras were pretty naff. Low quality images, expensive to make.
Now they're better than film for many uses.
Another ten years of improvement and suddenly we have 16 megapixel images using this technology. It's still better image quality than your screen can display or your printer produce on paper, and you've been able to play with the focus, the depth of field, everything else this gives to you.
Get off the internet, you're clearly not qualified.
My parents taught me to make tea and coffee when I was a kid. We used a kettle.
The kettle boils water. When it boils, you pour water into the teapot/cup.
Boiling water is 100C. It's safe to assume the coffee I was making was around 95C.
If I can make coffee at that temperature at the age of 8, it's pretty sensible to assume that coffee being bought somewhere else might be that hot. Holding it between my thighs would thus be very stupid.
95C is not unreasonably hot for a beverage. Anybody that pretends otherwise is out to make money from that fact.
I do what the big boys in this industry do. I learn, try out, evaluate and apply techniques to improve what I do, and how I do it.
TDD works fantastically well for me. Pair programming works superbly for me. Automated system testing is buggeringly hard to set up but really speeds things up. Sitting next to the customer provides an order of magnitude improvement in specification and delivery. Short delivery timescales with ruthless prioritisation keeps things focussed.
It's hard to put all that together. Very hard. I'll admit the organisation I work for at the moment just isn't structured to support it. Worse, they've outsourced development so there are two continents between the customer and the developer. But I have done it in the past, and I know I can do it again.
So the people that successfully delivered a lot of very capable software written in Java between 1998 and 2005 were wrong?
The people using agile methodologies since 1999 have been failing their customers?
Forgive my precociousness but even working for a large business, I seek continual improvement. I look for better ways to do things. I implement new practices that add value.
This means that in 1999 I started looking at some of the XP practices. In 2000 I adopted some full time. In 2001 I tried a full XP project. In 2002 I had most developments in the (multi-billion pound turnover) business following those practices that both worked for me, and fit into how the company worked.
I was still looking at other approaches, techniques, tools to see how to improve everything else we did.
I did recommend that we didn't take on vanilla XP. That's nothing to do with the methodology and everything to do with the organisation's ability to implement it. But we still learned from it.
Right now we don't use AJAX. That's more because the nature of our business doesn't have a need for that level of functionality. However, we're monitoring it, we're keeping abreast of it and we do use some AJAX techniques in minor ways to help with our websites.
Did I mention we're also maintaining and developing a 35 year old mainframe system? The developers of that system are still using assembler. They haven't picked up this new fangled object oriented programming thing. They love the internet but think it's horribly slow and unintuitive compared to their beloved green screen terminals. Oh, and it takes them several hundred days of development to make relatively simple changes underlying data storage due to the several thousand modules that all talk directly to it.
In practice I've yet to work for a business willing to wait 2 years for their product. Where the business environment, aims, markets don't change for that period of time.
Pragmatically Waterfall doesn't work. It often almost works, and most developments muddle through. But my customers want new functionality next week, not next year. They'll wait until next month, but any longer and they start complaining.
Since I know of ways of successfully delivering next month, I'd be failing them to force them to wait until next year while I kick off a full waterfall process. Especially since they wouldn't give it the support it needs to work properly.
I can deliver every 2 months. I can deliver approximately bug-free code in that timeframe. I can deliver genuine business advantage, meeting actual business need and keeping customers happy. And I can repeat it.
Other engineers don't write software the way they build bridges, design power stations, construct roads. Oddly enough some of them have tried - and if they'd succeeded they'd be winning ALL the business. Different environment, different constraints, and therefore different approaches needed.
Incidentally, "every step must be done in order" is very wrong. Test before you build - how else do you know you built the right thing. (And test again after.)
You also forgot various steps, but that's a whole other discussion..
As someone that has lived in Germany and has visited multiple times this year, I find customer service in shops, hotels, restaurants to be extremely good.
It's not the intrusive service you get in America, and nothing like the offensively intrusive service you get in India, but it's certainly not normally 'bad'.
Where I do have problems is when I'm offered assistance but am unable to describe my needs because my German is so shite. I don't think it would be fair to blame others for that.
This whole topic is one big piece of insecurity. It's not only possible to do productive and secure work in cubicles, if laid out properly it's more productive.
Shit, I worked for a credit card company where everybody worked in open-plan desks - they weren't even cubicles, just half-height partitions between face-to-face workers. System admins worked like that, HR worked like that, the information security team worked like that.
The only person in the whole building who had a special case desk position was the one guy on the information security team that did the technical investigations into internal fraud. He was also in the open area, just that he had his back to a solid wall and good sight of anybody approaching.
So are cubicles a bad idea for IT staff computers? You're right, the answer to that is obvious. No, it's not a bad idea. It's at best marginally less secure than offices, it's no less productive, it's better for the company as a whole and it's great for filtering out those arseholes that want to sit browsing slashdot and jerking off all day in an office.
Kids of today.. I remember getting excited because I upgraded to a computer with 3.5k of memory.
80MB _is_ mammoth. That we have the bandwidth and storage capacity to handle it these days doesn't change that.
Re:Buy the Game and Pay Again to Play It - NOT!!!!
on
Blizzcon Writeup
·
· Score: 1
Yeah, but since WoW came out in (the UK in) February I've bought one other game. Normally I'd have bought 3-4 in that time. So that's £50-90 saved (depending on purchase price) which compares pretty reasonably with the £63 I've paid in subscription so far.
Good MMORPGs have longevity beyond most games. UT, the CM series, and the Total War series are the only games in the last 5 years to have kept going that long. Heck, even X2 only lasted 3 months before I moved on..
You appear to have adopted the fallicious opinion that Slashdot is a single entity with a single mind.
In reality lots of people think lots of different ways.
I suspect you'll also find many Slashdot readers are very much in favour of copyrights. After all, the GPL and 'Free' software rely heavily on them.
The inclusion of the standards from the National Science Teachers Association would be far beyond fair use - it is a derivative work. Worse than that, it (rightly or wrongly) implies support from that body for the derivative work.
Preventing derivative works that detract greatly from someone (other than satire) is not generally something people rail against here on Slashdot.
Luckily Microsoft catered to people that aren't the best Windows developmenet author and offered 'New Windows Application' for people that don't know any better.
Sure, it means that people with less programming skill will be able to write software. Does that threaten you?
On software developments I control and influence I'll ensure waste code is removed, that people learn how to do things 'properly'. I'll also let them make use of IDE capabilities where appropriate, including 'intellisense' (or rather, its equivalents), including stub/skeleton generation (I write distributed systems), etc.
But if someone wants to write software for the first time, and picks VS, and uses 'New Windows Application'? Well, that's a new Windows developer, and Microsoft are happy.
The speaker (in the article) didn't say "don't use VS", he said "Here's how I recommend you use it". That's not damning. That's publicity. I think MS will be happy with that.
In the article the speaker noted that he recommends people start a new VS 'empty' project, not a Windows Forms project.
They then have control, and can intentionally add the features they desire.
People who know how to drop widgets on forms know only that. People who know how to code can also drop widgets on forms.
I think people should learn to code, and then pick up tools that improve their productivity. Start with the basics first, learn what's happening and why, and you'll be far better than if you merely mechanically repeat simple actions.
I like the article. I don't use VS, I don't write code for Windows any more, I've never written anything in c#. I can also relate to everything he's said, and agree with most of it.
Slashdot Mirror
When some muppet pulled out in front of me in his 8 ton lorry doing approximately 60mph less than me on Tuesday, I was exceedingly glad I had ABS.
95 to 35 without skidding. Without loss of control. Without going sideways into the next lane, or the central barrier. Without hitting the idiot in front. In just over 2 seconds.
Sure, if I hadn't got ABS I'd have been able to do a lot to both avoid and control the skid. But I would have skid. I was losing too much speed too fast for me not to.
Modern cars stop in exceedingly shorter distances than cars of 20 years ago. They manage this despite ABS; the ABS gives them greater control and safety while doing so. My car also has various other acronyms dealing with redistributing the braking force to keep the car stable under such conditions.
It's also got an airbag. Hurrah for the modern brake technologies that avoided me needing it.
Yes, I could smell the brake pads burning afterwards..
>> Google (like most private companies) has no obligation to provide for handicapped users.
Actually, yes they do.
(in the UK)
>> what's wrong in MS demanding that you pay them for it when after all, you are trying to make money out of it?
It's their choice. But when I'm about to write software that'll cost companies a six digit sum in database, OS and other software licences to run, would you rather I wrote that software for your OS, your database, or your competitors'?
Just on that basis alone, Java has a massive head start. Free to get into, free to get a world class IDE, free for the OS to run it, free for the enterprise class application servers if you need them.
Of course, there are also commercial alternatives for all of them. Choice in the marketplace? Great joy.
>> But oh wait, you mean they ought to give it to you for free while you can make money out of it? Nice one, there.
I'm not going to pay them money to write software that by default generates them far more money. Especially when it's not (yet) a better solution choice.
On the whole I think you gave a balanced view. A couple of points
>> Unless you have the pleasure of running in an entirely Java/managed environment, those unsigned types are a life saver (or at least a sanity saver).
I've never yet had a problem with the lack of unsigned types in Java.
>> Operator overloading can also be useful, provided it's used carefully (and can cause no end of confusion if it's not).
This is why I hate it. There are too many utter muppets out there writing code, and given a tool that lets them completely bollocks up they'll take full advantage. Sure, they may write code that works - but I want code that's maintainable.
But as the top rated comment in the article says - pick either, and learn it well.
I'm dealing with integration issues on a system written 30 years ago.
The authors of that code are dead. They grew old and died.
Had they been able to take advantage of the advances in software engineering over the past three decades, they may have used good application architecture to abstract out their interfaces, to properly decouple presentation logic from business logic from data storage, to make the simple maintainable.
Because they didn't, we're spending literally millions of pounds to achieve what takes us just a couple of weeks on our web platforms.
Proper software engineers don't think "after I write this nifty abstraction layer I'm never going to think about this facet of the problem again". They fully acknowledge and deal with the complexities of writing software that will be around for a long time, that will change extensively throughout its lifetime, and that will be worked on by people that didn't do the initial design/code.
Anybody writing database access code inside their web page needs educating.
>> Anything you can do with a flashy GC in Java, you can code up the same memory management algorithms in C++ if you really need it.
Why? I can download Java from Sun and it has this built in.
Performance hasn't been the issue with Java since 1.1, maybe 1.2. If you want to write embedded systems, device drivers, software with a small memory footprint, maybe Java isn't a good choice.
>> If the Java evangelists were right, and Java really was rivalling the performance of C++ and easier/safer/more productive today, then it's strange that the entire industry I work in, with all its R&D, hasn't noticed.
Ignoring performance, writing in Java _is_ easier/safer/more productive today than writing in C++.
People make fewer mistakes. People write better code. People don't have to spend weeks trying to write GC instead of just downloading something so efficient it's inadequate 1 time in 10,000.
I have deployed, at three companies now, Java based web applications handling millions of pounds of business, serving terabytes of dynamically created content, underpinning the leading websites in their industries.
Performance issues? Sure, we've had some. We've dealt with them. Good application design helps immensely, good hardware is cheap, basic measures such as caching data in memory, reducing network calls and writing stateless code all impact performance several orders of magnitude beyond the language used.
Is Java as performant as C++? In terms of money spent, on hardware, on developers, on design and analysis, to get web pages to users within 5 seconds? Yes.
A password in a configuration file is only visible to someone that can read that file.
Since that file exists only on your production server, only the system admin should have access to it. Since they're the person that sets the password, and the only person that needs to know it, nobody else ever gets to see it.
Why is this excessively insecure?
The point of the article is that these passwords never change, and that developers know them. Putting the password in a config file makes it possible to change it, and also means the developers don't know the production password. It is in fact more secure.
It also makes it much easier to deploy the same system in different environments - useful if you want clean separation of dev/test/prod, or are writing a product.
Imagine if Apache had a hard-coded password..
The good security people put in place security schemes that they can't bypass themselves.
If I know how to hack my web-app, I fix that vulnerability. Don't you?
Combine that with clear separation of development, test and production environments, with enforced policies mandating different passwords in each, keep the production passwords to the admin that set them, and change them whenever someone leaves that role and at regular intervals.
This isn't rocket science. The article highlights common bad practice, but the approaches and mechanisms to avoid the problem entirely are standard practice for more than a few.
My digital hearing aids make a massive difference to me.
Then again, I can hear reasonably well without them. They just fill in the gaps.
You can get directional aids btw - that will pull more sound from in front than the side/behind.
My hearing loss has definitely hurt my social life, but I've also done constructive things to deal with it. Anyway, there's always the internet..
Of course they could.
Reverse engineering molecules is easy - how do you think we know what the common ones look like?
Recreating them.. that's the tricky part.
The hard bit's already been done - someone's thought of those molecules, designed them, created them for the first time. That was the raw genius. The rest is just engineering.
If the idea has no practical application, why are you complaining about a specific implementation of it?
Ten years ago digital cameras were pretty naff. Low quality images, expensive to make.
Now they're better than film for many uses.
Another ten years of improvement and suddenly we have 16 megapixel images using this technology. It's still better image quality than your screen can display or your printer produce on paper, and you've been able to play with the focus, the depth of field, everything else this gives to you.
Get off the internet, you're clearly not qualified.
>> they have only to use their radio and armed officers will be on their way within seconds
a : Wrong. I've heard too many reports of ambulance/fire crews sat waiting for 10 minutes to an hour waiting for an armed response team.
b : When they do arrive, they sometimes do stupid things like shoot a man carrying a table leg, or shoot innocent Brazilians 7 times in the head.
I don't want an armed police - it would be a bigger threat to me than the criminals/terrorists.
Bullshit. Utter crap.
My parents taught me to make tea and coffee when I was a kid. We used a kettle.
The kettle boils water. When it boils, you pour water into the teapot/cup.
Boiling water is 100C. It's safe to assume the coffee I was making was around 95C.
If I can make coffee at that temperature at the age of 8, it's pretty sensible to assume that coffee being bought somewhere else might be that hot. Holding it between my thighs would thus be very stupid.
95C is not unreasonably hot for a beverage. Anybody that pretends otherwise is out to make money from that fact.
I do what the big boys in this industry do. I learn, try out, evaluate and apply techniques to improve what I do, and how I do it.
TDD works fantastically well for me. Pair programming works superbly for me. Automated system testing is buggeringly hard to set up but really speeds things up. Sitting next to the customer provides an order of magnitude improvement in specification and delivery. Short delivery timescales with ruthless prioritisation keeps things focussed.
It's hard to put all that together. Very hard. I'll admit the organisation I work for at the moment just isn't structured to support it. Worse, they've outsourced development so there are two continents between the customer and the developer. But I have done it in the past, and I know I can do it again.
~Stuart
I worked out maths. Going 90 not 70 saves me 7 minutes each way on my commute to work.
That's 70 minutes a week.
That's 60 hours a year (allowing for holidays, etc).
Yeah, I'm prepared to pay £400/year extra on fuel for 60 hours of my life back. That's pretty cheap.
So the people that successfully delivered a lot of very capable software written in Java between 1998 and 2005 were wrong?
The people using agile methodologies since 1999 have been failing their customers?
Forgive my precociousness but even working for a large business, I seek continual improvement. I look for better ways to do things. I implement new practices that add value.
This means that in 1999 I started looking at some of the XP practices. In 2000 I adopted some full time. In 2001 I tried a full XP project. In 2002 I had most developments in the (multi-billion pound turnover) business following those practices that both worked for me, and fit into how the company worked.
I was still looking at other approaches, techniques, tools to see how to improve everything else we did.
I did recommend that we didn't take on vanilla XP. That's nothing to do with the methodology and everything to do with the organisation's ability to implement it. But we still learned from it.
Right now we don't use AJAX. That's more because the nature of our business doesn't have a need for that level of functionality. However, we're monitoring it, we're keeping abreast of it and we do use some AJAX techniques in minor ways to help with our websites.
Did I mention we're also maintaining and developing a 35 year old mainframe system? The developers of that system are still using assembler. They haven't picked up this new fangled object oriented programming thing. They love the internet but think it's horribly slow and unintuitive compared to their beloved green screen terminals. Oh, and it takes them several hundred days of development to make relatively simple changes underlying data storage due to the several thousand modules that all talk directly to it.
Which team would you rather work with?
Waterfall make work in theory.
In practice I've yet to work for a business willing to wait 2 years for their product. Where the business environment, aims, markets don't change for that period of time.
Pragmatically Waterfall doesn't work. It often almost works, and most developments muddle through. But my customers want new functionality next week, not next year. They'll wait until next month, but any longer and they start complaining.
Since I know of ways of successfully delivering next month, I'd be failing them to force them to wait until next year while I kick off a full waterfall process. Especially since they wouldn't give it the support it needs to work properly.
I can deliver every 2 months. I can deliver approximately bug-free code in that timeframe. I can deliver genuine business advantage, meeting actual business need and keeping customers happy. And I can repeat it.
Other engineers don't write software the way they build bridges, design power stations, construct roads. Oddly enough some of them have tried - and if they'd succeeded they'd be winning ALL the business. Different environment, different constraints, and therefore different approaches needed.
Incidentally, "every step must be done in order" is very wrong. Test before you build - how else do you know you built the right thing. (And test again after.)
You also forgot various steps, but that's a whole other discussion..
As someone that has lived in Germany and has visited multiple times this year, I find customer service in shops, hotels, restaurants to be extremely good.
It's not the intrusive service you get in America, and nothing like the offensively intrusive service you get in India, but it's certainly not normally 'bad'.
Where I do have problems is when I'm offered assistance but am unable to describe my needs because my German is so shite. I don't think it would be fair to blame others for that.
~Cederic
Exactly how the fuck does an office prevent this?
One simple word : Cleaners.
This whole topic is one big piece of insecurity. It's not only possible to do productive and secure work in cubicles, if laid out properly it's more productive.
Shit, I worked for a credit card company where everybody worked in open-plan desks - they weren't even cubicles, just half-height partitions between face-to-face workers. System admins worked like that, HR worked like that, the information security team worked like that.
The only person in the whole building who had a special case desk position was the one guy on the information security team that did the technical investigations into internal fraud. He was also in the open area, just that he had his back to a solid wall and good sight of anybody approaching.
So are cubicles a bad idea for IT staff computers? You're right, the answer to that is obvious. No, it's not a bad idea. It's at best marginally less secure than offices, it's no less productive, it's better for the company as a whole and it's great for filtering out those arseholes that want to sit browsing slashdot and jerking off all day in an office.
Kids of today.. I remember getting excited because I upgraded to a computer with 3.5k of memory.
80MB _is_ mammoth. That we have the bandwidth and storage capacity to handle it these days doesn't change that.
Yeah, but since WoW came out in (the UK in) February I've bought one other game. Normally I'd have bought 3-4 in that time. So that's £50-90 saved (depending on purchase price) which compares pretty reasonably with the £63 I've paid in subscription so far.
Good MMORPGs have longevity beyond most games. UT, the CM series, and the Total War series are the only games in the last 5 years to have kept going that long. Heck, even X2 only lasted 3 months before I moved on..
That's interesting, cos my email from FFII only arrived at the weekend.
I voted for Seb Coe not Ellen MacArthur. Admiral though her achievement was it didn't piss off the French quite as much as Seb did..
You appear to have adopted the fallicious opinion that Slashdot is a single entity with a single mind.
In reality lots of people think lots of different ways.
I suspect you'll also find many Slashdot readers are very much in favour of copyrights. After all, the GPL and 'Free' software rely heavily on them.
The inclusion of the standards from the National Science Teachers Association would be far beyond fair use - it is a derivative work. Worse than that, it (rightly or wrongly) implies support from that body for the derivative work.
Preventing derivative works that detract greatly from someone (other than satire) is not generally something people rail against here on Slashdot.
Luckily Microsoft catered to people that aren't the best Windows developmenet author and offered 'New Windows Application' for people that don't know any better.
Sure, it means that people with less programming skill will be able to write software. Does that threaten you?
On software developments I control and influence I'll ensure waste code is removed, that people learn how to do things 'properly'. I'll also let them make use of IDE capabilities where appropriate, including 'intellisense' (or rather, its equivalents), including stub/skeleton generation (I write distributed systems), etc.
But if someone wants to write software for the first time, and picks VS, and uses 'New Windows Application'? Well, that's a new Windows developer, and Microsoft are happy.
The speaker (in the article) didn't say "don't use VS", he said "Here's how I recommend you use it". That's not damning. That's publicity. I think MS will be happy with that.
In the article the speaker noted that he recommends people start a new VS 'empty' project, not a Windows Forms project.
They then have control, and can intentionally add the features they desire.
People who know how to drop widgets on forms know only that. People who know how to code can also drop widgets on forms.
I think people should learn to code, and then pick up tools that improve their productivity. Start with the basics first, learn what's happening and why, and you'll be far better than if you merely mechanically repeat simple actions.
I like the article. I don't use VS, I don't write code for Windows any more, I've never written anything in c#. I can also relate to everything he's said, and agree with most of it.