Re: Other than php/perl/lisp/c/c++/java, anybody have a favorite computer-programming language?
- From: rem642b@xxxxxxxxx (robert maas, see http://tinyurl.com/uh3t)
- Date: Mon, 05 Feb 2007 09:15:02 -0800
From: "Arthur J. O'Dwyer" <ajonos...@xxxxxxxxxxxxxx>
Ideally, an algorithm is designed independently of data type. WhileBasically true if we assume "data type" means "primitive C-like
this is not always possible, it most often is. A language that
supports generics/templates (C++, Eiffel, Ada, and now Java) can
enable this kind of generality of design.
data type" (integer, char, bool, floating-point, bignum, even string),
I disagree with both of you. Many of the specific operations that are
meaningful for one datatype aren't meaningful at all for another datatype.
For example, arithmetic (add, subtract, multiply, divide) make
sense for numbers (integers including bignums, floating-points,
rationals) but not for the other types (char, bool, string).
Picking an element based on index makes sense for strings and other
kids of vectors (1-d arrays), but not for char or bool or even
integer except if the integer is treated as if a bitvector.
Operations to convert from UTF-8 to UTF-16 make sense for strings
or byte vectors but not much else. Append and sub-sequence make
sense for any kind of vector, but not much else. Lots of algorithms
deal intimately with these restricted-type operations, for example
GCD makes sense only for integers (including bignums) and maybe
rationals (by a different algorithm based on the GCD-of-integers
algorithm). Converting to upper-case works for individual
characters or strings, but not floating-point numbers, maybe
integers if they are interpreted either as single ASCII or UniCode
character codes or as packed bytes of ASCII character codes.
I think Java's concept of "interface" is useful as a way of
thinking about such matters, even for primitive types that aren't
"objects" in Java: Numbers support the "arithmetic" interface. Any
algorithm that depends on that particular interface but nothing
else will work with numbers. Integers support the "well-ordered"
interface. GCD and a few other algorithms depend on that and would
work fine on other datatypes that also support both "arithmetic"
and "well-ordered" interface. (Actually "arithmetic" interface is
in two flavors, ring and field, where rationals satisfy both but
integers satisfy only ring. Some algorithms such as exact division
don't work without the "field" interface.)
If you really believe all algorithms that work on integers also
work on strings and bools, try to devise a version of the Chinese
Remainder Theorem that works with strings and bools.
As to what you said later about containers and algorithms that
operate on/with them, I agree with what you said.
When one has a choice of language, that choice should be madeTrue.
on the basis of how well that language supports the functional and
qualititative issues related to the problem to be solved. Simply
putting together comparative algorithms may mask the importance
of those qualititative concerns.
I agree that learning *how* to do the same task in all the
different common likely-to-be-chosen programming languages, such as
by consulting to my multi-language "Cookbook", is just a first
step. Next a judgement must be made as to which would be *best* for
the overall task, considering ease of writing the code and getting
it to work correctly, speed of execution, and political/interface
considerations. Sometimes the fact you're doing a project in an
all-C++ shop precludes using Java or Lisp or PHP to do some
particular task, but other times you just have to get the boss to
make an exception because writing a certain part of the system in
C++ would be a major burden while interfacing between C++ and
another language would be relatively easier.
By the way, I've mostly finished writing the first two chapters
(data types part 1, mostly the types that can be used as literals
in a program; syntax for program structure), and I've made some
progress on the third chapter (the matrix of operations that deal
with one or two specific data types), having most of the built-in
C-et-al operators included alongside their lisp equivalents. For
chapter 4 (control structures and programming paradigms) I have
only a summary of what I want to eventually include. In chapter 3
I'll be including simple assignment and member access, as well as
comparison of pointers, with the next edit, probably later today.
Allocation and disposal of memory will be done later when I start
dealing with the standard libraries. (I wanted to get the pure
C-syntax part all completed first.) Otherwise, would any C expert
be willing to look at what I have now and tell me if I omitted or
mis-described any built-in operator?
<http://www.rawbw.com/~rem/HelloPlus/CookBook/CookTop.html>
Chapters 1,2 are in same file, link to chapter 3 which is in another file.
.
- Follow-Ups:
- References:
- Prev by Date: Are you outsourcing software development?
- Next by Date: Re: Alternative to C for system programming
- Previous by thread: Re: Other than php/perl/lisp/c/c++/java, anybody have a favorite computer-programming language?
- Next by thread: Re: Other than php/perl/lisp/c/c++/java, anybody have a favorite computer-programming language?
- Index(es):
Relevant Pages
|
