C in Science and Engineering...
chutsu
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?
Fire Crow
[snip]
>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
> 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
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
> 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
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
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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
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
"Rui Maciel" <rui.m...@gmail.com> wrote in message
news:4c0a3c77$0$3337$a729...@news.telepac.pt...
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.
--
Bartc
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
> "Rui Maciel" <rui.m...@gmail.com> wrote in message
> news:4c0a3c77$0$3337$a729...@news.telepac.pt...
<snip: about scientific computing>
>> 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....
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>
--
Ben.
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
cwi...@chromatico.net
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.
Richard Heathfield
> bart.c wrote:
>
>> 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.
You see, that's the problem right there. :-)
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Moi
>>>>>> "RM" == Rui Maciel <rui.m...@gmail.com> writes:
>
> 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
> bart.c wrote:
>
>> 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.
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.
>> being able to deal with entire arrays at once,
>
> 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?
>> 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?
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.
>
>> 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".
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.
>> 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
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.
--
Bartc
bart.c
> bart.c wrote:
>
>> 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.
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.
>> being able to deal with entire arrays at once,
>
> 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?
>> 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?
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.
>
>> 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".
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.
>> 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
You've chosen an extreme example. There are languages that are not quite 300
Geoff
>On 2010-06-05, Rui Maciel <rui.m...@gmail.com> wrote:
>> 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
Aren't Ruby and perl written in C?
Isn't CATIA an engineering application? It's written in C++.
Tim Harig
>
> "Rui Maciel" <rui.m...@gmail.com> wrote in message
> news:4c0a5511$0$3347$a729...@news.telepac.pt...
>> bart.c wrote:
>>
>>> 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.
>
> 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.
>> 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.
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.
>> 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
>
> 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.
Seebs
> 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.
A couple of points:
1. 8% is not a reasonable estimate. My experience is it's usually a factor
of two or three, although that can vary widely between scripted languages.
2. Back in the day, one of the posters here, whose name I've forgotten
(Tanmoy, last name started with a B?), pointed something out, in a debate
between C and Ada users. It was to the effect of (paraphrased):
I pay for computer time, and I am paid for programming time. If
I spend twelve months writing something that will complete execution
in five months, that is better than if I spend ten months writing
something that will complete execution in six months.
Consider the case of tasks being run on supercomputers. There was a press
release a while back about some people who were building a supercomputer
cluster based on the Cell microprocessor. The *power savings* of running
the more-efficient CPU instead of a conventional CPU were in the millions
of dollars. At that point, a 10% reduction in processing time to complete
a task could be enough to pay for a couple of years' development effort...
Also, I should point out: It is not at all impossible for scripted languages
to crash due to crazy bugs. I found a beautiful and very hard to reproduce
bug in the Ruby<->PostgreSQL bindings once, the net result of which was that
you could VERY occasionally get data corruption under circumstances where
you bound a large number of variables into a query and at least a few of
them were not strings to begin with, but objects of other sorts which had a
possible string representation. You may rest assured, this was harder to
debug in Ruby than it would have been in C...
Charlton Wilbur
S> 1. 8% is not a reasonable estimate. My experience is it's
S> usually a factor of two or three, although that can vary widely
S> between scripted languages.
Perl has the overhead of having to be compiled each time it is run. For
short scripts on trivial data, you might be looking at 100% to 200%
overhead. The longer the processing time, the less the overhead of
compilation matters.
My experience is that once you factor out that cost of compilation,
idiomatic Perl rarely takes more than 10% more overhead than idiomatic C.
S> Also, I should point out: It is not at all impossible for
S> scripted languages to crash due to crazy bugs. I found a
S> beautiful and very hard to reproduce bug in the Ruby<->PostgreSQL
S> bindings once, the net result of which was that you could VERY
S> occasionally get data corruption under circumstances where you
S> bound a large number of variables into a query and at least a few
S> of them were not strings to begin with, but objects of other
S> sorts which had a possible string representation. You may rest
S> assured, this was harder to debug in Ruby than it would have been
S> in C...
Of course. But how many bugs were avoided entirely by using Ruby rather
than C in the first place?
Charlton Wilbur
>> 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.
M> If the file fits into memory, I would probably mmap() it. If
M> mmap() is not available, there is the possibility of malloc()ing
M> one big array, read the entire file into it, and then do the
M> parsing and processing.
Why should a scientist *care* about the details of implementation on
that level? You're just offering more potential failure cases that
result from programmer error, and generally scientists are *not*
programmers.
jacob navia
>
> Of course. But how many bugs were avoided entirely by using Ruby rather
> than C in the first place?
>
None.
A programming language doesn't avoid bugs. Mistakes can be done
in any programming language.
malloc/free bugs?
Use a GC in C.
Zero terminated strings problems?
Use a counted string library.
Etc.
C is as good as anything else, and remember:
Ruby is written in C.
jacob navia
(1) If a scientist starts programming he/she is a programmer.
(2) The allocation errors and low level accounting can be avoided
completely using a garbage collector in C. You are not forced to use
malloc/free.
You are just spreading nonsense, as always. You do not like C. OK.
It is your "choice", but please take into account the facts.
Richard Heathfield
> Charlton Wilbur a écrit :
<stuff>
> You are just spreading nonsense, as always. You do not like C. OK.
> It is your "choice", but please take into account the facts.
With regard to the point under discussion, I do not agree with Charlton
Wilbur. But I cannot agree that he is "spreading nonsense, as always". I
recognise his name, which makes him a reasonably regular contributor to
this newsgroup (and/or possibly comp.programming - I haven't checked),
and I have read a reasonable number of his articles. If he were in the
habit of spreading nonsense, I'm pretty sure I'd have noticed.
You would have much more credibility in this newsgroup if you spent more
time arguing the issues and less time trying to ridicule your
opposition. You are a pretty good programmer by all accounts, but you
are not good at ridicule. Play to your strengths. If he's wrong, *show*
him he's wrong, using logic. Don't try to mock him. It doesn't work.
(Mocking can work just fine with genuine refusenik idiots. But he isn't
one.)
Charlton Wilbur
JN> A programming language doesn't avoid bugs. Mistakes can be done
JN> in any programming language.
JN> malloc/free bugs?
JN> Use a GC in C.
JN> Zero terminated strings problems?
JN> Use a counted string library.
What is so magical about C that means that it's preferable to use a
custom string library, a custom hash/map/dictionary library, a custom
counted string library, a custom regular expression library, and
probably a half-dozen other custom libraries than to use a language
that's better suited to the problem?
Charlton Wilbur
JN> (2) The allocation errors and low level accounting can be
JN> avoided completely using a garbage collector in C. You are not
JN> forced to use malloc/free.
The allocation errors and low level accounting can *also* be avoided
completely by using a language with dynamic memory management. You are
not forced to use C any more than you are forced to use malloc/free.
JN> You are just spreading nonsense, as always. You do not like
JN> C. OK. It is your "choice", but please take into account the
JN> facts.
Actually, no, I like C a great deal. I just don't think it's the
perfect language for all problems and all situations, because I *do*
take the facts into account. Your view of C being the perfect universal
language is, as far as I'm concerned, the nonsense that's being spread.
Rui Maciel
> Perl has the overhead of having to be compiled each time it is run. For
> short scripts on trivial data, you might be looking at 100% to 200%
> overhead. The longer the processing time, the less the overhead of
> compilation matters.
>
> My experience is that once you factor out that cost of compilation,
> idiomatic Perl rarely takes more than 10% more overhead than idiomatic C.
Can you provide any objective, tangible proof of that?
> Of course. But how many bugs were avoided entirely by using Ruby rather
> than C in the first place?
On the other hand, how many bank robberies were avoided entirely by using C rather than Ruby?
Rui Maciel
Rui Maciel
> 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),
I don't see how this can be seen as the C way of doing a list. You will be hard-pressed to find a
language/library that provides dynamic arrays that doesn't do that, either "under the hood" or
explicitly.
> or I have to handle dynamic
> allocation and keep track of pointers.
Linked lists are terribly basic data structures that don't pose any challenge to anyone remotely
invested in writing software.
> In Perl, Python, or Ruby, I just
> make a list, and the language worries about dynamic memory allocation.
And what leads you to believe that you are forced to "worry about dynamic memory allocation" with
C? If you opt to use a library that, as those interpreted languages do, pushes those details
under the hood then you can also claim that in C you don't have to "worry about" that. It's just
a matter of choosing what component you wish to use. What forces you to write everything from
scratch if you happen to write something in C?
> 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.
Based on this example, this isn't quite true. If the perceived problem regarding C is the
apparent lack of generic data structures then all you need to do is pick up one of the countless C
libraries providing generic data structures. Yet, I don't see what's so frightening about writing
a linked list.
> Dictionaries,
> hashes, or maps - whatever they're called in your local dialect.
> Regular expressions and data parsing. String manipulation.
You mean, stuff like this?
http://library.gnome.org/devel/glib/2.24/
> 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?
It depends, really. If the language you need to parse is a well established language then chances
are someone already wrote a parser for it. In that case, a half dozen LoC would suffice,
including the code to open the file. On the other hand, if it's some sort of custom language
which no one has any real clue about what the language's production may look like then it would
need a bit of work, whether you are using C or any other language.
In essence, it appears that your criticism is directed towards what libraries/routines are
accessible on a specific language and not the language itself.
> I can accomplish it with one line of Perl. An inexperienced Perl
> programmer can probably do it in less than two dozen.
Perl's conciseness isn't exactly seen as a feature. In fact, it's one of those things that is
constantly pointed out as a defect instead of a quality. People don't refer to Perl as a "write
once, read never language" for nothing.
> 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.
You would have a point if we were talking about a 8% performance drop. Yet, with Perl, at best,
we are taking about a 2x performance penalty and, at worse, a 198x performance penalty. That
performance penalty isn't easily sold to anyone who needs to run demanding applications whose run
time is measured in hours instead of seconds.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=perl&lang2=gcc
> 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.
And would your reaction be if you were able to go from those 48-hour runs to some other run time
between 24h and less than 2 minutes just by picking up the right language for the job?
Rui Maciel
bart.c
"jacob navia" <ja...@spamsink.net> wrote in message
news:hue76m$kg2$1...@speranza.aioe.org...
> Charlton Wilbur a écrit :
>>
>> Of course. But how many bugs were avoided entirely by using Ruby rather
>> than C in the first place?
>>
>
> None.
>
> A programming language doesn't avoid bugs. Mistakes can be done
> in any programming language.
>
> malloc/free bugs?
>
> Use a GC in C.
Which takes care of half of it.
> Zero terminated strings problems?
>
> Use a counted string library.
>
> Etc.
>
> C is as good as anything else, and remember:
>
> Ruby is written in C.
One program written in C, and thousands in the easy language.
Versus thousands in C, which *is* more error-prone, so requires more skills
from programmers who might be more interested in getting their tasks
accomplished quickly and painlessly.
--
Bartc
Rui Maciel
> M> If the file fits into memory, I would probably mmap() it. If
> M> mmap() is not available, there is the possibility of malloc()ing
> M> one big array, read the entire file into it, and then do the
> M> parsing and processing.
>
> Why should a scientist *care* about the details of implementation on
> that level? You're just offering more potential failure cases that
> result from programmer error, and generally scientists are *not*
> programmers.
Then again, scientists don't tend to be dumb slobs. Quite the opposite, actually. And they do tend
to pay attention to details. In fact, in essence that's what a scientist does for a living.
Rui Maciel
Rui Maciel
> What is so magical about C that means that it's preferable to use a
> custom string library, a custom hash/map/dictionary library, a custom
> counted string library, a custom regular expression library, and
> probably a half-dozen other custom libraries than to use a language
> that's better suited to the problem?
I don't know what's so special about C. Yet, following that point of view, Perl and Ruby must be
terribly magical, as their communities felt the pressing need to build specialized repositories
dedicated to this sort of stuff. Have you ever heard of CPAN and rubyforge?
Rui Maciel
chutsu
I think I've started a flame war. Getting back to the point, me as a
undergrad physicist I understand (or try to) that there are many tools
for the job, but when I look at stuff available on the internet, being
the "New Generation" we tend to like newer things like scripting
languages such as Python and Ruby. My reason for posting the question
was to to see whether C will cease to be used in future, and to
determine the "General Language" scientists and engineers alike use.
Obviously one cannot predict the future, and I accept that. From what
I have learnt through scanning through the replies is that Fortran is
used. However I personally don't like Fortran all that much, because:
1.) Its seems only old men aged 40~50+ use them
2.) Its not very widely used in anything else other than science
3.) GNU seems to only have a compiler for the Fortran 95 dialect (am I
right?)
4.) Fortran keeps changing, trying to be something its not by adding
Object Oriented features...
Note, I think the last point is quiet important, because when thinking
in the long term, when one creates a piece of code, I would like to
keep it for a loooonnnnggg time. I want to be able to write reusable
code, so 10-20 years down the line I'll still be able to use functions
or libraries I've created. Scripting languages, like python and ruby
change so much that they aren't backwards compatible. Like in Python
3000, or ruby 1.8 to 1.9. One has to change their old code to work
with the new, but really*? How stupid is that?
Some times I wish there was a decent scripting language, mature, and
stable. That doesn't change every 10 or 5 years...
Chris Choi
Seebs
> short scripts on trivial data, you might be looking at 100% to 200%
> overhead. The longer the processing time, the less the overhead of
> compilation matters.
> My experience is that once you factor out that cost of compilation,
> idiomatic Perl rarely takes more than 10% more overhead than idiomatic C.
Interesting. I guess it depends a lot on various factors. For instance,
multi-layered loops tend to be very expensive, while string operations are
usually not noticably more expensive in perl than in C. For mathematical
operations, though, I would expect to see a pretty significant cost to
the bytecode interpreter.
> Of course. But how many bugs were avoided entirely by using Ruby rather
> than C in the first place?
I don't know.
Seebs
> completely by using a language with dynamic memory management. You are
> not forced to use C any more than you are forced to use malloc/free.
I have one program in my collection for which I feel genuinely comfortable
saying that I am forced to use C. One. Everything else I've done in C
has been done because I was comfortable with C, or because I had reason
to believe that the overhead of a scripted language would be unacceptable,
or because I felt C mapped nicely onto the problem space.
But it is *possible* to find yourself "forced" to use C -- in that it would
be unreasonable to use anything else. For the example in question, have
a look at the program "pseudo", hosted at:
http://github.com/wrpseudo/pseudo
It's not a portable program by any means, but I genuinely feel that there was
no reasonable alternative to writing it in C. :)
Charlton Wilbur
RM> Linked lists are terribly basic data structures that don't pose
RM> any challenge to anyone remotely invested in writing software.
But most of the people involved in scientific computation are *not*
interested in writing software. They're interested in getting the
answer to a complex question that involves significant computation.
RM> And would your reaction be if you were able to go from those
RM> 48-hour runs to some other run time between 24h and less than 2
RM> minutes just by picking up the right language for the job?
If you can actually cut the run time *in half*, and you don't double the
development time by doing so, then go for it.
That does not match anything I've ever observed in practice, but hey,
it's your fantasy.
jacob navia
You have a way of dicussing that is typical of people with no arguments.
(1) I said that the problems YOU mentioned about C memory allocation
can be avoided with a GC.
(2) YOU say that I think that "C is the perfect universal language".
I never said that. I just pointed out that you CAN avoid low level
accounting problems in memory management in C without any pain by
using a GC. From that sentence to go to "C is the perfect universal
language" is just BAD FAITH and putting words in other people's
mouth.
Get a clue man.
jacob navia
The advantage of C is its performance, its simplicity, its absence of
a preconceived and pre-imposed way of doing your computation.
C has been used in scientific computing since several decades and there
is a wealth of libraries ready to use. I mentioned a few, but there are
much important ones for scientific and technical applications.
jacob navia
> 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?
> programmer can probably do it in less than two dozen.
>
Exactly that is why perl is GREAT for throw away software.
You want a program that will do something, then be thrown away?
Use perl. In one incrempehensible line that will give good
result in perl 5.1.2 under RedHat 7.5 it will run perfectly.
You got perl 4.xx or perl 6.xx?
Bad luck
You want it to run under windows?
Bad luck.
Perl is write only software. Write it, use it once or twice,
then forget it...
Nobody will be able to debug it, or to understand it later.
jacob navia
> 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
>
>
Can you please tell me a public available bioinformatic
library in perl?
Thanks
Rui Maciel
>
> "Rui Maciel" <rui.m...@gmail.com> wrote in message
> news:4c0a5511$0$3347$a729...@news.telepac.pt...
>> bart.c wrote:
>>
>>> 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.
>
> 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.
Quite bluntly, if someone is unable to figure out how a linked list works and believes that it's a
source of "clutter", along with being a potential source of bugs, then if that person intends to
write a science/engineering... Well, let's say that handling a linked list is the least of his
problems.
>>> being able to deal with entire arrays at once,
>>
>> 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?
And why exactly do you believe you are forced to "deal with with an element at a time"?
>>> 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?
>
> 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 word "typically" also reads as "the user doesn't really know what's going on". There's a lot
of science invested in evaluating margin of errors involving FP operations, all of which is
rendered useless once that info (or, better yet, the control over that parameter) is taken away
from you. And what good is your calculation for if you don't have a way to know how far off it
may be?
> 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.
Quite bluntly, this is a terrible excuse. If you can't even manage to type what you mean then
what makes you believe that your program is working right, let alone as you expected it to work?
>>> 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
>
> You've chosen an extreme example. There are languages that are not quite
> 300 times slower than C, and yet offer rapid development.
How exactly is this an "extreme example"? It's an objective benchmark which provides a
quantitative comparison of a set of parameters which can't simply be ignored.
Moreover, we aren't discussing general purpose applications, where the most demanding part of the
program is how fast it can repaint a button. We are discussing an application domain where
performance is king, where people spend a lot of money on high-end systems to be able to crunch
numbers a tidbit faster than before. In some cases people even pay good money to run their
programs on specific computers, a service which comes with a price tag which is proportional to
the amount of time it takes for the program to run.
> 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.
It's also possible to develop algorithms with pen an paper. That doesn't mean that we should
suddenly drop C in favor of a bic pen and a notepad.
Rui Maciel
Rui Maciel
> RM> Linked lists are terribly basic data structures that don't pose
> RM> any challenge to anyone remotely invested in writing software.
>
> But most of the people involved in scientific computation are *not*
> interested in writing software. They're interested in getting the
> answer to a complex question that involves significant computation.
That doesn't make any sense. Are you actually claiming that people whose living consists of
writing software are not interested in writing software?
> RM> And would your reaction be if you were able to go from those
> RM> 48-hour runs to some other run time between 24h and less than 2
> RM> minutes just by picking up the right language for the job?
>
> If you can actually cut the run time *in half*, and you don't double the
> development time by doing so, then go for it.
>
> That does not match anything I've ever observed in practice, but hey,
> it's your fantasy.
I don't deal with fantasies. I deal with measurable, objective results. What's great about this
is that you simply can't contradict a fact with vague, subjective claims about some anecdotal
observation that no one can be sure you even made, let alone if they are remotely close to being
true.
Rui Maciel
Rui Maciel
> Me neither. Most of the people I know in scientific computing are using
> Perl to do their bioinformatics data crunching.
Looks like they did a terrible job with their choice, as the performance hit goes a bit beyond 8%
http://www.bioinformatics.org/benchmark/results.html
Rui Maciel
jacob navia
Please do not disturb Mr Wilbur with FACTS. As everybody knows, FACTS
are just unimportant. Much more important is to avoid C.
Those benchmark tell the whole story. In some of them perl is 400 times
slower than C. This means a calculation that takes a minute in C, will
take 400 minutes (more than 6 hours) in perl!
Obviously waiting more than 6 hours is OK...
jacob navia
> I don't deal with fantasies. I deal with measurable, objective results. What's great about this
> is that you simply can't contradict a fact with vague, subjective claims about some anecdotal
> observation that no one can be sure you even made, let alone if they are remotely close to being
> true.
>
Facts are stubborn.
Thanks for reporting them here.
Jens Thoms Toerring
> I think I've started a flame war.
Looks like you managed to do that;-)
> Getting back to the point, me as a
> undergrad physicist I understand (or try to) that there are many tools
> for the job, but when I look at stuff available on the internet, being
> the "New Generation" we tend to like newer things like scripting
> languages such as Python and Ruby. My reason for posting the question
> was to to see whether C will cease to be used in future, and to
> determine the "General Language" scientists and engineers alike use.
Perhaps you should clarify what you mean with "scientific pro-
gramming". There are at least four domains I can think of
a) not too complicated data manipulation of experimental data
b) not too complicated modelling
c) heavy number crunching applications
d) controlling the hardware for an experiment
Note that the "not too complicated" bit in a) and b) obviously
depends on time - things that were considered "heavy number
crunching" 15 years ago now are easily done on a slow desktop
machine. I once had to resort to writing an integer based FFT
in assembler back then because it was too slow even in C, but
with a not too ancient machine you can do the same nowadays
much faster in an interpeted scripting language...
For a) and b) I would guess that "scripting languages" can be
used quite successfully, especially if there are plug-ins (or
how you want to call it) for a lot of the functionality needed
(I guess the success of MATLAB etc. is due to so many "toolboxes"
being available). If you want to simulate global weather patterns
I guess nobody would use Python or Ruby etc., you will typically
find that stuff is written in FORTRAN, C or C++, especially due
to the availability of very well-tested libraries. And for con-
trolling the experiment's hardware a lot of the programs will be
written in C or C++ or in the equivalent of a "scripting language",
LabView. (And, of course, that again depends on the size of the
experiment, a "simple" spectrometer is quite a different beast
from e.g. an electron synchrotron).
> Obviously one cannot predict the future, and I accept that. From what
> I have learnt through scanning through the replies is that Fortran is
> used. However I personally don't like Fortran all that much, because:
> 1.) Its seems only old men aged 40~50+ use them
Do you have a problem with people in that age bracket?;-) I can
assure you that being 50 instead of 25 doesn't make that much of
a difference - the change from 15 to 25 is a lot bigger. All
you gain (hopefully) is a bit of experience in not falling for
the latest hype anymore since you have seen that too many times;-)
> 2.) Its not very widely used in anything else other than science
Since you're asking about programming in science explicitely I do
not see your point.
> 3.) GNU seems to only have a compiler for the Fortran 95 dialect (am I
> right?)
> 4.) Fortran keeps changing, trying to be something its not by adding
> Object Oriented features...
The last time I had to compile a rather complex FORTRAN 77 program
with gcc I didn't experience too many problems (but that was, ad-
mittedly, a few years ago)...
> Note, I think the last point is quiet important, because when thinking
> in the long term, when one creates a piece of code, I would like to
> keep it for a loooonnnnggg time. I want to be able to write reusable
> code, so 10-20 years down the line I'll still be able to use functions
> or libraries I've created. Scripting languages, like python and ruby
> change so much that they aren't backwards compatible. Like in Python
> 3000, or ruby 1.8 to 1.9. One has to change their old code to work
> with the new, but really*? How stupid is that?
Ok, what kind of stuff do you want to write? If it's not too
complicated data manipulation nobody (not even you) will care
in 20 years - there will be a lot better methods then. If I
need to do something that I wrote a program for 15 years ago
I nearly never try to use what I did back then without modi-
fications - I normally will have a look at how I did it but not
just copy and paste it, that hardly ever looks feasible (and I
don't really trust stuff I wrote 15 years ago - one of the (few)
good things of becoming older is learning to avoid some of the
mistakes one made before;-)
If it's real heavy number crunching then you probably won't write
it all on your own as an undergraduate. You will most likely have
to use what others with a bit more of experience picked for the
project.
And if you're into hardware control then a scripting language
may not give you enough freedom to do what needs to be done.
Or you may pick a "mixed approach" - write the bits that need
low-level access to hardware in C and use that in a wrapper
written in a scripting language.
> Some times I wish there was a decent scripting language, mature,
> and stable. That doesn't change every 10 or 5 years...
MATLAB (and Octave) and Perl look most like what you're asking
here. And they have lot of useful libraries. Python and Ruby
are the "new kids on the block" and when they mature for this
problem domain they may become very interesting contenders. If
you like Python or Ruby you personally could make a difference
by writing good libraries/modules for them and thus help adop-
tion in the science community;-) Just don't expect any language
to become the "silver bullet", that won't happen.
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
bart.c
> bart.c wrote:
>> "Rui Maciel" <rui.m...@gmail.com> wrote in message
>> news:4c0a5511$0$3347$a729...@news.telepac.pt...
>>> 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.
>
> Quite bluntly, if someone is unable to figure out how a linked list works
> and believes that it's a
> source of "clutter", along with being a potential source of bugs, then if
> that person intends to
> write a science/engineering... Well, let's say that handling a linked
> list is the least of his
> problems.
I was talking of the problems of managing flexible, random-access arrays. I
like to be able to write:
a &:= x
or some such syntax, to append an element to array 'a', and worry *only*
about what I want to do with this data, rather than the inherent memory
management problems
>>> 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?
>
> And why exactly do you believe you are forced to "deal with with an
> element at a time"?
You must know something about C that I don't then.
>> 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 word "typically" also reads as "the user doesn't really know what's
> going on". There's a lot
> of science invested in evaluating margin of errors involving FP
> operations, all of which is
> rendered useless once that info (or, better yet, the control over that
> parameter) is taken away
> from you. And what good is your calculation for if you don't have a way
> to know how far off it
> may be?
The chances are the floating-point format will be 64-bits; there are not so
many alternatives.
>> For someone who's a clumsy typist, there is just more opportunity for
>> mistyping.
> Quite bluntly, this is a terrible excuse. If you can't even manage to
> type what you mean then
> what makes you believe that your program is working right, let alone as
> you expected it to work?
Nevertheless, C is fiddlier to type compared with 'easier' languages not
based on the same syntax:
for (int i=1; i<=n; +=i) /* common typo left in */
for i:=1 to n do
14 tokens vs. 7 (and half the time the latter can be written as 'to n do').
(Notice also the 'i' in the C-version appears 3 times; how many times have I
written that third one especially as j or n instead...)
>
>>>> There are all sorts of efforts underway to get these languages faster
>>> 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.
>
> How exactly is this an "extreme example"? It's an objective benchmark
> which provides a
> quantitative comparison of a set of parameters which can't simply be
> ignored.
You've chosen Ruby which is quite slow anyway. Python is faster and some
special versions of it I understand are very fast. There's also LuaJIT which
appeared to rival C for speed. Functional languages have been mentioned too
(although they are not for me).
I've also had a go myself; my last interpreted language was 4-5x slower than
C in floating point benchmarks, and I'm now working on a compiled version
that retains it's rapid development features.
> Moreover, we aren't discussing general purpose applications, where the
> most demanding part of the
> program is how fast it can repaint a button. We are discussing an
> application domain where
> performance is king, where people spend a lot of money on high-end systems
> to be able to crunch
> numbers a tidbit faster than before.
One approach is to use the fastest possible language to implement the
essential part of a calculation, then use something like a scripting
language to glue everything together and perhaps provide a user-interface.
Using C for everything is silly.
>> 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.
>
> It's also possible to develop algorithms with pen an paper.
It's not so easy to try them out however and find out they don't work.
--
Bartc
Seebs
> That doesn't make any sense. Are you actually claiming that people whose living consists of
> writing software are not interested in writing software?
Seems likely to me. Software is a tool for getting a job done. Sometimes,
if you can't get cost-effective rates on having someone else write the
software you need, it may be reasonable for you to write it yourself, even
though writing software is not what you are actually trying to accomplish.
Ben Bacarisse
> Rui Maciel a écrit :
>> Charlton Wilbur wrote:
>>
>>> Me neither. Most of the people I know in scientific computing are using
>>> Perl to do their bioinformatics data crunching.
>>
>> Looks like they did a terrible job with their choice, as the performance hit goes a bit beyond 8%
>>
>> http://www.bioinformatics.org/benchmark/results.html
>>
>>
>> Rui Maciel
>
> Please do not disturb Mr Wilbur with FACTS. As everybody knows, FACTS
> are just unimportant. Much more important is to avoid C.
Unfortunately the link to the source code did not work for me so it's
hard to check the details. If anyone gets it to work, please post.
> Those benchmark tell the whole story. In some of them perl is 400 times
> slower than C. This means a calculation that takes a minute in C, will
> take 400 minutes (more than 6 hours) in perl!
>
> Obviously waiting more than 6 hours is OK...
The author's software page lists six items. Two use Java and four use
Perl. It would be interesting to find out why he did not use C for any
of them.
--
Ben.
Charlton Wilbur
RM> Charlton Wilbur wrote:
>> But most of the people involved in scientific computation are
>> *not* interested in writing software. They're interested in
>> getting the answer to a complex question that involves
>> significant computation.
RM> That doesn't make any sense. Are you actually claiming that
RM> people whose living consists of writing software are not
RM> interested in writing software?
No. I'm claiming that people whose living consists of finding the
answers to complex and subtle questions are interested in doing that;
they only write software because that is how they find the answers to
those complex and subtle questions.
Charlton Wilbur
S> Interesting. I guess it depends a lot on various factors. For
S> instance, multi-layered loops tend to be very expensive, while
S> string operations are usually not noticably more expensive in
S> perl than in C. For mathematical operations, though, I would
S> expect to see a pretty significant cost to the bytecode
S> interpreter.
Also, the performance advantage of C goes away rather quickly if you're
bound by anything other than processor. If you're disk bound or I/O
bound -- or if you're waiting for human interaction -- it doesn't matter
whether the processor is pegged or is 95% idle.
>> Of course. But how many bugs were avoided entirely by using Ruby
>> rather than C in the first place?
S> I don't know.
That's the $64,000 question.
Charlton Wilbur
RH> You would have much more credibility in this newsgroup if you
RH> spent more time arguing the issues and less time trying to
RH> ridicule your opposition.
Don't worry - I've seen Jacob frothing at the mouth before, and I am
prepared to accord to him exactly as much credibility as he's earned.
Keith Thompson
[...]
> Exactly that is why perl is GREAT for throw away software.
>
> You want a program that will do something, then be thrown away?
>
> Use perl. In one incrempehensible line that will give good
> result in perl 5.1.2 under RedHat 7.5 it will run perfectly.
>
> You got perl 4.xx or perl 6.xx?
>
> Bad luck
>
> You want it to run under windows?
>
> Bad luck.
>
> Perl is write only software. Write it, use it once or twice,
> then forget it...
>
> Nobody will be able to debug it, or to understand it later.
This is wrong. If it were topical here, or if you were interested
in my opinion, I'd explain why.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
blm...@myrealbox.com
chutsu <chu...@gmail.com> wrote:
> On Jun 5, 8:17 pm, Charlton Wilbur <cwil...@chromatico.net> wrote:
> > >>>>> "JN" == jacob navia <ja...@spamsink.net> writes:
[ snip ]
> I think I've started a flame war.
You think? what, you thought you could raise the issue of this
language versus that one and *not* get a certain amount of heat? :-)
> Getting back to the point, me as a
> undergrad physicist I understand (or try to) that there are many tools
> for the job, but when I look at stuff available on the internet, being
> the "New Generation" we tend to like newer things like scripting
> languages such as Python and Ruby. My reason for posting the question
> was to to see whether C will cease to be used in future, and to
> determine the "General Language" scientists and engineers alike use.
>
> Obviously one cannot predict the future, and I accept that. From what
> I have learnt through scanning through the replies is that Fortran is
> used. However I personally don't like Fortran all that much, because:
> 1.) Its seems only old men aged 40~50+ use them
> 2.) Its not very widely used in anything else other than science
No comment about whether either of these points is true, but what if
they are?
> 3.) GNU seems to only have a compiler for the Fortran 95 dialect (am I
> right?)
No. The Fortran compiler that's part of gcc compiles Fortran 95 (and
Fortran 90), but it also compiles FORTRAN 77. Indeed, aside from
differences in source-code format (FORTRAN 77 is "fixed form", while
Fortran 90 and later can be "fixed form" or "free form"), as far as
I know a valid FORTRAN 77 program is also a valid Fortran 95 program.
> 4.) Fortran keeps changing, trying to be something its not by adding
> Object Oriented features...
It's true that the language continues to evolve, but one of the
reasons people like it, again as far as I know, is that it allows
them to (continue to) use library code developed over many decades.
Backward compatibility is a powerful force .... As you seem to agree:
> Note, I think the last point is quiet important, because when thinking
> in the long term, when one creates a piece of code, I would like to
> keep it for a loooonnnnggg time. I want to be able to write reusable
> code, so 10-20 years down the line I'll still be able to use functions
> or libraries I've created. Scripting languages, like python and ruby
> change so much that they aren't backwards compatible. Like in Python
> 3000, or ruby 1.8 to 1.9. One has to change their old code to work
> with the new, but really*? How stupid is that?
>
> Some times I wish there was a decent scripting language, mature, and
> stable. That doesn't change every 10 or 5 years...
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
bart.c
"Tim Streater" <timst...@waitrose.com> wrote in message
news:timstreater-2778...@news.individual.net...
> In article <0iAOn.83585$3B3.54703@hurricane>,
> "bart.c" <ba...@freeuk.com> wrote:
>> Nevertheless, C is fiddlier to type compared with 'easier' languages not
>> based on the same syntax:
>>
>> for (int i=1; i<=n; +=i) /* common typo left in */
>
> Is this going to compile, much less execute properly?
No; the += was an actual typo; I decided to leave it in.
The 'int i' I put in as a reminder that a declaration for i is also needed
(and declared externally, a bit more hassle).
>> for i:=1 to n do
>>
>> 14 tokens vs. 7 (and half the time the latter can be written as 'to n
>> do').
>> (Notice also the 'i' in the C-version appears 3 times; how many times
>> have I
>> written that third one especially as j or n instead...)
>
> Might be nice if a simple loop is all you want. What if you want
> something more complex?
90% of the time, a simple loop, with or without an index, is all that's
needed. For complex loops, the C version can work well (and I've included a
variation of it in one of my projects).
--
Bartc
chutsu
>
> > I think I've started a flame war.
>
> You think? what, you thought you could raise the issue of this
> language versus that one and *not* get a certain amount of heat? :-)
well I never really did raise the issue of C itself but the
applications of it. I was sort of expecting, YES, or NO to see if C is
being used in science. I stated with the rise of scripting languages
(Python, Ruby), does one still use compiled languages such as C to do
scientific analysis. But I guess it kinda got haywire...
Nick Keighley
> Charlton Wilbur a écrit :
> > I mean, here's a task. [...] 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.
>
> Exactly that is why perl is GREAT for throw away software.
you can write readable perl. You can write maintainable perl.
> You want a program that will do something, then be thrown away?
>
> Use perl. In one incrempehensible line that will give good
> result in perl 5.1.2 under RedHat 7.5 it will run perfectly.
>
> You got perl 4.xx or perl 6.xx?
>
> Bad luck
you might have a point here. I remember C++ going through a phase a
bit like that.
> You want it to run under windows?
>
> Bad luck.
perl runs under Windows. In fact that's one of its attractions to me.
It's a portable script language.
> Perl is write only software. Write it, use it once or twice,
> then forget it...
>
> Nobody will be able to debug it, or to understand it later.
this isn't actually true. Or needn't be true
Charlton Wilbur
NK> On 5 June, 21:44, jacob navia <ja...@spamsink.net> wrote:
>> Exactly that is why perl is GREAT for throw away software.
NK> you can write readable perl. You can write maintainable perl.
I think the project that currently pays for my salary, which is about
500,000 lines of readable, maintainable Perl, and which generates an
amount of revenue measured in the hundreds of millions of dollars, is
proof of that.
Of course, the company *also* uses C++ for a Windows-specific client,
database code in our database engine's quirky stored procedure language,
and Python for a configuration and system administration language.
They've also tried a Java pilot project, but that hasn't gone so well.
>> Use perl. In one incrempehensible line that will give good result
>> in perl 5.1.2 under RedHat 7.5 it will run perfectly.
>>
>> You got perl 4.xx or perl 6.xx?
>>
>> Bad luck
NK> you might have a point here. I remember C++ going through a
NK> phase a bit like that.
Perl is much like C in that regard. You can write Perl that runs only
on RedHat (and RedHat was in the habit for a long time of subtly
customizing their Perl builds), and that relies on bugs in particular
versions of the interpreter; but this is really no different than
writing C code that takes advantage of a particular compiler's
resolution of undefined behavior.
>> You want it to run under windows?
>>
>> Bad luck.
NK> perl runs under Windows. In fact that's one of its attractions
NK> to me. It's a portable script language.
In that it's *exactly* as portable as C is. If you write a Perl script
that uses Perl abstractions for I/O and interfacing with the system,
it's completely portable. If you insist on using platform-specific
features, well, surprise, they aren't portable to other platforms!
NK> this isn't actually true. Or needn't be true
Why should being *true* or *false* get in the way of anything Mr. Navia
chooses to believe?
Nick Keighley
> >>>>> "NK" == Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> NK> On 5 June, 21:44, jacob navia <ja...@spamsink.net> wrote:
JN > Perl is write only software. Write it, use it once or twice,
JN > then forget it...
JN > Nobody will be able to debug it, or to understand it later.
> NK> this isn't actually true. Or needn't be true
>
> Why should being *true* or *false* get in the way of anything Mr. Navia
> chooses to believe?
I was addressing the lurkers
Keith Thompson
[...]
> Perl is too full of regexes and funny symbols to be, in general,
> readable and understandable.
That's your opinion. (And yes, the fact that it was written over
your signature is sufficient to establish that, so
My point is that well-written Perl code can be perfectly
understandable *to someone who knows the language*.
Exactly the same thing is true of C.
C code can look like line noise to someone who doesn't know the
language. Deliberately obfuscated C can look like line noise even
to someone who does know the language. And yet, it's entirely
possible to write readable and maintainable C code, assuming the
target audience knows the language and its idioms reasonably well.
Substitute Perl for C in the preceding paragraph, and it's still
equally true. (I know both C and Perl reasonably well, and
I personally find them to be about equally readable.)
I'm not asking you to like Perl (if I were, this wouldn't be the
place for it), but please consider that the ugliness of *any*
language depends largely on the reader's familiarity with it.
Richard Bos
> Charlton Wilbur wrote:
>
> > But most of the people involved in scientific computation are *not*
> > interested in writing software. They're interested in getting the
> > answer to a complex question that involves significant computation.
>
> That doesn't make any sense. Are you actually claiming that people
> whose living consists of writing software are not interested in
> writing software?
In the same way that people who make a living writing articles for
scientific magazines are usually not that interested in language, yes.
They're interested in the scientific content, not in the medium through
which it is propagated.
Richard
Nick Keighley
> Perl is too full of regexes and funny symbols to be, in general,
> readable and understandable.
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?
jacob navia
> Don't worry - I've seen Jacob frothing at the mouth before, and I am
> prepared to accord to him exactly as much credibility as he's earned.
:-)
Thanks
Tom St Denis
> Perl is too full of regexes and funny symbols to be, in general,
> readable and understandable.
While I agree there is a lot of indecipherable perl out there, the
language does support whitespace and comments. I use it when I need
to script a test suite since I can mash around natural language
strings a lot easier than in C. The trick is to not turn your perl
programs into IOCCC-esque entries.
Tom
bart.c
> On Jun 6, 2:52 pm, Tim Streater <timstrea...@waitrose.com> wrote:
>> Perl is too full of regexes and funny symbols to be, in general,
>> readable and understandable.
>
> While I agree there is a lot of indecipherable perl out there, the
> language does support whitespace and comments. I use it when I need
> to script a test suite since I can mash around natural language
> strings a lot easier than in C.
Thats like the point I was trying to make, not very successfully.
Let's try turning it around: if these easy, dynamic languages were faster
than C, how many people would still be programming in it? Would there be any
point?
--
Bartc
Tim Harig
> Tom St Denis wrote:
>> On Jun 6, 2:52 pm, Tim Streater <timstrea...@waitrose.com> wrote:
>>> Perl is too full of regexes and funny symbols to be, in general,
>>> readable and understandable.
>>
>> While I agree there is a lot of indecipherable perl out there, the
>> language does support whitespace and comments. I use it when I need
>> to script a test suite since I can mash around natural language
>> strings a lot easier than in C.
I agree with this 100%. Any tool can be misused and abused. That said,
I have never been able to bring myself to like the language even though
I am fully aware of its power of expression; and that is from somebody
who is know to write quite a bit of awk. There is just something about
the language that tends to turn many of us off in a way not no other
language that I have encountered has managed. That isn't a functional
deficiency, it is a matter of personal taste. I am not too fond of C
code written in Hungarian notation either; but, I can understand why
some people might find it useful.
> Let's try turning it around: if these easy, dynamic languages were faster
> than C, how many people would still be programming in it? Would there be any
> point?
1. Most of the dynamic languages require interpretation (or at the very
least some kind of embedded runtime). Most of those interpreters
are written in C. There are just some things that *require*
low level language support. Even for higher level support,
most dynamic langauges still require wrappers to access basic
system level calls that are usually implemented as C interfaces.
Then again, there are always those who claim they can write an
operating system in these languages. I am always left to wonder
what is running the interperator that such an operating system
runs on.
2. Having the ability to organize and access memory directly through the
use of pointers and pointer arithmetic can lead to some very
powerful data structures that cannot as easily or expressively
be created using higher level constructs.
Nick Keighley
> Tom St Denis wrote:
> > On Jun 6, 2:52 pm, Tim Streater <timstrea...@waitrose.com> wrote:
> >> Perl is too full of regexes and funny symbols to be, in general,
> >> readable and understandable.
criticising Perl for being full of regexps is a bit like complaining
about the sea for having fish in it.
> > While I agree there is a lot of indecipherable perl out there, the
> > language does support whitespace and comments. I use it when I need
> > to script a test suite since I can mash around natural language
> > strings a lot easier than in C.
>
> Thats like the point I was trying to make, not very successfully.
>
> Let's try turning it around: if these easy, dynamic languages were faster
> than C, how many people would still be programming in it? Would there be any
> point?
C would still have wide availability, low level bit banging,
portability, and historical inertia on its side. Often the very things
that make these scripting languages cool is also what makes them slow.
Perl is also a bit of a conceptual mess
Default User
> chutsu wrote:
> 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++.
Depends on what you mean by "serious". I work in R&D for an aerospace
company. That means a lot of prototype, proof-of-concept work. The most
common languages are C++ and Java, with C still in the mix. I'm going to
have to do some work this time out with C#. At least one of our developers,
who's a hardware guy more than anything, likes Python. I haven't seen anyone
do much new development in Fortran in a long time.
Brian
Seebs
> than C, how many people would still be programming in it? Would there be any
> point?
A few, and yes there would -- device drivers, etc.
Richard Heathfield
> In article <timstreater-8BBF...@news.individual.net>,
> Tim Streater <timst...@waitrose.com> wrote:
>
>> I got off Pascal as soon as I possibly could, but I was disappointed by
>> some parts of C when I started to use it in about 1085.
>
> Oh, nice typo. Yes, I came over the C with WIlliam the Conqueror.
Yes, I always wondered what language the Domesday Book was written in.
Now I know.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
bart.c
> I've mentioned particle physicists and their concerns about floating
> point. This was always why they used FORTAN, historically; now they
> apparently use C++.
> These people have *serious* amounts of data. The company I last worked
> for was responsible for configuring, for CERN, some 15 or so 10Gbps
> circuits from CERN to individual physics labs around Europe. This is so
> the LHC data can be distributed for processing. At CERN itself there are
> farms of hundreds of PCs doing data analysis. Slow scripting languages
> are not going to cut it.
I'm sure scripting languages do form part of such projects (even if it's
just to schedule the programs proper rather than do the actual work).
I added scripting languages into my applications years ago. They made life
much, much easier (for example, by being able to develop modules while
actually running the application (no need to save data and settings, quit,
edit, compile, link, run, load the data again, create the same environment,
and eventually get back to the problem area if you haven't totally forgotten
what it was).
I reckoned if a scripted program was only between one and two times slower
than a compiled version (where the execution time was even significant),
then that was a sensible use of scripted over compiled.
And because this was a custom language, it knew about the sort of
calculations I was interested in (3D graphics), and had suitable datatypes
and operations ready made; multiplying two matrices was as simple as a=b*c
and about the same speed as compiled code.
I'm now interested in making such languages faster so they can take over
more tasks (with my stuff, I'm probably already at 75% (that will run no
slower than half the speed of compiled code, or is not significant), and
trying to push that to 100%).
Anyway, it's not just a question of choosing between C or C++, or Ruby at
300-400x slowdown (if you believe some people). The options are wider than
that.
>> C would still have wide availability, low level bit banging,
>> portability, and historical inertia on its side. Often the very things
>> that make these scripting languages cool is also what makes them slow.
>>
>> Perl is also a bit of a conceptual mess
$, @ and # everywhere put me off.
--
Bartc
Nick Keighley
> > the language does support whitespace and comments.
>
> I haven't yet found a switch I can set on the programmers, though, to
> make them use this feature.
Don't use a switch. Use a horse whip.
jacob navia
Instead of talking like this have you EVER reflected on
why comments are absent from throw-away software?
Perl scripts are used for "write once use twice" code. Everybody
knows that, and writing comments on such code is seen as a waste
of time.
But as always, perl scripts tend to be used far more than their
writers thought it would be possible.
Nick Keighley
> Nick Keighley a crit :
> > On 7 June, 21:15, Tim Streater <timstrea...@waitrose.com> wrote:
> >>> the language does support whitespace and comments.
> >> I haven't yet found a switch I can set on the programmers, though, to
> >> make them use this feature.
>
> > Don't use a switch. Use a horse whip.
>
> Instead of talking like this
it's like a joke
> have you EVER reflected on
> why comments are absent from throw-away software?
my throw-away code sometimes has comments. I tend to keep so-called
throw-away code in case I have to do something similar again.
> Perl scripts are used for "write once use twice" code.
> Everybody
> knows that, and writing comments on such code is seen as a waste
> of time.
>
> But as always, perl scripts tend to be used far more than their
> writers thought it would be possible.
quite substantial programs get written in Perl. Sometimes
intentionally. And sometimes with comments.
For instance:-
#!/opt/perl5/perl
# $Id: XXX.pl 253 2008-02-15 09:35:20Z XXX$
# This script file creates (or restores) the XXX database and
appropriate data files
# and logs all actions to $admin/XXXdirectory
#
# Usage: perl XXX.pl [-Q] [-I] [-V] [-CREATE | -CREATEINACTIVE | -
DELETE | -RESTORE [restorePath]] [-TEST]
#
# Command line options:
#
# -Q Quiet mode; STDOUT supressed. -Q is incompatible with -I
and -V.
#
# -I Interactive mode; some questions are asked to the user.
Note: even
# if -I is disabled, there are some questions that must be
asked to the user. -I
# and -Q are incompatible.
#
# -V Verbose mode. -V and -Q are incompatible.
#
# -NQ NO to QUERIES mode. If selected, the program automatically
assumes a 'NO' answer to
# each of the update requests. Only the database is updated
in this mode.
#
# -CREATE Create XXX database. Previous instance of the database (if
# exists) will be automatically deleted. (ignore errors
about stopping/starting
# services, that can be due to a previuos corrupted
configuration)
[and so on...]
the code itself was reasonably well commented as well
FredK
"jacob navia" <ja...@nospam.org> wrote in message
news:hul1s3$7bk$1...@speranza.aioe.org...
> Nick Keighley a �crit :
>> On 7 June, 21:15, Tim Streater <timstrea...@waitrose.com> wrote:
>>
>>>> the language does support whitespace and comments.
>>> I haven't yet found a switch I can set on the programmers, though, to
>>> make them use this feature.
>>
>> Don't use a switch. Use a horse whip.
>
> Instead of talking like this have you EVER reflected on
> why comments are absent from throw-away software?
>
Have you ever reflected on why comments are absent from a lot of C
*production* code? Ever read the Linux source? "We don't need no stinkin'
comments, the code is self documenting." is all I can figure. "Real men"
don't need comments.
After 30+ years of programming for a living, I long ago discovered that you
often can't predict the lifetime of code - even what at the time you thought
was "throw away" code. So I comment pretty much every piece of code I
write, since I expect at some random time down the road I'll need to re-use
it or will need to fix it.
Of course, there are good comments and bad comments. Good comments describe
why something is being done /* this loop derives the ... */ as opposed to
describing the obvious /* is j null? */
Nick Keighley
the Refactoring people (eg. Fowler) encourage the removal of comments.
The argument being that if you have to comment it then it should have
been a function with a name that matched the comment.
/* this loop derives the snafu context */
while (!snafu_value)
....
should be replaced with
derive_snafu context ();
I'm still thinking about this. I still want major chunks of code to
have comments that indicate what their intent is.
On the other hand I hate those code templates that demand a header
like this
/*
* Name: derive_snafu_context
*
* Arguments: none
*
* Return: none
*/
void derive_snafu context ()
{
}
that sort of stuff drives me mad.
Nick
> On 2010-06-05, Rui Maciel <rui.m...@gmail.com> wrote:
>> 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.
I think I would if I was starting again. Neither were widespread or
mature enough when I started my application. I need to use C or similar
for the core route-planning function (a big "shortest path" calculation)
and ended up developing from what was a configuration language around
this to a full scripting language.
Today I'd use Ruby or Python calling back to C for the clever stuff. It
wouldn't have been half as much fun to write though (is there anything
as much fun as writing a language?).
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
FredK
> In article
> <7f6fa240-c9d1-448f...@b35g2000yqi.googlegroups.com>,
> Nick Keighley <nick_keigh...@hotmail.com> wrote:
>
>> On 8 June, 15:24, "FredK" <fred.nos...@dec.com> wrote:
>
>> > Of course, there are good comments and bad comments. Good comments
>> > describe
>> > why something is being done /* this loop derives the ... */ as opposed
>> > to
>> > describing the obvious /* is j null? */
>>
>> the Refactoring people (eg. Fowler) encourage the removal of comments.
>> The argument being that if you have to comment it then it should have
>> been a function with a name that matched the comment.
>>
>> /* this loop derives the snafu context */
>> while (!snafu_value)
>> ....
>>
>> should be replaced with
>>
>> derive_snafu context ();
>>
>> I'm still thinking about this. I still want major chunks of code to
>> have comments that indicate what their intent is.
>
> comment *that*. What's the benefit?
>
>> On the other hand I hate those code templates that demand a header
>> like this
>>
>> /*
>> * Name: derive_snafu_context
>> *
>> * Arguments: none
>> *
>> * Return: none
>> */
>> void derive_snafu context ()
>> {
>> }
>>
>> that sort of stuff drives me mad.
>
>
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.
I comment for myself, knowing that after time passes - even I need to
re-remember why I did what I did.
jacob navia
>
> 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.
>
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.
For instance, I had to figure out what was GCC generating for C++
exceptions. There was NO documentation, and all you had is several
huge files without a single comment, not even a comment that describes
what the file is supposed to do. It took me several months of work
till I figured it out. For instance, one (uncommented) pitfall was that
the assembler did not assemble what you wrote in some cases.
It "optimized" your instructions, merging some data to save space.
It took me several days to figure that the assembler was the culprit...
and that it was OK that the generated code did NOT conform the DWARF
specs.
But I could figure it out eventually. Compare that to windows.
Under windows I didn't have the source code but I had an API
(documented!). You just call a function with a series of well
described tables and that was it. It took me only several days.
Conclusion:
It is better to have a documented API than a bunch of C source
code that you have to figure out!
jacob
Nick Keighley
> In article
> <7f6fa240-c9d1-448f-a595-277940d3b...@b35g2000yqi.googlegroups.com>,
> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>
>
>
>
>
> > On 8 June, 15:24, "FredK" <fred.nos...@dec.com> wrote:
> > > Of course, there are good comments and bad comments. Good comments describe
> > > why something is being done /* this loop derives the ... */ as opposed to
> > > describing the obvious /* is j null? */
>
> > the Refactoring people (eg. Fowler) encourage the removal of comments.
> > The argument being that if you have to comment it then it should have
> > been a function with a name that matched the comment.
>
> > /* this loop derives the snafu context */
> > while (!snafu_value)
> > ....
>
> > should be replaced with
>
> > derive_snafu context ();
>
> > I'm still thinking about this. I still want major chunks of code to
> > have comments that indicate what their intent is.
>
> comment *that*. What's the benefit?
>
> > like this
>
> > /*
> > * Name: derive_snafu_context
> > *
> > * Arguments: none
> > *
> > * Return: none
> > */
> > void derive_snafu context ()
> > {
> > }
>
> > that sort of stuff drives me mad.
>
it's not just the layout but the zero information content that makes
it ugly. If you can read C you can see what arguments it takes and
what type it returns
jacob navia
You are completely missing the point here. As in ALL COMMENTS, the thing to describe
there is not what type the arguments are, but what they MEAN.
You should NOT write:
argument "a" is an int
but
argument "a" is the number of hits since last checkin.
for instance.
Nick Keighley
> "Tim Streater" <timstrea...@waitrose.com> wrote in message
> news:timstreater-3F37...@news.individual.net...
> > In article
> > <7f6fa240-c9d1-448f-a595-277940d3b...@b35g2000yqi.googlegroups.com>,
> >> [...] I hate those code templates that demand a header
> >> like this
>
> >> /*
> >> * Name: derive_snafu_context
> >> *
> >> * Arguments: none
> >> *
> >> * Return: none
> >> */
> >> void derive_snafu context ()
> >> {
> >> }
>
> >> that sort of stuff drives me mad.
>
> > That's because this sort of template is ugly as sin.
>
> Perhaps ugly, but perhaps informative.
more often than not, not informative
> Especially when the template has an
> *abstract* explaining what a snafu context is and the approach taken to
> derive it.
you'll be amazed how many programmers don't know what "abstract"
means. My style would be to describe what a snafu context was, either
here or wherever its corresponding data structure was.
> 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.
I do try to comment what is not obvious. The refactoring people would
expect sane identifier names.
> I comment for myself, knowing that after time passes - even I need to
> re-remember why I did what I did.
I was only railing against information free comments. And the
refactoring people have a point that good choice of names can save you
some comments.
Nick Keighley
> Nick Keighley a crit :
> > On 8 June, 16:49, Tim Streater <timstrea...@waitrose.com> wrote:
> >> In article
> >> <7f6fa240-c9d1-448f-a595-277940d3b...@b35g2000yqi.googlegroups.com>,
> >> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> >>> On 8 June, 15:24, "FredK" <fred.nos...@dec.com> wrote:
> >>>> Of course, there are good comments and bad comments. Good comments describe
> >>>> why something is being done /* this loop derives the ... */ as opposed to
> >>>> describing the obvious /* is j null? */
> >>> the Refactoring people (eg. Fowler) encourage the removal of comments.
> >>> The argument being that if you have to comment it then it should have
> >>> been a function with a name that matched the comment.
> >>> /* this loop derives the snafu context */
> >>> while (!snafu_value)
> >>> ....
> >>> should be replaced with
> >>> derive_snafu context ();
> >>> I'm still thinking about this. I still want major chunks of code to
> >>> have comments that indicate what their intent is.
>
> >> OK, so you move all the code into derive_snafu_context() and then you
> >> comment *that*. What's the benefit?
you don't have a comment like the one I described... The whole point
is you end up with a bunch of tiny self evident functions.
> >>> On the other hand I hate those code templates that demand a header
> >>> like this
> >>> /*
> >>> * Name: derive_snafu_context
> >>> *
> >>> * Arguments: none
> >>> *
> >>> * Return: none
> >>> */
> >>> void derive_snafu context ()
> >>> {
> >>> }
> >>> that sort of stuff drives me mad.
> >> That's because this sort of template is ugly as sin.
>
> > it's not just the layout but the zero information content that makes
> > it ugly. If you can read C you can see what arguments it takes and
> > what type it returns
>
> You are completely missing the point here. As in ALL COMMENTS, the thing to
> describe there is not what type the arguments are, but what they MEAN.
no I am not missing the point. I see comments exactly as I'm
describing.
"teach not your mother's mother to extract the embryonic juices of the
bird by suction"
> You should NOT write:
>
> argument "a" is an int
>
> but
>
> argument "a" is the number of hits since last checkin.
>
> for instance.
or use a meaningful typename (bit hard in this case)
void gen_report (FILE *report, Hit_count hits)
Nick Keighley
strike one for closed source! Next time one of Stallman's acolytes
creeps up behind me a belts me with a rolled up copy of the Public
Virus I'll have another answer!
bart.c
>> That's because this sort of template is ugly as sin.
>
> it's not just the layout but the zero information content that makes
> it ugly. If you can read C you can see what arguments it takes and
> what type it returns
Types are often irrelevant. But sometimes a parameter or return value has
complex behaviour that can't expressed in an identifier, without making it
ridiculously long. And there might be interdependencies.
And sometimes there aren't any parameters, and there is no return value! The
name of the function can only express so much.
Most C sources I've looked at (for open source software), seem to be
completely devoid of comments, other than licensing text, list of authors,
and version numbers. As to what it actually does, nothing!
--
Bartc
Mark
>
> Perl scripts are used for "write once use twice" code. Everybody
> knows that, and writing comments on such code is seen as a waste
> of time.
>
> But as always, perl scripts tend to be used far more than their
> writers thought it would be possible.
It's possible to write reasonable Perl which is well-designed and
maintainable. While we use C a lot, sometimes Perl (or, shock horror,
Perl embedded in C or C embedded in Perl) or another language is
more appropriate.
We have good Perl which has done good service for us for over 10 years
now - and hasn't been significantly more trouble to maintain than our C,
Fortran or Python programs, and significantly less trouble than our C++.
Just because it's possible to write bad Perl (and it is), doesn't mean
it's impossible to write good Perl.
Of course: if all you have is a hammer, everything looks like a nail!
Nick Keighley
> Nick Keighley wrote:
> > On 8 June, 16:49, Tim Streater <timstrea...@waitrose.com> wrote:
> >> That's because this sort of [comment] template is ugly as sin.
>
> > it's not just the layout but the zero information content that makes
> > it ugly. If you can read C you can see what arguments it takes and
> > what type it returns
>
> Types are often irrelevant.
I'm not so sure they are. Well chosen types can make a lot of
difference. I sometimes find I can omit the parameter names in the
header file because it is quite clear what the function does without
them. (I believe people should have enough infomation to be able to
use my functions without having to read the C file)
> But sometimes a parameter or return value has
> complex behaviour that can't expressed in an identifier, without making it
> ridiculously long. And there might be interdependencies.
yes this can happen. I'm not a "write no comments!" kind of guy. It's
just that I want their SNR to be high rather than low.
> And sometimes there aren't any parameters, and there is no return value!
what the Agile people would call a "code smell"...
> The name of the function can only express so much.
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.
> Most C sources I've looked at (for open source software), seem to be
> completely devoid of comments, other than licensing text, list of authors,
> and version numbers. As to what it actually does, nothing!
not a style I like
--
And so when you think of the future,
imagine a Pentium stamping on a man's face,
forever.
Richard Bos
> >>>>> "JN" == jacob navia <ja...@spamsink.net> writes:
>
> JN> A programming language doesn't avoid bugs. Mistakes can be done
> JN> in any programming language.
>
> JN> malloc/free bugs?
>
> JN> Use a GC in C.
>
> JN> Zero terminated strings problems?
>
> JN> Use a counted string library.
>
> What is so magical about C that means that it's preferable to use a
> custom string library, a custom hash/map/dictionary library, a custom
> counted string library, a custom regular expression library, and
> probably a half-dozen other custom libraries than to use a language
> that's better suited to the problem?
The magic is not in C. The magic is in a _very specific implementation_
of C.
Richard
Malcolm McLean
wrote:
>
> 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.
>
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.