Reputation
367
Next privilege 500 Rep.
Access review queues
Badges
1 6
Newest
 Critic
Impact
~4k people reached

  • 0 posts edited
  • 0 helpful flags
  • 39 votes cast
1h
comment Better to have 2 methods with clear meaning, or just 1 dual use method?
Also, using charge(0) as the way of getting the balance because it happens to have no effect now weds you to this implementation detail; I can easily imagine a future requirement where tracking the number of charges becomes relevant, at which point having your code base littered with charges that aren't really charges becomes a pain point. You should provide interface elements that mean the things your clients need to do, not ones that merely happen to do the things your clients need to do.
Jan
22
comment Is it good practice to avoid warnings and notices?
If you can't find a way to avoid a notice or warning, switching it off with @ is much better than turning off all warnings. Yes you're "hiding a potential problem", but turning off all warnings is like putting @ on every single line!
Sep
14
comment Should I create a class if my function is complex and has a lot of variables?
Any class that you instantiate and then immediately call a single method on and then never use again is a major code smell, to me. It's isomorphic to a simple function, only with obscured data flow (as the broken out pieced of the implementation communicate by assigning variables on the throwaway instance instead of passing parameters). If your internal functions take so many parameters that the calls are complex and unwieldy the code doesn't get less complicated when you hide that dataflow!
Jul
9
comment Why is heap size fixed on JVMs?
But the threshold for running GC doesn't have to have anything to do with a fixed threshold that total memory use by the program cannot exceed. (Indeed it probably shouldn't; if you have a large heap and you can only GC when it's full, you necessarily have rare-but-long periods of GC). See generational garbage collection.
Feb
20
comment Critique of the IO monad being viewed as a state monad operating on the world
@CMCDragonkai Each thread does have its own "world", but within each thread the world must be used uniquely. They sync up when you call primitives. The pure model says nothing at all about exactly when each thread can observe what results from another thread's IO actions... but that's exactly how concurrency with threads works! Unless you explicitly synchronise with locks or other methods, the effects of threads are interleaved in a completely unspecified order. This is consistent with the semantics we'd have if we really could pass around representations of the entire universe.
Feb
20
comment Critique of the IO monad being viewed as a state monad operating on the world
@CMCDragonkai The implementation of the io passing is just a no-op. But the model that makes you able to do IO with pure code says that whenever you do a "primitive IO operation", the io it gives you back is a world that incorporates the effects of the primitive and arbitrary other effects. The "other effects" come from other threads in your program, as well as totally unrelated processes going on in the real world (like stars decaying).
Feb
16
comment Can “higher order function” feature allow/maintain abstraction and encapsulation?
If someone is making mission-critical software using your code, it's their job to make appropriate non-fragile use of the APIs they're using. It's your job to clearly communicate what your clients can and cannot rely upon, and to make sure those properties you advertise as reliable really are bullet-proof.
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.