Irmen's blog

Yoda Conditions en andere nieuwe programming jargon

http://www.globalnerdy.com/2010/05/09/new-programming-jargon/

Bevat juweeltjes als deze:

Pokemon Exception Handling: For when you just gotta catch ’em all!

en deze:

Shrug Report: A bug report with no error message or “how to reproduce” steps and only a vague description of the problem. Usually contains the phrase "doesn’t work."

En eindelijk een leuke naam voor een techniek die ik al een paar jaar gebruik: Yoda Conditions

Over dat laatste:

This is actually quite a common idiom on languages that use == and =. If you put a constant on the LHS of the expression the compiler will generate an error if you use = accidentally rather than == for equality checking. Quite a few C or C++ programming types actually recommend doing this, and the principle would apply to C# or Java as well.

Tevens helpt het om null-pointer errors te voorkomen.

person.getName().equals("harry")

kan nullpointeren als getName() null teruggeeft. Maar

"harry".equals(person.getName())

is equivalent en nullpointert nooit want je kunt altijd een string constante vergelijken met een eventuele null. Scheelt dus weer een bug (of een extra if, of een try-catch)

What's in a long: 64 bit? Of toch 32?

Vanaf eind jaren 80 toen ik mijn Amiga 500 kocht, heb ik eigenlijk altijd gewerkt op een 32 bits operating systeem en CPU. Pas recentelijk heb ik een PC met daarin een Intel Core2 CPU die 64 bit ondersteunt, en daarop Windows 7 64-bits. Ik heb ook een Mac Mini met een Core2 CPU (ook 64 bits dus) met Mac OS X 10.6.

Onlangs ben ik weer eens in C aan het programmeren (ugh, maar het gaat om een aanpassing aan Python dus dat maakt het weer goed). Het wordt dus eens tijd om rekening te gaan houden met wat dat nou betekent, 64 bits, als je aan het programmeren bent.

Ik kwam er namelijk achter dat er een subtiel verschijnsel optreedt waar ik tot nu toe geen weet van had. Kort samengevat gaat het om de lengte van een long. Het blijkt dat op een 64 bits machine deze niet altijd 64 bits hoeft te zijn. Lees verder voor de details.

Use my stuff! It will save you almost $300,000 !

Use my software, it will save you almost $300,000!

http://www.ohloh.net/p/pyro

http://www.ohloh.net/p/snakelets

Mijn oude CORBA versus SOAP artikel

Om te voorkomen dat hij kwijt raakt link ik nog maar eens een keer mijn oude CORBA versus SOAP artikel. Dit schreef ik ergens in 2002 omdat ik vond dat SOAP bagger was en alles wat CORBA al had nog een keer aan het uitvinden was maar op een slechtere manier. Mijn mening is wel iets genuanceerder tegenwoordig, maar ik blijf een aversie hebben tegen SOAP.

Anyway, hier is het artikel: CORBA_vs_SOAP.odt (Open Document Format). Het staat ook als PDF op de site van de Object Management Group zelf.

Compensated sum (Kahan summation): a+b is niet c

Een rij floating point getallen optellen op de normale manier levert een steeds groter wordende afrondingsfout op. Er bestaat een algorithme dat deze fout behoorlijk verkleint: Kahan Summation.

Ik heb het even geprobeerd in Java en ten opzichte van de absolute precisie die je krijgt door BigDecimal te gebruiken voor de optelling, leverde dat het volgende resultaat:

• 100 random doubles: normal sum error: 7.105427e-15 ; compensated sum error: 0.000000e+00
• 10000 random doubles: normal sum error: -9.094947e-13 ; compensated sum error: 0.000000e+00
• 1 miljoen random doubles: normal sum error: -1.338776e-09 ; compensated sum error: 0.000000e+00

Pas zo'n beetje vanaf 1 miljoen waardes wordt de normale error groter dan 1e-10, dus tenzij je echt absolute precisie wilt zou je gewoon normale optelling kunnen gebruiken... Of je kiest ervoor om sowieso BigDecimal (arbitrary precision decimals) te gebruiken voor dit soort 'kritieke' optellingen. Het is veel langzamer dan doubles optellen, maar als het niet om heel veel waardes gaat is dat wellicht verwaarloosbaar.

De Kahan summation was bijna even snel als de gewone optelling, en leverde in al mijn tests een fout op van nul, dus in speciale gevallen is dit een interessante optie. Let wel op de problemen die je kunt krijgen met optimizing compilers: als die slim genoeg zijn, dan optimaliseren ze het hele algoritme eruit zodat er een normale optelling overblijft. Zie het Wikipedia artikel voor meer info.

Dit is de code voor de compensated sum:

double compensatedSum(double[] numbers)
{
    double s = 0.0;
    double c = 0.0;
    double y;
    double t;
    for (double number : numbers) {
         y = number-c;
         t = s+y;
         c = (t-s) - y;
         s = t;
    }
    return s;
}

History of programming languages!

1987 - Larry Wall falls asleep and hits Larry Wall's forehead on the keyboard. Upon waking Larry Wall decides that the string of characters on Larry Wall's monitor isn't random but an example program in a programming language that God wants His prophet, Larry Wall, to design. Perl is born.

Zomaar 1 random 'fact' uit A Brief, Incomplete, and Mostly Wrong History of Programming Languages. Erg grappig En nog behoorlijk actueel ook want het loopt helemaal door naar Scala uit 2003.

SOAP: The S stands for Simple. Or not?

Back in the days, I wasn't a real fan of SOAP, so to say. (CORBA vs SOAP). Today I came across the following blog entry: The S stands for Simple

It's hilarious. It hits the nail on the head, and I can't really say anything else to justify my still strong aversion to SOAP. Judging by the number of comments and the general state of mind they convey, I'm hardly alone here. Isn't it incredible that SOAP remains that overhyped buzzword thingy in a lot of organizations?

Release early, release often... of Gletsjer model?

Hm, veel open-source aanhangers zijn ook van mening dat dé manier van OSS ontwikkeling "release early, release often" is. Dat wil zeggen dat je dus vroeg en vaak nieuwe versies uitbrengt, en zo de vaart erin houdt en gebruikers gauw voorziet van aanpassingen en verbeteringen.

Mijn eigen project Pyro is denk ik een goed voorbeeld van het tegenovergestelde.

Pas zojuist heb ik een beta versie van de nieuwe 3.6 versie de deur uit gedaan. Meer dan een jaar na de vorige versie.

• 2007-02-12 Pyro-3.6-beta
• 2005-10-07 Pyro-3.5
• 2004-05-29 Pyro-3.4
• 2003-08-14 Pyro-3.3
• 2003-04-23 Pyro-3.2
• 2003-01-19 Pyro-3.1
• 2002-11-20 Pyro-3.0

Ouch.

Maar is dit een kwalijke zaak? Ik weet het eerlijk gezegd niet. Ik werk niet zo veel aan Pyro, omdat het eigenlijk een heel stabiel stuk software is, en het is min of meer feature-complete. Tevens zitten alle tussentijdse wijzigingen die ik maak wel gewoon in CVS ingecheckt, dus als je wilt kun je altijd een tussentijdse versie ophalen direct uit CVS. Een andere belangrijke reden is dat ik gewoonweg niet zo veel tijd heb om eraan te werken. En ik ben de enige ontwikkelaar. Dat beperkt de ontwikkelsnelheid nogal, vanuit praktisch oogpunt.

Wat wel een beetje raar voelt is dat de allereerste Pyro versie stamt van omstreeks 10 jaar geleden (ergens eind 1996 geloof ik), en dat Pyro sinds versie 2.0 op Sourceforge staat, wat dus sinds januari 2001 is.

Pyro's ontwikkel model is meer als een gletsjer lijkt het wel. Heel vroeger begonnen, stabiel en voorspelbaar, kruipt langzaam maar gestaag vooruit. Ik heb er geen klachten over gehoord tot dusver.

Scaling systems

Software system's scalability is not that simple as you might think. According to a blog posting on 'adding simplicity', it boils down to much more than a simple "I can handle more users". We need to consider six scalability vectors:

• Transactional
• Data
• Operational
• Deployability
• Productivity
• Feature time-to-market

Those six vectors are interconnected in different ways. All in all a good read: "You scaled your what?"

Law of Demeter

The Law of Demeter, also known as the don't talk to strangers principle of low coupling in software design:

The Law of Demeter was originally formulated as a style rule for designing object-oriented systems. "Only talk to your immediate friends" is the motto. The style rule was discovered at Northeastern University in the fall of 1987 by Ian Holland.

A more general formulation of the Law of Demeter is: Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Or: Each unit should only talk to its friends; Don't talk to strangers.

Basically it can be formulated like this:

A method of an object should use only the following kinds of objects:

1. itself
2. its parameters
3. any objects it creates/instantiates
4. its direct component objects