3 ms·

No. You really don't want to do this. Really. I have worked with a project for the past several years that, by necessity not choice, required a web application

No. You really don't want to do this. Really. I have worked with a project for the past several years that, by necessity not choice, required a web application framework written in C (it's an embedded platform) and I can tell you it is pure hell. The most mundane and simple tasks, often trivial one-liners in scripting languages, require many lines of error-prone C code even with a fairly rich set of libraries available. Working in this environment, you'll quickly realize why the rest of the world doesn't do it this way. Thankfully, this project is finally moving away from this architecture and I couldn't be happier about it.

silentbicycle 17y ago
Would Lua have worked there? It's a ~200k library designed to provide an embedded scripting language to C projects. (It's very similar to Python, but a tenth the size, and with a bit more Scheme influence.) While it may be too big for some especially tight embedded platforms, if you could fit it in, it would have likely been substantially less painful. It's also a pretty good scripting language on its own merits, and has replaced Python as my default language. (Unlike Python, its design expects you to know at least a little C, but in exchange, it avoids cluttering the language with things that C already does well.)
- gamache 17y ago
  Lua is meant for embedding in C programs; that is different from running on embdedded systems. The latter typically features drastically less RAM and CPU cycles, so most interpreted languages (which are not shy about trading away some performance) don't cut it. There are some exceptions; FORTH, for instance, can fit in about a kilobyte and its performance isn't miserable. But putting e.g. Lua in a confined space would not work out well.
  - silentbicycle 17y ago
    To my understanding "embedded systems" spans from something with 1k of memory to something like a cell phone or a router. Working with Lua is quite comfortable on the latter, hence my qualification. It's been ported to Lego Mindstorms (http://www.hempeldesigngroup.com/lego/pbLua/index.html http://www.hempeldesigngroup.com/lego/pbLua/index.html), for example, which is "a 32 bit ARM7 microcontroller with 256K of FLASH and 64K of RAM." It's not clear from the post which end of the spectrum he or she works with. (I don't work with embedded systems professionally, I've just tinkered with OpenWRT, cell phones, etc. as an enthusiastic amateur.) It would be usable in the same niches that SQLite is, for example.
baguasquirrel 17y ago
You're attacking the weaknesses of C, not the weaknesses of compiled languages for web platforms.
nkurz 17y ago
The most mundane and simple tasks, often trivial one-liners in scripting languages, require many lines of error-prone C code even with a fairly rich set of libraries available. What would be an example of this? I'm mostly a C and Perl person, and once a library is available I've never noticed cases where something was much simpler to write in one than the other. That library might take more time to write in C than Perl, but once it's written I find it just about (less than a factor of 2?) as easy to write the application logic in C as in Perl. My instinct is that if you're writing 'many lines of error-prone C' to do something simple, there's probably room for improvement somewhere.

silentbicycle 17y ago

Would Lua have worked there? It's a ~200k library designed to provide an embedded scripting language to C projects. (It's very similar to Python, but a tenth the size, and with a bit more Scheme influence.) While it may be too big for some especially tight embedded platforms, if you could fit it in, it would have likely been substantially less painful. It's also a pretty good scripting language on its own merits, and has replaced Python as my default language. (Unlike Python, its design expects you to know at least a little C, but in exchange, it avoids cluttering the language with things that C already does well.)

gamache 17y ago
Lua is meant for embedding in C programs; that is different from running on embdedded systems. The latter typically features drastically less RAM and CPU cycles, so most interpreted languages (which are not shy about trading away some performance) don't cut it. There are some exceptions; FORTH, for instance, can fit in about a kilobyte and its performance isn't miserable. But putting e.g. Lua in a confined space would not work out well.
- silentbicycle 17y ago
  To my understanding "embedded systems" spans from something with 1k of memory to something like a cell phone or a router. Working with Lua is quite comfortable on the latter, hence my qualification. It's been ported to Lego Mindstorms (http://www.hempeldesigngroup.com/lego/pbLua/index.html http://www.hempeldesigngroup.com/lego/pbLua/index.html), for example, which is "a 32 bit ARM7 microcontroller with 256K of FLASH and 64K of RAM." It's not clear from the post which end of the spectrum he or she works with. (I don't work with embedded systems professionally, I've just tinkered with OpenWRT, cell phones, etc. as an enthusiastic amateur.) It would be usable in the same niches that SQLite is, for example.

baguasquirrel 17y ago

You're attacking the weaknesses of C, not the weaknesses of compiled languages for web platforms.

nkurz 17y ago

The most mundane and simple tasks, often trivial one-liners in scripting languages, require many lines of error-prone C code even with a fairly rich set of libraries available. What would be an example of this? I'm mostly a C and Perl person, and once a library is available I've never noticed cases where something was much simpler to write in one than the other. That library might take more time to write in C than Perl, but once it's written I find it just about (less than a factor of 2?) as easy to write the application logic in C as in Perl. My instinct is that if you're writing 'many lines of error-prone C' to do something simple, there's probably room for improvement somewhere.