First class developer: who ?

[sl@my-rialto]

Someone says if one does not know the difference between "equality" and
"equivalence", then one is an entry-level developer at best.

What is your opnion ? (I think we should not talk about mathematical
concepts, since it is the software developer in question.)

Thanks.

 

[Roedy Green]

Someone says if one does not know the difference between "equality" and
"equivalence", then one is an entry-level developer at best.

I think you will find these both defined in many different ways. It is
expecting mindreading if they use yours.
--
Roedy Green Canadian Mind Products
http://mindprod.com

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
~ Tom Cargill

 

[Arne Vajhøj]

Someone says if one does not know the difference between "equality" and
"equivalence", then one is an entry-level developer at best.

What is your opnion ? (I think we should not talk about mathematical
concepts, since it is the software developer in question.)

First class developers would ask you what you mean by those terms
(or walkout from the interview, because they don't see any point
in answering such questions).

Entry level developers may think that the question makes sense.

Arne

 

[Joshua Cranmer]

Someone says if one does not know the difference between "equality" and
"equivalence", then one is an entry-level developer at best.

What is your opnion ? (I think we should not talk about mathematical
concepts, since it is the software developer in question.)

A highly cultured person would recognize that even common words may
carry subtly different connotations to different groups of people. As
such, it is therefore important to note that requiring people to attach
the same two distinct definitions, as dictated by some arbitrary
authority, to words that are typically synonyms in vernacular speech
does not aid multicultural relations.

I'm guessing that the intent is to distinguish between = and ≡. I'm also
trying to think of an instance in computer science where I've actually
cared about the difference between those two... relations.

 

[Lew]

First class developers would ask you what you mean by those terms
(or walkout from the interview, because they don't see any point
in answering such questions).

Entry level developers may think that the question makes sense.

Here in the U.S., through the 1950s and 1960s, a great deal was made of the
difference, primarily because people would claim "equivalence" when it was, in
fact, not present, and thus the Jim Crow laws were finally repealed.

(For those oblivious to such things, that was humor. In other words, I agree
with Arne. The question is bullshit.)

 

[BGB / cr88192]

Someone says if one does not know the difference between "equality" and
"equivalence", then one is an entry-level developer at best.

this distinction is far too fluid to really be worth bothering to worry
about.
first one has to define these terms, and as well find some consistent way to
distinguish one from another.

if it were identity and equivalence, this would be more plausible (as an
entry level developer can also be reasonably confused by the subtleties of
pass-by-reference and pass-by-value, but anyone with much experience
couldn't get by without knowing this).

now, if one defines "equality" to mean "identity" and "equivalence" to mean
"structurally identical", maybe this works, but could not be safely assumed
from the original statement.

What is your opnion ? (I think we should not talk about mathematical
concepts, since it is the software developer in question.)

who knows...

the role of math in programming is a subject of debate.

personally, I think many people overstate the role of math in programming in
some ways:
when ever was the last time programmers had to seriously invest time in
things like solving polynomials or writing proofs.

these are some of the core elements of traditional math:
they spend all ones' earlier years forcing off solving on people, and then
later expect them to write proofs.

but, usually the programmer has little need or reason to care:
it matters instead that things work, and that they can get the job done, and
nearly all else is secondary.

the more "advanced" programmer may find themselves messing with issues which
are NOT matters of solving and/or proofs, but more a world often consisting
of endless piles of repetition and boilerplate...


so, it would seem there is a disconnect somewhere.

to the worlds of C, C++, and Java, traditional Math is an alien landscape,
neither sensible nor often particularly relevant... (and those few things
which are relevant are often those things Mathematicians like to sweep into
the corners...).

at nearly every level, some similarities exist, but at the same time, they
are opposed.

 

[Mike Schilling]

Maybe this is a rather vague way of getting at the following issue: I
would indeed expect a competent Java developer to understand the
difference, in Java, between a.equals(b) and a==b for reference
expressions a and b.

Me too, but they're both called "equality".

 

[Arved Sandstrom]

Well, there we go introducing mathematical concepts, from right there in
the Javadocs, no less!, despite the OP's attempt to eliminate the only
reasonable context in which to answer his point.

Both terms actually have clear English meanings - "equality" means (or
should mean) that two things *are* the same, and "equivalence" means (or
should mean) that two things can be substituted, that they behave the
same way.

A mathematical and CS definition in fact tracks the common English
meanings of these 2 words, and the language concerning Object.equals
that Patricia quoted does say exactly this: equals is an implementation
of equivalence.

My point is that the common English, the mathematical and the CS
definitions of the two terms are pretty much the same. And programming
languages that differentiate between the two also track those
definitions. We see that Java does.

Having said all this I did have to do a few minutes of research to
remind myself that the way the words are used in math and in CS are also
what they mean in common speech. And I don't normally walk around
thinking that equals is an implementation of an equivalence relation.

AHS

 

[Mike Schilling]

BGB / cr88192 wrote:
...
...

I have rarely needed to solve a polynomial as a programmer, although I
have had to understand how to solve very large systems of linear
equations.
On the other hand, writing proofs seems to me to be a very practical
activity. For example, I sometimes debug by trying to construct a
proof that the problem could not possibly have happened, taking
things I think are true as the axioms. Given a valid proof of the
impossibility of something that has actually happened, at least one
axiom used in the proof must be false. It is a good way of selecting a set
of beliefs to
investigate.

My degree (taken many, many years ago) is in mathematics. I don't use much
of the math itself, but the discipline of writing proofs, that is, making
sure each step follows logically from the previous ones and that no special
cases are omitted, is something I still use every time I write a piece of
code..

 

[Mike Schilling]

Having said all this I did have to do a few minutes of research to
remind myself that the way the words are used in math and in CS are
also what they mean in common speech. And I don't normally walk around
thinking that equals is an implementation of an equivalence relation.

I do, but I was trained to think of things that way. hashCode() is too, if
you think about it [1], and for hashCode() and equals() to be consistent
means that each equals() equivalence set is a subset of some hashCode()
equivalence set.

1. That is, the property of having the same hashCode() value is an
equivalence relationship.

 

[Eric Sosman]

Someone says if one does not know the difference between "equality" and
"equivalence", then one is an entry-level developer at best.
[...]

[...]
I'm guessing that the intent is to distinguish between = and ≡. I'm also
trying to think of an instance in computer science where I've actually
cared about the difference between those two... relations.

Common LISP has *four* different "equality" predicates:
eq, eql, equal, and equalp, plus type-specific tests like
char-equal.

I'd say that a questioner who thinks "equality" and
"equivalence" exhaust the set of possibilities is an entry-
level questioner at best.

 

[Tom Anderson]

Someone says if one does not know the difference between "equality" and
"equivalence", then one is an entry-level developer at best.

What is your opnion?

I think the person who said that is probably a prat.

(I think we should not talk about mathematical concepts, since it is the
software developer in question.)

Only a fool closes the door on an idea.

Mathematical concepts can be useful at times in software development, and
so the wise programmer makes them a tool in his toolbox. Your dismissal is
as misplaced as his elitism.

tom

 

[Tom Anderson]

My degree (taken many, many years ago) is in mathematics. I don't use
much of the math itself, but the discipline of writing proofs, that is,
making sure each step follows logically from the previous ones and that
no special cases are omitted, is something I still use every time I
write a piece of code..

Exactly the same here.

Except that my degree was in biochemistry, and when i'm making sure each
step follows logically from the previous ones and that no special cases
are omitted, i'm applying the scientific method. I bet there are
programmers who used to be historians and policemen who can make analogous
claims about the origin of their discipline. I have the highest respect
for mathematics and mathematicians, but i don't think they have a unique
claim on rigorous thinking. Rather, mathematics is just what you get when
you apply rigorous thinking to numbers, rather than to enzymes,
manuscripts, or criminals.

tom

 

[Arne Vajhøj]

Maybe this is a rather vague way of getting at the following issue: I
would indeed expect a competent Java developer to understand the
difference, in Java, between a.equals(b) and a==b for reference
expressions a and b.

I think it is.

But asking the question this way reveals more about the
interviewer than the interviewed.

Arne

 

[Martin Gregorie]

But programming languages themself are Maths ... The whole lagnguage you
are using is an example of First Order Logic. Like SQL is a more human
readable form of relational calculus...

Good point.

Re SQL though: I remember seeing an early piece on relational calculus,
probably written by Chris Date, and thought at the time that I'd rather
use it than SQL. Maybe the raw form's time has come again now that more
programmers are used writing concise block structured and OO languages
instead of the pseudo-English of COBOL. Even at the time I had the
impression that SQL was relational calculus that had been obfuscated to
suit COBOL programmers.

 

[Arne Vajhøj]

Both terms actually have clear English meanings - "equality" means (or
should mean) that two things *are* the same, and "equivalence" means (or
should mean) that two things can be substituted, that they behave the
same way.

A mathematical and CS definition in fact tracks the common English
meanings of these 2 words, and the language concerning Object.equals
that Patricia quoted does say exactly this: equals is an implementation
of equivalence.

My point is that the common English, the mathematical and the CS
definitions of the two terms are pretty much the same. And programming
languages that differentiate between the two also track those
definitions. We see that Java does.

I don't think Java follow those rules.

I assume that you consider equals to be equivalence and
== to be equality.

But it is not so.

Example:

public class ZZ {
public static void main(String[] args) {
int iv = 2;
double xv = 2.0;
System.out.println(iv == xv);
}
}

Arne

 

[Arne Vajhøj]

personally, I think many people overstate the role of math in programming in
some ways:
when ever was the last time programmers had to seriously invest time in
things like solving polynomials or writing proofs.

these are some of the core elements of traditional math:
they spend all ones' earlier years forcing off solving on people, and then
later expect them to write proofs.

but, usually the programmer has little need or reason to care:
it matters instead that things work, and that they can get the job done, and
nearly all else is secondary.

the more "advanced" programmer may find themselves messing with issues which
are NOT matters of solving and/or proofs, but more a world often consisting
of endless piles of repetition and boilerplate...

so, it would seem there is a disconnect somewhere.

to the worlds of C, C++, and Java, traditional Math is an alien landscape,
neither sensible nor often particularly relevant... (and those few things
which are relevant are often those things Mathematicians like to sweep into
the corners...).

I completely disagree.

Developers that google solutions and copy paste them and generally
consider the computer a black box may not use math.

But developers that like to understand what they are doing and
why will be thinking math every hour at work whether they
realize it or not.

Picking correct collection based on big O characteristics and
using relational databases are extremely common. Both build
on a strong mathematical foundation.

Arne

 

[Martin Gregorie]

Developers that google solutions and copy paste them and generally
consider the computer a black box may not use math.

No argument here.

But developers that like to understand what they are doing and why will
be thinking math every hour at work whether they realize it or not.

Here we diverge. Despite spending my working life in IT, I'm a scientist
by training, not a mathematician.

I work on the principle that a software design is a hypothesis from which
true and false predictions can be made. Code written to implement the
design is then exhaustively tested against the predictions to verify the
correctness of the design.

There's a nod to maths rolled in too: I use inductive proofs to generate
tests of normal operation rather than exhaustive scans of the entire
valid operation space. The aforesaid true predictions generate corner
tests and the false predictions become error handling tests.

 

[Arved Sandstrom]

Both terms actually have clear English meanings - "equality" means (or
should mean) that two things *are* the same, and "equivalence" means (or
should mean) that two things can be substituted, that they behave the
same way.

A mathematical and CS definition in fact tracks the common English
meanings of these 2 words, and the language concerning Object.equals
that Patricia quoted does say exactly this: equals is an implementation
of equivalence.

My point is that the common English, the mathematical and the CS
definitions of the two terms are pretty much the same. And programming
languages that differentiate between the two also track those
definitions. We see that Java does.

I don't think Java follow those rules.

I assume that you consider equals to be equivalence and
== to be equality.

But it is not so.

Example:

public class ZZ {
public static void main(String[] args) {
int iv = 2;
double xv = 2.0;
System.out.println(iv == xv);
}
}

Arne

I do consider == to be equality (identity). Same object for references,
same value for primitives...that's equality.

An implementation of equals() I consider to be _an_ implementation of an
equivalence relation; == is clearly another.

I'm not that perturbed by your example. Java == equality for primitives
of different types is what we define it to be, so defining it to be an
operation that takes place after primitive conversions is not wrong. In
effect we're not saying that (int 2) == (double 2.0), we're saying that
(double 2.0) == (double 2.0); the binary numeric promotion happened
before the ==.

AHS

 

[Arne Vajhøj]

Both terms actually have clear English meanings - "equality" means (or
should mean) that two things *are* the same, and "equivalence" means (or
should mean) that two things can be substituted, that they behave the
same way.

A mathematical and CS definition in fact tracks the common English
meanings of these 2 words, and the language concerning Object.equals
that Patricia quoted does say exactly this: equals is an implementation
of equivalence.

My point is that the common English, the mathematical and the CS
definitions of the two terms are pretty much the same. And programming
languages that differentiate between the two also track those
definitions. We see that Java does.

I don't think Java follow those rules.

I assume that you consider equals to be equivalence and
== to be equality.

But it is not so.

Example:

public class ZZ {
public static void main(String[] args) {
int iv = 2;
double xv = 2.0;
System.out.println(iv == xv);
}
}

I do consider == to be equality (identity). Same object for references,
same value for primitives...that's equality.

But 2 and 2.0 are not identity equals.

An implementation of equals() I consider to be _an_ implementation of an
equivalence relation; == is clearly another.

I'm not that perturbed by your example. Java == equality for primitives
of different types is what we define it to be, so defining it to be an
operation that takes place after primitive conversions is not wrong. In
effect we're not saying that (int 2) == (double 2.0), we're saying that
(double 2.0) == (double 2.0); the binary numeric promotion happened
before the ==.

That promotion is done by ==.

Arne