I perform a lot of work that would fall under the DevOps umbrella. And I don't do it because I'm told to, or it's expected of me. I do it because I know the admin's that have been hired are "point and click" bozo's who cannot manage a simple shell script. They can barely keep AD permissions straight.
As a developer, sure I'm not the guy you want performing core admin duties - I know that. But I know I'm far more competent at DevOps than a crappy admin. Seriously, why would I trust my entire CI infrastructure to someone who cannot code, or has never done any serious engineering (software or otherwise)? It would be like trusting a developer who has never setup a mail server before, to maintain a datacenter.
It comes down to hiring skilled admin's who can work with developers. And both camps need to trust that each can do their job.
So please tell me how your going to fit any other language on a microcontroller with 1MB of flash memory. Nah, I'll be nice, how about 2MB of flash memory. Dont forget the roughly 512KB of RAM your going to have. And those specs are just guessing at what most industry will be using in 5-10 years. Most of us are still on ~256KB ROM.
You have no CPU cache either. No OOE. Memory alignment limitations (on some architectures). Most default C runtimes dont even support malloc/free. If you have C++ then your probably not using exceptions either.
How are you going to cram a JVM onto a microcontroller? We'll see Go before the JVM or Ruby or Python or whatever else. And even then Go is going to be stripped down as well.
Programming for phones and tablets is not embedded programming. Sorry, it's just not. I'll concede the point that C is dead for embedded, when I can buy a $1.50 PIC that can run a JVM.
I was the AC, you were responding to (decided I should make an account).
I agree, recursion in real embedded systems is a red flag. If you have a 512B stack, recursion is certainly not the best idea! Personally, I deal with dynamic allocation on a case by case basis.
I just can't stand this idea that "pointers" are dangerous, optimization is bad, and error checking is a pointless because the "hardware always does what its told". I feel that you can build a solid case for no recursion. But most other things, I don't think inherently decreases system reliability.
Slashdot Mirror
Agreed.
I perform a lot of work that would fall under the DevOps umbrella. And I don't do it because I'm told to, or it's expected of me. I do it because I know the admin's that have been hired are "point and click" bozo's who cannot manage a simple shell script. They can barely keep AD permissions straight.
As a developer, sure I'm not the guy you want performing core admin duties - I know that. But I know I'm far more competent at DevOps than a crappy admin. Seriously, why would I trust my entire CI infrastructure to someone who cannot code, or has never done any serious engineering (software or otherwise)? It would be like trusting a developer who has never setup a mail server before, to maintain a datacenter.
It comes down to hiring skilled admin's who can work with developers. And both camps need to trust that each can do their job.
Uh, what?
So please tell me how your going to fit any other language on a microcontroller with 1MB of flash memory. Nah, I'll be nice, how about 2MB of flash memory. Dont forget the roughly 512KB of RAM your going to have. And those specs are just guessing at what most industry will be using in 5-10 years. Most of us are still on ~256KB ROM.
You have no CPU cache either. No OOE. Memory alignment limitations (on some architectures). Most default C runtimes dont even support malloc/free. If you have C++ then your probably not using exceptions either.
How are you going to cram a JVM onto a microcontroller? We'll see Go before the JVM or Ruby or Python or whatever else. And even then Go is going to be stripped down as well.
Programming for phones and tablets is not embedded programming. Sorry, it's just not. I'll concede the point that C is dead for embedded, when I can buy a $1.50 PIC that can run a JVM.
I was the AC, you were responding to (decided I should make an account).
I agree, recursion in real embedded systems is a red flag. If you have a 512B stack, recursion is certainly not the best idea! Personally, I deal with dynamic allocation on a case by case basis.
I just can't stand this idea that "pointers" are dangerous, optimization is bad, and error checking is a pointless because the "hardware always does what its told". I feel that you can build a solid case for no recursion. But most other things, I don't think inherently decreases system reliability.
Forgive my ignorance, but given C's linking and visibility spec ... what platform/toolchain will create static variables on the stack?