If your first priority is your kids, your first priority is not your work. That's fine, it's a choice, but there is a frequent claim that the massive incremental time demand of kids makes one so much more time efficient at work that it more-than-compensates. Insofar as one is the same human being, with the same energy reservoirs and time management skills as before your child was born, this is unlikely.
I understand the reason this fiction is maintained: people with kids need the job even more than people without, and have an interest in denouncing people who claim kids make you less productive. There's also the second order effect in which "with kids" is correlated with "older".
The net of it though is that devs with kids tend to assign work a lower priority, to take fewer risks, to need more money, and to be older and hence less familiar with new technologies (and too busy to learn in their free time).
Society doesn't have a good answer for this situation yet. In times past, technology didn't move so fast that experience was mostly obsolete (and hence useless) in a decade's time. A 40 year old farmer with kids in 1713 would probably have much to teach a young whippersnapper. The same isn't true for a 40 year old programmer with kids in 2013.
If your experience of programming becomes worthless after 10 years, then you probably did not focus on the good skills. I don't see how learning how low level hardware works, some time tried languages (C for example), data structures, networking details, debugging protocols of all kinds, structuring programs, working in teams and so on and so forth... could become worthless.
For the idea that parents and older programmers have different priorities, that may be true, but you downplay experience way too much. That said, trying to find 150% dedicated younglings, that don't spend a lot of time on side projects and just enjoying life is not that easy either
Since you felt free to generalize us parents, I will feel free to tell you that people without kids are generally way behind us parents in terms of maturity. That might not matter in entry-level jobs, but is quite essential when you climb up a bit.
...fighting an overgeneralization with another overgeneralization - if one were to write a "starting flame wars guide for dummies" it should be the top of the bullet list :) (thankfully this is not a topic people start flamewars in)
"Maturity" is an ambiguous and contextual concept that doesn't usually mean anything - people should be rated by objective attributes like experience, productivity and so on. One could also say that a younger person with more and harsher life experience can be more "mature" than someone older and with kids (think someone who raised his/her little brothers by mistake after the parents got killed or something like that), but with less impacting experience but it would be just as meaningless because of the ambiguity of "maturity" (how much is life experience relevant to a programmer?). Raising children teaches one useful "life things", but so does starting a business, travelling around the world or working for the red cross in Africa. Adding insult to injury, managers tend to use "maturity" when referring to employees as "ability to take orders and act predictably even if not particularly creative" which basically makes it an "antiquality" for a small fast startup.
> experience was mostly obsolete (and hence useless) in a decade's time
I'm 28, which means I'm young enough that even people like you believe I can learn new tricks. As far as I can tell, my brain is still fully functional. That said, most of what I use every day, I learned over ten years ago. Computer science never gets old. The notion of indirection is never obsolete. The mental machinery required to navigate up and down in an abstraction hierarchy is universal. Sure, I learn new APIs every day, read about new programming paradigms (hey, functional reactive programming is cool), and so on, but I learned all the basics way back when.
Would you say that all my older experience is worthless? If your hypothesis were correct, I should be able to say that what I'm learning now is more important than what I learned in 1998, and that's just not true.
Even technology-wise, a lot of the knowledge you got 10 years ago could still be applicable. For example, as a result of having learned webdev in the '90s, I actually know how to manipulate the DOM and work around cross-browser issues even when jQuery isn't available, which it is my impression a lot of professionals have no clue about these days. Similarly, I learned Objective-C and Cocoa about a decade ago, and I know others with grayer beards than mine who learned it almost a decade before that — I would say that experience is actually more valuable in the modern development landscape than it was back then.
I bet the "inventor" of the "cloud" thought it was some new discovery too. Those of us useless 40+ people with evil kids and no skills left know different, and smile...
What are you basing all of these assumptions on? All you've contributed to the conversation is more stereotyping. If you have something to cite I'm happy to look at it.
Most of the assumptions you've made don't apply to me, a 40 year old father of two. It may very well apply to some people similar to me. This is the problem with stereotypes and the problem with people perpetuating them. Oversimplifications are a shoddy mental crutch to deal with the complexities of reality.
What the OP wrote is the same kind of thing I'd have said at 22, before I knew any better. Now 32 (and, at least for another four months, childless) I turn a little red reading it.
The older you get, the more experienced you become, the better decisions you make, the more valuable you become.
At 22, I was a great tactician. I could code faster than anyone else.
At 32, I'm a moderate strategist. I code slow than when I was at 22; but my productivity is far higher.
At 52, I hope to be a great strategist. The potential is frightening.
I concur. I'm 34, been programming "properly" (think C, C#, JavaScript, Python, Objective C etc) for over 20 years now, and I've noticed that in the last couple of years most of my productive coding time is just thinking.
3 hours of sitting thinking about a problem, then 30 minutes of coding. I would never have done that at 20, I'd have opened an editor and started typing because I was still learning the intricacies of the platform.
..and now I can think of several good ways to implement something, weight up the pros and cons, discuss them with another experienced colleague, and then pick the best one..
In my late teens/early twenties, I just implemented the first thing that I could think of.
Back then it was much easier.
Actually, I have noticed that other developers around my age still think like I did when I was in my twenties. Maybe it's because I've been coding since I was 10 (22 years!) and full time since I was 17, and most came in after university?
Totally agree, I'm the same. I have a real feeling that the years spent between 10/11 and 15 when I was mucking around doing a really bad job in C have given me a foundation to build on which many developers have to build in their twenties.
Then there is the argument about blindly learning to code from BAD code on the internet, whereas we had to learn from books! :)
Employees who are parents are less productive. Logically, it follows that there would be measurable degredation in society over time, as long as workers keep procreating. Society's decline is irrefutable.
I hope the explanation for your post is that you're 17. This blatant generalization is idiotic and useless. Reading that reply is a denial of service attack on productive thought.
When will we get it that in real life, people don't have "first priorities" just as they don't have "arch enemies"? :) Really, any sane not-overworked not-burned-out team will benefit from older more experienced devs in it. If you're overworking the shit out of everybody, of course that the older-with-kids guys will underperform. But if you are overworking people like hell, it probably just means that you are doing things very inefficiently and compensating by "sheer work power" and shooting yourself in the foot by making the experience holders work at 40% of their top performance because of the environment (ok, I agree, this might be a good trade-off for some businesses). Chill out a bit, do things the right way and at the "natural" pace and you don't need to care about this "problem" or use the nine-to-five-with-kids stereotype. As one wise man told me once: you can't "move fast and break things" kiddo, because all that time spent fixing the things you break actually means that you're not moving as fast as you can or fast enough.
LOL at technology moving fast and experience becoming obsolete in "a decade's time." I'm not even that old--I started programming in the late 1990's--but I've been programming more than a decade, and as far as I can tell all that has happened to mainstream programming technology in that time span is bike-shedding. There has been basically nothing new in mainstream programming since about the 1980's ("Oh, NewtonScript looks like C now instead of Pascal, and we're calling it Javascript? That's nice.") In many ways it's gone backwards (the sorry state of Javascript IDE's relative to Visual Studio 6.x not to mention Smalltalk IDE's a decade older than even that). "Oh, you can use threads in web apps now? Like you could in Win32 apps since 1995?"
To a first approximation, all this new "web technology" is just a way of doing what you could've done on an internet-connected NeXT machine 20 years ago, only more brain-damaged and frustrating to work with.
The only place technology has advanced in that time period is in domain-specific areas (which of course requires experts, not young whippersnappers), and infrastructure (the world looks a lot different for computers with pervasive 4G--the software is just an adaptation of proven concepts to uses enabled by innovative hardware).
Programming is applied mathematics, and that hasn't changed substantially since people were developing software on punch cards.
The main thing that's changed for what you call infrastructure is that a massive proportion of people are connected from a plethora of different devices on different kinds of networks.
That wouldn't have been possible without the web. The web technologies you decry are more irritating in many ways than any one specific proprietary system from 20 years ago, but that ignores some of the huge benefits of openness and standards and platform independence.
I can write a program and have it run without modification on my phone, on an embedded computer running sensors, on a tablet, on my laptop, my desktop computer, my hifi, my network hard drive, a huge server being rented to me on the other side of the world. I can even make it easily distributable so it can run safely on other peoples computers who don't fully trust me. It's unimaginable that any proprietary system from 20 years ago would have been able to produce that state of affairs.
I do agree that open standards are necessary to make the modern web work, but those aren't advances in technology per se, they're advances in organization. There's no technology in HTML/JS/WebGL that didn't exist in SGML/Obj-C/OpenGL. There are no breakthrough new concepts that "old programmers" have to wrap their minds around. Rather, it's just the organizational process of agreeing on the color of the bike shed (in this case puke green). Don't get me wrong, organization is important, but standardization isn't technological change.
I agree with the core point about experience remaining relevant, but I think you underestimate the changes that got us here. For example, we've learnt a lot about jits in the last 20 years. The fact that we can write interpreted code that can achieve near compiled speeds in certain situations is amazing.
Speed of interpreted Javascript has improved by two orders of magnitude on the same hardware in the last ten years, and you don't see technological advance? I can't think of another field that has advanced so quickly.
I don't want to diss other fields, but an awful lot of the most valuable improvements in infrastructure in the last ten years have been about standardization and bringing technology that existed years ago to the masses.
On top of that, the inconvenience of the Web platform is real but also overhyped. Imagine you're writing a network app in another platform. It's extremely unlikely you have access to an integrated network analyzer as good as chromes. How many other systems allow you to completely modify the look of your application while it's running just to see how it looks by playing with the developer tools? Having a repl that allows you to interact with the running system has been standard on the Web platform for ever.
I'm not even sure what you're looking for. What would constitute new technology if 100x speed ups don't? Almost all of software is implied in the concept of the Turing machine so complaining that you can't achieve anything you couldn't have in the past with large, expensive, proprietary systems and specialized knowledge seems unfair. It's been true since Babbage at least.
Things like the CAP theorem, monads, functional programming and distributed systems knowledge, programmable graphics pipelines, and the pervasiveness of unit testing and CI infrastructure certainly look like advances in mainstream programming technology to me. Are you sure you're not defining "mainstream programming technology" to mean "what I know", and arguing that you don't feel like you know much more than when you started programming?
Functional programming is neither mainstream nor is it new. It dates to Lisp in the 1960's and was refined by SML in the 1970. What's new in the mainstrea of distributed systems? Programmable rendering pipelines date to renderman in 1988 if not earlier. I don't know what to tell you if you think unit testing and continuous integration are new.
"I can write a program and have it run without modification on my phone, on an embedded computer running sensors, on a tablet, on my laptop, my desktop computer, my hifi, my network hard drive, a huge server being rented to me on the other side of the world. I can even make it easily distributable so it can run safely on other peoples computers who don't fully trust me. It's unimaginable that any proprietary system from 20 years ago would have been able to produce that state of affairs."
As someone who has written j2me applications, I can tell you that you couldn't run them on the desktop except in an emulator, so no, you couldn't take one program and run it across all those systems.
Java failed badly at its dream and ended up adopting an entirely different niche to what was expected.
But you're right, I shouldn't have said 'unimaginable'. I suppose it's just about possible that if java had 'won', we might have ended up with something not massively dissimilar to what I described.
This doesn't add up. I started programming in late 80-ies, I've learnt Forth, C, WinAPI (I started seriously developing Windows programs with 2.0! Gosh, how old I am...), then moved to the brighter side, learnt C++, LISP, I used ksh and vi (never was smart enough to master Emacs), used sccs and then rcs, wrote my own implementation of TCP, did some embedded work in C and asm, etc, etc etc.
Given that list, what would you consider obsolete now? It's been 2 decades, not 1, mind you. Asm? Well, the last time I touched this sword for a reason was 2005 and it was SSE assembler, something that compilers were not able to generate efficiently then (and to the large extent still not able).
Yeah, like very quick lowercasing of blocks of ASCII text, 8 characters at a time:
char *strlwrmmx(char *buffer,int len=-1)
{
if (len==-1) len=strlen(buffer);
unsigned __int64 a=0x4040404040404040; // 0x40='A'-1
unsigned __int64 z=0x5B5B5B5B5B5B5B5B; // 0x5B='Z'+1
unsigned __int64 c=0x2020202020202020; // conversion offset for lowercase->uppercase
asm {
mov edi,buffer
mov ecx,len
convblock:
cmp ecx,8
jl rest
movq mm4,c // Eight copies of conversion value
movq mm2,a // Put eight "A" characters in mm2
movq mm3,z // Put eight "Z" characters in mm3
movq mm0,[edi] // Get next eight characters of our string
movq mm1,mm0 // We need two copies
pcmpgtb mm1,mm2 // Generate 1's in MM1 everywhere chars >= 'A'
pcmpgtb mm3,mm0 // Generate 1's in MM3 everywhere chars <= 'Z'
pand mm1,mm3 // Generate 1's in MM1 when 'A'<=chars<='Z'
pand mm1,mm4 // Generates $20 in each spot we have a l.c. char
paddb mm0,mm1 // Convert uppercase chars to lowercase by adding $20
movq [edi],mm0 // Store back in buffer
sub ecx,8
add edi,8
jmp convblock
rest: // convert any left characters one by one
cmp ecx,0
je done
convchar:
mov al,[edi]
cmp al,'A'
jb skip
cmp al,'Z'
ja skip
add al,0x20
mov [edi],al
skip:
inc edi
loop convchar
done:
}
return buffer;
}
A text indexer. It did case-insensitive searching, so I lowercased everything (both source text and search terms), allowing me to use a quicker substring search (i.e., no need to compare characters with case insensitivity).
The indexer had to chew huge amounts of text, so the quicker the lowercasing, the better.
There's so much wrong with you condescending and arrogant post that it's hard to know where to begin.
Where do you think bad, old developers come from? Well, they started off as untalented young developers. Right now now there are young developers who are awesome and others who suck and will one day become crappy, old developers.
I could go on about stories where youth and inexperience led to disasters. They would be just as one-sided as talking about old developers who are out of touch. Who do you think it is that's creating all if the tools that you use?
Somehow, despite having kids, I manage to learn new technologies, even insofar as I was able to write a book about it (Dart in Action). The only reason I had time to do that is because I try to keep my day job between 9-5.
I'm not yet 40, just 35 with 2 kids. I don't agree with any bit of what you wrote.
1. As many people noted - experience is NOT obsolete. The same few concepts re-occur in every software language. You need to learn new APIs and new syntax, but that's total non-sense for good experienced people.
2. People with children have a better understanding of what responsibility is.
3. People with children usually spend less time on dating and going to bars :)
Ah yes, 20-somethings without kids are famous for having work be their first priority.
Having kids can put a lot more structure into a life that was missing it before. 20-somethings without kids are usually the ones late in in the morning, missing standups, or the ones working while hung over.
I'm sure that it is possible to get someone who is so dedicated to their work that they have no life at any age. Whether or not this is a good idea for your company is a different question.
Is it reasonable that we try to build a IT-industry where people can have a family and kids and still be considered productive? Do you plan on having a family and kids yourself one day? Will you change job and start selling bananas that day?
I know of very few other jobs were you are supposed to spend so much of your spare time reading up on new stuff as the IT-business. A few of my friends are physicians and they to spend their spare time reading up on new stuff. Others, not so much.
I don't think this is a sustainable way of doing business in the long run.
Insofar as one is the same human being, with the same energy reservoirs and time management skills as before your child was born, this is unlikely.
Your whole post drips with resentment-fueled bigotry and ignorance, making me wonder if you're fighting for attention at your workplace or whatever, feeling unloved. Here's an internet hug. Hugz.
Many years back I -- a new graduate employee -- was chatting with my boss, who was a part owner of the company/president. He had five kids, or maybe even six. He asked me when I was thinking of having children (it was still too early for me, but just as a conversational thing), and my honest answer was that I didn't know how he could afford it.
He then told me about an Arabic parable or the like that each child comes with a bag of money.
That seemed counter intuitive to me, but my life has proven it out. I now have four children, and I would wager good money that I know more current technologies, in much more depth, than you do.
If you have the capacity, having children has a profound ability to make you focus: While I am the same intellectual being, like the vast majority of developers I was absolutely pissing time away before children, and I doubt I passed even 5% productivity. Slashdot was the Reddit of the time, and doing asinine, meaningless implementations for days on ends was just a normal day. And I know this is the case for most developers.
Now I don't have time for the bullshit. I focus specifically on the things that yield success, in the most efficient manner possible. I'm still only maybe 15% productive (still piss away a lot of time), but the result is my own company, a lot of success, etc.
Your words exactly mirror my experience after having my first child, too.
I still waste time, but I've never been more productive. I work full-time, have my own company in my spare time, and my child at every moment he's awake.
> He then told me about an Arabic parable or the like that each child comes with a bag of money.
I can see how an empathetic person having children would increase their focus to succeed, but what is the limit on the number of kids? How would one know when to stop having kids? Why did you stop at four kids? Are you going to have more?
While indeed the story as told sounds like I am promoting copious reproduction, really one child fulfills the meaning of the parable: Many if not most of us operate at a very low level of effort, and succeed to some degree regardless. Having a child (which really is a surrogate for "having a reason to pursue success", which to others might simply be intrinsic drive) seems to make many focus the effort and improve efficiency.
We didn't expect our third child, or the fourth for that matter. That's life though, and I'm a very roll with it sort of person and am extremely pleased with how things have turned out.
Of course I am speaking from a very privileged position of happening to have the right sort of mind at the right moment in history in the right situation where I can talk about pissing most of my time away and still achieving what many would consider a lot of success. This obviously doesn't apply to all careers or all people.
"If your first priority is your kids, your first priority is not your work. That's fine, it's a choice, but there is a frequent claim that the massive incremental time demand of kids makes one so much more time efficient at work that it more-than-compensates."
I am not young. I've been attending funerals recently, and meeting family members I have not seen for 30+ years. None of us were comparing notes about our productivity.
The claim about technology moving faster now is absolute garbage. We've had exactly two major pieces of innovation in computer science in the last two decades.
The first was in search and distributed systems, at Google, and the blueprint for their systems was created by two mid-career engineers out of DEC.
The second was the evolution of the smartphone, at Apple, an old company that is known for keeping its engineers for a long ass time.
The most innovative computer language we have was designed in the 50s, and every time I meet an old-time hacker, there's something I can learn from them.
The real lie is that a kid out of college who starts a company is automatically considered an innovator. Rehashing an idea one more time in a slightly more marketable way or creating an app that goes viral has nothing to do with innovation.
In the pop culture age, we constantly confuse the Britney Spears' of the world with real talent, and the Summly's of the world with real innovation.
I couldn't agree more. That one phrase was the only thing that bugged me. As if having kids suddenly made me a lower quality coder. I wonder how many of the seasoned veterans that the author lamented losing had kids.
As people get older, they get more experience, which is good. They are also more likely to have a family. Is that supposed to be bad?
Some of us are 9-5 types without kids. I strongly believe that the work yourself to death model isn't healthy, and in my experience doesn't lead to the best code long term either. I see it all the time from college hires though.
I'd agree. I know the OP is trying to spread knowledge and this is a great read, but I think this was slightly rude, not to mention questionable fair use.
There's no "fair use" argument at all. Copying an entire work, then distributing it with no transformative change or criticism, is inexcusable infringement should the author want to enforce his rights.
What's wrong with 9-5? Can't you be passionate about what you work on, excel in you career, yet stick to dedicating ~50% of your time awake to your job?
That sounds like an organizational problem to me if you spend 75% of your time at meetings everyday instead of coding (if coding is actually your job).
Unfortunately that kind of thinking is no longer only an American thing. I see it more and more every day. Employers are pushing fresh college grads to work as many hours as possible for a low wage just so they can have a bigger profit. If they burn out, there are others to replace them.
It's amusing watching Americans boast about working past the norm 9-5 hours and calling the rest of the world lazy. My response, "What are you proud about? After working twice as hard, you have the same quality of life as friends in Canada, and statistically speaking you'll drop dead sooner because of stress."
While I agree with you, nothing could wipe the smug grin off these persons' faces. They are beyond reality, and I'd be much happier with America if something so simple could give the "socialists are universally lazy" rabble whenever labor rights are mentioned in any sense.
> Another reason for the quality gap is that that we've been having trouble keeping talented people. Google and other large Seattle-area companies keep poaching our best, most experienced developers, and we hire youths straight from college to replace them.
I will say all of the ex-Microsoft folks I've encountered at Google Seattle have been fantastic.
On a related note, it's stupidly easy to get code accepted by another team at Google.
Too bad you guys don't seem to give a second glance at someone without any formal education, despite working on systems for government, training, banking security and airline industries.
I have zero formal education past A levels, but I've had two in-person interviews at Google and had an offer, and I have their charming recruiters chasing me to make sure I wouldn't be happier working for Google every 6 months or so. :)
It does take a ferociously long time to get through the initial screening if you just send them a CV, and I'm sure a lot of people fall through the cracks - my suggestion would be to find a Googler or Xoogler and ask them to recommend you, I understand you get a lot more traction that way. Chin up.
"Too bad you guys don't seem to give a second glance at someone without any formal education, despite working on systems for government, training, banking security and airline industries."
I find it doubtful that your lack of education alone is what's keeping you from getting a callback. Do you have a portfolio linked from your resume? Have you got friends that work for these companies that are willing to go over your resume with you?
> On a related note, it's stupidly easy to get code accepted by another team at Google.
Unless that other team is Android. Though then you could submit to AOSP directly (assuming the issue you are addressing wasn't fixed internally 4 months ago, but how would you know?).
I look forward to further entanglement with a hiring process much more toxic than Microsoft's. Plus the joy of being hired for a mystery job where all my Big O knowledge goes to writing scripts for placing free porn ads.
I think there are two complementary parts that Linux gets right here. One is as cited in the article, that you get personal glory for improvements you make to the kernel even if they are fairly small. The other part is that there is for Linux someone who will say "no" to a patch. Linus will certainly do it, and other trusted devs will do it too. Linus is perhaps even famous for telling people when they are wrong.
I've seen a number of open-source projects where you get all the personal glory for your additions but there is nobody who takes the responsibility to tell people "no". These projects, almost universally, turn into bloated messes over time. Open-sourced computer games seem to fall down this path more easily, since everyone and her little dog too has ideas about features to add to games.
> Open-sourced computer games seem to fall down this path more easily, since everyone and her little dog too has ideas about features to add to games.
I just listened to an episode of Roguelike Radio from the mid-30s (maybe the one with Red Rogue or Thomas Biskup) and Andrew / Keith (IIRC) go on and on about how all the "major" roguelikes are just accretions of features.
This rings very true to me; I grew up playing Nethack [0], and Slash (and then Slash'Em) just got silly with all the things they were adding. Light sabers ? In my roguelike ? Come on, fhgwgads. Nethack at least has a mysterious Dev Team who ostensibly are the guardians of quality... but they _did_ bring Sokoban back from Slash'EM into vanilla.
[0] since Nethack was my first roguelike, I didn't realize until lately just how crappy it is in many ways, most notably that it's very difficult to win before you've figured out all the sources of instadeath (whether you've figured them out by spoilers (written or source-diving) or through (really frickin hard-won) experience).
I <3 the crap out of brogue; I'm currently playing through some roguelikes that I've never looked at before [0], and I keep coming back to brogue.
In particular, brogue's food clock is excellent in that if I forget about it too long and go back to my natural "explore everywhere, kill everything" tendency, the food clock _will_ kill me.
[0] something that jumped out at me is just how much modern roguelike development is windows-first (or even windows-only), and how much of it is distributed primarily as runnable binaries vs source. I had to bend way over backwards to get PrincessRL running: I ended up installing a 32-bit ubuntu userspace virtualbox instance so that mono could run the prepackaged binary.
Try POWDER. It's made practically by one person, and it's very well designed (inspired by Dungeon Crawl Stone Soup). It also has hands down the best writing in any roguelike. God system in particular is unique, all 5 or so gods evaluate your behavior at the same time. Gods like different actions, and whatever you do you will piss off some gods and delight others. It requires some spoilers to understand, but is very fun once you do. POWDER's implementation of Xom is intriguing - he's mentally unstable and changes his preferences every 1000 turns, first he wants you to act like a warrior, second he gets annoyed when you strike a monster in melee. Or even kill anything personally when he impersonates Pax...
But I digress. POWDER feels very much a designed roguelike, not something that evolved.
I actually enjoy working at Microsoft --- I'm in Phone, working on telemetry and various other things --- and I've met a ton of very smart people people. I've also made the cross-team (and cross-org) contributions that the OP says are nearly impossible (just today, even). While the OP makes a few good points (some teams are kinda reluctant to take patches), I think he's grossly exaggerating the problems, and the level of vitriol really isn't called for either.
He's also slightly off-base on some of the technical criticisms: there are often good reasons for doing things a certain way, and these reasons aren't always immediately apparent. Besides, change _does_ happen: Arun Kishan (who is smarter than I'll ever be) broke the dispatcher lock a while ago (see http://channel9.msdn.com/shows/Going+Deep/Arun-Kishan-Farewe...) when nobody thought it could be done.
By the way: there's actually quite a lot of information available on Windows Internals. In fact, there's a whole book, Windows Internals (http://technet.microsoft.com/en-us/sysinternals/bb963901.asp...) on exactly how the NT kernel and related system components work. The book is highly recommended reading and demystifies a lot of the odder parts of our API surface. We use it internally all the time, and reading it, you'll repeatedly say to yourself, "Ah, so that's why Foo does Bar and not Qux! Yeah, that's a good reason. I didn't think of it that way."
"there are often good reasons for doing things a certain way, and these reasons aren't always immediately apparent."
One of the issues the author seemed to be alluding to is that the loss of experienced developers makes it really hard to keep track of "line 123 of foo_dispatch.c does this because of vital business reason xyz or compatibility reason uvw" and "line 123 of foo_dispatch.c was written while I was hungover and trying to make a deadline--it looks clever, but feel free to junk it.".
This issue is compounded when you are hiring safe, and you have a culture where making gross fuckups while trying to make progress is discouraged. It is neither good nor bad--after all, I too enjoy using stable software--but there is a price to be paid if devs don't feel comfortable making breaking changes.
There are always good reasons for doing everything. But this is how you end up with a "death by a thousand cuts" scenario. Sometimes, if you want to be great, you have to be bold. Windows NT was bold back in 1995 when I first played with 3.51. It was the best OS out there by far.
Now, once you set up a system where people play it safe more than they innovate, you'll get a situation where all of the best programmers will want to leave because it's boring, and you're left with mediocre programmers who aren't good enough to be bold and innovative. This is exactly what the OP describes.
It's nice to see that internal developers feel the same way about XNA that external developers (who used to build XNA games, or still build XNA games) do.
From the outside I always assumed the constant flood of new, half-baked features instead of fixes and improvements to old ones was caused by interns and junior devs looking for glory - sad to hear that's actually partly true. I always considered frameworks like WPF (or Flex, for that matter) 'intern code' - not that interns necessarily wrote them, but they reek of not-experienced-enough engineers trying to solve problems by writing a bunch of new code, instead of fixing existing code.
It really is too bad, though. There are parts of the NT kernel (and even the Win32 API) that I consider a joy to use - I love IOCP, despite its warts, and APIs like MsgWaitForMultipleObjects are great tools for building higher-level primitives.
Plus, say what you want about GDI (there's a lot wrong with it at this point), but it's still a surprisingly efficient and flexible way to do 2D rendering, despite the fact that parts of it date back to before Windows 3.1. Some really smart people did some really good API design over time over at Microsoft...
Actually, I think one NT's largest advantages over POSIX systems is process management: yes, the venerable CreateProcess API.
See, in Windows, processes are first class kernel objects. You have handles (read: file descriptors) that refer to them. Processes have POSIX-style PIDs too, but you don't use a PID to manipulate a process the way you would with kill(2): you use a PID to open a handle to a process, then you manipulate the process using the handle.
This approach, at a stroke, solves all the wait, wait3, wait4, SIGCHLD, etc. problems that plague Unixish systems to this day. (Oh, and while you have a handle to a process open, its process ID won't be re-used.)
It's as if we live in a better, alternate universe where fork(2) returns a file descriptor.
You can wait on process handles (the handle becomes signaled and the wait completes when the process exits). You can perform this waiting using the same functions you use to wait on anything else, and you can use WaitForMultipleObjects as a kind of super-select to wait on anything.
If you want to wait on a socket, a process, and a global mutex and wake up when any of these things becomes available, you can do that. The Unix APIs for doing the same thing are a mess. Don't even get me started on SysV IPC.
You can apply memory use, scheduling, UI, and other restrictions to processes in job objects. Most conveniently of all, you can arrange for the OS to kill everything in a job object if the last handle to that job dies --- the closest Linux has is PR_SET_PDEATHSIG, which needs to be set up individually for each child and which doesn't work for setuid children.
(Oh, and you can arrange for job objects to send notifications to IO completion ports.)
Yes, Windows gets a lot wrong, but it gets a lot right.
My personal annoyance is the introduction of win32k in NT4. With per-session CSRSS existing since WinFrame and Vista+ having Session 0 Isolation, not to mention much faster processors, and the removal of XPDM and the requirement of the DWM in Win8, it doesn't make as much sense anymore.
Update: And I forgot to mention the font parsing security issues (look up Duqu), and the issues with user mode callbacks too.
"Okay, you're in charge. Are you sure you can't find a better way to deploy shareholder capital than using it to remove win32k?"
Could that be why developing an OS inside of a shareholder-owned corporation is inherently hobbled compared with developing it as an open source project?
> It's not like open source projects are known for their lack of cruft.
True, but resource allocation is distributed between volunteer contributors, sponsored contributors who may have different sponsors, downstream consumers of a project, and people involved in project governance. That can make it easier to try new approaches.
I don't think commercial vs. open source really affects that much - regardless of open-source-ness, different projects are run in different ways. Just to give two examples, surely Office's switch to the Ribbon (and putting Office Apps online) was more speculative (or disruptive, or innovative, or whatever you want to call it) than anything being done by the open source office suites. Likewise, Visual Studio 2010 represented a big break from the past with a switch to many managed APIs driving their extensibility story (including the move to WPF for their UI), which was a huge change from their existing COM APIs.
Not all commercial projects are run like Windows, and it seems to me that most of their conservatism doesn't come from lazy or shoddy or shortsighted developers and managers, but rather their large number of hardware and software partners who take dependencies on undocumented implementation details (see Raymond Chen's blog for a virtually infinite supply of such anecdotes).
Genuine question (because I really don't know) -- how do Linux GUI frameworks work without kernel-mode callbacks? What do they use instead, when they need to send messages to other windows?
X11 clients communicate with the server using Unix domain sockets or TCP sockets. Requests, responses and event notifications are exchanged as messages.
Asynchronous communication is achieved using syscalls like select and poll which take a set of file descriptors (files, special files, sockets) and block the calling thread until some descriptor from this set has new data available for reading, starts accepting writes or signals an error.
GUI toolkits repeatedly poll the X server descriptor, parse incoming messages and call application-defined callbacks.
That sounds like it's basically the same thing as Windows (GetMessage or MsgWaitForMultipleObjectsEx anyone?)... only that now you don't have the ability to use SendMessage, and need to rely exclusively on PostMessage instead.
Between threads, you rely exclusively on PostMessage anyway. You can't directly call into a routine on a different thread, so SendMessage to a window owned by another thread just posts the message to a special queue that's serviced before the regular message queue, then blocks until the other thread's window procedure processes the message.
In all boils down to message-passing: in Windows, the win32k is the trusted third party that mediates interactions between different window-system clients. In the X11 case, the X server and the window manager work together to do the same job. The architecture are fundamentally similar.
Thanks, I took a look at that... but it doesn't seem to quite explain what I meant. I was thinking more like, there's no need for SendMessage() to go from user->kernel->user, even when it's on the same thread. It could just do a system call to get the wndproc for the given window, then call the wndproc from user-mode directly.
Wouldn't that completely avoid needing to call back into user-mode from kernel mode?
It does this already when the window is on the same thread if no window hooks are installed. When the window is on a different thread, it is GetMessage or PeekMessage on the target thread that notices the sent message and does the user-mode callback to call the window procedure.
> WaitForMultipleObjects as a kind of super-select to wait on anything
Except for the 64 handle limit, which makes it largely useless for anything that involves server applications where the number of handles grows with the number of clients. So then you'd spawn "worker" threads, each handling just 64 handles. And that's exactly where your code starts to go sour - you are forced to add fluff the sole purpose of which is to work around API limitations. What good is the super-select if I need cruft to actually use it in the app?
And don't get me started on the clusterfuck of the API that is IOCP.
> Yes, Windows gets a lot wrong, but it gets a lot right.
Oh, no, it doesn't.
Specifically, what Windows does not get is that it's other developers that are using its services and APIs, not just MSSQL team that can peek at the source code and cook up a magic combination of function arguments that does not return undocumented 0x8Fuck0ff. I have coded extensively for both Linux and Windows, including drivers and various kernel components, and while Windows may get things right at the conceptual level, using what they end up implemented as is an inferior and painful experience.
As far as I see you had a contact with Win API but you haven't understood enough, based on your complaints. Moreover, why do you mention "MySQL" as the team with the access to kernel sources?
Can you than please give a technical reason for you to insist on waiting on more than 64 threads in a single API call, having simply too many threads for good performance anyway when IO Completion Ports could be used instead?
He probably doesn't have 64 threads, but he may have much more than 64 files or sockets. After all, the response was to the statement that "WaitForMultipleObjects as a kind of super-select to wait on anything". It clearly isn't, with this arbitrary limitation.
The problem with Windows is that there isn't any such super-select, unlike on Linux (see epoll, signalfd, timerfd...). You should take a look at my SO answer which lists six different ways to use sockets in Windows: http://stackoverflow.com/questions/11830839/when-using-iocp-...
Whatever he has more, waitfor is not the optimal way on Windows for that so it's still a complaint that round holes on Win32 are poor fit for his cubes. First choosing tools then complaining that they don't fit to some goal is typical for beginners.
Do tell me, oh, enlightened one, what I should be using if I have 10K idle network connections and I can't really use IOCP, because I need keep things reasonably portable. That's not even considering that IOCP is a great example of premature optimization at cost of clarity and simplicity. It tries to solve a problem that I don't have and it doesn't offer a simpler solution that would just do. It is not a "hole" for my square peg, it's a freaking snowflake.
And expecting a modern OS to have an uncomplicated O(1) API for monitoring sockets is clearly too much to ask.
It's possible to abstract IOCP and non-blocking sockets into a single interface with reasonable efficiency. For example:
- To send data, user calls Socket::send(const char *data, size_t length). This starts sending the given data; the buffer must remain available while data is being sent. IOCP implementation will initiate I/O using WSASend() or similar.
- When send operation is complete, the socket implementation calls a Done() callback of the user, and from that point on, the user is allowed to call Socket::send() again. With proper implementation, send() can directly be called from the callback.
This interface is very easy to implement on Linux. But on Windows there's a complication, because it's non-trivial to just stop an IOCP I/O operation that is in progress, in case you decide you don't need the socket any more and want to red rid of it NOW. If you just forget about it, there could be a crash when you release your buffer but Windows is still using it. A simple solution is to CancelIo() the socket and do blocking GetQueuedCompletionStatus()s until you get an event inidicating the completion of the pending I/O operation - taking care to queue up any unrelated results you may have gotten, for later processing. However, a more efficient solution is to use reference counting or similar with your buffers, so they only get released when Windows is done with them.
Yes, I know the abstraction is possible. In fact, I ended up implementing a nearly complete BSD socket API emulation on top of IOCP. Just don't lose the sight of the context, which is Windows does a lot of things right and my point being is that it doesn't.
> The problem with Windows is that there isn't any such super-select, unlike on Linux (see epoll, signalfd, timerfd...)
> I can't really use IOCP, because I need keep things reasonably portable
LOL!
You outright dismiss the solution because it isn't "portable". What does "portable" mean here? Portable in a particular platform?!
Portable between what exactly? IOCP has been there since Windows NT 3.51 -- it's "portable" between the Windows-es.
Your epoll, signalfd, timerfd, etc. are Linux functions They're "portable" between the Linux-es.
i.e. The "portable" solutions you like are just as non-portable as the "non-portable" solutions you outright dismiss, making Microsoft's Windows designers look like idiots.
You're never going to find a solution while considering the Linux platform to be the "portable platform" and Windows to be the weird kid on the block.
Sadly, you're not the only person who thinks like this.
A scalable variation of BSD socket API is supported by every major OS with a sole exception of Windows. It's an abstraction that is both simpler and more universal than IOCP model, not to mention that it also predates it by a decade.
> A scalable variation of BSD socket API is supported by every major OS with a sole exception of Windows
It's funny, you mention "epoll, signalfd, timerfd" as an example of a portable API, and then when I point out they're Linux APIs, you suddenly start talking about "a scalable variation" of the BSD sockets API. As for your "scalable variation of BSD sockets API", why don't you tell us the name so we know what you're referring to? Are you talking about Kqueue for example, or something else?
> an abstraction that is both simpler
I/O completion ports are just read-write queues... you ReadFile(), and when it's done, an item goes into the queue.
(You can insert your own tasks into the queue, too, if you want.) Now just pop off the next item in the queue and off goes your thread. What part of that was so complex compared to your portable API (which for some reason you didn't feel was appropriate to mention the name of)?
> and more universal
Can't reply to it without knowing what "scalable variation" you're referring to, and why you didn't actually mention it as an example of portability when you were actually talking about the subject. Is portability actually a concern for you or no? (If it is, why did you bring up non-portable examples?!)
One problem that the WINE project (windows emulator for unix)has is that windows is full of undocumented APIs, some of which might be really quite useful, which are used by windows internal developers.
For WINE, if you are going to write an emulator that runs Microsoft code (like the .net framework, or notepad.exe), you need to find the correct behavior of these undocumented APIs by trial and error.
For a developer on Windows, it is perhaps frustrating that MS identifies and solves problems with it's platform, but doesn't publicly release these solutions to you.
I work for some random company that makes an SDK, although I mostly make products using it. Many of our best features are hidden - we don't ship the header files with the SDK, but the symbols are there in the binaries. Someone doesn't think they are useful enough to justify the testing expense for a full release. I guess MS have the same thing.
What shall we call WINE then? A "pretender"? I'm serious btw. I've never seen a good concise explanation of the way WINE works in comparison to say, an emulator. I have a fairly good idea myself, but I wouldn't want to have to give more than a very brief talk over it.
From the WINE website:
"Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, Mac OSX, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop." [1]
I should have been more specific. How would you introduce WINE to freshmen, not CS students who might need to study WINE in detail, but well, here's a specific case, college freshmen who are expected to install WINE and then install and use software such as LTSpice, DipTrace, etc.? Or, more generally, how to explain it to neophytes who are expected to become moderately sophisticated computer users who might need to use WINE, but will probably never be software devs.
> WINE is a translator that allows Windows programs (those that have an .exe extension) to talk to other Operating Systems.
I'm sure the aforementioned freshmen would like a no-bullshit explanation for why "emulator" hurts the WINE people's feelings but "translator" does not. It's always been a mystery to me.
I'd say they've changed the meaning so they can reinforce that it's not just another virtual machine ( and that it's faster than one).
Which is true, it doesn't emulate another hardware architecture's calls, just the kernel and OS magic needed.
In that regard, think of say a console game or arcade game emulator on a computer- that will have to emulate the whole architecture of said game system as well as the game.
Contrast that to a game program for the the x86 architecture, but not for windows- you could run it natively on windows providing you change everything the game asks for that's part of the Gamesystem380 system into something windows understands, and vice versa.
No. You can complain about insufficiently documented APIs, or internal APIs that you wish you could use but are not documented, but please do not complain about undocumented APIs that are used by Microsoft applications outside of Windows.
Ever since the monopoly rulings against Microsoft, they have had extremely strict internal controls preventing non-OS code from using undocumented APIs. If a DLL or EXE does not ship on the Windows client install disk, it cannot reference APIs which are not documented in MSDN. Full stop.
You're referencing an API that inadvertently didn't get documented, but everyone knows about it, has blogged about it and lots of articles mentioning to use it? Too bad. Either stop using the API or delay release by 3 months for the next MSDN update.
What is the feeling about XNA? I haven't followed the area, so I found it unfortunate that it was treated in the original post without explanation. Was XNA a good thing or a bad thing? Why?
It was loved by Indies for XBox 360 development, got so popular, Microsoft decided to make it the way to develop games on the Windows Phone 7.
When Windows Phone 8 came out, the native renaissance was full speed inside Microsoft, C++ with DirectX became the official way and XNA was canned while Microsoft left MonoGame and Unity pick up the C# developers still willing to invest into the platform.
The sad thing is that this is not a native vs managed issue, because even C# gets compiled to native code when targeting Windows Phone 8. Just plain product management decision to kill the product, which was being sold as the way to develop Windows Phone games.
No because microsoft isn't going to support a toolkit it has no intention of using on mobile or the desktop and will never be used by commercial game developers.
The "Inside Windows Kernel" book series are quite interesting to understand on how it all works, and even some of the initial VMS influence in the original kernel design.
> I always considered frameworks like WPF (or Flex, for that matter) 'intern code' - not that interns necessarily wrote them, but they reek of not-experienced-enough engineers trying to solve problems by writing a bunch of new code, instead of fixing existing code.
This is unfair and unfounded accusation. If you look at the time frame, all the major platform were working on their first hardware accelerated UI toolkits and went through the similar teething problems (Cocoa anyone?). WinForms was a dead end, there was no fixing to do. WPF has turned out well enough, and WinRT has evolved into something very efficient (e.g. by using ref counting rather than GC).
> Plus, say what you want about GDI (there's a lot wrong with it at this point), but it's still a surprisingly efficient and flexible way to do 2D rendering
Not anymore. I get it that some love to use antique APIs and computer systems just for the sake of being retro, but when every computer ships these days with a GPU, using GDI is not even close to pragmatic.
Not the same thing! This is like comparing pre-DX8/programmable shader hardware acceleration to the fixed-function crud we had to deal with a long time ago. Ya, you can emulate fixed functions with programmable shaders, but its a poor way to make use of a modern GPU.
> When the GDI DDI was first defined, most display acceleration hardware targeted the GDI primitives. Over time, more and more emphasis was placed on 3D game acceleration and less on application acceleration. As a consequence the BitBlt API was hardware accelerated and most other GDI operations were not.
> In order to maintain compatibility, GDI performs a large part of its rendering to aperture memory using the CPU. In contrast, Direct2D translates its APIs calls into Direct3D primitives and drawing operations. The result is then rendered on the GPU. Some of GDI?s rendering is performed on the GPU when the aperture memory is copied to the video memory surface representing the GDI window.
> Existing GDI code will continue to work well under Windows 7. However, when writing new graphics rendering code, Direct2D should be considered, as it takes better advantage of modern GPUs.
The caching misbehavior of referencing counting has been greatly exaggerated, especially in the context of UI where responsiveness is much more important than raw CPU speed. Also, the ref counting tradeoff seems to work better for device (e.g. all the cool kids [1] are doing it).
.NET still does GC, it is only the WinRT APIs (something like COM) that manage resources through ref counting. There is some cool interop magic that makes this somewhat transparent to the programmer.
> The caching misbehavior of referencing counting has been greatly exaggerated, especially in the context of UI where responsiveness is much more important than raw CPU speed. Also, the ref counting tradeoff seems to work better for device (e.g. all the cool kids [1] are doing it).
Apple's ARC is a compiler hack. It only works if you happen to use set of Cocoa libraries that are recognized by the compiler and allow for some magic incantation.
You cannot make any Objective-C library ARC aware.
ARC is a good solution for Objective-C, because Apple never managed to have their GC working safely in all situations, given the underlying C type system.
> .NET still does GC, it is only the WinRT APIs (something like COM) that manage resources through ref counting. There is some cool interop magic that makes this somewhat transparent to the programmer.
True, but C++ does not and you still have the performance penalty of reference counting.
The only way to have reference counting with good performance is do what Parasol or Objective-C do, by removing unnecessary increment/decrement operations thanks to dataflow analysis.
Which is something that you cannot do just by using the WinRT runtime and need to rely on the cleverness of the compilers.
Actually, are you aware that reference counting tends to be presented on the first chapter of many CS books about garbage collection as poor man's GC?
> Apple's ARC is a compiler hack. It only works if you happen to use set of Cocoa libraries that are recognized by the compiler
I don't understand. How does ARC rely on more than what NSObject provides? I'm coming from the C++ shared_ptr world and ARC does not feel much different so far (less explicit, but easier to optimise).
Most of the restrictions (bridge casts and naming methods) are interoperation with non-ARC code, and from working on Java/JNI I can assure you GC<>manual interaction was worse.
It is of course still quite possible to get abandoned memory through retain cycles.
> True, but C++ does not and you still have the performance penalty of reference counting.
Not very relevant. For UI code, responsive resource allocation and de-allocation is much more important than saving a few % CPU cycles.
> Actually, are you aware that reference counting tends to be presented on the first chapter of many CS books about garbage collection as poor man's GC?
Yes! Sometimes the conventional wisdom doesn't hold in the end, or it doesn't hold for all use cases. But I should have been more clear that ref counting is GC, whereas what I refer to as GC involves sweeping reference roots periodically to identify garbage.
> > True, but C++ does not and you still have the performance penalty of reference counting.
> Not very relevant. For UI code, responsive resource allocation and de-allocation is much more important than saving a few % CPU cycles.
I beg to differ. I consider missile control radar systems of military applications a bit more important than UIs.
There are military applications using real time GC systems, which I can list here if you want.
I also have a German magazine here (Making Games Magazin 1/13) that explains how Witcher2 for the Xbox 360 makes use of a GC.
Anyway one thing I do agree, automatic memory management, regardless of the form, should be the any of any programming language.
Pure manual memory management should be treated like Assembly. It will never go away and should only be used for the very few cases where there is no other way around the problem at hand.
I'm not anti-GC, I just think that reference counting is appropriate for UI code. .NET still supports GC, and the collector is very good compared to our competitors; I'm not saying we should give that up!
I should have mentioned that the primary reason WinRT seems to use reference counting is for interop reasons: its much easier to great a UI toolkit that is programmable in both C# and C++. Note that WPF never had a C++ interface, while WinRT has one without the need for any bridge code.
Reference counting has some interesting applications where it is more appropriate trace-based GC. Heck, sometimes we want old-fashioned arenas (Pascal!), it would be nice if our languages could give us some choices.
Manual memory management is annoying but sometimes necessary. I can see why native programmers don't want to give it up as it constitutes the primary performance difference these days between native and managed languages.
If the ref counting is manual or optimized, it doesn't happen after every assignment, only ones which change object ownership. If you're really nuts about avoiding cache hits, you can pack most ref counts into the low bits of the class pointer, since allocations tend to be 16-byte aligned, including allocations for class objects. Assuming you use the object at least once following a change of ownership, the overall cost in cache misses becomes 0. Or you can store the references in a global table with better cache properties (IIRC this is what ObjC does). Or you can rely on the fact that cache lines are typically large enough to grab a few words at a time, so fetching the class pointer will automatically fetch the refcount (again with the assumption that you use objects at least once per assignment). Honestly, I'm having difficulty imagining how cache behavior could become a problem unless you wanted it to.
As for not allowing cycles, I consider that a feature. The headache of memory management doesn't go away with GC. You still have to avoid inadvertently keeping references to objects through the undo stack & so on. Unintentional strong refs creep through GC code just as easily as memory leaks creep through code with manual memory management. Almost universally, I find that GC'd projects large enough to have memory management best practices implicitly do away with this freedom at the first opportunity by calling for acyclic or single-parent object ownership graphs. These restrictions primarily make it easier to think about object lifecycle -- the fact that they allow refcounting to suffice for memory management is icing on the cake.
> If the ref counting is manual or optimized, it doesn't happen after every assignment, only ones which change object ownership.
The Rust compiler does this. Even so, 19% of the binary size in rustc is adjusting reference counts.
I am not exaggerating this. One-fifth of the code in the binary is sitting there wasted adjusting reference counts. This is much of the reason we're moving to tracing garbage collection.
All of those optimizations that you're talking about (for example, packing reference counts into the class pointer) will make adjusting reference counts take even more code size.
> As for not allowing cycles, I consider that a feature. The headache of memory management doesn't go away with GC.
The fact that memory management is still an issue doesn't mean that we shouldn't make it work as well as we can.
In large software projects, cycles are a persistent issue. Gecko had to add a backup cycle collector over its reference counting framework, and observed memory usage decreased significantly once it was implemented.
That's the evolution Python went through as well: reference counting, then (in CPython 2.0) an adjunct cycle-collector, then (in PyPy) a non-reference-counting garbage collector.
Hopefully in future versions of PyPy an even better garbage collector. :-)
> "It's nice to see that internal developers feel the same way about XNA that external developers (who used to build XNA games, or still build XNA games) do. From the outside I always assumed the constant flood of new, half-baked features instead of fixes and improvements to old ones was caused by interns and junior devs looking for glory ..."
Am I understanding you correct; are you implying that you think XNA was created by juniors? Would you say that because of this, it's a good thing XNA is being killed?
Cause personally I think it's been a terrible decision by Microsoft to kill XNA. A lot of indie game developers have relied on XNA and I really feel Microsoft can use the indie support. Sure, big name games might be a priority, but personally I feel most _interesting_ work is being done by indies. Indies tend to be less concerned with proven formulas and seem to see it more of a creative outlet for themselves[1]. I think it's a good thing frameworks like Monogame[2] exist, so developers can still put their existing XNA knowledge to good use - and not just limited to the Windows platform, but e.g. iOS and Android as well.
The Monogame website might not show very impressing examples, but a game like Bastion[3] was ported to other platforms using Monogame, showing very high-quality work can be created with XNA.
"Unicode-enabled functions are described in Conventions for Function Prototypes. These functions use UTF-16 (wide character) encoding, which is the most common encoding of Unicode and the one used for native Unicode encoding on Windows operating systems. Each code value is 16 bits wide .. New Windows applications should use UTF-16 as their internal data representation."
Wikipedia tells me that Windows NT was started in 1988 and shipped in 1993, while Linux's first release was in 1991, giving them approximately the same age. Furthermore, NT shipped with UCS-2 support, not UTF-16, as UTF-16 did not exist until 1996. UTF-16 was a migration that they completed in Windows 2000. UTF-8 was first presented in 1993 and is, therefore, older than UTF-16.
With all of these facts being true (I hope), today things are such that the Windows world mostly (but not completely -- they sometimes assume two-byte characters) correctly implements UTF-16, while the Linux world correctly implements UTF-8.
Before 1996 (when 2.0 was released) Unicode was a 16bit fixed width encoding. And the first astral character allocations didn't happen until 3.1 was release in 2001.
Look at recent Microsoft releases: we don't fix old features, but accrete new ones. New features help much more at review time than improvements to old ones.
(That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.)
Ahh, I was wondering about that. So, I guess I'll just keep using cygwin.
On another note, I recently asked a friend who works at Microsoft how work is going. His reply: "Well, it's calibration time, so lots of sucking up to the boss." Must be hard to get much actual work done when you're worried about that all the time.
I do wonder, however, whether 'boo! MS's rating system is suboptimal, to say the least!' is a very useful comment here (which might by why we haven't seen Michael write here yet)
Yeah, and that was about Google, which has a much better reputation than Microsoft in this area. I wonder how he would like working at MS. I doubt he'd last a week there!
That's because they don't have nice, human readable COM (and WMI) wrappers. I don't think they had time to implement them - they kept adding more and more from v1 to v2 and v3.
Every time you have Win32 spilling over in Powershell, it looks like crap (0xA).
Commands like Remove-Item have familiar aliases like rm by default. If you see code in tools like Psake, etc. it would be very verbose, because the intention is to have readable code. But you sure can use the aliases for everyday use.
I really can't agree with that. To me, Powershell feels like it was designed by geniuses and implemented by interns.
Absolutely basic stuff, like "find the path of this file" (%~dp0 in batch) is a 5 line copy-paste. Why? It's lovely that I can pipe .NET objects places, but every time i want it to actually do something, I end up in copy-paste hell.
I found that [1] lists a one-liner too, but that's also a four-liner if you'd turn it into a function. Still, I can't remember that shit by heart. I don't want to. Why do I have to? Did these people ever even use Powershell themselves?
Sidenote: if something like node.js, entirely designed for fast asynchronous networking, despite all its callback hell and whatnot, is a better and more user-friendly Windows scripting host than Powershell, some people really should start to worry.
Maybe if Powershell had something like npm, including its (simply perfect) install-to-current-directory-by-default, people could fix all the holes MS left behind. I might even start to like it then.
I don't understand why they felt the need to defy standards with powershell. It's not similar to anything else i'm familiar with. All they had to do was copy bash and port some of the GNU tools.
As an ex-MS employee I always feel obligated to point out that MS has well over 50,000 employees spread out across countless teams and divisions. One employee's experience is never indicative of the company as a whole. I never went through "calibration time" while at MS or anything even close to it.
tl;dr : corporatism and careerism. It's the death of creativity and productivity. No large organization is immune to it. Never will be. (and yes, that includes Google... it's just much smaller and newer than Microsoft is right now)
Sad post IMO, which will unfortunately and unduly tarnish Microsoft's reputation. I would suppose it was written by a developer who has just become senior enough to see some of what's going on, but has not yet realized it's everywhere like that. One day, he'll understand that those challenges too need to be managed.
I assume some other dev with source access at Microsoft could verify that fact, broadcast that the fact is true, and thereby stamp the OP as actually who he says he is.
From what I've heard (unofficially) the source is typically watermarked to identify the sources of any leaks. He may have given himself away with the SHA-1.
I doubt it. Not only would that involve generating a different watermark for each person with access to the code, but in doing so you also raise complications for source control. Additionally, it is almost impossible for developers not to notice if supposedly identical files are not identical, not to mention the fact that implementing the type of system without the conscious corporation of the developers seems impossible.
The problems with the NT kernel are nothing new. When I suggested for Windows to use a BSD kernel to overcome its current limitations, I got lots of disagreement. Microsoft developers seem to be happy with the current state and have no vision of a totally new architecture.
The NT-based kernels were not as big a problem for Microsoft as CE-based OSs were. Nokia transitioned away from a Linux-based smartphone OS to Windows Phone 7, based on Windows Embedded CE 6. It is clear that Windows Phone 7 was uncompetitive with other smartphone OSs. That put Nokia in limbo for a year when they could least afford it.
Now the problem is not so much the kernel, but all the cruft a Windows-based OS drags along with it. The most visible symptom is the amount of storage used up by stuff that adds little or no readily apparent value to Windows RT.
Windows OSs are heavy compared to Android and other Linux-based OSs. That means inexpensive tablets and phones won't run Windows, and Windows is shut out of mobile device markets in India, Africa, and other developing areas. These markets are how Yulong (who??!!) became a top 10 mobile OEM.
People are praising BSD like it was all hot and new. OS X is built on a BSD which has it's roots in 60's and 70's OS design, just like the VMS roots of WinNT.
OS X didn't change the world by bringing some great new underlying architecture to the table. In fact, their kernel and filesystem are arguably getting long in the tooth. The value that OS X brought to the table was the fantastic Carbon and Cocoa development platforms. And they have continued to execute and iterate on these platforms, providing the "Core" series of APIs (CoreGraphics, CoreAnimation, CoreAudio, etc.) to make certain HW services more accessible.
There's very little cool stuff to be gained in the windows world by developing a new kernel from scratch. A quantum leap would not solve MS's problem. The problem is the platform. What's really dead and bloated is the Win32 subsystem. The kernel doesn't need major tweaking. In fact, the NT kernel was designed from the beginning such that it could easily run the old busted Win32 subsystem alongside a new subsystem without needing to resort to expensive virtualization.
Unfortunately, the way Microsoft is built today it have a fatal organizational flaw that prevents creating the next great Windows platform. The platform/dev tools team and the OS team are in completely different business groups within the company. The platform team develops the wonderful .NET platform for small/medium applications and server apps while the OS team keeps crudging along with Win32. Managed languages have their place, but they have yet to gain traction for any top shelf large-scale windows client application vendors (Adobe, even Microsoft Office itself, etc.) Major client application development still relies on unmanaged APIs, and IMHO the Windows unmanaged APIs are arguably the worst (viable) development platform available today.
What Windows needs is a new subsystem/development platform to break with Win32, providing simplified, extensible unmanaged application development, with modern easy-to-use abstractions for hardware services such as graphics, data, audio and networking. This is starting to come to fruition with WinRT, but the inertia in large scale apps is unbelievable.
The problems with the NT kernel are nothing new. When I suggested for Windows to use a BSD kernel to overcome its current limitations, I got lots of disagreement. Microsoft developers seem to be happy with the current state and have no vision of a totally new architecture.
I thought Microsoft refusing to update their decades behind, ancient C compiler was just to piss me off and make life difficult cross-platform developers that need to work in C. Interesting to see this applies to their own employees too.
I think a lot of people that care about C support are already aware of Herb Sutter's stance on the matter. But knowing why he made his decision doesn't really change anything, its not like C++ never crossed their minds before. And classing it up by calling it official policy doesn't make the pill go down any easier.
Microsoft's position in the market is already big enough that they'll never really be proven wrong on C unless they relent. But they're also not large enough to kill it outright.
As an outsider, it looks like MSFT does not grasp kernel performance as a super important feature of Windows. They add so much bells & whistles over the UI, but the inside sucks release after release
As someone else posted in this same thread: is modern Windows substantially slower than the OSes it competes with (in anything other than a few uncommon niches)? If it's more than a few percentage points slower for anything but rare scenarios, I'd be surprised.
I've even seen this mentality in startups. It does have some business rationale, provided you are thinking short term and focused only on near-term goals.
One of the reason businesses have trouble really innovating is that it's hard in a business to work on long-term things when markets are very short sighted. Only mega-corps, monopolies, and governments can usually do that... or hobbyists / lifestyle businesses who are more casual about hard business demands.
That being said, MS is surely cash-rich enough to think long term. So this doesn't apply as much here.
I've also found that of all things optimization almost gets you looked down upon in most teams -- even young ones. "Premature optimization is the root of all evil," and all that, which is usually misinterpreted as "optimization is naive and a waste of time." It's seen as indicative of an amateur or someone who isn't goal-focused. If you comment "optimized X" in a commit, you're likely to get mocked or reprimanded.
In reality, "premature optimization is the root of all evil" is advice given to new programmers so they don't waste time dinking around with micro-optimizations instead of thinking about algorithms, data structures, and higher order reasoning. (Or worse, muddying their code up to make it "fast.") Good optimization is actually a high-skill thing. It requires deep knowledge of internals, ability to really comprehend profiling, and precisely the kind of higher-order algorithmic reasoning you want in good developers. Most good optimizations are algorithmic improvements, not micro-optimizations. Even good micro-optimization requires deep knowledge-- like understanding how pipelines and branch prediction and caches work. To micro-optimize well you've got to understand soup-to-nuts everything that happens when your code is compiled and run.
Personally I think speed is really important. As a customer I know that slow sites, slow apps, and slow server code can be a reason for me to stop using a product. Even if the speed difference doesn't impact things much, a faster "smoother" piece of code will convey a sense of quality. Slow code that kerchunks around "feels" inferior, like I can see the awful mess it must be inside. It's sort of like how luxury car engines are expected to "purr."
An example: before I learned it and realized what an innovative paradigm shift it was, speed is what sold me on git. The first time I did a git merge on a huge project I was like "whoa, it's done already?" SVN would have been kerchunking forever. It wasn't that the speed mattered that much. It was that the speed communicated to me "this thing is the product of a very good programmer who took their craft very seriously as they wrote it." It told me to expect quality.
Another example: I tried Google Drive, but uninstalled it after a day. It used too much CPU. In this case it actually mattered -- on a laptop this shortens battery life and my battery life noticeably declined. This was a while ago, but I have not been motivated to try it again. The slowness told me "this was a quick hack, not a priority." I use DropBox because their client barely uses the CPU at all, even when I modify a lot of files. Google Drive gives me more storage, but I'm not content to sacrifice an hour of battery life for that.
(Side note: on mobile devices, CPU efficiency has a much more rigid cost function. Each cycle costs battery.)
Speed is a stealth attribute too. Customers will almost never bring it up in a survey or a focus group unless it impacts their business. So it never becomes a business priority.
The concept of "premature optimization" also has another connotation in product development: Don't waste too much time making that product or feature optimized until you are convinced you can actually sell it. It's not that optimization is bad, but optimization before market trial (premature) can result in you spending precious time working hard on the wrong thing.
Optimizing the right thing is good, but figure out what that thing is first.
In a publicly traded company, such as Microsoft, that doesn't take long. It is shareholder value. It is not Optimization "for its own sake" promoted in the article. I savvy developer made need to run business tests against their software.
The article implies that line kernel workers interested in optimization for the sake of optimization are ideally situated to judge what matters in the long and medium term, and that Bill Gates and Steve Ballmer, despite being the two largest share-holders and more than three decades of experience running a software company (apiece) are incompetent to recognize long and medium term strategies.
The fundamental assumption of the article - that the Windows kernel should strive toward the Linux kernel management model is patently absurd.
FOSS is free as in "free to break software that depends on your code."
I'm not sure he's arguing the individuals are making better decisions, but rather the sum of thousand developers making decisions is better than the shareholders the C levels at Microsoft.
I think a good analogy is centralized government economies vs private enterprise economies. The less people you have making key decisions and the more isolated you are from the effects of bad decisions, the easier it is to evolve and improve.
Obviously open source has a lot of failures and took a long time to catch up in certain areas. But things like the Linux kernel have become a massive, unstoppable force that's evolving quicker and more efficiently than ever before. Microsoft simply can't compete with the hundreds of companies and tens of thousands of developers working on it.
I'm not sure he's arguing the individuals are making better decisions, but rather the sum of thousand developers making decisions is better than the shareholders the C levels at Microsoft.
I think a good analogy is centralized government economies vs private enterprise economies. The less people you have making key decisions and the more isolated you are from the effects of bad decisions, the easier it is to evolve and improve.
Obviously open source has a lot of failures and took a long time to catch up in certain areas. But things like the Linux kernel have become a massive, unstoppable force that's evolving quicker and more efficiently than ever before. Microsoft simply can't compete with the hundreds of companies and tens of thousands of developers working on it.
I'm not sure he's arguing the individuals are making better decisions, but rather the sum of thousand developers making decisions is better than the shareholders the C levels at Microsoft.
I think a good analogy is centralized government economies vs private enterprise economies. The less people you have making key decisions and the more isolated you are from the effects of bad decisions, the easier it is to evolve and improve.
Obviously open source has a lot of failures and took a long time to catch up in certain areas. But things like the Linux kernel have become a massive, unstoppable force that's evolving quicker and more efficiently than ever before. Microsoft simply can't compete with the hundreds of companies and tens of thousands of developers working on it.
> In reality, "premature optimization is the root of all evil" is advice given to new programmers so they don't waste time dinking around with micro-optimizations instead of thinking about algorithms, data structures, and higher order reasoning. (Or worse, muddying their code up to make it "fast.")
It's also for experienced programmers who dink around with macro-optimizations. For example, designing an entire application to be serializable-multi-threaded-contract-based when there's only a handful of calls going through the system. Or creating an abstract-database-driven-xml-based UI framework to automate the creation of tabular data when you have under a dozen tables in the application.
premature optimization is the root of all evil is a really really important mindset, and I agree it doesn't mean to not optimize, and many developers seem to take it that way.
X+1 = How many transactions your business does today
Y = How many transactions your business needs to do in order to survive
Y/X = What the current application needs to scale to in order to simply survive. This is the number where people start receiving paychecks.
(Y/X)4 = How far the current application needs to scale in order to grow.
The goal should be to build an application that can just barely reach (Y/X)4 - this means building unit tests that test the application under a load of (Y/X)4 and optimizing for (Y/X)4
Spending time trying to reach (Y/X)20 or (Y/X)100 is what I'd call premature optimization.
Disclaimer: (Y/X)4 is no real point of data that I know of, just something I pulled out as an example, anyone who knows of actual metrics used please feel free to correct.
I recently realized, e.g., that the HotSpot JVM is the R.M.S. Titanic, and invokedynamic (or any change in bytecode) is the iceberg. That's probably a reason why we're still waiting for lambdas, in-memory transactions, etc. It's too large to evolve quickly.
I've read your comment three times today. I still cannot avoid thinking of Richard M Stallman and trying to link him to the Titanic. Even though I know it is wrong.
I think you missed half the argument. Windows is noticeably slower than Linux or Mac on the same hardware. Isn't that a problem?
And if optimization always hinders evolution, boy should Windows be evolving... I mean... the NT kernel should have smashed through all kinds of antiquated paradigms by now. It should be doing memory deduplication, disk deduplication, fast JIT compilation of binaries for alternative architectures. It should support live process migration between machines, joining of systems together efficiency to form larger super-systems, a better permission model obviating the need to rely completely on virtualization for true privilege isolation in enterprise environments. It should have truly efficient network filesystems supporting disconnected operation, sharding, etc.
Oh wait... it's stuck in the 90s... never mind. And it's slow.
Linux, which optimizes a lot, has at least some of the things I mentioned above.
"Premature optimization is the root of all evil" is a deeply nuanced statement that is nearly always misunderstood. "Optimization hinders evolution" is probably likewise. They're quotes cherry-picked out of context from the minds of great craftsmen who deeply understand their craft, and alone I do not believe they carry the full context required to comprehend what they really mean. I think they have more to do with maintaining clarity and focusing on higher-order reasoning than they do with whether or not to try to make things run faster. (And like I said, the most effective optimizations are usually higher-order conceptual algorithmic improvements.)
> Windows is noticeably slower than Linux or Mac on the same hardware. Isn't that a problem?
Windows isn't slower at running Windows apps, fitting into a Windows infrastructure (Active Directory, management tools, Exchange etc), using Windows device drivers, working with NTFS volumes and their features, backwards compatibility, printers etc.
It all comes down to what the goals of the users (or purchasers) are, and I doubt anyone buys Windows because of "performance" in the sense being talked about. But they do care about the "performance" of items mentioned in my previous paragraph.
Linux has been able to optimise because of being open source and vehemently ignoring closed source. Open source means for example that the Linux USB stack could be optimised and all affected code due to API changes could be updated. This and other topics are covered really well in Greg Kroah-Hartman's OLS 2006 keynote - http://www.kroah.com/log/linux/ols_2006_keynote.html - see "Linux USB Code" about halfway down for that specific example.
"Or creating an abstract-database-driven-xml-based UI framework to automate the creation of tabular data when you have under a dozen tables in the application."
I'm not an experienced programmer, and I'd use that approach anyway, simply because it makes sense (is there any alternative that isn't worse?). What does that mean? (Oh, and I'd skip XML. I abhor violence.)
Just bite the bullet and render them by hand. It'll take less time than writing the abstract whatever-driven autogenerated UI framework, making it lay things out nicely, handle all the corner cases and auto-wiring of stuff which might not be needed in all cases, and tweaking the generated code to look good for all the data.
You know, this is where conciseness comes in handy. Another suspicion that I have (in addition to the one I've voiced elsewhere here) is that complex, inflexible languages almost force people to write stuff "by hand". What exactly is the reason for a simple, small generative layer to be so complex that it can't beat hand-written stuff for two dozen tables? I'd understand if you were talking about Java and Cobol, for example, but I'd think that such languages as Ruby, Smalltalk, and Lisp will have the threshold for "now it's worth it to be generic" quite a bit lower. I'm not sure where exactly, but certainly lower.
Factories only make economic sense if you are planning on building a large number of widgets.
For small applications, dynamic form generation infrastructure dwarfs the actual business logic. It means writing a lot of code which isn't solving your business problem.
Your project has an extra layer of 'meta'. It's harder to debug. It decreases flexibility. Validation is hard for multi-field relationships. Special-casing that one form can require major infrastructure changes. The approach tends to be slower and buggier than the naive approach for all but the most form-heavy applications.
It's not just the form generation. I've given some thought to how one might work with a MVCC/MGA system such as the one you have in PostgreSQL and Firebird to make an interactive system with tabular display that would keep the beneficial properties of these transactional architectures (optimistic concurrency) and still work the way that people expect from "business apps with data grids". Among other things, this implies data edit conflict resolution etc. The problem is that even if the way of going about this is straightforward, I'd never, ever want to write this even twice. Not just because it's extra work, simply because generating the updating transaction in the manner recommended by the designers of these RDBMS systems (a snapshot transaction to populate the UI and a read-committed transaction to post the edits) is error-prone.
Also, why would an extra layer of 'meta' make it harder to debug and decrease flexibility? I would have thought that it would enforce more structure by centralizing certain functionality, thus making it correct-by-design instead of relying that you'll follow conventions in multiple places consistently, and increase flexibility by separating aspects that you'd otherwise have to "weave-in" throughout the code and later change in multiple places.
> I've given some thought to how one might work with a MVCC/MGA system ...
Yes, it's an interesting problem. That's exactly what makes it fly paper ;)
Less flexible: suppose your framework is doing dynamic form generation on top of wxPython. You could have a date picker as a radio box item if you wanted. However it would probably not a be a good use of time to support that in your MDA system.
Harder to debug: Usually, bugs in the auto-form-generation infrastructure are "trickier" than the bugs you would get if you just wrote the forms.
A lot of the use cases for dynamic form generation are adequately served by automatic scaffolding in django/rails/turbogears or on the enterprisey side, technologies like Oracle forms and its successors.
I'd consider it easier to debug a piece of meta-code as long as the language wasn't too hostile to it, than multiple sections of similar code that need to be scanned manually to keep in sync.
And for those corner cases, code them as one-offs but within the templating system, and keep the benefits of any logging etc from the system.
I think you're missing the forest for the trees. The lesson is just: don't spend the time to generalize something unless doing so will save you time and effort. You'll have to use a lot of judgement to determine where the crossover points are.
> > In reality, "premature optimization is the root of all evil" is advice given to new programmers
> It's also for experienced programmers who dink around with macro-optimizations.
The hilarious thing is that everyone seems to think everyone else's optimizations are premature.
Don't believe me? Just go ahead and ask someone an optimization question, like maybe on StackOverflow.
Those who respond might not know you, but I'll be damned if their first reply isn't to tell you that you probably shouldn't even be optimizing in the first place, because obviously if you'd thought about it more carefully, you'd have realized it's premature.
Do you have to spend all your time and resources architecting the system poorly the first time, just to "prove" that you are wrong -- even though you knew it would happen before you even started coding?!
That's like telling an engineer to prove (by actually building it and subjecting it to a lot of stress) that the bridge he designed would be prone to collapsing before helping him find a better design!
It's just a simple fact about the signal-to-noise ratio on a public Q&A site. Almost all optimization questions will be premature optimization questions. Including any evidence that you know what you're doing makes your question stand out. But just claiming to know what you're doing is indistinguishable from a common form of noob arrogance.
i admit to doing this... made a multithreaded simulation framework for use by my game team.... too bad the games they make with are so computationally simple as to make the sim framework a complete waste :(
322 comments
[ 3.1 ms ] story [ 284 ms ] threadWe didn't delete it. It was deleted by whoever posted it.
No, they do not. Specifically, I have showdead on, and when trying to view the comment in question, I see only "[deleted]".
then
>We occasionally get good people anyway
Uh... nine-to-five-with-kids type here. Thanks for the stereotyping... from your safe corporate nest.
Otherwise an insightful post.
I understand the reason this fiction is maintained: people with kids need the job even more than people without, and have an interest in denouncing people who claim kids make you less productive. There's also the second order effect in which "with kids" is correlated with "older".
The net of it though is that devs with kids tend to assign work a lower priority, to take fewer risks, to need more money, and to be older and hence less familiar with new technologies (and too busy to learn in their free time).
Society doesn't have a good answer for this situation yet. In times past, technology didn't move so fast that experience was mostly obsolete (and hence useless) in a decade's time. A 40 year old farmer with kids in 1713 would probably have much to teach a young whippersnapper. The same isn't true for a 40 year old programmer with kids in 2013.
For the idea that parents and older programmers have different priorities, that may be true, but you downplay experience way too much. That said, trying to find 150% dedicated younglings, that don't spend a lot of time on side projects and just enjoying life is not that easy either
"Maturity" is an ambiguous and contextual concept that doesn't usually mean anything - people should be rated by objective attributes like experience, productivity and so on. One could also say that a younger person with more and harsher life experience can be more "mature" than someone older and with kids (think someone who raised his/her little brothers by mistake after the parents got killed or something like that), but with less impacting experience but it would be just as meaningless because of the ambiguity of "maturity" (how much is life experience relevant to a programmer?). Raising children teaches one useful "life things", but so does starting a business, travelling around the world or working for the red cross in Africa. Adding insult to injury, managers tend to use "maturity" when referring to employees as "ability to take orders and act predictably even if not particularly creative" which basically makes it an "antiquality" for a small fast startup.
I'm 28, which means I'm young enough that even people like you believe I can learn new tricks. As far as I can tell, my brain is still fully functional. That said, most of what I use every day, I learned over ten years ago. Computer science never gets old. The notion of indirection is never obsolete. The mental machinery required to navigate up and down in an abstraction hierarchy is universal. Sure, I learn new APIs every day, read about new programming paradigms (hey, functional reactive programming is cool), and so on, but I learned all the basics way back when.
Would you say that all my older experience is worthless? If your hypothesis were correct, I should be able to say that what I'm learning now is more important than what I learned in 1998, and that's just not true.
Most of the assumptions you've made don't apply to me, a 40 year old father of two. It may very well apply to some people similar to me. This is the problem with stereotypes and the problem with people perpetuating them. Oversimplifications are a shoddy mental crutch to deal with the complexities of reality.
The older you get, the more experienced you become, the better decisions you make, the more valuable you become.
At 22, I was a great tactician. I could code faster than anyone else.
At 32, I'm a moderate strategist. I code slow than when I was at 22; but my productivity is far higher.
At 52, I hope to be a great strategist. The potential is frightening.
3 hours of sitting thinking about a problem, then 30 minutes of coding. I would never have done that at 20, I'd have opened an editor and started typing because I was still learning the intricacies of the platform.
In my late teens/early twenties, I just implemented the first thing that I could think of.
Back then it was much easier.
Actually, I have noticed that other developers around my age still think like I did when I was in my twenties. Maybe it's because I've been coding since I was 10 (22 years!) and full time since I was 17, and most came in after university?
Then there is the argument about blindly learning to code from BAD code on the internet, whereas we had to learn from books! :)
I hope the explanation for your post is that you're 17. This blatant generalization is idiotic and useless. Reading that reply is a denial of service attack on productive thought.
This is brilliant!!
What? New workers enter the workforce.
To a first approximation, all this new "web technology" is just a way of doing what you could've done on an internet-connected NeXT machine 20 years ago, only more brain-damaged and frustrating to work with.
The only place technology has advanced in that time period is in domain-specific areas (which of course requires experts, not young whippersnappers), and infrastructure (the world looks a lot different for computers with pervasive 4G--the software is just an adaptation of proven concepts to uses enabled by innovative hardware).
Programming is applied mathematics, and that hasn't changed substantially since people were developing software on punch cards.
That wouldn't have been possible without the web. The web technologies you decry are more irritating in many ways than any one specific proprietary system from 20 years ago, but that ignores some of the huge benefits of openness and standards and platform independence.
I can write a program and have it run without modification on my phone, on an embedded computer running sensors, on a tablet, on my laptop, my desktop computer, my hifi, my network hard drive, a huge server being rented to me on the other side of the world. I can even make it easily distributable so it can run safely on other peoples computers who don't fully trust me. It's unimaginable that any proprietary system from 20 years ago would have been able to produce that state of affairs.
Speed of interpreted Javascript has improved by two orders of magnitude on the same hardware in the last ten years, and you don't see technological advance? I can't think of another field that has advanced so quickly.
I don't want to diss other fields, but an awful lot of the most valuable improvements in infrastructure in the last ten years have been about standardization and bringing technology that existed years ago to the masses.
On top of that, the inconvenience of the Web platform is real but also overhyped. Imagine you're writing a network app in another platform. It's extremely unlikely you have access to an integrated network analyzer as good as chromes. How many other systems allow you to completely modify the look of your application while it's running just to see how it looks by playing with the developer tools? Having a repl that allows you to interact with the running system has been standard on the Web platform for ever.
I'm not even sure what you're looking for. What would constitute new technology if 100x speed ups don't? Almost all of software is implied in the concept of the Turing machine so complaining that you can't achieve anything you couldn't have in the past with large, expensive, proprietary systems and specialized knowledge seems unfair. It's been true since Babbage at least.
That's what Java was about. According to http://en.wikipedia.org/wiki/Java_(programming_language) it appeared 1995 - 18 years ago.
Java failed badly at its dream and ended up adopting an entirely different niche to what was expected.
But you're right, I shouldn't have said 'unimaginable'. I suppose it's just about possible that if java had 'won', we might have ended up with something not massively dissimilar to what I described.
Given that list, what would you consider obsolete now? It's been 2 decades, not 1, mind you. Asm? Well, the last time I touched this sword for a reason was 2005 and it was SSE assembler, something that compilers were not able to generate efficiently then (and to the large extent still not able).
The indexer had to chew huge amounts of text, so the quicker the lowercasing, the better.
Where do you think bad, old developers come from? Well, they started off as untalented young developers. Right now now there are young developers who are awesome and others who suck and will one day become crappy, old developers.
I could go on about stories where youth and inexperience led to disasters. They would be just as one-sided as talking about old developers who are out of touch. Who do you think it is that's creating all if the tools that you use?
It's about the work.
Somehow, despite having kids, I manage to learn new technologies, even insofar as I was able to write a book about it (Dart in Action). The only reason I had time to do that is because I try to keep my day job between 9-5.
2. People with children have a better understanding of what responsibility is.
3. People with children usually spend less time on dating and going to bars :)
4. We tend to be more time efficient
Were you parents rubbish slackers because they made the mistake of having you? Or did they work so hard they forgot to bring you up well?
Having kids can put a lot more structure into a life that was missing it before. 20-somethings without kids are usually the ones late in in the morning, missing standups, or the ones working while hung over.
I'm sure that it is possible to get someone who is so dedicated to their work that they have no life at any age. Whether or not this is a good idea for your company is a different question.
I know of very few other jobs were you are supposed to spend so much of your spare time reading up on new stuff as the IT-business. A few of my friends are physicians and they to spend their spare time reading up on new stuff. Others, not so much.
I don't think this is a sustainable way of doing business in the long run.
Your whole post drips with resentment-fueled bigotry and ignorance, making me wonder if you're fighting for attention at your workplace or whatever, feeling unloved. Here's an internet hug. Hugz.
Many years back I -- a new graduate employee -- was chatting with my boss, who was a part owner of the company/president. He had five kids, or maybe even six. He asked me when I was thinking of having children (it was still too early for me, but just as a conversational thing), and my honest answer was that I didn't know how he could afford it.
He then told me about an Arabic parable or the like that each child comes with a bag of money.
That seemed counter intuitive to me, but my life has proven it out. I now have four children, and I would wager good money that I know more current technologies, in much more depth, than you do.
If you have the capacity, having children has a profound ability to make you focus: While I am the same intellectual being, like the vast majority of developers I was absolutely pissing time away before children, and I doubt I passed even 5% productivity. Slashdot was the Reddit of the time, and doing asinine, meaningless implementations for days on ends was just a normal day. And I know this is the case for most developers.
Now I don't have time for the bullshit. I focus specifically on the things that yield success, in the most efficient manner possible. I'm still only maybe 15% productive (still piss away a lot of time), but the result is my own company, a lot of success, etc.
Its hard to remember life before kids, but one thing I know for sure: I wasted a huge amount of time.
I work far more effectively at 39 than I did in my 20's. And my ability to focus took a massive boost after becoming a father.
I still waste time, but I've never been more productive. I work full-time, have my own company in my spare time, and my child at every moment he's awake.
I can see how an empathetic person having children would increase their focus to succeed, but what is the limit on the number of kids? How would one know when to stop having kids? Why did you stop at four kids? Are you going to have more?
We didn't expect our third child, or the fourth for that matter. That's life though, and I'm a very roll with it sort of person and am extremely pleased with how things have turned out.
Of course I am speaking from a very privileged position of happening to have the right sort of mind at the right moment in history in the right situation where I can talk about pissing most of my time away and still achieving what many would consider a lot of success. This obviously doesn't apply to all careers or all people.
I am not young. I've been attending funerals recently, and meeting family members I have not seen for 30+ years. None of us were comparing notes about our productivity.
The first was in search and distributed systems, at Google, and the blueprint for their systems was created by two mid-career engineers out of DEC.
The second was the evolution of the smartphone, at Apple, an old company that is known for keeping its engineers for a long ass time.
The most innovative computer language we have was designed in the 50s, and every time I meet an old-time hacker, there's something I can learn from them.
The real lie is that a kid out of college who starts a company is automatically considered an innovator. Rehashing an idea one more time in a slightly more marketable way or creating an app that goes viral has nothing to do with innovation.
In the pop culture age, we constantly confuse the Britney Spears' of the world with real talent, and the Summly's of the world with real innovation.
As people get older, they get more experience, which is good. They are also more likely to have a family. Is that supposed to be bad?
It might have been better to rewrite his post into your own words, and take out some of the unnecessary detail, rather than literally repost.
That always wipes the smug grin of their faces.
While I agree with you, nothing could wipe the smug grin off these persons' faces. They are beyond reality, and I'd be much happier with America if something so simple could give the "socialists are universally lazy" rabble whenever labor rights are mentioned in any sense.
I will say all of the ex-Microsoft folks I've encountered at Google Seattle have been fantastic.
On a related note, it's stupidly easy to get code accepted by another team at Google.
Also we're hiring.
Insult to injury? ;)
It does take a ferociously long time to get through the initial screening if you just send them a CV, and I'm sure a lot of people fall through the cracks - my suggestion would be to find a Googler or Xoogler and ask them to recommend you, I understand you get a lot more traction that way. Chin up.
I find it doubtful that your lack of education alone is what's keeping you from getting a callback. Do you have a portfolio linked from your resume? Have you got friends that work for these companies that are willing to go over your resume with you?
Bah... my friends keep referring me, but recruiters never seem to like it... ;-)
Unless that other team is Android. Though then you could submit to AOSP directly (assuming the issue you are addressing wasn't fixed internally 4 months ago, but how would you know?).
I've seen a number of open-source projects where you get all the personal glory for your additions but there is nobody who takes the responsibility to tell people "no". These projects, almost universally, turn into bloated messes over time. Open-sourced computer games seem to fall down this path more easily, since everyone and her little dog too has ideas about features to add to games.
I just listened to an episode of Roguelike Radio from the mid-30s (maybe the one with Red Rogue or Thomas Biskup) and Andrew / Keith (IIRC) go on and on about how all the "major" roguelikes are just accretions of features.
This rings very true to me; I grew up playing Nethack [0], and Slash (and then Slash'Em) just got silly with all the things they were adding. Light sabers ? In my roguelike ? Come on, fhgwgads. Nethack at least has a mysterious Dev Team who ostensibly are the guardians of quality... but they _did_ bring Sokoban back from Slash'EM into vanilla.
[0] since Nethack was my first roguelike, I didn't realize until lately just how crappy it is in many ways, most notably that it's very difficult to win before you've figured out all the sources of instadeath (whether you've figured them out by spoilers (written or source-diving) or through (really frickin hard-won) experience).
In particular, brogue's food clock is excellent in that if I forget about it too long and go back to my natural "explore everywhere, kill everything" tendency, the food clock _will_ kill me.
[0] something that jumped out at me is just how much modern roguelike development is windows-first (or even windows-only), and how much of it is distributed primarily as runnable binaries vs source. I had to bend way over backwards to get PrincessRL running: I ended up installing a 32-bit ubuntu userspace virtualbox instance so that mono could run the prepackaged binary.
But I digress. POWDER feels very much a designed roguelike, not something that evolved.
He's also slightly off-base on some of the technical criticisms: there are often good reasons for doing things a certain way, and these reasons aren't always immediately apparent. Besides, change _does_ happen: Arun Kishan (who is smarter than I'll ever be) broke the dispatcher lock a while ago (see http://channel9.msdn.com/shows/Going+Deep/Arun-Kishan-Farewe...) when nobody thought it could be done.
One of the issues the author seemed to be alluding to is that the loss of experienced developers makes it really hard to keep track of "line 123 of foo_dispatch.c does this because of vital business reason xyz or compatibility reason uvw" and "line 123 of foo_dispatch.c was written while I was hungover and trying to make a deadline--it looks clever, but feel free to junk it.".
This issue is compounded when you are hiring safe, and you have a culture where making gross fuckups while trying to make progress is discouraged. It is neither good nor bad--after all, I too enjoy using stable software--but there is a price to be paid if devs don't feel comfortable making breaking changes.
Now, once you set up a system where people play it safe more than they innovate, you'll get a situation where all of the best programmers will want to leave because it's boring, and you're left with mediocre programmers who aren't good enough to be bold and innovative. This is exactly what the OP describes.
Azure is the new Windows.
From the outside I always assumed the constant flood of new, half-baked features instead of fixes and improvements to old ones was caused by interns and junior devs looking for glory - sad to hear that's actually partly true. I always considered frameworks like WPF (or Flex, for that matter) 'intern code' - not that interns necessarily wrote them, but they reek of not-experienced-enough engineers trying to solve problems by writing a bunch of new code, instead of fixing existing code.
It really is too bad, though. There are parts of the NT kernel (and even the Win32 API) that I consider a joy to use - I love IOCP, despite its warts, and APIs like MsgWaitForMultipleObjects are great tools for building higher-level primitives.
Plus, say what you want about GDI (there's a lot wrong with it at this point), but it's still a surprisingly efficient and flexible way to do 2D rendering, despite the fact that parts of it date back to before Windows 3.1. Some really smart people did some really good API design over time over at Microsoft...
See, in Windows, processes are first class kernel objects. You have handles (read: file descriptors) that refer to them. Processes have POSIX-style PIDs too, but you don't use a PID to manipulate a process the way you would with kill(2): you use a PID to open a handle to a process, then you manipulate the process using the handle.
This approach, at a stroke, solves all the wait, wait3, wait4, SIGCHLD, etc. problems that plague Unixish systems to this day. (Oh, and while you have a handle to a process open, its process ID won't be re-used.)
It's as if we live in a better, alternate universe where fork(2) returns a file descriptor.
You can wait on process handles (the handle becomes signaled and the wait completes when the process exits). You can perform this waiting using the same functions you use to wait on anything else, and you can use WaitForMultipleObjects as a kind of super-select to wait on anything.
If you want to wait on a socket, a process, and a global mutex and wake up when any of these things becomes available, you can do that. The Unix APIs for doing the same thing are a mess. Don't even get me started on SysV IPC.
Another thing I really like about NT is job objects (http://msdn.microsoft.com/en-us/library/windows/desktop/ms68...). They're a bit like cgroups, but a bit simpler (IMHO) to set up and use.
You can apply memory use, scheduling, UI, and other restrictions to processes in job objects. Most conveniently of all, you can arrange for the OS to kill everything in a job object if the last handle to that job dies --- the closest Linux has is PR_SET_PDEATHSIG, which needs to be set up individually for each child and which doesn't work for setuid children.
(Oh, and you can arrange for job objects to send notifications to IO completion ports.)
Yes, Windows gets a lot wrong, but it gets a lot right.
Update: And I forgot to mention the font parsing security issues (look up Duqu), and the issues with user mode callbacks too.
Okay, you're in charge. Are you sure you can't find a better way to deploy shareholder capital than using it to remove win32k?
Could that be why developing an OS inside of a shareholder-owned corporation is inherently hobbled compared with developing it as an open source project?
True, but resource allocation is distributed between volunteer contributors, sponsored contributors who may have different sponsors, downstream consumers of a project, and people involved in project governance. That can make it easier to try new approaches.
Not all commercial projects are run like Windows, and it seems to me that most of their conservatism doesn't come from lazy or shoddy or shortsighted developers and managers, but rather their large number of hardware and software partners who take dependencies on undocumented implementation details (see Raymond Chen's blog for a virtually infinite supply of such anecdotes).
Genuine question (because I really don't know) -- how do Linux GUI frameworks work without kernel-mode callbacks? What do they use instead, when they need to send messages to other windows?
Asynchronous communication is achieved using syscalls like select and poll which take a set of file descriptors (files, special files, sockets) and block the calling thread until some descriptor from this set has new data available for reading, starts accepting writes or signals an error.
GUI toolkits repeatedly poll the X server descriptor, parse incoming messages and call application-defined callbacks.
That sounds like it's basically the same thing as Windows (GetMessage or MsgWaitForMultipleObjectsEx anyone?)... only that now you don't have the ability to use SendMessage, and need to rely exclusively on PostMessage instead.
Is that correct?
In all boils down to message-passing: in Windows, the win32k is the trusted third party that mediates interactions between different window-system clients. In the X11 case, the X server and the window manager work together to do the same job. The architecture are fundamentally similar.
Why does Windows need kernel-to-user callbacks in the first place then? Now I'm thinking it shouldn't even be necessary at all...
Wouldn't that completely avoid needing to call back into user-mode from kernel mode?
Except for the 64 handle limit, which makes it largely useless for anything that involves server applications where the number of handles grows with the number of clients. So then you'd spawn "worker" threads, each handling just 64 handles. And that's exactly where your code starts to go sour - you are forced to add fluff the sole purpose of which is to work around API limitations. What good is the super-select if I need cruft to actually use it in the app?
And don't get me started on the clusterfuck of the API that is IOCP.
> Yes, Windows gets a lot wrong, but it gets a lot right.
Oh, no, it doesn't.
Specifically, what Windows does not get is that it's other developers that are using its services and APIs, not just MSSQL team that can peek at the source code and cook up a magic combination of function arguments that does not return undocumented 0x8Fuck0ff. I have coded extensively for both Linux and Windows, including drivers and various kernel components, and while Windows may get things right at the conceptual level, using what they end up implemented as is an inferior and painful experience.
The problem with Windows is that there isn't any such super-select, unlike on Linux (see epoll, signalfd, timerfd...). You should take a look at my SO answer which lists six different ways to use sockets in Windows: http://stackoverflow.com/questions/11830839/when-using-iocp-...
And expecting a modern OS to have an uncomplicated O(1) API for monitoring sockets is clearly too much to ask.
- To send data, user calls Socket::send(const char *data, size_t length). This starts sending the given data; the buffer must remain available while data is being sent. IOCP implementation will initiate I/O using WSASend() or similar.
- When send operation is complete, the socket implementation calls a Done() callback of the user, and from that point on, the user is allowed to call Socket::send() again. With proper implementation, send() can directly be called from the callback.
This interface is very easy to implement on Linux. But on Windows there's a complication, because it's non-trivial to just stop an IOCP I/O operation that is in progress, in case you decide you don't need the socket any more and want to red rid of it NOW. If you just forget about it, there could be a crash when you release your buffer but Windows is still using it. A simple solution is to CancelIo() the socket and do blocking GetQueuedCompletionStatus()s until you get an event inidicating the completion of the pending I/O operation - taking care to queue up any unrelated results you may have gotten, for later processing. However, a more efficient solution is to use reference counting or similar with your buffers, so they only get released when Windows is done with them.
I didn't say it's easy, but it's possible.
> I can't really use IOCP, because I need keep things reasonably portable
LOL!
You outright dismiss the solution because it isn't "portable". What does "portable" mean here? Portable in a particular platform?!
Portable between what exactly? IOCP has been there since Windows NT 3.51 -- it's "portable" between the Windows-es.
Your epoll, signalfd, timerfd, etc. are Linux functions They're "portable" between the Linux-es.
i.e. The "portable" solutions you like are just as non-portable as the "non-portable" solutions you outright dismiss, making Microsoft's Windows designers look like idiots.
You're never going to find a solution while considering the Linux platform to be the "portable platform" and Windows to be the weird kid on the block.
Sadly, you're not the only person who thinks like this.
So "LOL!" yourself, bud.
It's funny, you mention "epoll, signalfd, timerfd" as an example of a portable API, and then when I point out they're Linux APIs, you suddenly start talking about "a scalable variation" of the BSD sockets API. As for your "scalable variation of BSD sockets API", why don't you tell us the name so we know what you're referring to? Are you talking about Kqueue for example, or something else?
> an abstraction that is both simpler
I/O completion ports are just read-write queues... you ReadFile(), and when it's done, an item goes into the queue. (You can insert your own tasks into the queue, too, if you want.) Now just pop off the next item in the queue and off goes your thread. What part of that was so complex compared to your portable API (which for some reason you didn't feel was appropriate to mention the name of)?
> and more universal
Can't reply to it without knowing what "scalable variation" you're referring to, and why you didn't actually mention it as an example of portability when you were actually talking about the subject. Is portability actually a concern for you or no? (If it is, why did you bring up non-portable examples?!)
It wasn't me who mentioned it.
My comment remains essentially unchanged, though, with the same question as before:
What's this great portable API you're referring to?
Don't leave us hanging... what examples are you referring to?
For WINE, if you are going to write an emulator that runs Microsoft code (like the .net framework, or notepad.exe), you need to find the correct behavior of these undocumented APIs by trial and error.
For a developer on Windows, it is perhaps frustrating that MS identifies and solves problems with it's platform, but doesn't publicly release these solutions to you.
I work for some random company that makes an SDK, although I mostly make products using it. Many of our best features are hidden - we don't ship the header files with the SDK, but the symbols are there in the binaries. Someone doesn't think they are useful enough to justify the testing expense for a full release. I guess MS have the same thing.
Wine Is Not an Emulator.
[1]http://www.winehq.org/about/
tl;dr: compatibility layer
WINE is a translator that allows Windows programs (those that have an .exe extension) to talk to other Operating Systems.
or perhaps:
Many people need wine if you want them to work. A windows program on Linux is no exception.
I'm sure the aforementioned freshmen would like a no-bullshit explanation for why "emulator" hurts the WINE people's feelings but "translator" does not. It's always been a mystery to me.
Hah! Not really possible, especially considering that the project used to be called windows emulator:
I'd say they've changed the meaning so they can reinforce that it's not just another virtual machine ( and that it's faster than one).Which is true, it doesn't emulate another hardware architecture's calls, just the kernel and OS magic needed.
In that regard, think of say a console game or arcade game emulator on a computer- that will have to emulate the whole architecture of said game system as well as the game.
Contrast that to a game program for the the x86 architecture, but not for windows- you could run it natively on windows providing you change everything the game asks for that's part of the Gamesystem380 system into something windows understands, and vice versa.
"undocumented APIs" != "a magic combination of function arguments"
Any function that's not documented can be called an undocumented API, any program has them -- Linux, Windows, whatever.
But you were talking about the argument combinations being undefined, not the functions themselves. What are some examples of that?
Ever since the monopoly rulings against Microsoft, they have had extremely strict internal controls preventing non-OS code from using undocumented APIs. If a DLL or EXE does not ship on the Windows client install disk, it cannot reference APIs which are not documented in MSDN. Full stop.
You're referencing an API that inadvertently didn't get documented, but everyone knows about it, has blogged about it and lots of articles mentioning to use it? Too bad. Either stop using the API or delay release by 3 months for the next MSDN update.
http://www.freebsd.org/cgi/man.cgi?query=pdfork
That said, if you're writing an app you might be able to go higher level and use XPC services, which can be much less pain.
When Windows Phone 8 came out, the native renaissance was full speed inside Microsoft, C++ with DirectX became the official way and XNA was canned while Microsoft left MonoGame and Unity pick up the C# developers still willing to invest into the platform.
The sad thing is that this is not a native vs managed issue, because even C# gets compiled to native code when targeting Windows Phone 8. Just plain product management decision to kill the product, which was being sold as the way to develop Windows Phone games.
I have no insider information to suggest otherwise, but don't you think that a replacement will be released with the new console?
Right, I find it likely that XNA was killed to work on a better toolkit for all three.
Sadly those videos seem to no longer be online after MSDN was redone.
Maybe someone can correct me if I am wrong.
This is unfair and unfounded accusation. If you look at the time frame, all the major platform were working on their first hardware accelerated UI toolkits and went through the similar teething problems (Cocoa anyone?). WinForms was a dead end, there was no fixing to do. WPF has turned out well enough, and WinRT has evolved into something very efficient (e.g. by using ref counting rather than GC).
> Plus, say what you want about GDI (there's a lot wrong with it at this point), but it's still a surprisingly efficient and flexible way to do 2D rendering
Not anymore. I get it that some love to use antique APIs and computer systems just for the sake of being retro, but when every computer ships these days with a GPU, using GDI is not even close to pragmatic.
Since the Win32 UI stack uses GDI, it was hardware accelerated before WPF even existed.
Here is a good discussion of the topic:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff72...
Excerpts:
> When the GDI DDI was first defined, most display acceleration hardware targeted the GDI primitives. Over time, more and more emphasis was placed on 3D game acceleration and less on application acceleration. As a consequence the BitBlt API was hardware accelerated and most other GDI operations were not.
> In order to maintain compatibility, GDI performs a large part of its rendering to aperture memory using the CPU. In contrast, Direct2D translates its APIs calls into Direct3D primitives and drawing operations. The result is then rendered on the GPU. Some of GDI?s rendering is performed on the GPU when the aperture memory is copied to the video memory surface representing the GDI window.
> Existing GDI code will continue to work well under Windows 7. However, when writing new graphics rendering code, Direct2D should be considered, as it takes better advantage of modern GPUs.
Ah you mean by causing cache stalls when doing increments/decrements after each assignment and allowing for cyclic references?
[1] https://developer.apple.com/library/mac/documentation/Genera...
.NET still does GC, it is only the WinRT APIs (something like COM) that manage resources through ref counting. There is some cool interop magic that makes this somewhat transparent to the programmer.
Apple's ARC is a compiler hack. It only works if you happen to use set of Cocoa libraries that are recognized by the compiler and allow for some magic incantation.
You cannot make any Objective-C library ARC aware.
ARC is a good solution for Objective-C, because Apple never managed to have their GC working safely in all situations, given the underlying C type system.
> .NET still does GC, it is only the WinRT APIs (something like COM) that manage resources through ref counting. There is some cool interop magic that makes this somewhat transparent to the programmer.
True, but C++ does not and you still have the performance penalty of reference counting.
The only way to have reference counting with good performance is do what Parasol or Objective-C do, by removing unnecessary increment/decrement operations thanks to dataflow analysis.
Which is something that you cannot do just by using the WinRT runtime and need to rely on the cleverness of the compilers.
Actually, are you aware that reference counting tends to be presented on the first chapter of many CS books about garbage collection as poor man's GC?
I don't understand. How does ARC rely on more than what NSObject provides? I'm coming from the C++ shared_ptr world and ARC does not feel much different so far (less explicit, but easier to optimise).
Just read this document.
https://developer.apple.com/library/mac/#releasenotes/Object...
You need to write code with lots of special cases to be able to have ARC active and not fall into strange compiler errors.
Most of the restrictions (bridge casts and naming methods) are interoperation with non-ARC code, and from working on Java/JNI I can assure you GC<>manual interaction was worse.
It is of course still quite possible to get abandoned memory through retain cycles.
Not very relevant. For UI code, responsive resource allocation and de-allocation is much more important than saving a few % CPU cycles.
> Actually, are you aware that reference counting tends to be presented on the first chapter of many CS books about garbage collection as poor man's GC?
Yes! Sometimes the conventional wisdom doesn't hold in the end, or it doesn't hold for all use cases. But I should have been more clear that ref counting is GC, whereas what I refer to as GC involves sweeping reference roots periodically to identify garbage.
> Not very relevant. For UI code, responsive resource allocation and de-allocation is much more important than saving a few % CPU cycles.
I beg to differ. I consider missile control radar systems of military applications a bit more important than UIs.
There are military applications using real time GC systems, which I can list here if you want.
I also have a German magazine here (Making Games Magazin 1/13) that explains how Witcher2 for the Xbox 360 makes use of a GC.
Anyway one thing I do agree, automatic memory management, regardless of the form, should be the any of any programming language.
Pure manual memory management should be treated like Assembly. It will never go away and should only be used for the very few cases where there is no other way around the problem at hand.
I should have mentioned that the primary reason WinRT seems to use reference counting is for interop reasons: its much easier to great a UI toolkit that is programmable in both C# and C++. Note that WPF never had a C++ interface, while WinRT has one without the need for any bridge code.
Reference counting has some interesting applications where it is more appropriate trace-based GC. Heck, sometimes we want old-fashioned arenas (Pascal!), it would be nice if our languages could give us some choices.
Manual memory management is annoying but sometimes necessary. I can see why native programmers don't want to give it up as it constitutes the primary performance difference these days between native and managed languages.
As for not allowing cycles, I consider that a feature. The headache of memory management doesn't go away with GC. You still have to avoid inadvertently keeping references to objects through the undo stack & so on. Unintentional strong refs creep through GC code just as easily as memory leaks creep through code with manual memory management. Almost universally, I find that GC'd projects large enough to have memory management best practices implicitly do away with this freedom at the first opportunity by calling for acyclic or single-parent object ownership graphs. These restrictions primarily make it easier to think about object lifecycle -- the fact that they allow refcounting to suffice for memory management is icing on the cake.
The Rust compiler does this. Even so, 19% of the binary size in rustc is adjusting reference counts.
I am not exaggerating this. One-fifth of the code in the binary is sitting there wasted adjusting reference counts. This is much of the reason we're moving to tracing garbage collection.
All of those optimizations that you're talking about (for example, packing reference counts into the class pointer) will make adjusting reference counts take even more code size.
> As for not allowing cycles, I consider that a feature. The headache of memory management doesn't go away with GC.
The fact that memory management is still an issue doesn't mean that we shouldn't make it work as well as we can.
In large software projects, cycles are a persistent issue. Gecko had to add a backup cycle collector over its reference counting framework, and observed memory usage decreased significantly once it was implemented.
Hopefully in future versions of PyPy an even better garbage collector. :-)
This means each increment/decrement is a virtual method call with the corresponding invocation costs.
This is why the .NET runtime caches the WinRT objects, and even re-uses them instead of making a 1:1 use like C++/CX does.
Am I understanding you correct; are you implying that you think XNA was created by juniors? Would you say that because of this, it's a good thing XNA is being killed?
Cause personally I think it's been a terrible decision by Microsoft to kill XNA. A lot of indie game developers have relied on XNA and I really feel Microsoft can use the indie support. Sure, big name games might be a priority, but personally I feel most _interesting_ work is being done by indies. Indies tend to be less concerned with proven formulas and seem to see it more of a creative outlet for themselves[1]. I think it's a good thing frameworks like Monogame[2] exist, so developers can still put their existing XNA knowledge to good use - and not just limited to the Windows platform, but e.g. iOS and Android as well.
The Monogame website might not show very impressing examples, but a game like Bastion[3] was ported to other platforms using Monogame, showing very high-quality work can be created with XNA.
[1]: http://www.youtube.com/watch?v=GhaT78i1x2M
[2]: http://monogame.codeplex.com
[3]: http://supergiantgames.com/index.php/2012/08/bastions-open-s...
"Unicode-enabled functions are described in Conventions for Function Prototypes. These functions use UTF-16 (wide character) encoding, which is the most common encoding of Unicode and the one used for native Unicode encoding on Windows operating systems. Each code value is 16 bits wide .. New Windows applications should use UTF-16 as their internal data representation."
ugh
With all of these facts being true (I hope), today things are such that the Windows world mostly (but not completely -- they sometimes assume two-byte characters) correctly implements UTF-16, while the Linux world correctly implements UTF-8.
(That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.)
Ahh, I was wondering about that. So, I guess I'll just keep using cygwin.
On another note, I recently asked a friend who works at Microsoft how work is going. His reply: "Well, it's calibration time, so lots of sucking up to the boss." Must be hard to get much actual work done when you're worried about that all the time.
I do wonder, however, whether 'boo! MS's rating system is suboptimal, to say the least!' is a very useful comment here (which might by why we haven't seen Michael write here yet)
It's useful, sure, but nice? I'm not convinced.
How about an empty recycle bin command? Why, certainly, you can do that:
Teh F33243ck. Readable much? I sure hope your powershell scripts come with comments; the one's we've inherited sure didn't and they're black magic.Every time you have Win32 spilling over in Powershell, it looks like crap (0xA).
Though I don't use Trash/Recycle myself, to contrast, I like the simplicity of
but there is no way in hell they can/ever will or want to write powershell.
Absolutely basic stuff, like "find the path of this file" (%~dp0 in batch) is a 5 line copy-paste. Why? It's lovely that I can pipe .NET objects places, but every time i want it to actually do something, I end up in copy-paste hell.
As an intern I find this slightly offensive. ;)
I thought you just needed to do something like: $(ls $PSCommandPath).Directory
(Not that that isnt longer than %~dp0; but I am curious what the 5 lines actually does)
[1] http://stackoverflow.com/questions/5466329/whats-the-best-wa...
Sidenote: if something like node.js, entirely designed for fast asynchronous networking, despite all its callback hell and whatnot, is a better and more user-friendly Windows scripting host than Powershell, some people really should start to worry.
Maybe if Powershell had something like npm, including its (simply perfect) install-to-current-directory-by-default, people could fix all the holes MS left behind. I might even start to like it then.
Growing pains, all around.
EDIT: redacted information. Still, when that information we present, how would anyone be able to confirm it?
Great words for concluding a video game intro
I started to understand better how Microsoft works, after getting into the Fortune 500 enterprise world.
Many of the bad things geeks associate with Microsoft are actually present in any development unit of big clunky Fortune 500 companies.
https://news.ycombinator.com/item?id=2841934
Now the problem is not so much the kernel, but all the cruft a Windows-based OS drags along with it. The most visible symptom is the amount of storage used up by stuff that adds little or no readily apparent value to Windows RT.
Windows OSs are heavy compared to Android and other Linux-based OSs. That means inexpensive tablets and phones won't run Windows, and Windows is shut out of mobile device markets in India, Africa, and other developing areas. These markets are how Yulong (who??!!) became a top 10 mobile OEM.
OS X didn't change the world by bringing some great new underlying architecture to the table. In fact, their kernel and filesystem are arguably getting long in the tooth. The value that OS X brought to the table was the fantastic Carbon and Cocoa development platforms. And they have continued to execute and iterate on these platforms, providing the "Core" series of APIs (CoreGraphics, CoreAnimation, CoreAudio, etc.) to make certain HW services more accessible.
There's very little cool stuff to be gained in the windows world by developing a new kernel from scratch. A quantum leap would not solve MS's problem. The problem is the platform. What's really dead and bloated is the Win32 subsystem. The kernel doesn't need major tweaking. In fact, the NT kernel was designed from the beginning such that it could easily run the old busted Win32 subsystem alongside a new subsystem without needing to resort to expensive virtualization.
Unfortunately, the way Microsoft is built today it have a fatal organizational flaw that prevents creating the next great Windows platform. The platform/dev tools team and the OS team are in completely different business groups within the company. The platform team develops the wonderful .NET platform for small/medium applications and server apps while the OS team keeps crudging along with Win32. Managed languages have their place, but they have yet to gain traction for any top shelf large-scale windows client application vendors (Adobe, even Microsoft Office itself, etc.) Major client application development still relies on unmanaged APIs, and IMHO the Windows unmanaged APIs are arguably the worst (viable) development platform available today.
What Windows needs is a new subsystem/development platform to break with Win32, providing simplified, extensible unmanaged application development, with modern easy-to-use abstractions for hardware services such as graphics, data, audio and networking. This is starting to come to fruition with WinRT, but the inertia in large scale apps is unbelievable.
https://news.ycombinator.com/item?id=2841934
I thought Microsoft refusing to update their decades behind, ancient C compiler was just to piss me off and make life difficult cross-platform developers that need to work in C. Interesting to see this applies to their own employees too.
Microsoft's position in the market is already big enough that they'll never really be proven wrong on C unless they relent. But they're also not large enough to kill it outright.
I just remembered Microsoft wrote this scathing document: C++ for Kernel Mode Drivers: Pros and Cons http://msdn.microsoft.com/en-us/library/windows/hardware/gg4...
I didn't find an actual pro. Makes sense that a Microsoft Kernel developer would also be frustrated by their lack of modern C support.
One of the reason businesses have trouble really innovating is that it's hard in a business to work on long-term things when markets are very short sighted. Only mega-corps, monopolies, and governments can usually do that... or hobbyists / lifestyle businesses who are more casual about hard business demands.
That being said, MS is surely cash-rich enough to think long term. So this doesn't apply as much here.
I've also found that of all things optimization almost gets you looked down upon in most teams -- even young ones. "Premature optimization is the root of all evil," and all that, which is usually misinterpreted as "optimization is naive and a waste of time." It's seen as indicative of an amateur or someone who isn't goal-focused. If you comment "optimized X" in a commit, you're likely to get mocked or reprimanded.
In reality, "premature optimization is the root of all evil" is advice given to new programmers so they don't waste time dinking around with micro-optimizations instead of thinking about algorithms, data structures, and higher order reasoning. (Or worse, muddying their code up to make it "fast.") Good optimization is actually a high-skill thing. It requires deep knowledge of internals, ability to really comprehend profiling, and precisely the kind of higher-order algorithmic reasoning you want in good developers. Most good optimizations are algorithmic improvements, not micro-optimizations. Even good micro-optimization requires deep knowledge-- like understanding how pipelines and branch prediction and caches work. To micro-optimize well you've got to understand soup-to-nuts everything that happens when your code is compiled and run.
Personally I think speed is really important. As a customer I know that slow sites, slow apps, and slow server code can be a reason for me to stop using a product. Even if the speed difference doesn't impact things much, a faster "smoother" piece of code will convey a sense of quality. Slow code that kerchunks around "feels" inferior, like I can see the awful mess it must be inside. It's sort of like how luxury car engines are expected to "purr."
An example: before I learned it and realized what an innovative paradigm shift it was, speed is what sold me on git. The first time I did a git merge on a huge project I was like "whoa, it's done already?" SVN would have been kerchunking forever. It wasn't that the speed mattered that much. It was that the speed communicated to me "this thing is the product of a very good programmer who took their craft very seriously as they wrote it." It told me to expect quality.
Another example: I tried Google Drive, but uninstalled it after a day. It used too much CPU. In this case it actually mattered -- on a laptop this shortens battery life and my battery life noticeably declined. This was a while ago, but I have not been motivated to try it again. The slowness told me "this was a quick hack, not a priority." I use DropBox because their client barely uses the CPU at all, even when I modify a lot of files. Google Drive gives me more storage, but I'm not content to sacrifice an hour of battery life for that.
(Side note: on mobile devices, CPU efficiency has a much more rigid cost function. Each cycle costs battery.)
Speed is a stealth attribute too. Customers will almost never bring it up in a survey or a focus group unless it impacts their business. So it never becomes a business priority.
Edit: relevant: http://ubiquity.acm.org/article.cfm?id=1513451
Optimizing the right thing is good, but figure out what that thing is first.
But in what timeframe? The article seems to imply they are thinking only about short term value and ignoring medium and long term.
The fundamental assumption of the article - that the Windows kernel should strive toward the Linux kernel management model is patently absurd.
FOSS is free as in "free to break software that depends on your code."
I think a good analogy is centralized government economies vs private enterprise economies. The less people you have making key decisions and the more isolated you are from the effects of bad decisions, the easier it is to evolve and improve.
Obviously open source has a lot of failures and took a long time to catch up in certain areas. But things like the Linux kernel have become a massive, unstoppable force that's evolving quicker and more efficiently than ever before. Microsoft simply can't compete with the hundreds of companies and tens of thousands of developers working on it.
I think a good analogy is centralized government economies vs private enterprise economies. The less people you have making key decisions and the more isolated you are from the effects of bad decisions, the easier it is to evolve and improve.
Obviously open source has a lot of failures and took a long time to catch up in certain areas. But things like the Linux kernel have become a massive, unstoppable force that's evolving quicker and more efficiently than ever before. Microsoft simply can't compete with the hundreds of companies and tens of thousands of developers working on it.
I think this is a little unfair; the specific example is the Linux kernel where enormous emphasis is placed on never breaking userland.
I think a good analogy is centralized government economies vs private enterprise economies. The less people you have making key decisions and the more isolated you are from the effects of bad decisions, the easier it is to evolve and improve.
Obviously open source has a lot of failures and took a long time to catch up in certain areas. But things like the Linux kernel have become a massive, unstoppable force that's evolving quicker and more efficiently than ever before. Microsoft simply can't compete with the hundreds of companies and tens of thousands of developers working on it.
It's also for experienced programmers who dink around with macro-optimizations. For example, designing an entire application to be serializable-multi-threaded-contract-based when there's only a handful of calls going through the system. Or creating an abstract-database-driven-xml-based UI framework to automate the creation of tabular data when you have under a dozen tables in the application.
premature optimization is the root of all evil is a really really important mindset, and I agree it doesn't mean to not optimize, and many developers seem to take it that way.
X+1 = How many transactions your business does today
Y = How many transactions your business needs to do in order to survive
Y/X = What the current application needs to scale to in order to simply survive. This is the number where people start receiving paychecks.
(Y/X)4 = How far the current application needs to scale in order to grow.
The goal should be to build an application that can just barely reach (Y/X)4 - this means building unit tests that test the application under a load of (Y/X)4 and optimizing for (Y/X)4
Spending time trying to reach (Y/X)20 or (Y/X)100 is what I'd call premature optimization.
Disclaimer: (Y/X)4 is no real point of data that I know of, just something I pulled out as an example, anyone who knows of actual metrics used please feel free to correct.
I've got the wrong closure over HN.
66. Making something variable is easy. Controlling duration of constancy is the trick.
see http://www.cs.cmu.edu/~spot/nitrous/top.html
http://www.cs.yale.edu/quotes.html
Archive.org's backup of the [behind a paywall] ACM article:
http://web.archive.org/web/20080513191245/http://www-pu.info...
And if optimization always hinders evolution, boy should Windows be evolving... I mean... the NT kernel should have smashed through all kinds of antiquated paradigms by now. It should be doing memory deduplication, disk deduplication, fast JIT compilation of binaries for alternative architectures. It should support live process migration between machines, joining of systems together efficiency to form larger super-systems, a better permission model obviating the need to rely completely on virtualization for true privilege isolation in enterprise environments. It should have truly efficient network filesystems supporting disconnected operation, sharding, etc.
Oh wait... it's stuck in the 90s... never mind. And it's slow.
Linux, which optimizes a lot, has at least some of the things I mentioned above.
"Premature optimization is the root of all evil" is a deeply nuanced statement that is nearly always misunderstood. "Optimization hinders evolution" is probably likewise. They're quotes cherry-picked out of context from the minds of great craftsmen who deeply understand their craft, and alone I do not believe they carry the full context required to comprehend what they really mean. I think they have more to do with maintaining clarity and focusing on higher-order reasoning than they do with whether or not to try to make things run faster. (And like I said, the most effective optimizations are usually higher-order conceptual algorithmic improvements.)
Windows isn't slower at running Windows apps, fitting into a Windows infrastructure (Active Directory, management tools, Exchange etc), using Windows device drivers, working with NTFS volumes and their features, backwards compatibility, printers etc.
It all comes down to what the goals of the users (or purchasers) are, and I doubt anyone buys Windows because of "performance" in the sense being talked about. But they do care about the "performance" of items mentioned in my previous paragraph.
Linux has been able to optimise because of being open source and vehemently ignoring closed source. Open source means for example that the Linux USB stack could be optimised and all affected code due to API changes could be updated. This and other topics are covered really well in Greg Kroah-Hartman's OLS 2006 keynote - http://www.kroah.com/log/linux/ols_2006_keynote.html - see "Linux USB Code" about halfway down for that specific example.
I'm not an experienced programmer, and I'd use that approach anyway, simply because it makes sense (is there any alternative that isn't worse?). What does that mean? (Oh, and I'd skip XML. I abhor violence.)
Just bite the bullet and render them by hand. It'll take less time than writing the abstract whatever-driven autogenerated UI framework, making it lay things out nicely, handle all the corner cases and auto-wiring of stuff which might not be needed in all cases, and tweaking the generated code to look good for all the data.
For small applications, dynamic form generation infrastructure dwarfs the actual business logic. It means writing a lot of code which isn't solving your business problem.
Your project has an extra layer of 'meta'. It's harder to debug. It decreases flexibility. Validation is hard for multi-field relationships. Special-casing that one form can require major infrastructure changes. The approach tends to be slower and buggier than the naive approach for all but the most form-heavy applications.
Also, why would an extra layer of 'meta' make it harder to debug and decrease flexibility? I would have thought that it would enforce more structure by centralizing certain functionality, thus making it correct-by-design instead of relying that you'll follow conventions in multiple places consistently, and increase flexibility by separating aspects that you'd otherwise have to "weave-in" throughout the code and later change in multiple places.
Yes, it's an interesting problem. That's exactly what makes it fly paper ;)
Less flexible: suppose your framework is doing dynamic form generation on top of wxPython. You could have a date picker as a radio box item if you wanted. However it would probably not a be a good use of time to support that in your MDA system.
Harder to debug: Usually, bugs in the auto-form-generation infrastructure are "trickier" than the bugs you would get if you just wrote the forms.
A lot of the use cases for dynamic form generation are adequately served by automatic scaffolding in django/rails/turbogears or on the enterprisey side, technologies like Oracle forms and its successors.
And for those corner cases, code them as one-offs but within the templating system, and keep the benefits of any logging etc from the system.
> It's also for experienced programmers who dink around with macro-optimizations.
The hilarious thing is that everyone seems to think everyone else's optimizations are premature.
Don't believe me? Just go ahead and ask someone an optimization question, like maybe on StackOverflow. Those who respond might not know you, but I'll be damned if their first reply isn't to tell you that you probably shouldn't even be optimizing in the first place, because obviously if you'd thought about it more carefully, you'd have realized it's premature.
Do you have to spend all your time and resources architecting the system poorly the first time, just to "prove" that you are wrong -- even though you knew it would happen before you even started coding?!
That's like telling an engineer to prove (by actually building it and subjecting it to a lot of stress) that the bridge he designed would be prone to collapsing before helping him find a better design!