I have heard that "O'Reilly: Mastering Bitcoin" is good, but never read it and it's 2014 which is probably both good and bad - no Ethereum or other notable coins by then, but also none of the recent bitcoin nonsense.

You could learn a lot reading the satoshi bitcoin white paper and his other postings, ethereum white paper etc. (almost books, you could print them out anyhow )

Probably anything in book form will already be hilariously out of date?

The basic details of proof-of-work and the idea of a distributed ledger probably hasn't really changed much.

This paper says that it's not intended for a technical audience, but it appears to be a decent overview anyway? It was probably put together for the congressional committee meeting today(?):

https://csrc.nist.gov/CSRC/media/Pub...8202-draft.pdf

Yeah, it's more to just get enough background in it that I don't sound too stupid. Outside chance I could end up working at a start up a friend of mine is a CTO at as something. Maybe a scrum master, maybe a tester, maybe all of the above and be the guy who buffers the developers from customers.

Perfect, thanks!

i think i passed my phone interview, he's sending me a homework assignment this week.

big question was: "What are the advantages and disadvantages of a linked list vs dynamic array"

hit it out of the park, i didnt even research beforehand. he asked what the size of a pointer was in C++ and I didn't know, but I got everything else right.

he asked what I liked about C++ vs. java and I told him I like how you can overload operators and make your classes much more flexible, and can manage your own garbage collection. The downside of this is having to manage your own garbage collection. He laughed at that. I also said something how I liked having the option to pass by value or pass by reference into a function.

This strikes me as a trick question, or possibly an example of a question where the asker thinks he knows the answer, but is incorrect. I have heard lots of people give incorrect answers to this question.

Maybe it's just me being pedantic, because in a modern sense there's not that much variation any more, but there definitely used to be, and there's no *particular* reason to think you know what the size will be on an unknown compiler or processor architecture without looking.

A better question might have been "how can you find out?" or "why does it matter?"

I explained that my answer was 32 bit because every target processor I’ve ever programmed for was 32 bit addressed

the correct answer is probably "compiler dependent" but in the moment I just kinda blanked.

the other Q he asked was how large an integer was in C++, that's easy but I think that can vary too. I know it can in C.

1. Woefully out of date, no one ever looks at it.
2. Probably out of date. Maybe someone looks at it.
3. Never out of date. End state for 99.99% of systems.

Yeah that's kind of a dumb question for that reason, and actually something I don't like about the language. I think int has been 32 bits on everything I've ever programmed for but the fact that the language makes no guarantees just makes it a PITA. The introduction of types like int16_t/uint32_t makes life much better and I've used those in any instance where I've given a crap.

(related: anytime a char isn't 8 bits = **** off, which iirc was actually the case when I did console programming, I think maybe we had a separate byte type to compensate)

Probably something like "man, it's going to be a pain deleting all this".

you cant pass by reference in Java? that seems weird. you can in C#.

All objects are passed by reference in Java. You can't pass by value unless you make a copy first. Same as JS.

Edit: well I guess there's some confusion on what's meant by "reference". Ugh.

I read this blog post and it confused the **** out of me: https://www.javaworld.com/article/20...-by-value.html

But then this comment is more in line with what I remember:
https://stackoverflow.com/questions/...-pass-by-value

For all intents and purposes if you pass an object into a method in Java - you have a pointer or reference or whatever you want to call it to the original object. You do not have a copy you can just play around with and do whatever you want. You will change the original object.

This is all you really need to know:

it passes everything by value. in the case of objects, it'll pass the object's reference by value, so pretty much has the same effect as passing by reference.

but if you pass 2 ints into a function and try to change their values, when you return, the original variables you passed into the function will still be the same as when they entered. it's silly and confusing to me.

Yeah same as JS. Primitives get passed as a copy, objects get automatically passed as a reference (or value of a reference or pointer or whatever the hell you want to call it).

Personally doing a bit of C++ work before becoming a Java dev I found it a lot easier not to have to worry about pass by reference or pass by value. The rare times I need to do one or the other I can always add a line of code to work around it.

In JS having the ability to choose would be a disaster imo.

That would be a really good interview question

I would have blown it apparently.

We had this convo about JS recently and candybar came in and set it straight.

The distinction of "value of a reference" matters imo, because you need to know that if you try to reassign an object passed into the function, it won't do anything, but MODIFYING it will.

This was a common interview question in my early days, and I asked it my share of times.

But its actually pretty bad because there's a lot of semantic arguing about what exactly is happening. And the important thing is to just know that primitives are distinct copies and objects are the same object. Whether you want to say everything is passed by value, but its the object's reference that is passed VS saying primitives are passed by value and objects are passed by reference - doesn't seem to matter much in the real world.

I get confused about it all the time when switching from C++ to java and have to frequently look it up.

I think it’s more java has a strange way of defining “references”

Right. I've just been doing it for so long with Java and then JS - that *re-assigning a parameter doesn't affect the passed in object* seems obvious to me.

Also re-assigning a passed in parameter, whether it's an object or primitive, is code smell imo. Guaranteed to result in confusing code.

Yeah, as someone who has spent many years programming in C#, I could probably count on one hand the number of times I have used the ref keyword. It's usually a bad idea.

The related "out" keyword (which is a reference pass, but unidirectionally out of the function - an additional return value, basically) is actually encountered pretty frequently, because the framework has these built in for basic types:

This takes a string, attempts to parse it into an int, and returns a bool indicating success or failure, while the int result (if any) is returned as an out parameter. I've always found this formulation kind of awkward, I don't know why it doesn't just return a Nullable<int>. Maybe TryParse predates nullable basic types, I don't remember.

Types - reminding me why I never want to go back to Java. Or use typescript - which I'm convinced is primarily useful as a security blanket for recently-converted java devs.

Things like this are what I really enjoy about Rust's (and other languages too I'm sure) Option and Result types.