Ethan

It sounds like you already know how to do embedded programming, at least at the hobby level. For someone who’s new to that, Arduino IDE is the easiest learning curve I know of. As far as which boards to use, I have no specific feelings which is why I said Arduino or equivalent.

You need to understand how code actually works. If you’ve only worked with highly abstracted languages like Python, Ruby, JavaScript, etc then you should probably start by learning lower level languages like C or C++. Or maybe Rust and Go but they’re kind of low level and abstracted at the same time. If you already know C/C++ then buy yourself an Arduino (or equivalent) and start screwing around. If you’re in school and interested in this as a career, take some electrical engineering or digital circuit design classes.

There was this one time where I took down the accounting department by accidentally DDOSing the SQL server. MS Dynamics is such a piece of garbage that it will crash if the database takes more than a minute to respond.

There’s no difference between SSA and ASS in that context so it’s pointless to punish a student for that

I’m not saying it doesn’t happen. This thread started because I said I’ve never understood why people talk like tar is some indecipherable black magic. Common tasks are easy and there’s a man page for everything else.

Literally the only time I’ve ever run into that is when I was trying to manipulate the path it extracted to. In 99% of cases I’m doing tf, xf, or cf plus flags for the compression type, etc, and those differences are irrelevant.

I almost never create a tarball, so I have to look up the syntax for that. Which is as simple as man tar. But as far as extracting it almost couldn’t be easier, tar xf <tarball> and call it a day. Or if you want to list the contents without extracting, tar tf <tarball>. Unless you’re using an ancient version of tar, it will detect and handle whatever compression format you’re using without you having to remember if you need z or J or whatever.

I’ve never understood why people are so intimidated by tar

I’ve had success with Claude, but there’s always a layer of separation. I ask it to do something, read what it produced, and decide if it’s garbage or not. And rewrite or discard as necessary. Though counting by LOC mainly I’ve used it for writing tests.

I didn’t say never copy and paste. I’m saying when you push a commit you should understand what all the LOC in that commit do (not counting vendored dependencies). If you don’t understand how something works, like crypto (not sure what Hamilton or Euler refers to in this context), ideally you would use a library. If you can’t, you should still understand the code sufficiently well to be able to explain how it implements the underlying algorithm. For example if you’re writing a CRC function you should be able to explain how your function implements the CRC operations, even if you don’t have a clue why those operations work.

I said you need to understand what the code you wrote (as in, LOC that git blame will blame on you) does. Not that you need to fully understand what the code it calls does. It should be pretty obvious from context that I’m referring to copy-pasting code from stack overflow or an LLM or whatever without knowing what it does.

If you are submitting work, you should understand how the code you’re submitting works. Sure, you don’t have to know exactly how the code it calls works, but if you’re submitting code and there’s a block of code and you have no clue how that block works, that’s a problem.

There’s a huge difference between copy-pasting code you don’t understand and using a library with the assumption that the library does what it says on the tin. At the very least there’s a clear boundary between your code and not-your-code.

Are you seriously trying to equate “I don’t know which instructions this code is using” to “I copied code I don’t understand”? Are you seriously trying to say that someone who doesn’t know how to write x = a + b in assembly doesn’t understand that code?

If you’re adding code you don’t understand to a production system you should be fired

Edit: I assumed it was obvious from context that I’m referring to copy-pasting code from stack overflow or an LLM or whatever without knowing what it does but apparently that needs to be said explicitly.

I guess I just don’t see enough memes to have picked up on that

I’m not sure what to tell you. I just don’t see what you do. And I never bother to look at a meme close enough to notice the kind of details the other user pointed out.

How can you tell?

nasm is an assembler though, not a ‘languages’

That’s like saying “clang is a compiler though, not a language”. It’s correct but completely beside the point. Unless you’re writing a compiler, “cross platform assembler” is kind of an insane thing to ask for. If want to learn low level programming, pick a platform. If you are trying to write a cross-platform program in assembly, WHY!? Unless you’re writing a compiler. But even then, in this day and age using a cross-platform assembler is still kind of an insane way to approach that problem; take a lesson from decades of progress and do what LLVM did: use an intermediate representation.

I’ve genuinely never had a problem with it. If something is wrong, it was always going to be wrong.

Have you worked on a production code base with more than a few thousands of lines of code? A bug is always going to be a bug, but 99% of the time it’s far harder to answer “how is this bug triggered” than it is to actually fix the bug. How the bug is triggered is extremely important.

Why is it preferable to have to write a bunch of bolierplate than just deal with the stacktrace when you do encounter a type error?

If you don’t validate types you can easily run into a situation where you write a value to a variable with the wrong type, and then some later event retrieves that value and tries to act on it and throws an exception. Now you have a stack trace for the event handler, but the actual bug is in the code that set the variable and thus is not in your stack trace. Maybe the stack trace is enough that you can figure out which variable caused the problem, and maybe it’s obvious where that variable was set, but that can become very difficult very fast in a moderately complex application. Obviously you should write tests, but tests will never catch every weird thing a program might do especially when a human is involved. When you’re working on a moderately large and complex project that needs to have any degree of reliability, catching errors as early as possible is always better.