I wouldn't argue that it's easier to maintain code in a dynamic high-
level language like Python rather a compiled relatively low-level
language like C. Some projects benefit from focus on elements of
programming like memory management and are thus better written in C,
but the problem that's impacting the population of C programmers is
that C is chiefly used in "close to the metal" code or things that
need to run with a minimum of support from other OS facilities like
kernels or SMF. Languages like Java have been made central to an
approach to development that emphasises higher-level logic and more
general problem solving. This has its ups and its downs, but the fact
of the matter is that languages like perl, Python, and Ruby that can
be used as much for scripting and automation as web development. That
amounts to access to a much wider range of jobs, so people tend to
have a loose ability to read C and at least a passable ability to
write in a high-level language and a capability to climb the learning
curve quite a lot faster learning another dynamic language rather
learning C. This is reflected in education: from what I've seen of
computer science programs in the US and UK, the move away from C to
Java or C# as the first language taught in computer science courses
and in many cases the only language learned in the classroom has been
fairly firmly entrenched for more than 15 years. The emphasis has thus
shifting towards code that expresses the logic of the problem you're
trying to solve as opposed to the lower-level mechanics of the
implementation.
Such is why perl and Python tend to be the integration glue that holds
large-scale infrastructure together at places like Google: these sites
use technologies which solve their problems and for which they can
readily source talented people familiar with the technology. To the
extent that there's a question of "hip" or "cool", it's just as fair
to say that movement from mainframes to distributed systems or from
terminal applications to client-server to n-tier partake of fashion
phenomena: you can't completely extricate motion in marketplaces with
so much money sloshing around from trendiness. You go on to mention
Bill Joy, but these are also the kind of dynamics that led Joy to
think that developers already versed in C might benefit from a Unix
shell using C syntax rather than having to learn Bourne. Conversely,
Joy found himself fifteen years later sufficiently convinced that C
wasn't the be-all, end-all of language design or implementation that
he helped mid-wife Java at Sun.
I don't therefore see it as inherently objectionable that something
like packaging be written in Python. The upside of writing in a
dynamic language is that you can read the code from any point where
the documentation leaves off (e.g. internals), which can also make it
easier to get not just bug reports but patches from the community. As
far as performance goes, any well-designed packaging system is going
to have most of the work done on its behalf by system calls when it
comes time to lay down the software. The difference in execution time
when evaluating metadata, which is the rest of what you'll need to do,
is likely to be sufficiently comparable that no one's going to
complain that their software install is intolerably slow. Performance
optimisation past a certain point of adequacy becomes a trade-off
between maintainable code and further performance benefits, which is
why premature optimisation is said to be a fatal mistake in software
engineering. Choosing the right language for a project can be a
version of that dilemma.
Again, I'm not arguing that there are perfect languages (or that there
haven't been some nasty side effects from dynamics that have resulted
in a generation of developers who generally think that memory
management is a magic property of the virtual machine running their
code and don't understand much about how these classes of problems
impact performance and scale, not to mention reinforcing unnecessarily
short lifetimes for computers, as developers expect consumers to
continue compensating for poor software engineering by buying systems
with faster CPUs, more cores, and more memory to run it)–I think some
of the benefits of higher-level languages can be overstated to support
conclusion and that this has had some downsides in terms of software
quality and development expertise. I don't think that's the case here.
Am 17 Dec 2009 um 09:50 schrieb Joerg Schilling:
Joseph Mocker <m...@sun.com> wrote:
While I don't entirely agree with UNIX admin, I am sort of concerned
with the growing number of scripting environments that are now
required
to make [Open]Solaris run.
First I realized that Perl was needed was when I discovered the kstat
was rewritten in Perl, which kind of bummed my Operations folks out
to
have to install Perl just for a few utilities that had previously
been
written in C. (I ended up rewriting kstat for them in C, pretty
easily).
Now Python is needed for IPS, Xen, probably more. What other language
platforms are necessary?
+1 and BTW: I don't see that software written in scripting languages
is easier
to maintain than C programs.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling
D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
