Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #30891 > unrolled thread
| Started by | justaguy <lichunshen84@gmail.com> |
|---|---|
| First post | 2016-07-18 09:10 -0700 |
| Last post | 2016-07-19 16:16 -0300 |
| Articles | 20 on this page of 84 — 16 participants |
Back to article view | Back to comp.lang.javascript
How would you prepare for javascripting interview? justaguy <lichunshen84@gmail.com> - 2016-07-18 09:10 -0700
Re: How would you prepare for javascripting interview? Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2016-07-18 18:37 +0200
Re: How would you prepare for javascripting interview? justaguy <lichunshen84@gmail.com> - 2016-07-18 11:09 -0700
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-07-21 01:04 +0000
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-07-21 14:24 +0100
Re: How would you prepare for javascripting interview? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-07-23 16:25 +0200
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-07-23 15:56 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-03 19:39 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-04 15:56 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 00:06 +0100
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-05 14:49 +0100
Re: How would you prepare for javascripting interview? $Bill <news@todbe.com> - 2016-09-05 10:01 -0700
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-06 09:36 -0700
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-05 15:05 +0100
Re: How would you prepare for javascripting interview? Andreas Bergmaier <andber93@web.de> - 2016-09-05 20:31 +0200
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-06 15:15 +0000
Re: How would you prepare for javascripting interview? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-06 19:40 +0200
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-06 19:25 +0100
Re: How would you prepare for javascripting interview? Andreas Bergmaier <andber93@web.de> - 2016-09-06 22:16 +0200
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-07 17:17 +0100
Re: How would you prepare for javascripting interview? Andreas Bergmaier <andber93@web.de> - 2016-09-07 20:07 +0200
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-08 14:36 +0100
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-05 18:46 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 20:32 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-05 17:27 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 20:12 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-06 16:48 +0000
Re: How would you prepare for javascripting interview? Andreas Bergmaier <andber93@web.de> - 2016-09-06 19:56 +0200
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-07 20:16 +0000
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-07 10:01 -0700
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-07 20:21 +0000
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-09 11:41 -0700
Re: How would you prepare for javascripting interview? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-09 15:35 -0700
Re: How would you prepare for javascripting interview? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-09 20:40 -0700
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-10 15:12 +0000
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-12 11:14 -0700
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-13 21:07 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-06 16:20 +0000
Re: How would you prepare for javascripting interview? Ken Tilton <kentilton@gmail.com> - 2016-09-05 11:37 -0700
Re: How would you prepare for javascripting interview? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-06 19:26 +0200
Re: How would you prepare for javascripting interview? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-08 12:41 -0700
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-05 20:37 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 22:13 +0100
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-06 02:33 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-06 16:02 +0000
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-06 09:50 -0700
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-07 01:36 +0000
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-07 10:07 -0700
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-10 00:03 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-10 00:12 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-10 15:34 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-11 01:32 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-12 19:26 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-13 01:02 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-13 21:38 +0000
Re: How would you prepare for javascripting interview? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-09-14 00:56 +0200
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-15 15:09 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-14 00:47 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-15 15:34 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-11 02:45 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-12 19:10 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-12 21:06 +0100
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-07 03:12 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-07 19:53 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-10 02:14 +0000
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-10 11:25 +0100
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-10 15:49 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-10 18:39 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-11 02:45 +0000
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-11 16:23 +0100
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-12 20:32 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-12 18:49 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-13 00:27 +0000
Re: How would you prepare for javascripting interview? Tim Streater <timstreater@greenbee.net> - 2016-09-13 08:51 +0100
Re: How would you prepare for javascripting interview? Jon Ribbens <jon+usenet@unequivocal.eu> - 2016-09-13 12:33 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-14 01:17 +0000
Re: How would you prepare for javascripting interview? Tim Streater <timstreater@greenbee.net> - 2016-09-14 11:15 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-15 15:02 +0000
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-13 10:06 +0100
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-06 19:53 +0100
Re: How would you prepare for javascripting interview? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-07-18 22:30 +0200
Re: How would you prepare for javascripting interview? justaguy <lichunshen84@gmail.com> - 2016-07-18 14:56 -0700
Re: How would you prepare for javascripting interview? Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2016-07-19 16:01 -0300
Re: How would you prepare for javascripting interview? Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2016-07-19 16:16 -0300
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Doc O'Leary <droleary@2015usenet1.subsume.com> |
|---|---|
| Date | 2016-09-12 19:10 +0000 |
| Message-ID | <nr6ujr$lka$2@dont-email.me> |
| In reply to | #31313 |
For your reference, records indicate that
Scott Sauyet <scott@sauyet.com> wrote:
> Doc O'Leary wrote:
> >
> > People need to stop making this mistaken argument. This has nothing
> > to do with the mathematical sets. It has to do with a function in a
> > library of computer code.
>
> Sorry, I should have used "list" here rather than "set".
I was taking issue with your whole argument, not the questionable
equivalence of sets/lists/arrays.
> I was simply pointing out that if `max([]); //=> NaN`,
> then we get some awkward behavior, a violation of the law I was proposing.
I know. Stop proposing that law, because the topic at hand is
computer science, not pure mathematics.
> If you split a list into two sublists and take the max of each, then the
> max of those two resulting values, logically, you should get the same
> result as if you took the max of the initial list.
Stop.
It.
> > Even if it were implemented recursively,
> > it would be poorly programmed if it made a call of max([]), regardless
> > of what such a call might return.
>
> I'm sorry, but I make no sense of this.
Again, it’s basic computer science. To call functions that do no
useful work is wasteful, and most often times wrong.
> I was suggesting that my definition ("max returns the smallest value that
> is no smaller than any element in the list") allows us to capture the
> meaning of the function faithfully, return something useful mathematically
> in every case
And this is where you continue to fail. Identity elements are *not* mathematically useful outside the scope of the function they apply to.
Therefore they should *not* be used as the end result of such an
operation. Otherwise, you run into a mathematical cul-de-sac where
max() < min().
> I'm sure that our views are colored by our various tolerance for things
> such as exceptions (which I mostly hate) and Infinity (which bothers me
> not at all), but I think it's hard to argue that this definition is not
> simpler than such alternatives.
“For every problem there is a solution which is simple, clean and wrong.”
Henry Louis Mencken
--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-12 21:06 +0100 |
| Message-ID | <87d1k8sx1d.fsf@bsb.me.uk> |
| In reply to | #31343 |
Doc O'Leary <droleary@2015usenet1.subsume.com> writes:
> For your reference, records indicate that
> Scott Sauyet <scott@sauyet.com> wrote:
>
>> Doc O'Leary wrote:
>> >
>> > People need to stop making this mistaken argument. This has nothing
>> > to do with the mathematical sets. It has to do with a function in a
>> > library of computer code.
>>
>> Sorry, I should have used "list" here rather than "set".
>
> I was taking issue with your whole argument, not the questionable
> equivalence of sets/lists/arrays.
>
>> I was simply pointing out that if `max([]); //=> NaN`,
>> then we get some awkward behavior, a violation of the law I was proposing.
>
> I know. Stop proposing that law, because the topic at hand is
> computer science, not pure mathematics.
I think you've got it backwards. It's relatively rare for
mathematicians to define max of nothing. I did not find any, in fact,
(though I am sure there must be some), and had to hunt quite hard to
find a math text that defined sup {} to be -oo and inf {} = oo, but
that's both rare and not quite the same thing to a mathematician. It's
computer scientists who've generalised max to empty lists. They do it
for practical reasons. I don't know why you are determined to reject
the idea that a CS person would want their library functions to follow
simple laws. It helps write correct programs.
<snip>
> “For every problem there is a solution which is simple, clean and wrong.”
> Henry Louis Mencken
Which leaves open the possibility of a simple, clean and correct
solution. Maybe this is one of those problems?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Scott Sauyet <scott@sauyet.com> |
|---|---|
| Date | 2016-09-07 03:12 +0000 |
| Message-ID | <nqo0jf$a4v$2@dont-email.me> |
| In reply to | #31250 |
Doc O'Leary wrote:
> Scott Sauyet wrote:
>
>> I disagree. The realistic choices are
>>
>> (A) Return something of the correct type, even though it's not
>> in the (empty) input list.
>>
>> (B) Return some semaphore of a different type that signals that
>> things have gone wrong: `undefined` or `null` are most likely.
>>
>> (C) Throw an error.
>>
>> None of these choices is ideal, but we have to choose between them.
>> I'd say that the best ordering is A > C > B.
>
> Then I wonder if you’ve ever done any sort of sophisticated programming.
I believe I have. I've also been training programmers in advanced
techniques for a number of years.
> There is a *reason* why languages developed mechanisms other than
> “return a valid value and let the programmer figure out if it’s
> *actually* a good result, or just some kind of error”.
I've argued (most recently in a response to Gene Wirchenko) that this is
not only a good result, but the only reasonable value.
It allows us to assert laws such as
max([max(list1), max(list2)]) === max(concat(list1, list2))
>> Of course this is better for numbers than for some other types because
>> numbers specifically encompass maximum and minimum values of their
>> type. But this is the `Math` API. Why should it not speak to the
>> number type?
>
> It’s best dealt with abstractly, because the concept applies to things
> other than numbers. If you can order it, you can determine a “max”
> value. And if there is *no* values to order, it is ludicrous to say the
> correct result is a valid value you have simply fabricated.
This is no more fabricated than 0 is fabricated as the sum of an empty
list of numbers, than 1 is fabricated as the product of an empty list of
numbers, or than `true` is fabricated as the result of a call to `all` on
an empty list. These are the obvious and useful results. While `max
([]); //=> -Infinity` is slightly less obvious, the same sort of
reasoning demonstrates why it is correct.
> But even restricted to numbers, the abuse of infinity remains an
> implementation hack. NaN is also a number, and also already used by
> min/max to signal an error. It makes zero sense (beyond the hack) to
> return an infinity.
There is an argument to be made for `- Number.MAX_VALUE`, and for
`Number.MAX_VALUE` for `min`, but there might be a slight boundary
condition issue, and more importantly, these fail if your list includes
Infinity or -Infinity. Other than that, there is no reasonable option.
>> Since the second choice in my hierarchy is to throw an error, I think
>> it would be reasonable to do so if the type does not permit a
>> reasonable maximum or minimum value. For Javascript, only three
>> ordered types come to mind: Numbers, Dates, and Strings, although I may
>> be missing some.
>
> You’re missing an infinity of objects that developers can define for
> themselves. Or just the infinity of uses a Number can have.
You clipped the bit where I mentioned custom types and how since the user
would already have to do the ordering, asking her to also signal the
proper behavior here is not unreasonable.
> You’re
> stuck thinking about the objects you have rather than the *uses* the
> objects are put to. Stop and actually *think* about what you actually
> have to do to write a program that behaves properly when you define
> functions that fabricate “valid” results.
I'm suggesting that those who define the types to be used with a generic
`max`/`min` would have to define their own boundary values, or signal
that they don't exist, not that such a function could do it for an
arbitrary type. But I also insist that ±Infinity is the only reasonable
choice for Javascript's Number type.
>> Dates have an underlying fixed bit-sized number, so we could easily do
>> the same for Dates. An imaginary `String.max()` could be satisfied
>> with the empty String, but `String.min()` would be much harder; I think
>> it would have to throw.
>
> That’s an utter mess.
This is simply the result of my suggestion that this should be left to
those implementing ordering for the types. I don't know better than they
do; neither do you.
> You should never be allowed to write a software
> library that is used by anyone else.
:-)
Check out Ramda [1], "a practical functional library for Javascript
developers." It's being downloaded around 8500 times per day [2]. I am
the original author and one of the three primary contributors to it. I'm
sure there are those that will say it's utter crap, but I'm pretty fond
of it. It's not as principled as Sanctuary [3], preferring to better
bridge the gap between work-a-day Javascript programmers and FP
enthusiasts than to fall too heavily on the pure FP side. But it is a
much purer FP library than something like Underscore [4].
>> It's not that I think this is a bad point. I simply don't believe it's
>> as clear-cut as described.
>
> It is. Perhaps one day you’ll be experienced enough to understand why.
It is not. Perhaps one day you'll understand enough math to recognize
why.
>>> They’ll have to do worse if they expect to function correctly based
>>> on the current behavior. You could perhaps raise it as an exception
>>> if you prefer, but it’s just plain *wrong* to return a number that
>>> wasn’t given to you.
>>
>> Garbage in, garbage out. It's no more wrong to do this than to supply
>> a function that needs a non-empty list with an empty one. I assume
>> that you would rather throw in this case or to return `null` or
>> `undefined`.
>
> I would seek to define a consistent behavior. The *way* garbage comes
> out is important. That’s the entire issue of why an infinity is the
> wrong result.
I was simply being flip here. I apologize.
To me `null` or `undefined` would be true garbage. Instead of a function
whose results I can simply use, I would get something that then requires
type-checking, and then manual intervention if I get the wrong type. If
this throws, I cannot compose it with other functions, and need to build
complex logic flows rather than simple functional pipelines.
I have no fundamental issue with the thought of instead offering a `Maybe
Number` type (or more generally a `Maybe a` one) for an API, but this
whole discussion is in the context of a function already documented to
return a number.
>> To my mind, either of these is significantly worse. By returning a
>> number, you allow the user to proceed with numeric calculations,
>> including, most importantly, using this result in a further max or min
>> calculation. (This is very much related to the arguments that Stefan
>> Ram has made.)
>
> Compounded errors are not the better solution. I want to know when and
> where something went wrong, not just *guess* at when the final result
> looks a bit off.
But I don't think this is a signal that something went wrong, any more
than `sum([]); //=> 0` signals that something went wrong. `sum([]); //=>
null` would be much worse, as would `sum([]); //~> Error`, the first
because it really could compound, and the second because I can no longer
comfortably compose that function with others.
>>> That’s why this behavior makes for a suitable trick question,
>>> but a terrible one for finding a JavaScript developer that actually
>>> thinks about the work they’re doing.
>>
>> But remember the context of this question: I've already determined that
>> the candidate has reasonably strong skills in Javascript.
>
> I doubt you objectively have.
Of course not. But given the limited time of an interview, I've don't
the best I could. Over the years I've read literally thousands of
resumes, performed some awful number of phone screens, held full-on
interviews about 200 times, and hired about 25 developers. In two cases,
the candidate managed to get past this vetting process without having the
necessary skills. But that's still a 90%+ success rate. I'll take it.
>> This is not a trick question in the sense that I'm asking the candidate
>> about the esoterica of the language; I'm not asking her to explore
>> obscure corners of the spec.
>
> But that’s exactly what you’re doing. You’re asking them about a hack
> that has, unfortunately, remained in the Math object for far too long.
Of course, again, I disagree here. I think this is the best possible
solution.
> If you legitimately want them to think, you’d do something like I have
> done, and explore ways to provide a min/max function for abstract
> collections of any type.
I find that a trivial problem, honestly.
If you have a solution for it, do you always throw on an empty list, do
you always return a `null`/`undefined` signal, or do you leave it up the
type to decide?
> My bet is that none but the *least* qualified
> candidates will come up with solutions that fabricate results the way
> Math does for numbers.
I'm not asking them to come up with that solution. I tell them how it
is, and offer them as many hints as are necessary for them to understand
why it works as it does.
I don't know what sort of position you hold. I work in a large company
with an ongoing mix of old and new software for developers to work on. A
very important skill is trying to figure out how a system or a component
works, and why it's written the way it is. Watching a candidate go
through this exercise, I believe, helps me determine how skilled she is
at this.
[1]: http://ramdajs.com/
[2]: https://npm-stat.com/charts.html?package=ramda&from=2016-01-01
[3]: http://sanctuary.js.org/
[4]: http://underscorejs.org/
-- Scott
[toc] | [prev] | [next] | [standalone]
| From | Doc O'Leary <droleary@2015usenet1.subsume.com> |
|---|---|
| Date | 2016-09-07 19:53 +0000 |
| Message-ID | <nqpr7i$l7t$1@dont-email.me> |
| In reply to | #31265 |
For your reference, records indicate that Scott Sauyet <scott@sauyet.com> wrote: > Doc O'Leary wrote: > > > > Then I wonder if you’ve ever done any sort of sophisticated programming. > > I believe I have. I've also been training programmers in advanced > techniques for a number of years. How unfortunate for them, and anyone they’ve every worked for. Care to name the institution, so that it makes it easy to exclude those people from jobs where people need to know how to do things right? Thanks. > > > There is a *reason* why languages developed mechanisms other than > > “return a valid value and let the programmer figure out if it’s > > *actually* a good result, or just some kind of error”. > > I've argued (most recently in a response to Gene Wirchenko) that this is > not only a good result, but the only reasonable value. > > It allows us to assert laws such as > > max([max(list1), max(list2)]) === max(concat(list1, list2)) The purpose of Computer Science is *not* to assert mathematical laws. It is to do useful work. It is *wrong* to return a result *as if* useful work was done when it is highly likely such a result is not only in error, but will likely propagate that error. > > It’s best dealt with abstractly, because the concept applies to things > > other than numbers. If you can order it, you can determine a “max” > > value. And if there is *no* values to order, it is ludicrous to say the > > correct result is a valid value you have simply fabricated. > > This is no more fabricated than 0 is fabricated as the sum of an empty > list of numbers, than 1 is fabricated as the product of an empty list of > numbers, or than `true` is fabricated as the result of a call to `all` on > an empty list. They are all fabricated. Done so to reflect their respective identity element, sure, but all of them are equally *wrong* behavior from a CS perspective. > These are the obvious and useful results. Internally, yes, they are useful in the way that many other hacks are useful. But it is not the sign of a competent developer to architect a library that *always* returns valid results like that. Pull your head out of your math book and actually *think* about the work you’re trying to do. > You clipped the bit where I mentioned custom types and how since the user > would already have to do the ordering, asking her to also signal the > proper behavior here is not unreasonable. It is in a polymorphic sense. Or do you expect max() to be implemented to return -Infinity by *all* developers for all objects? Again, I suspect you’ve never really architected a system of substantial complexity. > I'm suggesting that those who define the types to be used with a generic > `max`/`min` would have to define their own boundary values, or signal > that they don't exist, not that such a function could do it for an > arbitrary type. But I also insist that ±Infinity is the only reasonable > choice for Javascript's Number type. And that kind of thinking is why a lot of people see JavaScript as amateur hour. We don’t need some overwrought system to allow you to keep doing bad things out of a sense of mathematical purity. All we need is a standard that says which operations need 0, 1, 2, or more arguments to produce behavior that makes (common) sense, and what the error behavior is when those pre-conditions aren’t met. > This is simply the result of my suggestion that this should be left to > those implementing ordering for the types. I don't know better than they > do; neither do you. It seems I do know better, though. And, worse, I happen to know from *experience* that your approach of just letting everyone do what they want willy-nilly results in exactly what I said: an utter mess. > >> It's not that I think this is a bad point. I simply don't believe it's > >> as clear-cut as described. > > > > It is. Perhaps one day you’ll be experienced enough to understand why. > > It is not. Perhaps one day you'll understand enough math to recognize > why. My math is fine. It’s your computer science that isn’t up to snuff. > > I would seek to define a consistent behavior. The *way* garbage comes > > out is important. That’s the entire issue of why an infinity is the > > wrong result. > > I was simply being flip here. I apologize. > > To me `null` or `undefined` would be true garbage. Instead of a function > whose results I can simply use, I would get something that then requires > type-checking, and then manual intervention if I get the wrong type. If > this throws, I cannot compose it with other functions, and need to build > complex logic flows rather than simple functional pipelines. Your (local) simplicity can be maintained if you raise exceptions. The fact is that unexpected behavior and errors need to be accounted for. You can’t just fall back to mathematical purity and say “Well, you’re going to have to live with the results that came back because it satisfies a proof someone made 400 years ago.” Everything more complex than that comes at a cost. > I have no fundamental issue with the thought of instead offering a `Maybe > Number` type (or more generally a `Maybe a` one) for an API, but this > whole discussion is in the context of a function already documented to > return a number. Only because JavaScript defines it solely in Math. Many other languages define similar operations more abstractly on collections. I encourage you to expand your thinking beyond mathematics to the real world uses of these things. Talk to some actual humans about what *they* would say is the maximum value of 3, 2, 1, and even 0 items. I would wager a large amount of money that they’ll all agree to what the result should be down to 1 item, and that essentially *nobody* would offer up -Infinity as the result for 0 items. > If you have a solution for it, do you always throw on an empty list, do > you always return a `null`/`undefined` signal, or do you leave it up the > type to decide? That’s just it: for an empty list, abstractly, there is no “type” of the nothing it contains. The behavior you choose has to be consistent with all kinds of objects. So, sure, it might make the most sense to raise an exception, even for functions like sum() that might otherwise commonly return a 0 value for numbers. > I don't know what sort of position you hold. I work in a large company > with an ongoing mix of old and new software for developers to work on. A > very important skill is trying to figure out how a system or a component > works, and why it's written the way it is. Watching a candidate go > through this exercise, I believe, helps me determine how skilled she is > at this. Not really. Again, you stop with the hack itself when the *real* demonstration of CS skill is everything we’re discussing here. It is trivially easy to discover and put up with bad code, because bad code is everywhere. That is not a rare skill you need to select for. The places I aim to work for are the ones that appreciate the need to get to solutions that are *better* than existing ones. -- "Also . . . I can kill you with my brain." River Tam, Trash, Firefly
[toc] | [prev] | [next] | [standalone]
| From | Scott Sauyet <scott@sauyet.com> |
|---|---|
| Date | 2016-09-10 02:14 +0000 |
| Message-ID | <nqvqac$64e$1@dont-email.me> |
| In reply to | #31271 |
Doc O'Leary wrote:
> Scott Sauyet wrote:
>> Doc O'Leary wrote:
>>> There is a *reason* why languages developed mechanisms other than
>>> “return a valid value and let the programmer figure out if it’s
>>> *actually* a good result, or just some kind of error”.
>>
>> I've argued (most recently in a response to Gene Wirchenko) that this
>> is not only a good result, but the only reasonable value.
>>
>> It allows us to assert laws such as
>>
>> max([max(list1), max(list2)]) === max(concat(list1, list2))
>
> The purpose of Computer Science is *not* to assert mathematical laws.
> It is to do useful work.
So if we're going to write functions to be used in a mathematical
context, we should write functions that are mathematically lucid.
Mathematical laws like the one above make it *easier* to write useful
code. Imagine you have a list of temperatures with timestamps and have
to display the highs for each month and for the year. You partition the
readings by month, pluck the temperatures for each, find the maxima, and
then you can simply take the maximum of that list to to find the annual
high. It's more efficient, and it's even possible that the part of the
system that takes the annual maximum only knows these monthly maxima, not
the raw data.
What makes this possible? The law above.
If instead, you were to return `null` on an empty list, what happens when
it turns out that the sensor was down for all of April and no data was
recorded? April's value is now `null`, and the annual value is `null` or
`NaN` or whatever you choose to return in this case. If you choose to
throw, it's even worse. You're trying to get an annual value, from data
which is perfectly legitimate, but you're implementation is causing you
to throw an exception.
> It is *wrong* to return a result *as if*
> useful work was done when it is highly likely such a result is not only
> in error, but will likely propagate that error.
How would you define the maximum function? I would choose this: "max
returns the smallest value that is no smaller than any element in the
list." That seems succinct, clear and covers all cases (for Numbers, at
least.) ISTM that this works for lists of any size, including empty ones.
>>> It’s best dealt with abstractly, because the concept applies to
>>> things other than numbers. If you can order it, you can determine a
>>> “max” value. And if there is *no* values to order, it is ludicrous
>>> to say the correct result is a valid value you have simply
>>> fabricated.
>>
>> This is no more fabricated than 0 is fabricated as the sum of an empty
>> list of numbers, than 1 is fabricated as the product of an empty list
>> of numbers, or than `true` is fabricated as the result of a call to
>> `all` on an empty list.
>
> They are all fabricated. Done so to reflect their respective identity
> element, sure, but all of them are equally *wrong* behavior from a CS
> perspective.
So it seems reasonable to you that
sum(filter(isOdd, ints)) + sum(filter(isEven, ints))
could have different behavior than
sum(ints)
knowing that `ints` is a non-empty list of integers, and every one
matches either `isEven` or `isOdd`? To me, that's ludicrous.
>> These are the obvious and useful results.
>
> Internally, yes, they are useful in the way that many other hacks are
> useful. But it is not the sign of a competent developer to architect a
> library that *always* returns valid results like that.
Sure, let's all sporadically returns some invalid results. We like to
keep our users on their toes, right? WTF?
> Pull your head out of your math book and actually *think* about the work
> you’re trying to do.
Well, if I'm writing mathematical functions, a math book seems a really
good place to start. And while I do have formal training in mathematics,
this has very little to do with that. It's just common sense.
>> You clipped the bit where I mentioned custom types and how since the
>> user would already have to do the ordering, asking her to also signal
>> the proper behavior here is not unreasonable.
>
> It is in a polymorphic sense. Or do you expect max() to be implemented
> to return -Infinity by *all* developers for all objects? Again, I
> suspect you’ve never really architected a system of substantial
> complexity.
That's funny; that's what I'm feeling about you at this point. I've
worked on small, medium, and large systems. Nothing the size of GMail,
say, but my last project included a custom web framework (similar in
scope to Angular but designed quite a bit differently) a custom business
rules engine, a large utility library, a powerful global event bus, and,
of course, lots of business logic, in about 200K lines of JS. I served
as lead developer and de facto front-end architect as well as coach and
mentor to a large team of mixed-level developers.
I've been writing Javascript since 1998, and it's been my main focus
since 2008. I have one major open source library to my name as well as
many smaller contributions to others.
In other words, I've been around. And yet, you seem to feel that you
know my skill level based on a disagreement about one function, one which
a number of other smart people on this thread are suggesting similar
things as me. That makes me wonder if you're just trolling, or if you
simply don't understand software design very well.
>> I'm suggesting that those who define the types to be used with a
>> generic `max`/`min` would have to define their own boundary values, or
>> signal that they don't exist, not that such a function could do it for
>> an arbitrary type. But I also insist that ±Infinity is the only
>> reasonable choice for Javascript's Number type.
>
> And that kind of thinking is why a lot of people see JavaScript as
> amateur hour. We don’t need some overwrought system to allow you to
> keep doing bad things out of a sense of mathematical purity. All we
> need is a standard that says which operations need 0, 1, 2, or more
> arguments to produce behavior that makes (common) sense, and what the
> error behavior is when those pre-conditions aren’t met.
Javascript *is* amateur hour if you're coming from Haskell, LISP, OCaml,
or some well-designed language. If you don't understand that, you don't
really understand programming. That does not mean we should avoid doing
the best we can.
But we always have to choose our priorities. For a function called
`Math.max`, I would always choose mathematical correctness over possible
abstraction to other types. If I wanted to use the same implementation
for other types I would proceed as above. If not, there would have to be
very serious design decisions. It's quite reasonable for those creating
types to *want* analagous behavior to `max([]); //=> -Infinity`; we'd
have to decide if we wanted to support that when desired or to insist
that we'd have to throw. And of course, all of this is contingent on
being able to determine some sort of context; if we have a single `max`
function that's supposed to infer the type, then we can of course know
nothing about an empty list. Of course we have similar issues with `max
([1, 'a', true, new Date(), {}])`. These are the joys of working in JS,
I'm afraid.
>> This is simply the result of my suggestion that this should be left to
>> those implementing ordering for the types. I don't know better than
>> they do; neither do you.
>
> It seems I do know better, though. And, worse, I happen to know from
> *experience* that your approach of just letting everyone do what they
> want willy-nilly results in exactly what I said: an utter mess.
Are you going to even let them determine how to order their elements? Or
do you think you know better than them about that too?
This is nonsense. This is part of API design, making choices.
You seem to be saying that this is perfectly reasonable:
Ord a :: {
lt :: (a, a) -> Bool,
eq :: (a, a) -> Bool
}
But one that offers additional optional elements of `bottom :: a` and
`top :: a` is ridiculous. I simply don't see why.
>>>> It's not that I think this is a bad point. I simply don't believe
>>>> it's as clear-cut as described.
>>>
>>> It is. Perhaps one day you’ll be experienced enough to understand
>>> why.
>>
>> It is not. Perhaps one day you'll understand enough math to recognize
>> why.
>
> My math is fine. It’s your computer science that isn’t up to snuff.
Nope, try again.
>> To me `null` or `undefined` would be true garbage. Instead of a
>> function whose results I can simply use, I would get something that
>> then requires type-checking, and then manual intervention if I get the
>> wrong type. If this throws, I cannot compose it with other functions,
>> and need to build complex logic flows rather than simple functional
>> pipelines.
>
> Your (local) simplicity can be maintained if you raise exceptions.
> The fact is that unexpected behavior and errors need to be accounted
> for. You can’t just fall back to mathematical purity and say “Well,
> you’re going to have to live with the results that came back because it
> satisfies a proof someone made 400 years ago.” Everything more complex
> than that comes at a cost.
I think you're missing the point.
Badly.
-Infinity is a number. It's a valid number that can be used in
comparisons, in further `max` calls, even in much arithmetic. Granted,
it might not be the best for final displays, but as these should always
be pushed to the edges of your program, it's pretty easy to handle these
in a single place.
A `null` on the other hand really is action at a distance, and it's very
hard to know the original cause of one.
A raised exception will work, but it adds substantial complexity to a
program. They should be used for exceptional circumstances, not for
normal operations. In my `filter(isOdd)` example above, it is not
exceptional for a list of integers to have no odd elements. Using an
exception to handle such a case, or adding coding gymnastics to avoid
getting into such a condition, is adding complexity for very little gain.
>> I have no fundamental issue with the thought of instead offering a
>> `Maybe Number` type (or more generally a `Maybe a` one) for an API, but
>> this whole discussion is in the context of a function already
>> documented to return a number.
>
> Only because JavaScript defines it solely in Math.
Ahh, so you finally realized the context of this discussion?!
> Many other languages define similar operations more abstractly on
> collections.
Yes, they do. Now, if I were to interview you for a job, and were to
say, "This is something of a trick question. Most people find it a
surprising fact that Math.max() < Math.min(). Can think of why it might
be so?" and then started to guide you through it, would you try to answer
my question and engage in the problem at hand, or would you try to
convince me that TC39 or Brendan Eich or whoever had fallen asleep on the
job by not trying to make this a more generic function? Because, believe
me, while I might find that discussion interesting, I would also notice
that you don't seem able to work on the problem assigned.
> I encourage you to expand your thinking beyond mathematics to the real
> world uses of these things. Talk to some actual humans about what
> *they* would say is the maximum value of 3, 2, 1, and even 0 items. I
> would wager a large amount of money that they’ll all agree to what the
> result should be down to 1 item, and that essentially *nobody* would
> offer up -Infinity as the result for 0 items.
It's come up on this thread, and I work with a number of functional
programmers for whom this is totally natural... for numbers. You're
trying to abstract in a way that I find interesting, but not relevant to
a discussion of the function `Math.max`.
>> If you have a solution for it, do you always throw on an empty list, do
>> you always return a `null`/`undefined` signal, or do you leave it up
>> the type to decide?
>
> That’s just it: for an empty list, abstractly, there is no “type” of the
> nothing it contains. The behavior you choose has to be consistent with
> all kinds of objects. So, sure, it might make the most sense to raise
> an exception, even for functions like sum() that might otherwise
> commonly return a 0 value for numbers.
That is only a concern if you are writing a generic `max` function. I'd
actually be curious to see one you wrote. The more I think about it, the
less trivial it seems. You'd need to write a type system that determined
the least common supertype of pairs of elements; you'd have to ensure
that the ordering for subtypes is consistent with that of their parents,
or only allow lists containing the same exact type, which sounds very
restrictive (why couldn't you have a square in a list of rectangles?);
you'd have to enforce rules such as `a < b && b < a; //=> a ~= b`.
It sounds like a big job. Do you already have an implementation at
hand? If not, do you think this is a simple task?
>> I don't know what sort of position you hold. I work in a large company
>> with an ongoing mix of old and new software for developers to work on.
>> A very important skill is trying to figure out how a system or a
>> component works, and why it's written the way it is. Watching a
>> candidate go through this exercise, I believe, helps me determine how
>> skilled she is at this.
>
> Not really. Again, you stop with the hack itself when the *real*
> demonstration of CS skill is everything we’re discussing here. It is
> trivially easy to discover and put up with bad code, because bad code is
> everywhere. That is not a rare skill you need to select for. The
> places I aim to work for are the ones that appreciate the need to get to
> solutions that are *better* than existing ones.
If you cannot discover how something works, I don't want you on my team.
Even if you could design something better from scratch, you're no good to
me if you can't go in and understand what others have done in the system.
That doesn't mean that I don't want to know about how much better you can
do. But if you can't understand existing code, I probably won't trust
your designs anyway, because I have no idea if you really understand the
requirements and the constraints.
-- Scott
[toc] | [prev] | [next] | [standalone]
| From | John Harris <niam@jghnorth.org.uk.invalid> |
|---|---|
| Date | 2016-09-10 11:25 +0100 |
| Message-ID | <8rn7tb5sl4gea5mricmn7rvemv1kn3st3u@4ax.com> |
| In reply to | #31295 |
On Sat, 10 Sep 2016 02:14:36 -0000 (UTC), Scott Sauyet <scott@sauyet.com> wrote: <snip> >-Infinity is a number. It's a valid number that can be used in >comparisons, in further `max` calls, even in much arithmetic. Granted, >it might not be the best for final displays, but as these should always >be pushed to the edges of your program, it's pretty easy to handle these >in a single place. <snip> -Infinity is an ECMAScript Number, but not a genuine number (lower case n), though it is sometimes used in maths to signal don't know, undefined, keep going, etc. If you want a number it would be far more logical to use -Number.MAX_VALUE. If the application is restricted to integers then that would be -Number.MAX_SAFE_INTEGER. John
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-10 15:49 +0100 |
| Message-ID | <87r38ru7vv.fsf@bsb.me.uk> |
| In reply to | #31301 |
John Harris <niam@jghnorth.org.uk.invalid> writes: > On Sat, 10 Sep 2016 02:14:36 -0000 (UTC), Scott Sauyet > <scott@sauyet.com> wrote: > > <snip> >>-Infinity is a number. It's a valid number that can be used in >>comparisons, in further `max` calls, even in much arithmetic. Granted, >>it might not be the best for final displays, but as these should always >>be pushed to the edges of your program, it's pretty easy to handle these >>in a single place. > <snip> > > -Infinity is an ECMAScript Number, but not a genuine number (lower > case n), though it is sometimes used in maths to signal don't know, > undefined, keep going, etc. Since the discussion is about ECMAScript, using -Infinity makes perfect sense. What's more, ECMAScript states when the result of arithmetic operations will be +/-Infinity, and it mandates what results are to returned from expressions involving these quantities. > If you want a number it would be far more logical to use > -Number.MAX_VALUE. If the application is restricted to integers then > that would be -Number.MAX_SAFE_INTEGER. Then, for some values of list, you could have Math.max.apply(null, []) > Math.max.apply(null, list) If Math.max is going to return a value at all (and I think it's reasonable to do so) the -Infinity is the only reasonable choice. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Doc O'Leary <droleary@2015usenet1.subsume.com> |
|---|---|
| Date | 2016-09-10 18:39 +0000 |
| Message-ID | <nr1k0b$d4t$1@dont-email.me> |
| In reply to | #31295 |
For your reference, records indicate that
Scott Sauyet <scott@sauyet.com> wrote:
> So if we're going to write functions to be used in a mathematical
> context, we should write functions that are mathematically lucid.
Except computers *aren’t* only used in a mathematical context. Even
things in Math are called to do work with *meaning*, not demonstrate
some abstract mathematical laws. That’s why it does indeed qualify
as a trick question to compare the results of min/max without
arguments.
> Mathematical laws like the one above make it *easier* to write useful
> code. Imagine you have a list of temperatures with timestamps and have
> to display the highs for each month and for the year. You partition the
> readings by month, pluck the temperatures for each, find the maxima, and
> then you can simply take the maximum of that list to to find the annual
> high. It's more efficient, and it's even possible that the part of the
> system that takes the annual maximum only knows these monthly maxima, not
> the raw data.
The mistake you make is in thinking everything is just about that one
calculation, and that there are no possible errors in the process.
What if instead your wonderful system had a sensor that broke down
one day? Now you have empty set that returns -Infinity as the
maximum temperature! And what if the calculation of interest in
aggregate is instead the *average* maximum temperature for the time
period that now contains that fabricated -Infinity?
> What makes this possible? The law above.
And a lot of incompetent programming.
> If instead, you were to return `null` on an empty list, what happens when
> it turns out that the sensor was down for all of April and no data was
> recorded?
This depends entirely on how you intend to handle a data set that has
missing values. Just as it is possible to have max() return NaN for
non-numeric input, it’s also possible to program it to *ignore*
non-numeric input. I mean, really, what does your wonderful
mathematical law say about any of that?
> April's value is now `null`, and the annual value is `null` or
> `NaN` or whatever you choose to return in this case. If you choose to
> throw, it's even worse. You're trying to get an annual value, from data
> which is perfectly legitimate, but you're implementation is causing you
> to throw an exception.
You haven’t even begun to define what is “legitimate” for mathematical
functions that aren’t operating on mathematical elements. Depending
on the program, it may very well be the correct thing to raise an
exception on the whole thing, or it might be fine to just discard any
values that are out of an acceptable range.
I mean, after all, it’s quite possible for a sensor to return not
only an empty value, but wildly high and low values as well. I
certainly know *I* have dealt with things like real-time GPS data
that falsely indicated I was momentarily *thousands* of miles away
from my actual position. Your desire for mathematical purity is out
the window the instant you have to put error bars on your data.
> > It is *wrong* to return a result *as if*
> > useful work was done when it is highly likely such a result is not only
> > in error, but will likely propagate that error.
>
> How would you define the maximum function? I would choose this: "max
> returns the smallest value that is no smaller than any element in the
> list." That seems succinct, clear and covers all cases (for Numbers, at
> least.) ISTM that this works for lists of any size, including empty ones.
No, that *doesn’t* cover the empty set. You can’t talk about something
like relative smallness when there are no comparisons to be made! It
only makes sense for numbers (for now, so as long as you neglect that
there are different sizes of infinity) because you have a pre-defined
range. For other data types, that’s not always the case. And the root
of my argument is *still* that it is wrong to return a value in the
range of valid input values if that value was not *actually* one of the
input values.
> > They are all fabricated. Done so to reflect their respective identity
> > element, sure, but all of them are equally *wrong* behavior from a CS
> > perspective.
>
> So it seems reasonable to you that
>
> sum(filter(isOdd, ints)) + sum(filter(isEven, ints))
>
> could have different behavior than
>
> sum(ints)
>
> knowing that `ints` is a non-empty list of integers, and every one
> matches either `isEven` or `isOdd`? To me, that's ludicrous.
I have no idea what behavior you’re trying to claim is ludicrous.
Again, from a CS perspective everything you say is ludicrous if you
don’t define what the actual behavior is intended for all of those
functions, including error conditions.
> > Internally, yes, they are useful in the way that many other hacks are
> > useful. But it is not the sign of a competent developer to architect a
> > library that *always* returns valid results like that.
>
> Sure, let's all sporadically returns some invalid results. We like to
> keep our users on their toes, right? WTF?
I’m arguing exactly the opposite, and I think you know that. Being
intellectually dishonest is not the way to make your case.
> In other words, I've been around. And yet, you seem to feel that you
> know my skill level based on a disagreement about one function, one which
> a number of other smart people on this thread are suggesting similar
> things as me. That makes me wonder if you're just trolling, or if you
> simply don't understand software design very well.
The more you keep trying to make an appeal to authority, the more you
undermine any authority you attempt to claim. Same goes for calling
people “smart” just because they agree with you. You’re all wrong
from a CS perspective, and it just makes me think any code you’ve
written is a nightmare to actually use. You’d do yourself and everyone
else a big favor if you could just admit to architectural mistakes like
this, and work to *fix* the problems rather than puffing your chest
out in interviews by way of silly trick questions.
> Javascript *is* amateur hour if you're coming from Haskell, LISP, OCaml,
> or some well-designed language.
Well, OK, we can agree on that. :-) But I’m not willing to accept
that it must continue to be this way. As a competent programmer,
certain *I* would mark this kind of behavior as a bug.
> > It seems I do know better, though. And, worse, I happen to know from
> > *experience* that your approach of just letting everyone do what they
> > want willy-nilly results in exactly what I said: an utter mess.
>
> Are you going to even let them determine how to order their elements? Or
> do you think you know better than them about that too?
Maybe I do. It depends on the system I’m architecting. For example,
I have some concurrent code that implicitly orders operations to
insure an object’s consistency. The last thing I want is someone
thinking they can get the length of an array *before* all the objects
have been added to it!
> You seem to be saying that this is perfectly reasonable:
>
> Ord a :: {
> lt :: (a, a) -> Bool,
> eq :: (a, a) -> Bool
> }
>
> But one that offers additional optional elements of `bottom :: a` and
> `top :: a` is ridiculous. I simply don't see why.
You haven’t defined what any of those operations *actually* mean, so
I can’t comment on any of it, and it is presumptuous of you claim I
would say anything about it. Ask a question of me if you have one;
don’t just create straw men.
> > My math is fine. It’s your computer science that isn’t up to snuff.
>
> Nope, try again.
Man, I *do* keep trying. I think that’s my mistake here.
> I think you're missing the point.
>
> Badly.
>
> -Infinity is a number.
Exactly the point I’m making. It’s a number that didn’t exist in
the input set, but it is being returned in the output set. As a
result, it makes any operations that follow it which *do not* have
-Infinity as the identity element *completely unreliable*.
> > Many other languages define similar operations more abstractly on
> > collections.
>
> Yes, they do. Now, if I were to interview you for a job, and were to
> say, "This is something of a trick question. Most people find it a
> surprising fact that Math.max() < Math.min(). Can think of why it might
> be so?" and then started to guide you through it, would you try to answer
> my question and engage in the problem at hand, or would you try to
> convince me that TC39 or Brendan Eich or whoever had fallen asleep on the
> job by not trying to make this a more generic function?
Because my background is AI, I also have a lot of experience with
psychology and theory of mind. As a result, I can tell you it’s a
mistake for you to think that I should think that the problem you
assigned is the problem you want solved. My experience in collecting
requirements and architecting solutions has made it clear to me that
getting at the *actual* problem to be solved is very much more
important than solving the surface problem that everyone *says* they
want to solve.
So, no, I’m not really sure *what* you’re really trying to get at when
you present a trick question. Do you just want me to agree that it is
the correct result? Do you want me to agree that code *you* write
should also be given a pass when it fails to give expected results for
a < operation? Do you want me to come up with an implementation that
gives a better result? Do you expect me to not see the bear that is
walking through the room?
> Because, believe
> me, while I might find that discussion interesting, I would also notice
> that you don't seem able to work on the problem assigned.
So stop with the pretense you’re looking for skilled developers. You
really want people who agree with you, don’t think too much, keep
their heads down, and just code what you tell them to code. No doubt
that has allowed you to surround yourself by people who make you feel
good about yourself, but you do both yourself and the company you
work for a *huge* disservice by not willing to be challenged when
you’re wrong.
> It's come up on this thread, and I work with a number of functional
> programmers for whom this is totally natural... for numbers. You're
> trying to abstract in a way that I find interesting, but not relevant to
> a discussion of the function `Math.max`.
I argue it *is* relevant because the identity element is only
meaningful on a per-function basis. Even if you stick to
mathematical functions, it is wrong to treat it as a useful value
in future calculations.
> > That’s just it: for an empty list, abstractly, there is no “type” of the
> > nothing it contains. The behavior you choose has to be consistent with
> > all kinds of objects. So, sure, it might make the most sense to raise
> > an exception, even for functions like sum() that might otherwise
> > commonly return a 0 value for numbers.
>
> That is only a concern if you are writing a generic `max` function. I'd
> actually be curious to see one you wrote. The more I think about it, the
> less trivial it seems.
Welcome to computer science. It’s a shame you’ve done so much work
in the field before realizing that not everything is simple numbers,
and that complex things are not easy to do.
> It sounds like a big job. Do you already have an implementation at
> hand? If not, do you think this is a simple task?
Yeah, I do. But so do *many* existing programming languages. It all
starts with getting your head out of the mathematical clouds. Until
you’re willing to do that, and actually talk about the useful work
that these functions are intended to do, the details don’t matter.
> If you cannot discover how something works, I don't want you on my team.
> Even if you could design something better from scratch, you're no good to
> me if you can't go in and understand what others have done in the system.
As I have said, understanding bad code is trivial. You’re not doing
a very good job of filtering candidates if you simply are looking for
them to determine *how* something got done badly. The biggest flaw
you have is that it does seems that that *is* all you really want
though, and you count it against a person if they actually want to
write better software. I mean, I certainly *could* “discover” how
to do all sorts of *awful* things in this world, but if that’s the
kind of team you’re really looking to put together, then I don’t
want to be on it.
> That doesn't mean that I don't want to know about how much better you can
> do. But if you can't understand existing code, I probably won't trust
> your designs anyway, because I have no idea if you really understand the
> requirements and the constraints.
But I have no idea whether or not *you* understand them. I’ve seen
a lot of effort wasted because clients keep insisting on getting what
they *want* rather than taking a step back and thinking about what
they really *need*. The more you try to make it about “existing
code”, the less I think you’re interested in actually solving the
problem the code was written for in the first place.
--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly
[toc] | [prev] | [next] | [standalone]
| From | Scott Sauyet <scott@sauyet.com> |
|---|---|
| Date | 2016-09-11 02:45 +0000 |
| Message-ID | <nr2gg3$esh$2@dont-email.me> |
| In reply to | #31311 |
Doc O'Leary wrote:
> Scott Sauyet wrote:
>> So if we're going to write functions to be used in a mathematical
>> context, we should write functions that are mathematically lucid.
>
> Except computers *aren’t* only used in a mathematical context. Even
> things in Math are called to do work with *meaning*, not demonstrate
> some abstract mathematical laws.
These abstract mathematical laws you're talking about are what *define*
the meaning in mathematics. What would you think of a version of
`Sting.prototype.toUpperCase` which upper-cased all the characters,
except that it skipped every 37th one? It would be well-defined by
these rules, but it's totally non-sensical in a general-purpose utility.
That's because the most obvious rule for `toUpperCase` is that it
returns a String with characters all in upper-case. The sorts of laws
I'm talking about are what define mathematical operations.
> That’s why it does indeed qualify
> as a trick question to compare the results of min/max without
> arguments.
Again, I introduce this with the words "trick question", mostly to put
candidates in the right frame of mind. But I do think it is a very
useful part of a discussion with certain interviewees; Those who can
figure out why this happens with little or no guidance have notably
different skills than those who never really figure any of it out on
their own.
>> Mathematical laws like the one above make it *easier* to write useful
>> code. Imagine you have a list of temperatures with timestamps and
have
>> to display the highs for each month and for the year. You partition
the
>> readings by month, pluck the temperatures for each, find the maxima,
and
>> then you can simply take the maximum of that list to to find the
annual
>> high. It's more efficient, and it's even possible that the part of
the
>> system that takes the annual maximum only knows these monthly maxima,
not
>> the raw data.
>
> The mistake you make is in thinking everything is just about that one
> calculation, and that there are no possible errors in the process.
> What if instead your wonderful system had a sensor that broke down
> one day? Now you have empty set that returns -Infinity as the
> maximum temperature! And what if the calculation of interest in
> aggregate is instead the *average* maximum temperature for the time
> period that now contains that fabricated -Infinity?
Funny, I was pointing out how beneficial it was that we had such a
useful -Infinity.
If you're worried about the average, then you'd better do some other
error checking regardless: I don't think there's really too much to
choose from between `-Infinity / 0` and `null / 0`.
>> What makes this possible? The law above.
>
> And a lot of incompetent programming.
In one school of programming, there are a million ways things can go
wrong, because all of your functions have weird edge cases that you have
to handle. To work in such an environment, one needs to add error-
checking everywhere. In this world it's considered competence to
thoroughly cover these cases.
In another one, one writes functions that have consistent behavior,
where they take specific types of input and return a given type of
output. They avoid such things as null returns. To work in such an
environment, one needs to ensure that one's functions are clear and
consistent. In this world, it's considered competence to create
simple and elegant code.
The former seems to be the world you're describing. I worked in Java
for enough years that I remember that world. But as I moved into
functional languages, I also moved more into a world where that sort
of error-checking became unnecessary. I certainly don't miss it.
>> If instead, you were to return `null` on an empty list, what happens
when
>> it turns out that the sensor was down for all of April and no data was
>> recorded?
>
> This depends entirely on how you intend to handle a data set that has
> missing values. Just as it is possible to have max() return NaN for
> non-numeric input, it’s also possible to program it to *ignore*
> non-numeric input. I mean, really, what does your wonderful
> mathematical law say about any of that?
Right, but the question was not about non-numeric input but about an
empty list of input, where you seemed to be claiming that any numeric
value is illegitimate, leaving only something such as `null`/`undefined`
or an exception. Or do you have a different solution?
>> April's value is now `null`, and the annual value is `null` or
>> `NaN` or whatever you choose to return in this case. If you choose to
>> throw, it's even worse. You're trying to get an annual value, from
data
>> which is perfectly legitimate, but you're implementation is causing
you
>> to throw an exception.
>
> You haven’t even begun to define what is “legitimate” for mathematical
> functions that aren’t operating on mathematical elements. Depending
> on the program, it may very well be the correct thing to raise an
> exception on the whole thing, or it might be fine to just discard any
> values that are out of an acceptable range.
I object to raising an exception, as I don't think it's exceptional that
a list might be empty. But of course one might discard unacceptable
values. I would expect that to happen first and not affect the rest of
the problem at all.
> I mean, after all, it’s quite possible for a sensor to return not
> only an empty value, but wildly high and low values as well. I
> certainly know *I* have dealt with things like real-time GPS data
> that falsely indicated I was momentarily *thousands* of miles away
> from my actual position. Your desire for mathematical purity is out
> the window the instant you have to put error bars on your data.
No, it's just part of the process: simply filter the data appropriately.
This has nothing to do with the question, though.
>>> It is *wrong* to return a result *as if*
>>> useful work was done when it is highly likely such a result is not
only
>>> in error, but will likely propagate that error.
>>
>> How would you define the maximum function? I would choose this: "max
>> returns the smallest value that is no smaller than any element in the
>> list." That seems succinct, clear and covers all cases (for Numbers,
at
>> least.) ISTM that this works for lists of any size, including empty
ones.
>
> No, that *doesn’t* cover the empty set. You can’t talk about something
> like relative smallness when there are no comparisons to be made!
There have been several references already in this thread to the Wikipedia
article on Vacuous Truths [1]. *Please* try to read and understand it
before writing nonsense like this again!
> It only makes sense for numbers (for now, so as long as you neglect
that
> there are different sizes of infinity) because you have a pre-defined
> range.
Yes, it only makes sense for numbers. I've been at pains to make that
obvious. But the comment on multiple sizes of Infinity is a non sequitur.
Yes, there are multiple sizes of infinity, thank you Mr. Cantor, but
Javascript's floating point numbers implement the IEEE 754 specification
which have special values of a positive and a negative infinity, and no
other infinite options. (`NaN` is a more complex story.) When speaking
in
Javascript, -Infinity is a very specific value, which happens to compare
as less than any other numeric value (except `NaN`.)
> For other data types, that’s not always the case. And the root
> of my argument is *still* that it is wrong to return a value in the
> range of valid input values if that value was not *actually* one of the
> input values.
Again, can you define (or, even better, implement) the function you
think is appropriate?
You see, I disagre with your contention here. I think of `max` in the
same way I think of `sum`, `all`, etc., as a way to *combine* values,
and not as a way to *select* a value. And again, my definition works
with this notion. And there are many obvious ways to implement it.
Thomas Lahn and others have already done so in this thread, and it's
trivial to do so with a fold.
Is there some clear way to express your suggestion in code?
> [ ... ]
>>> Internally, yes, they are useful in the way that many other hacks are
>>> useful. But it is not the sign of a competent developer to architect
a
>>> library that *always* returns valid results like that.
>>
>> Sure, let's all sporadically returns some invalid results. We like to
>> keep our users on their toes, right? WTF?
>
> I’m arguing exactly the opposite, and I think you know that. Being
> intellectually dishonest is not the way to make your case.
Perhaps you miswrote, or perhaps I'm misreading. But looking it over
again, you still seem to me to be saying that a competent developer
would not architect a library to always return valid results. Did you
mean something different? Do you see from the paragraph above why I
interpret it that way?
>> In other words, I've been around. And yet, you seem to feel that you
>> know my skill level based on a disagreement about one function, one
which
>> a number of other smart people on this thread are suggesting similar
>> things as me. That makes me wonder if you're just trolling, or if you
>> simply don't understand software design very well.
>
> The more you keep trying to make an appeal to authority, the more you
> undermine any authority you attempt to claim.
Ok, some basic logical reasoning here. First of all, there is no appeal
to authority (_argumentum ab auctoritate_). Even a case for _argumentum
ad
populum_ would be extremely weak. I did not try to claim that the support
of those other people made my claim true; instead I noted how strange it
was for you to try to judge my skills based on your disagreement with me
on one topic that you disagree with all these other people on as well.
Second of all, "the more you keep trying to"? On what basis do you use
this phrase? Where else in our discussion have I cited the opinions of
others in this thread?
> Same goes for calling people “smart” just because they agree with you.
I've been involved in comp.lang.javascript for about seven years. Among
the people who've posted in this part of the discussion are Stefan Ram,
Thomas Lahn, John Harris, Andreas Bergmaier, Ben Bacarisse, and Michael
Haufe, all of whom have been around that whole time, and Ken Tilton and
Gene Wirchenko who are somewhat newer. All of these people have shown
themselves over the years to be competent and intellegent in
conversation. (That doesn't mean I like them all, BTW!) I have no clue
about you. I'm not calling them smart because they agree with me.
Thomas Lahn and I rarely ever agree. But I don't doubt his intelligence.
> You’re all wrong from a CS perspective,
You see, I find you all wrong, also from a CS perspective. Do you happen
to work mostly in languages like Java or C#, by any chance? Perhaps
you've simply not had a chance to work in an environment/language that
affords you the opportunity to write really nice code without reams of
boilerplate error-checking.
> and it just makes me think any code you’ve written is a nightmare to
> actually use.
If you have a little time, do look into Ramda, and tell me if it lives
down to these expectations of yours? Most of the complaints are that
it's too strict, not that it's too loose, so I'm curious as to how
you see it.
> You’d do yourself and everyone
> else a big favor if you could just admit to architectural mistakes like
> this, and work to *fix* the problems rather than puffing your chest
> out in interviews by way of silly trick questions.
What problem are you suggesting I fix? Do you want me to fix the
specification for `Math.max`/`Math.min`? While every now and then I
participate in es-discuss, I'm not part of TC39, nor do I have any
interest in becoming part of it.
And where in the world do you get the idea that I'm puffing out my
chest with this question? This is nothing like a "gotcha" question.
It is a guided (as much as necessary) through a somewhat surprising
result to see how the candidate thinks her way to an understanding
of the function.
But I'll tell you what. If you can offer me a question or series of
questions that will give me the same sort of insight into the
candidates, I will replace this one from my routine. Remember
that what I want to know is *how* and *how well* she reasons about
such behavior,
>>> It seems I do know better, though. And, worse, I happen to know from
>>> *experience* that your approach of just letting everyone do what they
>>> want willy-nilly results in exactly what I said: an utter mess.
>>
>> Are you going to even let them determine how to order their elements?
Or
>> do you think you know better than them about that too?
>
> Maybe I do. It depends on the system I’m architecting. For example,
> I have some concurrent code that implicitly orders operations to
> insure an object’s consistency. The last thing I want is someone
> thinking they can get the length of an array *before* all the objects
> have been added to it!
I said "order", not "sort". "order"ing generally is used to represent an
operation on two elements on your type that reports if one of them is less
than the other. There are many ways to do this. Haskell [2] extends the
`Eq` type (which has just a boolean `eq` function) with a `<=` operator
(or equivalently a `compare` function) that returns true in the case that
the first operand is less than or equal to the second.
My question was rhetorical. I was poking at you. Of course you have
to let those defining a type determine how to order their elements, or
even decide if they can be ordered.
>> You seem to be saying that this is perfectly reasonable:
>>
>> Ord a :: {
>> lt :: (a, a) -> Bool,
>> eq :: (a, a) -> Bool
>> }
>>
>> But one that offers additional optional elements of `bottom :: a` and
>> `top :: a` is ridiculous. I simply don't see why.
>
> You haven’t defined what any of those operations *actually* mean, so
> I can’t comment on any of it, and it is presumptuous of you claim I
> would say anything about it. Ask a question of me if you have one;
> don’t just create straw men.
This is simply a translation of the discussion so far into pseudo-code.
You were the one who called me out for the suggestion that generic max/
min
functions might offer the user the ability to decide whether to return a
default smallest or largest value in response to an empty list. The
plain `Ord` above would give you the ability to create an ordering in a
manner somewhat similar to the Haskell description. By adding `bottom`
and `top` values, you create defaults for empty lists. Without them
presumably such generic functions would throw, return semaphores.
Here would be a reasonable version for Number:
ordered(Number, {
lt: (a, b) => a < b,
eq: (a, b) => a == b,
bottom: -Infinity,
top: Infinity
});
>> [ ... ]
>> -Infinity is a number.
>
> Exactly the point I’m making. It’s a number that didn’t exist in
> the input set, but it is being returned in the output set. As a
> result, it makes any operations that follow it which *do not* have
> -Infinity as the identity element *completely unreliable*.
What part of "This is a function for `Math.max`" don't you understand?
> [ ... psychology elided ...]
> So, no, I’m not really sure *what* you’re really trying to get at when
> you present a trick question. Do you just want me to agree that it is
> the correct result? Do you want me to agree that code *you* write
> should also be given a pass when it fails to give expected results for
> a < operation? Do you want me to come up with an implementation that
> gives a better result? Do you expect me to not see the bear that is
> walking through the room?
No, I'd really like you to try to answer the question.
>> Because, believe
>> me, while I might find that discussion interesting, I would also
notice
>> that you don't seem able to work on the problem assigned.
>
> So stop with the pretense you’re looking for skilled developers. You
> really want people who agree with you, don’t think too much, keep
> their heads down, and just code what you tell them to code. No doubt
> that has allowed you to surround yourself by people who make you feel
> good about yourself, but you do both yourself and the company you
> work for a *huge* disservice by not willing to be challenged when
> you’re wrong.
And you accuse me of straw men?!!
Where do you get this bullshit? I do not ask candidates to justify (or
to denigrate) the design of these functions. I just ask if they can try
to imagine why it works as it does. And I guide them as much as they
need so that they never walk away from this discussion without an
answer.
>> It's come up on this thread, and I work with a number of functional
>> programmers for whom this is totally natural... for numbers. You're
>> trying to abstract in a way that I find interesting, but not relevant
to
>> a discussion of the function `Math.max`.
>
> I argue it *is* relevant because the identity element is only
> meaningful on a per-function basis. Even if you stick to
> mathematical functions, it is wrong to treat it as a useful value
> in future calculations.
Once again, you're full of _non sequiturs_. Why in the world would you
think otherwise? Would you expect the same identity value for `all` as
for `product` as for `max` as for `sum`? That's absurd! But why does
the fact that they're different make them less useful? You said earlier
that your math is fine, but I'm really starting to doubt it.
>>> That’s just it: for an empty list, abstractly, there is no “type” of
the
>>> nothing it contains. The behavior you choose has to be consistent
with
>>> all kinds of objects. So, sure, it might make the most sense to raise
>>> an exception, even for functions like sum() that might otherwise
>>> commonly return a 0 value for numbers.
>>
>> That is only a concern if you are writing a generic `max` function.
I'd
>> actually be curious to see one you wrote. The more I think about it,
the
>> less trivial it seems.
>
> Welcome to computer science. It’s a shame you’ve done so much work
> in the field before realizing that not everything is simple numbers,
> and that complex things are not easy to do.
Again, I urge you to look at Ramda: Many functions on lists, on
objects, on functions. Fewer on strings and still fewer on numbers, but
then others that work on generic Functors, Monoids, Applicatives,
Monads, etc. But the goal is to keep the API simple, even when our
underlying implementation is not.
Most of my day job involves working with custom objects. Working with
math is mostly hobby-time coding. So no, I don't think everything should
look like math.
But that doesn't mean that I think everything should work immediately
with the first abstaction that leaps to mind.
>> It sounds like a big job. Do you already have an implementation at
>> hand? If not, do you think this is a simple task?
>
> Yeah, I do. But so do *many* existing programming languages. It all
> starts with getting your head out of the mathematical clouds. Until
> you’re willing to do that, and actually talk about the useful work
> that these functions are intended to do, the details don’t matter.
I've been asking what your generic solution is. I'm interested in seeing
if it seems reasonable for the sorts of situations I find myself in, if
it seems robust, it it does what you're claiming it does.
I can implement this in just a few lines of Haskell, but to do it
reasonably in Javascript you're going to have to create a type system.
That's a substantial job, and seems quite the overkill just to abstract
`max` and `min` functions. So I'm curious to see if you have found some
short-cuts to avoid all the problems inherent in developing a type
system for a dynamic language.
Is your solution something your able and willing to share?
>> If you cannot discover how something works, I don't want you on my
team.
>> Even if you could design something better from scratch, you're no good
to
>> me if you can't go in and understand what others have done in the
system.
>
> As I have said, understanding bad code is trivial.
Can you say that again?
With a straight face?
Have you ever worked on a complex system that includes bad code? Was it
all trivial to understand? (If the answer to the second question was
"yes", please reread the first one again!)
> You’re not doing a very good job of filtering candidates if you
> simply are looking for them to determine *how* something got done
> badly.
Did I ever say that this was *all* I looked for from candidates?
Did I ever imply it?
Did I ever make the suggestion that this was anything more than four
to six minutes of a 60 - 90 minute interview?
Did I not note that this was only used for candidates who's already
impressed me a bit, as a way to learn more about the better ones?
> The biggest flaw
> you have is that it does seems that that *is* all you really want
> though, and you count it against a person if they actually want to
> write better software.
Wow -- Are you going to hang your shingle out with Lucy Van Pelt?
> I mean, I certainly *could* “discover” how
> to do all sorts of *awful* things in this world, but if that’s the
> kind of team you’re really looking to put together, then I don’t
> want to be on it.
Well, remember that I happen to believe this is the absolutely correct
behavior for `Math.max`, So I don't share your sentiment at all. But
none of that is really all that important in a discussion about how to
interpret the actions of an existing function.
>> That doesn't mean that I don't want to know about how much better you
can
>> do. But if you can't understand existing code, I probably won't trust
>> your designs anyway, because I have no idea if you really understand
the
>> requirements and the constraints.
>
> But I have no idea whether or not *you* understand them. I’ve seen
> a lot of effort wasted because clients keep insisting on getting what
> they *want* rather than taking a step back and thinking about what
> they really *need*. The more you try to make it about “existing
> code”, the less I think you’re interested in actually solving the
> problem the code was written for in the first place.
Have you ever performed interviews?
[1]: <https://en.wikipedia.org/wiki/Vacuous_truth>
[2]: <https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-
Ord.html>
-- Scott
[toc] | [prev] | [next] | [standalone]
| From | John Harris <niam@jghnorth.org.uk.invalid> |
|---|---|
| Date | 2016-09-11 16:23 +0100 |
| Message-ID | <kltatb9s2ik11fmnloh51feb6spru32spt@4ax.com> |
| In reply to | #31314 |
On Sun, 11 Sep 2016 02:45:24 -0000 (UTC), Scott Sauyet <scott@sauyet.com> wrote: <snip> >You see, I find you all wrong, also from a CS perspective. Do you happen >to work mostly in languages like Java or C#, by any chance? Perhaps >you've simply not had a chance to work in an environment/language that >affords you the opportunity to write really nice code without reams of >boilerplate error-checking. <snip> One problem with this conversation is that one side is talking about ordinary languages such as Algol and C++ whereas the other side is talking about Functional Programming languages/implementations. The former must cope with partial functions. Many commercial applications need this. Division is a common example. Customer's telephone numbers are another example. The latter can't. A partial function is forbidden as it wrecks the algebra of operations. John
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-12 20:32 +0100 |
| Message-ID | <87inu0sym4.fsf@bsb.me.uk> |
| In reply to | #31322 |
John Harris <niam@jghnorth.org.uk.invalid> writes: > On Sun, 11 Sep 2016 02:45:24 -0000 (UTC), Scott Sauyet > <scott@sauyet.com> wrote: > > <snip> >>You see, I find you all wrong, also from a CS perspective. Do you happen >>to work mostly in languages like Java or C#, by any chance? Perhaps >>you've simply not had a chance to work in an environment/language that >>affords you the opportunity to write really nice code without reams of >>boilerplate error-checking. > <snip> > > One problem with this conversation is that one side is talking about > ordinary languages such as Algol and C++ whereas the other side is > talking about Functional Programming languages/implementations. People have been drawing on varied backgrounds, but the focus has been on ECMAScript's variadic Math.max function. Ultimately, all the points have to be relevant to that and I think that has been the case in the vast majority of the posts. In that since it's been a very good discussion. > The former must cope with partial functions. Many commercial > applications need this. Division is a common example. Customer's > telephone numbers are another example. > > The latter can't. A partial function is forbidden as it wrecks the > algebra of operations. I don't get your point at all. I suspect some miss-communication because functional languages often have partial functions at their core. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Doc O'Leary <droleary@2015usenet1.subsume.com> |
|---|---|
| Date | 2016-09-12 18:49 +0000 |
| Message-ID | <nr6tcg$lka$1@dont-email.me> |
| In reply to | #31314 |
For your reference, records indicate that Scott Sauyet <scott@sauyet.com> wrote: > Doc O'Leary wrote: > > Scott Sauyet wrote: > > >> So if we're going to write functions to be used in a mathematical > >> context, we should write functions that are mathematically lucid. > > > > Except computers *aren’t* only used in a mathematical context. Even > > things in Math are called to do work with *meaning*, not demonstrate > > some abstract mathematical laws. > > These abstract mathematical laws you're talking about are what *define* > the meaning in mathematics. What would you think of a version of > `Sting.prototype.toUpperCase` which upper-cased all the characters, > except that it skipped every 37th one? I grow tired of these patently absurd straw man arguments. I’m talking about one very simple issue: whether or not a function like max() should return a valid value when it is called with 0 arguments. Your argument from a purely mathematics perspective has been given and answered. If you have nothing new to add, we’re done here. > In one school of programming, there are a million ways things can go > wrong, because all of your functions have weird edge cases that you have > to handle. Says the person who enjoy a trick question of a comparison behaving unexpectedly, and yet also argues that that is the correct behavior. > In another one, one writes functions that have consistent behavior, > where they take specific types of input and return a given type of > output. They avoid such things as null returns. To work in such an > environment, one needs to ensure that one's functions are clear and > consistent. In this world, it's considered competence to create > simple and elegant code. Which *still* would have max() being less than min(). Wow! So elegant. Much consistency. > The former seems to be the world you're describing. I worked in Java > for enough years that I remember that world. But as I moved into > functional languages, I also moved more into a world where that sort > of error-checking became unnecessary. For +Infinity values of “unnecessary”. > > This depends entirely on how you intend to handle a data set that has > > missing values. Just as it is possible to have max() return NaN for > > non-numeric input, it’s also possible to program it to *ignore* > > non-numeric input. I mean, really, what does your wonderful > > mathematical law say about any of that? > > Right, but the question was not about non-numeric input but about an > empty list of input, where you seemed to be claiming that any numeric > value is illegitimate, leaving only something such as `null`/`undefined` > or an exception. Or do you have a different solution? I’m not sure why you think you need a different solution. If you return an invalid result on an empty set, but invalid values are otherwise discarded, any set that *does* contain at least one numeric value would return that value as the maximum numeric value of that set. Seems simple enough. > I object to raising an exception, as I don't think it's exceptional that > a list might be empty. You’re not raising it on the empty list, you’re raising it on the *operation* on that list because there is no *meaningful* result. You’re welcome to set preconditions that avoid the exception, which is the *only* thing you’d be able to do if you didn’t want the current behavior of fabricated infinities polluting your data set. > > I mean, after all, it’s quite possible for a sensor to return not > > only an empty value, but wildly high and low values as well. I > > certainly know *I* have dealt with things like real-time GPS data > > that falsely indicated I was momentarily *thousands* of miles away > > from my actual position. Your desire for mathematical purity is out > > the window the instant you have to put error bars on your data. > > No, it's just part of the process: simply filter the data appropriately. > > This has nothing to do with the question, though. It does, in that a fabricated infinity needs to be handled as an error, but only if it *wasn’t* part of the valid input. Your mathematical purity doesn’t make for any less of a mess. > > No, that *doesn’t* cover the empty set. You can’t talk about something > > like relative smallness when there are no comparisons to be made! > > There have been several references already in this thread to the Wikipedia > article on Vacuous Truths [1]. *Please* try to read and understand it > before writing nonsense like this again! And I wish *you* would please understand that I’m looking to do useful work when I employ computer science. Again, it’s tiresome that you can’t seem to reach beyond your mathematics education. > You see, I disagre with your contention here. I think of `max` in the > same way I think of `sum`, `all`, etc., as a way to *combine* values, > and not as a way to *select* a value. Even by that logic, there are *no values to combine* in an empty set! To pick the identity element as the result is itself problematic, as your trick question highlights. The burden is on *you* to provide a consistent result, not me. Me, I’m fine dealing with exceptions or non-numeric results because I’m a computer scientist. > >> Sure, let's all sporadically returns some invalid results. We like to > >> keep our users on their toes, right? WTF? > > > > I’m arguing exactly the opposite, and I think you know that. Being > > intellectually dishonest is not the way to make your case. > > Perhaps you miswrote, or perhaps I'm misreading. But looking it over > again, you still seem to me to be saying that a competent developer > would not architect a library to always return valid results. Did you > mean something different? Do you see from the paragraph above why I > interpret it that way? A function should not return a result in a valid range if the operation should not yield such a result. It is *because* we want max() >= min() to hold true, along with all sorts of other following operations, that it is *wrong* for those functions to return values that are inconsistent with that thinking. It is *your* desire to return identities that will “keep our users on their toes”; *you* are arguing for the “sporadically invalid result” that results in the trick question you think is so nifty. > > The more you keep trying to make an appeal to authority, the more you > > undermine any authority you attempt to claim. > > Ok, some basic logical reasoning here. First of all, there is no appeal > to authority (_argumentum ab auctoritate_). Incorrect. You are trotting out your work credentials as if they alone should be reason to see that you are right. Don’t show us you’ve managed to fool your bosses into thinking you know what you’re doing, show us a sound argument that directly proves it. > All of these people have shown > themselves over the years to be competent and intellegent in > conversation. (That doesn't mean I like them all, BTW!) I have no clue > about you. I'm not calling them smart because they agree with me. > Thomas Lahn and I rarely ever agree. But I don't doubt his intelligence. Well it’s good to know you still doubt mine. > > You’re all wrong from a CS perspective, > > You see, I find you all wrong, also from a CS perspective. Do you happen > to work mostly in languages like Java or C#, by any chance? Perhaps > you've simply not had a chance to work in an environment/language that > affords you the opportunity to write really nice code without reams of > boilerplate error-checking. You’re accepting fabricated infinities as valid values in your data. If you’re not *heavily* doing error detection, you’re just not very good at your job. Please again tell us how many people you’ve mentored over the years . . . > > and it just makes me think any code you’ve written is a nightmare to > > actually use. > > If you have a little time, do look into Ramda, and tell me if it lives > down to these expectations of yours? Most of the complaints are that > it's too strict, not that it's too loose, so I'm curious as to how > you see it. I’m not inclined to do a free code audit at this time. And, heck, I might not even be able to make it past your clever interview process if you made a job of it. > > You’d do yourself and everyone > > else a big favor if you could just admit to architectural mistakes like > > this, and work to *fix* the problems rather than puffing your chest > > out in interviews by way of silly trick questions. > > What problem are you suggesting I fix? Do you want me to fix the > specification for `Math.max`/`Math.min`? Yes. Or, at the very least, begin actually talking about the behavior as being a genuine error rather than just an idle curiosity. There is no productive reason for bringing it up in an interview unless you’re looking to mitigate the problems that the current behavior causes. > And where in the world do you get the idea that I'm puffing out my > chest with this question? This is nothing like a "gotcha" question. > It is a guided (as much as necessary) through a somewhat surprising > result to see how the candidate thinks her way to an understanding > of the function. But to go no deeper than that *is* a signal that it’s all about the show rather than doing useful work. It’s a whole lot of juvenile “I know something you don’t know” rather than a professional “Here’s a problem we need to address”. > But I'll tell you what. If you can offer me a question or series of > questions that will give me the same sort of insight into the > candidates, I will replace this one from my routine. Remember > that what I want to know is *how* and *how well* she reasons about > such behavior, Again, I’m not inclined to do your job for you. As it stands, you do the rest of the world a favor when you hire the candidates that nobody else would want. > >> Are you going to even let them determine how to order their elements? > Or > >> do you think you know better than them about that too? > > > > Maybe I do. It depends on the system I’m architecting. For example, > > I have some concurrent code that implicitly orders operations to > > insure an object’s consistency. The last thing I want is someone > > thinking they can get the length of an array *before* all the objects > > have been added to it! > > I said "order", not "sort". And I didn’t say “sort”, so do try not to fabricate another straw man. > My question was rhetorical. I was poking at you. Of course you have > to let those defining a type determine how to order their elements, or > even decide if they can be ordered. Again, I disagree. It it *very* likely that out-of-order execution is the way to architect a modern system that has constraints which aren’t (necessarily) exposed to the end user. You think you’re being clever when you’re “poking” like that, but all you’re doing is exposing a real lack of experience when it comes to doing complex engineering. > >> -Infinity is a number. > > > > Exactly the point I’m making. It’s a number that didn’t exist in > > the input set, but it is being returned in the output set. As a > > result, it makes any operations that follow it which *do not* have > > -Infinity as the identity element *completely unreliable*. > > What part of "This is a function for `Math.max`" don't you understand? The part where you use the fabricated result in future computations without any error checking. I don’t understand that *at all*. > No, I'd really like you to try to answer the question. I already did. It’s a hack. They initialized the result to -Infinity because they were too lazy to handle an empty list more intelligently. It also happens to convenient match the identity element for that operation, which compounds the mistake. It’s essentially numerology, and you should be embarrassed for thinking it’s OK. So, do I get the job? :-) > > So stop with the pretense you’re looking for skilled developers. You > > really want people who agree with you, don’t think too much, keep > > their heads down, and just code what you tell them to code. No doubt > > that has allowed you to surround yourself by people who make you feel > > good about yourself, but you do both yourself and the company you > > work for a *huge* disservice by not willing to be challenged when > > you’re wrong. > > And you accuse me of straw men?!! When it applies, yes. Certainly, of course, I *can’t* really know your motivations for your poor hiring practices. You’re an unreliable witness to you own behavior, though. I do still encourage you to think about whether or not what you *claim* you’re screening for is actually what you *do* screen for, in a real scientific sense. > Where do you get this bullshit? I do not ask candidates to justify (or > to denigrate) the design of these functions. I just ask if they can try > to imagine why it works as it does. And I guide them as much as they > need so that they never walk away from this discussion without an > answer. Indeed, that is the problem. That is why I characterized your behavior the way I did. > > I argue it *is* relevant because the identity element is only > > meaningful on a per-function basis. Even if you stick to > > mathematical functions, it is wrong to treat it as a useful value > > in future calculations. > > Once again, you're full of _non sequiturs_. Why in the world would you > think otherwise? Would you expect the same identity value for `all` as > for `product` as for `max` as for `sum`? That's absurd! Indeed it is. Again, that is *my* argument you’re supporting. > But why does > the fact that they're different make them less useful? Sigh. For the last time, because they lead to the conditions that allow you to ask your silly trick questions. Because they introduce bugs in code. > Is your solution something your able and willing to share? Again, start with any of the *dozens* of other languages that already do the same thing. I’m not about to do any free work beyond that when you have made it *very* clear here that you’re unwilling to accept an answer for numbers that is anything other than: Math.max() == -Infinity; > > As I have said, understanding bad code is trivial. > > Can you say that again? > > With a straight face? > > Have you ever worked on a complex system that includes bad code? Was it > all trivial to understand? (If the answer to the second question was > "yes", please reread the first one again!) Yes and Yes. All I have to do to understand bad code is to turn off the parts of my brain that are thinking critically about it. If you don’t have those parts, and if your brain thinks a *different* wrong is right, only then would I expect you to find it hard to understand a particular bit of bad code. > > You’re not doing a very good job of filtering candidates if you > > simply are looking for them to determine *how* something got done > > badly. > > Did I ever say that this was *all* I looked for from candidates? > > Did I ever imply it? Yes. You said you’d have a problem with me if I couldn’t “get back down to Earth” (or some similar phrase) when you raised the issue. > Did I ever make the suggestion that this was anything more than four > to six minutes of a 60 - 90 minute interview? And, again, that’s exactly the problem. You think it’s a nothing issue, but you’re wrong. But you refuse to take the time to *be* wrong, so you compound your error. You interview like you code. > Did I not note that this was only used for candidates who's already > impressed me a bit, as a way to learn more about the better ones? Who you proceed to cut off at the knee before they even get a chance to dive deep. Here we’ve had what could still be a productive discussion about the tradeoff, but your own words describe how little that sort of candidate would interest you in an interview. > Have you ever performed interviews? Yes. All indications are I do a *much* worse job than you do in inflating my own ego when I do them. Maybe it’s because I’m looking to hire someone who is competent that I can delegate complex jobs to, and who is willing to tell me when I’m being foolish. I guess I’ve just had too much experience with jerk bosses to approach things the way you do. -- "Also . . . I can kill you with my brain." River Tam, Trash, Firefly
[toc] | [prev] | [next] | [standalone]
| From | Scott Sauyet <scott@sauyet.com> |
|---|---|
| Date | 2016-09-13 00:27 +0000 |
| Message-ID | <nr7h4k$lnc$1@dont-email.me> |
| In reply to | #31342 |
Doc O'Leary wrote: > I grow tired of these patently absurd straw man arguments. Likewise. We're clearly talking past each other here. You haven't managed to convince me that there is anything at all wrong with returning -Infinity for `Math.max()` or that my interview question is flawed. And I certainly haven't been able to convince you of the benefits of enforcing simple laws about how a function's inputs and outputs are related. > If you have nothing new to add, we’re done here. I think we are done. I'll let the excellent answers from Ben Bacarisse and Stefan Ram serve as the final points I would have liked to have made. The rest of our discussion seems to have devolved into *ad hominem* and typical USENET flames. I apologize for allowing that to happen. I don't normally. I believe there are only two others with whom I've exchanged nasty flames on comp.lang.javascript, and with them the provocation was much longer-lived, and I believe my response was much more justified. I should have simply ignored the personal stuff and stuck to the technical arguments. I'm sorry. -- Scott
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2016-09-13 08:51 +0100 |
| Message-ID | <130920160851457407%timstreater@greenbee.net> |
| In reply to | #31350 |
In article <nr7h4k$lnc$1@dont-email.me>, Scott Sauyet <scott@sauyet.com> wrote: >Doc O'Leary wrote: > >> I grow tired of these patently absurd straw man arguments. > >Likewise. We're clearly talking past each other here. You haven't >managed to convince me that there is anything at all wrong with returning >-Infinity for `Math.max()` or that my interview question is flawed. And >I certainly haven't been able to convince you of the benefits of >enforcing simple laws about how a function's inputs and outputs are >related. I didn't see the start of this thread, but if any interviewer thought it relevant to ask, in an interview, whether Math.max() should return -infinity or not then I would just get up and walk out. Such questions are trivially unimportant. -- HAL 9000: Dave. Put down those Windows disks. Dave. DAVE!
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.eu> |
|---|---|
| Date | 2016-09-13 12:33 +0000 |
| Message-ID | <slrnntfshn.pn1.jon+usenet@sable.unequivocal.eu> |
| In reply to | #31351 |
On 2016-09-13, Tim Streater <timstreater@greenbee.net> wrote: > I didn't see the start of this thread, but if any interviewer thought > it relevant to ask, in an interview, whether Math.max() should return > -infinity or not then I would just get up and walk out. > > Such questions are trivially unimportant. If I was the interviewer I would be pleased to see you leave. I agree that if the question was what *does* it return, and that not knowing was a mark against the interviewee, then the interviewer is an idiot. However if the purpose of the question was to see what the interviewee says when they don't know the answer, or indeed the question was what *should* it return and the purpose was to see how the interviewee thinks and argues, then it seems a perfectly sensible question to me. (Much better than "what is your main weakness" or "how would your friends describe you" anyway! ;-) )
[toc] | [prev] | [next] | [standalone]
| From | Scott Sauyet <scott@sauyet.com> |
|---|---|
| Date | 2016-09-14 01:17 +0000 |
| Message-ID | <nra8g7$n5r$1@dont-email.me> |
| In reply to | #31351 |
Tim Streater wrote: > I didn't see the start of this thread, but if any interviewer thought it > relevant to ask, in an interview, whether Math.max() should return > -infinity or not then I would just get up and walk out. > > Such questions are trivially unimportant. Well, that would tell me as an interviewer quite a bit about you! :-) But that was not the context at all. I didn't start this thread, which was asking about interviewing questions and techniques. But in response to mention of a site with some fairly horrid "What does this code do?" trick questions, I reacted to the nature of those question and then included this: | When interviewing developers, I will ask questions designed to test | the depth of their knowledge, I will ask them to describe projects | and techniques, and I will have them write out some simple code. I | have two favorite bits. First, I present a really, really horrible | bit of code and ask them to note some of the things they see wrong | with it; those who skip over the more obvious and numerous surface | flaws and go directly to the poor choice of fundamental algorithm | get my attention quickly. And second, the only thing I have at all | related to trick questions is presented precisely as such. I only | use this one with candidates who have already demonstrated that | they're fairly advanced. I present this question and then help them | figure their way through it, to determine how well they can reason | about this fairly simple, but surprising result just through | discussion: "It's a somewhat surprising fact that in Javascript, | Math.min() > Math.max(). Can you think of why this might be so?" | | Other than that, I make sure I avoid trick questions, and that's | really not what this one is. I've never had someone answer it | without guidance, but some people take only a nudge or two, and for | others I have to spell it out entirely. This is not a deciding | factor, but does help me form an overall impression of a candidate. | | - <nmp72g$4pc$1@dont-email.me> Subsequent discussion has focused on two points related to this latter question: - Is the behavior of `Math.max` / `Math.min` reasonable? - Is this a reasonable interview question? I think we've beat the first point to death. I would be curious to hear your thoughts on the second one, though. -- Scott
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2016-09-14 11:15 +0100 |
| Message-ID | <140920161115372321%timstreater@greenbee.net> |
| In reply to | #31367 |
In article <nra8g7$n5r$1@dont-email.me>, Scott Sauyet <scott@sauyet.com> wrote: >Tim Streater wrote: > >> I didn't see the start of this thread, but if any interviewer thought it >> relevant to ask, in an interview, whether Math.max() should return >> -infinity or not then I would just get up and walk out. >> >> Such questions are trivially unimportant. > >Well, that would tell me as an interviewer quite a bit about you! :-) [snip] >Subsequent discussion has focused on two points related to this latter >question: > > - Is the behavior of `Math.max` / `Math.min` reasonable? No. > - Is this a reasonable interview question? No. Somehow I'm reminded of something that happened during my CS postgrad year in 1968. I can't remember in what exactly, but it may have been CACM or perhaps some British CS publication, a puzzle was posed for readers to solve, the implication being that some software was required and readers should submit programs to find the answer. And over the subsequent weeks responses came in. The one that struck me most, however, was from IIRC a CS prof at Southampton University, who was able to show by analysis and logical thought that the answer could be derived using no software at all. An application I have written with probably 20k lines of javascript appears to make no use at all of Math.max()/min(). So I'd probably disclaim anything other that a mild interest in your second question. I don't do crossword puzzles or Sod-yokos either. -- New Socialism consists essentially in being seen to have your heart in the right place whilst your head is in the clouds and your hand is in someone else's pocket.
[toc] | [prev] | [next] | [standalone]
| From | Doc O'Leary <droleary@2015usenet1.subsume.com> |
|---|---|
| Date | 2016-09-15 15:02 +0000 |
| Message-ID | <nred5d$ikp$1@dont-email.me> |
| In reply to | #31367 |
For your reference, records indicate that Scott Sauyet <scott@sauyet.com> wrote: > - Is this a reasonable interview question? I aim to work for companies that have interesting projects they’re working on. To that end, I expect them to be focussed on discussing those problems, and that the interview process would be structured to find people who are fit to the task at hand. So if they decide to waste time with silly trick questions (whatever the technology), it is a strong indication to me that they are not a well run organization. I won’t walk out of the interview, though. I’d indulge them for a bit. I might take them down the path I’ve taken here and further show how inane it is to raise problems without seeking solutions. For that desire on my part to actually *do work*, I might come off as not being a “team player” to a really incompetent interviewer. If they were to still offer me a job, I might decline, or possibly set a salary so high (because I’m clearly going to be carrying their team) that they’re unlikely to hire me. So, yes, it’s a reasonable interview question if you’re looking to filtering out any candidates that actually know what they’re doing. -- "Also . . . I can kill you with my brain." River Tam, Trash, Firefly
[toc] | [prev] | [next] | [standalone]
| From | John Harris <niam@jghnorth.org.uk.invalid> |
|---|---|
| Date | 2016-09-13 10:06 +0100 |
| Message-ID | <i9gftb92hkmcr1ov0skt9acl9binfvnlni@4ax.com> |
| In reply to | #31342 |
On 12 Sep 2016 21:21:20 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:
<snip>
> You remind me of one fact that I would like to add to the
> thread:
>
> In (standard) mathematics, there are no "functions with 0 arguments".
> Therefore, in the strict sense, mathematics does not treat
> the question of how to define a "function with 0 arguments".
This is not entirely true. In some maths textbooks (e.g Enderton) a
nullary function can be used to represent a constant. Thus
zero()
can be defined to return 0. In an ECMAScript function it can do this
even if more than 0 arguments are given.
> However, in mathematics, there are two other objects that
> get near:
>
> First, one can define functions that take sets as
> arguments and then ask for the value of a function
> for the empty set as an argument.
<snip>
The case of f( {} ) is different. f is a unary function. It's author
will decide if f is defined for this argument or not.
Unfortunately ECMAScript's variadic function capability makes it
difficult to distinguish between the two cases.
John
[toc] | [prev] | [next] | [standalone]
| From | John Harris <niam@jghnorth.org.uk.invalid> |
|---|---|
| Date | 2016-09-06 19:53 +0100 |
| Message-ID | <nv3usbp4feklq028t1t556daafihk3g47p@4ax.com> |
| In reply to | #31245 |
On Mon, 5 Sep 2016 20:37:35 -0000 (UTC), Scott Sauyet <scott@sauyet.com> wrote: <snip> >I disagree. The realistic choices are > > (A) Return something of the correct type, even though it's not > in the (empty) input list. > > (B) Return some semaphore of a different type that signals that > things have gone wrong: `undefined` or `null` are most likely. > > (C) Throw an error. > >None of these choices is ideal, but we have to choose between them. I'd >say that the best ordering is A > C > B. <snip> There's something else that has to be known before you can choose. Is this max function going to be put into a library you hope to sell to many software shops? Or is this function going to be used in one of your projects and needs to be optimum for this environment? In the first case you know that there will be incompetent loud-mouthed programmers who will scream if max ever hints that there was a programming error. max must return a Number so the error will not cause trouble until it becomes someone else's code bug. If not, your library will be vilified in all the social media and you'll lose sales. In the second case, any objector gets reprogrammed (not in the computer sense). John
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.javascript
csiph-web