Doubt it. Its still a bit different... since its an all or nothing, there's not flags, like there are in CPUs, either... So for that to happen, they'd have to get non-compliant drivers go by microsoft's certification program, fool them, then somehow not crash when direct x calls functions the GPU doesn't have...
The worse they can do I think, is pull an Nvidia like the Geforce FX: officialy, and technically support something, but have a totally horrible implementation.
Actualy, DX10 is not like that btw. There's no compatibility "bits" or whatsnot. With DX10, its an all or nothing: a card cannot claim DX10 compatibility if it doesn't support the entire spec. Sure, different cards can be slower on certain features than other, but thats it, which is quite very different from previous implementation.
That always cracks me up when people point out concerns over kids having access to this kind of material, then give, as an example, a (most likely) post puberty teenager as an example.
Aside the occasional retard who goes and meet total strangers offering candies and end up getting raped in the process, whats the worse that can happen to a 12 years old having access to that kind of content, may I know? I was watching hardcore porn when I was 8, and, ironically, I am now whats most likely considered a very "straight", successful individual...
Are there really people who are severly negatively affected by this?
Im not american either, and from speaking with my fiancee (who is), it seems slightly different there, but aside the occasional tutored booksmart top of the class geek, virtually everyone I've seen (including myself, with tons of trophees and prizes to show for it) who were top dogs in schools, didn't even lift a finger for it. They obviouslly avoided totally stupid acts like not showing up for a final, but aside that? I think from the time I finished elementary to graduating from college, with a 90-97% average among all my classes, Ive studied... a couple douzan hours total?
Like with economics, the "middle class" in school is the one that tend to work the hardest. The bottom and the top don't work all that hard (in general). So its far from "excessive willingness to engage in the daycare system"
Again, thats extremely relative... being able to fix stuff from the source is quite the idealogy. Not all Open Source projects are Apache-quality.
If you were using PostgreSQL a few years back (the latest version ain't so bad, so it wouldn't be a good example), and the project went under, good freagin luck making any sense of the source. Even in its latest version, it would take several thousand dollars to get anything done with the source: potentially more expensive than starting back from scratch.
On top of that, just about any serious license contract has a clause where if shit hits the fan, you get the source. If you're big enough, you can even get Windows' freagin sources!
Simply put, most softwares that you'd be worried to go under are multi-million lines of code softwares. If they're not popular projects, getting someone to go through the code would take weeks or months. If they ARE popular projects, the day the project goes under, any developer experienced with the project, willing to get anything done with it, will charge a pretty penny once they're called by everyone else.
And well, now with the advance of Java and.NET, unless the sources are specifically obfuscated, you can just decompile them if you need to know the inner working...
Thus my point remains: Yes, the fact that you have the source if something happens, IS an advantage of open source. A significant one. It IS, however, vastly overrated.
You mean, they only allow non-free (as in beer) and non-viral license (as in GPL...not using "viral" license as a bad term here, but simply to denote a license that applies to derived work) based companies to enter the market. A company that actually makes cash using open source softwares that don't force you to open connected modules, probably could use them just fine. Not very different from certain commercial Linux distros offering commercial closed codecs, etc.
On the desktop, Microsoft's biggest competitor is a closed source company (Apple). On the server, its not even Linux directly, but ISVs that use open source: in those case, using closed APIs is rarely an issue.
There's really no problem allowing competitors to enter the market: its just not "everything" open source advocates wants. Well, nothing's perfect in this world, have to live with it, and I wouldn't be surprised if even the EU commission would realise that. Hell, at this point, Microsoft can't even attribute a lot of its market to its Monopoly, but only to brand loyalty and, to some extent, to some of its products actually being good (I know its not the norm...yet...but I've worked for quite a couple of companies in the last few years, most being windows centric, and none of them were actually locked in, aside for minimal Office file format need, and we're talking companies of all sides).
The work the EU commission is doing is good. Microsoft wouldn't have started making some kind of effort without being forced to, I'll admit. But being blinded by our own little wishes, and getting anti-thrust laws to be respected, is two things, EVEN in Europe.
Whats totally ironic, is that while you're 100% right (minus the part where if you have must have apps not available on Linux, you're a bit screwed), Microsoft is becoming more attractive on the server side, and, as you pointed out, less on the desktop. Totally upside down.
Things like IIS (yes, IIS, I said it), especially IIS7 once its available as a real server, along with ASP.NET, are very attractive. SQL Server's business intelligence platform have amazing values for the cost, especially when you count that its free for small installs, and that for larger ones the cost is insignificant compared to equivalent alternatives (and superior alternatives are several times the cost in many cases).
While I don't think I'd have an issue switching to Linux as a desktop platform, it would be a cold day in hell before I move it away from my servers and development machines. Which is, a gain, totally ironic, considering Microsoft's track record on the server side. Hell froze over.
This is about Microsoft's anti-competitive behaviors, not about Microsoft not being what we want. By selling access to their protocoles, they allow other companies to enter the market, which is the point in these suits. Not pleasing the open source community.
One of the (if not "The") prime motivations behind Open Source is the simple fact that you can always fix problems yourself and will never be locked into a vendor.
With a lot of software, that is indeed true. I have myself fixed bugs in some smallish open source tools that were not maintained anymore and I still wanted to use. All good. But its not a holy grail either. The cost of a small team of kernel developers to fix problems in the Linux kernel if, theorically, it was abandonned, would make even most Fortune 1000 companies shiver.
Probably more expensive than it would be to hire a consulting firm to scavenge my stuff and move it to another newer OS (which can be done on either side of the fense). The whole "open source means you're not screwed if something happens" is a good argument, but its not absolute either.
.NET 3 is only an extension of.NET 2, but its the same language. Its basically the J2EE of.NET, more or less. An enterprise framework (or a piece of one, since.NET's way is to split it up).
And for being able to read C++ equalling being able to read C#... thats true for the base stuff. Pop in a custom control with a GUI designer, and your average C++ programmer will quickly go "What...the....f...." at the declarative attributes programming model of that kindda task. Just an example.
Be careful about that. While its true in the basics, as soon as you get in enterprise level development, everything changes. Implementing many patterns in C# is different than in Java (or at least, you don't implement them in the first place... I'm getting SO sick of java programmers coding Observer from scratch in C#...), and at the enterprise level it all changes: introspectable objects, messenging, caching, data access, data layer design, all of the web stuff, distributed computing and web services, multi-threading (yup! even something that basic is quite different), etc.
A OO basic is definately a must, but that should be mastered by the end of Uni (though I know many don't show much about it).
Once thats there, I personally suggest the Microsoft Press books for the various MCTS certifications. They assume you know the basic cross-language stuff from the get go, and focus only on the particularities of the environment. Excellent books.
Usualy for things like that (and I didn't check, and don't quote me), is fairly simple. When you pay redhat, what you're most likely buying is the support, not the product. So if you install more client than you paid for, and you called redhat and they somehow knew about it, you're sorry out of luck.
That quite the abstraction of how it works, but you get the idea.
The applied skills can't always be self taught. What the current CS schooling system fails to teach, is that CS is just one of many "theoritical" parts of the IT field.
Learning how to do a good, scalable, solid, integrated architecture, by yourself, is quite a bit more difficult than learning all the math and "basics" they'll teach you in school. Even more so I'd say, since to learn it well, you need human input a lot more than a "strict" science (like math) requires it. I'd have quite a bit an easier time learning functional analysis, data structures, algorythms, low level gates, and network layers from a book, than I would learning how to apply design patterns (not to be confused with learning design patterns themselves, thats easy), or how to design a software development process.
Don't confused a full fledged software development engineer with a "self taught hacker". Your average run of the mill CS major can't do that job any more than a self taught hacker can design a state machine.
So far, everywhere I worked (and thats quite a few places, I work on contracts), the flaws in most of the software development were always lack of understanding of software engineering paradigms. So obviously, its not that easy to be self taught there. But the whole "CS is the basics of everything!" is drilled so deep in people's heads, that they'll fail to see the other side of the coin: its quite harmful in the long run.
Software development foundations are just as part of the basics as, let say, knowing all of the network layers is, and those basics get used in totally different places. In a successful project, you need both skills, and people who are senior in both are extremely rare: taking an expert in one to do the other is almost always a recipy for disaster.
Thats the thing: there`s no common vernicular when you're not -working with these things-. My days, and I'm sure the days of quite a few software engineers in the business fields (which tend to be more common lately than R&D and low level software engineering) has a lot more to do with software architecture, design patterns and practices, specific technologies, data mining, business analysis.
Many of these things are theory. Some even share stuff with math. Doesn't change that they are only rarely taught in CS schools. Had this conversation with one of our -data analysts-, last time he had to bring up big O notation for the performance of one of his algorythms: it was the first time in a decade that it had been needed, and trust me, we would use it if it was needed, and many of us are almost begging to find uses for what we were taught in school, so its not like its going over our heads.
Common vernacular is useful? Yes: but software isn't all about math as it was, hell, just 10 years ago. The IT field is fragmenting in smaller, very different pieces, and someone with your average CS degree (some schools teach this stuff, its just uncommon) will not understand ANYTHING we talk about in a lot of companies, and it causes all the issues you talk about. Its the PROBLEM, not the solution.
Again: we don't all work for Intel, ATI, Nvidia, IBM, etc. I work for a fortune 500, yes, but its a freagin oil company. Functional analysis is as close to math as my job is gonna get, and the insane mess caused by those who only know the math and low level stuff are creating is just horrible. I've worked on both sides of the fence, and trust me, you have to see it to beleive it. People without a CS degree trying to work in places that need it causes, well, the situation you talked about. CS graduates who think the "basics" are actually the "base" of everything, causes the opposite problems in the business field.
Totally correct, but with a small issue: A lot of universities (including some prestigious ones in the top 5-10 of american CS schools) teach, well, CS (duh).
Knowing how to handle data structures, how low level network layers work, and a whole lot of theoritical math, doesnt help in any of these things. More "applied" skills are required, and at first glance, its not the norm, and well, doesn't even match the base definition of CS.
So I guess, CS is far from dead: we (and schools) just need to redefine it, or better yet, stop using that term (unless its -really- what they wanna teach... ATI and Intel still need to hire people for their low level stuff after all!)
There are architectural concerns in using something like Hibernate, that forces you into using a domain model type of software design to your application. I personally think that if there is a good architect around, it can be done smoothly and the time saving benifits are amazing, so I'm all for using ORMs, but there's another side of the story where some architect (mostly in the windows world, but it is -far- from being limited to it) who think that its the job of the RDBMS (and thus, stored procedures, etc) to handle all of this stuff, and that an application should never make its own SQL, siting certain headaches for the DBAs, and some theoritical architectural issues with it.
Anyhow, all that to say, Hibernate is awesome, but from a certain point of view, its similar to putting business logic straight in the JSP file (I disagree though)
So we have slow, bloated, IE6-only web apps. Hey, its easy to deploy. Has the users cursing non-stop and wanting us dead. But its easy to deploy!
So you're expressing a preference for non-web apps based on the fact that the people who wrote your company's web app are incompetent? What the hell makes you think they'd have done a better job with whatever other toolkit they used, especially keeping in mind that both of those you mentioned would simply give them vastly more opportunity to seriously screw things up?
If you've never used a properly designed and written web app (and from the tone of your comment, I'd guess not) you have no idea just how well they can work. Not everybody loves using them, but my experience with replacing non-web internal apps with web-based ones has been that the majority of people much prefer the web-based app. And if the developers of the software are clueless... well, no toolkit in the world is going to save them.
Quick to assume, eh? No. The people in charge of making decisions, decided on something not understanding its advantages and drawbacks. Our apps have requirements that fall straight in line with thick clients, and have very, VERY little in common with web apps. The developers just did what they were told (good people, but sheeps), made applications out of the use case to the best of their abilities. Which ended up with a total mess. However, I will admit that most of the developers had no clue how to use the web: Which is part of the thing, if all your senior developers haven't touched the technology, you either train them, or you go with a thick client. Existing ressources (and that includes the current hired developers) should always be considered in an analysis.
I know very well that well written web apps. Thats my speciality. Which is why I can easily tell when its a good idea to use a web app, and when it isn't. When part of your requirement is to be able to display extreme amounts of data, and allow a bazillion amounts of operation in a single screen, updating the data in real time, all while minimising network usage, and that your current users were used to a terminal app (aka: extremely, EXTREMELY fast), a thick client through an automatic deployement technology, using binary remoting, is what you want. -Especially- when cross platform compatibility of any kind isn't required, and actually, isn't even desired (one of our requirements was total integration in the current system, including windows token authentification, active directory, etc, and while thats all possible cross platform, its a decent bit longer).
Makes more sense now? We needed -nothing- web apps bring to the table, except ease of deployement, which is in itself not a major advantage anymore. Developping a thick client would have been faster, easier, more efficient, and more responsive for the scenarios we had to deal with. I, of course, would not be working there if they had made that decision, since I'm a web application specialist.
Many moralists and philosophers have elaborated on how fear is directly linked to faith: when an individual is scared to the point where they can't go on with their daily lives, beleiving in something can be the only way to work it out. Which would make sense, when you look at countries where the amount of fear is high. Middle East, the US, etc. On top of that there's the near universal fear of death, explaining why there's nowhere where religion and faith is totally absent (or almost).
Not a universal rule, of course, but its part of it anyway.
Well, the main thing with.NET is that its sent through windows update, and you can very easily push it through a windows domain (you can push anything mind you, but its obviously a lot easier to push windows components). Its also a big part of SQL Server's Reporting Services (the user end tools are pushed with ClickOnce), so you know there's a relatively large user base testing it. It "just works".
Oh, it can. Maybe not for "real", but there are toolkits that build entire "windows managers" in javascript. Works amazingly well.
and will never have any of the graphical capabilities of a desktop app
Now that depends where we stop the line of "web app". If we count it as HTML/CSS/Javascript/Whathaveyou, you're right. But there are things coming out to bridge the gap. For example, WPF/XAML, which is fairly amazing, though nothing a slashdotter would be interested in for obvious reasons. I'm sure there are cross platform equivalents in the work or already out.
The rest of your post IS right though, now I wish most analysts/project managers/architects would get that. Right tool for the right job, and its not always the web, no matter how buzzword-compliant it can be....
things like Java Web Start or.NET's ClickOnce solve the distribution issue. The advantages of the web are more lightweight UIs, easier to distribute to -third partys-, and better cross platform compatibility (even compared to Java). Easier update and maintenance, not so much.
Im working for an (extremely large) company that decided on web apps for the deployement thing alone, without needing (or -wanting-) any of the other advantages. So we have slow, bloated, IE6-only web apps. Hey, its easy to deploy. Has the users cursing non-stop and wanting us dead. But its easy to deploy!
They're talking about the PAID fix. The article is about microsoft charging to fix certain older products, and the parent was saying that anyone with a more recent version of the softwares don't need to pay a dime (obviously). Some people missed that, thus the parent precised, thats all.
[blockquote]Do they? A design pattern is an abstract, theoretical, generic approach to a solution. A recipe is a concrete solution to a specifc problem.[/blockquote]
Abstract, yeah. Generic, yes. Theoritical? Hell freagin no. Design patterns are practical way of solving -implementation- problems. That implementation will differ accross environments.
Best example in the book: The Observer pattern. In C++ or Java, you implement it "by the book". In.NET, you use a delagate.
Or some design patterns are solutions that were made for lack of better ways of solving a problem. The MVC pattern is one of em. In certain environments, its a de facto standard to decouple the presentation from the rest of the system. In other environments (that came later for the most part), its useless to achieve the same result.
Re:another "idea"
on
MySQL Cookbook
·
· Score: 2, Interesting
Caching: different if we're dealing with a web application. If you're using a cluster, you have to share cache dependency to keep it in sync, and depending on clustering technology/tools, its different.
Distributed applications: RMI in Java, C++, or.NET are different. Or are we using web services? Unless you're coding from scratch, different across environments. Do we make the WSDL manually, does the framework generate it on the fly? God forbid you're using Windows Communication Foundation, or Corba? Best practices and architecture are totally different.
Clustering: In ASP.NET you'll need to switch over to a state server else sessions won't work. Most mainstream RDBMS will link almost transparently, but with those that don't, you'll need to get creative. This one is almost purely dependant on technology, and different environments will have different ways of dealing with the mass servers.
BI: Data mining and such. SQL Server has a bunch of proprietary mechanics and ways of dealing with cubes and data models, and how to train them... Oracle of other ways, other third party tools have theirs. Or you can code from scratch. Depends on your needs, 100% different either way: the theorical concept is the same, the implementation, totally different.
Reversal of Dependency: Different languages, different ways of loading an object from a configuration..NET's objects are all introspectable by definition. Javas are not, so you need to do things differently..NET's best practice would build around the Provider pattern, which can be done by inheriting objects made for that purpose entirely. In Java (last time I checked, might have changed), you have to go by the design pattern from scratch. Or use Spring, for example.
Optimisation: totally different accross environments. For real RDBMS, you have to avoid cursors at all cost. For transactional engines with a relational API, you might need to use cursors like hell..NET has constructs to ease async calls built in web service proxies and database calls without ever having to make a thread instance, in Java, its handled differently.
Another example: the Observer Pattern. In Java its a standard design pattern, in.NET you use delegates. What about threads? I used to work on socket servers, handling concurrent connection. I had to do the same darn thing in.NET just today, and realised the best practices for locking and synchronising threads were completly different. Different constructs. Same logic, yes, but completly different ways of doing things cleanly.
And the list go on. Im comparing Java and.NET here because they're so close, yet all the best practices are different. If you compare PHP and.NET, its so freagin different, when you look at forums, you keep seeing PHP programmers begging to know how you can easily make a table by looping and outputting HTML, but its horrible practice. And it goes the other way around in reverse.
If we compared low level stuff, like string manipulation, pointer arithmetics, etc, yes, its the same across languages. But unless you're coding a driver, working on the Linux kernel, or coding in C, you're not going to do things that people have done 19274092174902 times over in the past. What you're more likely to do is make softwares that integrate one way or another with their environment. And thats never the same. It might LOOK the same. And thats the pitfall.
Seeing someone implement the Observer pattern in.NET makes me feel sick everytime...
Re:another "idea"
on
MySQL Cookbook
·
· Score: 2, Informative
Recipes have a lot in common with design patterns, or best practices. That is, they are far more "real world" than the fundamentals. And while the typical computer science major will have trouble understanding that (I don't mean you, btw), yes, the technology you use matters.
For example, whats efficient in MySQL, isn't whats efficient in SQL Server, and vice versa. That makes for extreme differences in whats the best architecture and best practices between environments. It tends to be extremely visible in "similar, but not" environments, like, again, MySQL vs SQL Server, C# vs Java, VB.NET vs VB6, and so on. People that think the fundamentals are all there is, end up applying something that works (amazingly well) in one world, in another, and then all hells break loose. I'm currently having to deal a lot with Java and C++ programmers (all extremely senior in their field), that are trying to apply their patterns and practices in.NET, and its a total disaster. The same would apply if the other way around happened, I am sure.
Simply put, we don't (frequently) code B-Trees, linked lists and matrix transformations anymore (certain fields do, but sure as hell not the fields that would have someone even spend a moment learning fundamentals, so we can ignore those). Anything that actually "matters", caching, distributed applications, clustering, Business Intelligences, reversal of dependency, optimisation, you name it, is night and day from one environment to another. Thats why these "recipes" exist.
Now, I'm not sure if a recipe book is a good solution, since as you said, people will just copy and paste them, but the concepts (often environment specific!) shown in there are important, and WILL have to be relearnt when doing anything significant using the "next buzz-word compliant thing".
Slashdot Mirror
Doubt it. Its still a bit different... since its an all or nothing, there's not flags, like there are in CPUs, either... So for that to happen, they'd have to get non-compliant drivers go by microsoft's certification program, fool them, then somehow not crash when direct x calls functions the GPU doesn't have...
The worse they can do I think, is pull an Nvidia like the Geforce FX: officialy, and technically support something, but have a totally horrible implementation.
Actualy, DX10 is not like that btw. There's no compatibility "bits" or whatsnot. With DX10, its an all or nothing: a card cannot claim DX10 compatibility if it doesn't support the entire spec. Sure, different cards can be slower on certain features than other, but thats it, which is quite very different from previous implementation.
That always cracks me up when people point out concerns over kids having access to this kind of material, then give, as an example, a (most likely) post puberty teenager as an example.
Aside the occasional retard who goes and meet total strangers offering candies and end up getting raped in the process, whats the worse that can happen to a 12 years old having access to that kind of content, may I know? I was watching hardcore porn when I was 8, and, ironically, I am now whats most likely considered a very "straight", successful individual...
Are there really people who are severly negatively affected by this?
Im not american either, and from speaking with my fiancee (who is), it seems slightly different there, but aside the occasional tutored booksmart top of the class geek, virtually everyone I've seen (including myself, with tons of trophees and prizes to show for it) who were top dogs in schools, didn't even lift a finger for it. They obviouslly avoided totally stupid acts like not showing up for a final, but aside that? I think from the time I finished elementary to graduating from college, with a 90-97% average among all my classes, Ive studied... a couple douzan hours total?
Like with economics, the "middle class" in school is the one that tend to work the hardest. The bottom and the top don't work all that hard (in general). So its far from "excessive willingness to engage in the daycare system"
Again, thats extremely relative... being able to fix stuff from the source is quite the idealogy. Not all Open Source projects are Apache-quality.
.NET, unless the sources are specifically obfuscated, you can just decompile them if you need to know the inner working...
If you were using PostgreSQL a few years back (the latest version ain't so bad, so it wouldn't be a good example), and the project went under, good freagin luck making any sense of the source. Even in its latest version, it would take several thousand dollars to get anything done with the source: potentially more expensive than starting back from scratch.
On top of that, just about any serious license contract has a clause where if shit hits the fan, you get the source. If you're big enough, you can even get Windows' freagin sources!
Simply put, most softwares that you'd be worried to go under are multi-million lines of code softwares. If they're not popular projects, getting someone to go through the code would take weeks or months. If they ARE popular projects, the day the project goes under, any developer experienced with the project, willing to get anything done with it, will charge a pretty penny once they're called by everyone else.
And well, now with the advance of Java and
Thus my point remains: Yes, the fact that you have the source if something happens, IS an advantage of open source. A significant one. It IS, however, vastly overrated.
You mean, they only allow non-free (as in beer) and non-viral license (as in GPL...not using "viral" license as a bad term here, but simply to denote a license that applies to derived work) based companies to enter the market. A company that actually makes cash using open source softwares that don't force you to open connected modules, probably could use them just fine. Not very different from certain commercial Linux distros offering commercial closed codecs, etc.
On the desktop, Microsoft's biggest competitor is a closed source company (Apple). On the server, its not even Linux directly, but ISVs that use open source: in those case, using closed APIs is rarely an issue.
There's really no problem allowing competitors to enter the market: its just not "everything" open source advocates wants. Well, nothing's perfect in this world, have to live with it, and I wouldn't be surprised if even the EU commission would realise that. Hell, at this point, Microsoft can't even attribute a lot of its market to its Monopoly, but only to brand loyalty and, to some extent, to some of its products actually being good (I know its not the norm...yet...but I've worked for quite a couple of companies in the last few years, most being windows centric, and none of them were actually locked in, aside for minimal Office file format need, and we're talking companies of all sides).
The work the EU commission is doing is good. Microsoft wouldn't have started making some kind of effort without being forced to, I'll admit. But being blinded by our own little wishes, and getting anti-thrust laws to be respected, is two things, EVEN in Europe.
Whats totally ironic, is that while you're 100% right (minus the part where if you have must have apps not available on Linux, you're a bit screwed), Microsoft is becoming more attractive on the server side, and, as you pointed out, less on the desktop. Totally upside down.
Things like IIS (yes, IIS, I said it), especially IIS7 once its available as a real server, along with ASP.NET, are very attractive. SQL Server's business intelligence platform have amazing values for the cost, especially when you count that its free for small installs, and that for larger ones the cost is insignificant compared to equivalent alternatives (and superior alternatives are several times the cost in many cases).
While I don't think I'd have an issue switching to Linux as a desktop platform, it would be a cold day in hell before I move it away from my servers and development machines. Which is, a gain, totally ironic, considering Microsoft's track record on the server side. Hell froze over.
This is about Microsoft's anti-competitive behaviors, not about Microsoft not being what we want. By selling access to their protocoles, they allow other companies to enter the market, which is the point in these suits. Not pleasing the open source community.
Probably more expensive than it would be to hire a consulting firm to scavenge my stuff and move it to another newer OS (which can be done on either side of the fense). The whole "open source means you're not screwed if something happens" is a good argument, but its not absolute either.
.NET 3 is only an extension of .NET 2, but its the same language. Its basically the J2EE of .NET, more or less. An enterprise framework (or a piece of one, since .NET's way is to split it up).
And for being able to read C++ equalling being able to read C#... thats true for the base stuff. Pop in a custom control with a GUI designer, and your average C++ programmer will quickly go "What...the....f...." at the declarative attributes programming model of that kindda task. Just an example.
Be careful about that. While its true in the basics, as soon as you get in enterprise level development, everything changes. Implementing many patterns in C# is different than in Java (or at least, you don't implement them in the first place... I'm getting SO sick of java programmers coding Observer from scratch in C#...), and at the enterprise level it all changes: introspectable objects, messenging, caching, data access, data layer design, all of the web stuff, distributed computing and web services, multi-threading (yup! even something that basic is quite different), etc.
A OO basic is definately a must, but that should be mastered by the end of Uni (though I know many don't show much about it).
Once thats there, I personally suggest the Microsoft Press books for the various MCTS certifications. They assume you know the basic cross-language stuff from the get go, and focus only on the particularities of the environment. Excellent books.
Usualy for things like that (and I didn't check, and don't quote me), is fairly simple. When you pay redhat, what you're most likely buying is the support, not the product. So if you install more client than you paid for, and you called redhat and they somehow knew about it, you're sorry out of luck.
That quite the abstraction of how it works, but you get the idea.
The applied skills can't always be self taught. What the current CS schooling system fails to teach, is that CS is just one of many "theoritical" parts of the IT field.
Learning how to do a good, scalable, solid, integrated architecture, by yourself, is quite a bit more difficult than learning all the math and "basics" they'll teach you in school. Even more so I'd say, since to learn it well, you need human input a lot more than a "strict" science (like math) requires it. I'd have quite a bit an easier time learning functional analysis, data structures, algorythms, low level gates, and network layers from a book, than I would learning how to apply design patterns (not to be confused with learning design patterns themselves, thats easy), or how to design a software development process.
Don't confused a full fledged software development engineer with a "self taught hacker". Your average run of the mill CS major can't do that job any more than a self taught hacker can design a state machine.
So far, everywhere I worked (and thats quite a few places, I work on contracts), the flaws in most of the software development were always lack of understanding of software engineering paradigms. So obviously, its not that easy to be self taught there. But the whole "CS is the basics of everything!" is drilled so deep in people's heads, that they'll fail to see the other side of the coin: its quite harmful in the long run.
Software development foundations are just as part of the basics as, let say, knowing all of the network layers is, and those basics get used in totally different places. In a successful project, you need both skills, and people who are senior in both are extremely rare: taking an expert in one to do the other is almost always a recipy for disaster.
Thats the thing: there`s no common vernicular when you're not -working with these things-. My days, and I'm sure the days of quite a few software engineers in the business fields (which tend to be more common lately than R&D and low level software engineering) has a lot more to do with software architecture, design patterns and practices, specific technologies, data mining, business analysis.
Many of these things are theory. Some even share stuff with math. Doesn't change that they are only rarely taught in CS schools. Had this conversation with one of our -data analysts-, last time he had to bring up big O notation for the performance of one of his algorythms: it was the first time in a decade that it had been needed, and trust me, we would use it if it was needed, and many of us are almost begging to find uses for what we were taught in school, so its not like its going over our heads.
Common vernacular is useful? Yes: but software isn't all about math as it was, hell, just 10 years ago. The IT field is fragmenting in smaller, very different pieces, and someone with your average CS degree (some schools teach this stuff, its just uncommon) will not understand ANYTHING we talk about in a lot of companies, and it causes all the issues you talk about. Its the PROBLEM, not the solution.
Again: we don't all work for Intel, ATI, Nvidia, IBM, etc. I work for a fortune 500, yes, but its a freagin oil company. Functional analysis is as close to math as my job is gonna get, and the insane mess caused by those who only know the math and low level stuff are creating is just horrible. I've worked on both sides of the fence, and trust me, you have to see it to beleive it. People without a CS degree trying to work in places that need it causes, well, the situation you talked about. CS graduates who think the "basics" are actually the "base" of everything, causes the opposite problems in the business field.
Totally correct, but with a small issue: A lot of universities (including some prestigious ones in the top 5-10 of american CS schools) teach, well, CS (duh).
Knowing how to handle data structures, how low level network layers work, and a whole lot of theoritical math, doesnt help in any of these things. More "applied" skills are required, and at first glance, its not the norm, and well, doesn't even match the base definition of CS.
So I guess, CS is far from dead: we (and schools) just need to redefine it, or better yet, stop using that term (unless its -really- what they wanna teach... ATI and Intel still need to hire people for their low level stuff after all!)
There are architectural concerns in using something like Hibernate, that forces you into using a domain model type of software design to your application. I personally think that if there is a good architect around, it can be done smoothly and the time saving benifits are amazing, so I'm all for using ORMs, but there's another side of the story where some architect (mostly in the windows world, but it is -far- from being limited to it) who think that its the job of the RDBMS (and thus, stored procedures, etc) to handle all of this stuff, and that an application should never make its own SQL, siting certain headaches for the DBAs, and some theoritical architectural issues with it.
Anyhow, all that to say, Hibernate is awesome, but from a certain point of view, its similar to putting business logic straight in the JSP file (I disagree though)
I know very well that well written web apps. Thats my speciality. Which is why I can easily tell when its a good idea to use a web app, and when it isn't. When part of your requirement is to be able to display extreme amounts of data, and allow a bazillion amounts of operation in a single screen, updating the data in real time, all while minimising network usage, and that your current users were used to a terminal app (aka: extremely, EXTREMELY fast), a thick client through an automatic deployement technology, using binary remoting, is what you want. -Especially- when cross platform compatibility of any kind isn't required, and actually, isn't even desired (one of our requirements was total integration in the current system, including windows token authentification, active directory, etc, and while thats all possible cross platform, its a decent bit longer).
Makes more sense now? We needed -nothing- web apps bring to the table, except ease of deployement, which is in itself not a major advantage anymore. Developping a thick client would have been faster, easier, more efficient, and more responsive for the scenarios we had to deal with. I, of course, would not be working there if they had made that decision, since I'm a web application specialist.
Many moralists and philosophers have elaborated on how fear is directly linked to faith: when an individual is scared to the point where they can't go on with their daily lives, beleiving in something can be the only way to work it out. Which would make sense, when you look at countries where the amount of fear is high. Middle East, the US, etc. On top of that there's the near universal fear of death, explaining why there's nowhere where religion and faith is totally absent (or almost).
Not a universal rule, of course, but its part of it anyway.
Well, the main thing with .NET is that its sent through windows update, and you can very easily push it through a windows domain (you can push anything mind you, but its obviously a lot easier to push windows components). Its also a big part of SQL Server's Reporting Services (the user end tools are pushed with ClickOnce), so you know there's a relatively large user base testing it. It "just works".
The rest of your post IS right though, now I wish most analysts/project managers/architects would get that. Right tool for the right job, and its not always the web, no matter how buzzword-compliant it can be....
things like Java Web Start or .NET's ClickOnce solve the distribution issue. The advantages of the web are more lightweight UIs, easier to distribute to -third partys-, and better cross platform compatibility (even compared to Java). Easier update and maintenance, not so much.
Im working for an (extremely large) company that decided on web apps for the deployement thing alone, without needing (or -wanting-) any of the other advantages. So we have slow, bloated, IE6-only web apps. Hey, its easy to deploy. Has the users cursing non-stop and wanting us dead. But its easy to deploy!
They're talking about the PAID fix. The article is about microsoft charging to fix certain older products, and the parent was saying that anyone with a more recent version of the softwares don't need to pay a dime (obviously). Some people missed that, thus the parent precised, thats all.
[blockquote]Do they? A design pattern is an abstract, theoretical, generic approach to a solution. A recipe is a concrete solution to a specifc problem.[/blockquote]
.NET, you use a delagate.
Abstract, yeah. Generic, yes. Theoritical? Hell freagin no. Design patterns are practical way of solving -implementation- problems. That implementation will differ accross environments.
Best example in the book: The Observer pattern. In C++ or Java, you implement it "by the book". In
Or some design patterns are solutions that were made for lack of better ways of solving a problem. The MVC pattern is one of em. In certain environments, its a de facto standard to decouple the presentation from the rest of the system. In other environments (that came later for the most part), its useless to achieve the same result.
Caching: different if we're dealing with a web application. If you're using a cluster, you have to share cache dependency to keep it in sync, and depending on clustering technology/tools, its different.
.NET are different. Or are we using web services? Unless you're coding from scratch, different across environments. Do we make the WSDL manually, does the framework generate it on the fly? God forbid you're using Windows Communication Foundation, or Corba? Best practices and architecture are totally different.
.NET's objects are all introspectable by definition. Javas are not, so you need to do things differently. .NET's best practice would build around the Provider pattern, which can be done by inheriting objects made for that purpose entirely. In Java (last time I checked, might have changed), you have to go by the design pattern from scratch. Or use Spring, for example.
.NET has constructs to ease async calls built in web service proxies and database calls without ever having to make a thread instance, in Java, its handled differently.
.NET you use delegates. What about threads? I used to work on socket servers, handling concurrent connection. I had to do the same darn thing in .NET just today, and realised the best practices for locking and synchronising threads were completly different. Different constructs. Same logic, yes, but completly different ways of doing things cleanly.
.NET here because they're so close, yet all the best practices are different. If you compare PHP and .NET, its so freagin different, when you look at forums, you keep seeing PHP programmers begging to know how you can easily make a table by looping and outputting HTML, but its horrible practice. And it goes the other way around in reverse.
.NET makes me feel sick everytime...
Distributed applications: RMI in Java, C++, or
Clustering: In ASP.NET you'll need to switch over to a state server else sessions won't work. Most mainstream RDBMS will link almost transparently, but with those that don't, you'll need to get creative. This one is almost purely dependant on technology, and different environments will have different ways of dealing with the mass servers.
BI: Data mining and such. SQL Server has a bunch of proprietary mechanics and ways of dealing with cubes and data models, and how to train them... Oracle of other ways, other third party tools have theirs. Or you can code from scratch. Depends on your needs, 100% different either way: the theorical concept is the same, the implementation, totally different.
Reversal of Dependency: Different languages, different ways of loading an object from a configuration.
Optimisation: totally different accross environments. For real RDBMS, you have to avoid cursors at all cost. For transactional engines with a relational API, you might need to use cursors like hell.
Another example: the Observer Pattern. In Java its a standard design pattern, in
And the list go on. Im comparing Java and
If we compared low level stuff, like string manipulation, pointer arithmetics, etc, yes, its the same across languages. But unless you're coding a driver, working on the Linux kernel, or coding in C, you're not going to do things that people have done 19274092174902 times over in the past. What you're more likely to do is make softwares that integrate one way or another with their environment. And thats never the same. It might LOOK the same. And thats the pitfall.
Seeing someone implement the Observer pattern in
Recipes have a lot in common with design patterns, or best practices. That is, they are far more "real world" than the fundamentals. And while the typical computer science major will have trouble understanding that (I don't mean you, btw), yes, the technology you use matters.
.NET, and its a total disaster. The same would apply if the other way around happened, I am sure.
For example, whats efficient in MySQL, isn't whats efficient in SQL Server, and vice versa. That makes for extreme differences in whats the best architecture and best practices between environments. It tends to be extremely visible in "similar, but not" environments, like, again, MySQL vs SQL Server, C# vs Java, VB.NET vs VB6, and so on. People that think the fundamentals are all there is, end up applying something that works (amazingly well) in one world, in another, and then all hells break loose. I'm currently having to deal a lot with Java and C++ programmers (all extremely senior in their field), that are trying to apply their patterns and practices in
Simply put, we don't (frequently) code B-Trees, linked lists and matrix transformations anymore (certain fields do, but sure as hell not the fields that would have someone even spend a moment learning fundamentals, so we can ignore those). Anything that actually "matters", caching, distributed applications, clustering, Business Intelligences, reversal of dependency, optimisation, you name it, is night and day from one environment to another. Thats why these "recipes" exist.
Now, I'm not sure if a recipe book is a good solution, since as you said, people will just copy and paste them, but the concepts (often environment specific!) shown in there are important, and WILL have to be relearnt when doing anything significant using the "next buzz-word compliant thing".