The original article, and most of the posts here, can be used to illustrate another important issue: if one makes snap judgments based on partial information, it is easy to be misled. Following the links all the way to http://voices.washingtonpost.com/securityfix/Decision%202008.12.03.pdf (the judge's decision) reveals that the plaintiff failed to achieve a satisfactory rating during student teaching, which contributed to her not getting a teaching certificate. Snyder and Mayer-Schoenberger failed to include that inconvenient fact.
Perhaps before jumping into a stranger's fight (or, in this case, flaming about narrow-minded opposition to free speech), we should take the time to learn more of the facts.
...between humor and malicious behavior. We don't excuse a schoolyard bully if he claims, "I was just having fun." Neither should we ignore malicious false statements merely because someone claims, "I was just doing a parody."
Accusations against teachers and principles of sexual misconduct against their students are typically taken very seriously (with good reason). So how is a student who makes such statements, apparently in retaliation for being disciplined at school, that different from a student who retaliates by pulling a fire alarm?
Meaning no disrespect to Lisp (I actually own a copy of the Lisp 1.5 Programmer's Manual), I was dating functional programming from John Backus's Turing Award Lecture of 1977, rather than from its Lisp heritage. I did so for two reasons:
1) Backus was specifically presenting FP as an alternative to imperative programming, highlighting the paradigm/style contrast that is currently relevant. His work certainly drew on predecessors, but his notation and algebraic style of reasoning bear (to my eye) a much stronger resemblance to modern FP languages than either of those do to Lisp.
2) Lisp can certainly be used in a functional way, but from the beginning also contained imperative-style features in the name of efficiency. In his Turing award lecture, Backus seems to have deliberately opted for expressiveness and purity over compromise, again a modern FP issue.
However, I think we'd agree that the roots of functional programing go back further than either McCarty or Backus (e.g. Frege, Curry, Howard, etc.), and the point remains that the Old Ones figured out things we still don't use in mainstream programming.
There are many dynamics in (American) programming; some are real problems, and some are changes that the "old guard" finds uncomfortable. Nobody here (including me) wants to read a 30-minute rant, so let me just mention a few high spots.
There are forces in almost every industry that seek to dumb down the role of the worker so that jobs can be commoditized or outsourced.
Any institution that caters to the forces of #1 is acting like a trade school offering training, rather than a university offering education.
There are many fine companies and schools that do not cave in to the forces of #1.
No curriculum that teaches just one language will produce well-rounded programmers, regardless of what that language is. Any well-rounded programmer knows multiple languages, and is capable of learning more.
The decline in mathematical competence of American college students has been widely discussed. Nobody with his head on straight believes that Java (or any other programming language) caused it. (The same can be said of grammatical competence.)
Overemphasis on GUI toys is a fault of the curriculum and/or the teacher, not of the language. On the planet where I live, Java is more likely to be found on the server than in the browser.
It is possible to have a long, productive career as a programmer without ever writing an operating system, or picking up a soldering iron.
It is possible to learn a great deal about the foundations of programming by writing an operating system, or picking up a soldering iron.
Conclusion from #7 and #8: there's more than one way to do IT.
Anybody who thinks that application servers, messaging middleware, and compilers are not "systems programming" is still living in the 1960's. Nobody who knows the current industrial software world can be ignorant of the fact that Java is one of the languages in which these are being written. It is also not the only one (see #4 and #9).
There are also the traditional inter-generational conflicts:
Every generation laments the fact that the following generations don't have to do/learn things "the hard way, like we did". Cars no longer require hand-cranking, manual choke, manual spark advance, or manual transmissions. Today's automotive technology makes it possible to be a good driver without knowing how to use any one of those bits of historical infrastructure. (It also means that we are more dependent on professional mechanics when our cars break down!;-) Modern type-safe languages allow very sophisticated programs to be written without ever directly manipulating a memory address masquerading as a "pointer".
Every generation runs the risk of losing important lessons learned the hard way by preceding generations. Merely playing video games doesn't prepare one for a career in a high-tech world (as if anybody thought it would!;-). How many Viet Nam wars or Great Depressions do we need before we learn to do better? ("How many roads must a man walk down before you can call him a man?") OO is about 45 years old (going back to Simula in the early 1960s). Functional programming is about 30 years old (going back to the mid 1970s). Our industry hasn't yet fully learned how to do either one correctly.
Progress is made by human beings, not by tools.
Or, as Shakespeare might have put it: "The fault, dear Brutus, is not in our programming languages, but in ourselves..." Julius Caesar (I, ii, 140-141), 2008 edition
I believe that the language quoted is typical of statisticians talking about the data (think "graph") rather than the underlying observed system. In other words, I believe one should read it as short-hand for
The segment of the sample which downloads X + 1 times per month was observed to purchase 0.44 CDs per year more than the segment of the sample which downloads X times per month.
I believe that professional statisticians and researchers understand the difference between describing 'the effect" of moving around on the graph of results (correlation) versus claiming cause and effect in the underlying system.
However, quibbling over statistician-speak is irrelevant to the key point that people who were observed to download more music were also observed to buy more CDs. This result drives a stake in the heart of the RIAA argument that people download music instead of purchasing CDs.
that the digital download service was undermining the ability of traditional media companies to set profitable rates for their content online
but unfortunately (for him and his ilk), he's fighting against both the inevitability of technological change and the just rewards (poetic justice, karma, payback, what-goes-around-comes-around,... choose your favorite term) of his own example.
As an amateur calligrapher with family members who are performers, I can confidently assert that:
the invention of the printing press undermined the ability of traditional scribes to set profitable rates for their content (handwritten books);
the automobile industry undermined the ability of traditional blacksmiths to set profitable rates for their content (horseshoes);
the recording industry undermined the ability of traditional (community-based) musicians to set profitable rates for their content;
television networks (undoubtedly obsessed with the profit margins of cheap "reality" shows) are undermining the ability of traditional actors and musicians to set profitable rates for their content (performances).
Let's see NBC sharing a cut of their profits with a health insurance fund for performers. Then maybe I'll start listening to anything he has to say about being on the receiving end of a revenue-sharing proposal. Maybe.
You seem to be making the common mistake of confusing numerical analysis with Mathematics.
Regardless of the application area for your program, when you rewrite something like:
if (!(a && b && c)) {...}
into:
if (!a || !b || !c) {...}
you're using Mathematics (DeMorgan's Law from Boolean Algebra, to be precise). It's hard to imagine a competent programmer writing code for ANY purpose who wouldn't understand the relationships between the two fragments above.
Mathematics (although usually the non-numerical flavor) is fundamental to programming.
The term itself is a product of the academic environment, similar to the equally dubious "Library Science" and "Management Science". For what it's worth, the European term "informatics" would have been better, but never caught on.
That said, I believe there's a useful set of relationships well understood in other fields:
Science = The search for fundamental knowledge and predictive models; Engineering = The creative application of the results of science; Technology = The routine application of the results of engineering.
giving us, for example:
Science: Physics Engineering: Electrical engineering Technology: TV Repair, Cable TV Installation
The punch line is that application of this model to computing works as follows:
Science: Mathematics Engineering: Programming, Informatics, "Computer Science" Technology: Coding, Computer Installation, Home Computer Repair, etc.
Mathematics IS the science in "Computer Science".
Anyone who has studied advanced Mathematics knows that Math is not about numbers; think of mathematical logic, Boolean algebra, abstract algebra, set theory, topology, category theory, etc. ad infinitum. Dijkstra defined Mathematics as "the art of precise reasoning". In the same sense, "computation" doesn't mean "number crunching", but more generally the automated manipulation of information.
It is true that there are legitimate concerns in today's computational landscape (networking, concurrency, etc.) which didn't figure in the mathematical/engineering world view of the 1940s, but that's simply a sign that the field has grown up (i.e. grown beyond the limited perspectives of its founders). That's also true in many other applications of Mathematics. For example, early research in differential equations paid much more attention to linear differential equations (because they were more tractable). However, we now know that most "interesting" systems in the real world involve non-linearity.
Science, Engineering, and Technology share with living systems an important rule: "Grow or die!" Fortunately, the field of computing has grown.
Look at it another way; that "essentially half a days [sic] work" is all that the voice talent gets for the entire release. By way of contrast, how much do you suppose each person in marketing earned for the release? Which one contributed more to the enjoyment of the typical consumer of the game, the voice talent or the marketing person? Even at minimum wage (not likely!) the back-room employees would have individually earned far more than the voice talent.
From a different perspective, it's reasonable to assume that most of the developers, sales, marketing, accounting, and even the office staff, probably had full-time employment throughout the development of the release. Compare that to a half-day's work for the voice talent. (And there probably wasn't another opportunity waiting to fill the other half of that day!)
The only point is that if we want a world in which people can contribute their various talents and skills to the making of products that people want to buy, it is necessary for each of the contributors to be able to live on what they make.
Others have already remarked on the competitive advantage in sales of a well-designed UI. You could also look at the other side of the ledger.
If your company is involved with product support, take the support call logs and identify specific examples of how the design of previous products could have been done in a way to reduce or eliminate the problems people call about.
If you have access to the codebase (or to friendly developers), take a look at how much wheel-reinventing happens on successive projects, as opposed to user-interface code/concept reuse based on consistent UI design principles.
Both of those will frame the argument in terms of cost savings, one long-term and one short-term.
If none of these arguments are relevant to your company -- no end-user market (resellers or in-house apps are your company's revenue stream), no end-user support, no stable development codebase, no interest in long-term development process enhancement -- then I agree with the earlier poster who advocated spending the effort on dusting off your resume.
There's much more to concurrency in Java (especially Java 5) than simple target-object synchronization. (For example, you can set up queues to pass safely from one thread to another.)
You might also want to look at some other frameworks that have been created in Java, such as CSP, covered in a series of DeveloperWorks articles beginning with:
The use of unconstrained pointers and casting (don't forget that in C this includes arrays!), combined with allocation of local data in the same stack that contains state information (registers to be restored upon function return) is at the heart of a large portion (most?) of the common security vulnerabilities on PCs.
Some large-ish number of years ago I saw an article in which the author (don't recall the name offhand, sorry) asserted that raw pointers were the data equivalent of GOTOs. Both are potentially useful as under-the-hood implementation mechanisms, but entirely too easy to abuse for them to be exposed in a high-level-language.
From a description of one of the sessions (names changed to protect... somebody):
... it is often the case that developers expect a core technology to provide one security assertion, when in fact it provides a whole set of unrelated assertions. X and Y have found that many security flaws... are the result of a fundamental misunderstanding of a core security technology.
This talk covered the security technologies in Windows that...[are]... almost without exception, misused.... X and Y discussed how to find out if your application is making silly security assumptions or whether you have truly mitigated risks against it.
So, security is the responsibility of the application? Does anybody remember the old song: "I beg your pardon! I never promised you a rose garden!" Or is there a new winner of the Not My Job award ( http://www.nickh.org/pix/notmyjob.jpg ) this year?
Ah, yes, the wonderful "innovation" of the object bench! Of course, that's "innovation" in the classic sense of "take somebody else's idea and resell it without credit or payment". See http://www.bluej.org/vs/vs-bj.html for the real story.
When I played the frequency-shifted (human audio range) versions on my laptop, our cat came running into the room, looking around frantically. Apparently his directional detection for high-frequencies isn't much better than mine...
Please re-examine the chart; Simula is a direct descendent of ALGOL-60 which was strongly typed. That's why block-structured, typed languages were referred to for years as "ALGOL-like languages". (I can't speak from personal knowledge regarding ALGOL-58/IAL, but I believe it was never actually implemented, thus making ALGOL-60 arguably the first strongly typed language in that part of the family tree.)
Slashdot Mirror
The original article, and most of the posts here, can be used to illustrate another important issue: if one makes snap judgments based on partial information, it is easy to be misled. Following the links all the way to http://voices.washingtonpost.com/securityfix/Decision%202008.12.03.pdf (the judge's decision) reveals that the plaintiff failed to achieve a satisfactory rating during student teaching, which contributed to her not getting a teaching certificate. Snyder and Mayer-Schoenberger failed to include that inconvenient fact.
Perhaps before jumping into a stranger's fight (or, in this case, flaming about narrow-minded opposition to free speech), we should take the time to learn more of the facts.
...between humor and malicious behavior. We don't excuse a schoolyard bully if he claims, "I was just having fun." Neither should we ignore malicious false statements merely because someone claims, "I was just doing a parody."
Accusations against teachers and principles of sexual misconduct against their students are typically taken very seriously (with good reason). So how is a student who makes such statements, apparently in retaliation for being disciplined at school, that different from a student who retaliates by pulling a fire alarm?
...abounds, under the name of Planned Obsolescence! How could any patent examiner with at least a high-school education fail to know that?
PS: Before marking something "redundant", look at the timestamps to see which entry came first!
Bing?
Under the scheme proposed by the parent, MegaCorp could easily outbid J. Random Inventor for his own ideas.
DIARY = DYslexic RecursIve Acronym
Meaning no disrespect to Lisp (I actually own a copy of the Lisp 1.5 Programmer's Manual), I was dating functional programming from John Backus's Turing Award Lecture of 1977, rather than from its Lisp heritage. I did so for two reasons:
1) Backus was specifically presenting FP as an alternative to imperative programming, highlighting the paradigm/style contrast that is currently relevant. His work certainly drew on predecessors, but his notation and algebraic style of reasoning bear (to my eye) a much stronger resemblance to modern FP languages than either of those do to Lisp.
2) Lisp can certainly be used in a functional way, but from the beginning also contained imperative-style features in the name of efficiency. In his Turing award lecture, Backus seems to have deliberately opted for expressiveness and purity over compromise, again a modern FP issue.
However, I think we'd agree that the roots of functional programing go back further than either McCarty or Backus (e.g. Frege, Curry, Howard, etc.), and the point remains that the Old Ones figured out things we still don't use in mainstream programming.
There are many dynamics in (American) programming; some are real problems, and some are changes that the "old guard" finds uncomfortable. Nobody here (including me) wants to read a 30-minute rant, so let me just mention a few high spots.
There are also the traditional inter-generational conflicts:
Progress is made by human beings, not by tools.
Or, as Shakespeare might have put it: "The fault, dear Brutus, is not in our programming languages, but in ourselves..." Julius Caesar (I, ii, 140-141), 2008 edition
s/normal/short-attention-span/g
s/english/american/g
Sufficiently terse?
A certain large company from R*dm*nd is feuding with another company, and security has become an issue?
The X-Files writers could NEVER have dreamed that one up!
-jn-
I believe that the language quoted is typical of statisticians talking about the data (think "graph") rather than the underlying observed system. In other words, I believe one should read it as short-hand for
I believe that professional statisticians and researchers understand the difference between describing 'the effect" of moving around on the graph of results (correlation) versus claiming cause and effect in the underlying system.
However, quibbling over statistician-speak is irrelevant to the key point that people who were observed to download more music were also observed to buy more CDs. This result drives a stake in the heart of the RIAA argument that people download music instead of purchasing CDs.
Zucker whines
but unfortunately (for him and his ilk), he's fighting against both the inevitability of technological change and the just rewards (poetic justice, karma, payback, what-goes-around-comes-around,
As an amateur calligrapher with family members who are performers, I can confidently assert that:
Let's see NBC sharing a cut of their profits with a health insurance fund for performers. Then maybe I'll start listening to anything he has to say about being on the receiving end of a revenue-sharing proposal. Maybe.
Regardless of the application area for your program, when you rewrite something like:
into:
you're using Mathematics (DeMorgan's Law from Boolean Algebra, to be precise). It's hard to imagine a competent programmer writing code for ANY purpose who wouldn't understand the relationships between the two fragments above.
Mathematics (although usually the non-numerical flavor) is fundamental to programming.
The term itself is a product of the academic environment, similar to the equally dubious "Library Science" and "Management Science". For what it's worth, the European term "informatics" would have been better, but never caught on.
That said, I believe there's a useful set of relationships well understood in other fields:
Science = The search for fundamental knowledge and predictive models;
Engineering = The creative application of the results of science;
Technology = The routine application of the results of engineering.
giving us, for example:
Science: Physics
Engineering: Electrical engineering
Technology: TV Repair, Cable TV Installation
The punch line is that application of this model to computing works as follows:
Science: Mathematics
Engineering: Programming, Informatics, "Computer Science"
Technology: Coding, Computer Installation, Home Computer Repair, etc.
Mathematics IS the science in "Computer Science".
Anyone who has studied advanced Mathematics knows that Math is not about numbers; think of mathematical logic, Boolean algebra, abstract algebra, set theory, topology, category theory, etc. ad infinitum. Dijkstra defined Mathematics as "the art of precise reasoning". In the same sense, "computation" doesn't mean "number crunching", but more generally the automated manipulation of information.
It is true that there are legitimate concerns in today's computational landscape (networking, concurrency, etc.) which didn't figure in the mathematical/engineering world view of the 1940s, but that's simply a sign that the field has grown up (i.e. grown beyond the limited perspectives of its founders). That's also true in many other applications of Mathematics. For example, early research in differential equations paid much more attention to linear differential equations (because they were more tractable). However, we now know that most "interesting" systems in the real world involve non-linearity.
Science, Engineering, and Technology share with living systems an important rule: "Grow or die!" Fortunately, the field of computing has grown.
Read any good book on professional typography, such as The Elements of Typographic Style by Robert Bringhurst.
;-)
The 'Net is no longer in high school typing class.
Look at it another way; that "essentially half a days [sic] work" is all that the voice talent gets for the entire release . By way of contrast, how much do you suppose each person in marketing earned for the release? Which one contributed more to the enjoyment of the typical consumer of the game, the voice talent or the marketing person? Even at minimum wage (not likely!) the back-room employees would have individually earned far more than the voice talent. From a different perspective, it's reasonable to assume that most of the developers, sales, marketing, accounting, and even the office staff, probably had full-time employment throughout the development of the release. Compare that to a half-day's work for the voice talent. (And there probably wasn't another opportunity waiting to fill the other half of that day!) The only point is that if we want a world in which people can contribute their various talents and skills to the making of products that people want to buy, it is necessary for each of the contributors to be able to live on what they make.
Others have already remarked on the competitive advantage in sales of a well-designed UI. You could also look at the other side of the ledger.
If your company is involved with product support, take the support call logs and identify specific examples of how the design of previous products could have been done in a way to reduce or eliminate the problems people call about.
If you have access to the codebase (or to friendly developers), take a look at how much wheel-reinventing happens on successive projects, as opposed to user-interface code/concept reuse based on consistent UI design principles.
Both of those will frame the argument in terms of cost savings, one long-term and one short-term.
If none of these arguments are relevant to your company -- no end-user market (resellers or in-house apps are your company's revenue stream), no end-user support, no stable development codebase, no interest in long-term development process enhancement -- then I agree with the earlier poster who advocated spending the effort on dusting off your resume.
There's another understanding of this scene:
Peter says, "You're the Messiah, God's Son."
Jesus says, "You're Peter."
Jesus built his church on the bedrock that God and human came face to face and each recognized the other for who he was.
Take a look at java.util.concurrent (as another response has suggested). Specifically, look at:
2 SE/concurrency/index.html
e ncy/overview.html
y /j-csp1.html
;-).
"Concurrent Programming with J2SE 5.0"
http://java.sun.com/developer/technicalArticles/J
and
"Concurrency Utilities Overview"
http://java.sun.com/j2se/1.5.0/docs/guide/concurr
There's much more to concurrency in Java (especially Java 5) than simple target-object synchronization. (For example, you can set up queues to pass safely from one thread to another.)
You might also want to look at some other frameworks that have been created in Java, such as CSP, covered in a series of DeveloperWorks articles beginning with:
"CSP for Java programmers, Part 1"
http://www-128.ibm.com/developerworks/java/librar
There's a lot out there to let you think in much higher-level concepts than simple locks (although you can do that to, for the learning exercise
The use of unconstrained pointers and casting (don't forget that in C this includes arrays!), combined with allocation of local data in the same stack that contains state information (registers to be restored upon function return) is at the heart of a large portion (most?) of the common security vulnerabilities on PCs.
Some large-ish number of years ago I saw an article in which the author (don't recall the name offhand, sorry) asserted that raw pointers were the data equivalent of GOTOs. Both are potentially useful as under-the-hood implementation mechanisms, but entirely too easy to abuse for them to be exposed in a high-level-language.
From a description of one of the sessions (names changed to protect... somebody):
... it is often the case that developers expect a core technology to provide one security assertion, when in fact it provides a whole set of unrelated assertions. X and Y have found that many security flaws ... are the result of a fundamental misunderstanding of a core security technology.
...[are]... almost without exception, misused. ... X and Y discussed how to find out if your application is making silly security assumptions or whether you have truly mitigated risks against it.
This talk covered the security technologies in Windows that
So, security is the responsibility of the application? Does anybody remember the old song: "I beg your pardon! I never promised you a rose garden!" Or is there a new winner of the Not My Job award ( http://www.nickh.org/pix/notmyjob.jpg ) this year?
Ah, yes, the wonderful "innovation" of the object bench! Of course, that's "innovation" in the classic sense of "take somebody else's idea and resell it without credit or payment". See http://www.bluej.org/vs/vs-bj.html for the real story.
When I played the frequency-shifted (human audio range) versions on my laptop, our cat came running into the room, looking around frantically. Apparently his directional detection for high-frequencies isn't much better than mine...
Please re-examine the chart; Simula is a direct descendent of ALGOL-60 which was strongly typed. That's why block-structured, typed languages were referred to for years as "ALGOL-like languages". (I can't speak from personal knowledge regarding ALGOL-58/IAL, but I believe it was never actually implemented, thus making ALGOL-60 arguably the first strongly typed language in that part of the family tree.)