Software Technologies

Belbinson Toby 14 Jun 2010
Stockholm, Sweden


Less Code Is Better

The less code that you write, the less that you have to read, the less that you have to maintain, and usually the program will be simpler, and will often run faster.

Rewrite It.

It finally compiles! You just finished that big hairy part of the project, and it seems to work! Yeah, there are a few messy areas and some parts are a little hazy, but you got it done!

...you just found a bug. It won't be too bad to fix, just go in and add another if-statement to detect for the special case, and you're good to go!

If it's broken, don't fix it. Rewrite it.

95% of the time you are better off rewriting all of the code. That little if-statement that you are adding, to fix an innocuous bug, may seem harmless, but it should be signalling disaster to you. It most likely means that your abstraction wasn't quite correct. So now you are making it a little bit harder to read. You are adding a little bit more code. It only takes a few minutes, and rewriting it would take hours or even days.

In the long run, you would've been much better off not fixing it, but rewriting it. Now that you have found a few more bugs, and added a few more patches, and it's been a few months, the code is getting hairy. Now you are having a hard time being sure that the new code isn't making more bugs. And it's taking longer and longer to work with the program.

If you would've just rewritten it to be correct, all these times, then you would have great code, solid abstractions, you would know the code inside and out, it would be readable and maintainable. After rewriting it a few times, the code just flows as well. It no longer takes as long to write it as it first did.

Sure, sometimes you end up dumping the project or you didn't end up making things that much worse, by not rewriting it, but it's near impossible to guess when the 5% will be. Don't play that game. Just rewrite it.

UPDATE: I've posted more of my thoughts on this in it's own essay.

Code Is For People To Read

Only as a side-effect is it for computers to run. The easier your code is to read, the better understanding you will have of it. You will have less bugs. It will be more maintainable.

Sure, coding super fast, inline assembly makes you feel macho, but being macho doesn't help when CPU architecture changes, and you have to go back in, and decipher the mess you made.

Correctness Wins

Do it the right way. If you don't have enough time to do things right, then don't do them.

It almost always costs more in the long run, to do things less than correctly. Most often the reason for incorrect code, is trying to do too much in too little time. This is the beginning of feature creep. You are entering the world of hazy abstractions.

Do yourself a favor, stop coding.

Stop Designing, Start Coding

Instead of spending all of your time on the whiteboard, drawing up elaborate plans, start writing code. Yes, your code is going to suck. It is going to be a mess. But what's the rule when our code is a mess?

Rewrite it.

Your program will always be better off if you spend a day writing it 6 times, rather than designing it 6 times and writing it once. Writing code, and forcing yourself to rewrite it if it is incorrect, forces you to figure out the abstractions, and allows you to do deal with the real problems, instead of guessing what they will be.

You aren't building a car. You can forget to hook up the brakes and still live.

Fortran for .NET allows you to create applications for the Microsoft .NET Framework. Lahey and Fujitsu have combined advanced compiler technology with support for Forms designers and Web Services to enable Fortran organizations to develop .NET applications with Fortran as easily as with other Microsoft .NET languages. Fortran for .NET consists of a Fortran compiler and associated tools designed to help you create applications that run in the .NET Framework.




Fortran for .NET compiler
Fortran for .NET language
Visual Studio .NET integration
Windows Forms
ASP.NET Web Forms
ADO.NET
Fortran for .NET compiler options
Restrictions on Fortran for .NET Code
Hardware and software requirements for Enterprise and Academic Editions
What can you do with Fortran for .NET and why would you want to?
The Fortran for .NET language system is included in LF Fortran v7.1 Enterprise and Academic editions.
--------------------------------------------------------------------------------

Fortran for .NET compiler

Th Fortran for .NET compiler targets Microsoft's .NET Framework. The compiler does not directly generate processor dependent object code; rather, it generates Microsoft Intermediate Language (MSIL) code assemblies and code modules. The code in an assembly can be executed on any computer that supports an execution engine called the Common Language Runtime (CLR), such as the .NET Framework.

The CLR does much more than provide the ability to operate on different operating systems, it also provides the basis for interoperability between different .NET languages, interlanguage debugging, versioning, and application deployment, among other things.

Applications that are targeted for the CLR are called managed applications, or managed code. Managed applications are required to be type safe and to present standardized interfaces, so that interoperability and security requirements can be met. Because some older Fortran features (such as COMMON and EQUIVALENCE) can violate the CLRs rules for type safety and interfaces, certain restrictions had to be placed on .NET applications that do not allow 100% compatibility with Fortran standards. For details on restrictions, see Restrictions on Fortran for .NET Code.