C in Science and Engineering...

[FredK]

which kind of implies your functions might be doing too much. Even the
Structured Programming crowd suggested that you should be able to
describe a function in a short sentence.

No, that they are poorly organised

char *translatetofrench(char *english)

is a perfectly well-formed function. Of course if it is any good it
will call many thousands of subroutines, and it will never give
perfect results on all input.

int is_vowel(char ch)

is probably one of the subroutines it will call, deep down in the
logic. Again, this is a perfectly-well formed fucntion.

 

[Michael Foukarakis]

Perhaps ugly, but perhaps informative.  Especially when the template has an
*abstract* explaining what a snafu context is and the approach taken to
derive it.

Pull some random Linux source out that you aren't intimately familiar with -
and anything over a half dozen lines tends to be gibberish.  So you spend a
few hours analyzing uncommented logic with "clever" but meaningless routine
names and even less informative variable names.  When the programmer could
have spent a few minutes explaining it - heck, even explaining how clever
his naming is.

http://lxr.linux.no/#linux+v2.6.34/fs/namei.c#L1897

That's a pretty nice snippet, methinks. Granted, not all Linux kernel
code is written that way, but if you're a kernel newbie asking for
trouble there are other places you can start before looking directly
at the source code (documentation, dozens of tutorials, mailing lists
and so forth). Ironically, that's the same with every other non-
trivial project, regardless of the language used for the
implementation.

 

[jacob navia]

FredK a écrit :

int is_vowel(char ch)

is probably one of the subroutines it will call, deep down in the
logic. Again, this is a perfectly-well formed fucntion.

Does an accentuated letter count as vowel?
What table does this function use? Unicode? utf8? utf16?

You HAVE to explain stuff, even if the name is self evident!

 

[Tim Harig]

Yes, (I had to read and port perl programs to C++) -

I have opinions about C++ as well. I learned C++ before templates became
part of the language. I liked the language well enough then; but, I didn't
really have much use for it personally. I hadn't really internalized the
OOP paradigm; and, at the time, it seemed like more overhead to me then
benefit. Over time, I more deeply internalized OOP thought process and
used more and more OOP constructs; but, when I came back to C++ the
language had become a very different beast then it had started out as.

These days, C++ is a *huge* langauge with a lot of features to have
to learn. The STL itself is a daunting beast. This seems to become a
problem with many languages as the progress over time. I stay with C
largely because it tends to stick more to its roots of being a language
small enough for a mere mortal to learn.

Instead of re-aquainting myself with C++, I have been looking for
something else that provides the features that I am looking for in a
smaller package.

And no, I know, it has wonderful features; it changes your thinking
about
programming etc. and I have read lots of books, mostly by supporters,
but
- I dislike Lisp et relatives as much!

Yea, Common LISP would definitly come in as a close second in the least of
my most disliked langauges; but, thats only because of the parenthesis. It
seems to me that I worked with a language once, of which I do not remember
the name, which was essentially LISP using a syntax independent of the
parenthesis/list structure. The list handling was still implied; but, it
was less explicit. I don't remember it being too bad.

I have worked with other languages that used "different" (for lack of a
better word) syntax mechanisms such as the stack based syntax of FORTH or
Postscript. Sometimes these things work out well even if they are a little
odd to most programmers.

What bothers me about Perl is that it is basically a conventional language
structurally; but the sigils and shortcut idioms make it look like
something else. I understand their uses; but, if you are going to make a
language different make it different enough that it stands out.

Perl, like C++, is also a very large language to learn and it seems that
Perl most Perl developers tends to use the subset of the language that they
find useful and which they are familiar with. This of course may be a
different subset that you have found useful and become familiar with.

I think, every developer has some aesthetic sense -
for programs and for programming languages.
While the preference for a PL might be historic and personal,
I think, a greater agreement exits of programs, that 'smell' -
somehow!

I have say thats true.

(As for scripting, I use Rexx since 20 years, over s.th. like 20
platforms,

I really like Rexx, but, I came rather late in the game (and I have not
learned the newer versions such as ooRex which seems to dominate in c.l.r).
I like its fallthrough to the system and I sometimes use it as a more
capable shell when creating system command based scripts that are tedious
to compose using Bourne shell constructs or awk. I do most of my general
purpose scripting and dynamic language programming in Python.

 

[Rui Maciel]

that was exactly my reaction to C when I first saw it. I'm a former
Pascal programmer.

Hell, I'm not even that big a fan of Perl. But in its own niche it's
excellent. If I want to match regexps how do I do it? Is there a C
library that does this without using arcane symbols?

This thread took a bad turn somewhere in the discussion. There is no question that languages such
as Perl, Ruby and Python have their rightful place and that in some applications they fare better
than languages such as C. Yet, no language is the right tool for every job. In this case, dynamic
languages such as Perl, Python and Ruby are far from being the right tools to develop scientific
computing applications. Nonetheless, they do have their rightful place.


Rui Maciel

 

[Rui Maciel]

The only commùents I find in the gnu source code is the FSF copyright
notice at the beginning of each file. This is a constant problem.

This isn't a GNU thing. You just happened to stumble on a project which is a mess and is a bit
lacking on the organization side of things. Meanwhile, there are other GNU projects who happen to
have decent comments. Please take a look at:
http://git.savannah.gnu.org/cgit/sed.git/tree/sed/sed.h

It has plenty of comments to go around. And informative comments, too.

Conclusion:

It is better to have a documented API than a bunch of C source
code that you have to figure out!

Very true.


Rui Maciel

 

[Dann Corbit]

This thread took a bad turn somewhere in the discussion. There is no question that languages such
as Perl, Ruby and Python have their rightful place and that in some applications they fare better
than languages such as C. Yet, no language is the right tool for every job. In this case, dynamic
languages such as Perl, Python and Ruby are far from being the right tools to develop scientific
computing applications. Nonetheless, they do have their rightful place.

Python makes a truly wonderful glue to stick scientific and mathematical
packages together. To wit:
http://www.sagemath.org/

IMO-YMMV

 

[blmblm]

use APL
(and buy a new keyboard)

Or use J, and have most of the fun of APL (as I understand it) with
your existing keyboard! (I'm not a J fanatic myself, or even a
competent J programmer, but I work with someone who is both, and
I suspect he would agree with the sentiments expressed upthread.)