Comments on: Are all languages leaky? http://therning.org/magnus/archives/321 Incoherent mumblings Tue, 06 Jan 2009 02:38:14 +0000 http://wordpress.org/?v=2.6.3 By: pozorvlak http://therning.org/magnus/archives/321#comment-82367 pozorvlak Tue, 16 Oct 2007 11:34:08 +0000 http://therning.org/magnus/archives/321#comment-82367 <p>Interesting. I think the thing is that C is (intentionally) a thin layer of abstraction over the machine: C abstractions map to their implementations in a very simple way. So, while it's very useful to know what your abstractions will become translated to, it's not especially onerous.</p> <p>Haskell's a much thicker abstraction layer. I've got myself into some horrible messes with laziness and space leaks: in fact, pretty much every time I try to write Haskell code to work with large input or to do long calculations! At this point, you really need to know a bit about how the garbage collector works.</p> Interesting. I think the thing is that C is (intentionally) a thin layer of abstraction over the machine: C abstractions map to their implementations in a very simple way. So, while it’s very useful to know what your abstractions will become translated to, it’s not especially onerous.

Haskell’s a much thicker abstraction layer. I’ve got myself into some horrible messes with laziness and space leaks: in fact, pretty much every time I try to write Haskell code to work with large input or to do long calculations! At this point, you really need to know a bit about how the garbage collector works.

]]> By: Magnus http://therning.org/magnus/archives/321#comment-82114 Magnus Thu, 11 Oct 2007 07:31:47 +0000 http://therning.org/magnus/archives/321#comment-82114 <p>Russel, I think I see what you mean. In C the leakiness happens already when trying to achieve basic functionality (e.g. I need to know that a local variable is allocated on the stack, so returning a pointer to a local array is problematic) while leakiness in Haskell doesn't happen until you try to achieve functionality with certain characteristics (e.g an algorithm executing in linear time or space). I guess this is an argument in favour of non-lazy languages in many cases, especially on embedded devices.</p> Russel, I think I see what you mean. In C the leakiness happens already when trying to achieve basic functionality (e.g. I need to know that a local variable is allocated on the stack, so returning a pointer to a local array is problematic) while leakiness in Haskell doesn’t happen until you try to achieve functionality with certain characteristics (e.g an algorithm executing in linear time or space). I guess this is an argument in favour of non-lazy languages in many cases, especially on embedded devices.

]]> By: Russell O\\\'Connor http://therning.org/magnus/archives/321#comment-82113 Russell O\\\'Connor Thu, 11 Oct 2007 06:54:46 +0000 http://therning.org/magnus/archives/321#comment-82113 <p>I'm not sure that Haskell abstraction is exactly leaky in this way. The Haskell language does not give operational semantics (giving denotational semantics instead), and hence does not provide any time/space guarantees (If I understand correctly). Therefore, any time you write a Haskell program with the intent of getting a certain space or time complexity, you are relying on compiler specific behaviour.</p> I’m not sure that Haskell abstraction is exactly leaky in this way. The Haskell language does not give operational semantics (giving denotational semantics instead), and hence does not provide any time/space guarantees (If I understand correctly). Therefore, any time you write a Haskell program with the intent of getting a certain space or time complexity, you are relying on compiler specific behaviour.

]]>