Home
Beware of the Train [entries|archive|friends|userinfo]
pozorvlak

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| My moblog Hypothetical, the place to be My (fairly feeble) website ]

Haskell doesn't need macros, eh? [Mar. 6th, 2008|11:25 am]
[Tags|, , , , , , ]

A comparison of the Haskell argmunger with its Arc equivalent (or even its Perl equivalent) should make something clear. It's been claimed that Haskell doesn't need macros, because most of the things that Lispers need macros for can be done in Haskell using lazy evaluation and so on. But the argmunger example makes it clear that there are things for which Lispers don't need macros and Haskellers do - if not Template Haskell macros, then SYB or DRiFT or some other macro-like facility.

Lispers often say that coding in other languages feels like manually generating macroexpansions. I'm nobody's idea of a Lisp hacker, but I often feel like this when I'm writing Haskell. Which is why I'm learning about Template Haskell even though I'm not yet au fait with things like do-notation and monad transformers, which most Haskell experts would probably consider more basic. Would you choose before or after you'd walked to Moscow to staunch the blood from your severed arm?
link4 comments|post comment

Grrrr, banks [Jan. 28th, 2008|04:40 pm]
[Tags|, ]

Why, in this day and age, does it take two working days and £27 to send a few hundred dollars from Britain to the US?
link12 comments|post comment

Aaargh! [Dec. 19th, 2007|08:14 pm]
[Tags|, , , , , ]

An email from the people to whom I applied:
( I missed the point entirely, it seems :-( )
I wouldn't mind so much if they'd asked for a "Personal Statement" or something - to me, the term "Research Proposal" suggests that it should mainly be about the research that you propose to undertake. But apparently not. I've got until, er, tomorrow to submit another one :-(

In other news, hearken ye programmers unto Steve Yegge's latest drunken blog rant. I've been having similar thoughts myself, related to Bad Things that have happened to me with big codebases: it's a large part of why I'm so interested in the APL family*. But I'd like to stick my neck out and say that the way Steve feels about Java is the way I feel about Haskell.

* I note in passing that that page comes up first in a Google search for "APL lesson" - epic win!
link13 comments|post comment

Non-colliding monic arrows in XYPic [Nov. 26th, 2007|12:53 pm]
[Tags|, , , , , ]

For reasons that are increasingly unclear to me, I've been using the TeX package XY-Pic for the commutative diagrams (of which there are many) in my thesis and papers. If there is one and only one Right Way to do something, you can pretty much guarantee that XY-Pic will:
  1. do something else by default, producing horribly ugly output;
  2. only do the Right Thing if you utter some cryptic and fragile incantation in a language that looks like the bastard offspring of APL and the Black Speech of Mordor1;
  3. hide the details of said incantation away somewhere in the depths of the voluminous, poorly-indexed, verbose and maddeningly unclear manual.
As should be clear, I'm not a huge fan.

One of its more annoying characteristics is the way it handles tails of arrows, which (by default) start after the end of the arrow, so the tail invariably collides with whatever it was the arrow is pointing away from. Like this:
That was produced by the code \xymatrix{ A \ar@{>->}[r] & B }, which, while not terribly clear, is the obvious thing to try, and the only thing you'll know how to do unless you've wasted days reading the manual.

( Fortunately, there is a fix )

1 Thinking about it, XY-Pic is actually kinda agglutinative, much like the Black Speech...
link9 comments|post comment

Musings on COBOL [Oct. 8th, 2007|03:24 pm]
[Tags|, , , ]

In a world such as this one, filled with war, famine, impending ecological collapse and Celtic fans, it really ought to take more to horrify me than this. But I guess I'm shallow that way.

Before diving into the actual text, let's just take a step back and consider the implications: the University of Limerick was teaching their "introduction to programming" course in COBOL, in 2002 (and as far as I can see, still are).

[Non-geeks: COBOL is the Common Business-Oriented Language, an ancient language used on dinosaur mainframes with about as much style and joie de vivre as the name implies. The Jargon File notes that in hacker circles its name is "synonymous with evil", and Edsger Dijkstra famously commented that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."]

( Read more... )
link3 comments|post comment

In praise of implementation-defined languages [Oct. 1st, 2007|09:18 pm]
[Tags|, , , , ]

Implementation-defined languages come in for a lot of flak. Users of certain languages will point to their language's standards document as if it were self-evidently proof of greater inherent worth: a language that's defined by its implementation, it is implied, is always going to be a bit non-U. It may train itself out of its dropped H's and tendency to mispronounce the word "scone"1, but it will never have the true breeding that comes from a standards document.

Which is daft, because implementation-defined languages ( have some important advantages )

By the way, I'm not saying that all specifications are bad (a good one is an excellent thing to have) or that specification-defined languages have no advantages - I'm assuming that the advantages of specification-defined languages are so well-rehearsed that I don't need to repeat them. Anyone needing further enlightenment is encouraged to go to comp.lang.scheme and say "I think spec-defined languages suck!" :-)

Now for the second part of my rant: Haskell, as we know it today, is an implementation-defined language, defined by the latest CVS snapshot of GHC. "But what about the Haskell Report, and the Revised Report, and Haskell prime, and Hugs, and, er, those other implementations?" I hear you cry. Well, what about them? Every time I asked some question, it seemed, the answer would begin with "first download the latest version of GHC, then turn on these extensions..." A spec for a language that people don't actually use is - well, not useless, if it's sufficiently close to a language that they do use, but it ain't a specification as I understand the term. Everyone in the Haskell community seems to track the latest version of GHC for its new features. This is not spec-like behaviour. Now, as I said above, I don't think that implementation-defined languages are bad: quite the reverse. I just think it would save everyone a lot of bother and false superiority if the community could admit this to itself and to outsiders.

1 The O is short: "scone" rhymes with "gone", not "groan". Unless you're talking about the town in Scotland, when it rhymes with "boon". People who insist on mispronouncing this word around me will have their scones taken away from them and donated to the Pozorvlak Pedant-Feeding Drive.
link22 comments|post comment

What I was trying to say [Mar. 29th, 2007|03:19 pm]
[Tags|, , , , , , , ]

chromatic, in a conversation about domain-specific languages in Perl 6, put something I've been trying to say for a while into the correct words that would never quite come for me.
I can decipher and fix bad Ruby code, for example, because I know the underlying language.

You know Ruby's syntax maybe, but who says you know the domain of the business problem the code attempts to solve?

I maintain that that is much more important than syntax--and if you have undisciplined, barely-competent monkeys who cannot or will not write maintainable code, then your biggest risk is not that they might use powerful language features to do bad things that are hard to unravel.

Your biggest risk is that they will do anything. It doesn't matter what they do, if they have access to your source code. They may never know about symbol tables or run-time code evaluation or method aliasing or macros or code generation or monkey patching, but you can be sure that they'll pull a stupid trick such as writing files and reading them in line by line because they don't know how to use arrays.

They're barely competent! They're undisciplined! They're monkeys! Want to fix your coding problems? Start by getting rid of monkeys, not by complaining about powerful tools that competent developers might be able to use productively.
From what I've seen, all the safety features in the world will not prevent monkeys from shooting themselves and others in the foot. Paw. Whatever. Whereas good, disciplined programmers will be able to get great mileage out of supposedly dangerous features, by using them correctly (note that "using them correctly" includes not using them in cases where it's not a good idea). I might, of course, be wrong, but this has been my experience thus far, and this is why I'm finding it such a big adjustment to come to a language community that seems to believe the opposite.

[Remember that crack I made a while ago about how, in the limit case, the "guarantees over expressivity" philosophy would lead to preferring guaranteed termination over Turing-completeness? It seems someone actually does believe that. Disclaimer: I've only skimmed the paper.]

By the way, I came across chromatic's post from Piers Cawley's post DSLs, Fluent Interfaces, and how to tell the difference, which says something I've long suspected: that this whole (embedded) DSL business is mostly just a buzzword slapped on a lot of fairly straightforward and common practices.
link4 comments|post comment

Ten things I hate about Perl [Mar. 13th, 2007|01:08 pm]
[Tags|, , , , , , ]

brian d. foy says that you can't be an effective advocate for a language unless you can think of five things that you hate about it off the top of your head, the reason being that if you can't, then you don't know enough about the language to advocate it effectively. So, just to go one (or five) better, here are ( ten things I hate about Perl )
This is not to say that I hate Perl: far from it. I think it's a wonderful, fun language, with a great community around it, producing some insanely cool software (CPAN might be considered the world's premier laboratory for module and language-extension design). I am continually surprised that Perl has such a bad press, and gets such short shrift from the language-design community. You might expect that a language that breaks almost every accepted precept of language design would simply be a bad language, and no fun at all to use. Yet Perl does this, and has a fanatical community of users, some of them truly excellent hackers. This, it seems to me, is a datum point of enormous importance.

But anyway, I'd like to ask this question to the hackers reading this. What five things do you hate most about your favourite language?

* Unless you've set $[ to 1 - thanks, [info]paddy3118!
link19 comments|post comment

Haskell and pusillanimity, part the second [Mar. 10th, 2007|12:57 pm]
[Tags|, , , , ]

A while ago I wrote a post about what appeared to be the endemic pusillanimity of the Haskell community, tried to find more charitable explanations for my observations, and, I think, mostly succeeded. Unfortunately, the example I gave turned out not to be a good one: it turns out that it is possible to have integer-parametrized types in Haskell (though you have to go through Hell and high water to do so). But the other day, I remembered ( a much better example )
link4 comments|post comment

Haskell, guarantees and pusillanimity [Jan. 25th, 2007|06:10 pm]
[Tags|, , , ]

Many times in the course of my Haskell apprenticeship, I've had conversations of the following form:

Me: I want to do X in Haskell, but the obvious thing doesn't work. How do I do it?
Sensei (usually Duncan or [info]totherme): Oh no, you can't do that! If you could do that, then you could have a transperambic Papadopolous twisted asiatic sine-curve freezeglargle Windhoek chromium bebop.
Me: Er, come again?
Sensei: well, [note of horror creeps into voice] it would be really bad! You could get [thing that doesn't sound all that bad, really].
Me: But that's a good thing/Nah, that would never happen/would never happen in real-world code/that's a price I'd gladly pay.

( Here's why I think this happens - Haskellers prefer guarantees to expressivity )

So, Haskellers: am I right? More importantly, is this widely known? Is it explicitly written down anywhere? (The second article comes very close, but I don't think it gets there in full generality). Because it strikes me that it would be a good thing to tell newbies as early as possible, and also a good thing to have it explicit so it can be appealed to, or (better) debated.
link37 comments|post comment

Euler's equation considered banal [Jan. 9th, 2007|11:53 am]
[Tags|, , ]

The other day, I noticed someone with the equation ei π = -1 as their usericon. This equation, or rather the high esteem in which it is held by so many, infuriates me, and I'm going to try to explain why.

Actually, I have nothing much against the equation itself. It has a pleasant - well, not exactly symmetry, but you know what I mean. What annoys me is people who (in many cases, literally) think it's the final proof of the existence of God. It isn't. It's a slightly more sophisticated cousin of those "take away the number you first thought of, multiply by seven, and add the digits together; now, is your answer sixty-nine?" trivial results from Christmas crackers.

Here's why: it's a tautology. Not just in the sense that every mathematical theorem is a tautology, but in the sense that it's actually a very shallow result, following almost immediately from the definitions involved. Just think, for a minute, about how you'd define the numbers mentioned. π first, because that's the hard one. "The ratio of the circumference to the diameter of the circle" - OK, but that's pretty fuzzy: what does it mean? Well, the line integral around a circular path, divided by twice its radius. Do some more simplifications, and you'll end up with the following: "π is the smallest positive real solution to the equation sin x = 0". Now, how do we define sin? Since we're working with complex numbers, we're pretty much forced to use the power series definition (which acceptable rigour more-or-less forces us to use anyway). The result that exp(z) = cos(z) + i sin(z) [1] drops straight out, as does the result that cos^2(z) + sin^2(z) = 1 [2] (OK, the last one's not that straightforward).

Apply this to the term exp(iπ). From [1], we know that exp(iπ) = cos(π) + i sin(π), and by definition sin(π) = 0. From [2], cos^2(π) = 1; since π is, by definition real, so must cos(π) be, since the power series has only real coefficients. So cos(π) = +/- 1, hence exp(iπ) = +/-1. We're not all the way there yet, but note that the equation ei π = 1 would have all the acclaimed aesthetic properties of the true equation.

So, what may initially have appeared as a deep and mysterious result is revealed as nothing of the kind. Note that the only non-obvious fact I've used is the definition of π as a solution to sin x = 0, and if you think about it for a minute that's actually perfectly natural. And yet this result gets parroted everywhere, in spite of the fact that there are plenty of genuinely surprising and deep results out there. The insolubility of the general quintic. Yoneda's Lemma. The Four-Colour Theorem. Stuff like that. Edit: since we're talking about complex analysis, how about Cauchy's theorem, or better, the Residue Theorem? That blows me away. Or the other Cauchy's theorem, the one about groups?

As for "final proof of the existence of God" - no, no it isn't. Mathematical truths cannot prove God's existence. Quite simply, God has no say in the matter of whether ei π is 1 or -1 (assuming, for the sake of argument, that He exists). If politics is the art of the possible, then mathematics is the art of the necessary. Mathematical truths simply could not be any other way. They do not depend on the existence of the Universe for their truth. This infuriated me when I read the end of Carl Sagan's Contact: God couldn't have left His final message to his creation in the digits of π, because God had no say in what those digits would be. If He was going to leave us such a message, he'd have to do so in the digits of some appropriate physical constant (a dimensionless one, probably).

[Actually, there's a lovely story about a "mathematical proof of God's existence" given by Euler himself, recounted here.]

[Edit: in a few of my comments below, I've confused de Moivre's theorem (cis(nθ) = cis(&theta)^n) with Euler's formula (equation [1] above). Sorry for any confusion.]

[Further edit: [info]foreverdirt, whose userpic prompted this rant, has graciously replied:
That it falls out so vacuously from the definitions is one of my favourite things about the equation, but I'm sorry the emphasis some people put on it irritates you.
How entertainingly ironic :-)]
link39 comments|post comment

An open letter to the authors of Haskell documentation [Nov. 27th, 2006|01:15 pm]
[Tags|, , ]
[mood | annoyed]

When writing Haskell docs, please bear the following points in mind:
  1. Debug.Trace is not a tracer1. Please stop referring to it as such. In fact, could you please give it a more accurate name, like Debug.Print?
  2. If tempted to write the words "monadic" or "combinator", write "damn" instead. Your editor will strike it out, and then the sentence will be exactly as it should be.
  3. By all means, include code examples. In fact, please include more, as they're one of the most helpful forms of documentation. However, please first check that they actually compile. Yes, I'm looking at you, whoever wrote the docs for Control.Monad.State.
    [Edit: it seems this is a layout problem. OK, so I should direct my ire at the authors of the error messages and the layout engine. But it would be a Good Thing if the docs pointed this out - you're probably only going to be reading that bit if you're a newbie.]
    [Further Edit: I see that [info]totherme has elaborated on this point rather more diplomatically :-) ]
  4. Scientific papers are not an acceptable form of documentation. They're barely an acceptable way of doing science.
  5. On a similar note, having the bulk of the useful information in documents that are available online but not shipped with the install is damn-all use to those of us trying to hack away from a 'net connection.

1 Googling, I see that Haskell actually has a tracer, in the form of Hat. Must try that...
link19 comments|post comment

navigation
[ viewing | most recent entries ]