Although in that case bullet dodged.
interviewer in 1999: we are looking for someone with 10 years of java experience.
james: I invented java 5 years ago.
I once was interviewing for an interesting job and the topic was general knowledge of a system made of A, B and C (all were similar). The interviewer did not know much but insisted on some very deep details about B. I told him more than was available in the docs already and at some point I said I would need to peek in the code to say more.
He told that this was too difficult for me because only people who were part of the team who designed that would understand.
I told him that I wrote almost by myself the A part so it won't be too difficult to catch up with B.
I did not get the job (ultimately a happy ending) and was told that I did not know enough on A (the part I wrote).
Easier to just say pass by value and forget about it. OR make all your variables consts and then it don't matter.
Where it matters is in passing arguments to a function call. If you pass 42, it’s not mutable so incrementing, or doing anything, will not modify the original variable you passed-in. For a reference, using = will assign a new value (not change the original) but modifying the referenced object like, say a.b = 5 WILL change the original object.
It’s not really “pass by reference” that a C/C++ developer would understand but it seems to be the term that has stuck.
>For a reference, using = will assign a new value (not change the original)
what I wrote was regarding only strings, so I'm not understanding - it seems you are saying the same thing I said? But maybe I'm wrong about how the actual strings are stored.
Every popular language which allows pass-by-reference makes those places very explicit (like ref in c++ and c#)
yes, technically I know this but even so he was technically not right because he still said there was pass by reference and pass by value in JavaScript, it's just that the description he had of what happens in pass by value is what is normally described as "pass by reference" and the description he had of what happens in pass by reference is what is normally described as "pass by value".
I think we can agree that given that he used both terms and mixed up their meanings that he was not "technically right"
on edit: meaning if he had said "we pass everything by value in JS but some values are references, what happens then?" he would be right, but when he said we pass objects by value and primitives by reference - what do these two terms mean and then he accepted the description of what happens in an object when passing the reference as being correct but insisted that was called pass by value, and he accepted that the description of what happened with a variable when it has a string assigned and then that variable is assigned to another variable and then the first variable is changed was correct including the ability to change the value of variable A and not have the value of variable B changed thereby but insisted that this process is called pass by reference, I intuited through this conversation that he was unfortunately not "technically correct"
It's been awhile since I've looked at NSA on graphs, but it's an interesting field of study. For something of a taste, an alternative proof of Kőnig's lemma might look like:
- Start with a locally finite, connected, infinite graph G.
- Choose any nonstandard extension G* of G.
- By the transfer principle (basically just logical compactness), there exist hyperpaths [0] of unbounded (hypernatural) length in G*. Pick one, P*.
- Restricting P* to G you obtain some path P, which is the infinite path you're looking for.
I settled into industry instead, but that's the sort of thing I'd like to study if I ever go back for a PhD, hence the interest in those sorts of ideas applying to spectral theory.
[0] The "transfer" of a path isn't actually necessarily a connected path in the usual sense, but it's indexed by the hypernaturals, and each well-ordered countable segment is connected. I'm skipping the entire intro that makes those operations make sense.
The most basic style of proof in a lot of nonstandard analysis is (1) lift your problem to a nonstandard space, (2) prove something interesting in that space, (3) hopefully project something interesting back down to the problem you actually care about.
E.g., in nonstandard real analysis you can look at a real-valued function like f(x) = x^2, pick any epsilon z, and compute the hyperreal analogue (f(x+z)-f(x))/z = 2x + z. This is within some infinitesimal of 2x, so you use some machinery you've built up to conclude the derivative of the real-valued function is 2x.
The graph lemma above had a similar flow. Create G*, find something interesting, project it back down to G, finish the proof.
That's certainly not the only proof style. Nonstandard topology combines basically all the normal compaction theorems into one, for example, and that's a bit more intricate.
Even such crude techniques can bear fruit quickly though. Menger's theorem was proven in the early 1900s, and only extended to infinite graphs in the late 1900s. That 3-step proof process with nonstandard graphs makes it a bog-standard freshman exercise for locally finite infinite graphs, and only a bit more involved for the full generality originally proven by Erdos and friends.
I don't have any deep insights beyond that. The Springer GTM series has a nice intro to nonstandard analysis (not actually graduate-level IMO, a mid/advanced undergrad could use it, which is a nice level for that sort of book), building it up in a way that you could probably work with nonstandard extensions of other infinite structures (like graphs) without needing many/any other resources, especially if you've done much with building models of other theories via set structures.
Indeed, and this is the step that standard mathematicians tend to balk at.