Re: best approach to develop running software

mensanator_at_aol.com
Date: 01/25/05 

Date: 24 Jan 2005 18:13:35 -0800

Andreas Klimas wrote:
> recently there are some interesting topics in c.l.smalltalk and
> c.l.lisp which raises a more general question.
>
> what makes the different languages different ?
> syntax vs. syntaxless, dynamic typing vs. static typing
> compiler / interpreted included into runtime or not ?
>
> the smalltalk guys swear that smalltalk is the best way.
> so the lisp guys says that lisp is the best way, of course.
> so the C++, Java, C#, Perl ... whatever does.
>
> anyway. how should one decide which approach fits best
> his met.
>
> personaly I'm programming in C, C++ and Smalltalk since
> about 10 years now. in Java only a handfull of years.
> I don't have the feeling that any language has a great
> advantage over the others. well, Smalltalk is nice, but ...
> Actually I'm totally back to C.
> I have done some rewrites of my applications from
> Smalltalk to C and from Java to C. not only are the
> applications now an order of magnitude faster they are
> even smaller (by far less code) more bug free, and surprise,
> simpler. I even have replaced SQL servers by memory mapped
> files which gave me an second order of magnitude speed.
>
> well, now I ask, why do people think that applications
> written in <put your favorite language here> did have an
> big advantage against a (small) low level language like
> C or FORTH (in todays environment where memory is huge
> available, compiler / debugger / editors are well fitted
> and processors are quite fast).
>
> give me the technique or concept rather than the langauge.

Didn't you just answer your own question? The big
advantage of <language X> is that you can focus on
high-level issues without having to be concerned
about low-level issues.

Speaking as a non-programmer, I'm looking to solve
certain number theory problems. I don't care about
memory allocation, pointers or the data structure
of unlimited precision integers. I just want to solve
a linear congruence where the variables involved have
50000 decimal digits. I don't care how it does it
as long as I get my answer.

> I would rethink and probably reimplement the mechanism as
> needed (only those for the problem to solve).
>
> maybe I totally miss the point. anyway I'm looking
> forward to get my confusion cleared.
>
> best wishes
> Andreas Klimas