In either case, they are specialized tools for solving specific problems.
Exactly. And if you don't know how to program practically in the first place, they still won't help you. They'll help you out with specific problems (I need to let other parts of the program know about when this happened), but you need to know to think in terms of having those problems (I'm going to have to need different parts of the program, with one part doing this and one part doing that) to start with.
I don't figure I ever mentioned hierarchies. I mentioned interfaces. (Even though I don't like the language itself, I think Go's approach to this, with duck-typed interfaces checked by the compiler and no type hierarchy, gets close. It's missing mixins though.) I agree with most of what you're saying.
I've heard design patterns referred to as recipes. If that was the case, it'd all be well and good; people can learn 20 recipes and be essentially set for life, without learning to really cook as such. But that's not it entirely.
Design patterns are more equivalent to a step in a recipe or a cooking technique: Peel something. Dice something. Make a reduction. Whip cream. If you don't know how to assemble them in the right order, or where to add the actual ingredients, you're not going to make it as a programmer.
Good programming often does include some design patterns; nearly all programs do. But just going through a list of them doesn't teach you to do anything. If you already have an inkling of where to go, maybe learning a particular design pattern can nudge you further in the right direction, or fill in a blank. But they don't put the key in the lock and turn it.
People will do as they are first taught unless there's a compelling reason not to. If you first teach them to just code fast and loose and only then to put up structure, they'll do it fast and loose, since structure takes time. It's not obvious to them most of the time that the right sort of structure saves time and spares you from headaches. You don't need to create huge abstractions for that to be true (it's probably likely not to be true, unless they know what they're doing).
Most courses are long enough that you can do a few small exercises per week to learn very minute concepts, or to build from the very bottom, but you should be able to make two or three longer exercises as well. I think a good way is to keep a well-chosen exercise on the cooker, adapting it to incorporate things as you learn them. If this is done well, and if it goes from messy to cleaned-up near the end without making it frustrating, it could provide reinforcement that one way is clunkier and needs more code than the other way.
Sure, it's a general problem, and I agree with what you say. It takes active participation by both the teacher and the student, but either one can make it easier.
What I meant by the part about polymorphism is that I've seen (and taken) tests where the important thing was knowing the word for it. There's no encouragement to actually exploit it beyond the so obviously theoretical examples, like the zoo example where you have different animal buttons do different things. How about making a chess game instead? That shows off interfaces/abstract base classes in a practical example - were you to do a game, you'd have to have different classes for different pieces, but you'd have to have some way of binding them all together in a general fashion.
It sounds like you're saying "things change, so they should never be stable, unless sometimes". Part of life as a programmer is vigilance and refactoring. Yeah, you're gonna mess up and make bad choices every now and then, but I mean things like breaking up the logic and the user interface into two separate layers. It's so simple and it forces you to do choices that will make sense weeks, months and years into the life of your application. Not only that, but it's something that's often ignored entirely in the avalanche of short exercises that plague these sorts of courses.
Good intentions will turn out bad results. I'm aware that if my suggestion is implemented, there will be teachers who force students to make elaborate sorta educated guesses, and they won't always be stellar. But they're part of the road towards being a programmer. You're going to need to tackle it someday. If you know how to think like a programmer and know the basics, you can read up on the theory later, but it's hard to be stuffed with all this knowledge that you can recite but don't understand and then try to squeeze in some deeper meaning.
The big problem with OO courses has always been that there's far more focus on the mechanism (and, lately, on design patterns) than on actually structuring your program to take advantage of objects. The word "polymorphism" isn't as important as getting across the concept that you can coordinate a few things as if they were the same thing, and have them act in different ways. Knowing a bunch of design patterns by name isn't as important as figuring out once and for all that you can structure your program in such a way that you can create interfaces (not necessarily actual interfaces/protocols) between different parts of your program and essentially replace them, or at least rework them entirely without having the whole house of cards collapsing.
There's no focus on making it click. There's no course that teaches you explicitly just about formulating problems in code, and that makes me sad.
If someone says "stop being an asshole" and your conclusion is "but then I will have nothing to say", what the hell is wrong with you?
I am continually amazed with what people defend this behavior with. You don't need to be devoid of humor or steeped in forced neutrality, you don't need to stop speaking your mind or fear that you can't have an open and honest discussion. You just need to stop being a dick. (Which would probably help any arguments you're trying to make in any case.)
("You" doesn't refer to parent or grandparent; it's just a placeholder. "One" doesn't sound good.)
I don't understand how pointing out that it's not of the same model as the PC junior keyboard, which comes down to facts, is "projecting". I figured that someone who would equate the MacBook keyboard with the old chiclet keyboards with a rubbery feel and without durable mechanisms hadn't used them, since the difference is quite stark.
But okay, it does suck for you that they don't make the previous model then.
I had a PowerBook G4, then a MacBook, their first to have the chiclet keyboard, then an early aluminium MacBook Pro. The chiclet keyboard is the most comfortable keyboard I've used, and a day didn't go by when I was on the MBP that I didn't want the chiclet keyboard back. (I have since gotten a MacBook Pro with the chiclet keyboard, and I'm very happy with it.) It may share some superficial looks with actual rubber-like chiclet keyboards (like the ZX Spectrum keyboard or those waterproof things you can roll up), but the keys are real keys; very distinct and deliberate without needing to travel far. The connection is made by scissor switches and the keys provide just the right amount of resistance. The aluminium keyboard was prone to accidentally triggering too easily unless you were built like a crane fly.
It's not too hard to find reviews of the desktop Apple keyboard of the same model where people walked in with preconceived notions but are now converted. Here's one. I have one of those keyboards at work at a mostly-Windows-based development shop, and the usual sequence from interested visitors tends to be to ridicule me, paint me with overzealous brand loyalty (who the hell uses an Apple keyboard!?) and then trying it out for half a minute before deciding they want one themselves, damn the torpedoes, even though they'll have to remap some keys and swallow some pride. Even people who already have flat, laptop-like keyboards tend to note an improvement.
If you've tried the keyboard for a significant period of time and don't like it, I apologize. Everyone should have the right to use a keyboard they're comfortable with. But you should know that you're in a clear minority from what I've seen, and that regardless of that, the keyboard is not actually anything like a PC junior model keyboard and people tend to like it because of how it feels, not because of how it makes them feel.
If you want to run state-of-the-art C# right now, this instant, Mono supports C# 4.0 just as well as Microsoft does. If you want to run state-of-the-art.NET framework, you're boned, because Mono skimps on a number of features from it, like WPF or mirror ports of LINQ to SQL or Entity Framework (although DbLinq and NHibernate provide similar solutions).
If you are willing to stick to C# and other frameworks than Microsoft's own, you've been able to do that for several years and nothing bad will happen to you. It's an accident of history, because Microsoft didn't quite open up the language well enough for this to have happened on its own, but the progress doesn't go away and Microsoft has started making available more of its frameworks as full-on BSD-level open source since Mono got off the ground. (I believe that Microsoft's implementation of the entire.NET framework will be open sourced within five years. I have nothing to back this up with except for the trend.)
That said, you probably shouldn't build exactly what you're planning to do for your tens-of-millions J2EE system in Mono, no. I might be more okay with that if Java wasn't such a painful language to program in.
If you're looking for web backend, first of all, I wouldn't choose Go for anything. It's too young and too prone to change in weird ways, and it's got an exception handling mechanism that's... exceptional. Like nothing you've seen before - for good reason, I believe.
For better or worse, Ruby's got plenty of web frameworks even if Rails isn't your thing. With some luck, you'll find something that should suit you perfectly, as long as you get along with the language.
I didn't start it. Someone said it sucked. I just said "nuh-uh and here's why". Someone retorted. I replied. Now you tell me, through posting a comment about something else than the topic, that I shouldn't post off-topic comments. If that's really what bugs you, go talk down dreamchaser instead, or the people who upvoted his comment.
And C# isn't even half as good as bacon. It's not even the best programming language I know of. (I mentioned Ruby, which apparently was decisively on topic, but you hadn't gotten to your "on-topic" phase yet, so you chose to bitch about the rest instead of actually cultivating the discussion, something that only people you disagree with and can convincingly describe as mouth-breathing scum should have to do.) I just agree with previous posters that it doesn't deserve most of the crap it gets, and that, as someone who also does a fair amount of other languages, share their values about keeping away from Microsoft by default and has actually used C#, I'm not as turned off as the asker seems to be. That actually seems to be on topic to me, but fair enough.
This is Slashdot: he would have gotten far fewer replies about C# had he just not mentioned Microsoft altogether. And he seems to have done alright with on topic commentary too. I'll reply to any reply I get, but I'll stop this discussion if you want. It's easy: just don't reply.
I know exactly why he was porting it. No one was doing anything new anymore in that environment. There was no new language, no new framework, nothing to make coding more productive than ten years prior aside from whatever had ground its way through Qt's world of macros or the C/C++ standards. (I'm wary of saying "easier" in that crowd. I don't mean that programs should write themselves for me, but there are easy wins to be had by simply learning from past mistakes. C doesn't need to go anywhere for the tasks it's made for. It just doesn't have to be the default for everything else, too.)
Maybe taking to porting Microsoft's previous version is alarming in a way you didn't address: there was no one looking forward except for repaving every damn layer below the window manager.
First, migration. When that ever actually becomes an issue for me, I'll let you know. Microsoft used to invent a new database access acronym every week or so, but they both support the old acronyms in perpetuity and have slowed down their pace dramatically. Except for swearing loudly at old projects using stored procedures and DataTables instead of an ORM with LINQ support (basically queries over objects that also turn into precompiled queries for the database using reified map/filter-like query expressions; look it up), I haven't had any actual problems with migrating anything. No wild goose chases even with major.NET upgrades. My legs are intact.
If you mean planning to migrate to another platform, who does that? You pick a platform you're comfortable with supporting, you build what they need and then you support it. Even if you were to specifically wean a client off of Redmond (or anything else), you're not going to "forget" that plan. They're going to come to you, or maybe you're going to come to them, and say so, and that's when you draw up the plan. You don't build things with the intent to then wildly change platforms midstream, and if you do, you damn well have a migration plan. (If you take on that sort of task and don't, you're short-sighted, by which I mean profoundly stupid.)
I didn't say a thing about portability in my comment; nor did the original parent. Either go higher ("scripting" languages) or lower (C, C++) on the abstraction scale if you want pure language portability. If you want "kinda sorta" portability, C# happens to offer that right now thanks to Mono, and it's not just academic in that there are real Linux programs being written, distributed and used with it. It's an accident of history, but the progress that's been made won't go away overnight either.
I wouldn't drown myself just in the portability of the language, though. Most cross-platform GUI toolkits suck. You end up designing for the lowest common denominator. Java is egregious with its several official toolkits at various stages of decrepitude, but it's far from the worst offender. It's a great solution, as long as you want your users to suffer equally.
I think the cross-platform toolkit people are coming around to is the web, where the parameters shift a bit. The backend (whichever server side component you use) and the frontend (the web pages) need to be portable in different ways, but both are easier to achieve. You can realistically host C# sites (with ASP.NET, including MVC) on Mono on non-Windows with good performance and support. I'm not losing any sleep over "locking in" our clients; it's usually a clear improvement to where they came from, even if it isn't exactly PHP in terms of ubiquity.
Okay, I'll bite: C# is a good language that makes more progress and is more eager to grow modern capabilities than Java is. None of the two will go away overnight, and C# isn't the very best thing ever, but I don't think people would have any problem giving it the credit it does deserve if Anders Hejlsberg worked somewhere else than Microsoft.
I personally mostly prefer to code in other languages than C#, like Ruby, but I'd much rather work in C# than in Java and that's not for a lack of trying. I use and love ASP.NET MVC, which is open source, patterned on Rails and all about the code, with no "insert control here" wizards in sight.
I know that there's a lot of people who drag a grid view onto a Web Forms canvas, hook up the data bindings, bill you the licenses of everything in the server stack and three weeks' work and then can't actually fix anything because they don't know how to code. Aside from conceding that Microsoft has largely traditionally gone out of their way to supply these people with software, I call Sturgeon's Law. Just please don't let that fool you into thinking that everyone who has touched or developed for a Microsoft product has the coding skills (and chair propelling propensity) of Steve Ballmer. If that's all they were capable of, I would be right behind you.
You're right that the people that Apple is now pissing off won't be queueing up to port their applications to Objective-C. But it's clear that Apple doesn't want to invest that kind of money in that kind of user experience and then have to support it. They're already well on their way to slough off Carbon completely.
They want to settle on just one framework that they provide and support. (And yes, I said framework, not languages. There are supported bridges to Objective-C for Ruby and Python, and unsupported bridges in many other languages.)
I would conserve my bewilderment until Apple starts making it impossible to do, say, Qt apps.
And frankly, Mac can ill afford to lose software.
My hunch tells me that there are more Cocoa applications than Java GUI applications, and even if that isn't strictly the case, that the number of people that are writing Java GUI applications each day are shrinking, and the number of people that are writing Cocoa applications each day are growing. (Yes, excluding iOS.)
Mac as a platform doesn't have a ton of software compared to Windows, but that doesn't mean that this makes even a sizable dent in the installed applications that people use. Name one pervasive Mac Java application besides Eclipse and Vuze.
(That doesn't mean that it's a valid reason to kill a Java runtime. But that sentence was discussing the impact, not the action.)
You're right. You're very right. That doesn't mean *every* other point is wrong, though. The PC era won't be over for a long time, and the laptop has won the war in the office, but businesses are also the first to look, point and drool at the iPad. Some didn't like Tablet PCs when they came out, and most simply focus on what it has the potential to do that laptops don't. (Nearly all those things has to do with its form factor and the human mind.)
It does a serviceable subset of what many people do with their laptops (yes, except for Flash games, etc) and serves its "light pad in a meeting" niche well. Some people will move to an iPad instead of a laptop, and a laptop instead of their desktop at work.
I'm also amazed at the idea that the iPad has to fully supplant the laptop before it gets anywhere. The Web doesn't fully supplant the desktop OS yet, and I'm guessing no one would call that a failure. It's about doing enough things well enough and a few things that nothing else does.
The composition of the driving logic is the most important part. It can't be a big switch case. It has to be a bunch of interconnecting heuristics, constantly looking for every sign of trouble, being able to figure out context and priority of every such signal and also failing gracefully.
There are also tough tradeoffs: It's obvious that if someone's running out in front of the car, you can't go even if the light just turned green, but if a small animal ran out in front of the car, you're doing 110 km/h, every lane is packed and you're on a bridge, you're probably best off actually continuing. It becomes an equation with a thousand terms, solved continuously.
To begin with, I don't know of another Swedish party with an official position on pharmacy patents.
There will always be people who want "copyrighted stuff for free", and since it became plausible a few decades ago, there always has been nearly free availability of "copyrighted stuff". The difference is that the rest of the democracy fundaments weren't being torn down in defense of it.
The IPRED directive intended to halt file sharing, as implemented in Sweden, perverts the concept of common carriers (it's not the PO's fault if you send people pot in envelopes), a fair trial (the civil trials are exempt from setting reasonable damages, they can seize your bank account, raid your house, make you the target of an investigation without telling you and you have to prove that you're not personally guilty) and reinvents the shame pole (you have to take out an ad in a newspaper of your own payment saying that you did something wrong). Some of these concepts date back to the Roman Empire. Is it really proportional to the crime?
There are more directives and motions like these, in other areas, and the Pirate Party is fighting them too, like supporting the repeal of a recent law enabling a defense authority, FRA, to tap every packet of Internet traffic that crosses the country borders in the interests of "preventing external threats", painted by a former Stasi employee as a tool they could only have dreamed of. Or why not by railing against the implementation of the EU Data Retention Directive, which would document every cell phone call or email. Don't confuse poor research and jumped conclusions with their actual, openly-discussed agenda.
But even where the focus is on file sharing, I don't think you'll agree after reading through the actual law that the measures are proportional, necessary or effective.
Something else: the summary mentions the "Hard Liquor Party". Although tiny (the data from the election agency lists where they appear specifically on write-in votes because their per-party ballot papers weren't available), they're a real political party, and they want to reduce the Swedish alcohol consumption by 50% to achieve many other beneficial side-effects, like decreases in domestic violence, poor performance in schools, heart failure and so on. While they didn't get my vote, I empathize with their politics.
Slashdot Mirror
Exactly. And if you don't know how to program practically in the first place, they still won't help you. They'll help you out with specific problems (I need to let other parts of the program know about when this happened), but you need to know to think in terms of having those problems (I'm going to have to need different parts of the program, with one part doing this and one part doing that) to start with.
I don't figure I ever mentioned hierarchies. I mentioned interfaces. (Even though I don't like the language itself, I think Go's approach to this, with duck-typed interfaces checked by the compiler and no type hierarchy, gets close. It's missing mixins though.) I agree with most of what you're saying.
I've heard design patterns referred to as recipes. If that was the case, it'd all be well and good; people can learn 20 recipes and be essentially set for life, without learning to really cook as such. But that's not it entirely.
Design patterns are more equivalent to a step in a recipe or a cooking technique: Peel something. Dice something. Make a reduction. Whip cream. If you don't know how to assemble them in the right order, or where to add the actual ingredients, you're not going to make it as a programmer.
Good programming often does include some design patterns; nearly all programs do. But just going through a list of them doesn't teach you to do anything. If you already have an inkling of where to go, maybe learning a particular design pattern can nudge you further in the right direction, or fill in a blank. But they don't put the key in the lock and turn it.
People will do as they are first taught unless there's a compelling reason not to. If you first teach them to just code fast and loose and only then to put up structure, they'll do it fast and loose, since structure takes time. It's not obvious to them most of the time that the right sort of structure saves time and spares you from headaches. You don't need to create huge abstractions for that to be true (it's probably likely not to be true, unless they know what they're doing).
Most courses are long enough that you can do a few small exercises per week to learn very minute concepts, or to build from the very bottom, but you should be able to make two or three longer exercises as well. I think a good way is to keep a well-chosen exercise on the cooker, adapting it to incorporate things as you learn them. If this is done well, and if it goes from messy to cleaned-up near the end without making it frustrating, it could provide reinforcement that one way is clunkier and needs more code than the other way.
Sure, it's a general problem, and I agree with what you say. It takes active participation by both the teacher and the student, but either one can make it easier.
What I meant by the part about polymorphism is that I've seen (and taken) tests where the important thing was knowing the word for it. There's no encouragement to actually exploit it beyond the so obviously theoretical examples, like the zoo example where you have different animal buttons do different things. How about making a chess game instead? That shows off interfaces/abstract base classes in a practical example - were you to do a game, you'd have to have different classes for different pieces, but you'd have to have some way of binding them all together in a general fashion.
It sounds like you're saying "things change, so they should never be stable, unless sometimes". Part of life as a programmer is vigilance and refactoring. Yeah, you're gonna mess up and make bad choices every now and then, but I mean things like breaking up the logic and the user interface into two separate layers. It's so simple and it forces you to do choices that will make sense weeks, months and years into the life of your application. Not only that, but it's something that's often ignored entirely in the avalanche of short exercises that plague these sorts of courses.
Good intentions will turn out bad results. I'm aware that if my suggestion is implemented, there will be teachers who force students to make elaborate sorta educated guesses, and they won't always be stellar. But they're part of the road towards being a programmer. You're going to need to tackle it someday. If you know how to think like a programmer and know the basics, you can read up on the theory later, but it's hard to be stuffed with all this knowledge that you can recite but don't understand and then try to squeeze in some deeper meaning.
The big problem with OO courses has always been that there's far more focus on the mechanism (and, lately, on design patterns) than on actually structuring your program to take advantage of objects. The word "polymorphism" isn't as important as getting across the concept that you can coordinate a few things as if they were the same thing, and have them act in different ways. Knowing a bunch of design patterns by name isn't as important as figuring out once and for all that you can structure your program in such a way that you can create interfaces (not necessarily actual interfaces/protocols) between different parts of your program and essentially replace them, or at least rework them entirely without having the whole house of cards collapsing.
There's no focus on making it click. There's no course that teaches you explicitly just about formulating problems in code, and that makes me sad.
This will "defiantly" fix the problem.
If someone says "stop being an asshole" and your conclusion is "but then I will have nothing to say", what the hell is wrong with you?
I am continually amazed with what people defend this behavior with. You don't need to be devoid of humor or steeped in forced neutrality, you don't need to stop speaking your mind or fear that you can't have an open and honest discussion. You just need to stop being a dick. (Which would probably help any arguments you're trying to make in any case.)
("You" doesn't refer to parent or grandparent; it's just a placeholder. "One" doesn't sound good.)
I don't understand how pointing out that it's not of the same model as the PC junior keyboard, which comes down to facts, is "projecting". I figured that someone who would equate the MacBook keyboard with the old chiclet keyboards with a rubbery feel and without durable mechanisms hadn't used them, since the difference is quite stark.
But okay, it does suck for you that they don't make the previous model then.
I had a PowerBook G4, then a MacBook, their first to have the chiclet keyboard, then an early aluminium MacBook Pro. The chiclet keyboard is the most comfortable keyboard I've used, and a day didn't go by when I was on the MBP that I didn't want the chiclet keyboard back. (I have since gotten a MacBook Pro with the chiclet keyboard, and I'm very happy with it.) It may share some superficial looks with actual rubber-like chiclet keyboards (like the ZX Spectrum keyboard or those waterproof things you can roll up), but the keys are real keys; very distinct and deliberate without needing to travel far. The connection is made by scissor switches and the keys provide just the right amount of resistance. The aluminium keyboard was prone to accidentally triggering too easily unless you were built like a crane fly.
It's not too hard to find reviews of the desktop Apple keyboard of the same model where people walked in with preconceived notions but are now converted. Here's one. I have one of those keyboards at work at a mostly-Windows-based development shop, and the usual sequence from interested visitors tends to be to ridicule me, paint me with overzealous brand loyalty (who the hell uses an Apple keyboard!?) and then trying it out for half a minute before deciding they want one themselves, damn the torpedoes, even though they'll have to remap some keys and swallow some pride. Even people who already have flat, laptop-like keyboards tend to note an improvement.
If you've tried the keyboard for a significant period of time and don't like it, I apologize. Everyone should have the right to use a keyboard they're comfortable with. But you should know that you're in a clear minority from what I've seen, and that regardless of that, the keyboard is not actually anything like a PC junior model keyboard and people tend to like it because of how it feels, not because of how it makes them feel.
The MacBook Air now has two USB ports.
Otherwise, you're correct. Carry on.
If you want to run state-of-the-art C# right now, this instant, Mono supports C# 4.0 just as well as Microsoft does. If you want to run state-of-the-art .NET framework, you're boned, because Mono skimps on a number of features from it, like WPF or mirror ports of LINQ to SQL or Entity Framework (although DbLinq and NHibernate provide similar solutions).
If you are willing to stick to C# and other frameworks than Microsoft's own, you've been able to do that for several years and nothing bad will happen to you. It's an accident of history, because Microsoft didn't quite open up the language well enough for this to have happened on its own, but the progress doesn't go away and Microsoft has started making available more of its frameworks as full-on BSD-level open source since Mono got off the ground. (I believe that Microsoft's implementation of the entire .NET framework will be open sourced within five years. I have nothing to back this up with except for the trend.)
That said, you probably shouldn't build exactly what you're planning to do for your tens-of-millions J2EE system in Mono, no. I might be more okay with that if Java wasn't such a painful language to program in.
I'll have what he's having. I could use a good high.
Well done! Leading by example.
If you're looking for web backend, first of all, I wouldn't choose Go for anything. It's too young and too prone to change in weird ways, and it's got an exception handling mechanism that's... exceptional. Like nothing you've seen before - for good reason, I believe.
For better or worse, Ruby's got plenty of web frameworks even if Rails isn't your thing. With some luck, you'll find something that should suit you perfectly, as long as you get along with the language.
I didn't start it. Someone said it sucked. I just said "nuh-uh and here's why". Someone retorted. I replied. Now you tell me, through posting a comment about something else than the topic, that I shouldn't post off-topic comments. If that's really what bugs you, go talk down dreamchaser instead, or the people who upvoted his comment.
And C# isn't even half as good as bacon. It's not even the best programming language I know of. (I mentioned Ruby, which apparently was decisively on topic, but you hadn't gotten to your "on-topic" phase yet, so you chose to bitch about the rest instead of actually cultivating the discussion, something that only people you disagree with and can convincingly describe as mouth-breathing scum should have to do.) I just agree with previous posters that it doesn't deserve most of the crap it gets, and that, as someone who also does a fair amount of other languages, share their values about keeping away from Microsoft by default and has actually used C#, I'm not as turned off as the asker seems to be. That actually seems to be on topic to me, but fair enough.
This is Slashdot: he would have gotten far fewer replies about C# had he just not mentioned Microsoft altogether. And he seems to have done alright with on topic commentary too. I'll reply to any reply I get, but I'll stop this discussion if you want. It's easy: just don't reply.
I know exactly why he was porting it. No one was doing anything new anymore in that environment. There was no new language, no new framework, nothing to make coding more productive than ten years prior aside from whatever had ground its way through Qt's world of macros or the C/C++ standards. (I'm wary of saying "easier" in that crowd. I don't mean that programs should write themselves for me, but there are easy wins to be had by simply learning from past mistakes. C doesn't need to go anywhere for the tasks it's made for. It just doesn't have to be the default for everything else, too.)
Maybe taking to porting Microsoft's previous version is alarming in a way you didn't address: there was no one looking forward except for repaving every damn layer below the window manager.
First, migration. When that ever actually becomes an issue for me, I'll let you know. Microsoft used to invent a new database access acronym every week or so, but they both support the old acronyms in perpetuity and have slowed down their pace dramatically. Except for swearing loudly at old projects using stored procedures and DataTables instead of an ORM with LINQ support (basically queries over objects that also turn into precompiled queries for the database using reified map/filter-like query expressions; look it up), I haven't had any actual problems with migrating anything. No wild goose chases even with major .NET upgrades. My legs are intact.
If you mean planning to migrate to another platform, who does that? You pick a platform you're comfortable with supporting, you build what they need and then you support it. Even if you were to specifically wean a client off of Redmond (or anything else), you're not going to "forget" that plan. They're going to come to you, or maybe you're going to come to them, and say so, and that's when you draw up the plan. You don't build things with the intent to then wildly change platforms midstream, and if you do, you damn well have a migration plan. (If you take on that sort of task and don't, you're short-sighted, by which I mean profoundly stupid.)
I didn't say a thing about portability in my comment; nor did the original parent. Either go higher ("scripting" languages) or lower (C, C++) on the abstraction scale if you want pure language portability. If you want "kinda sorta" portability, C# happens to offer that right now thanks to Mono, and it's not just academic in that there are real Linux programs being written, distributed and used with it. It's an accident of history, but the progress that's been made won't go away overnight either.
I wouldn't drown myself just in the portability of the language, though. Most cross-platform GUI toolkits suck. You end up designing for the lowest common denominator. Java is egregious with its several official toolkits at various stages of decrepitude, but it's far from the worst offender. It's a great solution, as long as you want your users to suffer equally.
I think the cross-platform toolkit people are coming around to is the web, where the parameters shift a bit. The backend (whichever server side component you use) and the frontend (the web pages) need to be portable in different ways, but both are easier to achieve. You can realistically host C# sites (with ASP.NET, including MVC) on Mono on non-Windows with good performance and support. I'm not losing any sleep over "locking in" our clients; it's usually a clear improvement to where they came from, even if it isn't exactly PHP in terms of ubiquity.
Okay, I'll bite: C# is a good language that makes more progress and is more eager to grow modern capabilities than Java is. None of the two will go away overnight, and C# isn't the very best thing ever, but I don't think people would have any problem giving it the credit it does deserve if Anders Hejlsberg worked somewhere else than Microsoft.
I personally mostly prefer to code in other languages than C#, like Ruby, but I'd much rather work in C# than in Java and that's not for a lack of trying. I use and love ASP.NET MVC, which is open source, patterned on Rails and all about the code, with no "insert control here" wizards in sight.
I know that there's a lot of people who drag a grid view onto a Web Forms canvas, hook up the data bindings, bill you the licenses of everything in the server stack and three weeks' work and then can't actually fix anything because they don't know how to code. Aside from conceding that Microsoft has largely traditionally gone out of their way to supply these people with software, I call Sturgeon's Law. Just please don't let that fool you into thinking that everyone who has touched or developed for a Microsoft product has the coding skills (and chair propelling propensity) of Steve Ballmer. If that's all they were capable of, I would be right behind you.
You're right that the people that Apple is now pissing off won't be queueing up to port their applications to Objective-C. But it's clear that Apple doesn't want to invest that kind of money in that kind of user experience and then have to support it. They're already well on their way to slough off Carbon completely.
They want to settle on just one framework that they provide and support. (And yes, I said framework, not languages. There are supported bridges to Objective-C for Ruby and Python, and unsupported bridges in many other languages.)
I would conserve my bewilderment until Apple starts making it impossible to do, say, Qt apps.
My hunch tells me that there are more Cocoa applications than Java GUI applications, and even if that isn't strictly the case, that the number of people that are writing Java GUI applications each day are shrinking, and the number of people that are writing Cocoa applications each day are growing. (Yes, excluding iOS.)
Mac as a platform doesn't have a ton of software compared to Windows, but that doesn't mean that this makes even a sizable dent in the installed applications that people use. Name one pervasive Mac Java application besides Eclipse and Vuze.
(That doesn't mean that it's a valid reason to kill a Java runtime. But that sentence was discussing the impact, not the action.)
It's worse than that; I believe they were British.
You're right. You're very right. That doesn't mean *every* other point is wrong, though. The PC era won't be over for a long time, and the laptop has won the war in the office, but businesses are also the first to look, point and drool at the iPad. Some didn't like Tablet PCs when they came out, and most simply focus on what it has the potential to do that laptops don't. (Nearly all those things has to do with its form factor and the human mind.)
It does a serviceable subset of what many people do with their laptops (yes, except for Flash games, etc) and serves its "light pad in a meeting" niche well. Some people will move to an iPad instead of a laptop, and a laptop instead of their desktop at work.
I'm also amazed at the idea that the iPad has to fully supplant the laptop before it gets anywhere. The Web doesn't fully supplant the desktop OS yet, and I'm guessing no one would call that a failure. It's about doing enough things well enough and a few things that nothing else does.
The composition of the driving logic is the most important part. It can't be a big switch case. It has to be a bunch of interconnecting heuristics, constantly looking for every sign of trouble, being able to figure out context and priority of every such signal and also failing gracefully.
There are also tough tradeoffs: It's obvious that if someone's running out in front of the car, you can't go even if the light just turned green, but if a small animal ran out in front of the car, you're doing 110 km/h, every lane is packed and you're on a bridge, you're probably best off actually continuing. It becomes an equation with a thousand terms, solved continuously.
To begin with, I don't know of another Swedish party with an official position on pharmacy patents.
There will always be people who want "copyrighted stuff for free", and since it became plausible a few decades ago, there always has been nearly free availability of "copyrighted stuff". The difference is that the rest of the democracy fundaments weren't being torn down in defense of it.
The IPRED directive intended to halt file sharing, as implemented in Sweden, perverts the concept of common carriers (it's not the PO's fault if you send people pot in envelopes), a fair trial (the civil trials are exempt from setting reasonable damages, they can seize your bank account, raid your house, make you the target of an investigation without telling you and you have to prove that you're not personally guilty) and reinvents the shame pole (you have to take out an ad in a newspaper of your own payment saying that you did something wrong). Some of these concepts date back to the Roman Empire. Is it really proportional to the crime?
There are more directives and motions like these, in other areas, and the Pirate Party is fighting them too, like supporting the repeal of a recent law enabling a defense authority, FRA, to tap every packet of Internet traffic that crosses the country borders in the interests of "preventing external threats", painted by a former Stasi employee as a tool they could only have dreamed of. Or why not by railing against the implementation of the EU Data Retention Directive, which would document every cell phone call or email. Don't confuse poor research and jumped conclusions with their actual, openly-discussed agenda.
But even where the focus is on file sharing, I don't think you'll agree after reading through the actual law that the measures are proportional, necessary or effective.
Something else: the summary mentions the "Hard Liquor Party". Although tiny (the data from the election agency lists where they appear specifically on write-in votes because their per-party ballot papers weren't available), they're a real political party, and they want to reduce the Swedish alcohol consumption by 50% to achieve many other beneficial side-effects, like decreases in domestic violence, poor performance in schools, heart failure and so on. While they didn't get my vote, I empathize with their politics.