Yes it could be useful for embedded programming, although maybe it's not all ready yet, i haven't kept close attention on it's progress for a little while.

The standard library and a couple built-in features allocate memory using/relying on the garbage collector, but it's possible to avoid it or supply a different memory allocation removing those needs. Last i remember a portion of the Standard library was moving more functions away from the garbage collector.

But it really depends on what features are needed in an embedded system, and how much of the environment needs setting up before it's used. If it's number crunching and you don't need text processing or are appending/manipulating arrays and classes, avoiding the GC is fairly easy.

If you don't rely on the GC/STDLib/LTS, you could likely write structs and/or functions and call them from C/C++ avoiding the Standard library and runtime altogether (as they just have stack allocation during the call and cleanup afterwards). Though name mangling might be a pain, so limit the public/visible API.

Already present, as pointers and asm code can be injected directly. Worst case you can use a union to force a number into an address and use that. Sorta an ugly workaround.

Though there isn't the violate keyword, which i would think is the biggest worry on this front.

I'm late to the party, but I concur with everyone else. The second alternative doesn't need to be updated (programmatically), whereas the template (if I'm reading your question aright) might be adjusted over time. A reliable, pre-rendered program is not reliant on the correct construction of the template, which you have also noted is problematic in any case.

On a related note, one of the main drivers of all my coding as I matured was to make it readable (post factum). This I learnt through face-planting walls of text that I could not decipher even a few days after I wrote them (C being a particular stand-out example of this phenomenon). Try reading legacy code written by someone else, with the idea to improve it.

Best practice demands legibility (less time to interpret spaghetti code). If it takes more time to understand what the subroutine does than to update it, then the rate of change ought to leverage the clarity of documentation / nomenclature. By all means have fast, clean, small, tight routines for looped action; adding a few judicious variable and constant names can make a big difference. (Calling everything x might be quicker to write, but it's maddening to debug / read. :)

I get a job in one company, and so I was given the task (deadlines a week) to write a Python program for log parsing, the future employer is aware from my resume that I don’t know Python and in general is very weak in programming, but despite it still set a task for me. Who can I pay for programming assignment?

thanks, I'll try

What kind of programm do you need to create with Python?

i add my vote to 2

I like the SOA kind of approach where you have small, focused services that do their job. they can be independantly maintained and tested. if you need to fix one you can release the fixed version without having to redeploy everything (unless you're doing a major overhaul of the interface ofc, but then there are ways of dealing with interfaces and breaking changes and versioning - but this seems out of scope of what you're doing anyway)

do you even need something that computes a result and passes it back at which point you include and compile? can it not be interrgoated during runtime? the values can still be precomputed and held in a cache on the other service and updated when feasable (over weekends / at night when noone is working)?

EDIT: oh, i see the thread was necro'ed and a new subject has been injected... well.. i hope whatever it was you were doing turned out ok)

Yes, this thread was necroed, but I am still interested in this sort of discussion. (I note that I wasn't actually working on anything where this came up, but rather I was just curious what people thought would work best in this situation.)

I can think of a few reasons why computing the vales at run-time might not be viable:

1. The value needs to be used at a place where the language requires a constant, like the size of an array or as a template parameter. Computing the value at run-time won't work, as it won't be a constant and therefore the program will fail to compile. (Keep in mind that dynamic memory management isn't always a realistic option, like on microcontrollers with limited memory.)

2. The target device is not powerful enough to do the computations in a reasonable amount of time. For example, maybe the target device is a microcontroller, like the one in the Arduino Uno (which uses an AVR chip).

3. RAM is at a premium, and the result needs to be stored somewhere else, like in a microcontroller's ROM. For example, on the AVR, program and data have separate address spaces, and program memory can't be written to at run time (unless the program counter is below a certain value, and keep in mind that flash memory has a limited number of writes before it dies). Perhaps we are runing out of RAM, but still have some space left in program memory to store the computed values.

Also, you seem to suggest taking the values from some server or other computer at run-time, but that won't work if the system is a microcontroller that has no connection to the outside world once it's deployed. (We're not talking about an Internet of Things device here.)

ah, fair enough. so you need the values at compile time.
i'd still say option 2. it's more faff, but ultimately cleaner especially if the process is documented