James provides a response to Danny's bare arse scenario.
I would add two things:
*Mark Weiser, "Source Code!," IEEE Computer, November 1987
I know, you're going to hate this idea. You're going to say "Windley's gone off the deep end!" and "I'll never use Microsoft's ID program!" and "Microsoft will turn it to commercial advantage!" All of those things may be true, but the alternative, in my opinion, is much worse. At some point, legislatures, spurred on by their constituents, will undertake to solve this problem and no matter how well intentioned, you'll lake that solution even less---I promise.
I may not like a legislated solution but it has some advantages:
But actually...
He said he couldn't give me his phone number or mailing address, and that he didn't have a boss who could talk to me.
Who do they think they are, the cable company?
From Ephraim Schwartz in Infoworld: "From everyone I speak to, it is a foregone conclusion that Web services are a less-costly alternative than other integration technologies."
I sure would like to see some analysis of what these folks are claiming. What costs are they including or excluding? What systems are being integrated? What is the environment (departmental, enterprise, external, global, regional, etc.)? What are the architectural components?
I don't doubt that web services in general are the direction. That's a fete accompli. How people are using them currently, and how they are accounting for their success or difficulty is a topic worth exploring in much depth.
Gordon Weakliem's not having fun anymore...
I think I've had it beaten out of me, I've spent too many nights and weekends chasing down stupid quirks, stuff that's not even programming, just accounting and janitorial stuff. I still read programming books in my free time, but most books just depress me. That thought occurred to me while reading one of the Agile process books, so I quit reading about process and started trying to find things that would take me back 12 years, back to when Pascal was neat, and everything seemed easy.
Every time I put fun and programming in the same thought, I go to Ward Cunningham, who still seems to find ways to have fun.
Lately I have been enjoying PragDave's Katas. These get back to the heart of programming and don't require VisualJ2ESharpPlus. Just me, Emacs, and Python.
I am surprised and not surprised at the lack of an outcry for simpler ways to program. My fear is all the good ideas and fun will be left behind.
But XML-RPC is fun. And Chandler looks like it could be the source of fun. Eclipse only looks like fun seen through a Jython lens. (Jython is the best way to get an interactive experience with Java classes!)
dotnet will have the Jython kind of fun eventually.
What I just wrote about interactive programming with various languages brought up an old thought, and I'm not the only one to think on this. But I've not read anyone else with this same angle. I wrote...
Lists, maps, arrays, even self-referencing structures can all be entered end edited in a command loop or workspace using a very simple (i.e. few characters) syntax. There are also the mundane (now that Java brought them to the masses) aspects of these languages like garbage collection and array bounds checking.
How I believe the Java-like family will get even closer to this experience is via XML. Complex structures (i.e. nestedt structures as well as "primitive" values) is fairly simple in XML. The Java family of languages will eventually make the leap from XML constants expressed as strings and DOM'ized via a library. They will leap to the world where the DOM and the expressions are "native". These will be the "self-referencing structures that can be entered and edited in a command loop or workspace" that Lisp programmers have been doing for 40 years.
Then someone will create a Java with transparent persistence with shared paging so the structures don't all have to be in memory. Oh wait, been there, done that (more than once), and literally have several of the T shirts.
Of course these language communities first have to get over their fascination with such things as "generics" and "partial types", etc. Think simple. How simple can you go?
Don Box disagrees with Jon Udell in this dynamic language discussion.
Jon writes: I think dynamic languages and interactive programming environments help make us better explorers and discoverers, and I think that's only going to matter more as time goes on.
Don counters: My confusion comes from Jon's conflation of dynamic languages and interactive programming environments... During the late 1980's, I used Sabre C[++]. Sabre was a highly interactive programming environment for C and C++... It's been almost 15 years since I've used Sabre or Smalltalk, but honestly I'm having a hard time remembering what you could do in say Digitalk's smalltalk environment that you couldn't do in Sabre.
I also used Sabre. Prior to Sabre I used Zeta C, which was a C implementation for Lisp Machines. (Get your head around that! Yes, Lisp Machines had Fortran, Ada, C, and other language compilers.) Zeta was even better than Sabre.
Language design absolutely makes a difference beyond interactive environments. This difference is what makes these languages good for exploration and discovery over more cumbersome Java-like languages.
Lisp, Smalltalk, (dynamic languages I have decades of experience with) as well as Python, Ruby, etc. have good support for not only making prototype code, they also have good support for making prototype objects and data structures.
Lists, maps, arrays, even self-referencing structures can all be entered end edited in a command loop or workspace using a very simple (i.e. few characters) syntax. There are also the mundane (now that Java brought them to the masses) aspects of these languages like garbage collection and array bounds checking.
If I had to do C or C++ programming I'd do everything in my power to use an environment like Sabre or Zeta. At a minimum I would use a conservative garbage collector (e.g. Boehm's) unless the delivery environment really could not support it.
Yes, there are languages and tools that are edging closer to the best dynamic languages. Coming from another angle we have ML, Haskell, etc. with their own advantages. But for overall programming experience, most common situations would benefit from a simple language and toolset like Lisp, Smalltalk, or Python that have been around for 10-40 years!
I believe a case could be made that more innovation is taking place with Wikis today than with weblogs. Clay Shirky writes...
A wiki in the hands of a healthy community works. A wiki in the hands of an indifferent community fails. The software makes no attempt to add 'process' in order to keep people from doing stupid things. Instead, it provides more flexibility, a crazy amount of flexibility, and intoxicating amount of flexibility, allowing massive amounts of stupidity and intentional damage to be done, at will, by roving and anonymous posters. And it provides rollback.
That captures it for me. Supporting evidence of my thesis include the Bliki and the Purple Wiki. Not to mention the Atom wiki.
Don Box responds... I didn't realize I was a static typing loyalist.
Don't look at me. I rely on my Bayesian categorizer (PDF) for such distinctions. 8^)
Chief Software Architect and Chairman Bill Gates has publicly described the company's goals to add support for model-driven development to Microsoft products leading up to the release of the company's "Longhorn" operating system, expected in 2005.
I am not convinced that IBM bought Rational for UML. The Three Amigos were last seen riding off into the sunset following the ascent of XP.
The IBM deal I think was driven by tools like ClearCase maybe, but more specifically for the embedded market.
Can MSFT make MDA shine? Maybe.
Don Box continues to come to terms with dynamic languages...
More and more, however, I'm less convinced the problem is with languages per se but rather is related to how dynamic linking and binding works in most modern object systems...
The problem is that we bake a fair amount of non-semantic information into the way their code compiles against those assumptions.
...then steps back with Perl as the red herring...
I don't think the answer is for everyone to adopt Perl - if that's our only hope let's give up now.
By "non-semantic information" I guess he means "syntactic sugar"?
In any case, I think Don is half right. It *is* about how dynamic linking and binding works in a system. But how that works is intimately associated with the language design.
Have you ever used an interactive environment for a Pascal-like language? It is a very different experience from using one for Lisp, Smalltalk, or Python.
I won't mention Perl. That's the red herring for static typing loyalists.
Victor Ng writes about Python's tuple syntax for length one tuples.
Not that I use a lot of explicit length one tuples, but here's something you can do instead. Redefine the tuple function to accept non-sequences. If so, just put them in a length one tuple.
Then you can express an explicit length one tuple as
def tuple(x):
try:
return original.tuple(x)
except TypeError:
return original.tuple([x])
tuple(x)
In terms of big picture ideas, open source is running out of things to copy. Here's something that hasn't been done yet.
Interesting claim about big picture ideas. I never thought of that.
I do agree that "smart clients" is a ripe area for innovation. I never used OpenDoc.
I wonder if Eclipse is a good platform for these ideas?
Are checked exceptions a good thing? Do they break encapsulation?
I don't think checked exceptions are necessary. I think they can provide value.
But the cost of maintenance of static checking in Java is not worth the cost. What is my evidence?
I am more productive in Jython, which is capable of dynamically handling checked exceptions at runtime without the cost of static checking.
Let me illustrate my point with an analogy.
Consider an application command processor. The application has many functional areas. Each functional area has multiple commands that can be processed.
I can define a command abstraction and a command processor that works on the abstraction, independent of the specifics of any one command and any functional area.
In this case the commands are encapsulated and the command processor only has to be written once. New commands can be added at any time.
Now say the commands have names. And say that optionally a command can be designated as "checked", i.e. that at compile time the command processor must declare its awareness that some functional area is providing such commands.
Has encapsulation been broken? No. The problem is that named encapsulations are checked at compile time.
Is this a good thing? You decide the value.
Does it have a cost? Yes. The command processor has to be updated whenever a checked command is added to the system.
Microsoft continues to get its dynamic language support going for the CLR.
Meanwhile using foreign function interfaces appears to be a somewhat viable approach for integration when SOAP/XML-RPC won't do...
From James' Cincom Smalltalk blog...
Also of interest is the fact that the JVM remains frozen, making sure that actual progress in Java-land is limited. Microsoft seems to realize that's a mistake, and looks like they will be extending and changing the CLR as time goes by (in particular, they seem interested in adding better support for dynamic languages). Meanwhile, the Java folks are stuck with an early 90's vision of what a VM can and should do....
Funny thing is... there is a fully capable instruction set in silicon underneath each of these VMs. But the source language has to fit through what in these cases are crippled VM instruction set "keyholes", losing all of the useful higher level information on the way, before getting executed in that silicon.
Starbucks is just trying to cover its costs. Sure, leasing a broadband connection with a Wi-Fi base is cheap. But add a billing system - secure login server, transactional database, credit card processing, tech staff, customer service operators standing by - and the outlay skyrockets to $30, $50, even $70 a day, particularly if there are lots of support calls. (Ironically, most of those calls will be about problems with the billing system itself.)... Wi-Fi isn't a luxury or even a commodity. It's a condiment.
Let's look at Wi-Fi in a different light. Where's the vision and the leadership? I believe Wi-Fi is the highway system, the printing press, and the bill of rights rolled into one mechanism.
If we leave out any of these three concepts then we lose.
When you drill an oil well, you don't go straight down, you curve and bend - maybe later when you find the reservoir, you will go straight down, but not during exploration.
Richard P. Gabriel's Patterns of Software book is now on-line (as a PDF noted in many Internet locations already). My favorite parts are in the autobiography.
A friend of mine, prominent in the patterns community, told me when the Design Patterns book came out he believed that book would extend the future of C++ by a decade. He may have been right. (Since then other factors such as Boost have had a big influence as well.)
I am here today to make a prediction myself.
I believe that the GCJ compiler for Java will have a substantial influence on that language's future, maybe extending Java's future by a decade. This compiler will itself boost Java on the server, and in conjunction with Eclipse/SWT revitalize Java as a key language for desktop applications.
Moreover a secondary effect will eventually be to influence Microsoft's dotnet approach.
GCJ is a presage of the end of the virtual machine.
From Loosely Coupled...
speaking the same language as someone else doesn't necessarily imply you'll understand each other
A nice thin book that should be a part of every computer science degree program is Understanding Computers and Cognition: A New Foundation for Design by Winograd and Flores.
And anyone who names his software "SHRDLU" has my vote.
