On 11/12/2012 02:15 PM, Miloslav Trmač wrote:
On Mon, Nov 12, 2012 at 7:54 PM, Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote:
Right. We need to stop writing core system components in scripting
languages!
Well, there _are_ significant advantages to using a higer-level
language than C.[1] Using one of the higher-level languages as a
primary development language on par with C often increases the quality
of the software and the time to develop it, in return for an
acceptable loss of speed.\
.......
[1] At least two to mention:
- Automatic memory management, with all associated lack of bugs and
simplified code
- Much easier access to higher-level (and more efficient!) data
structures. C programs frequently use linked lists instead of e.g.
hash tables simply because maintaining hash tables and the associated
memory allocation is just too complex.
+1!
I imagine that Kevin objects to the interpreter-induced slowness of
scripting, but quite often it's not even relevant because the code
doesn't run that much. To Miloslav's list of advantages, I would add
access to better libraries (e.g. network programming in Python or Tcl is
much easier than socket()-based code). There's the force multiplier
effect of higher level libraries allowing better algorithms, which often
trumps any advantages from compiled code.
If there's a _measurable_ speed issue, all modern interpreters have an
easy 'native method' interface, i.e. way of linking compiled code
functions that implement time-critical parts, if they are too slow for
interpreting. Let's avoid premature optimization--otherwise, taking this
idea to the extreme, one could argue for rewriting system services in
optimized assembly.
Remember also that data is code: any config files could be seen as tiny
specialized interpreted languages, so it's not like you can avoid
interpretation anyway. Perhaps embracing scripting in system components
would have a desirable side effect of more uniform config file syntax
because it's just easier to use some standard form like JSON or XML..
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
