You need to understand the difference between an OS and an application suite.
You need to understand what monopoly abuse is, and why it is illegal in most places. (Hint: just bundling other software with the OS isn't the problem.)
And if you think Microsoft are giving all this stuff away out of the kindness of their heart, you really need to understand what a loss leader is. If Microsoft secures the multimedia world as it has the web browser world, just in time for DRM-based lock-in solutions to arrive en masse with the support of the big media corps, you've just written them a blank cheque for 90% of the downloadable music content all over the world. Way to go.
In an object oriented system types are meaningless. What matters is what functionality other objects provide.
I think I know what you're trying to say, but I'm pretty sure it's not what you've said. OO basically implies explicit interfaces via inheritance, and in that respect, types are everything. You can program very powerfully using generic techniques instead, but then you're not doing OO.
STL requires you to deal with RTTI if you're going to do anything dynamic with it.
I'm sorry, you lost me there. How does using the STL require any more RTTI to achieve dynamic binding than any other version of the same code?
To quote Alan Kay, "I invented the term object-oriented, and I did not have C++ in mind."
I don't care who invented the word, I care who invented the concept, and the C++ community has collectively contributed more to the OO concept over the years than just about any other. Hell, Bjarne Stroustrup invented the term C++, and I'm guessing he didn't have today's C++ in mind, either. That doesn't mean today's C++ isn't an improvement on his original vision a couple of decades ago.
Everyone agrees that jumping around a function using gotos are bad, but somehow dynamically jumping around the program at runtime to undefined places is all ok.
Firstly, not everyone agrees that. It's common practice, because we have an alternative (structured programming) that many people prefer.
Secondly, exceptions are a natural complement to functional decomposition and structured programming, and the places where they can be handled are typically very well-defined. To date, no-one's managed to popularise a more effective system for controlling failure in a large application, so that's why we use them.
Take a look at page 7 of K&R. You write code in procedures. main is the procedure you start in. You call other procedures to do work; printf prints stuff. stdio is the standard input/output library that defines printf. Is that so hard to comprehend?
You're letting what's second nature to you as an experienced programmer cloud your judgement. Having taught several non-programmers some basic C, I can tell you that your explanation above would probably result in something like the following:
What's code?
What's a procedure?
What do I call other procedures? That didn't make sense!
Nothing came out of the printer when I said printf!
What's the library got to do with anything? Can't the system explain it without me having to go and borrow a book?
Teaching is all about recognising what you understand but somebody else doesn't. The more you understand, the harder that gets, and the more your own preconceptions and ideas get in the way.
Smalltalk, C++, Lisp, and Python are all completely different languages. Java is far more like C++ than it is to any of the other languages I mentioned; I consider it to be a cleaned up C++ more than anything
You don't know much about either Java or C++, do you?:-)
You can convert a Java program into a C++ program with zero effort just by implementing classes needed, and garbage collection
That's hardly zero effort. And besides, I can write FORTRAN in OCaml if I try hard enough, but it wouldn't give as good a result as using OCaml's own features well.
one of the big differences is that Java is type-safe, while C++ isn't!
I love this one. The language that forced everyone to cast for years (with its advocates frequently claiming that templates were just bloat, no less) and where everything derives from Object is type safe, but the language which has provided safer casts, typesafe templates and no universal root type for years isn't?
We're working the parse tree once removed and are forced into prose by the ancient conventions and a pathetic need to print.
We lack a model in which we work the parse trees symbolically/pictorially using the keyboard. One where we can zoom structurally, rotate and slice our model by patterns, flows and data-access regardless of instance and without regard for 'files'.
Well, I don't have nearly your experience, but I've thought along similar lines in the past and explored this idea in some detail.
I think the catch is that, as with so many things, the devil is in the details. Graphical interfaces (in the sense of representing your program as a graph, and displaying it in a non-pure-text format) can be useful for browsing source, as some of the better IDEs demonstrate. However, the decision logic I can represent concisely in ten lines of well-written code would take several screens of pretty graphics to represent if drawn in some sort of tree form.
There are definitely shades of grey here. The concise code is easy to manipulate, and of course text-based languages have some major practical advantages, from portability of the source files to the easy use of macros. On the other hand, that conciseness can hide misunderstandings and bugs that would be immediately apparent in a clearly presented graphical display; they don't call it "code" for nothing! But there is surely a reason the world of mathematics still writes its equations and papers in the same basic format it's used since forever...
But it's really not that simple; that's the point.
Open source may be supported by volunteers, but the people who wrote the CSS software were doing it for money. The companies employing them need to get some return on that investment to be profitable and remain in business. In the capitalist world, which like it or not is where we live, that return comes from licensing revenue, amongst other things.
Yes, this sucks for OSS, but it's not Microsoft's (or anyone else's, for that matter) fault that OSS projects choose to run on a non-financial model that gives them limited resources. Neither is it the court's job to disadvantage Microsoft for the benefit of OSS coders. It costs a significant amount of money to produce and maintain useful documentation for a complex interface, and while the courts might reasonably require Microsoft to make such documentation available at cost in the interests of fair competition, I see no reason they should require Microsoft to pay to produce it and then give it away for free because the open source world haven't found a source of funding to play by the same rules as everyone else in the business.
I realise this is unfortunate for Joe OSS Developer, but there are two sides to every argument, and even big corporations have to be treated reasonably by the courts.
And the software that has the best shot at being best for consumers and promoting interoperability is open source software, which gets shafted by this action.
Do you have any evidence to support that, beyond your personal opinion? There are very few things that have been done well by OSS that haven't been done at least as well if not very much better by CSS, even by software written by Microsoft in some cases.
Defending competition in the marketplace will naturally defend consumers, modulo minor bumps in the road. Having the courts set an agenda which promotes a specific product or philosophy, even one as apparently community-centric as OSS, comes with no such guarantees. If the open source approach is as superior a development philosophy as its advocates claim, then it will naturally win in a marketplace guaranteeing fair competition anyway.
If someone asked me to rate my C++ skills from 1 to 10, I would give myself a 4 or a 5. Anyone that rates themselves a 7 or higher is either named Sutter, Alexandrescu, Glassborow, or Stroustroup. Or is either grossly unfamiliar with the scope of C++ or flat out lying.
I'd give myself at least an 8, and I'd stand by that and justify it in an interview. C++ isn't that complicated, it just requires more than trivial "what I did at the office today" effort to learn what it can really do.
Their were people that thought they new the language cold until Alexandrescu wrote Modern C++ Design and turned the C++ on end.
No, he didn't. He introduced a neat idiom in policy classes, and showed some applications of design patterns using that idea. He also did a bit of work on template metaprogramming. While his book is impressive -- certainly I'll take nothing away from him in that regard -- concepts like template metaprogramming aren't rocket science, and have been well discussed among the on-line C++ community for years.
In fact, a great many of the "advanced" ideas in C++ development today are just nicked from what's routine in other languages, particularly where emulating higher-order functions or closures are concerned. Some of the implementation tricks talked about by the experts are neat, but the concepts are nothing radical, and don't require some sort of ueber-guru badge to understand.
They haven't written a program recently for fun? Better give a very good reason then, if they want a programming job.
Dear Mr Potential Interviewer,
I am a professional software developer. I wrote my first program when I was about five, and my first program for significant money when I was in my early teens. Throughout my time at school I wrote programs for fun. Throughout my time at university, I wrote programs to help me with my work. I have been a full-time professional for around five years, and in two successive jobs, I have been the person my colleagues turned to with tricky technical questions or for a second opinion on a programming book, because I've probably read it already.
Today, I'm 26, and as well as being a full-time developer, I volunteer around 20-30 hours per week helping to run a large club relating to one of my hobbies, I have a long-term girlfriend, and I have several other hobbies besides. I am a geek's geek, in the sense that I enjoy my field and keep abrest of new developments in computing generally and programming specifically. In the past two years, I have learned enough Perl to write reasonably involved scripts at work and a CGI interface to a MySQL database for the club, enough XML/XSLT to overhaul a 50+ page web site almost single-handed in my off hours so that it can be maintained by non-techies, and a fair bit of background on Python and various functional programming languages just for fun.
Unfortunately, there are only 26 hours in my day, and the last time I wrote a program just for fun was several years ago, so I'm afraid I won't be able to accept a job at your firm. Thanks for your time.
In other words, the actual software that these laws protects is horrible stuff like RealOne and Quicktime.
That's the software that might benefit today. But the action isn't protecting specific software, other than incidentally. It's defending the principles of competition and interoperability, which is a far more important goal.
It's not chump change. It's a small but significant dent, which they've unceremoniously been given in spite of Ballmer's best efforts to talk the authorities down last week.
It's also widely rumoured to be accompanied by (a) a compulsion to ship a version of Windows with Media Player completely stripped out, in order to remove the artificial dominance Microsoft has secured over the multimedia world, and (b) heavy penalty conditions if Microsoft gets up to this stuff again, so lengthy court action can be replaced by abruptly hitting them when they're down. These are, for now, only rumours, since the ruling won't be made public until later this week. However, no-one's jumping up and down denying them, and it's well known that all the European parties and Microsoft have seen that ruling. Draw any conclusions from that you like, or wait to see for sure mid-week.
At any rate, this isn't meant to kill Microsoft. It's meant to make them behave, and to reopen competition in the marketplace for the benefit of the public. In that respect, it seems fairly well judged, assuming the above rumours are reasonably accurate.
I still don't believe Microsoft is any more of a monopoly than Intel, but Intel knows how to play the game.
Well, I'm typing this on an AMD-based PC running Mozilla, so maybe you have a point.
Then again, Intel and AMD have swapped the lead in the processor race and each has maintained a very significant market share for years, while even Microsoft's main rivals -- probably the big names from the OSS world at this point -- languish with single figures of percent of market share at best, a few niche market exceptions notwithstanding. Maybe the point wasn't so great after all...
Did programming by itself made possible to create binary search, the QR algorithm, or quicksort? Not really, it just provided implementation.
And would anybody have researched and discovered those algorithms if they weren't going to be used in a programming context? Computer science is all about what you can do with programs, and without programming, computer science has no application. The two are inseparable, unless you're talking specifically about programming meaning strictly "the action of sitting down at a keyboard and typing a program", but I'm assuming the common usage where programming covers the whole process of producing a program.
There's still no science called "programming science".
Of course not: computer science is the science of programming. Programming itself is an art.;-)
But after studying a load of math the ideas of functional programming weren't too hard to grasp. In many ways it's just math done in a language.
That's true, up to a point, but the magic of functional languages -- concepts like first-order functions, currying, lazy evaluation, and serious use of recursive algorithms -- are quite a way beyond the simple mathematical definition of a function, and very different to the traditional, imperative perspective on programming languages.
Furthermore I fail to see the major diffrence between a functional style head+tail list with a procedural head+next structure. If you have a linked list implemented as a flat array you're apparently not very geared toward making insertions/deletions in the middle a fast case.
But again, the common usage is very different. In a typical procedural or OO language, you use a linked list as an alternative to an array-like data structure, when you need cheap extension or insertion and/or erasure of elements. It's common to iterate over lists, and you see variations on the theme such as skip lists, but that's about it.
In a functional language, OTOH, lists are frequently the fundamental data structure, rather than the arrays used by imperative or OO languages. The use of recursive algorithms to manipulate the lists, and pattern matching and empty lists, are paramount, and concepts like tail recursion are really important. The whole perspective, the role the lists play and the way they are constructed and manipulated, is very different. There is, or should be, more to a course in data structures and algorithms than just which structures have the best theoretical bounds on efficiency. That's one consideration, but hardly the only one (or even, up to a point, the most important one) in the real world.
Finally, I've done coding in a couple of languages and in my experience I've found Java to a pretty good compromise.
Java is a fine language for things it's good at. I just don't think education is one of those things.:-)
Show me a non-trivial piece of software software that doesn't stink.
TeX.
We need something fresh, something new, something creative to solve this problem. We have yet to hear from the person or people who will give us a revolution in software. It doesn't have to be like it is. We have been approaching the creation of software from the wrong angle since the beginning.
So a million people trying to sound clever have said. None of them has yet told us "morons" how to do it better, though, have they? And neither have you. Do get back to us when you've got something constructive to offer, though, as I'm sure the morons would love to hear about it.
There is no science to programming. It's not "programming science", it's computer science.
What an absurd thing to say. If computer science is not about the basics underlying programming (whether that's in a software language or using logic gates or drawing pictures on a piece of paper) then what exactly is it about?
My school's core computer science curriculum is in Java. Language of instruction is a moot point to a rather great extent. You can learn as much from a data structures class taugh in Java as you can from one taught in $language_of_choice. The idea is to learn how things work fundamentally, and then apply those ideas practically. A linked list in Java works the same as a linked list in C. Its not about Java being the "industry standard" as you call it, its about Java being a perfectly modern and capable programming language. The idea
It's a shame you didn't finish that sentence; I was interested in what you were thinking there.
The thing is, you can't learn as much about general practice from one language as another, or indeed from any one language compared to a range of different ones. For example, the use of arrays and indexing is common to many procedural and OO languages, including C, Java, and their friends. The use of lists (in the form head element + tail) and pattern matching is ubiquitous in functional programming, and also supported by some scripting languages. There are few if any lanugages where you'd really learn the implications and pros/cons of both, and these are the two most basic data structures I can think of. A more complex version would be comparing the use of structures+pointers to build data structures in C with the use of conjunctive/disjunctive types and pattern matching in functional languages.
Java is actually a particularly bad example of a teaching language, IMHO. It doesn't really let you get under the hood of either of these two mainstream techniques for defining data strucutures. It's similarly restrictive in other areas: everything is about objects, for example, yet it avoids some of the major OOP issues like multiple inheritance in favour of a much-simplified model. There are plenty of multi-paradigm languages that could have been used instead, or plenty of principally single-paradigm languages that are easier to understand for a beginner or more comprehensive beyond the basics. Java is used because it's trendy, nothing more.
95% of projects don't require [the hard CS stuff]. The sad fact is that "Computer Science" is only really applicable to solving "hard problems", writing compilers, designing languages, or to AI and its kin. It is in general, not applicable to business applications.
I think you touched on something very important there, but didn't pursue it.
The skills and techniques developed by CS very much are applicable to business applications. Everything including your swishy new web service front ends to international business DBs would fall apart without them.
The key is that in the business apps (aka databases) world, only a small number of people need to understand the deep stuff, and as long as the tools they write for others to use are good enough, everybody benefits. Skilled management in software development has always recognised that there is a bell curve of ability, and often the best use of your top people is to write tools for your average (and much more numerous) people.
it's just a fact that not much yummy stuff is left.
Again, I think this is a question of perspective. What's yummy to the theoretical/research-minded expert with a strong CS background is probably very different to what's yummy for the guy whose interest lies in producing a good database-based application for his client, and really has no time for the niceties of fine programming technique. In a happy coincidence, these two types of people are both valuable, and their roles are perfect complements.
But when you have garbage collection, a raging fast machine, and graphical IDE's, even if someone puts crappy code together, as long as they make a decent API, it's going to work after they try to compile it half a million times.
On that point, I disagree. I've just spent about four months on a project to implement a new feature at work. I spent the first month implementing the new feature, according to clear requirements based on a well-defined goal, and it worked just fine. I spent the next three months clearing up the regression test changes, ultimately going to the very heart of our system and code that has been there for a decade, and ripping it out because it was badly written and contained numerous minor bugs.
Now, those bugs had always been there, they just showed up much more often in the new applications we're giving our software, which happen to be where my new feature is used as well. As a result, my productivity, defined by how much useful functionality I added, was reduced 75%, precisely because I was clearing up the mess of people who didn't try hard enough to maintain a good design and a solid implementation.
This is probably the worst instance of this phenomenon that I've seen in my time as a professional developer, but it's hardly the first time I've seen the effect, and I'm sure it's familiar to any other software developers reading this post. This is the reason there will always be a need for the upper band of programmers; the question, IMHO, is more whether they're best used to clean up and maintain the code we write today, or implementing tools that will allow us to use more powerful code tomorrow.
I agree - coding well isn't easy, but my CS degree really only half prepared me for being able to code well.
I think half-preparing someone would be an exceptional achievement for a CS degree. It's all too easy to believe that such a qualification is all it takes to become a programmer, and to misunderstand an academic study of an area to be a replacement for experience of the practical application of that knowledge. This is why hiring a natural hacker is often a better bet than hiring a highly qualified CS grad who's just in it for the money.
Except for some elitits who claim one has to use, say, functional programming languages to do anything interesting, or "no pain no gain" hard-core low-level language fanatics, most truly good programmers understand it's not tools that make exceptional advances; it's the craftsmen that use them.
On the other hand, a professional in this field who isn't at least aware of the benefits of both low-level languages and functional programming probably has such a hole in general knowledge of their subject that they'll never be a "truly good programmer". You don't have to use them, any more than you have to be some sort of L337 Hax0r d00d who runs Linux because it's cool. But some awareness and appreciation of the strengths and weaknesses of different tools and approaches is elementary to becoming a competent practitioner of any craft -- not an expert, just competent.
Until we get away from this attitude that writing a basic database front-end in Visual Basic or an eight-week course in Java and OO qualifies you as a competent professional, and get back to the point where the average developer has a basic appreciation of the broader issues in their subject, we will continue to write crappy code, the world will continue to succumb to script-kiddie hacker wannabes, business software will never live up to its promise of boosting efficiency for the real work your company does (whatever that is), and so on. That's what you get for hiring incompetents, and sadly, incompetence has become the norm in our industry.
This is not elitism. It's simply advocacy of learning your subject before practising it, and taking a little pride in your work. Both are terribly old-fashioned values in today's high-tech world, and terribly politically incorrect, but there you go. You wanted to know how to improve things; I'm just telling it as it is.
Admittedly it was outside of the letter of the law to post this outside of its home site.
OK, before we start, let's be clear that you just said all that matters. If you object to anything else, it's nothing but your personal opinion, and if you want things to change, you should be campaigning to update the law, not ranting on Slashdot.
But this is the internet. The expectation is to be able to link to another part of someone else's site so that we have this inter-related "web" of information. The commercialization of the internet with broadcast paradigm limitations destroys the peer-to-peer web-like nature of the... of the web.
The Web would be nothing but an academic toy without that commercialisation. The use of the technology is evolving quickly, just as any new field does, but that evolution does not give it the right to violate the accepted rules of society. The Internet is nothing special in the eyes of the law, nor should it be. It is simply a new context, which requires clarification or adjustment, not a complete departure from existing norms. Understand this, please.
As for copyright: Copyright was meant to limit copying with copy presses.
No, it wasn't. It was designed to promote the generation of content in the interests of society, by recognising that producing good content requires investment, and that by offering reasonable guarantees to the authors in return for that investment you will encourage content generation.
Anyway, even the letter-ignoring law abiding slashdotters understand the bad karma of direct posting, but the impetus for doing so was that the submission of this article appeared to be an intentionally subversive advertising ploy.
I dislike the fact that the editors accepted the submission under the circumstances, but two wrongs do not a right make. And cut with the "impetus" crap: someone does this pretty much every time there's an interesting article hidden behind a front-end, even when all the front-end asks is a little advertising revenue from you in exchange for showing you their article.
Slashdot Mirror
You need to understand the difference between an OS and an application suite.
You need to understand what monopoly abuse is, and why it is illegal in most places. (Hint: just bundling other software with the OS isn't the problem.)
And if you think Microsoft are giving all this stuff away out of the kindness of their heart, you really need to understand what a loss leader is. If Microsoft secures the multimedia world as it has the web browser world, just in time for DRM-based lock-in solutions to arrive en masse with the support of the big media corps, you've just written them a blank cheque for 90% of the downloadable music content all over the world. Way to go.
Yeah, well, we thought it would be polite to wait for those guys across the pond to finish their go first. Terribly nice people, us Brits. :o)
I think I know what you're trying to say, but I'm pretty sure it's not what you've said. OO basically implies explicit interfaces via inheritance, and in that respect, types are everything. You can program very powerfully using generic techniques instead, but then you're not doing OO.
I'm sorry, you lost me there. How does using the STL require any more RTTI to achieve dynamic binding than any other version of the same code?
I don't care who invented the word, I care who invented the concept, and the C++ community has collectively contributed more to the OO concept over the years than just about any other. Hell, Bjarne Stroustrup invented the term C++, and I'm guessing he didn't have today's C++ in mind, either. That doesn't mean today's C++ isn't an improvement on his original vision a couple of decades ago.
Firstly, not everyone agrees that. It's common practice, because we have an alternative (structured programming) that many people prefer.
Secondly, exceptions are a natural complement to functional decomposition and structured programming, and the places where they can be handled are typically very well-defined. To date, no-one's managed to popularise a more effective system for controlling failure in a large application, so that's why we use them.
You're letting what's second nature to you as an experienced programmer cloud your judgement. Having taught several non-programmers some basic C, I can tell you that your explanation above would probably result in something like the following:
Teaching is all about recognising what you understand but somebody else doesn't. The more you understand, the harder that gets, and the more your own preconceptions and ideas get in the way.
You don't know much about either Java or C++, do you? :-)
That's hardly zero effort. And besides, I can write FORTRAN in OCaml if I try hard enough, but it wouldn't give as good a result as using OCaml's own features well.
I love this one. The language that forced everyone to cast for years (with its advocates frequently claiming that templates were just bloat, no less) and where everything derives from Object is type safe, but the language which has provided safer casts, typesafe templates and no universal root type for years isn't?
Well, I don't have nearly your experience, but I've thought along similar lines in the past and explored this idea in some detail.
I think the catch is that, as with so many things, the devil is in the details. Graphical interfaces (in the sense of representing your program as a graph, and displaying it in a non-pure-text format) can be useful for browsing source, as some of the better IDEs demonstrate. However, the decision logic I can represent concisely in ten lines of well-written code would take several screens of pretty graphics to represent if drawn in some sort of tree form.
There are definitely shades of grey here. The concise code is easy to manipulate, and of course text-based languages have some major practical advantages, from portability of the source files to the easy use of macros. On the other hand, that conciseness can hide misunderstandings and bugs that would be immediately apparent in a clearly presented graphical display; they don't call it "code" for nothing! But there is surely a reason the world of mathematics still writes its equations and papers in the same basic format it's used since forever...
But it's really not that simple; that's the point.
Open source may be supported by volunteers, but the people who wrote the CSS software were doing it for money. The companies employing them need to get some return on that investment to be profitable and remain in business. In the capitalist world, which like it or not is where we live, that return comes from licensing revenue, amongst other things.
Yes, this sucks for OSS, but it's not Microsoft's (or anyone else's, for that matter) fault that OSS projects choose to run on a non-financial model that gives them limited resources. Neither is it the court's job to disadvantage Microsoft for the benefit of OSS coders. It costs a significant amount of money to produce and maintain useful documentation for a complex interface, and while the courts might reasonably require Microsoft to make such documentation available at cost in the interests of fair competition, I see no reason they should require Microsoft to pay to produce it and then give it away for free because the open source world haven't found a source of funding to play by the same rules as everyone else in the business.
I realise this is unfortunate for Joe OSS Developer, but there are two sides to every argument, and even big corporations have to be treated reasonably by the courts.
Do you have any evidence to support that, beyond your personal opinion? There are very few things that have been done well by OSS that haven't been done at least as well if not very much better by CSS, even by software written by Microsoft in some cases.
Defending competition in the marketplace will naturally defend consumers, modulo minor bumps in the road. Having the courts set an agenda which promotes a specific product or philosophy, even one as apparently community-centric as OSS, comes with no such guarantees. If the open source approach is as superior a development philosophy as its advocates claim, then it will naturally win in a marketplace guaranteeing fair competition anyway.
I'd give myself at least an 8, and I'd stand by that and justify it in an interview. C++ isn't that complicated, it just requires more than trivial "what I did at the office today" effort to learn what it can really do.
No, he didn't. He introduced a neat idiom in policy classes, and showed some applications of design patterns using that idea. He also did a bit of work on template metaprogramming. While his book is impressive -- certainly I'll take nothing away from him in that regard -- concepts like template metaprogramming aren't rocket science, and have been well discussed among the on-line C++ community for years.
In fact, a great many of the "advanced" ideas in C++ development today are just nicked from what's routine in other languages, particularly where emulating higher-order functions or closures are concerned. Some of the implementation tricks talked about by the experts are neat, but the concepts are nothing radical, and don't require some sort of ueber-guru badge to understand.
Dear Mr Potential Interviewer,
I am a professional software developer. I wrote my first program when I was about five, and my first program for significant money when I was in my early teens. Throughout my time at school I wrote programs for fun. Throughout my time at university, I wrote programs to help me with my work. I have been a full-time professional for around five years, and in two successive jobs, I have been the person my colleagues turned to with tricky technical questions or for a second opinion on a programming book, because I've probably read it already.
Today, I'm 26, and as well as being a full-time developer, I volunteer around 20-30 hours per week helping to run a large club relating to one of my hobbies, I have a long-term girlfriend, and I have several other hobbies besides. I am a geek's geek, in the sense that I enjoy my field and keep abrest of new developments in computing generally and programming specifically. In the past two years, I have learned enough Perl to write reasonably involved scripts at work and a CGI interface to a MySQL database for the club, enough XML/XSLT to overhaul a 50+ page web site almost single-handed in my off hours so that it can be maintained by non-techies, and a fair bit of background on Python and various functional programming languages just for fun.
Unfortunately, there are only 26 hours in my day, and the last time I wrote a program just for fun was several years ago, so I'm afraid I won't be able to accept a job at your firm. Thanks for your time.
Yours sincerely
Someone Who Will Never Work For You
That's the software that might benefit today. But the action isn't protecting specific software, other than incidentally. It's defending the principles of competition and interoperability, which is a far more important goal.
You forgot "if you're Apple or offering OSS-based solutions" on 4.
It's not chump change. It's a small but significant dent, which they've unceremoniously been given in spite of Ballmer's best efforts to talk the authorities down last week.
It's also widely rumoured to be accompanied by (a) a compulsion to ship a version of Windows with Media Player completely stripped out, in order to remove the artificial dominance Microsoft has secured over the multimedia world, and (b) heavy penalty conditions if Microsoft gets up to this stuff again, so lengthy court action can be replaced by abruptly hitting them when they're down. These are, for now, only rumours, since the ruling won't be made public until later this week. However, no-one's jumping up and down denying them, and it's well known that all the European parties and Microsoft have seen that ruling. Draw any conclusions from that you like, or wait to see for sure mid-week.
At any rate, this isn't meant to kill Microsoft. It's meant to make them behave, and to reopen competition in the marketplace for the benefit of the public. In that respect, it seems fairly well judged, assuming the above rumours are reasonably accurate.
Well, I'm typing this on an AMD-based PC running Mozilla, so maybe you have a point.
Then again, Intel and AMD have swapped the lead in the processor race and each has maintained a very significant market share for years, while even Microsoft's main rivals -- probably the big names from the OSS world at this point -- languish with single figures of percent of market share at best, a few niche market exceptions notwithstanding. Maybe the point wasn't so great after all...
Erm... That wasn't funny when this lot said it the other day, and it's still not funny now. Sorry. :-)
And would anybody have researched and discovered those algorithms if they weren't going to be used in a programming context? Computer science is all about what you can do with programs, and without programming, computer science has no application. The two are inseparable, unless you're talking specifically about programming meaning strictly "the action of sitting down at a keyboard and typing a program", but I'm assuming the common usage where programming covers the whole process of producing a program.
Of course not: computer science is the science of programming. Programming itself is an art. ;-)
That's true, up to a point, but the magic of functional languages -- concepts like first-order functions, currying, lazy evaluation, and serious use of recursive algorithms -- are quite a way beyond the simple mathematical definition of a function, and very different to the traditional, imperative perspective on programming languages.
But again, the common usage is very different. In a typical procedural or OO language, you use a linked list as an alternative to an array-like data structure, when you need cheap extension or insertion and/or erasure of elements. It's common to iterate over lists, and you see variations on the theme such as skip lists, but that's about it.
In a functional language, OTOH, lists are frequently the fundamental data structure, rather than the arrays used by imperative or OO languages. The use of recursive algorithms to manipulate the lists, and pattern matching and empty lists, are paramount, and concepts like tail recursion are really important. The whole perspective, the role the lists play and the way they are constructed and manipulated, is very different. There is, or should be, more to a course in data structures and algorithms than just which structures have the best theoretical bounds on efficiency. That's one consideration, but hardly the only one (or even, up to a point, the most important one) in the real world.
Java is a fine language for things it's good at. I just don't think education is one of those things. :-)
TeX.
So a million people trying to sound clever have said. None of them has yet told us "morons" how to do it better, though, have they? And neither have you. Do get back to us when you've got something constructive to offer, though, as I'm sure the morons would love to hear about it.
What an absurd thing to say. If computer science is not about the basics underlying programming (whether that's in a software language or using logic gates or drawing pictures on a piece of paper) then what exactly is it about?
It's a shame you didn't finish that sentence; I was interested in what you were thinking there.
The thing is, you can't learn as much about general practice from one language as another, or indeed from any one language compared to a range of different ones. For example, the use of arrays and indexing is common to many procedural and OO languages, including C, Java, and their friends. The use of lists (in the form head element + tail) and pattern matching is ubiquitous in functional programming, and also supported by some scripting languages. There are few if any lanugages where you'd really learn the implications and pros/cons of both, and these are the two most basic data structures I can think of. A more complex version would be comparing the use of structures+pointers to build data structures in C with the use of conjunctive/disjunctive types and pattern matching in functional languages.
Java is actually a particularly bad example of a teaching language, IMHO. It doesn't really let you get under the hood of either of these two mainstream techniques for defining data strucutures. It's similarly restrictive in other areas: everything is about objects, for example, yet it avoids some of the major OOP issues like multiple inheritance in favour of a much-simplified model. There are plenty of multi-paradigm languages that could have been used instead, or plenty of principally single-paradigm languages that are easier to understand for a beginner or more comprehensive beyond the basics. Java is used because it's trendy, nothing more.
OK, I'll play; for comparison, I'm 26.
I think you touched on something very important there, but didn't pursue it.
The skills and techniques developed by CS very much are applicable to business applications. Everything including your swishy new web service front ends to international business DBs would fall apart without them.
The key is that in the business apps (aka databases) world, only a small number of people need to understand the deep stuff, and as long as the tools they write for others to use are good enough, everybody benefits. Skilled management in software development has always recognised that there is a bell curve of ability, and often the best use of your top people is to write tools for your average (and much more numerous) people.
Again, I think this is a question of perspective. What's yummy to the theoretical/research-minded expert with a strong CS background is probably very different to what's yummy for the guy whose interest lies in producing a good database-based application for his client, and really has no time for the niceties of fine programming technique. In a happy coincidence, these two types of people are both valuable, and their roles are perfect complements.
On that point, I disagree. I've just spent about four months on a project to implement a new feature at work. I spent the first month implementing the new feature, according to clear requirements based on a well-defined goal, and it worked just fine. I spent the next three months clearing up the regression test changes, ultimately going to the very heart of our system and code that has been there for a decade, and ripping it out because it was badly written and contained numerous minor bugs.
Now, those bugs had always been there, they just showed up much more often in the new applications we're giving our software, which happen to be where my new feature is used as well. As a result, my productivity, defined by how much useful functionality I added, was reduced 75%, precisely because I was clearing up the mess of people who didn't try hard enough to maintain a good design and a solid implementation.
This is probably the worst instance of this phenomenon that I've seen in my time as a professional developer, but it's hardly the first time I've seen the effect, and I'm sure it's familiar to any other software developers reading this post. This is the reason there will always be a need for the upper band of programmers; the question, IMHO, is more whether they're best used to clean up and maintain the code we write today, or implementing tools that will allow us to use more powerful code tomorrow.
I think half-preparing someone would be an exceptional achievement for a CS degree. It's all too easy to believe that such a qualification is all it takes to become a programmer, and to misunderstand an academic study of an area to be a replacement for experience of the practical application of that knowledge. This is why hiring a natural hacker is often a better bet than hiring a highly qualified CS grad who's just in it for the money.
Darn, where are my mod points? You deserve (+5, Required Reading For PHBs) for that. :-)
On the other hand, a professional in this field who isn't at least aware of the benefits of both low-level languages and functional programming probably has such a hole in general knowledge of their subject that they'll never be a "truly good programmer". You don't have to use them, any more than you have to be some sort of L337 Hax0r d00d who runs Linux because it's cool. But some awareness and appreciation of the strengths and weaknesses of different tools and approaches is elementary to becoming a competent practitioner of any craft -- not an expert, just competent.
Until we get away from this attitude that writing a basic database front-end in Visual Basic or an eight-week course in Java and OO qualifies you as a competent professional, and get back to the point where the average developer has a basic appreciation of the broader issues in their subject, we will continue to write crappy code, the world will continue to succumb to script-kiddie hacker wannabes, business software will never live up to its promise of boosting efficiency for the real work your company does (whatever that is), and so on. That's what you get for hiring incompetents, and sadly, incompetence has become the norm in our industry.
This is not elitism. It's simply advocacy of learning your subject before practising it, and taking a little pride in your work. Both are terribly old-fashioned values in today's high-tech world, and terribly politically incorrect, but there you go. You wanted to know how to improve things; I'm just telling it as it is.
OK, before we start, let's be clear that you just said all that matters. If you object to anything else, it's nothing but your personal opinion, and if you want things to change, you should be campaigning to update the law, not ranting on Slashdot.
The Web would be nothing but an academic toy without that commercialisation. The use of the technology is evolving quickly, just as any new field does, but that evolution does not give it the right to violate the accepted rules of society. The Internet is nothing special in the eyes of the law, nor should it be. It is simply a new context, which requires clarification or adjustment, not a complete departure from existing norms. Understand this, please.
No, it wasn't. It was designed to promote the generation of content in the interests of society, by recognising that producing good content requires investment, and that by offering reasonable guarantees to the authors in return for that investment you will encourage content generation.
I dislike the fact that the editors accepted the submission under the circumstances, but two wrongs do not a right make. And cut with the "impetus" crap: someone does this pretty much every time there's an interesting article hidden behind a front-end, even when all the front-end asks is a little advertising revenue from you in exchange for showing you their article.