Consequences of Modern Software Development Abstractions

Question

I am currently writing a dissertation on the implications or dangers that software development methods or exercises might have today regarding the long-term effects of programming.

Just to make it clear: I am not attacking the use of abstractions in programming . Every programmer knows that abstractions are the foundation of modularity.

What I want to explore with this dissertation is abstractions with positive and negative effects that can occur in software development. As for the positive, I'm sure I can find many sources that can confirm this. But what about the negative effects of abstractions? Do you have any stories to share this conversation about when certain abstractions failed on you?

The main problem is that many programmers today are against abstractions, having no idea what abstraction does under the hood. This can lead to errors and poor design. So, in your opinion, how important is it for programmers to know what happens below abstractions?

The simplest example is from Joel Back to Basics , C strcat:

void strcat( char* dest, char* src ) { while (*dest) dest++; while (*dest++ = *src++); } 

The above function puts the problem: if you are concatenating strings, the function always starts at the beginning of the dest pointer to find the null terminator character, whereas if you write the function as follows, you will return the pointer where is the concatenated string, which, in turn, allows you to pass this new pointer to the concatenation function as a parameter * dest:

 char* mystrcat( char* dest, char* src ) { while (*dest) dest++; while (*dest++ = *src++); return --dest; } 

Now this is obviously very simple with respect to abstractions, but it is the same concept that I will explore.

Finally, what do you think schools prefer to teach Java instead of C and Lisp?

Can you please express your opinion and you speak on this issue?

Thanks for your time and I appreciate every comment.

Answer 1

First of all, abstractions are inevitable because they help us cope with the fascinating complexity of things.

Abstractions are also inevitable, as more and more is required for a person to perform more tasks or even projects. To solve this problem, libraries are used that wrap lower-level concepts and cause more complex behavior.

Naturally, the developer has less and less time to know the inner essence of things. The last issue I've heard about SO pages about is starting to learn JavaScript with the jQuery library, ignoring raw JavaScript altogether.

The problem is the balance between:

• Know the smallest and smallest details of some technologies and be their master, but at the same time you cannot work with anything else.

• A superficial knowledge of a wide range of technologies and tools, which, however, are sufficient for ordinary everyday tasks that allow a person to perform in several areas, possibly covering all aspects of a (moderately large) project.

Make a choice.

Some work requires one, the other another.

So, how do you think, how important is it for programmers to know what happens below abstractions?

It would be nice if people knew what was going on behind the scenes. This knowledge comes with time and practice, to a certain extent. Depends on what tasks you have. Of course, you should not blame people for not knowing anything. If you want a person to be able to perform various fields, this is inevitable, he will not have time to cover each to the last bit.

What is important is knowledge of the basic building blocks. Data structures, algorithms, complexity. This should be the basis for everything else.

Knowing the smallest details of a particular technology is good, but not essential. In any case, you cannot recognize them all. There are too many of them, and they keep coming.

Finally, what do you think schools prefer to teach Java instead of C and Lisp?

Schools should not teach programming languages ​​at all. They should teach the basics of theoretical and practical CS, social skills, communication, teamwork. To cover a huge number of topics and issues, to provide a wide angle of view for their graduates. This will help them find their way. No matter what they need to know in detail, they will do it on their own.

Answer 2

An example of abstraction failure:

In this case, a piece of software is required to communicate with many other third-party data processors. Communication was carried out using various messaging protocols; in this case, the transport method / protocol is not important. Just assume everyone is messaging.

The idea was to abstract the capabilities of each of these third parties into a single unified message format. This seemed relatively simple because each side performed a similar service. The problem was that some third parties used different terms to explain such functions. It was also found that some third parties had additional functions that other third parties did not have.

Designers of abstraction did not see differences in third-party terms and did not consider it reasonable to limit the scope of unified functions only to support common functions of third parties. Instead, a unified monolithic communication scheme was developed to support any functions of third parties considered at that time. In what was probably seen as a future step, they added a way to transmit an infinite number of name / value pairs along with a monolithic message in case of future data elements that could not process monolithic messages.

In the beginning, it became clear that changing a monolithic message would be difficult due to the fact that many people use it in mission-critical systems. The use of name / value pairs has increased. Each name that could be used was documented inside a large spreadsheet, and developers had to consult a spreadsheet to avoid duplication of function name value. However, the list became so large that it was discovered that collisions were often found for the meaning of names.

Most monolithic message fields now have no purpose and are stored mainly for backward compatibility. Names exist that can be used to replace fields in a monolithic message. Most interfaces now run through name / value pairs. In cases where the client intends to communicate with several third parties, each client must agree on the values ​​of the names available for each third party. It would be easier to just connect directly to a third party.

I believe that this illustrates that it is important from the point of view of the monolithic message from the consumer that the developers of the consumer code do not know what is happening under the covers. If designers thought that consumers of a monolithic message did not need to understand in detail the abstraction, there could never have been a monolithic message and its name / value pairs. Documenting an abstraction with statements about the input and expected output will make life a lot easier.

As for colleges not teaching C and Lisp .... they are tricking students. You better understand what is happening with the machine and the OS with C. You get a slightly different perspective on data processing and upcoming problems with Lisp. I used some ideas that I learned using Lisp in programs written in C, C ++, .NET and Java. Learning Java, even knowing just C, is not very difficult. Part of OO is really not specific to programming, so maybe using Java for this is acceptable.

Answer 3

Understanding the basics of algorithms (e.g. time complexity) and some knowledge of metal are important for developing / writing odors - good code.

I would suggest that education in modern abstractions and profiling is just as important. I feel that modern abstractions make me much more productive than I would without them, that they are at least as important as good fundamentals, if not more.

An important element that was absent in my education was the use of profilers. With regular and proper use, profilers can help alleviate problems with poor foundations.

Answer 4

Since you are quoting Joel Spolsky, do I take him for what you know about his Law on Artificial Abstractions? I mentioned this for future readers. http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Green and Blackwell Ironies abstractions talk a little about the efforts to study abstraction. http://homepage.ntlworld.com/greenery/workStuff/Papers/index.html

The term "astronaut architecture" is a reaction to excessive abstraction.

I know that I certainly curse the abstraction when I did not touch Java or C # after a while, and I want to write to a file, but must have an instance of Stream ... Writer ... Adapter .... Handler .. ..

In addition, Patterns, as in the Gang Of Four. It was great when I first read about them in the mid-90s, but I can’t remember the factory, facade, interface, assistant, worker, flies ....