Comments on: On Language Design: Making Expensive Actions Hard

By: CJM

CJM — Sat, 27 Feb 2010 07:59:23 +0000

I have to admit, I don't buy it. You're no longer abstracting the calls and you'll have a hell of a time changing your code if you want to swap out the upstream implementation (what if your persistence provider is in memory?). All I want to do semantically is read a property (why should I create a transaction when no writing is involved anyways?).

One of the great things about abstraction is that you have reduced duplication of code. Your solution fails at this and requires nearly identical callbacks and transactions and whatnot to be created every time you want to do something (if you continue down this path, it makes sense not to factor the transaction block into its own function, because that would be hiding its real cost to consumers). Another great thing about abstraction is that it makes it possible to improve and change the implementation (and correct defects in it) without needing to modify the consumers. Actually creating all of the objects manually in sequence is well and good (and efficient, sure), but it doesn't exactly lead to code that can be maintained easily.

It seems to me that your solution is essentially 'make the programmer type more so that they get the idea that something is expensive'. The example that you provided is not necessarily expensive - you yourself mentioned that you could set up prefetching which would make the operation cheap. On different platforms, even without prefetching, the operation isn't necessarily that expensive. For that matter, what do you even mean by expensive (storage, processor cycles, end-to-end time, shared locks) - I'm guessing in terms of time? Even in the cases where it is always expensive, how is your solution better than creating functions with long names like 'getFatherOfObjectPleaseNoteThisTakesALittleWhileButNotQuiteAsLongAsFunctionX' to represent the functions that take longer? If you want approximate time cost information to be available, add it as metadata to the function if your language of choice supports it (eg [ApproximateFunctionTimeCostAttribute(ApproximatedCost.Expensive)]), or tell your developers to test their code (does it run acceptably fast? okay!), or tell them to use a profiler. Making complex or slow functions difficult to call isn't a way to program more efficiently, it's a way to irritate developers and design poor APIs.

By: Zef Hemel

Zef Hemel — Fri, 12 Feb 2010 20:39:54 +0000

> That's true, but the reason - abstraction - is valuable!

Abstraction is very valuable, but this is an example of a leaky abstraction. You think you're just doing a cheap getter call, but in fact it is really expensive. But of course, it's a trade off.

> Can you use those objects in the same ways as you could the equivalent Java objects (ie adding behaviour to the object)? Is their "life" limited to the duration of the async anonymous function, or could they, for example, be dumped in a queue for later use?

Absolutely, they're just regular objects, like Java objects. You can do with them whatever you like. Because of Javascripts extreme dynamic nature you can add any behavior to the object you like.

By: HolyHaddock

HolyHaddock — Fri, 12 Feb 2010 20:35:35 +0000

> In Java, it is difficult to predict which statements are going to be expensive to execute by inspecting the code.

That's true, but the reason - abstraction - is valuable! Relating your example to The Day Job, I can perform that ORM call deep in a data layer somewhere, pass the Person object for display - and when writing the UI code, I (or another person, or another team) writing the code don't have to know that there is a data layer. In your example, doesn't the data layer either need to know when the UI layer will need the parent, or the UI layer have to know about the fetch function from the data layer?

I don't really know Javascript, so the rest of this post is very interesting. I like that having taken that design decision, what would be incredibly verbose and impossible in Java is reasonably straightforward here. Can you use those objects in the same ways as you could the equivalent Java objects (ie adding behaviour to the object)? Is their "life" limited to the duration of the async anonymous function, or could they, for example, be dumped in a queue for later use?

By: Zef Hemel

Zef Hemel — Fri, 12 Feb 2010 13:53:04 +0000

Right, that's exactly the kind of thing you want to avoid.

By: Rickard Andersson

Rickard Andersson — Fri, 12 Feb 2010 13:51:36 +0000

I met someone from Sony Ericsson a while back and he told me about an issue they had with the address book in certain cell phone models. Scrolling through the list was very slow. Someone took a good look at it and it turns out, for every step you scrolled through the address book, about 60 queries were executed.

By: Zef Hemel

Zef Hemel — Thu, 11 Feb 2010 01:25:55 +0000

Thanks for that.

By: reddit

reddit — Thu, 11 Feb 2010 01:18:46 +0000

TLDR; I don't have implemented lazy fetching, but it's to prevent stupidness, look mum I've done an ORM!