it is important to know what the resulting machine code will be and the manner and consistency with which it is executed (thus his string copying example).
It can be, but it depends on what you're doing. For many tasks, it's not that important to understand the machine code being generated. Really.
There are two justifications for low level knowledge: a) correctness b) performance
Well-designed high level languages ensure consistency & correctness, so this generally isn't a problem. Performance, on the other hand, can certainly require deeper knowledge, down to the hardware. But that doesn't require mental translation to C. Some may CHOOSE to do that, but it's not required.
Since there are so many different machine languages, however, it is a clever compromise to learn the workings of a slightly higher level language that acts as a Rosetta stone across multiple platforms of machines and humans. This is C.
Absolutely, emphatically, NOT. This is language elitism. One needs to understand how their language interacts with the machine, if they want to be a senior developer. But they don't need to translate that to C.
the underlying truth that I just explained, that the important thing in software development is understanding what happens on the most basic level you can (yes, physicists and electrical engineers are my idols).
For advanced situations, particularly performance oriented, I agree. But it's not really the biggest problem for bad software quality. Bad design and abstraction practices (which have nothing to do with low level computing) cause more problems over the lifetime of software.
The babblings of Abelson and Sussman are just additional evidence of the people who don't want to take the time and energy to learn the fundamentals before they start abstracting.
This is completely wrong, and I would suggest you read the book before making comments like this. Ableson and Sussman show you, in SICP, how computers work at a fundamental level.
Nor should they be, necessarily. Corporations are driven by function (economic growth). So long as society views that as a core goal, it makes sense.
2. Corporations do best for the shareholders.
So they SAY. In reality, this is a very complicated issue and no two companies approach this the same way. "shareholder value" is only 20 years old as a mantra. Prior to that it was about "balance of stakeholder interests", which included employees and customers.
What hasn't changed is that management still wields illegitimate power unless there's a strong board of directors to counter-balance it.
3. The majority shareholders are mostly a small group of already wealthy people.
No. Majority shareholders usually are institutional investors, i.e. employees of large firms that manage money for others, often thousands of others, in which your mutual funds or pension funds are invested.
It's a tragic self re-inforcing loop: we want defined benefits pensions, pension funds demand performance, companies requrie short term gains, short term gains cause long term problems, cheating and other shenanigans become very tempting.
4. Aquire companies with "leveraged synergies".
Many mergers are silly. Others aren't. I'm not sure Oracle did a bad thing buying Peoplesoft.
5. Fire redundant pawns. Feed jobs overseas.
Since when did "Workers of the world unite!" mean "only in the USA"?
6. Lower competition.
Yeah, they do do this, and there needs to be a good watchdog to prevent it from going too far (unlike the current 'kiss the wrist of Microsoft' DOJ)
7. Handfull of shareholders get even richer at the expense of thousands of families and the business es they patronize.
There is no excuse to lay people off while paying obscene executive bonuses. But this is not so simple. Profits don't usually flow to shareholders, except thru dividends. Mostly they're re-invested. And a failing company does no one any good if they don't change.
8. Most people and the local economy lose.
At times, yes. If this is due to management incompetence and hubris, it's a tragic crime. However, it also is a side-effect of a market system -- when you introduce "creative destruction" to keeps things evolving, it tends to enthrone economics as the centre of life, instead of social ties and traditions. Assuming society wants ecnomic growth (and there's plenty of evidence that stasis or contraction is a bad thing), there's a trade-off between tradition and innovation. Again, a vigilant watchdog with teeth is needed to slow change down from time to time.
/waits for the revolution Oh, I don't know. Revolutions tend to be bloody affairs that make things much worse for a really long time. The U.S. revolution in a way was an exception this, to some degree; the French revolution was an example of the horrors and opression that can result.
This piece was an exercise in ego, with a couple of decent nuggets thrown in.
But this line takes the cake:...if you can't explain why while (*s++ = *t++); copies a string, or if that isn't the most natural thing in the world to you, well, you're programming based on superstition, as far as I'm concerned...
Right. Because programming is all about understanding pointer arithmetic.
This statement has nothing to do with CS, nothing to do with software engineering, nothing to do with digital design or assembly. This strikes me purely as "my language is better than your language" elitism.
I firmly believe in his general thesis: a great software developer pays attention to soft and hard skills. Software development is a continuum of skills: at one extreme, it's all about people -- at the other extreme, it's all about computer science.
However, the argument that the best programmers must know C idioms can be reduced to the argument that the best programmers must know (in depth) electrical engineering, digital design, or physics. Because otherwise, it's just superstition that the machine works!
In today's world, knowledge is the essential resource. It's more important to know how to organize your ignorance than to try to learn everything.
Abstract languages like Simula, Lisp, and Smalltalk completely changed the way we look at computer science. It brought the "people" element back into it - the need to think and communicate primarily at the level of the problem, not at the level of the machine -- but retaining the ability to drop down to machine level when necessary.
Abelson and Sussman explained this shift in the preface to SICP, which I think is a good way to end this rant (highlights mine):
First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.
Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems.
[...]
Underlying our approach to this subject is our conviction that ``computer science'' is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology -- the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of ``what is.'' Computation provides a framework for dealing precisely with notions of ``how to.''
OK, you got me. Though I think what I meant to say was that apps usually should stick with the technology they were originally built in; a rewrite because a framework has 'new features' is difficult to justify.
does it get extremely old and tedious after awhile?
I've been asked this by friends that are very technically savvy but don't want to get fat and bored in front of a screen.
The answer for me was that it depends on whether you're willing to take risks whenever you feel it's time for a change, i.e. the problems aren't challenging anymore and you're not learning.
But generally I'd say that software development is a very people-oriented and collaboration-intensive activity. Certainly you can do solitary work, and that has a certain "midnight hacker" enjoyment quality to it, but in many team environments that's increasingly rare, especially if you perform daily integrations and builds.
And when you get very good at programming and design you can evolve into a coaching role where you spend a lot of time coordinating and helping others -- same technical challenges, but also a new set of ones, and again, a different kind of enjoyment.
Re:Diagnosing and Recovering from UML Fever
on
How Do You Use UML?
·
· Score: 1
The UML Fever article is one of my favorite of 2004. I almost cried, I laughed so hard (particularly Curator fever and Circled Wagon fever).
Heaven help us if MDA becomes the next grail. Thankfully (thus far) some of the MDA vendors like Compuware seem rather pragmatic about it.
UML is not required to determine structure
on
How Do You Use UML?
·
· Score: 1
When you code first, doing the UML diagrams is useless. Why? Because when you find out the structure of your code and see possible improvements, you realize that it's too late to make any changes, due to compatibility problems, etc etc etc.
You're making an assumption that one can't understand the structure of their code without seeing it visually. This is similar to saying that one can't understand the plot of a book or interrelationships of characters without seeing it as a flow of bubbles & lines.
they 're still telling me it's too early to make an UML diagram because "the structures change too much". (WTF?!?!?)
WTF indeed. a UML diagram is merely a visual representation -- one can do it any time. Though they may have a point if you intend to do it by hand vs. reverse engineering the code & massaging
It's as though those behind Wikipedia believe there is no real truth. And if that's the case, why even bother to create an encyclopedia based on facts. To create a system of facts that you know are no true, because there is no truth, seems like an exercise in futility.
Certainly there's truth, but no one really agrees what that is:-)
There's empirically verifiable truth, what are often called 'facts'. There's also historical truth, which sometimes can be empirically verified (ends & outcomes), but other times not (means). And there's theorems, which if empirically verifiable or mathematically provable, are considered "true" until we find a counter-example. And then there's an area of stuff called "knowledge", or justified true belief. Problem with knowledge, is that it's very personal. And so "experts" (especially law experts!) disagree all the time!
This is why encyclopedias haven't very useful for anything beyond widely reputable empirical and historical facts, and while specialized texts or monographs drive expert debate.
Wikipedia seems to be toying with going further in terms of offering a forum for 'expert debate' than past encyclopedias. Perhaps it will succeed, or more likely satellilte wikis will pop up.
What's to stop the same utterly informed beliefs from mucking up Wikipedia?
Do you trust the strength of a literate elite to ensure that an encyclopedia is accurate, or in the strength of an oral community to ensure discipline in the evolution of that knowledge? Britannia was the former, Wikipedia is the latter. There's a tradeoff. WIth literate communities, they can spread their knowledge far & wide, but the feedback process is slow and minimal. You basically have to hope for a benevolent set of people, without hidden agendas.
With traditional oral societies, control breaks down at a certain size due to the immediacy of debate (e.g. in wikipedia, this would be a revert war) -- but there is a benefit that the nuance of evolving thought is carried through time.
What makes Wikipedia interesting is that it could become a nice hybrid of the two approaches, assuming they one day introduce a reputation system to go along side the free editing.
It also seem ridiculous that people at Wikipedia will assume that someone who plays Halo all day will have equal knowledge about aquatic plant life as someone who has studied it his entire life. If that's the world we're heading for, we are screwed as a society.
Ah, Platonic elitism rears its head.
Look, no one is suggesting that a gamer has more knowledge than a dedicated scientist. All I think the suggestion is that the Halo 2 gamer has the ability and right to question authority.
Society needs this desperately. I'm going to channel John Ralston Saul for a moment: How are people supposed to enter into public debate if the concepts which define our society and decided the manner in which we're governed are open neither to understanding nor questioning? Change can only come through what will seem at first to be outrageous statements, provocation, and a stubborn refusal to accept the calm, controlling formulae of conventional wisdom.
Remember: Encyclopedias and dictionaries were largely developed during the enlightenment by folks such as Diderot, Voltaire, and Flaubert as verbal guerilla warfare. They freed language from religion and court politics, and challenged the old regime. They didn't claim to be perveyors of "truth". Which is more true to that spirit -- Wikipedia, or traditional encyclopedias?
What will be interesting is how open source databases change the business models of database vendors. Tim O'Reilly has some interesting talks & papers on this, and Clayton Christiansen from harvard has a talk on itconversations.com about this, but the jist is: commoditize the OS and the database, de-commoditize the application.
Thus value moves away from Oracle and Microsoft and towards software that wraps OSS databases to the extent that you don't know it's even there. Classic 'disruptive innovation'.
Of course, mainframes are still around, despite being 'disrupted' by open systems and the PC. It'll be a slow decline for the dinos of the DB space. And they may reinvent themselves yet, Larry and Bill are wily.
As I said above, I like Cocoa, I get that its richer, but the reality is that most haven't moved to it yet because there's no compelling reason to port (incremental productivity gains aren't a business case, they're a technique for execution). Skills for Obj-C also are a perceived obstacle (an exagerrated one, but nevertheless present).
Thus new apps (Omniweb, Mail.app, etc.) have many reasons to go Cocoa, but legacy apps (Adobe, MS, etc.) have little reason.
But note that even some new apps, like Safari, are hybrid. Speed was an issue, at least prior to 10.3, when I noticed Mail.app and OmniWeb sped up.
which is why people who want to write native OS X programs usually write in Cocoa.
Mostly small ISV applications, not larger apps, yet, from my knowledge. It would be nice, but it's a slow growth.
I guarantee you, people in my past office environments had a) hundreds of megabytes of documents, and b) don't use folders very well. Let's not get into how many emails a day, or instant messages!
It's an infoglut world. Google desktop search is a godsend.
This isn't meant to diss Cocoa, which I like, but a clarification. The problem is not with Carbon, it is with Microsoft not updating their code to handle the newer OS X features. Remember, there is nothing Carbon can do that Cocoa can't do.
And I actually believe there are some side features that are released in Carbon before they are in Cocoa, but this may have been a memory implant.
Anyway, let's not forget that Mozilla Firefox and the Eclipse/SWT port were written in Carbon because the developers found troubles adapting their cross-platform toolkits to the "immersive" approach that Cocoa takes to controlling things like the message pump.
50 million items == 50 million rows. Any database with a B*Tree can efficiently query that. It says nothing about volume or concurrency of requests, which is where Oracle excels.
They're not quite as capable as the Oracle systems, but they can do at least 90% of what oracle can.
Online table & index reorganization? Transparent query rewrite? Shared disk clustering? Corrupt block recovery? Can they do 1/3 of what RMAN can do?
Try to improve the product. They're trying, but I'm not going to comment on what I think of the most recent efforts.
Oracle 9i introduced significant improvements to administration. And 10g has huge performance benefits.
Raise prices. Generates more revenue, but it's also fueling a race to jump ship.
Uhm, they've lowered prices, at least twice. A huge step in moving away from UPU's in 8i, then lowered std. edition costs with 9i, and again with 10g (std. edition & std. edition one).
Unbundle products, and create "new" must-have applications, each licensed seperately.
Err... last I saw they have three major suites: e-Biz suite, database, and app server. The app server suite contains pretty much everything under the sun, depending on what tier you buy. The 10g licensing & pricing PDF is available for public download off their website and pretty readable.
OAS, which basically wraps layers of nastiness around Apache to render it impossible to configure/maintain
The really old version did, but 9iAS & 10g (aka OC4J) is a full J2EE server. Though there's still the Apache stuff for the portal, I suppose.
" shrinking pool of customers"
Last I understood it, Oracle isn't really losing marketshare -- it's more of a number fudge. All the reports point to DB2 being the culprit, but in reality IBM just brands DB2 to mean "any relational database we sell", even if there are 3 different code bases (mainframe, AS/400, and UDB). SQL Server is in somewhat of a holding pattern until Yukon.
I predict that, very soon, pointy-haired-bosses of companies that CAN move to open source will do so 'en masse
Aha! I knew it! Troll!
IF you honestly believe this, you really will be disappointed. Yes, OSS databases will be a force to reckon with. Yes, they will eat Oracle's lunch in many ways. Some day. Not this day. And when they are competitive (I guess around 2007 timeframe), it will take YEARS for inertia and risk to pan out. You won't see a sizable marketshare impact on the big 3 until perhaps 2009-2010.
If you have anything remotely interesting (i.e. thousands of concurrent users, or parallel processing, or complex data processing), this is not true. And I'm a big fan of ORM, especially Hibernate.
Firstly, enterprise-class databases are still extremely expensive, on the order of $50,000 per CPU. The price is slowly dropping, but I wouldn't call this commoditization.
Secondly, you're isolating things to Java applications written wtih an ORM as sophisticated as Hibernate. That further whiddles down the applicable cases -- most places do NOT use ORM at all, they use plain JDBC with embedded SQL or stored procs. When they do use ORM, it usually isn't Hibernate, it is EJB CMP, or TOPLink, or JDO, if they're using ORM at all. And then let's look at the big OSS languages: Perl, PHP, Python. Those certainly aren't bastions of ORM technology.
Thirdly, you're ignoring a huge class of applications: analytical or business intellegence services. These are things that have nothing to do with ORM, and require good knowledge of the underlying database to gain appropriate performance, using appropriate indexing structures, materialized views, I/O layout, etc.
Fourth, administering a high volume production database is an experience that will convince most people that databases are not created equal. Not in backup schemes, nor failover, crash or media recovery, or parallelism, concurrency, or tuning parameters. They're all extremely different, with what some may suggest are large gaps between them in certain feature sets.
Anyone with a basic understanding of communications & media theory, and perhaps a dose of post-modern literary criticism, should be giggling right now about this article.
3 points:
Most of his arguments are short-term arguments due to the trust differential between traditional and modern references.
There are two major perspectives behind WHAT a reference actually is for. Wikipedia shows one perspective; Britannia another.
There are two major different cultures embodied Wikipedia vs. Britannia, due to their communication mediums.
Point 1:
PoMo literary criticism gets pretty hairy, but I can pretty much sum it up in 4 words: most text has bias. Britannia is no different. But people trust it. Why? Well, here's an idea: Trust is built through time, reputation, and endorsement. Texts compete with one another over time and are challenged by many people's evaluative skills. Wikipedia simply has a lot of growing to reach Britannia in terms of competition, endorsement, and assessing the reputations of the endorsers. It probably will take less time than Britannia took, though (due to the differences in medium).
Point 2:
What is the purpose of a dictionary, or an encyclopedia? Here's a reasonable start: to organize thought and language. This can be a power of great good, or great evil. It can be liberating, or controlling. I propose two approaches to the use of "references": a humanist approach vs. a rationalist approach.
One view is that a reference is a tool for examination, a series of questions, an inquiry into meaning, a weapon against received wisdom and therefore against the assumptions of established power. In other words, an organized Socratic approach.
Another view is that that the reference is a dispensary of truth. An instrument to limit meaning by defining language. It directs what people think. This is the Platonic elitist approach.
How are people supposed to enter into public debate if the concepts which define our society and decided the mannner in which we're governed are open neither to understanding nor questioning? Change can only come through what will seem at first to be outrageous statements, provocation, and a stubborn refusal to accept the calm, controlling formulae of conventional wisdom.
Remember: Encyclopedias and dictionaries were largely developed during the enlightenment by folks such as Diderot, Voltaire, and Flaubert as verbal guerilla warfare. They freed language from religion and court politics, and challenged the old regime. Which is more true to that spirit -- Wikipedia, or Britannia?
(Apology: the above is largely a paraphrase of the intro to John Ralston Saul's "The Doubter's Companion")
Point 3:
Both Marshall McLuhan (Wired magazine's patron saint) and Harold Innis (his mentor) claimed that communications mediums have a tremendous effect on culture, meaning, and interpretation. "The medium is the message", indeed.
Some mediums tend to enhance our communications over a wide area, promoting conformity of knowledge. This is referred to as "space bias" - aka. a "literate" society. Other mediums tend to enhance our communications over time, preserving and evolving knowledge. This is referred to as "time bias" - aka. an "oral" society.
An oral society is immediate -- words are spoken "now", provoking reactions immediately. Knowledge resides in memory and belongs to the community -- and is only available to those who can hear it. A literate society is one where knowledge is a point of view, argued linearly, in a logical order. Thought is stored, but cannot be reacted to ("you can't ask a book a question"). Action becomes seperate from thought, so "planning" becomes popular.
What I wondered was whether it is really a classic since, unlike many real classics, I had never heard of it.
What makes a classic? You seem to be referring to computer science classics. Books like Writing Solid Code are software development classics -- by practitioners, for practitioners. It also helps if you've had exposure to software development on Mac, DOS or Windows as these books tended to evolve from the PC development community in the early 90s, prior to Linux's rise.
In some circles, Design Patterns is considered a classic, particularly in C++ circles. Steve McConnell's Code Complete also is.
Then there are books like The Mythical Man Month, Peopleware, and The Psychology of Computer Programming that are more about human factors in softwre development. They're not CS related either, but have had tremendous impact on the field of software development.
Firstly, I think there is merit to your argument. Microsoft is amassing a patent portfolio, and while they haven't used it yet, they most definitely will at some point.
But first of all, you're a bit alarmist. Services orientation is not the new programming paradigm, and it is not a sucessor to OO. It certainly is the disruptive successor to OO-like distributed computing technologies such as CORBA, RMI, EJB, etc. But it doesn't kill OO "inside" the services.
Let's also note that OO is not actually inefficient, it's bad engineering that leads to inefficiency. OO is a tool in the toolbox, a big one at that, but must be used appropriately -- just like XML services need to.
There are two schools of thought here: a) Microsoft wants big in the enterprise. They finally understand they need to interoperate and play well with others to do so. So they've embraced SOA , XML, etc. They will compete on being the bringing tools, performance, productivity, etc. to developers and businesses.
b) Microsoft's conducting a massive ruse and will crush BEA and IBM with patents -- especially if strategy (a) doesn't work.
We know from the Wall Street Journal article this summer that Microsoft is quietly starting to go after its own customers in dissuading them to use Linux because of their finger on the patent-trigger.
If Microsoft does start to use its patents to threaten both clients and other web services vendors, we're going to be in a very interesting time. Microsoft will have to pull off one of the biggest PR coups of all time in order to not ACCELERATE adoption of Linux and other non-Microsoft technologies. Given their recent PR debacles and marketing failures (the.NET brand-name being one, security problems the other), I'm not confident they can pull this off.
IT departments like Microsoft because they brought costs down in the past and standardized skills. Today, they're becoming more of a liability -- they cost more, they're arrogant, and there are other standardized skills out there, like Linux. And remember -- most IT departments aren't ballsy enough to run their mission critical databases and applications on Windows. z/OS, UNIX and Linux are still key here, and I don't forsee a mass adoption of Mono over J2EE.
Secondly, IBM will not take this lying down. If Microsoft has a big patent portfolio, they probably have entire warehouses dedicated to IBM patents. IBM can bring 10 lawsuits against any 1 Microsoft lawsuit. So anything MS does will have to be in line with IBM.
So the only realistic scenario I could see happening is that they outsell and outmarket BEA and IBM, or at least BEA. IBM's already doing a good job at PR-slamming BEA. BEA is the marketshare leader on UNIX and Windows, but IBM's combination of sales, createive branding tactics ("everything is WebSphere!") and mainframe share have made it seem to many that they're clobbering BEA in revenue and wins, when they're reallly not.
Since BEA is the upstart here, it's quite possible we'll wind up with two major SOA stacks --.NET and IBM J2EE -- though BEA would probably just be acquired if it starts to falter. Sun isn't out of the game yet either, but they're certainly sidelined. And how HP rises to this arena is anybody's guess. BEA has the ability to win big here, but they don't seem to have the marketing will to become as household a name as Oracle. They need new senior leadership.
But let's also recognize that technical merit doesn't win market battles. Even if Indigo is the all singing, all dancing thing that Microsoft hopes it will be, it doesn't mean people will adopt it en masse and quickly. Firstly, it's a Windows-only technology. That's a big limit to start with. Second, it's very new and rich. There's a learning curve. Third, other vendors are not sitting still. They can and will compete.
It seems to say that companies are moving away from the "big monolith" system and investing in more modular, loosely-coupled systems. This tends to make custom software development and niche-vendor acquisition more palatable, which may cause problems for Big Death Star vendors like SAP.
The target audience for the article is obviously IT management, and is spoken in their language. This doesn't mean it is content free, it means they focus on different things than technical people usuallly do.
I actually found the article as a decent one -- it helps add fuel to those of us who think loosely coupled services are a good thing and huge monolithic systems aren't.
The "35 day month" used to actually be a fairly common practice in software around 10 years ago. It's purely due to accounting fictions -- monthly and quarterly sales goals and wall street guidance. Short term gain over long term wealth capacity.
Many companies squeeze vendors for discounts and delay purchase until end of month. Of course, purchasing processes and systems are bound to mess up, so the P.O. never really gets through until the 1st to 5th of the next month...
This also was rampant back in the.com days.
CA still operates in the old model of sales, whereas most enterprise software vendors are much smarter about this sort of stuff.
disclaimer: just my personal opinions, might be b.s., ymmv
the problem with CDP is all those employees now out of work... it's a good solution on paper, but then the pesky thing about lives and livelihoods come into play. this is one of the main reasons the airline industry keeps getting bail outs (among several).
I'm not quite sure what to make of this. Sometimes I think he's just promoting that developers learn more than one programming language. I can dig that. I don't agree with equating intelligence with choice of programming language. Things are harder than that, particularly in a large company.
In a general sense, there has been a long debate about whether language influences thought, or if all languages are independent of thought. In oral human languages, Steven Pinker would argue that language is an instinct, and doesn't influence thought -- it evolves from thought.
In computer languages, however, you're not just communicating. You're representing. Also note that computer languages are written langauges, not oral languages. Harold Innis and Marshal McLuhan have both shown that written languages do influence thought, particularly the western phonetic alphabet leading to a paritcular societal pattern vs. eastern pictographic languages.
Turning to computer languages, one could argue that if you've only been exposed to one way of "representing" a thought, say with Visual Basic 6 - you are limited in the boundaries you set up in your own mind about what's possible. Ideas like dynamic dispatch, inheritance, etc. are all foreign, unless you've been exposed to them in another language.
Or, on the other hand, you may be using a language like C with very few boundaries, but this doesn't help either -- there's a lot of freedom there, and not a lot of guidance about how to use it properly. I always find it interesting when C programmers defend their choice and suggest "but, you can do object oriented programming in C!". Well, of course you can! But it required another language, Simula, followed by Smalltalk, to generate the discipline and ideas around what object oriented programming really was. Could that paradigm have evolved without another language to naturally support it? It's possible, but somewhat unlikely.
Any Turing complete language could implement a programming paradigm, it's just a matter if it's natural to the language's constructs or if it requires more elaborate structures. For example, if anyone has programmed Microsoft's COM realizes that the underlying concepts are relatively simple, but the elaborate syntax for achieving it in C++ (prior to ATL especially) is ridiculous. In this light,.NET really is about bringing the level of language up to and beyond the semantics that Microsoft technologists already had with COM.
Nevertheless, there's still a practical problem with modern dynamic languages. The world has a legacy, and that legacy is large, chaotic, crufty, and not very dynamic. Getting a handle on it requires simplification, constraints, and classifications for the kinds of languages, tools, techniques, and platforms for the future. This is the main reason why languages like COBOL, C++, or Java stick around: we have to stick to something for a few years to simplify the system dynamics in the large. Picking "one standard" or "one vendor" is a key way of ensuring quality - by constraining and simplifying the business environment.
Java is clearly not a "thought leading" language like Python or Ruby , or even older languages like Lisp or Smalltalk. But that's not what it was supposed to be. Java was an "action provoking" language that took a very large C and C++ legacy of systems, skills, and mindsets, and pushed them forward an inch.
A lot of independent technical people may not agree with "constrainting" the environment, because it limits innovation. Modern dynamic lanaguages make life so much simpler for the programmer. And I agree they do. But there are levels of simplicity -- and organizational simplicty in the large often trumps simplicity in the small. We'll get there eventually, but it will take a while. Most enlightened organizations will have an emerging technology lab to bri
The whole point of this article was that there have been a number of cries of protest over Apple's treatment of the iTunes Music Store and iPod vs. Real. And popular opinion is again saying that Apple is failing again to "be like Microsoft" or is being "too much like Microsoft", depending on who you talk to.
This article set to debunk that there is any particular "thing" Microsoft did to get where they are. Other than having very smart people (which they started losing but are beginning to draw in again), and illegally perpetuating their position, they just followed good business practice - take advantage of whatever opportunity comes your way. Hindsight turned it into a philosophy of "low price high volume open licensing always wins", which we know CAN be true but not universally so.
Slashdot Mirror
it is important to know what the resulting machine code will be and the manner and consistency with which it is executed (thus his string copying example).
It can be, but it depends on what you're doing. For many tasks, it's not that important to understand the machine code being generated. Really.
There are two justifications for low level knowledge:
a) correctness
b) performance
Well-designed high level languages ensure consistency & correctness, so this generally isn't a problem. Performance, on the other hand, can certainly require deeper knowledge, down to the hardware. But that doesn't require mental translation to C. Some may CHOOSE to do that, but it's not required.
Since there are so many different machine languages, however, it is a clever compromise to learn the workings of a slightly higher level language that acts as a Rosetta stone across multiple platforms of machines and humans. This is C.
Absolutely, emphatically, NOT. This is language elitism. One needs to understand how their language interacts with the machine, if they want to be a senior developer. But they don't need to translate that to C.
the underlying truth that I just explained, that the important thing in software development is understanding what happens on the most basic level you can (yes, physicists and electrical engineers are my idols).
For advanced situations, particularly performance oriented, I agree. But it's not really the biggest problem for bad software quality. Bad design and abstraction practices (which have nothing to do with low level computing) cause more problems over the lifetime of software.
The babblings of Abelson and Sussman are just additional evidence of the people who don't want to take the time and energy to learn the fundamentals before they start abstracting.
This is completely wrong, and I would suggest you read the book before making comments like this. Ableson and Sussman show you, in SICP, how computers work at a fundamental level.
Peoplesoft 9 is going to be relased.
Peoplesoft's product line will be supported through 2010.
1. Corporations are not a democracy.
/waits for the revolution
Nor should they be, necessarily. Corporations are driven by function (economic growth). So long as society views that as a core goal, it makes sense.
2. Corporations do best for the shareholders.
So they SAY. In reality, this is a very complicated issue and no two companies approach this the same way. "shareholder value" is only 20 years old as a mantra. Prior to that it was about "balance of stakeholder interests", which included employees and customers.
What hasn't changed is that management still wields illegitimate power unless there's a strong board of directors to counter-balance it.
3. The majority shareholders are mostly a small group of already wealthy people.
No. Majority shareholders usually are institutional investors, i.e. employees of large firms that manage money for others, often thousands of others, in which your mutual funds or pension funds are invested.
It's a tragic self re-inforcing loop: we want defined benefits pensions, pension funds demand performance, companies requrie short term gains, short term gains cause long term problems, cheating and other shenanigans become very tempting.
4. Aquire companies with "leveraged synergies".
Many mergers are silly. Others aren't. I'm not sure Oracle did a bad thing buying Peoplesoft.
5. Fire redundant pawns. Feed jobs overseas.
Since when did "Workers of the world unite!" mean "only in the USA"?
6. Lower competition.
Yeah, they do do this, and there needs to be a good watchdog to prevent it from going too far (unlike the current 'kiss the wrist of Microsoft' DOJ)
7. Handfull of shareholders get even richer at the expense of thousands of families and the business es they patronize.
There is no excuse to lay people off while paying obscene executive bonuses. But this is not so simple. Profits don't usually flow to shareholders, except thru dividends. Mostly they're re-invested. And a failing company does no one any good if they don't change.
8. Most people and the local economy lose.
At times, yes. If this is due to management incompetence and hubris, it's a tragic crime. However, it also is a side-effect of a market system -- when you introduce "creative destruction" to keeps things evolving, it tends to enthrone economics as the centre of life, instead of social ties and traditions. Assuming society wants ecnomic growth (and there's plenty of evidence that stasis or contraction is a bad thing), there's a trade-off between tradition and innovation. Again, a vigilant watchdog with teeth is needed to slow change down from time to time.
Oh, I don't know. Revolutions tend to be bloody affairs that make things much worse for a really long time. The U.S. revolution in a way was an exception this, to some degree; the French revolution was an example of the horrors and opression that can result.
But this line takes the cake:
Right. Because programming is all about understanding pointer arithmetic.
This statement has nothing to do with CS, nothing to do with software engineering, nothing to do with digital design or assembly. This strikes me purely as "my language is better than your language" elitism.
I firmly believe in his general thesis: a great software developer pays attention to soft and hard skills. Software development is a continuum of skills: at one extreme, it's all about people -- at the other extreme, it's all about computer science.
However, the argument that the best programmers must know C idioms can be reduced to the argument that the best programmers must know (in depth) electrical engineering, digital design, or physics. Because otherwise, it's just superstition that the machine works!
In today's world, knowledge is the essential resource. It's more important to know how to organize your ignorance than to try to learn everything.
Abstract languages like Simula, Lisp, and Smalltalk completely changed the way we look at computer science. It brought the "people" element back into it - the need to think and communicate primarily at the level of the problem, not at the level of the machine -- but retaining the ability to drop down to machine level when necessary.
Abelson and Sussman explained this shift in the preface to SICP, which I think is a good way to end this rant (highlights mine):
OK, you got me. Though I think what I meant to say was that apps usually should stick with the technology they were originally built in; a rewrite because a framework has 'new features' is difficult to justify.
does it get extremely old and tedious after awhile?
I've been asked this by friends that are very technically savvy but don't want to get fat and bored in front of a screen.
The answer for me was that it depends on whether you're willing to take risks whenever you feel it's time for a change, i.e. the problems aren't challenging anymore and you're not learning.
But generally I'd say that software development is a very people-oriented and collaboration-intensive activity. Certainly you can do solitary work, and that has a certain "midnight hacker" enjoyment quality to it, but in many team environments that's increasingly rare, especially if you perform daily integrations and builds.
And when you get very good at programming and design you can evolve into a coaching role where you spend a lot of time coordinating and helping others -- same technical challenges, but also a new set of ones, and again, a different kind of enjoyment.
The UML Fever article is one of my favorite of 2004. I almost cried, I laughed so hard (particularly Curator fever and Circled Wagon fever).
Heaven help us if MDA becomes the next grail. Thankfully (thus far) some of the MDA vendors like Compuware seem rather pragmatic about it.
When you code first, doing the UML diagrams is useless. Why? Because when you find out the structure of your code and see possible improvements, you realize that it's too late to make any changes, due to compatibility problems, etc etc etc.
You're making an assumption that one can't understand the structure of their code without seeing it visually. This is similar to saying that one can't understand the plot of a book or interrelationships of characters without seeing it as a flow of bubbles & lines.
they 're still telling me it's too early to make an UML diagram because "the structures change too much". (WTF?!?!?)
WTF indeed. a UML diagram is merely a visual representation -- one can do it any time. Though they may have a point if you intend to do it by hand vs. reverse engineering the code & massaging
It's as though those behind Wikipedia believe there is no real truth. And if that's the case, why even bother to create an encyclopedia based on facts. To create a system of facts that you know are no true, because there is no truth, seems like an exercise in futility.
:-)
Certainly there's truth, but no one really agrees what that is
There's empirically verifiable truth, what are often called 'facts'. There's also historical truth, which sometimes can be empirically verified (ends & outcomes), but other times not (means). And there's theorems, which if empirically verifiable or mathematically provable, are considered "true" until we find a counter-example. And then there's an area of stuff called "knowledge", or justified true belief. Problem with knowledge, is that it's very personal. And so "experts" (especially law experts!) disagree all the time!
This is why encyclopedias haven't very useful for anything beyond widely reputable empirical and historical facts, and while specialized texts or monographs drive expert debate.
Wikipedia seems to be toying with going further in terms of offering a forum for 'expert debate' than past encyclopedias. Perhaps it will succeed, or more likely satellilte wikis will pop up.
What's to stop the same utterly informed beliefs from mucking up Wikipedia?
Do you trust the strength of a literate elite to ensure that an encyclopedia is accurate, or in the strength of an oral community to ensure discipline in the evolution of that knowledge? Britannia was the former, Wikipedia is the latter. There's a tradeoff. WIth literate communities, they can spread their knowledge far & wide, but the feedback process is slow and minimal. You basically have to hope for a benevolent set of people, without hidden agendas.
With traditional oral societies, control breaks down at a certain size due to the immediacy of debate (e.g. in wikipedia, this would be a revert war) -- but there is a benefit that the nuance of evolving thought is carried through time.
What makes Wikipedia interesting is that it could become a nice hybrid of the two approaches, assuming they one day introduce a reputation system to go along side the free editing.
It also seem ridiculous that people at Wikipedia will assume that someone who plays Halo all day will have equal knowledge about aquatic plant life as someone who has studied it his entire life. If that's the world we're heading for, we are screwed as a society.
Ah, Platonic elitism rears its head.
Look, no one is suggesting that a gamer has more knowledge than a dedicated scientist. All I think the suggestion is that the Halo 2 gamer has the ability and right to question authority.
Society needs this desperately. I'm going to channel John Ralston Saul for a moment: How are people supposed to enter into public debate if the concepts which define our society and decided the manner in which we're governed are open neither to understanding nor questioning? Change can only come through what will seem at first to be outrageous statements, provocation, and a stubborn refusal to accept the calm, controlling formulae of conventional wisdom.
Remember: Encyclopedias and dictionaries were largely developed during the enlightenment by folks such as Diderot, Voltaire, and Flaubert as verbal guerilla warfare. They freed language from religion and court politics, and challenged the old regime. They didn't claim to be perveyors of "truth". Which is more true to that spirit -- Wikipedia, or traditional encyclopedias?
What will be interesting is how open source databases change the business models of database vendors. Tim O'Reilly has some interesting talks & papers on this, and Clayton Christiansen from harvard has a talk on itconversations.com about this, but the jist is: commoditize the OS and the database, de-commoditize the application.
Thus value moves away from Oracle and Microsoft and towards software that wraps OSS databases to the extent that you don't know it's even there. Classic 'disruptive innovation'.
Of course, mainframes are still around, despite being 'disrupted' by open systems and the PC. It'll be a slow decline for the dinos of the DB space. And they may reinvent themselves yet, Larry and Bill are wily.
As I said above, I like Cocoa, I get that its richer, but the reality is that most haven't moved to it yet because there's no compelling reason to port (incremental productivity gains aren't a business case, they're a technique for execution). Skills for Obj-C also are a perceived obstacle (an exagerrated one, but nevertheless present).
Thus new apps (Omniweb, Mail.app, etc.) have many reasons to go Cocoa, but legacy apps (Adobe, MS, etc.) have little reason.
But note that even some new apps, like Safari, are hybrid. Speed was an issue, at least prior to 10.3, when I noticed Mail.app and OmniWeb sped up.
which is why people who want to write native OS X programs usually write in Cocoa.
Mostly small ISV applications, not larger apps, yet, from my knowledge. It would be nice, but it's a slow growth.
I guarantee you, people in my past office environments had a) hundreds of megabytes of documents, and b) don't use folders very well. Let's not get into how many emails a day, or instant messages!
It's an infoglut world. Google desktop search is a godsend.
This isn't meant to diss Cocoa, which I like, but a clarification. The problem is not with Carbon, it is with Microsoft not updating their code to handle the newer OS X features. Remember, there is nothing Carbon can do that Cocoa can't do.
And I actually believe there are some side features that are released in Carbon before they are in Cocoa, but this may have been a memory implant.
Anyway, let's not forget that Mozilla Firefox and the Eclipse/SWT port were written in Carbon because the developers found troubles adapting their cross-platform toolkits to the "immersive" approach that Cocoa takes to controlling things like the message pump.
50 million items == 50 million rows. Any database with a B*Tree can efficiently query that. It says nothing about volume or concurrency of requests, which is where Oracle excels.
This post really looks like an elaborate troll.
They're not quite as capable as the Oracle systems, but they can do at least 90% of what oracle can.
Online table & index reorganization? Transparent query rewrite? Shared disk clustering? Corrupt block recovery? Can they do 1/3 of what RMAN can do?
Try to improve the product. They're trying, but I'm not going to comment on what I think of the most recent efforts.
Oracle 9i introduced significant improvements to administration. And 10g has huge performance benefits.
Raise prices. Generates more revenue, but it's also fueling a race to jump ship.
Uhm, they've lowered prices, at least twice. A huge step in moving away from UPU's in 8i, then lowered std. edition costs with 9i, and again with 10g (std. edition & std. edition one).
Unbundle products, and create "new" must-have applications, each licensed seperately.
Err... last I saw they have three major suites: e-Biz suite, database, and app server. The app server suite contains pretty much everything under the sun, depending on what tier you buy. The 10g licensing & pricing PDF is available for public download off their website and pretty readable.
OAS, which basically wraps layers of nastiness around Apache to render it impossible to configure/maintain
The really old version did, but 9iAS & 10g (aka OC4J) is a full J2EE server. Though there's still the Apache stuff for the portal, I suppose.
" shrinking pool of customers"
Last I understood it, Oracle isn't really losing marketshare -- it's more of a number fudge. All the reports point to DB2 being the culprit, but in reality IBM just brands DB2 to mean "any relational database we sell", even if there are 3 different code bases (mainframe, AS/400, and UDB). SQL Server is in somewhat of a holding pattern until Yukon.
I predict that, very soon, pointy-haired-bosses of companies that CAN move to open source will do so 'en masse
Aha! I knew it! Troll!
IF you honestly believe this, you really will be disappointed. Yes, OSS databases will be a force to reckon with. Yes, they will eat Oracle's lunch in many ways. Some day. Not this day. And when they are competitive (I guess around 2007 timeframe), it will take YEARS for inertia and risk to pan out. You won't see a sizable marketshare impact on the big 3 until perhaps 2009-2010.
If you have anything remotely interesting (i.e. thousands of concurrent users, or parallel processing, or complex data processing), this is not true. And I'm a big fan of ORM, especially Hibernate.
Firstly, enterprise-class databases are still extremely expensive, on the order of $50,000 per CPU. The price is slowly dropping, but I wouldn't call this commoditization.
Secondly, you're isolating things to Java applications written wtih an ORM as sophisticated as Hibernate. That further whiddles down the applicable cases -- most places do NOT use ORM at all, they use plain JDBC with embedded SQL or stored procs. When they do use ORM, it usually isn't Hibernate, it is EJB CMP, or TOPLink, or JDO, if they're using ORM at all. And then let's look at the big OSS languages: Perl, PHP, Python. Those certainly aren't bastions of ORM technology.
Thirdly, you're ignoring a huge class of applications: analytical or business intellegence services. These are things that have nothing to do with ORM, and require good knowledge of the underlying database to gain appropriate performance, using appropriate indexing structures, materialized views, I/O layout, etc.
Fourth, administering a high volume production database is an experience that will convince most people that databases are not created equal. Not in backup schemes, nor failover, crash or media recovery, or parallelism, concurrency, or tuning parameters. They're all extremely different, with what some may suggest are large gaps between them in certain feature sets.
3 points:
Point 1:
PoMo literary criticism gets pretty hairy, but I can pretty much sum it up in 4 words: most text has bias. Britannia is no different. But people trust it. Why? Well, here's an idea: Trust is built through time, reputation, and endorsement. Texts compete with one another over time and are challenged by many people's evaluative skills. Wikipedia simply has a lot of growing to reach Britannia in terms of competition, endorsement, and assessing the reputations of the endorsers. It probably will take less time than Britannia took, though (due to the differences in medium).
Point 2:
What is the purpose of a dictionary, or an encyclopedia? Here's a reasonable start: to organize thought and language. This can be a power of great good, or great evil. It can be liberating, or controlling. I propose two approaches to the use of "references": a humanist approach vs. a rationalist approach.
One view is that a reference is a tool for examination, a series of questions, an inquiry into meaning, a weapon against received wisdom and therefore against the assumptions of established power. In other words, an organized Socratic approach.
Another view is that that the reference is a dispensary of truth. An instrument to limit meaning by defining language. It directs what people think. This is the Platonic elitist approach.
How are people supposed to enter into public debate if the concepts which define our society and decided the mannner in which we're governed are open neither to understanding nor questioning?
Change can only come through what will seem at first to be outrageous statements, provocation, and a stubborn refusal to accept the calm, controlling formulae of conventional wisdom.
Remember: Encyclopedias and dictionaries were largely developed during the enlightenment by folks such as Diderot, Voltaire, and Flaubert as verbal guerilla warfare. They freed language from religion and court politics, and challenged the old regime. Which is more true to that spirit -- Wikipedia, or Britannia?
(Apology: the above is largely a paraphrase of the intro to John Ralston Saul's "The Doubter's Companion")
Point 3:
Both Marshall McLuhan (Wired magazine's patron saint) and Harold Innis (his mentor) claimed that communications mediums have a tremendous effect on culture, meaning, and interpretation. "The medium is the message", indeed.
Some mediums tend to enhance our communications over a wide area, promoting conformity of knowledge. This is referred to as "space bias" - aka. a "literate" society. Other mediums tend to enhance our communications over time, preserving and evolving knowledge. This is referred to as "time bias" - aka. an "oral" society.
An oral society is immediate -- words are spoken "now", provoking reactions immediately. Knowledge resides in memory and belongs to the community -- and is only available to those who can hear it. A literate society is one where knowledge is a point of view, argued linearly, in a logical order. Thought is stored, but cannot be reacted to ("you can't ask a book a question"). Action becomes seperate from thought, so "planning" becomes popular.
The Internet flips the written wor
What I wondered was whether it is really a classic since, unlike many real classics, I had never heard of it.
What makes a classic? You seem to be referring to computer science classics. Books like Writing Solid Code are software development classics -- by practitioners, for practitioners. It also helps if you've had exposure to software development on Mac, DOS or Windows as these books tended to evolve from the PC development community in the early 90s, prior to Linux's rise.
In some circles, Design Patterns is considered a classic, particularly in C++ circles. Steve McConnell's Code Complete also is.
Then there are books like The Mythical Man Month, Peopleware, and The Psychology of Computer Programming that are more about human factors in softwre development. They're not CS related either, but have had tremendous impact on the field of software development.
Firstly, I think there is merit to your argument. Microsoft is amassing a patent portfolio, and while they haven't used it yet, they most definitely will at some point.
.NET brand-name being one, security problems the other), I'm not confident they can pull this off.
.NET and IBM J2EE -- though BEA would probably just be acquired if it starts to falter. Sun isn't out of the game yet either, but they're certainly sidelined. And how HP rises to this arena is anybody's guess. BEA has the ability to win big here, but they don't seem to have the marketing will to become as household a name as Oracle. They need new senior leadership.
But first of all, you're a bit alarmist. Services orientation is not the new programming paradigm, and it is not a sucessor to OO. It certainly is the disruptive successor to OO-like distributed computing technologies such as CORBA, RMI, EJB, etc. But it doesn't kill OO "inside" the services.
Let's also note that OO is not actually inefficient, it's bad engineering that leads to inefficiency. OO is a tool in the toolbox, a big one at that, but must be used appropriately -- just like XML services need to.
There are two schools of thought here:
a) Microsoft wants big in the enterprise. They finally understand they need to interoperate and play well with others to do so. So they've embraced SOA , XML, etc. They will compete on being the bringing tools, performance, productivity, etc. to developers and businesses.
b) Microsoft's conducting a massive ruse and will crush BEA and IBM with patents -- especially if strategy (a) doesn't work.
We know from the Wall Street Journal article this summer that Microsoft is quietly starting to go after its own customers in dissuading them to use Linux because of their finger on the patent-trigger.
If Microsoft does start to use its patents to threaten both clients and other web services vendors, we're going to be in a very interesting time. Microsoft will have to pull off one of the biggest PR coups of all time in order to not ACCELERATE adoption of Linux and other non-Microsoft technologies. Given their recent PR debacles and marketing failures (the
IT departments like Microsoft because they brought costs down in the past and standardized skills. Today, they're becoming more of a liability -- they cost more, they're arrogant, and there are other standardized skills out there, like Linux. And remember -- most IT departments aren't ballsy enough to run their mission critical databases and applications on Windows. z/OS, UNIX and Linux are still key here, and I don't forsee a mass adoption of Mono over J2EE.
Secondly, IBM will not take this lying down. If Microsoft has a big patent portfolio, they probably have entire warehouses dedicated to IBM patents. IBM can bring 10 lawsuits against any 1 Microsoft lawsuit. So anything MS does will have to be in line with IBM.
So the only realistic scenario I could see happening is that they outsell and outmarket BEA and IBM, or at least BEA. IBM's already doing a good job at PR-slamming BEA. BEA is the marketshare leader on UNIX and Windows, but IBM's combination of sales, createive branding tactics ("everything is WebSphere!") and mainframe share have made it seem to many that they're clobbering BEA in revenue and wins, when they're reallly not.
Since BEA is the upstart here, it's quite possible we'll wind up with two major SOA stacks --
But let's also recognize that technical merit doesn't win market battles. Even if Indigo is the all singing, all dancing thing that Microsoft hopes it will be, it doesn't mean people will adopt it en masse and quickly. Firstly, it's a Windows-only technology. That's a big limit to start with. Second, it's very new and rich. There's a learning curve. Third, other vendors are not sitting still. They can and will compete.
It seems to say that companies are moving away from the "big monolith" system and investing in more modular, loosely-coupled systems. This tends to make custom software development and niche-vendor acquisition more palatable, which may cause problems for Big Death Star vendors like SAP.
The target audience for the article is obviously IT management, and is spoken in their language. This doesn't mean it is content free, it means they focus on different things than technical people usuallly do.
I actually found the article as a decent one -- it helps add fuel to those of us who think loosely coupled services are a good thing and huge monolithic systems aren't.
The "35 day month" used to actually be a fairly common practice in software around 10 years ago. It's purely due to accounting fictions -- monthly and quarterly sales goals and wall street guidance. Short term gain over long term wealth capacity.
.com days.
Many companies squeeze vendors for discounts and delay purchase until end of month. Of course, purchasing processes and systems are bound to mess up, so the P.O. never really gets through until the 1st to 5th of the next month...
This also was rampant back in the
CA still operates in the old model of sales, whereas most enterprise software vendors are much smarter about this sort of stuff.
disclaimer: just my personal opinions, might be b.s., ymmv
the problem with CDP is all those employees now out of work... it's a good solution on paper, but then the pesky thing about lives and livelihoods come into play. this is one of the main reasons the airline industry keeps getting bail outs (among several).
Better NOT be patriot missles, considering they don't work, and never even took down a Scud in 1991, despite the news and military reports.
. ht ml
http://www.wired.com/news/print/0,1294,58147,00
I'm not quite sure what to make of this. Sometimes I think he's just promoting that developers learn more than one programming language. I can dig that. I don't agree with equating intelligence with choice of programming language. Things are harder than that, particularly in a large company.
.NET really is about bringing the level of language up to and beyond the semantics that Microsoft technologists already had with COM.
In a general sense, there has been a long debate about whether language influences thought, or if all languages are independent of thought. In oral human languages, Steven Pinker would argue that language is an instinct, and doesn't influence thought -- it evolves from thought.
In computer languages, however, you're not just communicating. You're representing. Also note that computer languages are written langauges, not oral languages. Harold Innis and Marshal McLuhan have both shown that written languages do influence thought, particularly the western phonetic alphabet leading to a paritcular societal pattern vs. eastern pictographic languages.
Turning to computer languages, one could argue that if you've only been exposed to one way of "representing" a thought, say with Visual Basic 6 - you are limited in the boundaries you set up in your own mind about what's possible. Ideas like dynamic dispatch, inheritance, etc. are all foreign, unless you've been exposed to them in another language.
Or, on the other hand, you may be using a language like C with very few boundaries, but this doesn't help either -- there's a lot of freedom there, and not a lot of guidance about how to use it properly. I always find it interesting when C programmers defend their choice and suggest "but, you can do object oriented programming in C!". Well, of course you can! But it required another language, Simula, followed by Smalltalk, to generate the discipline and ideas around what object oriented programming really was. Could that paradigm have evolved without another language to naturally support it? It's possible, but somewhat unlikely.
Any Turing complete language could implement a programming paradigm, it's just a matter if it's natural to the language's constructs or if it requires more elaborate structures. For example, if anyone has programmed Microsoft's COM realizes that the underlying concepts are relatively simple, but the elaborate syntax for achieving it in C++ (prior to ATL especially) is ridiculous. In this light,
Nevertheless, there's still a practical problem with modern dynamic languages. The world has a legacy, and that legacy is large, chaotic, crufty, and not very dynamic. Getting a handle on it requires simplification, constraints, and classifications for the kinds of languages, tools, techniques, and platforms for the future. This is the main reason why languages like COBOL, C++, or Java stick around: we have to stick to something for a few years to simplify the system dynamics in the large. Picking "one standard" or "one vendor" is a key way of ensuring quality - by constraining and simplifying the business environment.
Java is clearly not a "thought leading" language like Python or Ruby , or even older languages like Lisp or Smalltalk. But that's not what it was supposed to be. Java was an "action provoking" language that took a very large C and C++ legacy of systems, skills, and mindsets, and pushed them forward an inch.
A lot of independent technical people may not agree with "constrainting" the environment, because it limits innovation. Modern dynamic lanaguages make life so much simpler for the programmer. And I agree they do. But there are levels of simplicity -- and organizational simplicty in the large often trumps simplicity in the small. We'll get there eventually, but it will take a while. Most enlightened organizations will have an emerging technology lab to bri
The whole point of this article was that there have been a number of cries of protest over Apple's treatment of the iTunes Music Store and iPod vs. Real. And popular opinion is again saying that Apple is failing again to "be like Microsoft" or is being "too much like Microsoft", depending on who you talk to.
This article set to debunk that there is any particular "thing" Microsoft did to get where they are. Other than having very smart people (which they started losing but are beginning to draw in again), and illegally perpetuating their position, they just followed good business practice - take advantage of whatever opportunity comes your way. Hindsight turned it into a philosophy of "low price high volume open licensing always wins", which we know CAN be true but not universally so.