More concise and compact, easier to maintain, access to more powerful programming paradigms, flow control using exceptions for example. Another thing is you can hire cheaper programmers because you don't need gurus to write the code (C almost demands it).

 

More concise and compact, easier to maintain, access to more powerful programming paradigms, flow control using exceptions for example. Another thing is you can hire cheaper programmers because you don't need gurus to write the code (C almost demands it).

How can a script language possibly be "compact"???? There is an enormous amount of overhead to run that script. The C language is every bit as easy as JavaScript. Easier in some respect because the structure requires an exact syntax that can also be leveraged by editors and compilers to detect errors before the code is run. Then there is the spped issue. scripts need to be interpreted so they are slow. Making them almost useless in the embedded world.

Besides it is not the language that requires the skill. Anyone with an understanding of coding languages can learn C. It doesn't take a "guru". The hard part of embedded programming is knowing the chips being used. An extremely talented C programmer trying to work in the embedded area, is useless without a solid understanding of the embedded technology.

 

More concise and compact, easier to maintain, access to more powerful programming paradigms, flow control using exceptions for example. Another thing is you can hire cheaper programmers because you don't need gurus to write the code (C almost demands it).

OOP type Exceptions are one of main reasons for not using OOP in the deterministic hardware guy programming paradigms that most small controller are used. Exceptions -- they don't have predictable time of execution. There is nothing wrong with using 'goto' or one of its structured equivalents instead of having the heavy run-time requirement of some OOP elements to handle errors.

https://www.embedded.com/design/programming-languages-and-tools/4442577/C---exception-handling

 

Anyone with an understanding of coding languages can learn C. It doesn't take a "guru".

Gee, thanks Spin... just when I was beginning to feel good about myself... thinking of me as a guru and all... and now I'm back to being as ordinary as vanilla... ...

 

How can a script language possibly be "compact"???? There is an enormous amount of overhead to run that script. The C language is every bit as easy as JavaScript. Easier in some respect because the structure requires an exact syntax that can also be leveraged by editors and compilers to detect errors before the code is run. Then there is the spped issue. scripts need to be interpreted so they are slow. Making them almost useless in the embedded world.

You know maybe you're right. We've grown so accustomed to this idea that the advantages of scripting somehow justifies the (often extreme) detrimental impact on performance demonstrated by these technologies. But if you really think about it it's kind of like paying for syntactic sugar with gold.

What we really need is a language that simplifies the development cycle while at the same time providing roughly the same performance. The level of acceptability should be more or less proportional to the advances in hardware of a given system. Systems which never undergo an upgrade will simply have to use some heuristic speed metric (is it fast enough?) to decide whether or not the language would indeed be a wise choice for the application in question.

So now I'm just in the process of deciding if I'm really up for the challenge. Anyone else here crazy enough to get involved in such a project?

 

We've grown so accustomed to this idea that the advantages of scripting somehow justifies the (often extreme) detrimental impact on performance demonstrated by these technologies.

Is there someone else in the room with you?

 

Is there someone else in the room with you?

Yes just think of all the of the scripted web applications out there in the wild Joey. They far surpass the number of "native" applications under development. So yeah this is really something that has crept up on us over the past few years (sort of like a frog slowly boiled).

Maybe you embedded guys just have better sense about it because in your world speed/responsiveness is (almost) always an issue. Perhaps the rest of us need to take note and rethink our priorities...

 

Perhaps the rest of us need to take note and rethink our priorities...

You should. .asm makes for superiorly fast websites, SQL queries, and bash scripts.

 

You know maybe you're right. We've grown so accustomed to this idea that the advantages of scripting somehow justifies the (often extreme) detrimental impact on performance demonstrated by these technologies. But if you really think about it it's kind of like paying for syntactic sugar with gold.

What we really need is a language that simplifies the development cycle while at the same time providing roughly the same performance. The level of acceptability should be more or less proportional to the advances in hardware of a given system. Systems which never undergo an upgrade will simply have to use some heuristic speed metric (is it fast enough?) to decide whether or not the language would indeed be a wise choice for the application in question.

So now I'm just in the process of deciding if I'm really up for the challenge. Anyone else here crazy enough to get involved in such a project?

There already are languages that hope to provide that.
One example:
https://www.rust-lang.org/
https://doc.rust-lang.org/book/

 

You should. .asm makes for superiorly fast websites, SQL queries, and bash scripts.

I remember all the wars on ETO .asm vs. C what's funny is both to me are small differences in terms of size matters world. I remember back when learning Crestron Programming it's based on C small. But, then to make it more user friendly the company came up with bloatware program that was actually more difficult to learn. I like at @ericgibbs Signature.

"When close enough is perfect" or something like that, trying to build a better mouse trap why? Why of course, to catch mice.

Sorry, I don't see it. C is small "enough" .asm I have knowledge of, I take @joeyd999 word for it, since he convinced me Vodka is drinkable and isn't turpentine.

kv

 

...since he convinced me Vodka is drinkable and isn't turpentine.

Wasn't me. My martinis are gin.

 

Wasn't me. My martinis are gin.

Tried Gin for a while, but I'm allergic to Pine. I was having asthma attacks for no reason then someone told me what it's made of.

kv

 

You should. .asm makes for superiorly fast websites, SQL queries, and bash scripts.

Well right but that's not the answer either. Switch processors and now all the sudden you have to rewrite everything. I was thinking more along the lines of a language that could be (A) compiled directly to C/ASM for native applications and (B) compiled to a platform-neutral bytecode format to be run inside of a virtual machine.

 

There already are languages that hope to provide that.
One example:
https://www.rust-lang.org/
https://doc.rust-lang.org/book/

I am familiar with Rust and yes it is pretty cool but...it can't be made to be scripted AFAIK.

 

I am familiar with Rust and yes it is pretty cool but...it can't be made to be scripted AFAIK.

That is a good thing.

 

That is a good thing.

Well what about security? You can't just run everything with full access to the system. I know we can use things like Docker to mitigate the problem but that isn't really a practical overall approach. Plus the code really needs to meet the write-once-run-anywhere criteria (yet another reason why scripting languges have become so popular).

 

Well what about security? You can't just run everything with full access to the system. I know we can use things like Docker to mitigate the problem but that isn't really a practical overall approach. Plus the code really needs to meet the write-once-run-anywhere criteria (yet another reason why scripting languges have become so popular).

Security is enforced by hardware in any language. The write-once-run-anywhere criteria works only in the sandboxes of abstract machines that are not optimized for every computing task. In embedded software design's that's rarely the case even in similar processor families unless you include a lot of baggage to detect the exact model.

 

Security is enforced by hardware in any language. The write-once-run-anywhere criteria works only in the sandboxes of abstract machines that are not optimized for every computing task. In embedded software design's that's rarely the case even in similar processor families unless you include a lot of baggage to detect the exact model.

Right but hardware doesn't prevent things like files from being opened nor does it always protect all external segments of memory. Very problematic. So...if you could get all of the benefits of scripting while at the same time be given the option to compile directly to an uninterpreted format (like C, ASM, or machine code) then you'd have a truly useful programming language.

 

Right but hardware doesn't prevent things like files from being opened nor does it always protect all external segments of memory. Very problematic. So...if you could get all of the benefits of scripting while at the same time be given the option to compile directly to an uninterpreted format (like C, ASM, or machine code) then you'd have a truly useful programming language.

Software can only protect the elements that obey the rules of the sandbox. The sandbox security of the scripting language is protected by hardware access controls to resources like block devices and memory. Hardware can prevent things like files being opened and secure hardware with trusted MMU hardware can protect all external segments of memory. Your arguments are naive and reveal a lack of knowledge of basic systems programming.

 

Your arguments are naive and reveal a lack of knowledge of basic systems programming.

Just let me know when you're done with your pissing contest because I was actually trying to understand the objections that people have.