Slashdot invited people to ask some questions of Alexander Stepanov and Daniel Rose. Their responses to the questions are available in the forum post, Interviews: Alexander Stepanov and Daniel E. Rose Answer Your Questions. I gained some valuable insights reading their responses. Some of what I write below are not their words but what I have observed. Please do not accept these statements as final truths but as important insights. See my clarifications section at the end. Much of it is informative regarding technology and process surrounding technology.
Mastering software coding is mainly about doing it.
Mentors can give you a huge boost.
Formal education cannot teach everything. Real world mentors are vital.
Building things from scratch can expand the mind immensely.
Ambitious designs that fail can lead to successful practical designs if you persist.
Code has no clarity or real substance until you write lots of it and refine it down to the essentials.
Many years spent in assembly language could make one technologically formidable.
A minimalist approach to C++ is probably better. See Appendix B of Elements of Programming.
Software code excellence may be exemplified in their books.
The right code technology is hardware efficient yet maximizes abstraction.
An active effort to redesign the STL would probably be a good thing.
Commercial and social factors has affected the perceived quality of search technology.
Commercial and social factors can affect one’s own code in how it is perceived.
One size does not fit all. Not everyone will benefit from a software system design.
Be careful with node-based data structures. Their cache locality weakness can hurt.
A major challenge is raising one’s level of thinking beyond the immediate.
Focus, steadiness, and consistency.
Ability to change but with good reason.
A very strong connection to things of timeless meaning.
Programming Language Syntax
A precise syntax is preferable to one that is ambiguous.
Languages designed like verbal speech may lack technical certainty.
General Software Industry Concerns
Failure to use competent component architecture could spell long-term economic disaster.
Undisciplined software coding works in the short-term with limited long-term advancement.
Disciplined software involves well-designed, open specifications and competent components.
The above observations can benefit from some explanation.
Competent Component Architecture
The interview respondents mentioned that software probably should use good quality components rather than try to create alternative solutions to those components from scratch. A good quality component competently exercises the advertised functionality and does so efficiently. Competent component architecture are standardized, established components that are more than just functionality. A competent component is really fast, space efficient, and successfully addresses a good number of quality criteria in terms of interface, operations, and deployment.
I could go on about this, and there are books that do. Competent means high operational quality in addition to immediate functionality. This is an ideal though and not always practical. You should strive for it when it makes sense, but exercise the option to go another way if that fits the situation better.
Many experts and many of those immensely experienced in writing software can show you how competent component architecture can benefit you. Just as many experts and highly experienced practitioners can also show you how it does not. When I summarize the argument against competent component architectures what I perceive as the objection is that when you combine the components, the efficiency of the whole suffers.
I have not seen a survey, but if I were to guess, those who are against third-party or built-in, competent component architecture out number those in favor. It is not a clear-cut situation as to why but competent component architectures remain a solidly good idea. It is a matter of trade-offs you can accept.
Undisciplined Software, Ad Hoc Code
A few of the top experts in software development have described, and I am paraphrasing, that not using competent component architectures from beginning to end is the definition of undisciplined software coding. I believe this starts with the point of view that writing code without research, analysis, and systematic process is the definition of undisciplined. Writing lines of code without taking the time to consider and apply proven, pre-established solutions and methods absent justification is the definition of ad hoc.
I must admit, those are views I found expressed in formal literature about software development. They are not views I have seen widely expressed on the Web or in industry. People have found in some cases that some competent components in Java, Microsoft .NET, C++, and other environments have failed the competency test at scale.
As practitioners have repeatable disappointing encounters with competent component architectures, at scale, they may be less inclined to give future versions of specific component offering a second, third, or eight chance. Experience teaches them to lower risks to schedule and quality. Some then learn a personally effective, personally proven idiosyncratic process to raise the probability of an optimal result.
Node-based Data Structures
Several books that I have read about software writing use node-based data structures in the example code. When I see these data structures used in the books, I think of how useful they seem in supporting the organization of code in a way that is intuitively understandable. Especially in algorithms and graphics programming.
Node-based data structures are a class of data structures I have used in the past. I found them useful in small spots of a software program. That means I have used contiguous structures far more than node-based because the memory layout of contiguous structures is just too good to pass up. What about those books that exemplify node-based data structures though?
I remember a really good book on graphics programming I read in which I learned a tremendous amount about a specific graphics technology. That book had excellent code examples of how to apply the graphics technology and an example of a complete solution that if you replicated it, would move you from theory to the basis for a solution quickly. I couldn’t do it. I was not going to build a solution in the same way.
I read another great book on algorithms. Excellent descriptions, very solid demonstrations, and exceedingly consistent and understandable. Node-based data structures from beginning to end. None of this is a problem, it just points out that some data structures can be misidentified as appropriate solutions for most problems.
It is clear that computers are not designed in a way that makes node based data structures practical in terms of efficiency unless you optimize them. One way to optimize node based structures is to situate a contiguous structure underneath them. With plenty of time to design and write such a structure you can gain the advantages of both (ease of traversal through nodes, and binary map and reduce with contiguous when necessary). However, such implementations are not standard. Contiguous data structures are more straightforward in terms of efficiency but challenges the adaptability of software architecture.
Minimalist Programming Languages
Knowing everything about a programming language or using all the features of a programming language is not a good idea. A minimalist approach is to discover, agree upon, or understand the narrow set of features broadly useful to functional domain for which you build software. You can accomplish far more in a much strong way with this approach.
A lot of time can pass before you discover the minimal features. You wade through book after book, standards document after standards document. Significant experimentation only to see that there is a consistent pattern across most software solutions you have built. What you need is a model of minimal software development and the model for a minimal language.
Many books have been written on minimal software development. They do not have minimal software development in the title of the book, but go by other names. The intent is the same. I have read several of them and they informed my perspective.
The model for a minimal programming language? That, I have not seen so much. The first two versions of Microsoft C# was an example of this for a while. Alexander Stepanov states that Bjarne Stroustrup and Sean Parent has made general suggestions that could form the model of a minimal for a programming language. You will find their suggestions in Appendix B of the book, Elements of Programming. That section of the book is probably the best start. As one of the author of that section acknowledges however, that appendix may be many pages too short. You will have to stretch yourself a bit to gain a more complete definition of a minimal but comprehensive programming language that you can map onto other actual programming languages.
C++ Standard Template Library
Many large software companies have built their software on top of the STL programming library. It is the software programming library to know if you use C++. It was designed and put into circulation a few decades ago. Since then, it has been a primary tool in the definition of serious, significant software.
Several people including some of the original designers admit it could benefit from a strong revision effort. Although it is not perfect in every way does not diminish it’s usefulness or means it should not be used. It is the primary, competent component architecture for C++ that many other competent component architectures are built upon. In its present form, it is a proven software library that is calibrated to real world use.
You can gain a tremendous amount of insight into software development through a study of the STL. Any deficiencies some aspects of the library may have are greatly outweighed by the benefits the library provides overall. On that note, researching the deficiencies of the STL can inform a person’s knowledge about software design quality by example.
Applying Assembly Language
I spoke about the expertise someone can gain from rigorous use of assembly language. The person that can build a non-trivial solution in assembly language and repeat that over several projects has gained a unique mastery in software development. Why is this?
Assembly language requires that you engage with the computer in a very direct way. You intimately understand more complete details of how the machine processes code and data. Matters that general programming languages do not reveal. Therefore, when you do use general programming languages, your powers of insight and intuition pared with more conventional technological knowledge means you have the potential to design solutions that are both more efficient and adaptable.
I studied assembly language and it greatly transformed my productivity in terms of creating more efficient software. It is not for everyone. I see no harm in trying, but I know the material may not be accessible by virtue of what it is. Knowing assembly language simply means you have the potential to engage with the underlying computing system more comprehensively. It is not the only route to great software.
Depending on what software you are writing or for what purpose, you can be perfectly effective and masterful with general principles alone. The depth of hands-on practice of software development, regardless of what you know outpaces any theoretical knowledge of software. A solution that works reliably and accurately is more useful today than a perfected solution that remains unavailable.
It is also true that not every software writing process gains a huge boost from that understanding. Since some software development technologies do not allow you to do things you can do in assembly language, the useful extent of one’s knowledge of assembly language can reach a limit. Formulas in a spreadsheet, relational database queries, and I/O bound software frameworks are tools in which acceptable solutions can be achieved depending on the scale and scope of those solutions independent of deep knowledge of computer architecture. People of diverse backgrounds achieve those kinds of solutions often.
You can engage with the software writing process through a different route than what is presented here. I like what Alexander Stepanov and Daniel Rose have presented in their books and discussions. What they present is a great approach to software technology. It is not the only route to go, but one of several alternatives to incorporate into a software writing process. The perspective they offer is a way to achieve higher quality software. The best thing is to give a read and decide if it is the right approach for your process.
They describe some of their thoughts in more detail in a book by the title, From Mathematics to Generic Programming. It is a book I encourage others to read as it provides valuable insights into higher thinking concerning software development. I have reviewed their book and you may agree with me, that their book represents a powerful statement on the topic of abstraction.
I cannot find error with anything they have said. What they advocate will require willpower and motivation by those who write code who adopt their perspective. When the motivation towards a higher standard of quality is embraced and maintained through the will to not deviate for other reasons, then I can see their approach becoming prevalent. It is about the choices favoring expediency over genuine innovation.
The first major upvoted comment on the forum explains that real world conditions seem to diminish the likelihood that their approach will become mainstream. That person is right as to the present reality. Computers will have to change or the ideas more accessible in software.
Their ideas, observations, and suggestions are sound. There is much that can be learned from them. The thoughts they have shared is an immensely valuable contribution that can be put into practice.