Uncut blocks of wood

Java wildcards need taming

2011-06-02T04:22:00.000-07:00

In this year's PLDI, there is a session where every paper starts with the gerund "Taming ... "
Seems like some computer science topics are inherently wild. And what else could these papers talk about than ... Java wildcards :)

Ok, ok, it's only two papers after all. Still, the shrewishness is real, because since Java wildcards were imposed upon programmers, we find ourselves running into weird situations where people need silly casts, or declare two variables of different types for the same value "to make the compiler happy".

Well, if you feel like turning it around and make the compiler unhappy for once, try feeding it this :)

// source:
// Ross Tate, Alan Leung, Sorin Lerner.
// Taming Wildcards in Java’s Type System. in PLDI 11

import java.util.List;
class C<P extends List<? super C<D>>> implements List<P> {}
class D implements List<C<? extends List<? super C<D>>>> {}

Finishing SOLA 2011

2011-05-10T13:14:00.000-07:00

Some pics from the SOLA run last weekend, after 11 km. I wasn't in shape at all, and for some reason was so tense that I had sore muscles in the shoulders (?) but it was good fun. I guess this is the smile of a person who is glad to be still alive :)

Prepared for SOLA 2011

2011-05-06T11:01:00.000-07:00

Tomorrow, there is a run around Zurich, called SOLA. Teams of 14 people. Thanks to Aaron Z, I am going to take part in it. This is the first time I'll take part in a competition - excitement!

Creative Deprecation

2011-03-26T03:07:00.000-07:00

I came across Zach Tellman's essay [1], and I find it really lucid.

quote: "There is a tension between knowledge and creation: by pursuing one, he [the technologist] retreats from the other."

Here is an essay (really, an attempt) to connect it with some things I have observed. I believe it is possible to draw a connection to what economists call Schumpeter's Creative Destruction.

Creative Deprecation

In large-scale software development it is possible to observe a large-scale pattern. One of the effects is that, while working on a development project, software engineers typically have to commit some time to learning new technologies outside of their project. This pattern consists of something like a cycle that relates knowledge about technology to creation of new technology. Here is an analogy to economy that may help clarify the scope of this pattern:

The opening up of new markets and the organizational development from the craft shop and factory to such concerns as US Steel illustrate the process of industrial mutation that incessantly revolutionizes the economic structure from within, incessantly destroying the old one, incessantly creating a new one ... [The process] must be seen in its role in the perennial gale of creative destruction; it cannot be understood on the hypothesis that there is a perennial lull.
—Joseph Schumpeter, The Process of Creative Destruction, 1942

What matters here is the system view of economy, the purported economic structure. "The" Economy is a productive chaos with too many factors to keep track of. And so is software development, we can also see it as a "system" of people learning, creating and applying technology.

The currency are artifacts of technology. Software (especially open source software) is easily accessible and usable. What is not so easily transferable is in-depth knowledge, experience about a particular piece of software technology. Every new technology (take something like Megastore [3], but also the Google Apps ecosystem), and also backward incompatible changes to technology take time to be learnt and taken up by software engineers. And integrating technology often creates something synergistic, that comes with its own characteristics.

Understanding the cycle

Let us look at the cycle. At the beginning of it, there is a team building something new that is supposed to replace something old, or change it (radically) for the better. In the middle of the cycle, people widely acknowledge that the new thing is better and it is worth investing into using it. Towards the end, people have spent enormous efforts in putting the new technology to practical use, in ways not anticipated by the initiators. As more and more people have embraced the new way, and project roll it out, shortcomings appear. In the end, the new technology has become the standard, and the old is considered something low-level or arcane.

This is very different (and sometimes conflicting) with what is usually understood under "software development cycle". The latter cycle is only concerned with a single piece of technology. It is part of large system of creative deprecation and interacts with it.

Optimizing the cycle

The constantly changing world of available technologies and the speed at which basic assumptions are replaced by new, different ones creates friction for the software developer: it means knowledge, which had to be built up, is becoming obsolete. It means, time and resources have to devoted to learning the new stuff, even if the functional specification of the new technology is exactly the same as the old.

Software developers are humans, and as humans we have limited cognitive capacity to learn: if a technology is sufficiently complex, we cannot start using it and learn it "along the way". And here, methods exists that can help optimize the learning effect. One example of this is prototyping: we build something limited, admitting that we cannot build the whole thing at once, and the intention is to learn.

The way forward?

Claiming that this aspect has been ignored by the software industry would be going too far. There are many processes and development practices which can be understood as a concession to creative deprecation, from unit testing over javadoc to IBM's original code reviews (where developers formed committees, printed source code on paper, read it out and discuss).

The difficulty in taking advantage of creative deprecation is that our methods of "measuring" knowledge are not very developed. What are the indicators? Quality of past contributions would be a great indicator, but we don't seem to have accepted indicators for quality of artifacts either (test coverage is probably a good start).

More challenges come from the fact that individual knowledge does not add up. A team can have a wizard that wrote the book on X, and be clueless about X when that wizard is on vacation or transfers to another project. Agile methods that try to increase the "bus factor" are targeting exactly this aspect.
Preferring "simple" APIs (meaning: APIs that do not come with a high learning "price tag") is another method, trying to minimize the number of public methods are other examples.

Modest, and effective proposals are to

acknowledge that knowledge cycle matters and be aware that reducing complexity, in the big picture, is at least as important as adding features.
leave room for individuals to acquire knowledge, even if it is unrelated to the project
control the cycle, by controlling time and scope of the destruction and mitigating the effects of obsoleted knowledge. For instance, alternate cycles of expansion (features, integration of new technologies) followed by contraction (optimizations, cut-over, deprecation, refactorings, bug-fixes and other maintenance) when planning a project.

[1] http://ideolalia.com/becoming-eloi-becoming-morlock
[2] http://en.wikipedia.org/wiki/Creative_destruction#Schumpeterian_Creative_Destruction
[3] http://highscalability.com/blog/2011/1/11/google-megastore-3-billion-writes-and-20-billion-read-transa.html

Yacc is of the Living Dead

2010-12-09T02:07:00.000-08:00

The scientific process seems to evolve towards something like pop culture and music industry. For starters, we have publishing houses and record companies.

And then, there is a scientific article with the title "Yacc is dead" [1] which, quite possibly, has reached more people than all the accepted papers of the conference to which it was submitted.

Russ Cox criticized this paper quite harshly in an insightful blog post [2].

So, in short, the paper proposes a method that yields all parse trees and claims that the approach is "efficiently on average". The authors run a benchmark, but of course a benchmark is not exactly a proof. Russ's argument (by regexp analogy) goes something like we can make up grammars that simulate NFAs. Since there are regexps whose NFA will have O(exp(n)) possible successful runs on input of length n, (maybe something like a*a*), getting all parse trees means asking for trouble.

Where I am not so sure is, whether the authors are really unaware of this. It is possible to understand "parses efficiently on average" as "works efficiently for the average grammar programmers want to parse". Writing an ambiguous grammar by accident is one thing, writing something like a*a* is something else. Agreed, a statement like "works well for the average grammar" does not really have much scientific worth -- and Russ's criticism still stands -- but indeed it may work out in practice.

The math that derives working parsers from their specification is beautiful... the issue for practical purposes is that there are are other approaches to combinator parsing -- these are the ones that should be compared with derivative-based method, not yacc.

There is at least one paper (journal publication) out there that shows how memoization can make top-down functional parsers linear [3?], unfortunately I cannot access it so cannot comment on how applicable it is here. What's next, DMCA for papers? <b>J'accuse</b>.

Regardless what is up with yacc or memoization, among functional programming literature, there is a plethora of papers that use parser combinators to achieve polynomial parsing (the first reference that came to my mind is Swierstra and Duponcheel's paper [4]), but the wikipedia page on combinator parsing [5] has a link to more recent -- 2007 -- work from Frost and Hafiz that looks interesting.

There are no conclusions here. Combinator parsing is not new, but with the rising popularity of Scala, it is pretty much alive and kicking. After all, it has a packrat combinator parsing library included. For my next parser, I will certainly use that one and not Might and Darais approach. Still, I think the approach described in Might and Darais paper has educational value and I sincerely hope the authors will come up with a longer, more polished version.

[1] Matthew Might, David Darais. Yacc is dead.

[2] Russ Cox. Yacc is not dead.

[3?] Frost, Szydlowski. Memoizing purely functional top-down backtracking language processors. Science of Computer Programming
Volume 27, Issue 3, November 1996, Pages 263-288

[4] Swierstra, Duponcheel. Deterministic, error correcting parser combinators.

[5] http://en.wikipedia.org/wiki/Parser_combinator

Romantic enthusiasm for verification

2010-08-19T20:54:00.000-07:00

Recently, a workshop got me interested in contract programming again. In essence, programming by contract means we annotate our source code with pre- and postconditions.


@Requires(numChars % 2 == 0)
@Ensures(result.length() == numChars)
String foo(int numChars) {
...
}

This is like saying "the only proper way to call this method with a numChars parameter that is even. You will get a nice non-empty string in return." Sounds like a deal.

There is probably a lot to say about contracts and how they can help developers understand their code. There are frameworks that will take these annotations and turn these into run-time checks. My interest is more in verification though. Automated program verification is really hard to do, because several undecidability results apply -- but in the words of Prof Jürgen Giesl this also means that one can always improve the state of the art.

The previous time I got excited by contracts was when I had the pleasure to host Prof Peter Müller at Google where he give a talk and demo of SpecSharp. The article Specification and Verification: The Spec# Experience gives a glimpse of the programming system the authors had built. An amusing quote from there: "When programmers see our demos, they often develop a romantic enthusiasm that does not correspond to veriﬁcation reality."

Let me state that dream here: a program is made of method calls. If the compiler, or IDE, "understands" the pre-conditions and post-conditions of method calls, it should be able to chain these "facts" together and achieve some form of "understanding" of the program. This can help developers add or change lines and get immediate feedback on whether the source code they write is correct.

Going back to the example above: imagine writing foo(3) in your IDE and having it underlined in squiggly red, with a mouse-over message stating "precondition numChars % 2 == 0 not satisfied".

Spec# translates the pre- and postconditions into Satisfiability Modulo Theories (SMT) problems which are then solved by the underlying engine called Boogie. Another SMT solver is Z3 which has a readable tutorial. Reading up on these, it is quite striking that Spec# is working on a real programming language, and that neat interfaces do exist between the layers of byte code, verification source and the nitty gritty predicate logic formulae.

And then, there still is the following flaw, quoted here:

At the moment you ﬁnd an error, your brain may disappear because
of the Heisenberg uncertainty principle, and be replaced by a new
brain that thinks the proof is correct.
L.A. Levin

Just kidding. Robert Pollack's article is concerned with the problem that we can come up with a system that will verify our program, but we won't necessarily be able to trust it, because it is a program itself. Here is the bit that is relevant though: "My guess is that tech-
nologies of automated proof search will be highly developed because of economic
pressure for reliable hardware and software, and these, applied as tactics to proof
checking, will make formal mathematics a practical reality in the foreseeable fu-
ture."

It seems we still have a long way to go before developers see the light in IDEs having some form of automated program verification. I have a hope that if one goes back to natural deduction style proofs, logical frameworks or simple logic programming with SLD resolution, it may be possible to write reasonable (logical) annotations and have proper support. Let (expert) programmers write more. Only experimentation can show whether this is a good idea.

Good news and minarets

2010-08-14T16:28:00.000-07:00

Good news first:

I got married to Şerife exactly one week ago : )
It is the blessed month of Ramadan, and my best wishes go to all who observe it.
the world has not ended yet.

Apart from that, today's news have been full of bad news from all over the world. Additionally, I had been reading a lot of stuff all over the web and naturally some of it had potential to pull me down (think Palestine, think victims of human trafficking). But today the Swiss news also featured Obama supporting religious freedom in the US.

I got curious about the http://www.thecordobafoundation.com/ and there found their journal called Arches. This proved to be quite fascinating, as the points of view expressed in those articles are so different from what one usually sees in the media. The last edition is Vol 3 Edition 5.

Not all of the Arches articles are my taste. For instance, there is this Kurdish guy who represent the home-coming of PKK guerilla in Turkey (which derailed the peace process very efficiently) as the "home-coming of members of a peace group" and describes how brainwashed the Turkish people are to misunderstand this event. Well, it seems in 2010 "peace groups" sport fashionable war uniforms, even when they lay down their arms.

The one article I like most is " Understanding 'Land of War' and 'Land of Islam' " by Dr Jasser Auda, pp.41.

'Land of War' is a concept that, unfortunately, has currency among some Muslims. For them, 'Land of War' is the essential clash-of-civilizations hypothesis. This glossary gives the definition: A land ruled by infidels that might, through war, become the "Abode of Islam."

In essence, there really are people who believe that in the "Land of Peace" they are free to cheat or lie. Maybe they think, Muslims will "conquer" this land one day, and then, only then, will it become necessary to act. It seems pretty clear that terrorists would subscribe to this idea.

It sounds silly to think of a country like Switzerland as a "Land of War". You would think that Turkey, which is mostly Muslim, would not qualify. Yet, I once overheard a discussion where somebody qualified the whole country of Turkey as un-Islamic, since "the women would not wear the veil there". Uh-huh. What can one say to that? Something is pretty wrong with people who think in terms of "Land of War".

This has been refuted many times, and practicing Muslims who take their religion seriously enough to do some research should know about the falsity. Dr Auda's article is special in that it is at the same time approachable by Muslims as well as non-Muslims, and reads like a sound scholarly discourse on the topic.

First, the article points out the difference between Shari'a and Fiqh: whereas the former is an ideal (like "Justice"), the latter is a necessarily incomplete, changing attempt to achieve justice by norms and rules (like "Law"). Then he places the "Land of War" concept in the realm of Fiqh. In other words, yes, there was a time and a place where learned scholars argued that outside the secure realm of the Islamic empire, things gets rough. Fiqh is and must always be adapted to social circumstances of a particular time and place. (My remark: A great book that explains why is Tariq Ramadan "Radical Reform")

Back to the article. Auda then thinks on how the "Land of Peace" should look like. Should it be predominantly Muslim? Should it have a Muslim ruler? Should its legal system be Shari'a compliant? Is it enough for Muslims to practice their religion.

He arrives at the conclusion that the proper way of viewing things is to see "Land of Islam" as synonymous with "Land of Justice". This has its basis in the realization that the purpose of "Islamic Law" is to ensure justice and well being. This includes Muslims rights to perform "public acts of worship". Among other things, this means construction of mosques, including minarets.

There, finally, is a great explanation of why many "Western" countries are better developed and why Muslims find it easier to practice their religion there. The legal systems of many so-called "Islamic countries" are not up to the task of actually achieving justice.

I am willing to draw the conclusion that it absolutely does not matter whether the laws were derived from the Noble Qur'an or not: what matters is if they are achieving justice (or Shari'a). Muslims can well approximate the "divine way of living" in a secular democracy. Also in democracies, humans make errors when deriving and judging law. They introduce bugs. It seems the legal systems of "Islamic countries" are still buggy.

Democracy is not a guarantee for justice. In Switzerland, a not-so-nice bug got introduced. At the time of this writing, building minarets is still forbidden in Switzerland. People voted on this on 2009-11-29, after a big smear campaign by the SVP. On the other hand, the constitution still claims that everybody is free to practice their religion, and that everybody is equal in front of the law. Am I the only one who sees a contradiction here?

Barack Obama supported building the community center (including their mosque) near Ground Zero, on the basis that Muslims have the right to practice their religion.

first baby steps with luatex

2008-05-05T00:41:00.000-07:00

ok, I compiled the luatex beta and was puzzled on how to run this.

Then I found Luigi Scarso's answer:


what about
$texmfstart texexec --luatex luatest1.tex

What is texmfstart? No idea, but "wer sucht, der findet"


$ locate texmfstart
/usr/local/teTeX/share/texmf.local/scripts/context/ruby/texmfstart.rb
/usr/local/teTeX/share/texmf.tetex/scripts/context/ruby/texmfstart.rb

I do remember having played with context ones, but I do not remember whether I installed context there. Anyway, the .rb extension is for ruby, so


ruby /usr/local/teTeX/share/texmf.local/scripts/context/ruby/texmfstart.rb texexec --luatex sheet06.tex

did what I wanted... mostly. It produces a .pdf but it looks very basic, the page numbers are on the top of the page, and so on. Well a good starting point nevertheless.

lost in multi-lingualization

2008-04-06T07:30:00.000-07:00

I figured out that my multi-lingual dictionary needs a multi-lingual website.

In web-design as elsewhere, i18n is quite a pain: one has to actually think what one wants before going off and doing something.

For my web dictionary and its associated websites, there is one obvious requirement: the text on every page should be viewable in various languages.

There are interesting links on the net on how to approach this systematically: I have found the following particularly useful:

the comments in W3C's q&a blog article Content Negotiation: why it is useful, and how to make it work

the EURESCOM report Multi-lingual web sites: Best practice guidelines and architectures

When looking for a standard encoding of languages as strings, the three letter languages codes (ISO639-2) are quite enough (ISO-639-1 are the two-letter ones). Of course, despite the thing being a standard, there is some fun to be had with e.g. deu == ger.

Apart from deciding, which languages to support, there is also a user interface question, and for my website, I consider this the most important. In times of Google, content can also be found if your website has a lousy user interface, but since I am looking for something that is fun to use interactively, usability takes priority.

That is why I need to ask myself: how would one select between languages? I think the best is to go with a hybrid approach:

have URIs of the shape domain/language-code/path and rewrite them to domain/path.language-code.extension (the dispatching described in the comments to the W3C article).

additionally have a footer with links (view page in language1, ..., languageN)

Pages should not be very long, so that the footer is visible. For added fun, I can later go into having facebook's wall-to-wall (two pages displayed side-by-side) layout to see the same page in two different languages, for translation and language-learning.

asp.net, and computerclubzwei

2007-07-03T23:04:00.000-07:00

About to start a web app... coming from a Scala and Java background, but my web hoster offers me php and asp.net -- which poison is tastier? I was set to go for php, although I don't like the language much. So I thought I'd give this asp.net stuff a try.

For my first timid steps, I was happy to have read the German Wikipedia entry, and the
beginning wikibook "Webentwicklung mit ASP.NET". This had a link to visual studio web express, which is free, and it rocks as an IDE (I am a big fan of Microsoft IDEs, although I do everything to avoid owning a Windows OS). I get curious about MonoDevelop, all this Emacs juggling is getting boring sometimes.

About asp.net proper, the difference in complexity seems ridiculous compared to php... but this is more a psychological thing. While I quickly hacked a phpinfo.php to test that scripts were properly executed on the server, asp.net development first started by installing an IDE. There are quite some concepts to learn, and here I lost interest. Compared to the jsp world, the "usine à gaz" factor seems the same (I also lost interest in JSP 2, my last activity was a struts-1 webapp).

Out of curiosity, I will try to connect to the mysql database on asp.net, and continue some experiments... and if that works fine, I might stick with it and get used to IDE land again.

---

Growing up in Germany, I have at least one seen a show called "computer club" - although I was too young to appreciate it back then. Apparently, they have recently started podcasting on their new site cczwei. It's fun to listen to this professionally produced piece of audio-layman-tech-journalism - for one who enjoys people talking about technical things in a simple manner.

Code-follows-Type

2007-06-25T23:41:00.000-07:00

Adriaan writes up something on Code-follows-Type programming. It's a neat technique that has a killer application: automatically generating pickling and unpickling code from your class definitions - without code generation, without reflection, without anything... wait, it says it only works for "representable" types.

2006-07-30T03:49:00.000-07:00

Again, a web designer might be interested in
Google's Web Authoring Statistics for best practices.

There are far too many articles about the GWT, but here is Dion Hinchcliffe's analysis of GWT's service abstraction.

2006-07-19T10:41:00.000-07:00

always good to remember some best practices in web development.

Ralf Laemmel and Erik Meijer take a head-on jump into xml object mismatch. More (or less) data binding.

I still haven't gotten to look microformats and wonder if I need to.

This Scala XML documentation needs some updating.

different takes on data binding

2006-07-14T10:40:00.000-07:00

Some time ago, Kathleen Dollard showed how to generate classes from an XML Schema using XSLT. I dislike both schema and XSLT, but I would understand why someone would need to use both technologies and have respect for everybody that plunges in that hell. However all those technologies together might serve to describe the problem rather than the solution

Pull parsing examples, also a while ago, is often demonstrated as a fast way to do data binding. We can find Chris Fry's writeup on XML pull parsing. It seems
Pull parsing will be available in JDK6

This pull parsing stuff ultimately looks better than all other APIs, because all the other ones can be implemented on top of this one.

typed scripting? typescript

2006-06-13T08:51:00.000-07:00

Types are good, but a language aiming to resemble JavaScript should leave type annotations optional wherever possible. Palsberg and Schwartzbach have something to say about type inference for object oriented programs.

What would types be good for? There's all those "message-not-understood" (and so on), but there is also fancier stuff like Session types for channels, or regexp-like types for semistructured data.

JavaScript is object based, but not class based. Abadi and Cardelli's "A Theory of Objects" is the standard reference on object calculi. "Type inference for JavaScript" introduces a calculus for modeling JavaScript.

Castagna provides an account on overloading in the publication that came out of his thesis, titled
"Object-Oriented Programming: A Unified Foundation". The thing with overloading is that it might give a more precise type to pattern matching statements, an idea that haunts me since ages.

JavaScript2

2006-06-08T05:38:00.000-07:00

Brendan Eich's XTech 2006 keynote JavaScript 2 and the Future of the Web mentions some deltas to the language. This is warmly welcomed on LtU, who add a new JavaScript department.

One of the typing experts sitting int the committee, Cormac Flanagan, has worked on SAGE: Practical Hybrid type checking for Expressive Types and Specifications[pdf]

Not to be confounded with ECMAScript 4, the next version of JavaScript 1, designed by committee ECMA TC39TG1. They get proposals from Mozilla guys, and recently published their Wiki, which also is half-heartedly discussed on LtU.

why those books? discussions with friends

2006-05-29T13:31:00.000-07:00

Edward Angel. OpenGL(tm): a Primer. ISBN 0-201-74186-5 A fascination with NeuroScience and displaying 3d graphics, ideally in a web browser. Unfortunately, we are missing a Canvas3D that supports this stuff. For the moment, there are Java bindings, and lwjgl looks like the way to go.

David Flanagan. JavaScript: The Definitive Guide, Fourth Edition. ISBN 0-596-00048-0 Actually I don't remember why that book is here, I get all the info I want from the net.

John C. Mitchell. Foundations for Programming Languages. ISBN 0-262-13321-0The style and notation of this book are of a beauty that makes me want to read it over and over again. Although I don't really have spare cycles to do more foundational stuff, the proofs are spelled out in a very clear, yet concise manner and it is inspiring.

Benjamin Pierce, ed. Advanced Topics in Types and Programming Languages. ISBN 0-262-16228-8 Here, I started with the chapter of typed assembly language, also with an implementation actually. Wouldn't it be useful to have a low-level VM for iron that interprets typed assembly code? and have an x86 backend at some point.

When chatting with my chap about my final project, I was surprised how rational I could tell him the objectives and problems that I am facing, things I have been trying to find out for a long time. And there I am just communicating it as if I had known it all the time. My reluctance to use *the language*, the advantages of using HTML for user interfaces, the insights into GWT and the architectural sketch and constraints of the system.

When receiving another chap's email I'm surprised at his argument for dynamic typing having become more differentiated, preferring LISP over Python. And it somehow makes sense, because uniform containers (like sequences and hashtables) seems to be what most of my obsession with iron is about as well. His CLOS speak is beyond me but I recall from the book that I forgot to mention that setting up some object system in those languages is not very difficult.

Abelson and Sussman. Structure and Interpretation of Computer Programs. ISBN 0-262-51087-1 Never made it to those later chapters, where writing a scheme compiler is given as an exercise. Opening this book again is due to my interest in doing dynamic typing via tags. However it just clashes with the idea of doing static checking for regular expression types. What gives? There should be some program analysis and type inference.

Benjamin Pierce. Types and Programming Languages. ISBN 0-262-16209-1 There's something about recursive types that makes me return to this book. It stems from my obsession of regular expression types for sequences. The iron language is supposed to have sequences as primitives, and do some type-checking for an xsd-extension based object-class system. Also, the type inference idea mentioned above can be nourished from this book.

forging templates Google style

2006-05-24T14:42:00.000-07:00

Well, not surprisingly Google have their own way of templatin.

forging hypertext templates

2006-05-22T09:01:00.000-07:00

The good old hypertext. What have they done to you, pal? Just look at you. JSPed all over. And all those taglibs hanging down your front.


<%@ taglib uri="/WEB-INF/tld/struts-bean.tld" prefix="bean" %>
<%@ taglib uri="/WEB-INF/tld/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/tld/struts-logic.tld" prefix="logic" %>
<!--Logon_Block_Start-->
<html:form action="/loginlogout/login" focus="username">
  <TABLE WIDTH="<bean:message key="block.size.x"/>" 
   ...

No, no, some other I may have done this to you myself a long time ago, but not again.
Joel is right, so facade elements with attributes and ognl and tapestry style it shall be.

editable, viewable, maybe even validatable and bindable. No use to go over the top with WebObjects.

so you want to get web programming right, eh?

2006-05-19T08:33:00.000-07:00

Programming should be done in a decent language. That language should be the same on client and server (and I won't tell you why).

All web scripting somehow started with JavaScript. You could embed it on your server side if you really want to.

One can target JavaScript (and also targets ActionScript) with the haXe language. It also has a server component, going through an Apache plugin.

The Links language promises to compile from a single source database updates and Javascript bits in your page.

OTOH, one can get a nice language, XML capabilities and leverage the whole Java shebang using the Scala language. However, the whole backend-multiplexing thing is missing as of yet.

so you want to start a blog, eh?

2006-05-18T04:23:00.000-07:00

No meta-discussion, no navel-gazing, no propaganda. No technical details.

Once again scanning the web for frameworks, I got lost in Apache MyFaces and Tapestry and of course Google Web Toolkit the new kid on the block.

Over lunch, a discussion on JavaScript turns onto the XML lane and I realize that is another something that is missing in that language, just like actors.