Also see: http://root.cern.ch/drupal/content/cint — an interpretor, but large.
1) a library that lets you compile C code within a process, relocate it and execute it. This is rather faster than shelling out to run gcc to create a shared object and open it using dlopen.
2) an awesome 2004 demonstration where TCC was used as a boot loader. Take the Linux kernel source (slightly modified to remove some of the gccisms), add TCCBOOT and reboot the machine: as part of the boot process TCC recompiles the kernel and the continue to execute the freshly compiled kernel -- all in 15 seconds: http://bellard.org/tcc/tccboot.html
DOS weenie pride!
Take TCC with your point 1 above. Mix it with the ideas from Schemix ( http://abstractnonsense.com/schemix/ ). Now you can iteratively development a kernel driver!
I hacked on Schemix a while back, updating it to 2.6 module system (unfortunately lost the source code before it got uploaded). It's a seemingly great idea but what good is scheme code if you have to rewrite in a different language for the final version?
When I was using tcc a lot I used the tinycc fork as it had fixed bugs I was encountering. It's a shame that things didn't work out amicably.
- each dependecy makes it harder to build your project
- and makes it more brittle (libraries goes obsolete, changes versions, occasionaly have non-backward-compatibile changes, on different systems different versions of libraries are available, etc)
- most of the time you use only small fraction of each library, it is also common (at least in static typing world) that libraries enforces data structures on you, so sometimes it's easier to reinvent wheel, than to integrate your app with some library
- when you need to add some feature to library you often have to go throught hoops (inherit some class, make some wrappers and use it instead of what you'd use normally) - it is much easier to keep things simple, when you have controll over interfaces and can just change what you want, also architecture is simpler without proxies, wrappers and delegates
- static binaries on linux don't work after a few years
- dynamic linked binaries works as long as somebody worries about dependency problems - and this means you
- you can keep all dependencies in VCS together with your project, but often it's not legal (LGPL)
- not really important for most apps - dependencies bloats your app
Dependencies in programming are like moving parts in enginering - there should be as few of them as possible.
> I'm not trolling:
> I actually think that.
http://arstechnica.com/apple/news/2010/06/devs-cautiously-op...
Otherwise it is probably better to use Lua for instance, since I bet it is much faster (I just read part of the PicoC implementation and it is a pretty straightforward interpreter, very cool to read but hardly the faster) and safer.
As I understand, the main appeal of using C as a scripting language is the fact that you use the same language in compiled and interpreted part of your application.
Drawbacks of using C interpreter for scripting could include large footprint and external dependencies, but as far as I can understand, they are not the case here.
So what is your reasoning for Forth?
While not exactly a scripting language per se, Forth does have amazing interactive capabilities. It's extremely light-weight and it's easy to implement a new Forth on a new hardware architecture. Footprint issues aside, development time in Forth is usually shorter, and the ability to connect directly to a device's Forth "shell" and try out Forth words (functions), create new words, play around with hardware in real-time is invaluable.
Forth code is less readable if you don't know Forth, and occasionally Forth programmers write ugly code, but that is definitely the case for embedded C programmers too.