mikebenfield

> What? If you have instantiatable abstract data types with associated methods you have a "class". Calling them "structs" does not change that. There are classes defined with "struct" in C++ and D too.

So if I just take C's structs and add the ability to associate structs with functions using a "struct.function" notation, I now have classes? If so, a class isn't a very powerful concept, is it?

Here's an easy way to see the difference between traits and interfaces, and simultaneously see why some people find OOP completely inadequate for their purposes.

Imagine you're implementing several different types that all need to be able to be added. You've got integers, floats, mathematical vectors, and possibly other types. All of them should support an `add` method. But you should only be able add objects of the same type: an integer to an integer, a float to a float, and a vector to a vector. This incredibly simple idea, to my mind almost the simplest thing a person might want to do with a type system, cannot be expressed in most OOP languages using an interface with an `add` method.

But it can easily be expressed using traits (or using Haskell's type classes).

And this is why I never understood why anyone bothers with OOP.

It may be easier to see their significance when they're associated with a trait, rather than a struct.

For a simple example, imagine I've got a trait Number, and every implementation of Number is supposed to have a zero constant. Then I could let that constant be Number::ZERO, and refer to it as such in generic code, with each implementation of Number having a different value for Number::ZERO.

This isn't quite the same thing, but FWIW, during Renaissance times, scholars would rediscover ancient Greek works and legitimately learn "new" mathematics from them. See for instance Diophantus's Arithmetica, which was translated from Greek to Latin and thus rediscovered by the west.

I would love to have reliable and efficient mass transit. However, for most places in the USA, that seems to be politically and socially impossible. For whatever reason, Americans have almost completely rejected public transit.

For that reason, I'm more excited about self driving cars than about public transit.

Here's my informal and possibly screwy understanding of why translating to microcode doesn't really slow things down: When you've got a bunch of tasks to do, breaking the task-execution process into a pipeline of steps may potentially increase the latency (how long does it take to do a single task), because, well, you've now got to go through several steps do do that task. But (assuming your pipeline is designed well), it will also increase the throughput (how many tasks can you do in a fixed amount of time).

In software, it's likely that latency is not going to be a problem as long as you can get more throughput (you probably don't care if the time between when the program hits your opcode and the CPU actually executes your instruction is 1 nanosecond later than it conceivably could be as long as the number of instructions executed per millisecond is greater).

In any case, yes, you need to expose the same machine code interface, not just so people can write new software using the same code, but so that old code continues to work. It would be a nightmare if every few years there were incompatible changes to the instruction set.

> We're all busy.

Sure, but if the core of your job, the key skill you bring to the table, is writing software, you are (hopefully) going to find the time to learn best practices for writing software.

If that's not the core of your job, if your key skill is something else and writing software is just an occasional means to an end... maybe the incentives aren't there.

> How long do you think it takes for time spent learning good software development practices to pay for itself?

If you almost never write a program longer than 1000 lines and rarely use a program six months after you've written it, it may never pay for itself.

Don't get me wrong, I personally have an interest in good software development practices. I just understand why not everyone can or will take the time to learn them.

I have the same instinct, but I think in a few years we'd be in the same position, where what we write doesn't directly correspond to the architecture of the CPU. The CPU people are always going to work to make existing code faster, and since it's impossible for many generations of CPUs to "be just like the last generation, only faster", that's inevitably going to involve some kind of translation layer between your code and the CPU's "real architecture."

> You'd think people smart enough to pursue stem phds would understand basic programming abstractions, but that is often not the case.

Another way of looking at it: People doing STEM PhDs are extremely busy. They have to master the content in their field, keep up with new research, conduct their own research, write papers, go to conferences, give talks, teach, keep up with whatever department service responsibilities they have, etc.

They're smart people so they're going to be able to slap together some code that does what they need it to do. But to expect them to learn git and how to use it well, to learn about managing dependencies, about unit tests, about build systems, about best practices for documenting code, about programming abstractions or OOP whatever else... that's a lot to ask.

(And I say this as a STEM PhD who did learn all that stuff, more or less.)

> If you want to save cycles and bytes then use assembly language ... High level languages won.

This is a ridiculous straw man. It is completely possible to write efficient software in high level languages, and no one is suggesting people extensively use assembly language. Actually, in many cases it is very difficult to write assembly that beats what's generated by an optimizing compiler anyway.

You don't seem to understand the difference between a proposition and its converse.

"If a person wants to get married, s/he wants to share his/her life with someone" is (more or less) true, and is the premise everyone is working under.

The converse of that proposition is "If a person wants to share his/her life with someone, s/he wants to get married." That is what you for some reason appear to believe is the premise we are working under. But it's not.

Does this really have to be explained?

Persumably you want to get married because you want to share your life with somebody else. If you don't start sharing until you're 40, you've already missed the opportunity to share what are almost certainly the most transformative and significant years of your life. Of course this doesn't mean a later marriage can't be happy and successful too... but it does involve missing out on things that some people care a lot about.

1. I have always hated the notion that having a happy marriage is about filtering through many candidates to find the one perfect partner. Although I do think it's reasonable to try to learn early on what you're looking for, this idea that we should all be dramatically expanding our dating pool to find the perfect person is abominable.

Look at a city with a massive population of eligible young people, like say NYC.. and then listen to what people in NYC say about the dating scene there. It's not pretty. Having such a huge pool of potential mates discourages people from committing. In other words, it makes it harder to find a long term mate, and it makes you less satisfied with whoever you're seeing.

2. Biology isn't the only reason a person might want to get married before 40. There's something to be said for sharing your early adulthood with a person. Meeting your life partner at 37 will be a very different experience from meeting your life partner at 22. Not necessarily a bad experience, but not what everyone is looking for.

This doesn't make any sense to me, at least coming from mathematics.

If I'm writing writing a paper about my ideas, it would be unethical to "make my friend a co-author" if my friend didn't contribute to those ideas.

Yes, it would be strongly preferable to tell readers where they can find the info you are citing. But if that info is unpublished, then that's life.

You're designing a CPU, and you develop a method for how the CPU will decode and execute instructions. You come up with opcodes for all the instructions you want the CPU to use. As a side effect of your decode/execute method, some of the opcodes you didn't specify do other stuff. Maybe they do the same thing as some of the instructions you planned, or maybe they do weird things that seem meaningless and useless.

Either way, those extra opcodes weren't part of your design, and you don't want people using them. Because maybe a future design of your CPU will use those opcodes for something you actually planned, or maybe you'll figure out a more efficient way to decode and execute opcodes which, as a side effect, will change the way those unplanned opcodes work. So you either just don't document those extra opcodes, or you declare them illegal.

Another thing that can happen is that your CPU is buggy, and some of the opcodes don't do what you planned. The Z80 had undocumented (but commonly used) "shift logical left" instructions. These instructions set bit 0 of the operand to 1, which is strange. It's speculated that these were planned to be ordinary shift operations, but the bit 0 to 1 thing was a bug, and so Zilog just decided to leave those instructions undocumented.

> They added Python 3 features to Python 2 over the years to encourage adoption of Python 3 as the standard. It worked.

Did it really? My impression was the opposite: the fact that so much of Python 3 became available in Python 2 made people feel like there was no point in moving to Python 3.

But these examples aren't what is being referred to as "totally self taught." Your grandparent comment acknowledges, "I have no doubt you can replicate the undergrad education through self-study..." (Of course that is pretty rare too, but what's in doubt is people who did the equivalent of grad school on their own).

FWIW, in mathematics I know there's Blake Temple, who IIRC did his undergrad in philosophy but was somehow admitted to a strong math grad program and went on to a very successful career... but again this isn't "totally self taught" in the sense here.

Whether this is a good interview question I don't know, but:

> When the hell would you ever need to know that?

I find this such a strange perspective. You're writing code for a computer. Sometimes you need to estimate how quickly it should run, or else estimate how quickly it could run with optimal code. Surely it's obvious that knowing how fast your computer does stuff, at least within 3 orders of magnitude, is a necessary ingredient to make that estimate.

And yet in your mind that fundamental fact is "useless trivia." Very odd.

> Just being the most efficient coder possible is a pretty sad goal.

Well, I agree, but life is short. Why learn algebra rather than complex analysis or probability theory or functional analysis or differential geometry or mathematical logic or general relativity or quantum mechanics or any one of dozens of other topics from physics or mathematics that will almost surely seem more interesting and fun to a non-mathematician? (Not to mention non-mathematical topics...)

Abstract algebra is a massive field, the vast majority of which has little applicability to writing code, so it's hard to know what to recommend without knowing why you want to learn it.

If you're ready to get very serious with mathematics, I like Algebra by Mac Lane and Birkhoff. (Note that this is a different book from A Survey of Modern Algebra by the same authors, which I'm sure is okay, but... a different book.)

If you're not ready to get very serious with mathematics... well, then why do you want to learn algebra?

> I don't think I've ever seen someone describe a feature that vi/vim/emacs has that an IDE doesn't

Maybe this has changed in recent years, but in the past whenever I tried IDEs I would be amazed that they didn't have keyboard macros.

I think this idea is basically nonsense. Some things are complicated. To "explain" them in simple terms you necessarily leave out a lot of information. If all that information isn't crucial to the core idea, maybe that's worthwhile. But sometimes that information is crucial.

Some people look at advanced mathematics or physics and wonder why it has to be so complicated and so full of jargon. It's complicated because it is. The jargon, believe it or not, is mostly an attempt to make it easier to communicate. It would be very, very difficult to wade through these ideas without introducing new words with precise definitions.

Then again, John von Neumann said, "In mathematics you don't understand things. You just get used to them." So maybe the title is true for trivial reasons after all.

It varies by field. Try publishing in Math, CS, or Physics without using TeX.

Unfortunately I can't remember the details at this point. There was something I couldn't figure out with the `new` function and heap allocation in general, and I also got frustrated trying to understand some things about the type system. I do know one thing about `new` was that it took me forever to figure out how to allocate anything on the heap at all, only to find a couple lines about `new` in the API docs. At least, I think that's what happened.

Sorry I can't be more specific.

Well, at the time I would have thought it was required for the language to become widely used. But since that's clearly not true I suppose I have to downgrade that statement to say it's required for me to write code in the langauge and not feel like I'm constantly banging my head against a wall.

Frankly, yeah, I think Go programmers are kind of stuck in the 1980s in some respects. This isn't something I'm completely clear about, but I feel like Go's developers are biased against anything that smells at all academic. So for instance they didn't want to implement a super fancy, cutting-edge type system. Which is somewhat understandable... but as a result they ignored 30 years of programming langauge research and implemented a primitive type system that basically provides nothing over C. I do not understand this mentality.

I think Nim may be the most underdocumented project I've ever used. I spent a week or so with it, but quickly grew extremely frustrated as I was constantly scouring old forum posts to learn how to use the basic features of the language. That is not a tolerable situation for me.

Sounds like an aversion to me. By the time Go was developed, there was no doubt in my mind that generics (or some kind of polymorphism along those lines) were an essential feature for any new statically typed programming language. The fact that Go's developers "don't feel an urgency for them" to me makes it sound like they are living in the 1980s.

The Python project itself is dropping support for Python 2 by 2020. Lots of major libraries have pledged to stop supporting Python 2 by 2020 or even before.

Writing new code in Python 2 is completely nuts and just makes everyone's life harder (including your own).

I've only seen mathematicians use the terms morphisms, arrows, and domain/codomain. It is true that morphisms and arrows mean the same thing, but I think that's because the term morphism is specific to category theory and the term arrow is from graph theory.

All the other terms here (abstract functions, origin, destination, argument type, return type) appear to be the author's attempt to make the subject understandable to programmers.

> I cannot imagine what mechanism would drive, or what evidence would support, the average individual gamer preferring less complex games over time.

What mechanism? Maturity, expansion of interests and hobbies beyond video games, other responsibilities.

When I was a teenager, I was perfectly happy to spend many hours playing absurdly complex war strategy games and epic RPGs. Nowadays, if I'm actually going to play a video game, I better be able to pick it up and play and get some enjoyment out of it immediately without a lot of effort or thought. Dwarf Fortress looks neat and all, but I'd rather just play with my dog than spend any time on DF.

I wholeheartedly endorse the idea that people should learn more physics and math, but I'm not sure the author's personal story supports her apparent message.

She apparently went from 6th grade math to graduate quantum mechanics in a year and a half. This is highly atypical and is surely not an example of a "not smart" person overcoming and managing to learn some physics.