On Aug 7, 11:23 am, "Leslie P. Polzer" <[email protected]> wrote: > Maciej Katafiasz wrote: > > (I had a brief professional encounter with Rails, y'see, and it > > left a distaste for both), > > Not to carry this too far OT here, but I'm curious what you > didn't like about it?
Mostly the ever-present horrible hack culture. They're completely happy to use magic to pretend problems disappear, and then leave it largely unimplemented without even so much as hinting about it. So you're led to believe it works, but then walk into a trap you couldn't possibly see because the supposed magic obscured it. Prototype, which is in every inch Rail's brainchild, does exactly the same; in fact, there's an amusing class of bugs that depend their collective code and docs being crappy and misleading in an interleaving way. To give some examples (sorry about the lack of details, but it's been a long time): - ActiveRecord. The completely retarded join semantics which only make sense if you know how retardedly (and completely non-conformingly) MySQL behaves (but they still pretend to be DB-agnostic). The fact that projections will pretend to be of some model class, but will lack all the fields not included in the query, so methods will fail in random and amusing ways. - Rails REPL (aka console), which models only the C part of MVC, meaning you're SoL when you need to touch the M or V parts. And the fact that even the C part is all but useless without the magic request object(*) - Prototype releasing broken, untested versions. Which lead to a day wasted searching for a bug in my commits that broke our -dev server, despite it working fine on my own machine, before I realised that someone updated Prototype (1.5.1 → 1.5.2 or something similarly minor) and that they decided to do major refactoring in that version without testing, breaking previously-working features. The obscure, unpopular and definitely unused feature of popup completions in input fields. - Speaking of which, Rails & Prototype docs both suggesting that completing on custom values, not the ones shown, was supported and nonchalantly referring to it as "unless specified differently by the options", which took me half a day to figure out it wasn't actually and that "specified differently by the options" means "you're actually supposed to override the default get_completions controller and hack it into providing a reply doing what you want using the protocol you need to reverse engineer from what prototype then does with it". So I did, and using some cleverness I was even able to make it backwards- compatible with the ordinary invocations of get_completions, thus avoiding the need to un-break all the other sites in the code relying on it. To be honest, I can't remember if I ever got around to submitting the patch upstream :) - Speaking of which, the very "options" hash, which is always nonchalantly described by "as specified by the options" in the docs, before being passed through a twisty maze of ten undocumented function calls, all alike. Now, to be sure, a lot of the above, especially the lacking documentation on the protocols things are supposed to follow (which is made extra fun to investigate when the breaking code resides in a piece transformed by the CPS magic), applies to Weblocks. But in Rails it always felt as if they were perfectly fine with dirty hacks, and I never felt that Rails was even aiming at the right abstraction level anyway. In many ways Rails gives the impression of PHP built on a better (but still incredibly hacky) language. Sure, it's incomparably nicer to write in, but the culture of "works on my machine for the single use-case I had at hand, let's commit to the main tree as a builtin!" is similarly prevalent. Cheers, Maciej (*) that reminds me, WITH-REQUEST & friends should *really* be a part of our public API, not buried deep in the unit tests. Really. Unless it's there and I'm just missing something. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
