"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Friday, January 28, 2005

Lisp: an XML scripting language?

I guess if I had to sell someone on Lisp or Scheme today, I might describe it like this:

"Lisp is an XML scripting language."

More sexpr in Utah

Phil Windley is connecting language concepts, Scheme, and XML in his BYU programming language concepts course.

He has a simple excercise that makes the connection. The next step would be to blow their minds with SSAX.

Update: Phil Windley has a page for his students for running SSAX. To gauge how similar Lisp is to XML, how natural the mapping, the SSAX translation of Phil's original classroom example is identical except SSAX wraps Phil's translation in a list to indicate that is the top of the document...
(*TOP* (phil's data))

Naturally Dull

"Naturally dull, I’ve forgotten Zen activities"
- Isshi Bunshu (1608-1646)

Thursday, January 27, 2005

Testing Interfaces

Another blog item on testing.

This one asks whether the tests themselves should alter the interface of what's being tested. i.e. should the test have a back door for peeking into the black box.

My opinion is, emphatically, no. Not for the kinds of tests created while test-first programming.

An impulse to check on the internal state of an object while test-first programming is an indication of one or two things:

  • The test is being perceived too much as "testing" and not enough as "designing".
  • The object itself is probably too complex. Fix the design.

A Future so Bright?

Um...

Avid sailor Craig Venter has trawled for microbes in the Sargasso Sea and discovered more than a million new genes and 1,800 new species. Among them are organisms that thrive on carbon dioxide. Venter hopes to re-engineer some of these unique microbes genetically, into "designed species" that may reduce environmental CO2 levels, as well as provide new foods and energy sources. "Biology can do much more sophisticated chemistry than the best chemists," says Venter.
Hey, I suspect biology can do much more sophisticated *biology* than the best biologists as well!

I'm not sure I want people tinkering with CO2 consuming microbes any more than I want us putting fossil carbon into the atmosphere in the first place.

Test-First Programming

Frank Sommers writes...

I find myself violating this tenet of XP very often. I do test all my code, but often only after I've already written that code. Why does this one XP rule seem so out of place to me? ...

I like to think of refactoring and testing as editing. When writing an article, most writers first create an outline, then write the content, typically in a few sittings, and without regard to mistakes, typos, sentence structure, etc. Only then does an author spend most of his time on editing, fine-tuning, and polishing the article.

I think this seems out of place when "testing" is perceived to be a testing activity rather than a design activity. Rather than not testing first, try taking on a new perception of what it means to "test" software.

The way I view test-first programming exhibits the same outline -> content -> polish flow. In my perception, the "outline" is the short list of tests I think I want to write over the next hour or so. This list of tests is just a list of names, each name being some *design* feature that needs to be developed. Each name will show up in the design.

Then the "content" is the expansion of a name on the list into code:

  1. One or a few function calls or message sends.
  2. One or a few assertions about what is true afterwards.
  3. The other code needed to setup the calls, implement the assertions, and teardown.
  4. Then when this content breaks, the test framework tells me what's wrong.
  5. The rest of the content is missing... I have to write the code that implements the calls.
  6. When the "test" part of the content does not break, the initial draft is complete.
This content (the calls and assertions) is design information, an expression of a design contract. I am not testing something already conceived. I am in fact conceiving of something, creating something, designing something new: an expression about a system and an assertion about what is true given that expression.

As soon as the content is drafted, immediately I begin to polish that draft, consider how it fits with the other content, and how the content itself could be better expressed through reconsidering the names and parts and assertions.

So I see test-first programming as a way of designing. It happens to be a way of testing as well, which is good because a program has to be tested in ways that an informal text does not.

Wednesday, January 26, 2005

Exactly

A note to Sean McGrath from Steve Jensen in Sean's comment section...

Thanks for plugging Erlang: even if it doesn't end up being heavily adopted, it at least moves people in the right direction.
Exactly. I like what else Steve wrote...
We need to move from using semaphores and monitors to lock global state towards thinking of the world as partially ordered and asynchronous.
Someone asked Joe Armstrong at his Lightweight Languages 2002 presentation what synchronization mechanisms Erlang has. Joe responded, "Two. Send and receive."

Exactly.

Why...

...is Sharepoint the suckiest thing on this planet?

Monday, January 24, 2005

JSON: The Fat-Free Alternative to XML

JSON is the JavaScript Object Notation for writing "smart clients" like GMail in JavaScript without bulky XML messages. JSON-RPC is a simple RPC mechanism like XML-RPC. (Via Slashdot.)

I suppose this could also be based on YAML which is more rich than JSON, yet still not as complex as XML. I've not seen a mapping, in the few minutes I've looked, from JSON to XML, such as what's been defined for YAML.

Sunday, January 23, 2005

Communication

As seen on the XPDX Yahoo group...

Thanks for all the comments... One respondent said XP depends on communication, but I work in a corporation.
I guess that corporation does not "empower" their employees enough.

We Won't Get Fooled Again?

Scott Rosenberg writes...

The Bush inaugural marked the final transition of the Bush-family ideology from old-school conservatism, with its abhorrence of abstract schemes of human perfectibility, to a messianic idealism so divorced from reality it gives even sympathizers like Noonan the willies. Bush's vision of human perfectibility may be shaped by born-again fervor rather than socialist theory, but that difference doesn't make its collision with reality any less dangerous.
and writes...
This speech wasn't just soaring rhetoric. It was a lighter-than-air burst of helium verbiage -- lofty language untethered from the perplexing world we occupy and from the messy events of the last four years, sentences floating off into an empyrean of millennial vagaries.

The world is a simple place to Bush... His "untamed fire" is the cathartic inferno dreamed of by people who are confounded by a world they know is out of their control.

Thank You, Ken Anderson

Thank you, Ken Anderson, for your contributions to JScheme. There have been many times when I needed access to Java functionality but not the Java language per se. JScheme makes that kind of programming pleasant and productive. One of Ken's contributions was the Javadot notation which is a large part of ease of this Scheme/Java integration.

From Tim Hickey, another of JScheme's creators, via Chris Double...

I'm sorry to bring you the very sad news that Ken Anderson, one of the co-developers of JScheme, died last night...

Ken touched many lives and brought many communities together.

Saturday, January 22, 2005

Lisp and Concurrent Programming

Bill Clementson has a huge list of Lisp-related concurrent programming references. And if you haven't looked at Erlang yet, it is a list-based semi-functional language. Too bad it doesn't use Lisp syntax.

Bill refers to Dirk Gerrits, building an Erlang-like concurrency mechanism in Common Lisp. Something like this was done for Python as well, called Candygram.

Also related is the ETOS compiler for Erlang that generates Gambit Scheme, which scales as well as Erlang/OTP.

The mind spins, concurrent thoughts swirling all around.

This and That in Politics

I'm reading this and that near each other in my bloglines. They both alarm me for reasons that are not dissimilar.

PyCon DC 2005: IronPython

I didn't see anything on IronPython at the March conference, but Sam Ruby pointed out the keynote.

Structure and Notation of Computer Programs

Agreed...

We're not so much building on the programming state of the art as continually have each generation of programmers rediscover it.
-Bill de hOra

Thursday, January 20, 2005

OOP Is Much Better in Theory Than in Practice?

Lambda the Ultimate discusses the merit of an article as well as its content. Again against the object.

I think OOP is better in practice than in theory. But then I value practice more than theory.

Guessing from the Terminal

Mountains of wisdom from the Mountain of Worthless Information...

Next time you're in a meeting with folks and somebody asks you how long you think it'll take, be sure to tell them whether this is a "from the terminal" sort of guess, or a "from the ground" sort of guess. The difference? Until you've been-there-done-that, and have something against which to measure their requests (meaning you have some kind of experience with the things in question, ideally having built something like it before), your estimates are likely to be all "from the terminal" guesses, and highly likely to be wildly off base.

Smug Lisp Weenies

John Stephen Jacob Anderson, apparently a SmugLispWeenie if there ever was one, writes...

Python was the subset of Lisp that was understandable by C++ programmers.
Being at least a former SmugLispWeenie myself I am having trouble disagreeing. Which is not to say Python is bad, it just loses in certain significant ways that Lisp does not.

Update based comments:
"outside of the CS department"

Ouch.

I think Lisp is safely outside the CS dept. If we could get it *into* the CS dept. maybe things would improve a bit.

"Listing those significant ways"

Syntax extension, syntax itself, closures, continuations (Scheme in this case), to name the top of my list.

I would also include as a result of these, Lisp is a good vehicle for language experimentation (or just defining new object systems), whereas Python provides a simple object system it is more restricted in where you can take it.

Which is not to say that I would not choose Python over 90% of the industry's languages. I would.

Cairo as well as OpenGL

From "The (Re)Architecture of the X Window System" a progress report on Cairo...

This integration of the familiar PostScript operational model within the native application language environments provides a simple and powerful new tool for graphics application development...

Cairo's rendering algorithms use work done in the 1980's by Guibas, Ramshaw, and Stolfi [GRS83] along with work by John Hobby [Hob85], which has never been exploited in Postscript or in Windows. The implementation is fast, precise, and numerically stable, supports hardware acceleration, and is in advance of commercial systems...

Cairo is in the late stages of development and is being widely adopted in the open source community. It includes the ability to render to Postscript and a PDF back end is planned, which should greatly improve applications' printing support. Work to incorporate Cairo in the Gnome and KDE desktop environments is well underway, as are ports to Windows and Apple's MacIntosh, and it is being used by the Mono project. As with Xft2, Cairo works with all X servers, even those without the Render extension.

Also regarding X and OpenGL...
Using OpenGL as the basis for the X server itself will place X objects such as pixmaps and off-screen window contents inside OpenGL objects allowing applications to use the full OpenGL command set to manipulate them...

Whether the "core" X graphics will require any OpenGL extensions is still somewhat an open question.

In concert with the new compositing extensions, conventional X applications can then be integrated into 3D environments such as Croquet, or Sun's Looking Glass. X application contents can be used as textures and mapped onto any surface desired in those environments.

I think this is huge. (Yes, even huger than Avalon). Turning X, per se, into a legacy window system within a portable, modern vector and 3D graphics environment. Just remember, Don't Fidget With Widgets, Draw!

Where did those OpenGL patents go, again? Oh. Yeah. Now I remember.

Via Miguel de Icaza. (Microsoft must be wetting their pants trying to get de Icaza to sign up with them. I'd like to see the offer sheet.)

From the "What's That Again?" Department

From CNN...

"Poll: Nation split on Bush as uniter or divider"
Well then, apparently we have our answer.

Models for Backwards Navigation

Nice alternative implementation of a continuation-like web mechanism for languages without first-class continuations.

Unwittingly explains the *conceptual* model of continuation-based web servers. Languages with continuations offer a better *programming* model by simplifying the web programmer's *mental* model.

If you are familiar with web programming but unfamiliar with continuations, read this one first to get the concept, then read about continuation-based implementations.

Wiki and Comment Spam

I've not written my own wiki or blog system, and not thought about this problem at all. Given that, what if a form of "email authentication" was used to approve wiki edits and blog comments? (I think I've seen this somewhere but can't get google to remind me where.)

  1. Someone edits a wiki page or adds a comment.
  2. The change is suspended until "authenticated".
  3. At this point the person enters an email address (of some determinably accountable, non-transient nature).
  4. The change or some indication is sent to the email address.
  5. Upon receipt of the response or via an http form in the email, the change is accepted.
  6. In addition to other filtering and governing, the site now also has an email address.

Tuesday, January 18, 2005

Being FIT

Will Stott writes about using FIT via Excel.

Proof Carrying Code

I've only read a surface amount about Proof Carrying Code. In spite of my default stance on types, I am interested in ML and Haskell style type inference. So this book looks interesting, covering both topics and then some.

Via Lambda.

Can You Have It Your Way?

Guido's latest wandering around the world of type checking are disturbingly non-committal. I'd like to see his thinking get back to root causes and work forward to solutions. As it stands he's kind of wandering around the space of semi-solutions to unspecified problems.

Uninteresting and not a good use of my time at this point. If you've read this blog you know I am not interested in types much if at all. But whereever you are on the spectrum you most certainly would benefit from language changes being rooted in clearly outlined problems statements and solution explorations.

Monday, January 17, 2005

Objects are Easy? (Maybe Not)

A comment on Scott Rosenberg's blog post about concurrent programming...

Herb Sutter's analogy to object- oriented programming is completely bogus - OO is a bag of tricks for making it *easier* to write programs (often at the expense of making them a little slower), and especially easier to debug and maintain those programs; parallel programming makes it *harder* to write programs, and dramatically harder to make them correct, debuggable, and maintainable. It's just not going to happen.
First I would argue that programming with objects is not easier. But then the question is easier than what? The commentator does not say.

Objects are a code organization mechanism. As the complexity of a system grows, objects help through organizing the complexity. Progammers can use objects to focus on specific problems without being overwhelmed by uninteresting aspects of the system.

But objects are not easy. However I would agree that concurrency is even more difficult, especially given the languages and tools of the past several decades.

The commentator appears to be making an assumption though that the languages and tools of the past will not improve and there will be no incentive to improve...

As a software engineer with over 20 years experience, including a good deal on highly parallel machines, I can tell you for sure that there is not going to be a revolution in software development. Explicit parallelism is just too difficult to get right in general, and the applications that benefit from it have already been optimized for multi-cpu machines since the 1980's.
This sounds a lot like previous infamous predictions like no one needing more than 640k RAM.

Objects are hard, but they offer better notational organization. Processes are hard too, but they offer better dynamic organization. We just need better notations and tools for processes and someday someone may be writing something like "concurrency is a bag of tricks for making it *easier* to write programs".

The same commentator adds in a subsequent comment...

People don't get smarter, so this problem is not going to be solved no matter how much Intel would like it to be.
The same might have been said about programming sequentially before objects, or even modules and structured procedural improvements. The software industry has gotten smarter, perhaps not as quickly as any of us would like.

Friday, January 14, 2005

The Io Programming Language

A friend has been playing with the language Io. I spent an hour or so with him on it. Very interesting.

Io is small prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self, NewtonScript and Act1 (prototype-based differential inheritance, actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).
The language has an interesting evaluation, reflection, and delegation model. Io has a syntax that does not always require an explicitly denoted receiver for a message. Someone just learning Io can scratch their head once or twice figuring out what's going on.

On the whole though Io is a very simple language with what looks like a simple CPython-like implementation. For programmers looking to understand the "prototypes and delegation" approach to object-oriented programming (as opposed to "classes and inheritance"), then Io seems to be a simple way to dive in deep.

Playing a bit with Io felt a lot like the pre-CLOS days of Lisp in the 1980s when there were a lot of experiments with object systems like ObjVLisp, OakLisp, Loops, etc.

Wednesday, January 12, 2005

Scaling to Thousands of CPUs

From Shahin Khan in the Register...

A major shift is coming. Over the next few years, your ordinary applications will be able to tap into systems with, say, 7,000 CPUs, 50 tera bytes of memory, and 20 peta bytes of storage. In 2005, Azul Systems will ship compute pools with as many as 1,200 CPUs per a single standard rack...

What would change about application design if you could do this? Well, think back to what applications were like when you had just 128K of memory in your PC and a 512KB hard drive. The difference between the capabilities and flexibility of applications in those days and now is the level of improvement that we are talking about.

It may take more than a few years to get to these numbers for most of us, but I think at that point the change will be even more dramatic. Unless once again the software industry (you know, the "agile" industry) once again is too slow to keep up with hardware innovation.

One reason why I'm getting back into Erlang after tinkering with it several years ago. I want to understand how to think in terms of processes being about as cheap to create as objects are in other languages. One neat thing about Erlang is the sequential aspects of the language are so spartan, the programmer is forced to think about processes.

A single Erlang node on a single CPU today can comfortably get into the tens of thousands of dynamic processes. What would your system look like running hundreds of thousands or a million dynamic processes and lot of activity is spent collaborating with other systems also running at that scale?

See "Apache vs. Yaws" (Yaws is an Erlang-based web server)...

Yaws is still functioning at over 80,000 parallel connections.
The Java community is discussing a new protected-private keyword. This reminds me of the saying about rearranging Titanic's deck chairs.

Thursday, January 06, 2005

Message to Tim Bray

Larry Maccherone writes in a comment...

I wanted to post this to Tim Bray but his blog didn't allow posts. I've worked with a group here at Carnegie Mellon called the Fluid project. They have developed the ability to statically assure that your concurrency model matches your code. The tools also make it trivial for you to indicate your concurrency model by guiding you in adding minimal annotations in the code (think javadoc).

The fluid web site.

The publications (including Aaron Greenhouse's PhD thesis).

I post it here as a guide to how this might be done in dynamic languages but also to help Tim out with his java concurrency issues. Could someone see that it gets to Tim?
LMaccherone ..at.. cmu ..dot.. edu

Testing Interfaces

Ian raises some concerns about testing interfaces in Python...

Unit tests aren't going to test across the boundaries where people are proposing interfaces -- between loosely coupled components.
I am not sure I understand this point. Say I give you version 1 of a component and the tests deemed "sufficient" for that component. Then I give you version 2 of the component and the tests. If you are able to run version 1 of the tests against version 2 of the component, that should be a reasonable indicator that your own use of version 1 will be compatible with version 2 of the component.

As the provider of the component, I need to know nothing about your own use of that component, for reasonable definitions of "sufficient tests".

Note also that interfaces are more explicit about contracts between components than tests will be. For instance, an interface might demand a method which is not yet being used in your code or your usage; the interface makes it explicit that this method should still be defined, and so predicts future developments, not just current developments (half-implemented dictionary interfaces are a common example in Python, where interfaces would motivate people to finish the work).
The original scenario was an upgrade to a component breaking backward compatibility. If an upgrade provides a new feature then your old code has not used that feature yet. I would not expect that to break backward compatibility.

If an upgrade requires an old feature to require a new method of its old consumers, then that *would* break backward compatibility. However I would expect a reasonable set of tests from the component provider to demonstrate this failure on their part to keep their old customers happy.

Or two interfaces can match methods and signatures, but include extra information about the semantic differences between those interfaces; because it doesn't use duck typing, you won't accidentally mix semantics (you have to explicitly say which, if any, of those interfaces you support). This is particularly a problem with interfaces that define only a small number of methods, or use common methods like __call__. The only way to test these is with system tests, and system tests are always incomplete, there's always some code path or combination you haven't tested.
I guess I would need a specific example that cannot be tested by a unit test. Certainly there are "big" tests that require a lot of "units" to execute. But if each of those units were developed and updated by a series of "unit" tests then I would expect those tests to represent the "differences between those interfaces" as they exist within each unit.

I am having trouble addressing this issue in the abstract. If it is a frequent problem, I would look for ways to avoid it or break it into smaller problems. Maybe this is a scenario where changing the language would solve the problem. I just don't know, but I suspect there are simpler ways to solve the problem on the basis that I have used Python and several languages like Python and I have not run into this scenario. That doesn't mean it isn't real, just that I have not recognized it.

More Ways to Give and Help Children

In addition to my two favorites, Anders Jacobsen is asking bloggers to include these organizations on our blogs. For each of us that does, he'll donate to the British Red Cross. Thanks Anders! I think UNICEF is a good organization to have at the top, reading about their concern for child safety given the number of orphans resulting from the disaster. Pray to change the hearts and minds of people who would take advantage of children like this.

International aid organizations: UNICEF (United Nations Children's Fund) United Nations' World Food Programme Medecins Sans Frontieres / Doctors without Borders (donate!) CARE International The International Federation of Red Cross and Red Crescent Societies UK/Europe: Disasters Emergency Comittee (DEC) - comprises a raft of aid agencies, including the below and others British Red Cross Oxfam Save the Children UK North America: American Red Cross Canadian Red Cross Save The Children Oxfam America Anders Jacobsen: Webloggers: Give to tsunami victims and I'll give too!

Crying Out Loud

All of a sudden blogs are not about an ongoing discussion?

Gordon and Ian both write about the reaction to Guido's posting very preliminary thoughts on what would be a controversial change to the Python language.

The question they raise is this: does the reaction imply that Guido has to be somehow more "careful" with what he chooses to write?

This question puzzles me. I am assuming Guido published his thoughts in order to *get* a reaction. Should the kind of reaction he gets be considered a problem?

Dictators had better have thick skin. Let's assume he can handle it and continue to speculate. That's what blogs are for, right?

You publish your thoughts, I'll publish mine. The result will be a web of thoughts, and presumably this will be better for the whole community as compared to being afraid and secretive.

People don't "need to chill". People need to *write*!

Tuesday, January 04, 2005

I Must Be a Type Magnet

OK, I'm not resisting responding to some comments on the interface type declaration issue.

Interfaces are something that two of the major "framework" systems in Python (Zope and Twisted) have both found missing and wandered off in search of their own solution. If such a system existing and was codified into Python it would make it a lot easier for myself and others to actually rely upon bits of code crafted by other people; specifically feeling warm and fuzzy about you not going around and changing something deep in the guts of your modules that I am not going to find out about until five weeks after updating to the most recent release.
I have found that framework upgrades work best when there are sufficient tests available with the framework and sufficient tests for the system using the framework. These tests reduce the magnitude of lots of problems, especially the scenario described here.

Are you saying that even with sufficient tests, from the supplier and in your own code, you are still getting surprised a month into an upgrade?

If not, which do you think would be the lowest risk experiment for addressing the problem: writing more tests for the framework and your code, or changing the language?

(Note: I am *not* asking if you think type declarations would in some way address this problem. I *am* asking which of these two alternatives would be the lowest risk experiment.)

Monday, January 03, 2005

Freeze!

A big problem with Guido's considering type declarations for Python is that there are now at least three significant implementations of Python. Disregarding how you or I feel about this specific proposal, any big change in the language will put further distance between the implementations or impose a heavy fine on those implementations that are trying to keep pace.

Given the momentum in favor of Python over the last year, if I were the BDFL of Python, I would freeze the language at the 2.4 specification for a few years. This would allow the other implementations to catch up, and allow the CPython implementation to focus under the hood on implementation improvements.

I'd have to see real evidence of pain and suffering to want to extend the language significantly. Let other languages try new ideas, but Python should probably stay close to the current definition which has brought it to the threshold of something big.

Of course Guido's current thoughts just exist on his blog as far as I know. Real changes to the language based on these are a long way off. They could have an ill effect on the current momentum just the same. At the least they could suck energy away from more immediate concerns.

Comments are enabled for the concept of a moratorium. No type checking debates here please.

The Road to Ruin

The dictator is leading us astray and we're on the road to ruin. Sad just when things were looking up.

I thought I wasn't going to write about this anymore, but I can't believe my eyes. Just as Python is getting to the table with the superpowers.

I don't want to comment on this. Sorry, comments are disabled no matter how much fun more type checking debates might be!

Gartner Buys Meta

From The Register...

"This transaction is an exciting opportunity that will give us increased depth in key sectors, geographies and markets, and an increased ability to seize revenue opportunities with the addition of META Group's well-trained, successful sales force," said Gartner's CEO Gene Hall. "In sum, the acquisition will make Gartner a stronger company with increased opportunities for growth and greater resources to offer clients."
I was impressed with Meta's presence and insight at a conference they held a few years back, and with some recent content. My experience with Gartner has been spotty, but lately I've been finding some interesting white papers in their library.

James Robertson has more perspective on Gartner than I do.

Pimp My IT Ride

Chad Dickerson writes...

Smart IT shops should limit unneeded complexity at every turn, choose their customizations carefully, and turn a deaf ear to the siren song of the perfectly customized solution...

In the heat of the moment, no one thinks about what these one-of-a-kind customizations are going to mean down the road.

Do you think "service oriented architecture" is going to solve this problem? Can solving this problem be profitable?

Process Models

Bill de hOra writes...

There's no question that too much business logic is locked up in middleware and systems programming languages. But we need to avoid the industry standard hype cycle on these technologies and be clear on what they can and cannot do...
Process modeling has to balance agility and formality. We cannot allow to happen to process modeling what has happened to data modeling. And then we have to take back data modeling and fix *that* too. Related note.

Out of the Bottle and Into the Box

Daniel H. Steinberg writes...

Let's ship Jini, JXTA, and the Java APIs for Rendezvous along with the JVM. What if easy dynamic distributed networking was available from and to every Java enabled device.
He expands on this in a larger column.

3MLOC

Via Chris Double...

The runtime source code is 3 million lines of Java and C++. That's way too much for what it does...

This includes a mix of awk, sed, shell scripts, and indeed, Scheme! Yes, the JVM source includes jscheme.jar, used to generate some CORBA classes.

Sunday, January 02, 2005

Games

I played a few traditional games with family and friends New Year's Eve and yesterday at a friend's New Year's Day open house.

  • Rummy Royal -- We played for a couple of hours on New Year's Eve. It's been a long time since I've played this. The great thing about it is the variety of each round; you start with a chance to choose or bid on an alternate unseen hand. You can bet on an ace showing up in your hand. Then you play a poker hand by choosing five of your cards. Finally you play all your cards in a Rummy-like game. I pretty much broke even for the night.
  • Scrabble -- This was about the worst game of Scrabble I ever played. At one point I had all consonants. I foolishly traded *all* of them in, and came up with all *vowels*. At this point I had three of the four 'u' tiles and two of the four 'i' tiles. Why didn't I keep some of the consonants? The biggest problem was the play went from the middle of the board down into the lower corners and none of is had a way to build upward.
  • Sequence -- I had never played this game before even though my wife says we have it somewhere! This is a good game for adults and kids to play together. The rules are simple, the pace is moderate, and there's a good bit of chance, but opportunity for strategy to win out.
Some friends were telling me about "Speed Scrabble" but we didn't play. Next time; it sounds fun.

One Startling Sentence

PJE writes in a comment...

He's not saying adding enough negative numbers makes a positive -- although your phrasing sure made me click on the link out of mathematical curiosity!
Which is of course why I wrote that, and is drawn from the idea of One Startling Sentence.

But I chose two startling sentences. (One is the title itself.) I thought of a third, but thought then that was too much.

Take Back Your Data

Again Andrew Newman...

There is a common theme in the IT history towards more freedom. I don't mean free like in free speech, I mean free like in free will.

Lock Free Programming

Andrew Newman points to an article on atomic variables in Doug Lea's concurrent package for Java. Is the attention on concurrent programming going exponential?

More Than Two Wrongs Might Make a Right?

Oliver Steele seems to conclude that adding enough negative numbers may have a positive result. I'm not sure I get all the way to the same conclusion, but the argument is unique.

Update: OK, I definitely do not get to the same conclusion. Saying a type declaration "does a poor job of each scenario, and that means it does a good job of doing them all at once" is a leap I cannot make.

I don't see Oliver addressing the cost side of the equation sufficiently for his benefit side to come out greater. I think the costs can be overcome with creative work, but I'm not sure that's where I'd want my most creative thinkers working. Making type declarations optional alleviates costs, but why bother? I am just one who does not see the benefits.

Since Oliver already points out weaknesses in any one of the scenarios, there is no point attacking them individually. I cannot argue against the whole because I don't see a complete equation that can be analyzed. But I will point out some glaring problems he's passed over.

  • Documentation Providing f(a: String, b: Integer): Boolean rather than just f(a, b) is a weak argument. What are f, a, and b? Those names, well chosen, will tell me more than String, Integer, or Boolean. Moreover using Smalltalk's keyword syntax you have even more expressiveness than this Pascal style.
  • Early error detection Test-driven development eliminates the gap between coding and testing. There is no "earlier" time for detecting type errors.
  • Discouraged from writing tests If your language is so bad that programmers are discouraged from writing tests, my friend, well, type declarations are not going to make up the difference.
This is the last post I will make on type declarations for the foreseeable future. Feel free to comment, but don't expect a response.

I have another post to make responding to PJE, which I have learned is *not* about type declarations per se. Coming soon.

Saturday, January 01, 2005

Coming out of the woodwork

Another prediction...

10. Microsoft will increasingly play the patent card when competing with Linux. Although company officials have downplayed the extent to which Microsoft is threatening customers and partners with the risk of patent-infringement lawsuits if they go with Linux, we hear this is an increasingly key piece of Microsoft's competitive strategy. With Microsoft vowing to file 3,000 patent applications during fiscal 2005 alone, we expect the company to rattle the patent sabers even more in 2005.
Some background...
Microsoft has been slowly but surely deemphasizing its Passport digital-identity service for more than a year. But Passport increasingly is being pigeon-holed as a service for Microsoft properties only.
Another definition of the term "long tail"?

More Predictions

From Bill de hOra, tongue in cheek he says. We'll see...

java.util.concurrent will be a talking point and will produce a rash of articles and guidance as developers weep like children in the face of Doug Lea's 3rd edition of CPIJ.
Doug Lea's collection and concurrent packages have been one of my favorite features of Java for years. This would be a great prediction to come true.
Microsoft will try to hire Doug Lea.
I'd be surprised if this has not happened already. Does dotnet have anything like his concurrent package?
Everyone gets bored talking about AOP.
On the other hand, what if everyone realizes AOP is a nightmare from another era and moves to more simpler and expressive programming languages?
[Rich Internet Application] hacking hits the offline/online sweet spot as developers get fed up waiting for browsers, virtual machines and UI toolkits to evolve in response to Web Sites Which Are APIs... 2005 witnesses a revolution in how most developers are prepared to use obscure languages in production scenarios... The terms process-oriented, crash-first, concurrent message passing, and little language enter mainstream developer lingo. By the summer everyone gets closures and they replace IDE support as the popular distinguishing factor between languages. People start fooling with Erlang after they realise EJabberd is written in it and Herb Sutter's Fear and Loathing in Concurrency article scares the beejesus out of everyone.
Great predictions.
IM becomes a viable alternative to the heavier Grid and P2P technologies for integrators and data crunchers working at federation and Internet scales, but will initially be frowned on as a simplistic and inadequate for 'real work' - the debate will initially look like a rerun of WS-* v HTTP/XML
Nice. No tongue in cheek needed.

Finally...

Patrick Logan and Ehud Lamm become superstars.
Hmm. Tongue must be partially in cheek. Ehud certainly deserves credit and publicity for Lambda.

On the other hand, I don't look good in Spandex and I don't have much of a stage presence.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.