Lol, true, but in the spirit of altruism - I hope today's Comp Sci grads are being forced to actual write software not just implement problem sets. There's so much they could learn from the full life-cycle at University.

We had courses on declarative languages, another on imperative languages, and special topics courses on specific languages and topics that were hot at the time (Java, OpenGL.) Some classes taught using Lisp, the majority using C, one was all assembler, intro courses were Pascal. Basically we learned that the language itself isn't important, what that language offers you (the benefits and limitations) is...

Things have gotten a little better in the past few years, but for a while there in the early aughts you couldn't find a recent graduate who knew anything other than Java. The were helpless without libraries - LOL.

...they point out to the students all along the way that they should learn other languages, toolsets, and operating systems if they want to be useful when they graduate/drop out.

Subjectively I would recommend they start with C specifically because you can hang yourself but it has few ropes to do so than C++, and then different languages for different aspects of Computer Science after that. There's virtually nothing in an undergraduate Comp Sci syllabus that should prevent you from learning a new language for your course if you've learned the fundamentals of how these languages work.

You're not going to be making use of exotic features of the languages in question unless the purpose is to use them.

Let's see how the python thing works out, it'll be nice to see kids coming out of school insisting they're senior software engineers for a different reason other than "I used Java for 4 years... at school..." Lol.

Good luck :)

It always depends upon the circumstances.

There are times when being a great programmer could be the most important thing, but except in one man/woman operations this is very rarely the case.

It's overlooked because there's a romanticism (sad and geeky though it is) about wondrous programmers being able to leap tall feature lists with a single bound...

Not at all. This isn't some elitist "I'm not a programmer" kind of thing. I am a programmer, but that ability is a subset of my abilities as a software engineer.

Programming is the ability to instruct a computer to perform actions.
A programmer is someone who has this skill.

Software engineering is a superset of programming. It includes the abilities of a programmers, plus the skills, the ethos, and the discipline for all the other aspects of building software that are important. The discipline is the most difficult part (at least for me.)

The simplicity of those differences can be seen in the drudgery of commenting your code where appropriate (or, if you know that junior developers will be working in the codebase, documenting it thoroughly), and the complexity of those differences can be in recognizing that the architecture of your solution provides for 3rd party integration opportunities that may be of enormous value to your employer and yet require more work on your behalf because abstraction can also be drudgery.

This doesn't mean that there aren't people out there who consider themselves programmers, not software engineers, that don't have these skills - it means that that they are what would be technically considered a software engineer.

You can pick up a book on learning JavaScript in 24 hours and start programming and even refer to yourself as a programmer if you land a job doing so, but calling yourself a software engineer at that point is ridiculous. Heck, quite a few CS grads don't even appear to be able to call themselves programmers (they do so little of it in the course of their studies generally.)

An analogy, which in my obviously subjective opinion, describes this relationship would be a mechanic and a mechanical engineer. That is a rougher comparison than the differences between MOST programmers and software engineers, but it conveys the basis of what I mean.

You are clearly demonstrating your lack of understanding about how to make software. You seem to think that software engineering is about "chart bubbles" and "design documents." It isn't at all. That's like saying that being an excellent race car driver is about how nice your car looks. It also isn't about how well you can drive a GoKart or a Formula 4 car, it's about your ability to drive anything necessary to accomplish your goals, your ability to make decisions, to mitigate risks, et cetera.

Talented programmers are sometimes good software engineers.
Talented software engineers are often good programmers.

You not only display your lack of understanding what software engineering is, but here you demonstrate your lack of realization that there are more independent software vendors in the world than just cash strapped startups who have to hack together whatever they can in order to begin generating revenue.

Amazing. You really don't understand that software engineering is the discipline of creating software properly. You seem to conflate it with architecture design documents and waterfall planning.

Software engineering is critical for any project of ANY size.

It is about decision making, risk mitigation, and proper use of resources.

People who think the way you are exhibiting here are the reason with why so much software is just garbage when it doesn't have to be.

...but I would argue that software engineering is a far more important a skill than programming.

Which thing is ultimately more valuable, the ability to write JavaScript (or C++, or Objective-C, or whatever) better than anyone else, or, the ability to architecturally scale a big data solution along swim lanes or using an AKF cube (or properly design a secure inter-process communication system, or whatever)?

I'm not trying to demean raw programming ability, because that's always a valuable skill, the problem is that people seem to venerate it above what I believe it more important to the creation of good software.

Anywho...

Would you care to explain any of your reasons why? It seems to be vastly superior for client side work in comparison to everything else right now. I wouldn't use it on the backend (that's still C++ territory in my opinion), but it and/or Java work well on the web services side of the backend.

Writing a bytecode platform is exactly what using C# would do in any case (I guess I should have been clearer.) I don't care if the actual language on top is exactly C#, or something else, just let it compile to a bytecode platform that takes all the best of Java, C#, and other THICK CLIENT application languages because the state of the world today is that people are trying to write thick client applications in the web browser using languages never intended to be used in such a fashion.

This, a thousand time this.

Why don't browser makers get together and throw out the entire existing paradigm of horrific compromises and agree on completely fresh start with both language and UI framework.

Throw out HTML, throw out CSS, throw out JavaScript. Take the best *ideas* from them all, use C# (nothing to do with Microsoft though) and create a common framework on all platforms embracing those *ideas* and use OpenGL as the composition engine.

Reduced stimulus is EXACTLY classic sensory deprivation.

Maybe you're confusing it with total sensory deprivation.

Remove external stimuli with a static environment, and leave a single available stimulus, guess what's going to happen...

Sensory deprivation experiments, partial or full, have been going on for decades. How is this 'news' to the scientific community?

Weird, I only used it for C++ from 1.5 until VS 2010. The only time I had the problems you're describing are when the intellisense files were being invalidated because people were storing them (*.ncb) in source control and this was confusing my local VC++ setup.

I'm pretty sure you could turn off intellisense in 2003 and 2005 (don't recall with 2008 onwards though.)

As a long time VisualStudio user I find your problems to be rather 'bizarre' to say the least. I use many IDEs on a day to day basis from XCode, Eclipse, MonoDevelop, Emacs, KDevelop (only for one old project), and VisualStudio 2008, 2010, and 2012. It depends upon what platforms I'm building for.

I have a rather large Visual Studio solution that contains more than 30 projects including web services, DLLs, controls, assemblies, client applications, and COM/DCOM objects, and it takes about 5 seconds to startup and be ready to work when I load that solution.

I also don't run into the incremental build issues that you seem to experience. I've been building huge projects in VisualStudio for more than a decade and never experience the problems you are reporting except when somebody was hosing up source control and VisualStudio though files where changing all the time.

That being said, XCode is a really nice environment as well.