custardcream
2. Yes you're probably right. All out engineers bar two are male. All our QA team bar two are female. QA get paid less than engineering because the role demands less, not because they are women. I'll say that the women have a better memory and attention to detail and the programmers have more patience and work better together.
3. No he wasn't. He was representing himself.
Fed up of this argument. Its horse shit propagated by a few people.
Throwing some science into it, if we weren't specialised into genders we would be hermaphrodites. We're not equal and that's why the majority of us form couples and step forward together.
Everyone offended with everything and everyone reading about what they should be offended about in a media outlet using one liners suggesting that they should be remembered for a clothing choice rather a scientific achievement all so that in future some groups can maintain moral superiority via public humiliation for their own agendas.
Edit: Oh diddums I upset the PC squad.
Edit 2: Oh the maturity. Some of my other posts have been downvoted at the same time.
http://blogs.msdn.com/b/lukeh/archive/2007/10/01/taking-linq...
AFAIK only .net will which is not visual studio.
Oh and most problems are solved or canned so all we're doing is gluing things together and making it look pretty (which is what programming via abstractions is all about).
1. Firstly there are competing platforms on which to deploy your programs. This means there is little common ground between the three major sectors of the market. You either have to pick one and lose market share or pick all and increase cost. Nothing (yet) has solved this problem adequately without increasing cost or decreasing agility and/or quality and consistency.
2. Each of these platforms has many barriers to entry from subscription fees, having to buy specific hardware and learn how to use it, distribution and vendor costs, QA cost and the risks of rejection and having your product closed suddenly.
3. All of the markets are primarily consumer oriented which makes deploying things to corporate entities a pain in the backside requiring more hoops to jump through.
4. None of the programs have longevity, a stable platform to run on, security guarantees or predictable security evolution.
So at the end of the day, you're pitching programs sold behind a walled garden by someone who wants a slice of your cash and doesn't give a fuck if the device works after you've sold it versus a platform with zero entry cost, total ubiquity and importantly absolutely no distribution or sales model at all so you can build your own?
Nope.
People take apps because they're cheap, free or the vendor is pushing them. That's it. If it wasn't the case, the first thing we'd do when we unboxed a mac or a PC was download and install facebook. Which we don't do.
As for mobile first everything, not a chance.
I suspect we'll see a new 100% managed code IDE in the next 3-5 years that will fit this area nicely. It'll have bits of Visual Studio in it and it may even be called Visual Studio but it won't be what we have now.
I think to be honest that some of the stuff Microsoft have been working on behind the scenes is probably scaring the crap out of Apple and Google. There's not been a platform as holistic and complete as Microsoft's offerings so far and they are adding REAL value daily rather than just moving the chess pieces to great fanfare.
I use Firefox for everything because there is no central motivation to specialise. If a site doesn't work well, it doesn't get my business.
You need chunks of glass at the moment regardless of sensor size. I carry a basic DSLR around with me (D3100) and a decent but cheap lens (AF-S DX 18-55) and a shit smartphone. They cost less than a good smartphone and the results are amazing.
We had a system wide thrashing problem with ReaderWriterLockSlim which doesn't work properly under load. Took 15 mins to log into the box to blast the process. Couldn't even get any performance info out of it. Happens on a JVM on Unix; no problem.
For ref the concurrent collections should not be trusted under heavy load in processes with more threads than CPUs. Its to be honest piss poor quality.
At best you get a minidump out of a CLR process that is misbehaving and take it to bits inside VS. You may or may not catch it doing bad things. Most likely you'll find yourself with half the threads inside win32 and an 20 mins wait for symbol server to snag the symbols.
So we might see SharePoint for Linux yet.
The other two I suspect are very tied to win32.
There's nothing wrong with postulating and analysing it, even if the views are perhaps unpopular. Nothing should be beyond discussion even if it's uncomfortable for some people. Without making a judgement (I have no opinion on this myself), all arguments need contrast.
It means 1 indent, not 8 spaces, 3 bananas or one tree. It is a unit. How the user displays that is up to them.
"A key on a computer keyboard that, when pressed, inserts a special ASCII character used for formatting text, as in indenting a line or block of text."
Actually going back it means tabulation which was an early form of alignment of tables on typewriters. The tab key advanced the carriage to the next tabulation point. It was repurposed as a way of indenting code later and it has become an additional definition of that fact.
(I'm old enough to have owned a typewriter, a nice Selectric one as well ;-)
Groups of spaces and tabs are semantically different. Tabs mean indentation. Spaces mean spaces.
There were no complaints.
Sometimes you just have to push it.
To be honest windows (NT series) operating systems were pretty trouble free in the NT4 era. The masses of fragmentation and numerous paradigm shifts were what broke it all for me.
An example: I opened a case when IE9 was in developer preview with partner support. When they rewrote the download manager in IE for this release they changed how download prompting worked and removed a setting from the UI (and left it in the registry). This broke ClickOnce launches entirely for over 2000 users for us. Fast forward nearly 5 years and it's still broken, the case is still open and to get everything to work for the client we have to frig a registry setting on every workstation they roll out. That sucks for us and the client, badly.
This is a typical story for us. When you deal with VSTO, MSI packaging, managing large clusters of windows server machines, random bugs that just blow up in your face suddenly after working for years, signing code, trying to get repeatable builds out of a CLR solution and automating all of these things, forget it. PowerShell gets you 80% of the way there but the last 20% is a tar pit of pain and impossibility.
Now I've been in the Microsoft ecosystem for 20 years, certified and bought into it all. Perhaps I'm bitter and tired but I can't see past all this experience and have mixed memories of c#. All I see is hung instances of visual studio and working out which project file is buggered and all this is destroying the best language I ever used. I don't want to waste my life on giving them another chance.
There is literally none of the above on Unix platforms from experience. I've only encountered one bug in the last 15 years due to a CIFS kernel bug and RH fixed it within two days. I haven't had any automation friction at all.
I'm worn out and confused to be honest when I read back this post.