It is a general, sweeping statement, but I think it has enough truth in it to matter.
Once we have 2 classes of developers - those who were entrusted to the complicated bits that mattered, like the back-end data processing and business logic; and those who wrote the more RAD side of things, the VB and web developers. Now, I know I'm making another sweeping generalisation but you know what I'm talking about - there were poor developers who did crappy work, but it was ok as the work they were entrusted with wasn't critical to the running of the system.
But today, everyone's a back-end developer, only they;ve been given stuff like LINQ and so an ex-VB dev suddenly decides that he can write the back-end DB and doesn't have to know SQL because his ORM abstracts it all away from him so much. You see the answers on stackoverflow where people say that SQL development is dead because of LINQ!
Its just an example, but one that shows why I think the 'easy to code' stuff makes the poorer developers rise to work on the more difficult aspects of the system.
now, I like the IDEs, though I'm a bit "meh" about refactoring support - the support is limited and I don't tend to "rename variable" very often, if at all. Some of the bits you describe are best left to external tools anyway (eg doc generation as there are better tools out there than that integrated into your IDE, and I always want to put more doc into the docs than is supported by the auto-gen tool).
Frameworks.... should be banned, libraries are the way to go, something that you use. Frameworks are there to use you! I suppose they do have their place in some very well-defined areas, a game engine where you deliver graphics and a few extras, but when you're bastardising your language with attributes just to shoehorn it into a framework's poor extensibility, then you're on to a loser (yes, WCF I'm looking right at you, PHP has a much better webservice system that requires a tenth of the code.. when PHP kicks your arse, you should give up)
but yes, there's a difference between helping me organise my work; and doing so much work for me that anyone with only half a brain can think they can do it.
I've done agile many years back and it as great - iterative development, regular releases, a 'vision' of what was needed to be added to the product per cycle... it worked.
Today... agile seems to be a way of doing massively heavyweight processes. we have 2 scrum boards, we can't decide what the timebox items should be, or how long it'll take to do them, or how many should be in there, or how much planning for the next timebox needs to be done.... gah! its all planning on our agile nonsense.
Its' just a tool to solve some other problem I have. I can't wait for the day when I can tell the computer verbally or draw a picture the algorithm and never ever have to type another line of code - ever.
well, the good news is that you can do this today, it's been around for at least ten years. Its called UML. what happens in your fantasy is that you draw your code layouts in boxes with various types of lines to link the objects together, then click a button and the whole thing gets generated into your favourite language. you then fill in a few of the details (ie the implementation inside some of those objects) and you're done.
I also wrote a system that did something similar - you wrote objects that could be dropped onto a canvas designer like a flowchart and wire up inputs and outputs (yes, a lot like biztalk, only we did it before biztalk came out, though I guess taking our product to MS for performance testing in their labs was a mistake).
Ok, you can stop reading here, the rest of us... I think everyone knows the problems with UML - write the big diagram, put it somewhere for management to look at, then ignore it as you work on code. It simply wasn't expressive enough to use for real work. As for our product, it worked quite well, you could drop GUI components (html-based) onto it too and it would all magically make an application the user worked through and a business analyst could update when business requirements changed. Trouble was, the complexity of the thing increased exponentially. An app with a dozen components was easy, once you started work on a real-world app, the complexity meant you needed a couple dozen BAs working on it, It would have been more efficient just handing it to programmers and telling them the initial requirements are that the back-end rules will change.
So I don't think there will ever be a shift away from typing code, although practically every app I've seen in recent years has tried some form of configuration replacement (like.net, where everything you used to write in code is now in.config files, and everything you used to put in config is now hard-coded) or custom rolled ones that implement configurable business logic.
I'd agree totally with that, but I also blame the languages we use - there's often been a discussion concerning whether the "easy to use" languages and their "handholding" IDEs are corrupting the youth by making them turn coding into an exercise in snippets, or cut&paste, or click and its filled out for you.
Its no longer a problem to solve, its a problem that has 1 solution that you have to find. Coding might have turned from a puzzle game where you have to think of how it all fits together, into an adventure game where you have to discover the right words to progress to the next level.
Frameworks in particular are a problem here, as you never know what's happening under the hood so you're discouraged from finding out, instead you have to just know how to work the system.
There a few things like this that have a knock-on effect to the rest of the work we do, and the interest in it.
tech support! I used to dream of tech support interruptions!
Now I'm doing a bastard child of agile that the company has brought in and I cannot do anything for longer than 2 hours without having to go back to the scrum board for more work. Don't they know they can just point me at a problem and I'll get it solved - it is what I've been doing for several decades after all.
I guess the agile stuff is for the kids who can't concentrate on a task for longer than an hour and have to keep being told what to do or they'll just start looking at facebook and twitter all day.
even hedge bets with Symbian and featurephones would have been good enough, they were selling very well until the pillock stood up on his burning platform and, well, pushed the company off.
I'm sure he'll still get his million dollar bonus when they sack him though.
I'd like to offer a different analogy - the million-dollar pen that can write upside down for astronauts vs the russians pencil.
Most IDEs are like this, massively complex monsters that you need because the languages and frameworks you use are monsters themselves, and they were allowed to become monsters because... there are IDEs available to make the pain of using those languages easier. When the real answer is to make the language simpler to use and do more in library code.
My example earlier of what you need to make a WCF Service in C# work compared to the dozen lines of PHP is quite true - but no-one notices simply because they have Visual Studio to auto-generate most of the code for them. Obviously Microsoft loves this situation as they can sell lots and lots of IDEs - ain;t no-one going to write those services in notepad while they can make it impossibly complex!
I think this is the problem, not that IDEs are bad in themselves, but that they become crutches that you have to use to write code, and once you're hooked on that, they add other things like integrated SCM and testing where you must use only the test tooling that comes provided in order to get any tests done... and people upgrade to the next mega-expensive version to keep the cycle going.
That's becuase you write C# code and you *need* VS to do it.
challenge: write a simple WCF service using notepad. Go on, see if you can do it without VS implementing all the crazy interfaces you need, adding those attributes to your interface, creating the required complexity of a app.config settings file with all the endpoints, service hosts and bindings, plus all the required property settings to make it compile and the assemblyinfo.cs to make it work.
In PHP (as an example, I happen to be looking at some right now, not that PHP is anyhow better), I can write a webservice in notepad in a dozen lines of code.
This is what we've lost with the rise of the IDE - you may think your IDE is wonderful and allows you to do all manner of fancy things, and it takes away a lot of the burden of coding.... but you only think that because it's added that burden in the first place. VS will auto-generate all that crap for you and say "look how good I am to you", when really you should be thinking "what a load of crap you've dumped on me".
VS is a good IDE though, but its much better for writing C++ code that (yet) doesn't need the crutches VS gives you as a C# developer.
as everyone will say - you modularise your code so you have a hundred components each with 100 source files (a number I pulled out my ass but serves to describe how you can maintain a grokkable number in your head) and you have a system with 10,000 source files!
Naming conventions are good, as are logical separations, but another approach is to have a language that requires fewer files! I look at the.NET code in my IDE and see the simplest of simple projects has a multitude of crap scattered all over it - assemblyinfo.cs, app.config, app.manifest, and that's before I even see code (I'm ignoring the special files created by VS itself, like the.sln,.csproj,.vssscc etc).
I've been coding for years, and I managed perfectly fine with a bog-standard editor that didn't have any kind of lookups, intellisense, etc. I had "find in files" and that was enough:)
and I recommend another one: nodebeginner book, free on their own website with a link to a paid bundle on Leanpub.
Leanpub seems to be the thing the OP wants - simple ways to take payment for ebooks in multiple formats, low royalty overhead, and can offer free versions too.
ok, and you're right about self documenting... I'm sure that fad is just an excuse for people who don't want to do a professional job...
However, there is no "good style", they're all as good as each other - I mean some people like K&R braces because they use the indentation for block scope, and putting the first bracket on the same line reduces the amount of extraneous lines that clutter the ease of viewing the indentation. So its not a bad style at all, even if you don't like it.. it is quite a lot like Whitesmith's style though, and has the advantage of being more commonly found in the wild.
So you should modify your code to fit with Drupal's style, simply because you're wrong to say they're not as good - the only bad style is one that doesn't fit in with the rest of the codebase, and that makes (in this instance) your style a bad one. So embrace their style for your Drupal plugins and keep your style for your other projects.
not really - he means be consisted within a project, so if you decide to use _ in names for example, and create int my__variable then do not create int MyNextNewVariable afterwards. (or vice versa).
This applies to all projects, so if your coding standards say always use underscores in naming, and you have to work on existing code that uses pascal case for names, then you use the pascal case - not the standard. The point is that all the code needs to be roughly the same style in a project but it really doesn't matter what that style is.
Reformatting only really deals with syntax of the code, which is trivial stuff - braces in certain places etc, using one will screw your source code diffs, and will not help you with other parts of the code style. So they're a bad choice. But the flexibility to change styles is good advice.
why stop there? If you're worried some members of the team won't be able to understand someone else's code... then let them all write in Visual Basic, just to be sure.
sounds to me like a professional who is interested in doing the work, not arguing the toss over the latest trivial fasions to hit the coding industry.
You can work with code written in many different styles. Lots of people do it all the time. Think it cripples your ability to do good stuff?
Then think - what happens if you are exposed to code a different team wrote, using a different style guide. We've all worked with sample code on the web, tutorial code, library code written by someone else. Strangely enough they don't all follow your coding style, and you can read them all perfectly well.
So by mandating a single style, all you're doing is stopping you from maintaining your flexibility to work. Like I can no longer really get anywhere without my satnav, a rigorously enforced holy-style-guide will just kill off that part of your mind that used to deal with code written in all kinds of styles without problem.
The best thing to do is just scrap them entirely and rely on the team's code reviews to deal with anything nasty that someone puts in. The rest - working and no problems.
Of course, it does rely on everyone cooperatively working together, which kind of excludes those asperger's weenies who insist everyone else must work like they want.
Windows is a good product nowadays, and the Windows division is certainly full of excellent engineers. Too bad the guys who wrote Explorer shell extensions (and explorer itself) wouldn't know a clue if someone took a large one and shoved it up them!
But the problem with running an OS isn't that is runs "clean", you have to install products to make it do the things you want. The biggest problem I have with Windows nowadays is complexity. An OS should be as simple as possible so there is much fewer areas for things to go wrong, unfortunately Windows has a lot of incredibly complex pieces that make me not trust it nearly as much as I used to.
For example, I had the misfortune to install SQLServer 2008r2, and the install failed (I think it was a conflict with an existing sqlserver 2005 install, but of course, you can never be sure, even though its described as safe to install side by side). Anyway, I tried to uninstall it and it failed. So I went on the web to get instructions on how to manually get rid of it so I could try again... and that's where the problems really started. I was seriously considering a OS rewipe at one point. In the end I found how to remove the pieces from the registry - it involved searching through the installers key for guids used in the installation, then taking the first 8 characters of the guid and reversing them to find the corresponding entry in the installer.
Once they (and all the obvious bits) were gone, I managed to run the installer again. I'm sure you're reading this thinking "no way", but alas, its totally true - google for it and you'll see other people having the same problems.
And you can see this complexity if you run some debug traceing tools. Fire up SxsTrace and look at the log it produces when you run a.NET app - hundreds of lines of it simply looking for the assemblies to load. Hundreds! Whatever was wrong with search the path for matching filenames?
That's the difference - Linux will search the path and you will know exactly what it's doing. Windows will fill a log file with thousand lines and and you won't know what it's doing.
Ximinez: Hm! She is made of harder stuff! Cardinal Fang! Fetch...THE COMFY CHAIR!
[JARRING CHORD]
[Zoom into Fang's horrified face]
Fang [terrified]: The...Comfy Chair?
[Biggles pushes in a comfy chair -- a really plush one]
Ximinez: So you think you are strong because you can survive the soft cushions. Well, we shall see. Biggles! Put her in the Comfy Chair!
but Ballmer used and threw an office chair - see, he managed to fuck up even this simple act of corporate motivation.
Ximinez [with a cruel leer]: Now -- you will stay in the Comfy Chair until lunch time, with only a cup of coffee at eleven. [aside, to Biggles] Is that really all it is? Biggles: Yes, lord. Ximinez: I see. I suppose we make it worse by shouting a lot, do we? Confess, woman. Confess! Confess! Confess! Confess
ah... well, I suppose he does try to make up for it by shouting a lot.
ohhhh shit, the world's just been turned upside down - Unix is for personal, hack-style users and Windows is for mainframe, secure datacentre applications?!:)
Of course you're right - Dave Cutler did a great job with the original WNT, and Linux was a crashy bit of crap for many years, but things change and Linux had a load of good engineering put into it, and WindowsNT had a load of crappy engineering put into it.
So today, the faults with Linux lie in the original design flaws, and the faults with Windows lie in the bodged up crap that was added by other teams in Microsoft. (however, I'd take a slight contention about Windows NT security model - it started life really well, simple to use and understand. Today even running as administrator you don't have administrator privileges, then there's the overly complex way of applying some security aspects, and then there's the different models of security that just don't use the underlying model that worked so well - for example I once attended a course from MS about MTS and in there they talked of security roles. I put my hand up and asked "why have roles when you could have used Windows groups?" The guy ummed a little, gave a little laugh and said "ah yes, I see where you're coming from with that... next question"). Obviously some team at MS had decided to roll their own security system rather than rely on the underlying thing, and this is what still happens today.
(Unless you're one of those idiots who always runs Windows apps maximized to full screen no matter how big it is.)
you mean Windows 8 users who cannot get Metro apps to run in anything other than full-screen (ok, except for a little 2nd window)
I don't think an interactive table is much good for a desktop replacement - where would I put my coffee mug? If anything, it will be a flat-screen, slightly angled for view that you get like some news anchors have in their desks.
but once profits start to drop, Microsoft might be profitable but investors will start to walk away, and the share price will drop, and that will make people panic, and then Microsoft executives (who have millions of shares and will see the red) will start to do crazy things.
Look at Nokia for an example - symbian and feature phones are hugely profitable, yet the CEO says "they're sh*t" and next thing you know, they're not selling anything and are heading for ecven more layoffs and probably a takeover from Microsoft or Apple for peanuts. Do you think Ballmer could manage to achieve this? You bet.
I think you mean 80% of apps uploaded to the windows Store have not been downloaded...because they're stuck in the acceptance loop and not passed. See what the blogger said the Microsoft engineer said about thousands of apps being stuck, that's why it took so long for his app to fail each time he uploaded it - the servers are maxed out with a huge backlog of failures.
Microsoft has a huge chance to alienate developers... and are embracing it wholeheartedly.
no, its not. Its like an alcoholic thinking they've been dry for a couple of years and so its ok to start drinking again...
Allowing Microsoft to install only IE is much the same thing - the temptation to put just one little Windows-only extension in will be too great, and next thing you know, you're using MetroUI and wondering why your head hurts.
Its bad enough that Windows 8 will come with a single browser that works in the Metro side of things (subject to the others figuring out how to fully replace it, which they currently cannot). Can you imagine web sites that only work correctly in IE10 running in Metro?
my (next) car already has this: a split screen view so the driver can see the satnav while the passenger can watch movies or TV (with headphone support to avoid distraction)
Slashdot Mirror
It is a general, sweeping statement, but I think it has enough truth in it to matter.
Once we have 2 classes of developers - those who were entrusted to the complicated bits that mattered, like the back-end data processing and business logic; and those who wrote the more RAD side of things, the VB and web developers. Now, I know I'm making another sweeping generalisation but you know what I'm talking about - there were poor developers who did crappy work, but it was ok as the work they were entrusted with wasn't critical to the running of the system.
But today, everyone's a back-end developer, only they;ve been given stuff like LINQ and so an ex-VB dev suddenly decides that he can write the back-end DB and doesn't have to know SQL because his ORM abstracts it all away from him so much. You see the answers on stackoverflow where people say that SQL development is dead because of LINQ!
Its just an example, but one that shows why I think the 'easy to code' stuff makes the poorer developers rise to work on the more difficult aspects of the system.
now, I like the IDEs, though I'm a bit "meh" about refactoring support - the support is limited and I don't tend to "rename variable" very often, if at all. Some of the bits you describe are best left to external tools anyway (eg doc generation as there are better tools out there than that integrated into your IDE, and I always want to put more doc into the docs than is supported by the auto-gen tool).
Frameworks.... should be banned, libraries are the way to go, something that you use. Frameworks are there to use you! I suppose they do have their place in some very well-defined areas, a game engine where you deliver graphics and a few extras, but when you're bastardising your language with attributes just to shoehorn it into a framework's poor extensibility, then you're on to a loser (yes, WCF I'm looking right at you, PHP has a much better webservice system that requires a tenth of the code.. when PHP kicks your arse, you should give up)
but yes, there's a difference between helping me organise my work; and doing so much work for me that anyone with only half a brain can think they can do it.
oh no.
I've done agile many years back and it as great - iterative development, regular releases, a 'vision' of what was needed to be added to the product per cycle... it worked.
Today... agile seems to be a way of doing massively heavyweight processes. we have 2 scrum boards, we can't decide what the timebox items should be, or how long it'll take to do them, or how many should be in there, or how much planning for the next timebox needs to be done.... gah! its all planning on our agile nonsense.
Its not agile, lets put it that way.
Its' just a tool to solve some other problem I have. I can't wait for the day when I can tell the computer verbally or draw a picture the algorithm and never ever have to type another line of code - ever.
well, the good news is that you can do this today, it's been around for at least ten years. Its called UML. what happens in your fantasy is that you draw your code layouts in boxes with various types of lines to link the objects together, then click a button and the whole thing gets generated into your favourite language. you then fill in a few of the details (ie the implementation inside some of those objects) and you're done.
I also wrote a system that did something similar - you wrote objects that could be dropped onto a canvas designer like a flowchart and wire up inputs and outputs (yes, a lot like biztalk, only we did it before biztalk came out, though I guess taking our product to MS for performance testing in their labs was a mistake).
Ok, you can stop reading here, the rest of us... I think everyone knows the problems with UML - write the big diagram, put it somewhere for management to look at, then ignore it as you work on code. It simply wasn't expressive enough to use for real work.
As for our product, it worked quite well, you could drop GUI components (html-based) onto it too and it would all magically make an application the user worked through and a business analyst could update when business requirements changed. Trouble was, the complexity of the thing increased exponentially. An app with a dozen components was easy, once you started work on a real-world app, the complexity meant you needed a couple dozen BAs working on it, It would have been more efficient just handing it to programmers and telling them the initial requirements are that the back-end rules will change.
So I don't think there will ever be a shift away from typing code, although practically every app I've seen in recent years has tried some form of configuration replacement (like .net, where everything you used to write in code is now in .config files, and everything you used to put in config is now hard-coded) or custom rolled ones that implement configurable business logic.
I'd agree totally with that, but I also blame the languages we use - there's often been a discussion concerning whether the "easy to use" languages and their "handholding" IDEs are corrupting the youth by making them turn coding into an exercise in snippets, or cut&paste, or click and its filled out for you.
Its no longer a problem to solve, its a problem that has 1 solution that you have to find. Coding might have turned from a puzzle game where you have to think of how it all fits together, into an adventure game where you have to discover the right words to progress to the next level.
Frameworks in particular are a problem here, as you never know what's happening under the hood so you're discouraged from finding out, instead you have to just know how to work the system.
There a few things like this that have a knock-on effect to the rest of the work we do, and the interest in it.
tech support! I used to dream of tech support interruptions!
Now I'm doing a bastard child of agile that the company has brought in and I cannot do anything for longer than 2 hours without having to go back to the scrum board for more work. Don't they know they can just point me at a problem and I'll get it solved - it is what I've been doing for several decades after all.
I guess the agile stuff is for the kids who can't concentrate on a task for longer than an hour and have to keep being told what to do or they'll just start looking at facebook and twitter all day.
even hedge bets with Symbian and featurephones would have been good enough, they were selling very well until the pillock stood up on his burning platform and, well, pushed the company off.
I'm sure he'll still get his million dollar bonus when they sack him though.
I'd like to offer a different analogy - the million-dollar pen that can write upside down for astronauts vs the russians pencil.
Most IDEs are like this, massively complex monsters that you need because the languages and frameworks you use are monsters themselves, and they were allowed to become monsters because... there are IDEs available to make the pain of using those languages easier. When the real answer is to make the language simpler to use and do more in library code.
My example earlier of what you need to make a WCF Service in C# work compared to the dozen lines of PHP is quite true - but no-one notices simply because they have Visual Studio to auto-generate most of the code for them. Obviously Microsoft loves this situation as they can sell lots and lots of IDEs - ain;t no-one going to write those services in notepad while they can make it impossibly complex!
I think this is the problem, not that IDEs are bad in themselves, but that they become crutches that you have to use to write code, and once you're hooked on that, they add other things like integrated SCM and testing where you must use only the test tooling that comes provided in order to get any tests done... and people upgrade to the next mega-expensive version to keep the cycle going.
That's becuase you write C# code and you *need* VS to do it.
challenge: write a simple WCF service using notepad. Go on, see if you can do it without VS implementing all the crazy interfaces you need, adding those attributes to your interface, creating the required complexity of a app.config settings file with all the endpoints, service hosts and bindings, plus all the required property settings to make it compile and the assemblyinfo.cs to make it work.
In PHP (as an example, I happen to be looking at some right now, not that PHP is anyhow better), I can write a webservice in notepad in a dozen lines of code.
This is what we've lost with the rise of the IDE - you may think your IDE is wonderful and allows you to do all manner of fancy things, and it takes away a lot of the burden of coding.... but you only think that because it's added that burden in the first place. VS will auto-generate all that crap for you and say "look how good I am to you", when really you should be thinking "what a load of crap you've dumped on me".
VS is a good IDE though, but its much better for writing C++ code that (yet) doesn't need the crutches VS gives you as a C# developer.
as everyone will say - you modularise your code so you have a hundred components each with 100 source files (a number I pulled out my ass but serves to describe how you can maintain a grokkable number in your head) and you have a system with 10,000 source files!
Naming conventions are good, as are logical separations, but another approach is to have a language that requires fewer files! I look at the .NET code in my IDE and see the simplest of simple projects has a multitude of crap scattered all over it - assemblyinfo.cs, app.config, app.manifest, and that's before I even see code (I'm ignoring the special files created by VS itself, like the .sln, .csproj, .vssscc etc).
I've been coding for years, and I managed perfectly fine with a bog-standard editor that didn't have any kind of lookups, intellisense, etc. I had "find in files" and that was enough :)
and I recommend another one: nodebeginner book, free on their own website with a link to a paid bundle on Leanpub.
Leanpub seems to be the thing the OP wants - simple ways to take payment for ebooks in multiple formats, low royalty overhead, and can offer free versions too.
for the smile at the end; to you sir, I owe a beer.
cheers!
ok, and you're right about self documenting... I'm sure that fad is just an excuse for people who don't want to do a professional job...
However, there is no "good style", they're all as good as each other - I mean some people like K&R braces because they use the indentation for block scope, and putting the first bracket on the same line reduces the amount of extraneous lines that clutter the ease of viewing the indentation. So its not a bad style at all, even if you don't like it.. it is quite a lot like Whitesmith's style though, and has the advantage of being more commonly found in the wild.
So you should modify your code to fit with Drupal's style, simply because you're wrong to say they're not as good - the only bad style is one that doesn't fit in with the rest of the codebase, and that makes (in this instance) your style a bad one. So embrace their style for your Drupal plugins and keep your style for your other projects.
not really - he means be consisted within a project, so if you decide to use _ in names for example, and create int my__variable then do not create int MyNextNewVariable afterwards. (or vice versa).
This applies to all projects, so if your coding standards say always use underscores in naming, and you have to work on existing code that uses pascal case for names, then you use the pascal case - not the standard. The point is that all the code needs to be roughly the same style in a project but it really doesn't matter what that style is.
Reformatting only really deals with syntax of the code, which is trivial stuff - braces in certain places etc, using one will screw your source code diffs, and will not help you with other parts of the code style. So they're a bad choice. But the flexibility to change styles is good advice.
why stop there? If you're worried some members of the team won't be able to understand someone else's code... then let them all write in Visual Basic, just to be sure.
sounds to me like a professional who is interested in doing the work, not arguing the toss over the latest trivial fasions to hit the coding industry.
You can work with code written in many different styles. Lots of people do it all the time. Think it cripples your ability to do good stuff?
Then think - what happens if you are exposed to code a different team wrote, using a different style guide. We've all worked with sample code on the web, tutorial code, library code written by someone else. Strangely enough they don't all follow your coding style, and you can read them all perfectly well.
So by mandating a single style, all you're doing is stopping you from maintaining your flexibility to work. Like I can no longer really get anywhere without my satnav, a rigorously enforced holy-style-guide will just kill off that part of your mind that used to deal with code written in all kinds of styles without problem.
The best thing to do is just scrap them entirely and rely on the team's code reviews to deal with anything nasty that someone puts in. The rest - working and no problems.
Of course, it does rely on everyone cooperatively working together, which kind of excludes those asperger's weenies who insist everyone else must work like they want.
yes and no :)
Windows is a good product nowadays, and the Windows division is certainly full of excellent engineers. Too bad the guys who wrote Explorer shell extensions (and explorer itself) wouldn't know a clue if someone took a large one and shoved it up them!
But the problem with running an OS isn't that is runs "clean", you have to install products to make it do the things you want. The biggest problem I have with Windows nowadays is complexity. An OS should be as simple as possible so there is much fewer areas for things to go wrong, unfortunately Windows has a lot of incredibly complex pieces that make me not trust it nearly as much as I used to.
For example, I had the misfortune to install SQLServer 2008r2, and the install failed
(I think it was a conflict with an existing sqlserver 2005 install, but of course, you can never be sure, even though its described as safe to install side by side). Anyway, I tried to uninstall it and it failed. So I went on the web to get instructions on how to manually get rid of it so I could try again... and that's where the problems really started. I was seriously considering a OS rewipe at one point. In the end I found how to remove the pieces from the registry - it involved searching through the installers key for guids used in the installation, then taking the first 8 characters of the guid and reversing them to find the corresponding entry in the installer.
Once they (and all the obvious bits) were gone, I managed to run the installer again. I'm sure you're reading this thinking "no way", but alas, its totally true - google for it and you'll see other people having the same problems.
And you can see this complexity if you run some debug traceing tools. Fire up SxsTrace and look at the log it produces when you run a .NET app - hundreds of lines of it simply looking for the assemblies to load. Hundreds! Whatever was wrong with search the path for matching filenames?
That's the difference - Linux will search the path and you will know exactly what it's doing. Windows will fill a log file with thousand lines and and you won't know what it's doing.
That's my problem with Windows nowadays.
Ximinez: Hm! She is made of harder stuff! Cardinal Fang! Fetch...THE COMFY CHAIR!
[JARRING CHORD]
[Zoom into Fang's horrified face]
Fang [terrified]: The...Comfy Chair?
[Biggles pushes in a comfy chair -- a really plush one]
Ximinez: So you think you are strong because you can survive the soft cushions. Well, we shall see. Biggles! Put her in the Comfy Chair!
but Ballmer used and threw an office chair - see, he managed to fuck up even this simple act of corporate motivation.
Ximinez [with a cruel leer]: Now -- you will stay in the Comfy Chair until lunch time, with only a cup of coffee at eleven. [aside, to Biggles] Is that really all it is?
Biggles: Yes, lord.
Ximinez: I see. I suppose we make it worse by shouting a lot, do we? Confess, woman. Confess! Confess! Confess! Confess
ah... well, I suppose he does try to make up for it by shouting a lot.
ohhhh shit, the world's just been turned upside down - Unix is for personal, hack-style users and Windows is for mainframe, secure datacentre applications?! :)
Of course you're right - Dave Cutler did a great job with the original WNT, and Linux was a crashy bit of crap for many years, but things change and Linux had a load of good engineering put into it, and WindowsNT had a load of crappy engineering put into it.
So today, the faults with Linux lie in the original design flaws, and the faults with Windows lie in the bodged up crap that was added by other teams in Microsoft. (however, I'd take a slight contention about Windows NT security model - it started life really well, simple to use and understand. Today even running as administrator you don't have administrator privileges, then there's the overly complex way of applying some security aspects, and then there's the different models of security that just don't use the underlying model that worked so well - for example I once attended a course from MS about MTS and in there they talked of security roles. I put my hand up and asked "why have roles when you could have used Windows groups?" The guy ummed a little, gave a little laugh and said "ah yes, I see where you're coming from with that... next question"). Obviously some team at MS had decided to roll their own security system rather than rely on the underlying thing, and this is what still happens today.
You're gonna need two hands to hold this bitch
I guess you'll have to work the touch screen with your nose (yes... except you with what you're thinking, sir, need therapy!).
(Unless you're one of those idiots who always runs Windows apps maximized to full screen no matter how big it is.)
you mean Windows 8 users who cannot get Metro apps to run in anything other than full-screen (ok, except for a little 2nd window)
I don't think an interactive table is much good for a desktop replacement - where would I put my coffee mug? If anything, it will be a flat-screen, slightly angled for view that you get like some news anchors have in their desks.
but once profits start to drop, Microsoft might be profitable but investors will start to walk away, and the share price will drop, and that will make people panic, and then Microsoft executives (who have millions of shares and will see the red) will start to do crazy things.
Look at Nokia for an example - symbian and feature phones are hugely profitable, yet the CEO says "they're sh*t" and next thing you know, they're not selling anything and are heading for ecven more layoffs and probably a takeover from Microsoft or Apple for peanuts. Do you think Ballmer could manage to achieve this? You bet.
I think you mean 80% of apps uploaded to the windows Store have not been downloaded...because they're stuck in the acceptance loop and not passed. See what the blogger said the Microsoft engineer said about thousands of apps being stuck, that's why it took so long for his app to fail each time he uploaded it - the servers are maxed out with a huge backlog of failures.
Microsoft has a huge chance to alienate developers... and are embracing it wholeheartedly.
no, its not. Its like an alcoholic thinking they've been dry for a couple of years and so its ok to start drinking again...
Allowing Microsoft to install only IE is much the same thing - the temptation to put just one little Windows-only extension in will be too great, and next thing you know, you're using MetroUI and wondering why your head hurts.
Its bad enough that Windows 8 will come with a single browser that works in the Metro side of things (subject to the others figuring out how to fully replace it, which they currently cannot). Can you imagine web sites that only work correctly in IE10 running in Metro?
my (next) car already has this: a split screen view so the driver can see the satnav while the passenger can watch movies or TV (with headphone support to avoid distraction)
hmm. what happened to my link?!
this blog