Showing posts with label programming language. Show all posts
Showing posts with label programming language. Show all posts
Wednesday, December 20, 2017
Which code is more readable?
We were asked, "Which code is more readable, one that uses longer variable names or short ones?"
Maybe some historical perspective will help answer this question.
In the very early days of computing (I was there), we used short variable names because:
* Programs were fairly short and simple, so scope wasn’t much of a problem.
- Memories were small, so programmers didn’t want to waste memory with long names.
- Compilers and assemblers were slow, and long names made them slower.
- Many compilers and assemblers wouldn’t allow names longer than a few characters, because of speed and memory limitations.
- We didn’t think much, if at all, about who would maintain a program once it left the hands of the original programmer.
As programs grew larger, one result of short naming was difficult maintenance, so the movement toward longer names grew stronger. It wasn’t helped by COBOL, which asserted that executives should be able to read code. Lots of COBOL code was littered with super-long names, but that didn't help executives read it.
The COBOL argument proved to be nonsense. Still, the maintenance argument for longer, more descriptive names made sense.
Unfortunately, like many movements, the long-name movement went too far, at least for my taste. It wasn’t because long names were harder to write. After all, a typical program is written oncem but read for modification and testing many, many times. So, if long names really made reading easier and more reliable, it was good.
But the length of a name is not really the issue. I’ve seen many programs with long, long names that were so similar that they were easily confused, one with another. For instance, we once wasted many days trying to find an error when the name radar_data_station_#46395_azimuth_reading was mistaken for radar_data_station_#46895_azimuth_reading. Psychologists and writers know well that items in the middle of long lists are frequently glossed over.
So, like lots of other things in software development, long versus short names becomes a tradeoff, a design decision for a programmer for which there is no “right” answer. Programmers must design their name-sets with the same kind of engineering thought they put into all their design decisions.
And, as maintainers modify a program, they must maintain the name-set, so as to avoid building up design debt as the program ages.
So, sorry, there’s no easy answer to this question, nothing a programmer can apply mindlessly. Just as it’s always been, programmers who think will do a better job than those who blindly follow simplistic rules.
Tuesday, August 15, 2017
Must a Developer Know the Language?
We were asked, "Have you ever applied for a software developer job where you didn't know the language?"
My story is not exactly the same as others might have, for several reasons, but I think it does answer the question.
There are two phases to my story. My first job developing software was at IBM, in 1956. At that time, I didn’t know any programming language, largely because there really weren’t any languages other than machine code. So, I spent two weeks in a closet learning my first computer language.
Actually, it was three languages at once: machine codes for the IBM 704 and 650, plus the wired “language” for the IBM 607.
The second phase of my story takes place some years later, when I became a consultant. In that role, I have helped many, many clients who were using languages I didn’t know—even though I knew quite a few by that time, including LISP, Smalltalk, APL, PL/I, COBOL, FORTRAN, C, Pascal, Simula, several home-grown special application languages, and the machine code for the IBM 7090, 1410, 705, STRETCH, Dec’s PDP-1 and a few other machines. I had also studied in a bookish way quite a few other machines while doing competitive analyses for IBM.
I was able to help those clients largely because their problems seldom had much to do with the details of their chosen language(s). Instead, they were people problems of all sorts. The problems that did wind up with a language embodiment were usually easy to spot using my general knowledge of computer languages and typical errors people made in using them. That’s why I’ve always insisted that professional developers should know at least a handful of different language.
I think there's an analogy here with the term "mathematical maturity," something we might call "programming maturity." Here's how Wikipedia defines mathematical maturity:
Mathematical maturity is an informal term used by mathematicians to refer to a mixture of mathematical experience and insight that cannot be directly taught. Instead, it comes from repeated exposure to mathematical concepts. It is a gauge of mathematics student's erudition in mathematical structures and methods.
For instance, a mature mathematician is able to transcend notational differences, unlike my tutorial student who flunked algebra because he had learned to "solve for x," but said, "You didn't teach me to solve for y."
We could easily use most of those words to define "programming maturity," the ability that allows you to succeed in a developer job using a language in which you have no previous experience.
Wednesday, June 21, 2017
Goals for Beginning Programmers
The question was, "What are some goals a beginning programmer should have?"
I’d have to disagree with those who answered, “Pick a language.” Instead, I’d say, “Pick at least two languages.”
I agree that you should avoid the “holy war” about which language is “better,” but the way to do this is to train yourself to be multi-lingual, or at least bilingual.
Pick two languages that are as different as possible, and do all your practice programs in both languages. Then take some time to figure out how each language has influenced your thinking about the program.
We’ve used this method for several generations of beginning programmers with remarkable results. One of our goals was to train programmers who could move into a new job where they used a language the programmer had never seen before.
Within two weeks, the programmer would be able to match the shop’s average.
Within four weeks, the programmer would be the best in the shop.
And within six weeks, the programmer would be teaching the others how to be better programmers.
Quite simply, our students achieved these ambitious goals, thus giving themselves a terrific advantage in the job market, with prosperous future careers.
Labels:
career,
coding,
goals,
productivity,
programming,
programming language,
teaching
Monday, February 13, 2017
Should I learn C++ or Python?
When I first saw this question on Quora, there were already 47 answers, pretty much all of them wrong. But the number of different answers tells you something: choice of programming language is more of a religious question than a technical one. The fact is that if you want to be a professional programmer, you should learn both—and at the same time.
When we teach programming, we always teach at least two languages at the same time, in parallel. Assignments must be done in both (or more) languages, submitted along with a short essay on why the solutions are different, and why the same. That’s the way to develop some wisdom and maturity in the coding part of your professional work.
Some of the respondents asserted that programming languages are tools. If that’s an appropriate metaphor, then how would you answer this question of a wannabe carpenter:
"Should I learn saws or screwdrivers?"
Do you think someone could be a top-flight carpenter knowing only one?
So, stay out of this quasi-religious controversy, which can never be settled. Instead, spend your valuable time learning as many different programming languages as possible, at least 5 or 6. You won’t necessarily use all of them, but knowing their different approaches will put you far above those dullards who say:
“I only know Language X, but it I still think it’s the best language in the world.”
Subscribe to:
Posts (Atom)