However, I think that it makes the student's choice crystal clear: become a computer scientist, not just a programmer, because if the IT locomotive does decide next year that some new thing is better, you'd better be as adaptable or you'll get left in the dust.
You want to learn computer science, or anything really, from people with advice like this. You may end up even contributing to the next new thing.
Stefan Tilkov writes about me...
Patrick Logan has a blog. So what?
Exactly.
Oh, he continues...
Apart from some very interesting posts, I somehow recall the name, and have positive assocations with it ... digging ... I found a patricklogan@gemstone.com
Well, thanks. Gemstone went through an upheaval at the tail end of the dot com fiasco. I left before the implosion...
"In less than a year, a 20-year-old [sic] company, with revenues and profits, (though not brilliant, it was a going concern), has been destroyed by another company that is itself only a few years old. That is sad."
So I am wondering how much should be put into specifications and what should be left for emergence?
I have had bad experiences participating in the market-driven rush to unproven and premature standardization. So I lean toward the minimal necessary and look for patterns and principles to emerge from experience.
Giulio Piancastelli is very kind and also on the money speculating...
I quoted Patrick's words because I think they are the most original and interesting from the whole bunch. I see Prolog and tuple centers in them, and I am glad for what I see.
Nice connection and thanks for the references to these projects. Indeed I think the future is bright for logic/constraint languages and coordination through blackboard/tuplespace architectures.
There is nothing like a controversial statement to draw attention to an issue, or at least traffic to a little-known blog.
Apparently, Patrick took a peek at WS-Transaction, didn't get any further than the author list and decided it wasn't any good. I agree that two phase commit is traditional... I hold out more hope for compensating transactions via asynchronous messages.
I did read further than the list of authors. But nothing like a controversial statement to get people interested in a topic.
I do think the compensating approach is better than the atomic approach at the distributed business level of "transaction". But I am not sure either should be a part of the connection architecture. Compensation "meta-data" if you will should be a part of the documents exchanged among business partners, no matter how those documents are exchanged.
A distributed system across trust boundaries is where I believe we are collectively heading. The internet shows us the beginnings of what is possible... for the subset of things that are generally always online and publically accessible. Expanding this to mobile and access controlled is the next big thing.
I love the NeuroTransmitters story. But Sean McGrath illustrates the problems that emerge when you overload your connection architecture over time.
The network is not the computer. My computer is over here and yours is over there. All we need is a simple way to exchange documents.
The documents are the messages. The computers are the cells. (Fortresses in Roger Session's metaphor.)
The connections should be as simple as possible and get out of the way.
Sam Ruby points to WS-Transaction. But look at the list of authors. The problem is IBM and Microsoft have a lot to preserve by maintaining more or less traditional databases and transaction protocols.
Jon Udell wonders about the LAMP vs. J2EE/dotNET inflection point. But LAMP is made in the same image. This architecture goes back thirty years or more.
I've written an essay on what I think the next database architectures should look like. If you read through my blogs you'll know it has something to do with tuple spaces and star schemas. But Jon goes on to ask, "How do you preserve the fluidity that the agile enterprise requires?" There is a little bit more to say, since enterprises are not nearly as agile as they need to be.
WS-Transaction is intended to preserve the status quo rather than improve agility. I'll publish more on this in the near future.
Lambda the Ultimate has this piece on a Scheme program that analyzes Excel spreadsheets.
What is most notable about this? The essence of this system represents the future of software development and the need for more dynamic analysis than "compilers" traditionally give.
Note:
This represents the convergence of dynamic model checking and infered static type checking. The future is getting more dynamic and so "type checkers" will become more sophisticated (and background) theorem provers than they are now.
Additional features will include symbolic execution including concurrency model checking and semi-symbolic partial evaluation.
Over the last 10-15 years electronics design has taken more of a software design flavor. Over the next 10-15 years software design will take on more of a traditional hardware simulation and model checking flavor.
A quote from FDR via Mark Johnson's weblog...
For out of this modern civilization economic royalists carved new dynasties. New kingdoms were built upon concentration of control over material things.
From the Vistorian Age to the present it could be argued that dynasties were necessary to build the steel mills, shipping, the railroads, the telecommunications systems, and so on. Perhaps the benefits for society outweigh the cost of establishing the industrial dynasties.
But now we're in an age where extreme decentralization is at hand. It will be more of a challenge to get dynastical forces out of the way of progress than it will be to actually establish a decentralized age itself. Are dynasties necessary for societies to decentralize in the way they were necessary to centralize in the first place? I don't think so.
Dylan told the senators and congressmen not to stand in the doorways or block up the halls. The times are changing. Will the dynasties allow it? Will the people know enough to demand it?
This from Matt Gerrans ties in with the posts on structure and interpretation of computer programs I wrote about this week (and almost every week it seems).
OK. Another blogger to follow.
BTW when I was writing electronic design automation software way back when Matt's approach was the popular (and correct) technique. Scheme was the scripting language of choice for DA tools.
Jon Udell points out Bob Martin, Ward, and Guido van Rossum have entered the blog world. I'll pay particular attention to Ward's, he has a singular style and an uncommonly sensible approach to software.
Moreover two notable people in distributed systems have blogs as well: Ken Arnold and Jim Waldo.
Both have been instrumental with JINI and JavaSpaces, the two best satellites in the Java universe.
The blogsphere has achieved another level of benefit for software developers with the addition of this new handful. I'll have to check out the others in their sidebars.
Objective-C has advantages of simplicity and optional dynamic types, neither of which is an attribute of C++. A lot of people don't realize that Objective-C is part of the GCC. So the compiler and library are available for Linux, Windows, and other Unix in addition to Mac OS X.
The language also has a reflection interface in pure C, so integrating scripting languages into Objective-C applications is a snap compared to C++ or even C. You don't have to generate stubs per API. Just call the reflection API dynamically.
First, I am thrilled to have come across Bob Martin's weblog. His first book is still required reading as far as I am concerned, it is not a C++ book, it is a *design* book. His second is right up there as well, having won a 2002 Jolt award. He's co-authored, edited, etc. many others too.
Second, this weblog topic asks, are dynamic languages replacing static languages? He goes on to confirm what dynamic language programmers have been confirming to themselves for forty years: dynamic languages and their iterative, incremental approach to design obviates the need for static type checking.
The next interesting question addresses the future of type systems and will a more formal yet expressive static type system be more productive than either dynamic languages or the more primitive type systems of Java and C#?
My take on it is this having done a lot of dynamic language programming and a little modern functional language programming...
There is a convergence out there, maybe ten years out on the road to The Hundred Year Language, where better (less intrusive, more expressive) formal type systems and dynamic programming meet. After all, incrementally building a dynamic system of objects is not unlike incrementally building an expressive system of typed combinators!
Essentially type systems are theorem provers. The more expressive they become, the close they are to the problem domain, just as the more expressive dynamic languages allow us to speak more about the problem domain than the "compiling domain". In the future I expect to be able to dynamically build semi-formal systems and then have that system tell me things, i.e. prove theorems about itself. From there I can make adjustments not just through more tests and code, but through direct manipulation of the "theorems" I have stumbled upon.
Talk about refactoring! Organizations with interacting systems will be able to refactor the "theorems" of how they do business. It's one thing to share tests and dynamically update them, but it's another thing to share theorems and dynamically update those.
Phil Windley now has a great quote from Paul Graham's "The Hundred Year Language"... (The permalink to the message is broken for April 30 at this point.)
[Paul] Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches. Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today.
[Phil] The phrase accrete programs as a series of patches is so deliciously visual that it makes me smile.
So many juicy bits in Paul's keynote. I guess that's what makes a good keynote.
Since Phil will be sending some traffic my way, this is a chance to redirect you to a piece from OOPSLA 2002 related to the above quote...
Noble and Biddle's Notes on Postmodern Programming.
Paul Graham, in his by now famous "The Hundred Year Language" keynote at Pycon 2003, questions the future of parallel computing. I am a little more optimistic than he is, see if you agree...
I expect that, as with the stupendous speed of the underlying hardware, parallelism will be something that is available if you ask for it explicitly, but ordinarily not used.
In a hundred years I expect languages to express opportunities for parallelism better than they do today. I expect language compilers to plan for parallelism more than programmers using those languages.
I would use pH as an example of where this could go more maintstream.
This implies that the kind of parallelism we have in a hundred years will not, except in special applications, be massive parallelism. I expect for ordinary programmers it will be more like being able to fork off processes that all end up running in parallel.
Except in special kinds of applications, parallelism won't pervade the programs that are written in a hundred years. It would be premature optimization if it did.
On the contrary I think we'll be accustomed to parallel and concurrent computing through the use of simpler mechanisms that we have today, by and large.
So there will be much more parallel computing than we have today, but it will be simpler and mostly implicit. I think Paul Graham's OLTP/Workflow orientation is blinding him to the amount of analysis that takes place in the business world, and how much more can be automated in the next hundred years.
This video taped lecture demonstrates the benefits of computer science for non-majors, just people who want to improve their ability to think.
But, as I have pointed out: Computer Science is not a science, and its ultimate 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. I will defend this viewpoint with examples and demonstrations. -Gerald Sussman
If you are interested in computing and live near Salt Lake or Provo then Phil Windley will teach you how to think in this course that by all appearances is excellent.
I was fortunate to have a similar course with an emphasis on interpretation. Too many comparative courses are presented as a survey of disparate landscapes as opposed to a grounding in the fundamentals.
If you not in Utah, then look for similar courses near you. Indiana, MIT, Northeastern, Brown, and many others will have them.
If you are too far away then there are several on-line resources, e.g. on-line texts, Ars Digita University and some video taped courses like these from Berkeley that include Structure and Interpretation of Computer Programs.
KeithBa writes...
I also believe that OOP will be supplanted as the dominant programming model over the next 5-10 years as the XML and Web services model takes hold. I'm already building apps where I send hand-crafted SOAP messages within the application from one piece of code to another. Remember: the OS itself works off a message pump.
I agree, but we have examples already that are far simpler than SOAP/WS-xxx. Consider the open source Erlang system. Their messaging system is multi-language through the use of erl_interface and works with pure Java using jinterface.
Don Box writes...
My only point of contention is Sam's statement that when you control both ends of the wire, SOAP isn't the right answer.
I'm not convinced... For one, even in a homogeneous system, managing interface evolution in a CORBA/DCOM-like system is much harder than in a XML/SOAP-based system.
This might be a good argument if the choices were restricted to SOAP, CORBA, and DCOM. But remember, all three of these systems were intended for multi-language and multi-owner distributed interfaces.
If you truly own both end-points then you can provide very simple and transparent mechanisms such as those in Gemstone Smalltalk. Or far simpler, the open source Erlang.
And Don continues...
More importantly, as the supporting infrastructure for SOAP gets hardened into the (distributed and local) computing fabric, there is a lot to be gained from leveraging it. Today, this advantage isn't so obvious. Going forward, I think it will be.
No doubt there will be a lot to be leveraged as enterprises invest millions of dollars into a SOAP/WS-xxx infrastructure.
The question though is this the most efficient investment? Why?
The Web Services hype (and it is not much more than that today for most corporations) appears to me to be a "taking" in the making. If I controlled the purse strings I would sit back as long as possible to watch this stuff shake out. Let someone else spend the $$$ for now and then read the blogs that tell me what went wrong.
If I had to forge ahead with something I would do the simplest thing that could possibly work. I would look for the Web Services equivalent of Philip and Alex's Guide to Web Publishing
Andy [Hertzfeld] says "the hard thing about being a programmer is keeping track of lots of abstract things." I disagree. The hard part of programming is creating static documents (whether tectual or graphical) that result in correct dynamic interactions. This static to dynamic barrier is something most people don't cross with ease.
I'm with Phil Windley on this. (The quote above is from his blog). We struggle to simplify dynamic interactions even conceptually. And we have not even begun to figure out truly useful notations.
Toss distance and asynchrony into the equation and we are still very much at a loss.
From Infoworld's Web Services Report...
This declarative approach is the real essence of SOA, and of course it's not a new idea. I trace its lineage to MTS (Microsoft Transaction Server), which begat COM+ and J2EE. All these middleware technologies pull services (e.g., transaction management, connection pooling) out of components, and weave them into to the fabric in which the components are deployed.
We can (and should) go even 30 years back to discover some deeper roots of Web Services that run through but do not originate with MTS...
