>> 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.
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?
>>>>> "RH" == Richard Heathfield <r...@see.sig.invalid> writes:
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.
> 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"
In article <338266f6-4431-42e5-9f2d-e0c8aa239...@g7g2000yqj.googlegroups.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.
> 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).
> 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...
On 5 June, 21:44, jacob navia <ja...@spamsink.net> wrote:
> 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.
>>>>> "NK" == Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
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?
On 6 June, 16:48, Charlton Wilbur <cwil...@chromatico.net> wrote:
> >>>>> "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?
> 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.
-- 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"
> > 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.
On 6 June, 19:52, Tim Streater <timstrea...@waitrose.com> wrote:
> 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?
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. The trick is to not turn your perl programs into IOCCC-esque entries.
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.
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?
> 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.
On 7 June, 13:08, "bart.c" <ba...@freeuk.com> wrote:
> 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.
> 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.
> 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?
A few, and yes there would -- device drivers, etc.
> 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.
> 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?
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.
On 8 June, 10:17, jacob navia <ja...@nospam.org> wrote:
> 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
