Others have already pointed out how absolutely retarded this is, and have explained how "Brooke's Law" has not in any way been understood.
Large project productivity does not scale linearly with the number of developers working on it.
It's not _just_ communication, either. Large software is complex.
By working, it should work every time, all the the time without knob turning. It's embarrassing that in this area, Windows 95 is superior to Linux in almost every respect.
I'd mod you up if I had points, because I agree so strongly.
Yep; working. Part of the definition of enterprise-quality software.
Yes, open source software absolutely leads to a situation of "race to zero". As goods are commoditized and competitors can only differentiate their products based on price, prices are ultimately driven down.
Of course, some say that if companies continue to innovate, this situation might not be that bad. However, I'm definitely not convinced that people can really make a decent living through working on open source products alone. I don't know anyone that does.
Anyone who says they learned C++ in a fortnight is lying.
A fun read: http://yosefk.com/c++fqa/index.html. Mentioned are points (some subtle, some not) which illustrate dark corners of the language and some of its complexities.
The other side of this coin is: C++ shouldn't be left off the list but rather all facets of it explored (covering a fair number of the bases you listed). For instance, you could leave Java/Ada/C# out of the discussion if you restricted yourself single-inheritance and to using C++ in a 'pure o-o' kind of way (i.e., no free funcs).
I would still leave Java or C# on the list. I would consider familiarity with more mainstream garbage-collected languages that run on virtual platforms (JVM/.NET) an important piece of the puzzle.
Actually, the language itself does support functional programming via function pointers. All the libraries do is make the syntax a little more bearable.
Functional is as much a style as a 'paradigm'. It can be practised in a great many languages (even C and ASM if you so desire).
Yes, C++ provides the ability to program with higher order functions, as you mention. This certainly allows adoption of some functional programming style when writing C++ programs.
C++ does not provide first class functions, which real functional programming languages do.
I'd consider the minimum for a really good programmer to include at least a project or two's worth of exposure to:
At least one assembly language or pseudo-asm.
At least one mid-level pointer-driven language (C/C++/etc)
At least one statically typed functional language (ML/Haskell/etc)
At least one dynamically typed functional language (Lisp/Scheme/etc)
At least one dynamically typed OO language (Smalltalk/Python/ruby/etc)
At least one higher-level statically typed OO language (Java/Ada/C#/etc)
I concur!
I think an interesting result of spending project-amounts of time with languages spanning these categories is that learning the quirks, styles, idioms, strengths, and weaknesses of one language typically enables a person to program more effectively in languages they already knew. At least, in my experience, I've learned to approach some tasks in different and better ways in language X because of my exposure to how the task might be accomplished with language Y.
I'm sure I'm missing some areas, too.
I think you've hit the important categories spot on.
While not earth-shattering for brain food, a practicing programmer will probably want to pick up some shell language (bash, whatever) to enable themselves to use a shell productively. Hand-in-hand with that could also include a dose of regular expressions and using them with tools like grep/sed/awk (regex will also come in handy with the various libraries/implementations provided by all languages).
Although, as far as introductory material, I personally learned it all from java.sun.com. Although I can't vouch for whether this is an applied approach or not, I would suggest the concurrency tutorial and a good book on Java Patterns or even a design pattern wiki.
I can vouch that this is definitely an effective applied approach. I learned much the same way, developing a solid understanding of the Java threading and memory model, and this has allowed me to pick up other particular thread implementations (pthreads, Linux concurrency primitives, other OS concurrency models, etc.) very easily on the job. Thankfully Java does a great job of formally specifying the threading and memory model, so you have a solid foundation upon which to build.
Plus, there's nothing more fun than being able to do a "kill -3" on your Java process to get a thread-by-thread stackdump of where everything is at. That makes diagnosing some forms of deadlock absolutely trivial. I've done that on the job, too.
Most important rule of thumb of multi-threaded programming is to avoid it if possible. Maybe hardware (multi-core) will change that, maybe you feel the scheduler can't do its job as well as you can and maybe you feel it's more intuitive. But, often is the case, that you're just adding more complexity to your code resulting in more difficult bugs and harder maintenance for others. Keep it simple.
I agree with avoiding threading if you don't need it, but I implore all programmers to not think of multi-threading as a mysterious force only suited to experts. You can develop a mastery of the subject, and it will help you in many areas.
I read those pages, and I've already been aware of Microsoft not playing nice with other standards. But, to my knowledge they have not infiltrated and actually harmed the technical specification of anything, ever.
Now, if a heavy-weight player like Microsoft chooses not to implement ODF, could that negatively effect ODF's adoption? Sure. But in that case Microsoft would not have ruined the ODF standard itself. The technical specification would still be as (good/bad/great/whatever as) it is today.
I'm curious if Microsoft has been involved in defining the specification of an open standard, and if that involvement has led to the specification's downfall. To my knowledge this has never happened. Past events (the Java embarassment, heck, OOXML itself) have shown that Microsoft is more likely to try to fork off their own-grown version of something that isn't quite the same. Note that Microsoft paid for trying to fuck with Sun's Java. I don't believe they'll try to directly pull the same stunt with ODF ("implement" it incorrectly but try to advertise it otherwise).
Those quick to decry Microsoft's involvement with ODF (and I'm not saying you are one of these people) have, thus far, failed to provide critical analysis of the situation, and have failed to recognize it as a new and unique situation. I believe this event isn't 100% like what we've seen from Microsoft in the past. I still stand behind my insane optimistic hope that the open standards process behind ODF will prevail, and prevent the Microsoft Empire from being able to destroy it.
>For my edification, have there been any other open standards in the past with which Microsoft has associated itself, only to "ruin things"? (It seems as though this is the concern for ODF).
HTML?
You didn't provide any reference or links. I'm fully aware of IE's brokenness. This has not directly "ruined HTML", though. They've just not implemented W3C recommendations.
The point is, Microsoft is not going to "ruin ODF", as far as the technical specification itself goes. Could Microsoft reduce the effectiveness of ODF by not implementing it? Sure, but they've not done anything to actually harm the technical specification.
Does optimism include ignoring past history and evidence?
In my case, no. I'm not ignoring any history of which I'm aware.
However, I don't claim to be aware of everything.
For my edification, have there been any other open standards in the past with which Microsoft has associated itself, only to "ruin things"? (It seems as though this is the concern for ODF).
I'm genuinely interested, but just unaware of any past precedent. I'd definitely appreciate any links or references discussing similar situations in the past.
The question now is, what can the open source community do to prevent another OOXML-type situation?
Exactly!
We have a situation where Microsoft is, for better or worse, attempting to participate in the open standards game. Will the fact that ODF is an open standard fundamentally reduce Microsoft's leverage?
I'll conjecture that the open process will prevail. I'm an optimist, though...
This is a good thing. Microsoft has publicly shown that they have accepted the failure of OOXML, and are now attempting to participate (for better, or for worse) in ODF.
Those that cry "Microsoft is taking over!" -- remember how touted the "open-ness" of the process for ODF has been in the past, and how the contrast of that open process versus the less-open ECMA process has been attempted to be used as one of the many criticisms of the OOXML debacle.
Now the important question is, can an open standard like ODF prevail in face of the juggernaut Microsoft?
All that said, I don't consider the syntax of Haskel very good, lack of parenthesis around function arguments certainly doesn't help readability and the error messages can be rather obscure as well.
Syntax is absolutely irrelevant.
As for parentheses and function application, there is a reason for that. Read about Currying.
It's not a Windows problem, per se; the fact that it installs malware on Windows computers is functionally irrelevant.
I don't use Windows, thus I couldn't be affected by this particular crap at all. It is a Windows problem.
Now, the issue of ignorant users is also a problem; but don't let Windows off the hook.
The summary states, "Depending on your view this ranges from a harmless 'feature' to a rather serious privacy violation."
There is no view, this is absolutely an outright product of incompetence, oversight, and cluelessness. This is definitely a bug, even if Google touts it as a feature. We've seen this before, with Google calendar appointments/conference call numbers made publicy accessible via incompetence.
The problem is professors who REQUIRE class attendance even if you fully understand the material....
If I'm forced to be there even though I don't need to be, I'm going to sit in the back and either surf the web or do homework on my laptop. Why should my time go to waste?
This is a valid point -- at least you're in the back of the class, though, and not in the front, possibly distracting.
I should have emphasized that people that distract with laptops or actively detract from class discussions (zombies not paying attention and just not participating) are the assholes.
Those that sit and surf the net while in class are complete assholes. Don't bother coming to class if you're not going to productively participate in lecture or if you're just going to distract others that can see your screen.
Not to mention that it's also just blatantly, obliviously, and childishly rude to the lecturer.
The same things go for talking on your cell phone in confined spaces.
Slashdot Mirror
Others have already pointed out how absolutely retarded this is, and have explained how "Brooke's Law" has not in any way been understood.
Large project productivity does not scale linearly with the number of developers working on it.
It's not _just_ communication, either. Large software is complex.
The capital 'W' makes skins crawl and is reserved for the stock ticker.
By working, it should work every time, all the the time without knob turning. It's embarrassing that in this area, Windows 95 is superior to Linux in almost every respect.
I'd mod you up if I had points, because I agree so strongly.
Yep; working. Part of the definition of enterprise-quality software.
Yes, open source software absolutely leads to a situation of "race to zero". As goods are commoditized and competitors can only differentiate their products based on price, prices are ultimately driven down.
Of course, some say that if companies continue to innovate, this situation might not be that bad. However, I'm definitely not convinced that people can really make a decent living through working on open source products alone. I don't know anyone that does.
Anyone who says they learned C++ in a fortnight is lying.
A fun read: http://yosefk.com/c++fqa/index.html. Mentioned are points (some subtle, some not) which illustrate dark corners of the language and some of its complexities.
The other side of this coin is: C++ shouldn't be left off the list but rather all facets of it explored (covering a fair number of the bases you listed). For instance, you could leave Java/Ada/C# out of the discussion if you restricted yourself single-inheritance and to using C++ in a 'pure o-o' kind of way (i.e., no free funcs).
I would still leave Java or C# on the list. I would consider familiarity with more mainstream garbage-collected languages that run on virtual platforms (JVM/.NET) an important piece of the puzzle.
Actually, the language itself does support functional programming via function pointers. All the libraries do is make the syntax a little more bearable. Functional is as much a style as a 'paradigm'. It can be practised in a great many languages (even C and ASM if you so desire).
Yes, C++ provides the ability to program with higher order functions, as you mention. This certainly allows adoption of some functional programming style when writing C++ programs.
C++ does not provide first class functions, which real functional programming languages do.
I'd consider the minimum for a really good programmer to include at least a project or two's worth of exposure to:
At least one assembly language or pseudo-asm. At least one mid-level pointer-driven language (C/C++/etc) At least one statically typed functional language (ML/Haskell/etc) At least one dynamically typed functional language (Lisp/Scheme/etc) At least one dynamically typed OO language (Smalltalk/Python/ruby/etc) At least one higher-level statically typed OO language (Java/Ada/C#/etc)
I concur!
I think an interesting result of spending project-amounts of time with languages spanning these categories is that learning the quirks, styles, idioms, strengths, and weaknesses of one language typically enables a person to program more effectively in languages they already knew. At least, in my experience, I've learned to approach some tasks in different and better ways in language X because of my exposure to how the task might be accomplished with language Y.
I'm sure I'm missing some areas, too.
I think you've hit the important categories spot on.
While not earth-shattering for brain food, a practicing programmer will probably want to pick up some shell language (bash, whatever) to enable themselves to use a shell productively. Hand-in-hand with that could also include a dose of regular expressions and using them with tools like grep/sed/awk (regex will also come in handy with the various libraries/implementations provided by all languages).
The submitter is a fucking dumbass. D came from Digital Mars, not Microsoft.
Although, as far as introductory material, I personally learned it all from java.sun.com. Although I can't vouch for whether this is an applied approach or not, I would suggest the concurrency tutorial and a good book on Java Patterns or even a design pattern wiki.
I can vouch that this is definitely an effective applied approach. I learned much the same way, developing a solid understanding of the Java threading and memory model, and this has allowed me to pick up other particular thread implementations (pthreads, Linux concurrency primitives, other OS concurrency models, etc.) very easily on the job. Thankfully Java does a great job of formally specifying the threading and memory model, so you have a solid foundation upon which to build.
Plus, there's nothing more fun than being able to do a "kill -3" on your Java process to get a thread-by-thread stackdump of where everything is at. That makes diagnosing some forms of deadlock absolutely trivial. I've done that on the job, too.
Most important rule of thumb of multi-threaded programming is to avoid it if possible. Maybe hardware (multi-core) will change that, maybe you feel the scheduler can't do its job as well as you can and maybe you feel it's more intuitive. But, often is the case, that you're just adding more complexity to your code resulting in more difficult bugs and harder maintenance for others. Keep it simple.
I agree with avoiding threading if you don't need it, but I implore all programmers to not think of multi-threading as a mysterious force only suited to experts. You can develop a mastery of the subject, and it will help you in many areas.
Great book. (sorry I don't have mod points today, else I'd mod this up).
I read those pages, and I've already been aware of Microsoft not playing nice with other standards. But, to my knowledge they have not infiltrated and actually harmed the technical specification of anything, ever.
Now, if a heavy-weight player like Microsoft chooses not to implement ODF, could that negatively effect ODF's adoption? Sure. But in that case Microsoft would not have ruined the ODF standard itself. The technical specification would still be as (good/bad/great/whatever as) it is today.
I'm curious if Microsoft has been involved in defining the specification of an open standard, and if that involvement has led to the specification's downfall. To my knowledge this has never happened. Past events (the Java embarassment, heck, OOXML itself) have shown that Microsoft is more likely to try to fork off their own-grown version of something that isn't quite the same. Note that Microsoft paid for trying to fuck with Sun's Java. I don't believe they'll try to directly pull the same stunt with ODF ("implement" it incorrectly but try to advertise it otherwise).
Those quick to decry Microsoft's involvement with ODF (and I'm not saying you are one of these people) have, thus far, failed to provide critical analysis of the situation, and have failed to recognize it as a new and unique situation. I believe this event isn't 100% like what we've seen from Microsoft in the past. I still stand behind my insane optimistic hope that the open standards process behind ODF will prevail, and prevent the Microsoft Empire from being able to destroy it.
>For my edification, have there been any other open standards in the past with which Microsoft has associated itself, only to "ruin things"? (It seems as though this is the concern for ODF).
HTML?
You didn't provide any reference or links. I'm fully aware of IE's brokenness. This has not directly "ruined HTML", though. They've just not implemented W3C recommendations.
The point is, Microsoft is not going to "ruin ODF", as far as the technical specification itself goes. Could Microsoft reduce the effectiveness of ODF by not implementing it? Sure, but they've not done anything to actually harm the technical specification.
ODF is safe, for the time being.
Does optimism include ignoring past history and evidence?
In my case, no. I'm not ignoring any history of which I'm aware.
However, I don't claim to be aware of everything.
For my edification, have there been any other open standards in the past with which Microsoft has associated itself, only to "ruin things"? (It seems as though this is the concern for ODF).
I'm genuinely interested, but just unaware of any past precedent. I'd definitely appreciate any links or references discussing similar situations in the past.
The question now is, what can the open source community do to prevent another OOXML-type situation?
Exactly!
We have a situation where Microsoft is, for better or worse, attempting to participate in the open standards game. Will the fact that ODF is an open standard fundamentally reduce Microsoft's leverage?
I'll conjecture that the open process will prevail. I'm an optimist, though...
This is a good thing. Microsoft has publicly shown that they have accepted the failure of OOXML, and are now attempting to participate (for better, or for worse) in ODF.
Those that cry "Microsoft is taking over!" -- remember how touted the "open-ness" of the process for ODF has been in the past, and how the contrast of that open process versus the less-open ECMA process has been attempted to be used as one of the many criticisms of the OOXML debacle.
Now the important question is, can an open standard like ODF prevail in face of the juggernaut Microsoft?
I think so. I'm an optimist.
This is pretty cool -- it is definitely a testament to the effect of the open source movement.
Because I've given up on all the dual APIs with Gtk/Qt/Wx/GNUStep. I don't care anymore. Life is to short. Code with what works today.
I share your sentiment. I might actually tweak it by saying "Code with what works today and is likely to keep working tomorrow".
Read what Ulrich Drepper thinks of the LSB here: http://udrepper.livejournal.com/8511.html.
All that said, I don't consider the syntax of Haskel very good, lack of parenthesis around function arguments certainly doesn't help readability and the error messages can be rather obscure as well.
Syntax is absolutely irrelevant.
As for parentheses and function application, there is a reason for that. Read about Currying.
It's not a Windows problem, per se; the fact that it installs malware on Windows computers is functionally irrelevant.
I don't use Windows, thus I couldn't be affected by this particular crap at all. It is a Windows problem. Now, the issue of ignorant users is also a problem; but don't let Windows off the hook.
The summary states, "Depending on your view this ranges from a harmless 'feature' to a rather serious privacy violation."
There is no view, this is absolutely an outright product of incompetence, oversight, and cluelessness. This is definitely a bug, even if Google touts it as a feature. We've seen this before, with Google calendar appointments/conference call numbers made publicy accessible via incompetence.
Inexcusable.
This is a valid point -- at least you're in the back of the class, though, and not in the front, possibly distracting.
I should have emphasized that people that distract with laptops or actively detract from class discussions (zombies not paying attention and just not participating) are the assholes.
Mod parent up!
Those that sit and surf the net while in class are complete assholes. Don't bother coming to class if you're not going to productively participate in lecture or if you're just going to distract others that can see your screen.
Not to mention that it's also just blatantly, obliviously, and childishly rude to the lecturer.
The same things go for talking on your cell phone in confined spaces.
I did.