C in Science and Engineering...

[chutsu]

I've kind of learnt the basics of programming in Python, and I can't
resist the feeling that the use of C in scientific and engineering are
dropping dramatically compared to before 2000's. I realize that there
are many benefits to using scripting languages such as python to speed
up code development, however I fear in the long run the cost of speed
development is very expensive, because of code backwards
compatibility.

The interpreter changes with every release, and just like in ruby 1.8
to 1.9, the code are not all backwards compatible. Neither are code
before Python 3000. So I guess my question is, are there still people
sill using C in science and engineering? Can one be trained so that
they can code programs as fast as other programmers using python or
ruby?

 

[Stefan Ram]

So I guess my question is, are there still people sill using
C in science and engineering?

Recently, a university paid me to teach a scientist (biology) C.
So, I believe that there was at least one instant within the
last months when at least one scientist was using C.

However, »science and engineering« possibly is an
abstraction not usable for such a question, because
programming in language research might be a whole other kind
of programming than programming in bridge construction or
field theory.

Can one be trained so that they can code programs as fast as
other programmers using python or ruby?

Some simple programs can be written just as fast. However,
managing dynamic data structures (memory management) will
always be more difficult in C.

Also, someone who already knows object-oriented or
functional programming might be tempted to do this in C,
and might spend so time trying to »implement« it in C in
the sense of:

»Any sufficiently complicated C or Fortran program
contains an ad hoc, informally-specified, bug-ridden,
slow implementation of half of Common Lisp.«

http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule

But if one can deal with these temptations, C can be used.

The interpreter changes with every release, and just like in
ruby 1.8 to 1.9, the code are not all backwards compatible.

That's a good point! Some years ago someone said:

»C is dead.«

And I sometimes /want/ a dead language! That is, I want
my code to develope, but I want the underlying language
to be stable across the decades. So, sometimes a dead
language (that is, a language that does not change much
anymore) is exactly what you want.

 

[Fire Crow]

Can one be trained so that
they can code programs as fast as other programmers using python or
ruby?

yes, a dynamic language is just alot of objects, written in C in the
case of python.

so to prototype as rapidly, just requires reusable code tailored
to the things you do.

Python actually has a very nice C api, so you can use the python
objects under the hood and build C extension to python.

static PyObject *testobj(PyObject *self, PyObject *args) {
...[snip]...
/* the C awesomenes takes place here */
...[snip]...
return Py_BuildValue("i", result);
}

I would frame the situation this way, if you can use dyanimic
objects in python, and link C code in. you can also just
use the C source for the python dictionary in your C code.

which once I realized this I moved from Python to C altogether
and now roll my own "reusable dynamic objects" with all the
added control and efficiency of C, and none of the only
inconsistencies in languages are the changes I make the
data structure libraries I've created, which is I'll admit is
about as bad as the ruby scenario you described

 

[Tom St Denis]

I've kind of learnt the basics of programming in Python, and I can't
resist the feeling that the use of C in scientific and engineering are
dropping dramatically compared to before 2000's. I realize that there
are many benefits to using scripting languages such as python to speed
up code development, however I fear in the long run the cost of speed
development is very expensive, because of code backwards
compatibility.

Try writing code for embedded targets for a living then comeback and
say Python is the way forward.

Tom

 

[chutsu]

Can one be trained so that
they can code programs as fast as other programmers using python or
ruby?

yes, a dynamic language is just alot of objects, written in C in the
case of python.

so to prototype as rapidly, just requires reusable code tailored
to the things you do.

Python actually has a very nice C api, so you can use the python
objects under the hood and build C extension to python.

static PyObject *testobj(PyObject *self, PyObject *args) {
    ...[snip]...
    /* the C awesomenes takes place here */
    ...[snip]...
    return Py_BuildValue("i", result);

}

I would frame the situation this way, if you can use dyanimic
objects in python, and link C code in. you can also just
use the C source for the python dictionary in your C code.

which once I realized this I moved from Python to C altogether
and now roll my own "reusable dynamic objects" with all the
added control and efficiency of C, and none of the only
inconsistencies in languages are the changes I make the
data structure libraries I've created, which is I'll admit is
about as bad as the ruby scenario you described

But How easy is it though? To do that one has to modify the code don't
they? The example provided in the Python Docs was a simple one, what
if the library or program was a complex one? Would doing the ruby way
be easier?

 

[Rui Maciel]

So I guess my question is, are there still people
sill using C in science and engineering? Can one be trained so that
they can code programs as fast as other programmers using python or
ruby?

I haven't found a single person using python or ruby for serious science and engineering
applications. The ones I'm familiar with tend to use either fortran, C or matlab, and in some rare
cases even C++. In fact, the only people which I noticed weren't using any of those languages were
undergrads with a very poor programming background and a terribly limited programming experience who
tried to follow the path they believed was the one which offered the least resistance, and their
choice was mainly between visual basic, excel and python.

Having said that, it's a very sad thing to watch some poor sap implementing a Gauss factorization
routine on excel.

But going back to the subject, why exactly do you believe people should drop C in favor of python
for this sort of application?



Rui Maciel

 

[Rui Maciel]

But How easy is it though? To do that one has to modify the code don't
they? The example provided in the Python Docs was a simple one, what
if the library or program was a complex one? Would doing the ruby way
be easier?

The question you should be posing is: why do you believe writing a program in ruby is easier than in
any other language?


Rui Maciel

 

[Seebs]

The question you should be posing is: why do you believe writing a program in ruby is easier than in
any other language?

For the sorts of things it's good at, Ruby is a particularly expressive
language, and for large categories of problems, I would usually expect that
I could have something working reliably in Ruby in a tiny fraction of the
time it would take me to get something comparable working reliably in C.

There are, of course, tradeoffs. It's not going to execute as quickly as
the C code, for instance.

But if I were doing, say, some kind of dynamic web content, I would take
Ruby over C in nearly all cases. *Nearly* all, mind.

-s

 

[Rui Maciel]

For the sorts of things it's good at, Ruby is a particularly expressive
language, and for large categories of problems, I would usually expect
that I could have something working reliably in Ruby in a tiny fraction of
the time it would take me to get something comparable working reliably in
C.

There are, of course, tradeoffs. It's not going to execute as quickly as
the C code, for instance.

But if I were doing, say, some kind of dynamic web content, I would take
Ruby over C in nearly all cases. *Nearly* all, mind.

I see what you mean and, from your example, you have a point. Nonetheless, in this case the
application domain is restricted to scientific computing. Basically, that means that all an
application must do is input data, crunch numbers and output the result. I doubt that adopting an
interpreted language such as Ruby or Python will help anyone handle data input and output and I
really doubt that those language's "expressiveness" will be of any use when writing code to crunch
numbers.

From that, why would anyone believe that writing this sort of programs in ruby or python is easier
than writing it in some other well established language such as C? It may appear to be easier
when dealing with GUIs or dynamic web content but number-crunching? I don't see how.


Rui Maciel

 

[bart.c]

I see what you mean and, from your example, you have a point.
Nonetheless, in this case the
application domain is restricted to scientific computing. Basically, that
means that all an
application must do is input data, crunch numbers and output the result.
I doubt that adopting an
interpreted language such as Ruby or Python will help anyone handle data
input and output and I
really doubt that those language's "expressiveness" will be of any use
when writing code to crunch
numbers.

From that, why would anyone believe that writing this sort of programs in
ruby or python is easier
than writing it in some other well established language such as C? It may
appear to be easier
when dealing with GUIs or dynamic web content but number-crunching? I
don't see how.

Let's see: not worrying about allocating or growing dynamic arrays,
forgetting memory management for them, being able to deal with entire arrays
at once, not bothering about data-typing, not dealing with fussy,
punctuation-obsessed syntax, not having to keep declaring/undeclaring
identifiers as they pop into and out of existence....

That is not easier?

There are all sorts of efforts underway to get these languages faster (I'm
even doing my own bit), which suggest that people like using them, and would
be used even more if they were more efficient.

 

[Mark]

I see what you mean and, from your example, you have a point.
Nonetheless, in this case the application domain is restricted to
scientific computing. Basically, that means that all an application
must do is input data, crunch numbers and output the result. I doubt
that adopting an interpreted language such as Ruby or Python will help
anyone handle data input and output and I really doubt that those
language's "expressiveness" will be of any use when writing code to
crunch numbers.

From that, why would anyone believe that writing this sort of programs
in ruby or python is easier than writing it in some other well
established language such as C? It may appear to be easier when
dealing with GUIs or dynamic web content but number-crunching? I
don't see how.

Most of the engineers I work with use Fortran. Some even use a recent
version of Fortran, many do not (even when they think they do).

This is largely because scientists and engineers like the reliability
which comes with long-established models. One very important piece of
research code we use models atomic behaviours. Its been in continual
development since 1971 and there are literally hundreds of research
papers which have developed using this software. Resistance to changing
language are well founded and largely relate to:

- Reliability: this specific implementation has been under constant
scrutiny for decades. No software is bug-free, but this one is
now very well understood.
- Comparability: there is real concern that even slight changes in
the effective computation means that the results can't be reliably
compared to historic results - which means a break in the research
results.

These things are important.

Onto your point, though. This software takes input data, crunches
numbers and outputs the results. Because of the reasons listed above,
no-one is going to move to rewrite this (right now) in a language like
Ruby, but I think you oversimplify the needs. In particular, the
complexity of the data representation the computation itself. Languages
like Ruby might not be any better at the IO, but the stuff in-between
may well be more elegantly expressed using such a language. I don't
think you can be as black-and-white as to say it has no place in SC.

Another key issue biting SC continually is good language support for
parallelism. Bolt-on solutions like MPI are good (and extensively
used) but, as these issues start to really bite, it wouldn't surprise me
if it forced a full redesign of these models to fully exploit modern
hardware's potential.

At that point, a lot of the arguments in favour of sticking with
existing code are washed away. At that point, they may well jump to
some sort of extended Fortran, C or whatever...but they might be more
adventurous and choose the language which provides the "best" way to
express their models (in terms of performance, elegance,
maintainability, proveability) rather than simply using the same
language they've always used.

Would it be Ruby or Python? I don't know. I do know a fair few of our
Computer Scientists and Electronic Engineers have used NumPy in their
research...

 

[Rui Maciel]

Let's see: not worrying about allocating or growing dynamic arrays,
forgetting memory management for them

I don't see how handling data structures in C poses any problem, unless the people writing the
code don't have the faintest clue about basic data structures.

being able to deal with entire arrays at once,

I don't see how C stops anyone from "dealing with entire arrays at once".

not bothering about data-typing

That doesn't make sense. If you don't know what data types you are using then how do you know how
your margin of error is propagating?

not dealing with fussy,
punctuation-obsessed syntax, not having to keep declaring/undeclaring
identifiers as they pop into and out of existence....

These two points are silly, as they constitute nothing more than "I don't like this particular
syntax".

That is not easier?

Those points were either non-issues or potential sources of problems.

There are all sorts of efforts underway to get these languages faster (I'm
even doing my own bit), which suggest that people like using them, and
would be used even more if they were more efficient.

And a whole lot of work must be done before this becomes a non-issue.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=gcc


Rui Maciel

 

[Ben Bacarisse]

Let's see: not worrying about allocating or growing dynamic arrays,
forgetting memory management for them, being able to deal with entire
arrays at once, not bothering about data-typing, not dealing with
fussy, punctuation-obsessed syntax, not having to keep
declaring/undeclaring identifiers as they pop into and out of
existence....

There is a middle ground: compiled languages with static type inference
like Haskell and the ML family. These have many of your stated
advantages whilst being (usually) much faster than languages like Python
and Ruby. Hardly surprising, then, that they are being used for
scientific computing though I have no idea what sort of take up there
has been.

<snip>

 

[Charlton Wilbur]

RM> From that, why would anyone believe that writing this sort of
RM> programs in ruby or python is easier than writing it in some
RM> other well established language such as C? It may appear to be
RM> easier when dealing with GUIs or dynamic web content but
RM> number-crunching? I don't see how.

Suppose I have to read an arbitrarily long list of arbitrarily long
genetic sequences from a text file. In C, I have to either allocate
more space than I will possibly need for it (and possibly find out I'm
wrong -- or, worse, that the person who wrote the code was wrong, and
the source code has gone missing), or I have to handle dynamic
allocation and keep track of pointers. In Perl, Python, or Ruby, I just
make a list, and the language worries about dynamic memory allocation.

And there are several features in the dynamic languages just like this:
the task can be accomplished in C, and probably more efficiently, but
requires a lot more fiddly bits and programmer attention. Dictionaries,
hashes, or maps - whatever they're called in your local dialect.
Regular expressions and data parsing. String manipulation.

I mean, here's a task. I'm going to give you a file of arbitrary
length. In that file will be words, separated by whitespace. I want
you to give me a list of all the words in that file, together with a
count of how many times they're used. How many lines of C code is that?
I can accomplish it with one line of Perl. An inexperienced Perl
programmer can probably do it in less than two dozen.

The scientist is interested in *doing the calculation*. The fact that
it takes him less time to write and debug the code -- because he
*doesn't* have to fuss with manual memory management, because he
*doesn't* have to think about the nuts and bolts of string parsing,
because he *doesn't* have to think about whether to roll his own
hash/dictionary/map library or to decide which publicly available one to
use -- is far more important than the fact that he could get results 8%
faster if he wrote the code in C instead of Perl, Python, or Ruby.
Because the first time his genetic sequence analysis code crashes 36
hours into a 48-hour run because of a dangling pointer, that 8% time
savings means very little.

Charlton

 

[Charlton Wilbur]

RM> I haven't found a single person using python or ruby for serious
RM> science and engineering applications.

Me neither. Most of the people I know in scientific computing are using
Perl to do their bioinformatics data crunching.

Charlton

 

[Moi]

RM> From that, why would anyone believe that writing this sort of
RM> programs in ruby or python is easier than writing it in some RM>
other well established language such as C? It may appear to be RM>
easier when dealing with GUIs or dynamic web content but RM>
number-crunching? I don't see how.

Suppose I have to read an arbitrarily long list of arbitrarily long
genetic sequences from a text file. In C, I have to either allocate
more space than I will possibly need for it (and possibly find out I'm
wrong -- or, worse, that the person who wrote the code was wrong, and
the source code has gone missing), or I have to handle dynamic
allocation and keep track of pointers. In Perl, Python, or Ruby, I just
make a list, and the language worries about dynamic memory allocation.

If the file fits into memory, I would probably mmap() it.
If mmap() is not available, there is the possibility of malloc()ing
one big array, read the entire file into it, and then do the parsing
and processing.

But for trivial dataset sizes, a perl/python -like language will probably
be faster, in terms of development time.

HTH,
AvK

 

[bart.c]

I don't see how handling data structures in C poses any problem, unless
the people writing the
code don't have the faintest clue about basic data structures.

The point is not having to bother with these details (together with all
their clutter, and potential for bugs) especially with code that is being
revised over and over again.

I don't see how C stops anyone from "dealing with entire arrays at once".

By having to deal with an element at a time?

That doesn't make sense. If you don't know what data types you are using
then how do you know how
your margin of error is propagating?

Typically such a language will use the most accurate type for floating
point. But you don't have to tell it what to use, and it's possible also to
have lists of mixed numeric types.

These two points are silly, as they constitute nothing more than "I don't
like this particular
syntax".

For someone who's a clumsy typist, there is just more opportunity for
mistyping. Again, for code that is being revised every few seconds, a lot of
time is wasted dotting i's and crossing t's there will never make it to the
final version.

Those points were either non-issues or potential sources of problems.



And a whole lot of work must be done before this becomes a non-issue.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=gcc

You've chosen an extreme example. There are languages that are not quite 300
times slower than C, and yet offer rapid development.

Anyway it's also possible to use such a language to develop an algorithm
(trying perhaps dozens of approaches), then to write the final version in C.

 

[bart.c]

I don't see how handling data structures in C poses any problem, unless
the people writing the
code don't have the faintest clue about basic data structures.

The point is not having to bother with these details (together with all
their clutter, and potential for bugs) especially with code that is being
revised over and over again.

I don't see how C stops anyone from "dealing with entire arrays at once".

By having to deal with an element at a time?

That doesn't make sense. If you don't know what data types you are using
then how do you know how
your margin of error is propagating?

Typically such a language will use the most accurate type for floating
point. But you don't have to tell it what to use, and it's possible also to
have lists of mixed numeric types.

These two points are silly, as they constitute nothing more than "I don't
like this particular
syntax".

For someone who's a clumsy typist, there is just more opportunity for
mistyping. Again, for code that is being revised every few seconds, a lot of
time is wasted dotting i's and crossing t's there will never make it to the
final version.

Those points were either non-issues or potential sources of problems.



And a whole lot of work must be done before this becomes a non-issue.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=gcc

You've chosen an extreme example. There are languages that are not quite 300
times slower than C, and yet offer rapid development.

Anyway it's also possible to use such a language to develop an algorithm
(trying perhaps dozens of approaches), then to write the final version in C.

 

[Tim Streater]

Typically such a language will use the most accurate type for floating
point. But you don't have to tell it what to use, and it's possible also to
have lists of mixed numeric types.

The fact that it's the "most accurate" may not help. If you're doing
long numerical calculations you may well want to say "use this data
type" so you can have some idea of the accuracy of the result.

For someone who's a clumsy typist, there is just more opportunity for
mistyping. Again, for code that is being revised every few seconds, a lot of
time is wasted dotting i's and crossing t's there will never make it to the
final version.

I thought a lot of this code was *not* being frequently revised, that
was the point.

 

[Tim Harig]

The point is not having to bother with these details (together with all
their clutter, and potential for bugs) especially with code that is being
revised over and over again.

Also note that simple dynamic structures are built into the language
itself. While these kind of convienient structures are available through
abstraction in languages such as C, you either have to implement them
yourself, you have to embed a library inside your application (which
may not be possible because of license issues, etc), or you have to add
a dependency to your application.

Typically such a language will use the most accurate type for floating
point. But you don't have to tell it what to use, and it's possible also to
have lists of mixed numeric types.

In most cases, it *is* possible in dynamic languages to typecast your
variables if you choose to do so. Most dynamic languages don't completely
remove typing, they just make typing more implicit.

If you are dealing with applications where a knowledge of accuracy is
important, you will likely be using a module like the python "decimal"
module where it is possible to make more natural (arbitray decimal based)
approximations then it is using a fixed binary type.

Furthermore, when using modules like the above, the approximations are more
consistant between architectures.

You've chosen an extreme example. There are languages that are not quite 300
times slower than C, and yet offer rapid development.

Anyway it's also possible to use such a language to develop an algorithm
(trying perhaps dozens of approaches), then to write the final version in C.

Note that may dynamic languages have ways to implement some functionality
in C. This means that you can have most of the advantages of the dynamic
languages while optimizing the most performance sensitive parts in a
faster lower language. It is even possible to rapidly prototype an
algorithm in the dynamic language and then slowly convert sections of it at
a time to the faster lower level language. So you quickly get a working
algoritm that you can use today while moving towards a fully C fully
optimized algorithm down the road.

Static compiled and interpreted dynamic languages both have their place as
they serve different purposes and work together to meet common goals.