Reputation
3,809
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
1 18 34
Newest
 Guru
Impact
~206k people reached

1d
comment What do you call a function that's pure, meaning the same input will always return the same output, but also has side effects?
@ZachLipton Of course, but I didn't want to complicate my answer. Assume that, in the context of this answer, this is a magical database that doesn't need to be configured and never fails to write. Or replace "database" with "logging to stdout and ignoring all output errors".
1d
comment What do you call a function that's pure, meaning the same input will always return the same output, but also has side effects?
@ComicSansMS Indeed! I didn't want to complicate my answer with Haskell's additional type system features.
May
1
comment What do you call a function that's pure, meaning the same input will always return the same output, but also has side effects?
(PS: take a look at Haskell's trace, which makes it clear adding logging to a function makes it not referentially transparent, and therefore (by Haskell's definition) impure. trace is a dangerous function because it "hides" this impurity from the function's signature, which is in general a no-no).
May
1
comment Help me in this java programs
Hi and welcome to this site. Here we won't help you write Java programs from scratch, which means your question will get closed. You should strive to write most of the program yourself, and then if you have a programming question ask it on StackOverflow.com (not here). Make sure you are asking an actual question, and not simply dumping a heap of code on us.
May
1
comment What do you call a function that's pure, meaning the same input will always return the same output, but also has side effects?
This means that "the number of times the function was called" is an observable property of your program's behavior. Therefore, the two programs do not behave the same!
Apr
30
comment What do you call a function that's pure, meaning the same input will always return the same output, but also has side effects?
Agreed! It's (informally) the mathematical definition of "function", but like you say, unfortunately "function" means something different in programming languages, where it's closer to "a step-by-step procedure required to obtain a value".
Apr
30
comment What do you call a function that's pure, meaning the same input will always return the same output, but also has side effects?
Well, it depends. Maybe the logs make it impure, for example if you care about how many times, and at what times, "INFO f() called" appears in your log. Which you often do :)
Apr
30
comment What do you call a function that's pure, meaning the same input will always return the same output, but also has side effects?
I agree it's confusing. I can only think of contrived examples. Say f(x) depends not only on x, but also on some external global variable y. Then, if f has the property of RT you can freely swap all its occurrences with its return value as long as you don't touch y. Yes, my example is dubious. But the important thing is: if f writes to the database (or writes to a log) it loses the property of RT: now it doesn't matter whether you leave global y untouched, you know the meaning of your program changes depending on whether you actually call f or simply use its return value.
Apr
14
comment Does the visitor pattern violate the Liskov Substitution Principle
Is it just me or every other question on P.SE is about the LSP? It seems we're obsessed with it :P
Apr
13
comment Understanding polymorphism and interface in Java
@fizzix Yes, a.m2() won't compile in your example. Not because a doesn't "have" method m2() (it does have it, since a is an instance of B), but because you only told the compiler enough information to know it's an A. Note that if you casted a to class B, you'd be effectively telling the compiler "I assure you this a is an instance of B", and it'd let you call method m2, like this: ((B) a).m2().
Apr
13
comment As a programmer, how can I speed up my adoption and understanding of business rules?
This is a very good question to discuss with other programmers, but unfortunately it's off-topic for this Q&A site: it's both too broad (there is a lot to say about the matter) and primarily opinion-based (different people will tell you different things, essentially what works for them... how are you going to choose the "right" answer?).
Apr
13
comment How to deal with misconceptions about “premature optimization is the root of all evil”?
@AndrewPiliser Not for EDGE, no. Absolutely nothing works for EDGE, because it effectively means "no connection" :) No amount of optimizations can compensate for that fact.
Apr
12
comment How to deal with misconceptions about “premature optimization is the root of all evil”?
+1 Not sure why this answer has downvotes instead of upvotes plus being the accepted answer. It suggests both a way to handle the problem, plus an analysis of what the real underlying problem might be (i.e. that nobody wants to be told their code must be radically re-written).
Apr
12
comment How to deal with misconceptions about “premature optimization is the root of all evil”?
@errantlinguist In that case, it's not google.com's problem. It's a connectivity problem: nothing works on an EDGE connection. I consider the "E" symbol the same as "no connection" ;) More seriously: it wouldn't be an optimization problem, since nothing they could do at Google to improve their website would change the fact EDGE doesn't work for anything.
Apr
8
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB Yes, many, but more importantly, that's not a good argument. Some features are prone to misuse and are considered bad design choices (as an example, see the infamous Billion Dollar Mistake). The widespread use of getters/setters in Java is one of them. Note that it's not that they "can be misused", but that they often are; when an error is widespread, it points to a design error in the language itself. And regardless, like it has been mentioned several times already, they are theoretically at odds with OO design (which is what this question was about).
Apr
7
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB Finally, a nitpick: it's not true that in my example "it would be as bad whether [the change] happened through any other reason". The fact is that setters as used in Java provide uncontrolled access. Without the setter, access is limited to the instance -- which the class author knows how to handle responsibly. With the setter, access is granted to the caller, who may or may not know about sensitive details... and often doesn't!... which is how Java pitfalls are born :)
Apr
7
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB A different, unrelated problem with getters/setters as used in Java is that they break the "atomicity" of the construction of valid objects. When you build (or update) an object by using setters, you often break its invariant. In principle it's better to only build valid objects using constructors, not by changing them using setters. In practice, this almost never happens with Java (and intrusive frameworks like Hibernate are partly to blame). The overall pattern that emerges is that getters/setters are evil for multiple reasons!
Apr
7
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB In this case, yes, but I don't want you to focus on this example alone. Java is littered with this kind of pitfalls, in many cases encouraged by a proliferation of direct-access getters & setters. It's common enough that the overall lesson is: direct access to internal fields, which is almost always the case in Java, is an anti-pattern that leads to errors. This, of course, aside from the fact I've mentioned many times already, that it's against OOP principles. So getters/setters are evil for multiple reasons, some practical, some theoretical :)
Apr
7
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB True, I phrased it poorly. It doesn't exactly break encapsulation in theory (though it does in practice, since the vast majority of getters directly expose mutable fields in Java. This is so common, novices may not even know other uses. The client may not care, but if they accidentally change the field, behavior may be unexpectedly broken. An example of accidentally breaking behavior is changing fields used to compute a hash code for an instance stored in a HashMap). And regardless of encapsulation, it definitely breaks principles from the OO paradigm (again, "Tell, Don't Ask").
Apr
6
comment Mutable objects - setters and getters
(I agree that clone is generally broken, which is why Effective Java recommends not using it).