Slashdot Mirror
How Not to Write FORTRAN in Any Language
gManZboy writes "In an article that's sure to p/o Fortran programmers, Donn Seeley has assembled a rant that posits there are characteristics of good coding that transcend all programming languages, except Fortran. Seriously though, his point is that early FORTRAN made coding ugly. Thus the joke 'Don't write FORTRAN' was applied to anyone with ugly code. Though Fortran has in recent years overcome its early challenges, the point -- 'Don't write FORTRAN' (i.e. ugly stuff) -- still applies."
When I took computer programming in high school, it was all FORTRAN. We used a wonderfully dry textL FORTRAN IV with WATFOR and WATFIV. We didn't have any sort of microcomputer (this was 1980, and we were behind the times even then), but we had a keypunch, so we'd write code on a form, punch cards, rubber band 'em together, and send them off to be run on the district's big iron. Then you'd wait a week and get back a few sheet of green and white striped paper with ***SYNTAX ERROR*** all over it. And we liked it that way!
Although that was a toothache of a programming experience, I have never lost this bizarre fondness I have for that ugly, unwieldy, but somehow cool FORTRAN. Writing that stuff makes you feel like you're talking the language of a retro-scifi computer, like the ones in the original Star Trek that spoke in that odd mechanical monotone. Robby the Robot had to
have been programmed in FORTRAN (and NO he was NOT a guy in a suit! I'm not listening! La la la!).
At any rate, old-fashioned FORTRAN may deserve to be bashed, but I can't help shedding a tear.
sure to p/o Fortran programmers
.divide. o Fortran programmers.
You mean "sure to p
While I take issue with his blantant anti-FORTRANism, he makes the excellent point: Write good code in whatever language you write. Just because you can write Perl that looks like line noise does not meen you must.
How does the Slashdot Effect happen given that no slashdotters ever RTFA?
Thus the joke 'Don't write FORTRAN' was applied to anyone with ugly code.
I mostly program in C, Java,php and C++(and several other languages that I dont use as much), and am always interested in picking up new languages to play around with. Is Fortran worth learning? And are there any things that it does a lot better than other languages?
Boxing Equipment Reviews
In an article that's sure to p/o Fortran programmers and bore the hell out of everyone else, Donn Seeley...
I'm more of a western coder ... lots of wide open spaces in between clauses for readability. Documentation in bits rather than 100 lines of code then a paragraph about what happened in there.
I'm sure someone somewhere would gripe about my style too.
A feeling of having made the same mistake before: Deja Foobar
As long as you use vi. You can never write beautiful code with emacs
I just figured I'd follow one pointless flame fest with another.
Isn't FORTRAN used these days primarily to figure out mathematical and engineering calculations? I am sure most of these programs are small and maintained by a few people. So does it matter if it is ugly? I am sure there are FORTRAN libraries to access databases but how many are really large programs??
I have had to make changes to UNIX shell scripts and PERL code before. Most of the undocumented cryptic scripts were small enough to figure out what I needed to change.
Seriously, it's about time that someone knocked Fortran programmers down a peg or two. It seems impossible to get any type of programming job if you don't know Fortran.
Every job classified ad section is filled to the brim with Fortran positions while less relevant languages like Java, C# and Visual Basic are almost completely neglected.
I for one welcome news like this if it help Fortran programmers acquire just a little humility.
I'm a big tall mofo.
Zen and the art of computer programming.
Beginner: draws flowcharts
Amateur: chooses languages, optimizes structures, types
Pro: migrates types and structures across libraries, builds API's
ZEN: Thinks of and designs nothing.
The name "FORTRAN" came from "FORmula TRANslator." It was created so that engineers and scientists could write programs to perform calculations. They wouldn't need a degree in programming, and they wouldn't be reliant on programming staff. They would be able to independently take advantage of a company's (or university's) computing resources. It wasn't DESIGNED to be a pretty language; it was designed to be used by people who would have stared blankly at you if you'd mentioned the concept of a pretty language. It served its purpose well.
It reminds me of SQL in that respect. I have worked with managers who knew less about computers than their secretaries, but they were able to use SQL to write queries to get information that they wanted. SQL was written for that purpose. It ain't pretty, but it serves its target market.
I doubt that designers of armored cars and dump trucks worry about the slings and arrows of the Ferrari's designers; I think this rant is pretty much in the same vein as that. Beauty and utility are not synonymous.
So are they using "FORTRAN" as a adjective replacing "crappy" and then whipped up an article that has been covered in about 5,000 different programming books and/or documentation regarding some largely accepted guidelines for writing clean, manageable and efficient code?
Why is this on the front page?
"Acmqueue Click-thrus ACTIVATE!! Go Go Go!"
Sehr geehrter Toilettenbenutzer!
For the uninitiated, Brainfuck's a Turing Complete language with eight language statements, each consisting of a single character:
> increment the pointer.
+ increment the byte at the pointer.
- decrement the byte at the pointer.
. output from the byte at the pointer (ASCII).
, input to the byte at the pointer (ASCII)
[ jump forward to the statement after the corresponding ] if the byte at the pointer is zero.
] jump back to the statement after the corresponding [ if the byte at the pointer is nonzero.
I'd post actual code, but the /. filter is fucking me up.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
if the article weren't broken
into such small pieces.
That way I could
print it for my students.
Sort of amusing for an article that discusses using white space in a good way.
As Nietsche famously said, "If you stare too long into the Abyss, 1d4 Tanar'ri of random type will attack you."
I have to say my interest in the article plunged through the floor when I saw the example using Bush/WMDs as the subject. I immediately realized I'm either reading something written by a college student or someone who has not matured much beyond that. How gauche.
Regardless of how you feel about the politics, it's just not kosher to use examples like that. Clearly this is a person with an axe to grind.
I read the fucking article. I didn't see too much very insightful, or see any specific reference to Fortran at all.
10 clear
20 print "hello world"
30 goto 20
They're really starting to shake up the industry on slashdot, I'm sure this will create a lot of disruption in the massive FORTRAN industrial establishment. Oooh, next they should link an article criticizing ALGOL, that will shake up things even more.
You can't write "good" Brainfuck.
http://en.wikipedia.org/wiki/Brainfuck
500GB of disk, 5TB of transfer, $5.95/mo
I prided myself in college that I could write FORTRAN in any language. I had a prof that couldn't figure out why I was doing bit manipulation in COBOL. (Yes, this can be done in COBOL through multiplication and division, but it's really ugly.)
If you don't want crime to pay, let the government run it.
I think people like perl because you can do cool things in a short program with it, not because it's beautiful.
I am trolling
I've just spent the past two weeks leaning how to program in FORTRAN77 (hereafter F77). Why you might ask? Well, I'm a PhD student and most of the code that my supervisor has 'gifted' to me is in F77.
What do I think of F77? Well, I was very surprised how quickly you can get stuff done. Sure, sticking to the fixed format (a relic of punchcards) is a bit of a pain, but you quickly get used to it. I'm currently using a mix of g77 and the Intel F77 compilers (depending of the processor), and the compile time on reasonably complicated programs doesn't leave me twiddling my thunbs for too long.
I think that as long as you comment your code, and make sure that you have thought about what you want to do before you do it (!), then you can write very efficient code in F77.
Cheers,
John
FORTRAN 77 was my first programming language. I learned it during a high school mentorship program at NASA LaRC. I remember the coworkers of my mentor stating "Wow, you really hate this kid!"
We have huge amounts of FORTRAN 77 (and lesser amounts of Fortran 90) code flying around on our servers. It handles big arrays of numbers (which is all astronomical images are) very well. We're forced to actually buy compilers for the f90/f95 stuff...
So what if Fortran is ugly--all languages get uglier the less they are used and the more high-level languages are developed. I'm sure lots of people would look at assembly code and say it's ugly too. It's only a matter of time before our kids look at C++ code and say, "Boy, am I glad I didn't have to program like that!".
Kinda reminds me of "Back to the Future III" where Marty plays that shoot-em-up arcade game in front of kids, and all they can do is complain "You mean you have to use your hands. That's like a baby's toy."
I, for one, look forward to the day when I can think code and have it be done instead of writing it line-by-line.
... people would have got the point. Christ even John Backus (FORTRAN's creator) said that FORTRAN and even all imperative languages were horrible ugly hack, and that we should all go away and use "[the] functional style, and it's algebra of programs".(warning: pdf link).
It took me 2 hours to compile my first simple Fortran program, because I didn't realize that the first 5 columns were off limits. That's where the line numbers used to be on the punch cards.
Why this limitation persisted into a verion of Fortran that no longer even required line numbers - no idea.
Since major companies like IBM have chosen to produce compilers that perform best with FORTRAN. (absoft markets the compilers with a front end)
I like C, and a slew of other languages much better...
But my G5 dual-processor desktop machine can be optimized to run at around 35 GFLOPS. Try that on an 8086 derivative What, maybe you can get 2-4 GFLOPS per machine (if a dual-processor system)? I have a low-end supercomputer on my desk! Unfortunately, without FORTRAN, it wouldn't be so super.
FORTRAN is the only language that will easily take advantage of the HW (Altivec 'velocity engine' and parallel processing).
Each language is good for some tasks. FORTRAN happens to be good for performance in science and engineering work.
Fortran 90 Handbook Complete ANSI / ISO Reference
Jeanne C. Adams, Walter S. Brainerd, Jeanne T. Martin, Brian T. Smith, Jerrold L. Wagener
This is a Tr0ll story on the order of "GPL licensed software saves Tsunami victims." The FA really does not even comment on the merits or problems of Fortran syntax. It could just as well have read How not program Assembly In Any Language....
I have seen better Ruby vs Perl vs Python gripefests....
Have you Meta Moderated t
The existence of Perl poetry says that you're wrong...
While Fortran 77 is ugly and I saw terrible programs written in Fortran 77, Fortran 90 or 95 is a pretty modern and nice language and if you know C, it is easy to learn Fortran 90. It is not that much different from anything else. It is great in numerical programs (especially linear algebra) as the matrix handling is nice and fast. The only problem is that only recently free (as in speech) Fortran 90 compilers has become available and they are still in beta stage. However, for Linux, Intel Fortan Compiler is free (as in beer) and works fine. It includes also documentation of the language so you may try it.
Save the bandwidth. Don't use sigs!
Only old people in Korea code FORTRAN
Heh. The quote of the day at the bottom of slasdot was somthing like "HONK USE IF THEN" earlier this morning.
-Peter
I write very complex codes that solve partial differntial equations for science applications. We use fortran all the time for our core routines. All the data choreography is done in C++ but when you really need an array operation done quickly (and portably), nothing works better than Fortran. We have done tests comparing Fortran array operations to similar code written in c, and at one point the performance difference on the big iron was a factor of 7 (I doubt that it is still that high since most supercomputers now have commodity processors).
Mixed language programming is a pain in the neck and we would get rid of it if we could. As of now, we can't.
The truth is an offense, but not a sin.------R. N. Marley
1. Do not separate the presentation logic from the application logic. I love it when I have to search for a specific code function sandwiched between the visual element constructors and modifiers.
2. Do not create a data layer. It is great to search through thousands of line of code to change the sql code.
3. Use one very long class instead of separating the program's functionality into small atomic units. I just love 7th or 8th level if statements that are repeated everywhere.
4. Don't comment or doccument anything. Good code should be self docummenting right?
5. Don't handle exceptions. Good programs don't make em.
6. Don't use configuration files. Because we love to recompile everything to change settings.
Forgive my rant, it has been one long week... after another... of working with other people's code.
Cheers,
Adolfo
It's nice to see another coder who, in essense, styles code like I do. Namely:
:-)
- Using underscores in variable names
- Comment in real language when tricky stuff is happening
- Don't over comment code
- Use long variable names to enhance understanding
- Liberal use of whitespace and indenting to block off lines accomplishing a task.
I'm especially pleased about the underscores in the variable names. I can't stand CaseDeliniatedVariableNames.
Monitor bandwidth usage on IIS6 in real-time: http://www.waetech.com/services/iisbm/
Fortran is hardly used these days, while SQL is still ubiquitous. In recent years people seem to have stopped predicting SQL's demise. SQL has its weaknesses, but is extremely useful if you know its strengths.
... or did they consistently replace "APL" with "FORTRAN" in the article.
I could fix that for them with sed, or maybe a Perl script. Now, where did I leave all my leaning toothpicks...
Eloi, Eloi, lema sabachtani?
www.fogbound.net
loop:
lda speaker
jsr cout
jmp loop
And you need to run it on a computer created by some guy called "Rocky Clark".
Have you ever had the misfortune of working with APL?
...except that each time a page loads, a new set of ads is displayed, potentially making it more profitable for the author.
So the artificial 'page' breaks are a byproduct of profit motive, nothing more.
Sad, but true.
Your description of the purpose of Fortran doesn't really match anything I have seen before regarding it. My understanding is that Fortran was the first "high level" programming language and was designed to be used by everyone not just poorly trained egineers and scientists.
Being "first" had some advantages (namely long life) but many disadvantages as different programming styles and methodologies had not yet been invented, discussed or evaluated. As far as I can tell later versions of Fortran (ie IV, V, and 90 although not ANSI) were attempts to "modernize" the language and provide it with structured language extensions, etc.
In coming of age in the late '70s, early '80s, I generally saw people who were not formally trained in programming gravitating to "APL" which was a truly bizarre language/operating environment. For certain types of applications (primarily matrix operations), such as multiplying two matrices together in one line of code, it was fantastic. Unfortunately, the operator set used with APL uses non-standard (ie non-ASCII) characters which made the code impossible to follow unless you had a reference in front of you (or were very, very experienced in developing APL code). One of my first jobs was maintaining APL based applications that interfaced with system resources through the use of APIs. I would have preferred the "line noise" of Perl over what this looked like.
More recently, "Labview" seems to have taken over as the medium of choice for these applications. While it is outstanding as an application tool for developing fast instrumentation interconnect logic, traditional programming structures (like a "while loop") come out more like a page of Pentium IV schematics.
I think that you've gone too far in stating that Fortran was designed for just engineers and scientists, especially when compared to langauages/operating environmnets designed specifically for engineers and scientists. Fortran was simply the first product of an immature science.
myke
Mimetics Inc. Twitter
the keycard punched YOU!
Is something burning?
Oh, it's my karma.
Way back when, you only had a few choices. If you were a scientist/engineer you used Fortran. If you programmed business/text applications you used Cobol. Fortran stunk for business use, and Cobol stunk for math uses.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
...300:LDA $C030...
The A, X, and Y registers on the 6502 are eight bit, so the maximum value you'd be able to load is:
LDA #$FF
The platform for that code is probably C64 as the jump table was stored right at the high end of memory. But the Apple II's also used a 6502 so it could be them too.
Shh.
Every programmer should have this book in their reference library.
I got mine in '84, and even though I didn't work in Fortran or PL/I I still found it incredibly useful.
The Tao that can be spoken is not the one eternal Tao
You know, if I shit bricks, I'd probably go on the war path too. Ouch...
A Guide to Real Programmers.
Fight Spammers!
You had new punch cards to use? Back when I was in high school we had to recycle old punch cards from national elections, fill in the holes with white-out, cut new holes with our pen knife then tie them together with catgut!
I mean... so where is the "Obfuscated Fortran Contest"??? Teaching good (pretty) programming principles are a relatively recent development ('80s?). Fortran is freakin' old and a lotta legacy code comes from before the "pretty programming" era. And let's face it, a lotta science/math profs use Fortran -- and they wouldn't take a structured programming class to save their lives. My work deals with a lotta NASA code. Our joke has become "written by Physics grad students enslaved to Physics professors." A porter/debugger's nightmare! And it ain't limited to fortran -- the C code is just as bad, if not worse. The moral of the story (and it's been said before): You need to know HOW TO write good code before you can write good code... and these principals (generally) apply across languages. -Pie
The p/o'd response basically sounds like "He's equating Fortran with FORTRAN-66 (or 77)".
I know that I do this too. When someone says "It's written in FORTRAN" I don't think Fortran-95, I think FORTRAN-77... and I'm usually right.
I suspect that there are two reasons for this:
Which is a shame really because you should be judging the quality of the application - and not what it was written in. Seriously, if it does x and it does it quickly and well with a nice user interface - does it really matter that it was written in Algol 68?
As a by no-means perfect example, check out this site which is, I think, a reasonably nice looking application written in Visual Basic (it acts as a GUI to the free SMS gateways out there). I don't claim to have it perfect, but the feedback I've had from people indicate that they don't think it's the usual run-of-the-mill-vb-application.
Disclaimer: I wrote it and the preference section is a little nasty, but I'm working on it. Also, I know that VB is only really for doing RAD but I don't have the time or inclination to learn Visual C++.
Avantslash - View Slashdot cleanly on your mobile phone.
I just skimmed through "Code Complete, Volume 2" and although form and style were not the most interesting things I learned from it, I learned more about them in the book than this article. For example, one change I made recently in my code due to CC v.2 is changing
to:Then again I like to mixI learned a lot of good stuff from Code Complete and will have to check out other books I've been recommended (I have The Art of Computer Programming, but it is not the kind of quick and applicable type of book that Code Complete is, no "how to calm your boss down" advice in the middle of chapters). Especially ideas like functions should do one thing and do it well, functions should attempt to keep from using more than seven variables, the ideas of function cohesion and so forth.
I have not yet seen anything even approaching something like Code Complete on the web. I wonder why the free software community, which hopes to improve programming of its contributors, I'd think, has not written good, free stuff on how to write good code and put it on the web (aside from things like Linus's short CodingStyle). Some advice you don't even see much, like how to deal with APIs.
Perhaps the most important thing I've learned in all of this is that work pressure seems to create bad coding practices. I thought I'd try to get a job programming C to learn more on the job, but so many people complain about work pressure hurting their code, I think I'll stick to being a sysadmin, and writing code on my own time, at the pace I want.
[A two page ad. A middle-age man with a youthful, shy grin, dark horn-rimmed glasses, slicked, short hair, and the premonition of a hairy chest emerging from a blue denim(?) shirt, fills the left page; the vista of urban sprawl outside a window behind him; painted scrawls of mathematical formulas superimposed. On the right hand page is a block of sans-serif text]
Meet an elder statesman in the computer business.
IBM's Jon Backus is 43, pretty young for an elder statesman in most industries. But then, the computer business is less than 20 years old and a mathematician Bakcus has been in it since the beginning. He started workig with computers in the early 1950's. It was about the time a leading business magazine estimated that no more than 50 companies would ever have use for a comptuer. Today, it is estimated that there are well over 50,000 comptuer installations in the United States alone. Part of the reason for this astonishing growth: the progress made in programming. In this field, John Backus was a pioneer. "It bothered us, in the early days of computers, that so few people coluld use them" he says. "One reason was, programming cost as much as the machine. A small compnay just couldn't afford data processing." With a small group of associates, John Backus tackled the problem and stayed with it for three years. The result was the simplified programming system called FORTRAN (FORmula TRANslator) which made programming considerably less expensive than before. Today, FORTRAN is probably the most widely used programming system in the world. Currently, John Backus is working on a new mathematical concept which is still in the realm of pure theory. But his theories, like the work of many IBM scientists, ultimately have a way of making computers more useful.
[A red line runs across the text. A matching red 'IBM' (not the blue, CRT lines version) appears in the margin.]
From a beginning less than two decades ago, computer technology has made remarkable progress. John Backus is one of many outstanding men and women in the industry who have turned a laboratory marvel into tens of thousands of computers helping people around the world.
...but it's still quite possible to write readable and modular code even in Fortran 66.
(I'm saying this as a programmer who spent 12 of the past 15 years doing exactly that -- writing and maintaining Fortran 66 code that was part of a critical production system at a major airline).
As with any language, the onus is on the programmer who is writing the code to organize it and implement it in a way which is easy for subsequent programmers to follow and understand.
We were able to do it even within the limits and conventions present in the environment (external variable/parameter references limited to six (6) characters, internal references limited to either five (5) or one (1) character, subroutine names limited to six characters) by using common sense and trying to use a consistent coding style.
Yes, arithmetic IFs are ugly, computed GOTO statements can be confusing, and strings defined using Hollerith notation are strange to folks who haven't seen it before, and programs are hard to follow when everything is lined up neatly in column 7 without any spacing between code and comments. So don't use that style, avoid confusing notation, and refrain from using confusing syntax or statements which might make the intent of the program unclear.
It's the same advice in any languages -- cute tricks might save a few bytes or clock cycles, but in a production environment it's usually long-term MAINTAINABILITY that counts -- and that's true in *any* language!
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Well, I RTFA and I can quite easily summarise it for those who didn't:
When programming:-
Use whitespace properly.
Use comments effectively.
Name your variables sensibly.
This is programming beginner's stuff and barely worth reading through 5 pages of diatribe, padded with quotes and pointless examples.
Considering the technical audience of Slashdot, I'm surprised it ever made it to the front page.
It's not optimized at all. Matlab is great for doing routine work - I use it all the time - but it'll never compare to Fortran for something you REALLY need to be fast.
Check out some of the numerical libraries for python (Numpy, etc.) - they're all wrappers around compiled FORTRAN. Why? Fortran's made to do math. Partly the languages, partly the compilers available, but in the end, it'll do matrix math faster than anything. C++ most certainly included
-Looking for a job as a materials chemist or multivariat
A Fortran logical equivalence comparison and variable assignment:
.EQ. B
:-)
A
A = B
A C logical equivalence comparison and variable assignment:
A == B
A = B
Guess which language is more susceptible to subtle typos which can radically change the behavior of the program?
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
For certain purposes (including most of what I do), fortran is unmatched.
It is *possible* to write C that runs as fast as Fortran for heavy math. However, it involves hand-optimizing your C until this happens.
Fortran handles calculations quite well, thank you. It take less Fortran code to handle many common operations, and array options are built in and optimized to high heaven.
With Fortran 90 and 95, the grammars that led to the CS horror (e.g., computed gotos) are marked either deleted or obsolescent (meaning expect deletion in another standard or two).
Also, due to the selection of which features are included in Fortran and which are not, Fortran compilers can make much stronger assumptions than, for example, C compilers working with pointers.
There's nothing unfortunate at all about Fortran's (not FORTRAN any more) role in scientific computing. The tragedy is the number of people who bought into those silly C campaigns.
hawk
There is Visual Fortran and Fortran .NET. Visual Fortran I've actually seen and installed on a computer. Watching one of the grad students start to write a Windows program, with GUI, in Fortran was rather scary. I haven't messed with Fortran .NET but apparantly you can really generate .NET code with it. This also mean that one could write stuff in Fortran and call it from C++. To make things even scarier, there's a PERL .NET kit. So one could write a PERL program that calls on Fortran.
:)
These are things man was not meant to do
Fortran has accepted A==B as an equivalence test since 1990. But it is still immune from the C programming pitfall, since A=B can never appear in an evaluation context.
Tubal-Cain smokes the white owl.
My boss still has 'habits' from FORTRAN while coding C.. Basically, we all work late to make sure we never fall behind on a project because if we do he starts coding. He han an uncanny skill of only using the variables i,j, and k for eveything, over and over and over again.
Libraries - the most bullet-proof, battle-tested numerical code is pretty much all in FORTRAN
Optimizers - if you must wring the last factor of two of performance out of big vectorizing iron, and you're not a CS guru, the FORTRAN compiler is still your best bet
Semantics - FORTRAN the language enforces some constraints that make vectorizing optimization work better than less constrained stuff like C
The problem is, for these guys FORTRAN is a means to an end - most of them have had very little formal training in good coding practice, and worse, most of the code they read was written by people with similar experience.
Maybe what we should do is require scientists and engineers to pair-program with recent CS graduates. Both sides would learn a lot from that.
To a Lisp hacker, XML is S-expressions in drag.
Not that I can confirm or deny that those printouts had "MX" and "SHUTTLE" written on the side. :-)
The revolution will NOT be televised.
I thought those days were long behind me, but then...
This week, I got the new DVD release of the 1970 movie "THX 1138" from the local library; you know, George Lucas' college project about a dystopian future, that set him on his way to fame and fortune. Pretty bad movie, although I did like the "somebody ran over a Wookie" line in the background police chatter.
But the funniest part was when they wanted to show some "computer" stuff (this movie was from 1970, remember). They showed....Fortran code! Printed on green-and-white line-printer paper! Ohmigod, deja vu! And now, today, we get this story! AAAAAAAAAGH! It won't die!
Have you read my blog lately?
We're still using F77 here, so I didn't know that. :-)
/* comment notation */ are two things about C that I've never quite understood...
:-)
That and C's strange
Maybe I've been using too many non-C-like languages for my own good.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
- integer i, n, sum
18 continuesum = 1
d0 18 i = 1, n
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
I spent several weeks last summer trying to make a simple modification to a molecular simulation package. This package is about as old as Fortran itself and the primary (basically only) programmer is not a computer scientist. It was hell. I just barely got to the point where I could add my 20 lines - in six weeks. And I'm not a bad coder.
Along the way, I discovered many horrible things about Fortran-77:
- No dynamic allocation
- Mind-bendingly stupid global variable mechanism (COMMON blocks)
- Back in the day, identifier names were limited to something like six characters. Tens of thousands of lines of code later, it's anybody's guess as to what a given variable or function does.
I feel terrible for you folks who had to deal with this horrible language back in the day.
The only saving grace is the (very nice) guy who wrote has his office down the hall from me, so I could pester him with questions. Otherwise, I would have been completely sunk.
We're still using F77 here, so I didn't know that. :-)
Fortran 90/95/2003 are well worth 'upgrading' to -- for starters, the array syntax is fantastic. If A and B are arrays, you can assign from one to another simply by 'A=B'. Likewise, 'A=sin(B)' would set each element of A to the sine of the corresponding element of B. Code like this is a doddle to parallelize automatically, enabling one to write parallel code with very little effort.
Tubal-Cain smokes the white owl.
"Don't write perl." :)
Fortran-77 was the bane of my college existence. *shudder*
Yeah it might, I was thinking about that after I posted.
Shh.
I have seen people write a program consisting on a single C++ or Java class that is the entire program. Sometimes it is a single method- main. It may e hundreds of lines long and use only primitive data types. No concept of data abstraction through classes at all.
I'm not sure if there's even an F90 compiler available for this particular environment (basic mode HVTIP/USAS on a Unisys 2200/500).
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
The A, X, and Y registers on the 6502 are eight bit, so the maximum value you'd be able to load is:
LDA #$FF
Note he didn't specify LDA #$C030, he specified LDA $C030 - load the value from location $C030 into accumulator.
The platform for that code is probably C64 as the jump table was stored right at the high end of memory.
It's not for the C64 - if it's a useful program, $C030 is part of an 8K RAM bank, and $FDED isn't an official kernal entry point (it's been awhile since I took a look at the kernal disassembly, so I couln't tell you if it actually a valid address for jumping to, but I doubt it.) So, if it was a useful program, he'd be taking a value that doesn't change, and passing it to a fixed routine.
There is one true coding style, and everybody codes in it.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
And you mean...
"sure to P .DIVIDE. O Fortran programmers.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
in the mathematical sense of proof.
Sorry, but you cannot say the same about a lot of the languages that exist these days.
Wow, Fortran 2003 has OOP and asynchronous I/O.
Pretty cool.
I've often advocated the use of assembly language, and every time I do, the flames begin:
Now, I realize there's probably some pretty ugly assembly code out there. But when you look at what an idiot programmer can do in other languages, it doesn't seem so bad:
So often times we are quick to blame the language for what is really ineptitude on the part of programmers. A good programmer will write good code in any language, but a poor programmer requires a specific language in order to write good code. And a malicious programmer can write bad code in any language...
The society for a thought-free internet welcomes you.
Certainly, you can write poorly in any language. But you can't necessarily do the opposite.
:P
For example, I initially resisted C++. I viewed it as poorly designed objects on C (after experiencing the beautifully done objects of LPC), and programming examples for it made objects of things that never should have been objects - and as such I wanted nothing to do with it.
However, the other features of C++ ended up proving themselves infinitely useful, and since the value of C++ objects has shot up notably in my mind. Examples:
Templates: I can't even imagine how many pieces of code I wrote before C++ in which I wrote different versions of the same function for different variable types. Talk about a maintainance nightmare
Const correctness: I remember resisting this like crazy, because it makes initial programming harder. But not only does it offer some serious benefits to the compiler at optimization time, but it's saved me many times from errors and really helped with code cleanup and refactoring into functions. My only real problem with it, now, is programmers who don't const their libraries, thus preventing me from consting variables that I need to pass to them at each step of the way.
Destructors: I don't think I need to even get into why having your variables clean up their memory when they go out of scope is probably the best thing that ever happened concerning fighting memory leaks. You can also do garbage collection with smart pointers, but that's a topic for some other time and is less standard.
std::vector: I can't believe that I used to not only have to clean up variable size arrays before, but used to have to have each array contain three variables - the pointer, the count of elements, and the allocated size - all of which would need to be checked and adjusted at each insertion and deletion.
std::string: A lot easier to use than C's unwieldy strings, and easy to convert to and from regular C strings.
I could go on for a long time... a good language can save you many programming headaches if you're willing to learn it.
We also have a halon fire extinguisher. Its always nice to have a fire extinguisher that kills people around.
As somebody that has been programing for 25 years, all I can say with regard to this article is "Well, duh! Tell me something I don't already know!" Seriously, if you've been programming for more than 3 years and haven't already figured out by yourself (and by bad example) how to write understandable code, maybe you shouldn't be programming!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
All that said, though, I still think it's an ugly language. And I think there is something to be said for a programming language preventing some bad programming habits simply by not having any support for GOTOs.
Also digressing a little from my first point...did anybody else notice the irony of an article about clarity in programming posting code examples in a .jpg?
Ever see a BASIC program from the 8-bit computer days? This kind of crap was quite common:
#!/usr/bin/python
import sys
i = 0
k = 1
ary = []
ary.append(None)
while ( i != 0 ):
inl = sys.stdin.readline()
if inl:
j = int(inl)
ary.append(j)
k = k + 1
else:
i = 0
j = 1
while (j k):
print ary[j]
Don't piss off The Angry Economist
Now to really obfuscate the code, you want alternate returns and assigned goto's. Control keeps popping up in all sorts of unexpected places. It's like watching a colony of gophers.
"Personally I find Java's cutesyPooCapitalizationRules very annoying.
Hashtable and HashMap indeed."
I don't know much about Java's naming conventions. Was your intent to show that they are inconsistently applied? That's common practice with most naming conventions. Any set of rules that aren't enfoced by the compiler aren't going to get followed very well.
Also in my experience, a lot of productivity is sucked up by convention hard-cases, who feel the need to "correct" non-compliant code when they could be chasing down real functional defects.
> No dynamic allocation
:-)
:-)
:-)
In the mainframe transaction environment I write Fortran code for, it's still true.
While it isn't a good thing from some people's perspective, think about it this way: memory leaks induced by application programmers become nonexistent, and a machine with virtual memory is doing to dynamically page the process in and out at the OS's whim anyway so the fixed sizes seen by the applications programmer in that environment don't really matter all that much.
Each module I create is limited to roughly 262K words of memory. It may or may not use it, and it really doesn't matter to me. All I have to care about is getting the thing to compile!
> Mind-bendingly stupid global variable mechanism (COMMON blocks)
We don't use those. It's easier to map common areas to a memory file and INCLUDE a PROC with relevant DEFINE names.
> Back in the day, identifier names were limited of something like six characters. Tens of
> thousands of lines of code later, it's anybody's guess as to what a given variable or function does.
Here's a new term for you: "naming convention"
Where I used to work, the convention commonly followed was this:
* External refererences (usually defines for fields in a file) were six characters, with the first two indicating the subapplication code, the third being the file, and the last four being used for the field itself.
* Local references were usually five characters, but loop counters could be one-character.
It wasn't all that hard to learn that anything that was WXSxxx belonged to the Weather Station Record, WXGxxx to the Weather Grid record, etc., and LOOOP was a local loop counter.
Some defines (e.g., WXGLEN or WXGVER) are actually quite obvious (the WX Grid Record record length and version number respectively).
> I feel terrible for you folks who had to deal with this horrible language back in the day.
I feel terrible for you folks who have to type in 40-character mixed-case variable names when we are able to save both time and typos.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Have you ever wondered why there is all this bad code? I have. First I blamed it on the dog since everyone knows the dog is the first to blame. But the dog died a few years ago so I can't blame it on him anymore. I needed something else. So I started blaming it on that other guy. You know the one I'm talking about. Him, your predecessor, the one who came before you. The guy you never knew but everyone talks about. Yeah, that guy..(insert more Andy Rooney blah-blah here)....I really miss that dog.
Then just embed banners into the articles at evenly spaced intervals.
Neither. This is one place where Pascal and its bretherine win - A := B or A = B. Assignment is not equality, and the notation should not be such.
Still, I prefer C's brackets or Python's colons and bracing to Pascal-style "begin" and "end" statements.
I have to say my interest in the article plunged through the floor when I saw the example using Bush/WMDs as the subject. I immediately realized I'm either reading something written by a college student or someone who has not matured much beyond that. How gauche.
Why is using Bush/WMD's as an example any worse than, say, mentioning the Gallipoli operation, Kennedy's attempts to unseat Castro, Japan's 1592 invasion of Korea, the design of the RBMK nuclear reactor (Chernobyl), the US war on drugs, or any other case of a major world power majorly fucking up? Bush's search-for-WMD debacle is a fact, regardless of your political leanings, and it will stay in the history books for at least a century.
Saying that G.W.Bush is an imperialist monkeyboy = gauche. Saying that there are no WMD's in Iraq = fact. See the difference?
Unfortunately, g95'S developer chose to rather violate the GPL than to either work together with the gcc people or at least let them use his code. Look here for more information on the split.
Is tmp really any more meaningful than temp? pnt vs. point?
As long as programmers remember that source code is not for the computer to understand, but for *programmers* to understand, those of us who get paid to fix broken code will have a much less stressful life...
How's my programming? Call 1-800-DEV-NULL
People seem to like writing flight planning systems in Fortran, and we had several other major systems written in Fortran when I worked for an airline. Even the "modern" Unix-based system that replaced one of the mainframe systems while I was there had Fortran 66 code at its core.
Airlines were one of the first areas of industry to use computing heavily and are still using many older specialized applications, so that might explain the continued use of (and development in) that language.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
FORTRAN (FORmula TRANslation) was never meant to be a general-purpose programming language, it is strongly biased towards scientific calculations. It has native support for doing fast computations with scalars and arrays of integer, real and complex data types. In modern revisions of the language (F90/95, Fortran 2000/2003) it gained support for dynamic memory allocation (although there is no garbage collection), abstract data types, pointers and object-oriented programming but few people use these capabilities. And yes, it is possible to write beautiful programs in FORTRAN although bad practices prevail due to the backwards capability of modern FORTRAN with F66/F77.
Real programmers can (and do) write FORTRAN in any language. (And they aren't afraid of goto)
we discovered a new way to think.
Between this thread, and your sig, I feel an urge (buried for decades) to type @FTN,CS PROGNAME....
Yes. Back when we had 8K or 12K to program in.
When I programmed in RSTS Basic I rarely had more than one statement per line.
The worst of that cramped coding style was when you had to debug someone elses program. It took considerable time simply to determine what it was doing. I've still had to cope with things like that a few times over the years and usually bring it up in a text editor and split out individual statements and to show where nesting is taking place.
A feeling of having made the same mistake before: Deja Foobar
Yes, it's tricky at an "intermediate C programming" level to do fast multidimensional arrays in C, but it's not at all impossible.
Look at how cblas does it, if you can't figure it out on your own like I had to back in the day.
I still think for beautiful code, you can't beat a folding editor...
And no, the emacs folding editor macros aren't quite the same thing...
- You don't have enough experience reading/writing code. You have to read (more so than write) a tremendous amount of code to get good at reading code.
- You don't understand the problem the code is solving.
- The code is very badly designed at a higher level than things like white space and underscores.
A lot of people get frustrated when they don't understand code right away, and rather than trying to grok why they don't understand it (because 2/3rds of the time it is the reader's fault, not the coders), they just bitch about white space and brace placement. That is never the problem.Back in the 70s I had the priviledge of working with a very bright and skilled compiler designer who happened also to be our company representative to the FORTRAN standards committee. I think his position pretty well summed up the dichotomy between the ugliness and the usefulness of the language: "FORTRAN is a weed. It grows on every computer."
Ya think it's ugly now? You should have seen it in 1958 when, in its infancy, I spent a summer solving a triple integration problem on a 704! It was ugly, but it worked, and some engineer who got the result made a better jet engine because of it.
Plus la change....
Fortran can be a great language, generally in applications where the process is more complicated than the data.
"There's more than one way to do it" is fantastic for stringing a quick script together, but means that different people do things in different ways.
For big pieces of software, where the source has a long and continuing existence, a lot depends on the capability of one programmer to read and understand what another has written. This can be easier when "there's (barely) only one way to do it".
Did anyone else see this line and do a double-take?
Like pornography, I know bad code when I see it.
What? What??
Ethan
That particular program looks like it would make a tone and print crap on the screen of an Apple 2.
To test that, run an apple 2 emulator. According to the internet, type the following lines:
call -151
!
0300:lda C030
0303:jsr fded
0306:jmp 0300
0300G
Note that I corrected the bug :-)
And as I predicted, crap fills up the screen with characters scrolling past (isn't the internet wonderful?)
Check out the public domain area of the Numerical Recipies package. (While you're at it, you may want to insert your own harangue deriding the routines; but the 2D array routines are solid).
Returns a matrix with easy multidimensional dereferencing via a[i][j]:However, if you are saying that somehow C internally dereferences less optimally than Fortran, then perhaps someone else can comment on that---I don't know.
My last encounter with FORTRAN was 20 years ago (I translated a FORTRAN program into something prettier) & my only formal training was 30 years ago. But learning FORTRAN is sort of like an old saying I once heard: "First thing every morning if you squeeze a dead mole over your head, nothing worse will happen to you the rest of the day." Learn FORTRAN when you're young & forget it. Nothing else will ever seem as awful. Except possibly p-chem.
"Obviously, I'm not an IBM computer any more than I'm an ashtray" (Bob Dylan)
Without FORTRAN, what would you use for quick array indices? What I mean is that in FORTRAN, variables with one letter are assigned automatic types if they aren't explicity declared as something else. The letter 'i' happened to be the start of the integer letters.
What, 'i' is just the first letter of "index"?
Well, why do you use 'j' as the variable for a nested loop? Because j is the next letter that automatically becomes an integer.
Programming in 4 or 5 grade summer cool was fun. Palying Tapper was awsome, those 5 and then some inch floppy drives kicked but.
I like his discussion of the limitation of human brains. I see people write clever code in Perl, and it's wonderful that they're so smart. But what's going to happen when they've flown the coop and I'm stuck here trying to maintain it? My mantra for these people is: If you don't plan on being chained to this project for the rest of your career, then please be sure ordinary mortals can understand your code!
"Who controls the past controls the future. Who controls the present controls the past." -- George Orwell
My first job with decent pay was writing FORTRAN-2 to test nuclear missiles.
Did the job just fine. In fact, the code's still in use (as of six months ago, anyway), and was used to test several parts for the recent successful Mars missions.
You can write unreadable crap in any language (probably easiest in Perl or Lisp). You can overrun data boundaries in FORTRAN ludicrously easily - but that's also true of C.
Picking on FORTRAN is just grandstanding. Pick on a language with legions of frothing-at-the-mouth fanatic supporters (like Perl or Python for instance) if you've got the belly for a real fight.
So you have aspirations to be in management or an end user? I'm not clear here.
Worst case scenario: aspirations to be management and end user.
-kgj
-kgj
I thought the article was a good summary of a lot of important code formatting concepts. If I have a critique, it's that I saw nothing that hasn't been said before, and at greater depth. See e.g. McConnell's Code Complete for a discussion of most of the issues raised in this piece.
That said, anything that gets more exposure for these ideas increases the chances that I won't have to read so much FORTRAN-in-any-language. I view the article as a good thing.
It's a case of the poor workman blaming the tools, complaining about people using gotos in weird places is just like people mismanaging memory in C - it's the people not the langauge. All it takes is to write out the code in a reasonable fashion, only branch to subroutines and to declare all of your variables instead of just introducing something like "kount" - beacuse people unfamiliar with fortran are not going to know that variables starting with k are assumed to be integers. It's all very simple stuff which was taught to engineering students very early in their courses. Keep it real. Doubly so if you need more significant places.
Computers are used for a lot of things, not just typewiters and network services. Numerical computing still uses a lot of fortran.
C++ also has some pitfalls not disimilar to the problems FORTRAN can bring (maybe later versions of Fortran are better)
... ...
... ...
function.cpp
int i;
do_something(i);
There is no way of telling just by looking at this code whether the value of i changes in the function call. In C you know it doesn't.
It can be a great help when trying to trace back from a coredump where a crazy value came from to know that a function call couldn't possibly have affected the value without having to look at headers or, even worse, the source of the function.
Another problem C++ brings to the table:
void myfunc(myclass& c) {
c.do_something();
}
Here it is generally impossible to determine what code will be executed in the call to do_something without knowing the code for the caller to myfunc.
These things don't have to cause problems but in the wrong hands they are perfect for writing brittle code
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
This was really possible using HP's Fortran under RTE-IVB on an HP1000 computer circa early 1980's. The set-up was (with appropriate line indentations not shown).
Running this would print out: 2 (instead of 1)No man's an island, unless he's had too much to drink and wets the bed.
I don't get what you're trying to say in the second case - that when you make a function call, unless you have the code for that call, you can't tell what it's doing? Well, obviously. That's what function calls are for - they're groupings of code that do predictable things on a given set of inputs. What, do you want the code for all of /lib and /usr/lib interspersed throughout your code? I'm not really understanding what you're getting at.
As for the first case, you can tell whether it changes i - if that code compiles, that means you've got the prototype for that function, and the prototype of a properly written function will be const correct. What more, exactly, do you want? Do you want users to have to specify whether they want the variable passed to be const or not? They can do that if they want just by casting, although most people find that pedantic.
We also have a halon fire extinguisher. Its always nice to have a fire extinguisher that kills people around.
Yes, but the point is, some languages make so much easier for the compiler writers to come up with good optimizations. Read up on the "pointer aliasing" problem for instance. That's why numerical codes are (on average) always faster on f90/f95 than C/C++.
If one wanted to have an array optimized for number crunching, wouldn't one use valarray instead of vector?
The thing is, in C you're always using pointers even if you think you're not: whenever you use arrays! The compiler is in general not allowed to assume non-aliasing, and therefore it cannot optimize fully in those situations. Google up some info about "pointer aliasing" in this context. That's why they had to come up with the new "restrict" keyword in C9X. Fortran never had these problems, that's why numerical codes run typically faster.
Bah! People like you were saying stuff that 3 years ago. And, while I admit Moore's law has stalled, my computer today runs that same algorithm in C than yours did in Fortran 3 years ago. And what's more, it runs as a distributed J2EE web-service with computation done entirely in xslt than your finely tuned. fortran equations ran in 1990.
For the second case:
#include <iostream>
class A { public: virtual void do_something() { std::cout << "A" << std::endl; } };
class B:public A { public: virtual void do_something() { std::cout << "B" << std::endl; } };
void myfunc(A& a) {
a.do_something();
}
Does this code print A or B when myfunc is called? Which do_something() is executed? Unless you are using function pointers, this ambiguity does not exist in C (or FORTRAN)
For the first case I wrote:
There is no way of telling just by looking at this code.
in C if I have int i; do_something(i); I know that i doesn't change. I don't need to look at the prototype (ok do_something could be a macro)
What I would have liked is for the caller to a non-const reference to still have to write that '&'. The callee gets the benefit of the reference and anyone looking at the caller code immediately knows that there might be something happening that isn't explicit in the code they are looking at.
In theory a smart syntax highlighter could do this but it would probably have to almost be a compiler to handle this, especially if you want it to be correct, even in the face of macros. And I don't want to have to wait for a compilation every time I load a file up into my editor.
An editor could not handle something like:
#ifdef REALLY_SCREW_THINGS_UP
void shit(int& i) { i=i+1; }
#else
void shit(int i) { }
#endif
int main() {
int i=0;
shit(i);
}
But a compiler could have refused to compile unless that call in main was changed to shit(&i); if REALLY_SCREW_THINGS_UP was defined.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
P. J. O'Rourke once wrote that the Dodge Viper was like that ugly date who could perform between the sheets. Is this how you feel about Perl?
I hear the notion that a particular usage is the usage so often, I should just bite my tongue and let the fallacy go by. But for now, I'll continue to say it: Language is not a cosmic principle handed down by God. Language is a convention arrived at by haphazard consensus.
> For the second case:
;)
Obviously it prints based on whatever object to passed into it. That's a good thing. It's an optional benefit; if you didn't want this functionality, you wouldn't have coded it this way. I don't see the problem here.
People extend objects precisely *because* they want this sort of thing to happen. If you created the B object, this means that you specifically did *not* want it printing A - that printing A was unacceptable to you - and that you instead needed it to print B at that point. Thanks to C++, you are able to do this. If you wanted the A behavior, you would just have created and passed an A object.
> in C if I have int i; do_something(i); I know that i doesn't change.
If it concerns you, do:
int i;
do_something((const)i);
I mean, seriously, all you need to do typecast it. I don't see where the problem is. Do you not do const correctness? If not, I should lecture you about that - const correctness is very important for good clean code. I wish I could travel back in time to lecture myself about it when I was younger
> What I would have liked is for the caller to a non-const reference to
> still have to write that '&'.
And I wouldn't like that - that would be a pain. If I wanted people to force people be explicit when calling my function, I would make them pass by pointer instead of by reference. Otherwise, it's their choice: they can be explicit by adding (const) before they call the function, or they can not be explicit (concerning something that I personally would consider pedantic to do in most cases).
> An editor could not handle something like:
It wouldn't need to. If you're so concerned with your variables getting changed and want it to be explicit that they won't get changed, just put (const) before them before you pass them. Other people shouldn't be penalized because you want to get bothered when a function changes a variable, and yet don't feel up to putting (const) in front of your variables. Too many characters to type? Macro it.
We also have a halon fire extinguisher. Its always nice to have a fire extinguisher that kills people around.
http://rchrd.com/Misc-Texts/Famous_Fortran_Errors
... `R dot bar n' [R overstruck `.' and `_' and subscript n],
>From the alt.folklore.computers FAQ:
III.1 - I heard that one of the NASA space probes went off course and
had to be destroyed because of a typo in a FORTRAN DO loop.
Is there any truth to this rumor?
As revealed by past discussion in comp.risks (Risks Digest) as well as
alt.folklore.computers and occasionally other newsgroups, this turns
out to be a confusion of two separate events.
The space probe that the DO-loop story has been wrongly attached to is
Mariner I (or 1), which was intended for Venus (not Mars). Several
incorrect or partially correct versions of what really happened were
posted in comp.risks; the best of these cited a NASA publication called
"Far Travelers" by Oran W. Nicks, but still did not have the whole story.
Then in issue 8.75 we found out what really happened...
| Date: Sat, 27 May 1989 15:34:33 PDT
| From: Peter Neumann
| Subject: Mariner I -- no holds BARred
|
| Paul Ceruzzi has written a truly outstanding book for the new show
| that opened two weeks ago at the Smithsonian National Air and Space
| Museum. The exhibit and the book are both entitled "Beyond the Limits
| -- Flight Enters the Computer Age". Both are superb. Go for it (them).
|
| Paul has dug into several cases treated previously in RISKS and in
| issues of the ACM Software Engineering Notes, and has been able to
| resolve several mysteries. In particular he considers the case of
| Mariner I, about which various inaccurate stories have been told.
| Intended to be the first US spacecraft to visit another planet, it was
| destroyed by a range officer on 22 July 1962 when it behaved
| erratically four minutes after launch. The alleged missing `hyphen'
| was really a missing `bar'. I quote from Paul's book, pp. 202-203:
|
| # During the launch the Atlas booster rocket was guided with the help
| # of two radar systems. One, the Rate System, measured the velocity of
| # the rocket as it ascended through the atmosphere. The other, the
| # Track System, measured its distance and angle from a tracking
| # antenna near the launch site. At the Cape a guidance computer
| # processed these signals and sent control signals back to the
| # tracking system, which in turn sent signals to the rocket. Its
| # primary function was to ensure a proper separation from the Atlas
| # booster and ignition of the Agena upper stage, which was to carry
| # the Mariner Spacecraft to Venus.
| #
| # Timing for the two radar systems was separated by a difference of
| # forty-three milliseconds. To compensate, the computer was instructed
| # to add forty-three milliseconds to the data from the Rate System
| # during the launch. This action, which set both systems to the same
| # sampling time base, required smoothed, or averaged, track data,
| # obtained by an earlier computation, not the raw velocity data
| # relayed directly from the track radar. The symbol for this smoothed
| # data was
| # where R stands for the radius, the dot for the first derivative
| # (i.e., the velocity), the bar for smoothed data, and n for the
| # increment.
| #
| # The bar was left out of the hand-written guidance equations. [A
| # footnote cites interviews with John Norton and General Jack Albert.]
| # Then during launch the on-board Rate System hardware failed. That in
| # itself should not have jeopardized the mission, as the Track System
| # radar was working and could have handled the ascent. But because of
| # the missing bar in the guidance equations, the computer was
| # processing the track data incorrectly. [Paul's EndNote amplifies:
| # The Mariner I failure was thus a {\it combination} of
urrrhhhh brain hurts. too...far ... in past ... to re..mem...ber
Here's some nit-picky crap but wasn't the C64 6510 and Vic20 6502? oh gawd I'm outed. I actually had both of them for a while.
Can't remember... if not, then what was the 6510? was that apple ][e ??
oh well. it gone now.
killed that brain cell years ago.
man, I feel like mold.
I did some googling and the Apple II used a 6502 processor while the Commodore 64 used a 6510.
Shh.
http://sepwww.stanford.edu/software/ratfor.html
So do you want? A medal? Don't you get tired of reading the politics EVERYWHERE? And Iraq hasn't been flattened, you utter dumbass. Ah, I wish the lot of you, Left and Right, would all just drop dead of brain aneurysms.
--- Ban humanity.
It's funny and it's kind of on topic!
How to shoot yourself in the foot
Heh. Real men use @FOR. :-)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
In C, multidimensional arrays are a fiction, because a[i][j] is given exactly the semantics of *(*(a + i) + j), instead of *(a + i * second_dim + j).
Poster has absolutely no clue what s/he is talking about.
I suspect you spend most of your time looking at, and writing your own code. I spend most of my time looking at, and fixing, other peoples code.
And references give people power. They can change what was an input parameter into an input/output parameter by changing void myfunc(int); into void myfunc(int&); and not touching the caller.
The fact is that probably 80% of the people who write code should never have been allowed infront of an editor.
do_something((const)i); does not compile. And even if you change it to do_something((const int)i); it still won't compile if someone has written void do_something(int&); I've seen this where do_something(int) would have been sufficient but the original programmer obviously thought "This is C++. We use references in C++". Later, another programmer makes a change to the function do_something and ends up changing the value of the parameter. Now I'm left with a situation where I know a value was correct at line 100 and was incorrect at line 200 in a different function and I have to work out where the value changed. And I didn't write ANY of this code.
Had the first programmer written const int& then yes, the problem wouldn't have occurred. But, maybe, if they had had to write do_something(&x) if the prototype was do_something(int&) and do_something(x) if the prototype was do_something(const int&) we might get more const correctness.
And a similar issue occurs when using polymorphism. I know things were right at one line, and I know they had gone wrong at another line but it is impossible to determine where things went inbetween. Polymorphism can be a good thing but it can, and more often than not is, be abused which leads to more maintenance headaches, not less.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
It's an Ada example but still holds true in any language:
n tr ol#Isn.27t_goto_evil.3F
http://en.wikibooks.org/wiki/Programming:Ada:Co
Martin
Yes, the "old time languages" have beein improved all the time and now almost all have OO and other interesting features. I think it is worth to have a look at them.
a ge s_bookshelf)
(http://en.wikibooks.org/wiki/Programming_langu
I don't see the beauty in that. Beauty is all aesthetics, and I don't see any perl that's aesthetically attractive. There are perl programs that make you go "wow", one liners that creatively solve something that I would take two pages of C to do, but to me that's not beauty, it belongs somewhere else. I don't think most Picaso is beautiful either.
I am trolling
Well, typical slashdotter and all I don't really have that point of comparison, but yeah. Perl is great for short programs that I won't use again, or for when I need a program right now. But I've never found it nice to look at. If I'm writing a program I'll need to edit or can do in my own time, I'd far prefer Python or even C.
I am trolling
The NES used a 2A03
which is a 6502 with the decimal mode not working, and some sound registers added.
I think the BBC, VIC-20 and Apple 2 were plain jane 6502s, but some later models might have used the 65C02.
IIRC lots of optomechanical PC mice used a SunPlus 8 bit chip which was a cut-down 6502.
"My opinions are my own, and I've got *lots* of them!"
Tired of free ipod spam sigs? Opt ou
Read up on the "pointer aliasing" problem for instance.
Read up on the restrict qualifier of C99 for instance. It's a signal to the compiler that guarantees that two pointers so labeled in the same scope won't point to overlapping arrays.
> I spend most of my time looking at, and fixing, other people's code
// to /* */, and don't cast all of my variables before function calls. It's all style, however - just like whether you cast before function calls or not.
Actually, so do I. At my office, we're currently cleaning up a piece of software written in C. Because it didn't use C++'s lovely features, it's become a maintenance nightmare. Memory leaks spring up because objects don't destroy themselves and so when someone doesn't clean everything up right on returning from a function, the memory never gets freed. Passing by pointer to change variables leads to all sorts of cryptic code. To deal with the mess, they had these sprawling macros that kept getting redefined for each function. Etc. No fun.
> (const int)i
(const variabletype), not just (const int). Int is only the case of the example above. But I think we're on the same wavelength.
> And even if you change it to do_something((const int)i); it
> still won't compile if someone has written void do_something(int&);
Exactly; that's the point. The parent wants their code to be explicit. Good for them - if they want that, it is a *coding style* issue, and they can do it. If they think something is const and it isn't, congratulations - they just found a bug!
As for me, I indent with four spaces, use brackets lined up with the entry condition, only use tabs for comments, prefer
> And I didn't write any of this code
Congrats, you're debugging code of bad programmers. If they were bad programmers writing in C, you'd instead be tracing down spots where they misused pointers that were passed all over the place. And lets not even get into the other things you'd be dealing with (especially related to memory - bad programmers plus memory that doesn't clean itself up equals a disaster).
If you're having to deal with this poorly written code all of the time, your first step should be refactoring, not debugging. Const everything, strip out as much code as you can into function calls, group variables that tend to follow each other around into objects and then move function calls that they tend to get used on to the objects themselves, etc. There are a number of good books on refactoring out there.
In the process of consting things, you'll end up exposing functions that don't seem like they should be changing variables but actually are (among many other likely bug-causing situations). As you break code into smaller functions and group variables into objects, you increasingly gain the ability to const entire member functions. Errors start getting thrown where variables are being changed when they shouldn't be; the code ends up a whole lot cleaner.
> I know they had gone wrong at another line but it is impossible to determine
> where things went inbetween
Of course it is possible. You put debugging statements or breakpoints in the called object possibilities for the function; it's no harder than if than if there was no polymorphism and you were using flags or duplicated functions to represent the situation instead of polymorphism (which, by the way, would produce far uglier code). Plus, properly done objects, when you use polymorphism, will have a way to identify themselves. Heck, my boss has been pushing our lab toward not just including debugging information, but outright self-test modules into objects.
And if you don't believe that polymorphism aids in maintenance, try out ITK some time. That's just a beautiful C++ paradigm. Trying to implement such an imaging library in C would give you the most god-awful bug prone spaghetti code, but using C++ keeps it nice and orderly. Cleans itself up, does its own garbage collection via smart pointers, every image can have itself using any datatype that it wants (thanks to templates - any number of bits, grayscale, RGB, YUV, etc), and you can build images off of each other (thanks to polymorphism); since transforms work on basic images, all transforms can work on any new type of image with any datatype without any new code (thanks to both templates and polymorphism); internalized self-test; etc. We use it in medical imaging.
We also have a halon fire extinguisher. Its always nice to have a fire extinguisher that kills people around.
Well, bash Fortran all you want, but for most scientific/engineering applications it's STILL the best, and will be the best for the foreseeable future. What can be done (and it's what we do here at work) is to write the math/scientific/engineering core of the application in Fortran, and put a C/C++/Visual Basic/Tcl-Tk GUI around it, if you wish. We've found this approach works really well.
FYI, this is what modern IDEs do using things like incremental compilation. Not that you should take this as meaning I'm a fan of them though; they're also slow memory-hungry pigs (and they tend to not let me use either emacs or vi key-bindings either, the heathens!)
"Little does he know, but there is no 'I' in 'Idiot'!"
The CALL macro language I use here uses a nice mix, I think.
:=, and block statements follow syntax like the this:
:= 1 to something DO", or just "LOOP DO", and the ENDLOOP can also have a WHEN clause attached).
Equivalence is either = or EQ (the latter is used with string variables to force a case insensitive comparison), assignment is
LOOP WHILE xxxx DO
blah
blah
ENDLOOP;
(Could also be "LOOP UNTIL xxx DO", or "LOOP FOR xxxx
CASEENTRY xxxx OF
CASE xxx:
statements
CASE yyy:
statements
CASE *:
default if present
ENDCASE;
Most interesting is the way it does IF blocks:
IF something THEN
blah
ELSE IF something else THEN
blah blah
ENDIF;ENDIF;
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.