Actually Azure does support Linux servers (SUSE and Ubuntu). It is NOT strictly Windows and NOT strictly Microsoft. In addition to generic Linux servers, they support platform-as-a-service applications written in Java, PHP, Python, and Node.JS. In other words, not just.NET. They support not just SQL Server databases, but also MySQL and various embedded database and no-SQL options. I believe they are also working on supporting automated build/deployment from Git repositories in addition to TFS.
I neither work for nor own shares of Microsoft. But I have used both Azure and Amazon services. You may or may not like Microsoft as a company (or even Azure as a platform), but you're simply spreading misinformation. Azure has come a LONG way in the past year or two, and in a good way that embraces both traditional Microsoft and open-source technologies. This choice is a VERY good thing.
Actually a number of their products have been going open-source in the last year or two, especially some of their web development frameworks such as ASP.NET MVC, Entity Framework, the Razor view engine, etc. I believe these are under an Apache 2.0 license.
Their Azure cloud platform also recently added "IaaS" support for installing Linux in persistent VMs. My guess is they might want to discuss this.
Well partly true, but the question was about a sysadmin job, not a software development job. Sysadmins probably would need to write small shell scripts or whatnot, but they probably aren't going to be designing and building major new pieces of software. Rather, they will be configuring, deploy, and administering software that has already been built. It's a different skill set. And even in the real of software development, 99% of the developers out there will not need to ever design a new language or a new OS.
With that being said, I've found that with a few notable exceptions, most of the good software developers I've worked with have degrees (although one of the best I've worked with doesn't). I will also say that almost all of the poor software developers I've worked with DID have degrees -- and some from supposedly top-tier schools. It matters a great deal where you get your degree from, not in terms of the name on the diploma but in terms of what is emphasized in the curriculum. Some colleges get this attitude about anything applied. People who come out of those colleges may have an advanced understanding of the theory of computation but tend to have a lousy understanding of object-oriented design, system architecture, usability evaluation, low-level systems design, etc. -- the things that matter in the "real world".
That's not to say that it isn't good to learn some theory too -- just that the VAST majority of students are better off understanding how to design and build real, useful software systems and keeping the pure theory to a reasonable minimum. Unless you're planning on doing graduate research in theoretical computer science, my suggestion is to get a degree, but to try to get a degree with a more applied (although not exclusively so) focus. For sys admins, a tech degree might be sufficient if you don't already have enough years of experience. For a software engineering role, you'll probably want to get at least a four year degree, or a master's if you want to do more advanced stuff.
With no degree of any kind, you can probably start in desktop support or a help desk, if you're okay with that.
That would be great! I do hope the open source community would create such a thing -- but it would have to be on par with Silverlight and/or Flash/Flex to make a difference. I don't count JavaFX since they're so far behind.
Has anyone actually created a Silverlight app?
on
Silverlight 2.0 Released
·
· Score: 4, Informative
Relative to Flash, Silverlight doesn't really bring any more or less to the table from a user's perspective. But as at least one other poster mentioned here, the real power is on the development side of things. Relative to ActionsScript on the Flash side of things, and relative to some weird HTML/CSS/JavaScript combination on the "legacy" side of things, Silverlight is the best, most advanced web development platform I have seen to date, hands down. Sure, there are libraries that help with JavaScript development...YUI, the GWT, etc. But those are slow...and let's face it, the GWT, however effective it might be, is still one big hack for a set of technologies that were never meant to host full-blown applications.
With Silverlight, you get a couple key things:
1) Clean division between UI design and implementation. Gone are the days when the UI designer hands over an HTML prototype to the programmer, and the programmer mangles that into a JSP page, PHP page, oor whatever else. In the old world, making changes to the UI design was a mess, unless those changes were limited to CSS. Now the UI designer and developer are both on equal ground -- either can easially import the other's work for updates.
2) You don't have to write your front-end in a crappy language -- or more specifically, in a crappy runtime. Despite all the love that dynamic languages are getting these days, if you look at it, JavaScript's lack of built in libraries, the cumbersome DOM access, and the awful runtime implementation in browers like IE make it a real pain. With Silverlight, a development shop can pick whatever language they see fit -- it could be JavaScript, it could be C#, or it could even be Python or Ruby. And they get the power of a subset of the.NET framework. There is a LOT of value here.
3) Good tooling. Having proper tools is of critical importance. You get Visual Studio OR Eclipse on the development side and Expression Blend on the UI design side. I don't know how Expression Blend stacks up against the Adobe products, but I do know that on the development side, Visual Studio is one of just 2-3 top of the line IDEs. I love hacking in emacs as much as the next guy, but any serious large-scale development shop is unlikely to be using emacs or vi or notepad. Having the same tool you use for your back-end development apply to your front-end development is a very, very good thing.
4) Technology that was meant for application UIs. Let's face it: HTML was meant as a document presenation language. Sure, it's been updated over the years and other technologies like CSS have greatly helped. But at its core, it's still not architected to really be an application development platform. And it will never be that, no matter how many bells and whistles you may add.
It's easy to dismiss Silverlight because it's a Microsoft product or whatever. My background is in C and Java, mainly on Linux and Solaris. But Silverlight impressed the hell out of me. So long as they maintain the cross-browser, cross-platform compatibility, I feel it's a perfectly valid choice for developers to make. Keep in mind that competition is a good thing. Firefox was the best thing that ever happened to IE; both browsers now motivate improvements in the other. The same applies between Flash and Silverlight. It will be interesting to see whether Silverlight sees more widespread adoption going forward.
No, someone from ITT probably wouldn't be able to handle it either. You missed my whole point: it's not whether something is high-level or low-level that maks it worthy of learning in a CS curriculum. It's whether it requires a level of problem solving and technical sophistication that one would only really get in that environment. In other words, learning how to use libraries from Java some "trained code monkey" could learn how to do. That's the equivalent of writing a pre-processor include in C. But there *ARE* significant technical challanges that require modes of thinking that you simply don't need in C. Of course, the opposite is true too.
Oh, and like it or not, unless you're talking theoretical research (e.g. computational complexity, AI algorithms, etc.), any applied CS ultimately is professional training. And you'd damn well better learn how to use an appropriate sampling of the tools at your disposal.
As others have pointed out, the languages themselves are terribly important. What's more important is that students understand memory managment and semaphores. And by that same token, that they understand OO design patterns and SOA architectures. Java is a tool, just like C is a tool. If students understand the concepts and know how to learn new languages, then in my book you're well-prepared. But in order to do that, they need to be exposed to both low-level and high-level languages.
I don't see why students can't learn both Java (or C#, etc.) and C. I first learned Java in my undergraduate days, then in the second year we learned C++. After that we were pretty much expected to learn whatever language we needed with minimal instruction. It's not like CS programs need to do only one or only the other.
High-Level != Non-Innovative
I don't know why some people think that something can't be innovative if it's high-level. I frankly don't care whether something's written in assembly or JavaScript. It it brings something new and useful to the table, it's innovative in my book.
Different Skillsets, Different Challanges
Constructing a low-level system utility and architecting a large enterprise web-based application are two fundamentally different types of problems. It's true that students need to understand memory management and low-level OS concepts. But quite frankly students who come out of Universities understanding only this type of development consistently demonstrate a complete inability to design an enterprise web application using OO design patterns, SOA, and reusable components. There are significant technical challanges involved in this type of application development. They're just not the same as when you're living in the low-level world of systems programming.
Ever heard of reuse?
I don't know whether this guy seriously believes that students shouldn't be leveraging libraries in their code, but I've got news: that's the way the world works. It's true you should be able to dive into the low-level code if there is a specific need to, but nobody's going to pay you to reinvent the wheel (anyone who insists on implementing their own sorting algorithms in the real-world is probably a fool.) Reuse is something software engineering strives for, so why should we be painting it out to be something evil?
Besides, where do you draw the line? I know some people in the supercomputing industry that feel C is "too high-level and bloated". They would like to see students spending most of their time in Fortran and assembly. So...do we expect students to write all their software in assembly? Should students be designing everything using sequential circuits and skip the software alltogether? My point is that what's considered "high-level" is very relative, and there's no good justification to sitting exclusively any any level or another. Part of being a good engineer is knowing how to select the right tool for the right job. Sometimes that's assembly, and sometimes that's Java. As long as you're proficient in multiple styles of programming, you should be able to handle most anything you need to.
What are you talking about? The notion of IE standards mode has been around for years, even back when it WAS the most "standards-compliant" browser out there (and even that term is iffy). Standards mode is not something the users have to enable; it's enabled by specifying a proper DOCTYPE in HTML pages; in other words, something web developers do to mark their page as being written according to standards, so it will be rendered according to standards.
And you can't honestly tell me that they don't have a valid point about different types of standards. There are de-facto standards, not everything some here at slashdot whine about is an actual true blue standard. It's just that every other major browser vendor might support it, which would make it de-facto. Look, there plenty of valid complaints about past IE versions. But let's give credit where credit is due; IE 8 is looking to bring that browser back up to the level where other browsers have been for some time now. Which, despite the delays in getting there, is still commendable.
*SPOILERS*
Well I know they've said that their plans for episode 3 are very ambitious, maybe even too much so. When you consider that at the very end of episode 2 they were just about to get on a helicoper...who knows? You may not be far from the truth.
I have to agree with MS on this one. A radical update to Javacript has the potential to break more than I would care to think about. Major web applications can take months to simply test and years to design and implement! Major platform changes of this type are an unacceptable risk in the enterprise setting. Now, I fully agree that JScript is a horrible and broken implementation of the ECMAScript standard, but let's face it: JScript's own problems aside, Javascript as a language is not acceptable given what people are trying to do with the web. It was meant to provide limited dynamic capabilities to mostly static information delivery. That was yesterday, now let's take a serious look at today. I'm sorry if I'm offending any scripting fanboys, but weak typing, the lack of threading, the lack on non-prototypical OO features, the lack of a serious class library (including real data scructures), etc. all get in the way of delivering truly powerful client/server apps.
As I view it, casual web browsing and using a large-scale web application are fundamentally two different things, and demand two different approaches to development. Let ECMAScript/JScript/etc. stick around; it's sufficient for small-scale or casual needs. But if we're really talking about delivering large-scale, complex applications over the web, Javascript costs countless hours of productivity, and does limit the potential for what web applications might be able to deliver to users.
I'm completely in favor of creating a new language to meet the needs of tomorrow's web applications, provided that Microsoft and open source vendors work together in an open and honest fashion. This will only become a reality if all parties cooperate and make it a true standard. But on principle, yeah, Microsoft has the right idea on this one. (In my dream world, I would love to be able to deliver bytecode via HTTP, execute it in a tightly controlled sandbox, but still use the DOM as the UI delivery mechanism, but somehow I doubt that'll happen!!)
It fails because that copy of XP is meant ONLY for testing IE 6 -- it's not a fully liscenced copy of Windows. There is a separate image available with IE 7 already.
My company decided to do that, but only for certain people who didn't need the computing power. Developers and graphic artists and people who did stuff like that kept their desktop PCs. I think we used some sort of blade servers, but I don't recall the brand. However, I do know that nearly everyone I've talked to who used them just hated them...there reports of unacceptable latencies, the inability to work when there was a network glitch, etc.
How does it run SQL server? I'm not saying it necessarily doesn't; rather I'm saying I don't know one way or the other. I'd be curious to see how this was the case. I'm pretty sure some of the WinFS technology made its way into SQL Server, but I didn't know it also went the other way around. I'm very interested to know more about this.
As far as the notion of an upgrade, you're absolutely right. As I said, I don't think most people will want to spend the money to upgrade; they're probably better served simply getting it when they get a new computer. But unless someone was buying an absolute low-end computer or someone is a member of an enterprise with standardized OS/applications, I do think it would be downright silly to go with XP over Vista. As I said, there are a number of incremental improvements that viewed together make Vista a significant and worthwhile upgrade, at least if you're faced with the prospect of having to purchase some version of Windows anyway.
In a sense that's true, but sticking with a Chevy is not an accurate analogy. You might buy a newer Chevy that has newer features like like maybe a CD changer or built in guidance system. This causes the buttons to be in slightly different places. You still have to learn to adapt, even if you stick with the Chevy brand.
Regarding RAM consumption, I never once claimed Microsoft has a perfect track record with stuff like that. But I'm telling you that with Vista, they did get that right, at least from everything I've seen. Regardless of what they might have screwed up in the past, in this case it does work, and quite well at that.
That's odd. I'm running Vista with Office 2003, and have never once seen any message like that. But then again for me neither was an OEM version. Maybe the computer manufacturer is displaying that message?
First, it sounds more like most of their complaints are not with Vista itself, but that Vista is different from XP. I guess I don't understand this. The point of an OS upgrade is that things change, hopefully for the better. And people here complain that not enough changed to justify an upgrade. Well it doesn't work both ways. Changes (in anything in life) do incur a learning curve, but the idea is that once you get used to the change, you're better off.
Secondly, you claim that Vista is a memory hog. Do you know why it's a "memory hog", as you put it? Because it pre-loads data you might need, based on historical usage patterns. Any good OS *should* be using as much RAM as possible. That way, it doesn't have to be loaded from disk upon request. If an app requests RAM, I guarantee Vista will flush out part of it's pre-cached data. So in other words, the RAM is still available to applications upon request. Point being, the high RAM usage is a good thing.
As far as being a CPU hog, I generally do agree with this one. I've noticed my CPU usage is generally higher than it was with XP. I think this is largely due to things like background file indexing, DreamScene, Aero, etc. But for all of these things, I've noticed that Vista is usually good about stopping those "nice but not necessary" background processes when other applications need the CPU time, when you go on batteries, etc. So it hasn't really been anything more than an annoyance for me, and the benefits I reap from things like lightning-fast search, in my mind outweigh the generally high CPU usage.
As far as the responsiveness, I guess I've been running it for a month or so now and I haven't had any problems. Initially it was a bit slower, but as time goes on I've noticed an improvement in response time. I'm guessing this is likely due to the adaptive/learning "Superfetch" memory manager (see above paragraph). In fact, I would even go as far as claiming that as of now, Vista is slightly more responsive than XP was, on this 1.5-year old laptop. For instance, even when I have a lot of stuff running in the background, Word takes all of 0.25 seconds to load from scratch. That never happened with XP.
As far as XP availability, I'm guessing that's more a function of companies like Dell or HP not wanting to sell XP. While Microsoft may have certain incentives for doing this, there are also real benefits to moving people to a new OS. The sooner XP is no longer sold, the sooner companies won't have to offer support for multiple OS versions. That sort of multi-OS support has a real cost associated with it, I wouldn't blame companies for trying to minimize it.
But even beyond that, why wouldn't Microsoft want to promote their new OS? Although I probably would not justify people paying for an upgrade (I got mine from MSDNAA), there's really no good reason not to get it on a new PC. At the user level, there aren't huge changes beyond maybe Aero. But under the hood there's quite a few things that are drastically improved (IPv6/whole new network stack, built in anti-spyware, UAC, a *far* cleaner user interface API, DirectX 10's hardware standardization, etc.) I look at Vista as a whole TON of minor, incremental updates that together make for a decent upgrade.
The thing is, the term "computer science" is so broad. People view it as being any one of the following four areas of study. I like to think of them as all coming under the umbrella of computer science.
1) The formal methods that study the mathematics of computability and computation. 2) The study of how computers themselves actually work -- the CPU, the OS, compilers, etc. 3) An engineering discipline -- software engineering, computer (hardware) engineering, etc. For instance, in the case of software, we're talking the analysis, design, and implementation. 4) A foundation upon which to study specific subfields, like AI or robotics, or data visualization, 3D graphics, etc.
Obviously there are common skills shared between all four. For instance, programming is a tool used for empirical verification of results in #1, it's the product of the work done in #2, it's an entry-level skill upon which much of #3 is based, and it's necessary for experimentation with #4. The problem, as I see it, is that too may schools focus too much on #1. I do think there is value in understanding complexity theory and things like that, but the reality is that for 90% of the jobs out there, those sorts of skills are of secondary importance to #3, and to soft skills like verbal/written communication, project management, etc. If you look at all the lists of the top growing jobs, software engineering is always near the top of the list. There is a need for computer scientists, particularly those focused on software engineering.
My school focused on #3 -- software engineering in particular. We had the algorithms, data structures, discrete structures, CPU organization, OS, etc. All the basics. But for the upper level classes, instead of making us take a year of complexity theory or something like that, we studied data modeling, object-oriented design patterns, technical communication, software development methodologies, etc. Sure, you could take your theory of computation or #4 topics as electives if you wanted, but it wasn't the core focus. And with a background like that, there were far more job offers out there than graduates. And when you started, you started way above the entry-level position.
So no, computer science is not going away. It's just that the emphasis needs to shift towards a more engineering-oriented approach. We'll always still need some folks who really understand the theory, who understand the details of compilers, and the CPU designers. But the vast majority of people instead need to be effective software engineers. And educational institutions need to realize that and alter the emphasis of their curriculums to accommodate that trend. Those that don't will simply become irrelevant.
I believe these types of thin-client office suites will never move beyond a novelty, at least with the current architecture of the web. Some random reasons why:
Privacy. Do you really want all your personal, private documents being stored on some remote server?
Reliability. Not only do you depend on your computer being up, but you also depend on the remote server being up and your network connection being up.
Mobility. While on one hand, a web-based application does offer greater mobility, it also requires an Internet connection. I can't count the number of times I've worked in a car or at some other location without connectivity.
Responsiveness. There will always be a latency involved that far exceeds that found on fat clients.
Capability. I'm sorry, but the whole web 2.0 phenomenon has pushed HTML, CSS, and JavaScript far beyond what they were intended for. As long as we're relying on these technologies, documents created with web applications will never be as capable of the expressiveness of a documents created with a fat client. Using applets or ActiveX or something like Flash would probably mitigate this.
Development. Thin clients are arguably easier to develop than fat clients. However, as soon as you introduce things like AJAX and complex scripting into the picture, things balloon out of control at an alarming rate. You spend most of your time fighting the basic request/response nature of the web. AJAX is really just one big hack to overcome this. AJAX is nice for adding bits of dynamic functionality to web sites, but it shouldn't be used for stuff like this. In fairness, I should note that better tool support and frameworks like the GWT and RAP will go a long way twoards addressing this.
Say it with me class, "you pick the right technology for the job". Thin clients have their place. Office suites is not one of them.
How is this news? The IE has been around for years and years. I remember using it to customize IE 5.5. It may have been around even earlier than that. And as to Microsoft somehow being upset, please look past the knee-jerk reaction and notice that the IE Blog, from Microsoft, actually praises the Google release, and links to their download page. This is what people are SUPPOSED to do with the IEAK. The article is really trying to make a big deal about something that's not...
I had a software engineering class set up exactly like that. We actually interviewd with the professor for the various roles you mention. Our customer was another department in the University that needed an application built. The owner was our professor, essentially.
You're fairly accurate in your prediction on how such a class would go. The project turned out to be way larger than the analysts (or the professor) thought it would be, and hence most of us ended up putting in 120 hour weeks on that class alone. For 3 credits. We used the Iconix ("RUP Lite") methodology. Part of why it went so badly was our own inexperience. That class completely destroyed my health, my social life, and my other classes. But in the process, I probably learned more about software development than a lot of CS majors will learn in their entire education. There's something to be said for gaining an understanding of politics and dealing with difficult people. That's more important than knowing how to quick sort, in my mind.
I disagree. It may be good to have two degree programs, but the department should be one and the same. It's a very good thing for software engineers to have an undestanding of those sorts of things. And things like CPU organization, discrete structures, etc. Many courses would be the same between the two degrees.
A class like that is absolutely essential. Any undergrad program which does not include at least one software engineering course is doing a disservice to its students. Such a course should include a study of development methodologies, requirements analysis, basic OO, user interface, and database schema design, source control system, basic project management, UML diagrams, etc.
I had a second software engineering course that also covered design patterns, unit testing, software architecture, and refactoring.
These two courses have put me is a far better position to be an effective software engineer than most CS grads. In large enterprise systems, the code most CS majors produce is crap -- it's poorly designed and poorly implemented. Understanding complexity theory or numerical analysis is a good thing, but in the real world, it's all secondary to understanding things like object-oriented design patterns. It's a shame more undergrad programs don't place a similar emphasis on practical software engineering.
True, RCP is a library component, which means some extra download size. But disk space is obnoxiously cheap, and anyone with broadband won't have problems downloading an RCP app. As far as the JRE, nearly all computers have one installed already.
The fact that you point to a help system or "intro" page as the notable features of RCP tell me you don't really know what you're talking about. RCP is an application framework, much in the same way Spring might be for Java-based web apps. Or Rails might be for Ruby-based web apps. Anything like an "intro page" is just a corollary and is totally irrelevant.
Regarding speed, one of the biggest advantages to RCP is the fact that it employs the SWT user interface library. The SWT uses JNI to make direct calls to the native operating system to draw widgets. Which is unlike Swing, which manually paints each and every widget. That's the point - SWT is fast -- just as fast as any native application UI library would be. As far as Java in general, it is of course slightly slower, but the more recent versions (5, 6) are almost as fast as native code. They are nowhere near as slow as Java was when it first came out. RCP is fast. Given modern computers, the performance hit you get from RCP is going to be trivial compared to whatever processing the application itself needs to do. So basically the whole performance argument isn't valid.
Traditionally Java has been better for web applications, and the Microsoft products for desktop apps. But that's changing, in no small part due to the Rich Client Platform from the Eclipse foundation -- a desktop application framework which puts Java in the arena in a way it never previously was. And on the Microsoft side,.NET (especially the more recent versions) have greatly improved Microsoft customers' position for web-based apps.
Really, you'll probably see either environment in smaller shops, or a mixed environment for larger organizations.
That's true, and it's unfortunate. But I think you may be confusing a programmer with a software engineer, or a computer scientist. They're all different. A programmer can definetly get away without having to know too much. But programming is only part of the picture. A computer scientist should understand exactly why things work the way they do -- this includes all the concepts you mentioned. Like big/little endian, algorithm design, computational complexity, etc.
But it doesn't end there. If you're a software engineer -- as in you have to write software applications for a living -- you also need to understand application architecture, object-oriented design, unit testing, user interface design, business analysis, etc. Programming is only one part of software engineering, and my experience is that people who only understand things like compilers, theory of computation, and CPU organization in reality tend to be pretty poor software engineers.
As far as the concept of program-archaeology, I don't think it will get to that point. As long as there are custom-written applications, there will be a need to write new code. With that being said, it will also be important to reuse as much code as possible. I've got news -- an effective programmer (even one who understands the "why") -- will always reuse existing code. Yes, this means not writing vector normalization functions by hand. There's no reason to. It's already been done. If you do understand how normalization works, that's even better. But it's not strictly neccesary for many things. If you're being paid to code, you're sure as hell not being paid to reinvent the wheel. I do agree that some people get lost when they're presented with a new language or API. Learning and adaptinve to new situations and learning how to find those "missing functions" is an important skill -- in my opinion, more important than understanding things like the difference between big and little endian.
Slashdot Mirror
Actually Azure does support Linux servers (SUSE and Ubuntu). It is NOT strictly Windows and NOT strictly Microsoft. In addition to generic Linux servers, they support platform-as-a-service applications written in Java, PHP, Python, and Node.JS. In other words, not just .NET. They support not just SQL Server databases, but also MySQL and various embedded database and no-SQL options. I believe they are also working on supporting automated build/deployment from Git repositories in addition to TFS.
I neither work for nor own shares of Microsoft. But I have used both Azure and Amazon services. You may or may not like Microsoft as a company (or even Azure as a platform), but you're simply spreading misinformation. Azure has come a LONG way in the past year or two, and in a good way that embraces both traditional Microsoft and open-source technologies. This choice is a VERY good thing.
Actually a number of their products have been going open-source in the last year or two, especially some of their web development frameworks such as ASP.NET MVC, Entity Framework, the Razor view engine, etc. I believe these are under an Apache 2.0 license.
Their Azure cloud platform also recently added "IaaS" support for installing Linux in persistent VMs. My guess is they might want to discuss this.
Well partly true, but the question was about a sysadmin job, not a software development job. Sysadmins probably would need to write small shell scripts or whatnot, but they probably aren't going to be designing and building major new pieces of software. Rather, they will be configuring, deploy, and administering software that has already been built. It's a different skill set. And even in the real of software development, 99% of the developers out there will not need to ever design a new language or a new OS.
With that being said, I've found that with a few notable exceptions, most of the good software developers I've worked with have degrees (although one of the best I've worked with doesn't). I will also say that almost all of the poor software developers I've worked with DID have degrees -- and some from supposedly top-tier schools. It matters a great deal where you get your degree from, not in terms of the name on the diploma but in terms of what is emphasized in the curriculum. Some colleges get this attitude about anything applied. People who come out of those colleges may have an advanced understanding of the theory of computation but tend to have a lousy understanding of object-oriented design, system architecture, usability evaluation, low-level systems design, etc. -- the things that matter in the "real world".
That's not to say that it isn't good to learn some theory too -- just that the VAST majority of students are better off understanding how to design and build real, useful software systems and keeping the pure theory to a reasonable minimum. Unless you're planning on doing graduate research in theoretical computer science, my suggestion is to get a degree, but to try to get a degree with a more applied (although not exclusively so) focus. For sys admins, a tech degree might be sufficient if you don't already have enough years of experience. For a software engineering role, you'll probably want to get at least a four year degree, or a master's if you want to do more advanced stuff.
With no degree of any kind, you can probably start in desktop support or a help desk, if you're okay with that.
That would be great! I do hope the open source community would create such a thing -- but it would have to be on par with Silverlight and/or Flash/Flex to make a difference. I don't count JavaFX since they're so far behind.
Relative to Flash, Silverlight doesn't really bring any more or less to the table from a user's perspective. But as at least one other poster mentioned here, the real power is on the development side of things. Relative to ActionsScript on the Flash side of things, and relative to some weird HTML/CSS/JavaScript combination on the "legacy" side of things, Silverlight is the best, most advanced web development platform I have seen to date, hands down. Sure, there are libraries that help with JavaScript development...YUI, the GWT, etc. But those are slow...and let's face it, the GWT, however effective it might be, is still one big hack for a set of technologies that were never meant to host full-blown applications.
.NET framework. There is a LOT of value here.
With Silverlight, you get a couple key things:
1) Clean division between UI design and implementation. Gone are the days when the UI designer hands over an HTML prototype to the programmer, and the programmer mangles that into a JSP page, PHP page, oor whatever else. In the old world, making changes to the UI design was a mess, unless those changes were limited to CSS. Now the UI designer and developer are both on equal ground -- either can easially import the other's work for updates.
2) You don't have to write your front-end in a crappy language -- or more specifically, in a crappy runtime. Despite all the love that dynamic languages are getting these days, if you look at it, JavaScript's lack of built in libraries, the cumbersome DOM access, and the awful runtime implementation in browers like IE make it a real pain. With Silverlight, a development shop can pick whatever language they see fit -- it could be JavaScript, it could be C#, or it could even be Python or Ruby. And they get the power of a subset of the
3) Good tooling. Having proper tools is of critical importance. You get Visual Studio OR Eclipse on the development side and Expression Blend on the UI design side. I don't know how Expression Blend stacks up against the Adobe products, but I do know that on the development side, Visual Studio is one of just 2-3 top of the line IDEs. I love hacking in emacs as much as the next guy, but any serious large-scale development shop is unlikely to be using emacs or vi or notepad. Having the same tool you use for your back-end development apply to your front-end development is a very, very good thing.
4) Technology that was meant for application UIs. Let's face it: HTML was meant as a document presenation language. Sure, it's been updated over the years and other technologies like CSS have greatly helped. But at its core, it's still not architected to really be an application development platform. And it will never be that, no matter how many bells and whistles you may add.
It's easy to dismiss Silverlight because it's a Microsoft product or whatever. My background is in C and Java, mainly on Linux and Solaris. But Silverlight impressed the hell out of me. So long as they maintain the cross-browser, cross-platform compatibility, I feel it's a perfectly valid choice for developers to make. Keep in mind that competition is a good thing. Firefox was the best thing that ever happened to IE; both browsers now motivate improvements in the other. The same applies between Flash and Silverlight. It will be interesting to see whether Silverlight sees more widespread adoption going forward.
No, someone from ITT probably wouldn't be able to handle it either. You missed my whole point: it's not whether something is high-level or low-level that maks it worthy of learning in a CS curriculum. It's whether it requires a level of problem solving and technical sophistication that one would only really get in that environment. In other words, learning how to use libraries from Java some "trained code monkey" could learn how to do. That's the equivalent of writing a pre-processor include in C. But there *ARE* significant technical challanges that require modes of thinking that you simply don't need in C. Of course, the opposite is true too.
Oh, and like it or not, unless you're talking theoretical research (e.g. computational complexity, AI algorithms, etc.), any applied CS ultimately is professional training. And you'd damn well better learn how to use an appropriate sampling of the tools at your disposal.
As others have pointed out, the languages themselves are terribly important. What's more important is that students understand memory managment and semaphores. And by that same token, that they understand OO design patterns and SOA architectures. Java is a tool, just like C is a tool. If students understand the concepts and know how to learn new languages, then in my book you're well-prepared. But in order to do that, they need to be exposed to both low-level and high-level languages.
I don't see why students can't learn both Java (or C#, etc.) and C. I first learned Java in my undergraduate days, then in the second year we learned C++. After that we were pretty much expected to learn whatever language we needed with minimal instruction. It's not like CS programs need to do only one or only the other.
High-Level != Non-Innovative
I don't know why some people think that something can't be innovative if it's high-level. I frankly don't care whether something's written in assembly or JavaScript. It it brings something new and useful to the table, it's innovative in my book.
Different Skillsets, Different Challanges
Constructing a low-level system utility and architecting a large enterprise web-based application are two fundamentally different types of problems. It's true that students need to understand memory management and low-level OS concepts. But quite frankly students who come out of Universities understanding only this type of development consistently demonstrate a complete inability to design an enterprise web application using OO design patterns, SOA, and reusable components. There are significant technical challanges involved in this type of application development. They're just not the same as when you're living in the low-level world of systems programming.
Ever heard of reuse?
I don't know whether this guy seriously believes that students shouldn't be leveraging libraries in their code, but I've got news: that's the way the world works. It's true you should be able to dive into the low-level code if there is a specific need to, but nobody's going to pay you to reinvent the wheel (anyone who insists on implementing their own sorting algorithms in the real-world is probably a fool.) Reuse is something software engineering strives for, so why should we be painting it out to be something evil?
Besides, where do you draw the line? I know some people in the supercomputing industry that feel C is "too high-level and bloated". They would like to see students spending most of their time in Fortran and assembly. So...do we expect students to write all their software in assembly? Should students be designing everything using sequential circuits and skip the software alltogether? My point is that what's considered "high-level" is very relative, and there's no good justification to sitting exclusively any any level or another. Part of being a good engineer is knowing how to select the right tool for the right job. Sometimes that's assembly, and sometimes that's Java. As long as you're proficient in multiple styles of programming, you should be able to handle most anything you need to.
What are you talking about? The notion of IE standards mode has been around for years, even back when it WAS the most "standards-compliant" browser out there (and even that term is iffy). Standards mode is not something the users have to enable; it's enabled by specifying a proper DOCTYPE in HTML pages; in other words, something web developers do to mark their page as being written according to standards, so it will be rendered according to standards.
And you can't honestly tell me that they don't have a valid point about different types of standards. There are de-facto standards, not everything some here at slashdot whine about is an actual true blue standard. It's just that every other major browser vendor might support it, which would make it de-facto. Look, there plenty of valid complaints about past IE versions. But let's give credit where credit is due; IE 8 is looking to bring that browser back up to the level where other browsers have been for some time now. Which, despite the delays in getting there, is still commendable.
*SPOILERS* Well I know they've said that their plans for episode 3 are very ambitious, maybe even too much so. When you consider that at the very end of episode 2 they were just about to get on a helicoper...who knows? You may not be far from the truth.
I have to agree with MS on this one. A radical update to Javacript has the potential to break more than I would care to think about. Major web applications can take months to simply test and years to design and implement! Major platform changes of this type are an unacceptable risk in the enterprise setting. Now, I fully agree that JScript is a horrible and broken implementation of the ECMAScript standard, but let's face it: JScript's own problems aside, Javascript as a language is not acceptable given what people are trying to do with the web. It was meant to provide limited dynamic capabilities to mostly static information delivery. That was yesterday, now let's take a serious look at today. I'm sorry if I'm offending any scripting fanboys, but weak typing, the lack of threading, the lack on non-prototypical OO features, the lack of a serious class library (including real data scructures), etc. all get in the way of delivering truly powerful client/server apps.
As I view it, casual web browsing and using a large-scale web application are fundamentally two different things, and demand two different approaches to development. Let ECMAScript/JScript/etc. stick around; it's sufficient for small-scale or casual needs. But if we're really talking about delivering large-scale, complex applications over the web, Javascript costs countless hours of productivity, and does limit the potential for what web applications might be able to deliver to users.
I'm completely in favor of creating a new language to meet the needs of tomorrow's web applications, provided that Microsoft and open source vendors work together in an open and honest fashion. This will only become a reality if all parties cooperate and make it a true standard. But on principle, yeah, Microsoft has the right idea on this one. (In my dream world, I would love to be able to deliver bytecode via HTTP, execute it in a tightly controlled sandbox, but still use the DOM as the UI delivery mechanism, but somehow I doubt that'll happen!!)
It fails because that copy of XP is meant ONLY for testing IE 6 -- it's not a fully liscenced copy of Windows. There is a separate image available with IE 7 already.
My company decided to do that, but only for certain people who didn't need the computing power. Developers and graphic artists and people who did stuff like that kept their desktop PCs. I think we used some sort of blade servers, but I don't recall the brand. However, I do know that nearly everyone I've talked to who used them just hated them...there reports of unacceptable latencies, the inability to work when there was a network glitch, etc.
How does it run SQL server? I'm not saying it necessarily doesn't; rather I'm saying I don't know one way or the other. I'd be curious to see how this was the case. I'm pretty sure some of the WinFS technology made its way into SQL Server, but I didn't know it also went the other way around. I'm very interested to know more about this.
As far as the notion of an upgrade, you're absolutely right. As I said, I don't think most people will want to spend the money to upgrade; they're probably better served simply getting it when they get a new computer. But unless someone was buying an absolute low-end computer or someone is a member of an enterprise with standardized OS/applications, I do think it would be downright silly to go with XP over Vista. As I said, there are a number of incremental improvements that viewed together make Vista a significant and worthwhile upgrade, at least if you're faced with the prospect of having to purchase some version of Windows anyway.
In a sense that's true, but sticking with a Chevy is not an accurate analogy. You might buy a newer Chevy that has newer features like like maybe a CD changer or built in guidance system. This causes the buttons to be in slightly different places. You still have to learn to adapt, even if you stick with the Chevy brand.
Regarding RAM consumption, I never once claimed Microsoft has a perfect track record with stuff like that. But I'm telling you that with Vista, they did get that right, at least from everything I've seen. Regardless of what they might have screwed up in the past, in this case it does work, and quite well at that.
That's odd. I'm running Vista with Office 2003, and have never once seen any message like that. But then again for me neither was an OEM version. Maybe the computer manufacturer is displaying that message?
First, it sounds more like most of their complaints are not with Vista itself, but that Vista is different from XP. I guess I don't understand this. The point of an OS upgrade is that things change, hopefully for the better. And people here complain that not enough changed to justify an upgrade. Well it doesn't work both ways. Changes (in anything in life) do incur a learning curve, but the idea is that once you get used to the change, you're better off.
Secondly, you claim that Vista is a memory hog. Do you know why it's a "memory hog", as you put it? Because it pre-loads data you might need, based on historical usage patterns. Any good OS *should* be using as much RAM as possible. That way, it doesn't have to be loaded from disk upon request. If an app requests RAM, I guarantee Vista will flush out part of it's pre-cached data. So in other words, the RAM is still available to applications upon request. Point being, the high RAM usage is a good thing.
As far as being a CPU hog, I generally do agree with this one. I've noticed my CPU usage is generally higher than it was with XP. I think this is largely due to things like background file indexing, DreamScene, Aero, etc. But for all of these things, I've noticed that Vista is usually good about stopping those "nice but not necessary" background processes when other applications need the CPU time, when you go on batteries, etc. So it hasn't really been anything more than an annoyance for me, and the benefits I reap from things like lightning-fast search, in my mind outweigh the generally high CPU usage.
As far as the responsiveness, I guess I've been running it for a month or so now and I haven't had any problems. Initially it was a bit slower, but as time goes on I've noticed an improvement in response time. I'm guessing this is likely due to the adaptive/learning "Superfetch" memory manager (see above paragraph). In fact, I would even go as far as claiming that as of now, Vista is slightly more responsive than XP was, on this 1.5-year old laptop. For instance, even when I have a lot of stuff running in the background, Word takes all of 0.25 seconds to load from scratch. That never happened with XP.
As far as XP availability, I'm guessing that's more a function of companies like Dell or HP not wanting to sell XP. While Microsoft may have certain incentives for doing this, there are also real benefits to moving people to a new OS. The sooner XP is no longer sold, the sooner companies won't have to offer support for multiple OS versions. That sort of multi-OS support has a real cost associated with it, I wouldn't blame companies for trying to minimize it.
But even beyond that, why wouldn't Microsoft want to promote their new OS? Although I probably would not justify people paying for an upgrade (I got mine from MSDNAA), there's really no good reason not to get it on a new PC. At the user level, there aren't huge changes beyond maybe Aero. But under the hood there's quite a few things that are drastically improved (IPv6/whole new network stack, built in anti-spyware, UAC, a *far* cleaner user interface API, DirectX 10's hardware standardization, etc.) I look at Vista as a whole TON of minor, incremental updates that together make for a decent upgrade.
The thing is, the term "computer science" is so broad. People view it as being any one of the following four areas of study. I like to think of them as all coming under the umbrella of computer science.
1) The formal methods that study the mathematics of computability and computation.
2) The study of how computers themselves actually work -- the CPU, the OS, compilers, etc.
3) An engineering discipline -- software engineering, computer (hardware) engineering, etc. For instance, in the case of software, we're talking the analysis, design, and implementation.
4) A foundation upon which to study specific subfields, like AI or robotics, or data visualization, 3D graphics, etc.
Obviously there are common skills shared between all four. For instance, programming is a tool used for empirical verification of results in #1, it's the product of the work done in #2, it's an entry-level skill upon which much of #3 is based, and it's necessary for experimentation with #4. The problem, as I see it, is that too may schools focus too much on #1. I do think there is value in understanding complexity theory and things like that, but the reality is that for 90% of the jobs out there, those sorts of skills are of secondary importance to #3, and to soft skills like verbal/written communication, project management, etc. If you look at all the lists of the top growing jobs, software engineering is always near the top of the list. There is a need for computer scientists, particularly those focused on software engineering.
My school focused on #3 -- software engineering in particular. We had the algorithms, data structures, discrete structures, CPU organization, OS, etc. All the basics. But for the upper level classes, instead of making us take a year of complexity theory or something like that, we studied data modeling, object-oriented design patterns, technical communication, software development methodologies, etc. Sure, you could take your theory of computation or #4 topics as electives if you wanted, but it wasn't the core focus. And with a background like that, there were far more job offers out there than graduates. And when you started, you started way above the entry-level position.
So no, computer science is not going away. It's just that the emphasis needs to shift towards a more engineering-oriented approach. We'll always still need some folks who really understand the theory, who understand the details of compilers, and the CPU designers. But the vast majority of people instead need to be effective software engineers. And educational institutions need to realize that and alter the emphasis of their curriculums to accommodate that trend. Those that don't will simply become irrelevant.
Say it with me class, "you pick the right technology for the job". Thin clients have their place. Office suites is not one of them.
How is this news? The IE has been around for years and years. I remember using it to customize IE 5.5. It may have been around even earlier than that. And as to Microsoft somehow being upset, please look past the knee-jerk reaction and notice that the IE Blog, from Microsoft, actually praises the Google release, and links to their download page. This is what people are SUPPOSED to do with the IEAK. The article is really trying to make a big deal about something that's not...
I had a software engineering class set up exactly like that. We actually interviewd with the professor for the various roles you mention. Our customer was another department in the University that needed an application built. The owner was our professor, essentially. You're fairly accurate in your prediction on how such a class would go. The project turned out to be way larger than the analysts (or the professor) thought it would be, and hence most of us ended up putting in 120 hour weeks on that class alone. For 3 credits. We used the Iconix ("RUP Lite") methodology. Part of why it went so badly was our own inexperience. That class completely destroyed my health, my social life, and my other classes. But in the process, I probably learned more about software development than a lot of CS majors will learn in their entire education. There's something to be said for gaining an understanding of politics and dealing with difficult people. That's more important than knowing how to quick sort, in my mind.
I disagree. It may be good to have two degree programs, but the department should be one and the same. It's a very good thing for software engineers to have an undestanding of those sorts of things. And things like CPU organization, discrete structures, etc. Many courses would be the same between the two degrees.
A class like that is absolutely essential. Any undergrad program which does not include at least one software engineering course is doing a disservice to its students. Such a course should include a study of development methodologies, requirements analysis, basic OO, user interface, and database schema design, source control system, basic project management, UML diagrams, etc.
I had a second software engineering course that also covered design patterns, unit testing, software architecture, and refactoring.
These two courses have put me is a far better position to be an effective software engineer than most CS grads. In large enterprise systems, the code most CS majors produce is crap -- it's poorly designed and poorly implemented. Understanding complexity theory or numerical analysis is a good thing, but in the real world, it's all secondary to understanding things like object-oriented design patterns. It's a shame more undergrad programs don't place a similar emphasis on practical software engineering.
True, RCP is a library component, which means some extra download size. But disk space is obnoxiously cheap, and anyone with broadband won't have problems downloading an RCP app. As far as the JRE, nearly all computers have one installed already.
The fact that you point to a help system or "intro" page as the notable features of RCP tell me you don't really know what you're talking about. RCP is an application framework, much in the same way Spring might be for Java-based web apps. Or Rails might be for Ruby-based web apps. Anything like an "intro page" is just a corollary and is totally irrelevant.
Regarding speed, one of the biggest advantages to RCP is the fact that it employs the SWT user interface library. The SWT uses JNI to make direct calls to the native operating system to draw widgets. Which is unlike Swing, which manually paints each and every widget. That's the point - SWT is fast -- just as fast as any native application UI library would be. As far as Java in general, it is of course slightly slower, but the more recent versions (5, 6) are almost as fast as native code. They are nowhere near as slow as Java was when it first came out. RCP is fast. Given modern computers, the performance hit you get from RCP is going to be trivial compared to whatever processing the application itself needs to do. So basically the whole performance argument isn't valid.
Traditionally Java has been better for web applications, and the Microsoft products for desktop apps. But that's changing, in no small part due to the Rich Client Platform from the Eclipse foundation -- a desktop application framework which puts Java in the arena in a way it never previously was. And on the Microsoft side, .NET (especially the more recent versions) have greatly improved Microsoft customers' position for web-based apps.
Really, you'll probably see either environment in smaller shops, or a mixed environment for larger organizations.
That's true, and it's unfortunate. But I think you may be confusing a programmer with a software engineer, or a computer scientist. They're all different. A programmer can definetly get away without having to know too much. But programming is only part of the picture. A computer scientist should understand exactly why things work the way they do -- this includes all the concepts you mentioned. Like big/little endian, algorithm design, computational complexity, etc.
But it doesn't end there. If you're a software engineer -- as in you have to write software applications for a living -- you also need to understand application architecture, object-oriented design, unit testing, user interface design, business analysis, etc. Programming is only one part of software engineering, and my experience is that people who only understand things like compilers, theory of computation, and CPU organization in reality tend to be pretty poor software engineers.
As far as the concept of program-archaeology, I don't think it will get to that point. As long as there are custom-written applications, there will be a need to write new code. With that being said, it will also be important to reuse as much code as possible. I've got news -- an effective programmer (even one who understands the "why") -- will always reuse existing code. Yes, this means not writing vector normalization functions by hand. There's no reason to. It's already been done. If you do understand how normalization works, that's even better. But it's not strictly neccesary for many things. If you're being paid to code, you're sure as hell not being paid to reinvent the wheel. I do agree that some people get lost when they're presented with a new language or API. Learning and adaptinve to new situations and learning how to find those "missing functions" is an important skill -- in my opinion, more important than understanding things like the difference between big and little endian.