![]() ![]() Because we are often tackling the same problems in C, Perl, Scheme, Smalltalk, and so on, we can usually find a way to analyze them and code solutions using common designs. The idea of programming-language determinism has some truth to it, but is overrated. Edsger Dijkstra believed that programming in Fortran or Basic not only condemned us to produce bad code, it corrupted us for life. Roughly, it holds that the vocabulary and syntax of our language guide and limit the way we see the world: form dictates content. There is a famous view of linguistic determinism known as the Sapir-Whorf hypothesis, framed by Edward Sapir and his student Benjamin Lee Whorf. I’m going to state my biases up front, then attempt to justify them by example. Edward SapirĮach pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Human beings do not live in the objective world alone, nor alone in the world of social activity as ordinarily understood, but are very much at the mercy of the particular language which has become the medium of expression for their society. Whether you’re writing Fortran or Java, C++ or Smalltalk, you can (and should) choose to write good code instead of bad code. You can drown in a bathtub with an inch of water in it, and you can easily write a completely unreadable and unmaintainable program in a language with no gotos or line numbers, with exception handling and generic types and garbage collection. And a programming language that has been engineered to promote good style and design can still be used to write terrible code if the coder is sufficiently creative. Just because a programming language allows you to write bad code doesn’t mean that you have to do it. You can implement good design and transparent style in almost any code, if you apply yourself to it. There are characteristics of good coding that transcend all general-purpose programming languages. But you can write a usable and maintainable program in Fortran in spite of its many hindrances. No one would want to program in Fortran today, since many better alternatives are available. Believe it or not, you can write good Fortran, as well as bad Fortran. I spent a significant part of my career in proximity to Fortran. Many of us have never seen real Fortran code, but we know what coders mean when they say, “You can write Fortran in any language.” The world has seen so much bad Fortran code that the name of the language is now a synonym for bad coding. If the coder is old enough, often that unfavorite language is Fortran. Every coder has a favorite general-purpose programming language, and many have an unfavorite language, too. Programmers have debated the merits of different programming languages since the dawn of programming. A good programmer can overcome a poor language or a clumsy operating system, but even a great programming environment will not rescue a bad programmer. Whatever language you write in, your task as a programmer is to do the best you can with the tools at hand. There’s no obfuscated Perl contest because it’s pointless. ![]() How Not to Write FORTRAN in Any Language There are characteristics of good coding that transcend all programming languages. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |