On Sat, Aug 19, 2006 at 08:27:09PM -0500, Gabriel Sechan wrote:
>
>
>
> >From: Lan Barnes <[EMAIL PROTECTED]>
> >On Sat, Aug 19, 2006 at 03:35:17PM -0700, Stewart Stremler wrote:
> >> That being said, there are a lot of areas where C doesn't seem
> >> appropriate. GUI _applications_, f'r instance.
> >>
> >
> >God I wish I oculd get that through to people. The problem may setem
> >from viewing the components as separate (OS, GUI, app) rather than as
> >one system.
> >
>
> Until you start buying my hardware for me, performance does matter, and
> C/C++ is the correct language to use- for everything. The correct answer
> is to use a tool to layout the UI elements, and have it create the C code
> to place the elements.
>
> Gabe
>
I'm sorry, but we have a strong difference of opinion here (and I
usually line up right behind you on almost everything -- go figure!).
Please remember that I am the cheapest of the cheap, and run many
things, including at work, on discarded PCs that are no longer
considered fast enough for secretarial work. So I'm _not_ finding that
performance lags when a scripting language is used (on M$ they may load
slower than a compiled program, but everything loads slower on that dog
and you can always give them a progress bar).
So here's my pitch. The money saved in development time and maintenance
by using scripting languages for apps more than offsets any step up in
memory or CPU speed that the clients might need, if any boost at all is
needed. In my experience, most enterprise upgrades in processing power
on the desk are either done because the newest Windows needs it (not the
apps running on it) or just because. (Sometimes I think CIOs measure
their peckers by how much they spend ... explains a lot, especially
SAP.)
I suspect that compiled languages are actually preferred because PHBs
think compiled code is more difficult to steal. To a certain extent,
that may be true, although it is an example of security through
obscurity, with all the effectiveness that that phrase implies (IOW,
not much).
A good app in Python, Tcl/Tk, or Ruby (reputation only) is rapid to
develop and kicks butt from a user POV. (I don't include perl, which I
adore for one-off utilities, because I consider it too idiosyncratic to
scale or endure maintenance.)
Can't speak for the others, but in Tcl, if it has CPU-intensive
routines, you have the option of identifying them through histograms and
then rewriting them in C/C++ and binding them in as new commands. The
language is designed for exactly that ... quite easy. Even I can do it
;-)
In practice developers frequently find that they don't have to bother
with C optimization because what they thought would be slow isn't.
I am a convert to scripting languages. I used to argue that C (_not_
C++) was the final answer to everything. I still think C is a beautiful,
expressive, and rational language for system/driver development. But for
application development, I reach for Tcl/Tk with every confidence that
I'll have the shortest development time, the fewest low-level bugs, far
easier maintenance, improved scalability over C or at least scalability
with far less work (really, I mean it), a higher degree of cross
platform portability, yadda yadda yadda.
Haven't we all discussed this before?
--
Lan Barnes
Linux Guy, SCM Specialist
Tcl/Tk Enthusiast
Why should we hear about body bags and deaths, and how many, what day
it's going to happen, and how many this or what do you suppose? Or I
mean, it's ... it's not _relevant_, so why should I waste my beautiful
mind on something like that?
- Barbara Bush on "Good Morning America," 3/18/2003
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
