The difference between Ruby and Python.7
rzwitserloot posted in programming on May 1st, 2006
Wherein I nail the one true difference between these two programming languages.
(more…)
The difference between Ruby and Python.7
programmeren deze zomer?5
rzwitserloot posted in programming on May 2nd, 2006
This message is in dutch as it only applies to residents of the netherlands.
Een leuk initiatief - de nederlandse variant van google’s Summer of Code: De nederlandse http://www.programmeerzomer.nl/.
Ik heb me ingetekent, kijken wat het wordt.
via Roel (blog komt er eindelijk aan, hoor ik van ‘m).
The Computer Is Your Friend!0
rzwitserloot posted in programming on May 3rd, 2006
Here’s an interesting story: X Window System has a critical security bug. Interesting, because of the way it was found: An automated code analyser noticed that some parentheses weren’t correctly formatted. The red flag generated by this automated analyser led to the discovery of this bug.
Needless to say it would be even nicer if such a code analyser runs as-you-type your code, instead of an afterthought like this. In effect this is a lot like Eclipse’s java warnings, especially if you throw in an extended set such as Argus Code Watch.
The vast majority of automated tests that currently exist or should be possible to write depend in no small amount on the analysable information in a code fragment. For obvious reasons, dynamic languages tend to have far less practically analysable elements in any given line of code. One mans kludge is, apparently, another man’s critical security vulnerability.
No more Exams. Ever?5
rzwitserloot posted in me on May 3rd, 2006
Just got my Cryptography exam graded. An 8 (out of 10). I have an interesting observation regarding the way I studied for this (Executive Summary: I read Wikipedia articles instead of the book), but for now, let’s just leave it at:
That was my last exam for my MSc degree. Just some presentations and reports left.
waiterrant0
rzwitserloot posted in Uncategorized on May 4th, 2006
I’ve reported on it before, but Waitterrant.net is a blog filled with bits of delectable writing about life.
I occasionally page back through history and this one really struck a nerve. If you ask me, the best of 2006’s offerings:
Limiting yourself a good idea?2
rzwitserloot posted in programming on May 4th, 2006
Two completely unrelated factoids gave me an idea. First, the factoids:
java’s java.util.atomic package contains utility classes useful for various threading-related activities, including more extensive locking abilities compared to the language’s own synchronized keyword. Currently, the locks through that package are actually FASTER - eventhough synchronized is built right into the language and can use the local OS/processor’s abilities to the fullest extent. The tricks employed by the java.util.atomic team will be adapted by the language team for forthcoming versions, of course, but its rather interesting that the team with the rather huge limitation of only relying on java’s basic code and not an entire underlying OSes worth of low-level libraries wrote the faster code.
del.icio.us is a bookmarking webservice. I trust most of my readers are familiar with it. They had to work with the limited abilities of web programming to make it work, in contrast to the Opera, Firefox, Internet Explorer and Safari teams (all famous browser engines) who had an entire OS to work with.
Even without web-centric del.icio.us features its a much nicer bookmarking system compared to what ANY of the aforementioned 4 browsers have to offer (and I’ve actually extensively used all 4). Throw in the inbox, del.icio.us/popular, and the notion that you can access your bookmarks from anywhere, not just from your own machine, and del.icio.us is no longer in the same ballpark, hell, no longer on the same planet compared to the bookmarking engines built into any browser.
Apparently, restrictions that cannot be worked around can actually help you make the right design decisions.
Neccessity is the mother of invention, indeed!
Next time there is a restriction that you might be able to work around, consider not doing that and instead coming up with a new way of approaching the problem.
PHP - experiences.0
rzwitserloot posted in programming on May 7th, 2006
Tipjar is progressing very nicely. Only been working at it in earnest for a week or so and it’s already quite far along - at least, the technical (non-webdesign) bit. Some experiences:
Many languages aren’t easy to learn right. That whole schtick about an experienced programmer picking up anything in 2 weeks time is a load of crock. You can probably make something sorta work with a spit and a prayer, but it will look downright UG-LY by the standards of the language’s gurus. The experience will either way be unproductive, and the result will be a hard to read, impossible to maintain mess. When I go and write python, I can do it, I can make whatever you like, but I’ll be inadvertently trying to do things in static-namespaces way so much, it’ll look silly.
That doesn’t really apply to PHP. For two reasons: 1) The crowd that usually passes for ‘PHP Guru’ is utterly clueless (no offense, PHP mainstayers amongst my readership) to what we in the real world consider programming, and thus your incompetence isn’t noticed, and 2) The language is utterly trivial. It tries no tricks, it gives you few shortcuts, and in that way you truely HAVE learned it quickly. The downside is fairly obvious, you can’t trick your way past interesting problems like you can in almost any other language for at least a subset of interesting programming problems.
In some ways this is actually a good thing, because I can read absolutely ANY PHP code without diving into books (presuming it’s small enough not to be a mess o’ spaghetti!). Something that absolutely positively never works with something like Ruby or Perl which both look like homer simpson swearing at you. A number of python constructs are difficult to follow as well. In java you can follow the language paradigms, but you’ll be clicking yourself silly on library calls (which in my book is far more feasible than the Ruby/Perl and to some extent Python approach, but that’s another story entirely). Reminds me a bit about my earlier observation regarding limitations.
The biggest problem is community. A real reason for liking or disliking a language (I positively love BOO, but it has no community to speak of) is the community. I had expected, from amongst other people Cris’s comments on the PHP community, that everything’s already been done. So if you have a problem, you google for it, and you get an instant walkthrough or code fragment and you can be on your merry way.
Crock of male cow excrement.
Any trivial problem I can solve by myself. Any complicated problem is usually something your average PHP programmer doesn’t even think of. Questions like: If PHP is stateless, and the random number generator has an empty initializer, where the heck is the seed coming from? If it’s coming from the timer, then my web apps security is officially FUBARed. Worse, the specs do NOT specify anything in particular, so even if I check that it works safely on one PHP implementation, it might not work on the other. Currently solved by reading /dev/urandom, though on windows machines that obviously won’t work.
Typical PHP: PHP tries its hardest to make you brainfart into a security headache.
Second example of this: slimstat is a PHP traffic analyser. I’m using it to track blog traffic. The default install instructions drop it in /slimstat off of your root dir, and anyone can look at it. If that isn’t bad enough, anyone can empty the database and clear out all your traffic data. I had to dive into apache’s settings and lock out everything except the local machine, then ssh proxy my way to the page. This process is not described, or even so much as hinted at, in the installation manuals for slimstat.
These are just 2 situations where PHP and the PHP community collectively prove that they couldn’t secure a lemonade stand. I’ve ran into many more. I’ve also had some non-security related problems, though far less, and far less pressing.
I have, however, merited PHP a little bit: It doesn’t neccessarily cause brain damage, only if you look too much at the community, and it is in fact quite useful for prototypes.
Fleeble the… webserver?3
rzwitserloot posted in programming on May 7th, 2006
I had a flash of insight 2 days ago. Fleeble might make for a very interesting webserver. Fleeble is an agent framework I developed for my thesis. The basics are: Backend is java but agents can be a number of languages (in theory), all agents have separate threads and memory spaces. Communication between agents occurs by way of channels (You send or receive from a channel, never from another agent). All communications are copies, which complicates communication a lot, but it allows a lot of flexibility in where agents run. Agents can seamlessly truck across networks and computers.
Some of the things a Fleeble-based webserver could easily pull off:
Use a limited (single digits, never going up, no matter how many clients) amount of threads to handle any number of continuous connections (COMET jokes and such). Think Digg Spy. Serving the entirety of digg spy requests using 4 threads. Simply. No fuss. Very readable, very short code. What web framework, pray tell, pulls that off nicely?
Use multiple different languages to serve parts of the same request. This is an extreme example, but in general, you can mix and match programming languages to your hearts content. Anytime you let communications go across channels, your app no longer cares about what, or where, the other side is. You can do 99% of the gruntwork in Groovy or Python or some such, with some complicated hook someplace else. The key here is that you don’t have to jump through hoops to make it happen. It’s no more difficult than sticking to the same language.
‘Hook’ into the system. Anywhere. You could for example track your traffic without requiring participating pages to insert some sort of link to counting code, like in the case of slimstat. Makes it very easy to hack on some temporary solutions.
Update running systems. You can load, unload, reload and otherwise mess with agents in a very flexible manner. Anytime your dataflow crosses a channel path, it’ll swap to the updated code. Provided that your communication structure doesn’t change, or is capable of handling the ‘old’ standard, it’ll work.
Continuity. Boot up one agent to handle the entirety of the session for a single user. Think wizards - where your application no longer ‘exits’ when the data’s been served. It just goes to sleep until the user clicks something, or some sort of event occurs. Also extremely nice when serving up a game or chat or other 2+-interaction scheme through your webserver.
There are a lot of embarrassing problems I still have to hash out. For example, right now I have no easy way of realizing that no agents whatsoever are going to handle a request, which means I can’t generate a 404… it would just time out. Possibly a novel approach to foil URL guessing schemes, but that would be an excuse.
Still, it’s a sufficiently different way of writing webservers that it would actually be adding something to the world at large even if it ends up not working very well. Unfortunately some competition to the tipjar idea is beginning to take form (Alper spotted it) so that obviously has priority, but I’ll be working more on Fleeble during my off-hours again.
With some luck both will take off 
English is a bad programming language.1
rzwitserloot posted in programming on May 7th, 2006
This list of actual newspaper headlines should be sufficient preliminary proof to make anyone question that idea.
Graduation Ceremony6
rzwitserloot posted in education on May 13th, 2006
Congratulations to Robbert Jan, Judith and Thijs for picking up their degrees yesterday.
The ceremony was… interesting. By which I mean boring.
They did fortunately realize that trying to speechify for all 45 applicants is a bit over the top so they split it up into 2 batches, each with their own room. Of course, such splitting further cuts down on the already mediocre opportunities to let some interesting people give a commencement speech of sorts.
I was decidely unimpressed. Not good because the Delft University of Technology (DUT) clearly wants it to be a big deal.
Read on for a play-by-play on why it sucked, and a simple plan at the end to fix it.
(more…)