358 reputation
16
bio website smokingkangaroo.com
location Melbourne, Australia
age 31
visits member for 3 years, 2 months
seen Jul 21 at 22:04

Jul
17
awarded  Critic
Mar
19
comment Is it a code smell if you are frequently creating an object just to call a method on it
Messing with singletons and double-checked locking to get something equivalent to a simple function/procedure is a far bigger code smell to me!
Mar
19
comment Is it a code smell if you are frequently creating an object just to call a method on it
In my opinion, it's a language smell showing the weakness of "everything must be a class" analysis.
Mar
18
comment Do Design Patterns Stifle Creativity
@Amy Yes, but there's a big difference between "here's a problem, here's a solution, here's how I came up with it" and "here's a pattern, memorize it so you can apply it to these problems in future". You want to teach the ability to generate solutions, because patterns can only ever apply some of the time, so they'll need that ability no matter how many patterns they know. If I were teaching a course including patterns, I'd probably do it by setting exercises designed to make the students notice by themselves that there were common concepts in the solutions to the exercises.
Mar
18
comment Do Design Patterns Stifle Creativity
@dotslash For the same reason that IQ tests are heavy on maths/logic: they have some value and they're easy to test. That said, in my jobseeking as a programmer I didn't encounter them in interviews all that much; I'm Australian though, so maybe there's a difference in fashion.
Mar
18
answered Do Design Patterns Stifle Creativity
Feb
9
comment Critique of the IO monad being viewed as a state monad operating on the world
Are programming languages like Mercury and Clean that use explicit world-state passing to provide a declarative model for IO fundamentally wrong?
Feb
9
comment Critique of the IO monad being viewed as a state monad operating on the world
But forever (putStrLn "Hello") isn't like [0,1..], surely. Your proof isn't particular to worldState, therefore it also applies to the regular state monad. So forever (someModificationWith "Hello") is also denotationally equivalent to ⊥. I'm completely unsurprised by that result; it isn't productive in the denotational semantics, and what the computer is doing operationally while we wait forever is irrelevant. Same thing for forever (putStrLn "Hello"); it doesn't and shouldn't produce a new world state we can somehow consume lazily.
Oct
15
comment Is garbage collection necessary?
Not so much a rebuttal as a different definition. I would consider any technology for automatically collecting no-longer-needed memory to be "garbage collection". Heap scanning is one broad family of implementation technique for that idea; automatic use of reference counts is another. (For whatever it's worth, the wikipedia page on garbage collection uses the term the same way I do)
Jan
24
comment Critique of the IO monad being viewed as a state monad operating on the world
Is anyone surprised that a nonterminating program is equivalent to undefined in the pure semantics of Haskell? Different ⊥s are supposed to be indistinguishable in Haskell's pure semantics! But when we think operationally about our programs we want to distinguish different kinds of ⊥ too, even when IO is not involved; I care whether my program is throwing an exception or entering an infinite loop, even if you can prove that those are equal by proving that they're both ⊥. That's not actually a contradiction though.
Jan
24
comment Critique of the IO monad being viewed as a state monad operating on the world
But the interface WorldState -> (a, WorldState) is deliberately abstract, because the whole point is to model something that can't actually be directly expressed in Haskell, and it never breaks its contract. Mercury also uses explicit world-passing. The monad bit of Haskell's IO interface is only needed to ensure you don't reuse the world; understanding it as a State-monad-like abstraction for world-passing does work, because world-passing does work directly.
Jan
24
comment Critique of the IO monad being viewed as a state monad operating on the world
That's not a problem at all. The type WorldState -> (a, WorldState) only claims to accept a WorldState and give you back another one. It "does something" to the world. In the pure model of IO, that includes clocks advancing, stars decaying, network packets arriving, etc. Operationally of course it implements that by just observing how the real world actually changes.
Sep
7
comment Why is the concept of lazy evaluation useful?
This is why only languages with "enforced purity" like Haskell support laziness everywhere by default. "Encouraged purity" languages like Scala need the programmer to explicitly say where they want laziness, and it's up to the programmer to ensure that the laziness won't cause problems. A language that had laziness by default and had untracked side-effects would indeed be difficult to program predictably.
Jul
24
awarded  Yearling
Jan
5
comment Are there any “enterprise ready” functional programming languages?
@JörgWMittag I'm pretty sure the OP is interested in non-JVM non-CLR "enterprise-ready" functional languages. i.e. A functional language is not to be considered "enterprise-ready" solely on the basis of having been ported to JVM or CLR. It would be very strange to exclude a language from this discussion solely because there is another implementation of it on the JVM!
Oct
15
comment Why do languages such as C and C++ not have garbage collection, while Java does?
@BenVoigt I don't know that that's inherently true. I can imagine schemes where you run all the finalizers before deallocating any of the objects and only afterwards free anything that's still unreachable. I have gotten the impression that some modern languages are moving away from finalizers being a good idea because of complications with GC though, so your point has a measure of truth. I'd though it was impossible to do the GC/finalizers combo efficiently rather than impossible to do it though.
Oct
12
comment Is garbage collection necessary?
I would say automatic use of reference counting is a form of garbage collection. It's also known as a particularly inefficient way to implement garbage collection.
Oct
10
awarded  Nice Answer
Oct
9
comment Why do languages such as C and C++ not have garbage collection, while Java does?
@kylben Also, as others have said, reference counting is hugely inefficient compared to sophisticated modern GCs, and even hand-tuned manual free can be sub-par for some workloads. The advantage of C/C++ isn't that they're always more efficient than more managed environments, it's that they make it possible to write more efficient code when the managed environment is sub-par for your use-case.
Oct
9
comment Why do languages such as C and C++ not have garbage collection, while Java does?
@kylben You explicitly drew a distinction between reference counting schemes in C/C++ and GC, and then wrote a comment stating that GC has the risk of masking zombie object bugs. This is severely misleading; it's only true if you're using a library based GC such as Boehm and you circumvent it. GC was specifically invented to make bugs such as zombie objects impossible.