Reputation
2,914
Top tag
Next privilege 3,000 Rep.
Cast close & reopen votes
Badges
14 30
Newest
 Good Answer
Impact
~142k people reached

Jun
8
comment Why isn't lazy evaluation used everywhere?
Such as? There are reports of significant performance costs when using eager evaluation as well (costs in the form of either unneeded evaluation, as well as program non-termination). There are costs to almost any other (mis)used feature, come to think of it. Modularity itself may come at a cost; the issue is whether it's worth it.
Jun
7
comment Why isn't lazy evaluation used everywhere?
This seems to be an answer out of inexperience with languages with lazy evaluation. For example, what about infinite data structures?
Jun
7
comment Why isn't lazy evaluation used everywhere?
You seem to be arguing out of inexperience. I suggest you read the paper "Why Functional Programming Matters" by Wadler. It devotes a major section explaining the why of lazy evaluation (hint: it has little to do with performance, early optimization or "loading infrequently accessed data", and everything to do with modularity).
Jun
4
comment What can go wrong if the Liskov substitution principle is violated?
@user949300 A matter of good OO design is mostly orthogonal to having "a good compiler or static analyzer" -- good OO design must work in most situations and for most OO languages. For example, if you do OOP with an interpreted language, how is the "compiler" going to help you then? And a "minimal test suite" is demonstrably not enough (give me your suite and I'll write code that breaks it); even a reasonable test suite won't catch many bugs.
Jun
4
comment What can go wrong if the Liskov substitution principle is violated?
@user949300 I cannot give you an example of convoluted production code and don't have the time to distill it to its essentials. But Jimmy Hoffa's last comment hit the mark: it's not enough for software to "work", the costs of maintaining and refactoring it have to be taking into account. Otherwise, what's the point of having generics in Java, if collections of Objects work just as well?
Jun
4
comment What can go wrong if the Liskov substitution principle is violated?
@user949300 Well, your comment was unsupported as well. I wasn't trying to provide an answer; I'm quite satisfied with the accepted one.
Jun
3
comment What can go wrong if the Liskov substitution principle is violated?
@user949300 The Java Collections is a terrible counterexample, because they are known to have multiple historical problems. You can work around them, but it'd be better if they weren't there. Remember, at one time Java Collections didn't even support generics, and people still managed to write useful programs without them. Does this make generics useless, or "fairly academic"? :)
Jun
3
comment What can go wrong if the Liskov substitution principle is violated?
@user949300 This is not "fairly academic". If subclassing breaks existing methods which accept the superclass, this introduces a maintenance nightmare. You cannot introduce unit test to cover for every deviation a subclass can make, and you cannot predict them. Like this answer states, this problem can be seen as a case of tight coupling, which is a very serious and real-world software engineering concern!
Jun
3
comment What can go wrong if the Liskov substitution principle is violated?
@user949300 No, it doesn't. Also, minimal unit testing is not enough for non-toy situations.
Jun
2
comment What stops C from being compiled/interpreted/JIT'ed?
I'm puzzled about this bit: "what stops C from being compiled/[...]". Uh, nothing?
May
27
comment What makes functional programming languages declarative as opposed to Imperative?
@Brendan I don't think functional programming is a subset of imperative programming (nor is immutability a mandatory trait of FP). It can be argued that in the case of pure, statically-typed FP, it's a superset of imperative programming where effects are explicit in the types. You know the tongue-in-cheek assertion that Haskell is "the world's finest imperative language" ;)
May
26
comment What makes functional programming languages declarative as opposed to Imperative?
@ALXGTV You can indeed see functional programming as a superset of imperative programming. Your example with Clojure doesn't show reassignment; instead, it's an example of introducing new bindings with the same name (aka "shadowing"). The difference with imperative reassignment is that this effect is not seen outside the scope of the shadowing, whereas if you truly reassigned x, other parts of your function would see the change.
May
26
comment What makes functional programming languages declarative as opposed to Imperative?
@ALXGTV Your intuition is correct: declarative programming "just" provides a higher level of abstraction over certain imperative details. I'd argue this is a big deal!
May
26
revised Taking strong, static typing to an extreme?
removed irrelevant tag
May
24
comment Would it be good to have a readonly modifier for method level variables?
(Cont'd) It doesn't add much visual clutter and it helps add clarity to the intent of the code. It's very similar to Scala's val, which is mandatory (unless using var, of course).
May
24
comment Would it be good to have a readonly modifier for method level variables?
I use final in Java everywhere I can, and have introduced this style to my team. It greatly helps in understanding code. Often, while introducing final to local variables, I discover unintented/error-prone reassignments of the variable. In turn, correcting this often tends to refactoring the whole mess. I also introduced using final in all method arguments, no exceptions allowed.
May
20
revised Software paradigms: prove that sum and sum1 are equal
added a more appropriate tag; still better would be "induction" or "proof" ("scala" hs nothing to do with this question)
May
19
revised Software paradigms: prove that sum and sum1 are equal
code formatting
May
19
comment Software paradigms: prove that sum and sum1 are equal
An idea: prove by induction that k + sum1(xs, 0) = sum1(xs, k). Then use it in the step you're currently stuck.
May
9
comment JUnit Testing in Multithread Application
Please note that these tests won't prove your concurrency issues don't exist anymore. They simply exercise your threads more, and therefore increase the chance of finding concurrency problems if they are there; but I'm afraid this is still no guarantee. Finding and troubleshooting concurrency problems is unfortunately very hard.