3 ms·

This is a question I've struggled with ever since I started working in the field. In terms of definition, software development ticks all the boxes - depending

by qayxc 5y ago

This is a question I've struggled with ever since I started working in the field. In terms of definition, software development ticks all the boxes - depending on who you ask. Yet every way you look at it, something just doesn't feel right. Sure, there's best practices, models, a strong mathematical foundation, but on the other hand there's way too much freedom. By "freedom" I strictly mean lack of limitations. While the laws of physics dictate what can and can't be done in traditional engineering disciplines, the same cannot be said about software. A good design can be quantified, tested, and improved based on hard data (and eventual failure). A good program, however, is super hard to qualify. What even is "good maintainability" in terms of software? Is it a bunch of metrics like cyclomatic complexity, Halstead volume, and lines of code haphazardly cobbled together to form an arbitrary index value? With traditional engineering you have material properties like tensile strength that you can match against requirements and safety margins. What's the equivalent of tensile strength of a software product and can we measure it? For decades people in scientific computing have relied on Fortran programs that defy any modern notion of maintainability. The subroutines and "drivers" are limited to 6-character names and functions with >25 arguments are not uncommon. Yet they still work, are still used and stood the test of time despite archaic properties [0], which require users to memorise large tables of codes for data types and routine names. I also feel that despite these limitations, libraries like LAPACK are more readable and maintainable than modern C++ monstrosities like this [1]. [0] http://www.netlib.org/lapack/lug/node24.html http://www.netlib.org/lapack/lug/node24.html [1] https://github.com/nlohmann/json https://github.com/nlohmann/json

afarrell 5y ago
> Sure, there's best practices, models, a strong mathematical foundation, but on the other hand there's way too much freedom. I wonder if the same could be said of animation.
nyanpasu64 5y ago
Honestly I like well-designed modern C++ as a library/app developer; it's fast, type-safe, and (more or less) expressive. The worst thing about it is unnecessarily complex syntax/concepts (TMP scares me, `template<typename> using Foo` simplifies code, concepts are complicated but help avoid TMP) and slow compile times (unavoidable to my knowledge) I looked at nlohmann/json's homepage and I find the API surface perfectly readable (if you avoid ""_json and the more complex stuff, I didn't look at the library itself). Similarly I think that fmtlib is a beautiful piece of software (fmt::memory_buffer is beautiful, but I dislike the mysterious template errors when you write code wrong, and poor documentation for how to avoid them). It's as convenient as C format strings (but type-safe, and thankfully uses fat strings composed of a pointer and length, or begin and end, rather than null-terminated strings with O(n) strlen), and much better than C++ streams, which hold string formatting state (setw, precision) which is wholly wasteful for binary file IO, and is evil global state (possibly TU-local) for console IO. Modern C++ also a lot better than the 3+ layer deep inheritance hierarchies of 2000s C++, where Child::f() delegates to Base::f() which calls g(), which is a virtual function pointing to Subclass::g(), which delegates to Base::g(), which is alive and well in Qt and KDE code.
- qayxc 5y ago
  What bothers me about libraries like nlohmann/json isn't so much the style or the public interface (which is fine and I actually like, too). It's the fact that a conforming and performant JSON parsing and serialisation library doesn't require 22kloc in C++. That's madness. I also struggle to call a library "modern" that uses goto-statements. Especially if the library is even slower than smaller alternatives like [1]. But that's just my personal opinion, I understand that other people have different priorities and are fine with including 785kb of C++ template headers as long as the public interface suits their needs and taste. This is just an example for the kind of freedom software allows for, because it doesn't cost you anything and there is no objectively "better" in this case. [1] https://github.com/kazuho/picojson https://github.com/kazuho/picojson

by qayxc 5y ago

afarrell 5y ago

> Sure, there's best practices, models, a strong mathematical foundation, but on the other hand there's way too much freedom. I wonder if the same could be said of animation.

nyanpasu64 5y ago

Honestly I like well-designed modern C++ as a library/app developer; it's fast, type-safe, and (more or less) expressive. The worst thing about it is unnecessarily complex syntax/concepts (TMP scares me, `template<typename> using Foo` simplifies code, concepts are complicated but help avoid TMP) and slow compile times (unavoidable to my knowledge) I looked at nlohmann/json's homepage and I find the API surface perfectly readable (if you avoid ""_json and the more complex stuff, I didn't look at the library itself). Similarly I think that fmtlib is a beautiful piece of software (fmt::memory_buffer is beautiful, but I dislike the mysterious template errors when you write code wrong, and poor documentation for how to avoid them). It's as convenient as C format strings (but type-safe, and thankfully uses fat strings composed of a pointer and length, or begin and end, rather than null-terminated strings with O(n) strlen), and much better than C++ streams, which hold string formatting state (setw, precision) which is wholly wasteful for binary file IO, and is evil global state (possibly TU-local) for console IO. Modern C++ also a lot better than the 3+ layer deep inheritance hierarchies of 2000s C++, where Child::f() delegates to Base::f() which calls g(), which is a virtual function pointing to Subclass::g(), which delegates to Base::g(), which is alive and well in Qt and KDE code.

qayxc 5y ago
What bothers me about libraries like nlohmann/json isn't so much the style or the public interface (which is fine and I actually like, too). It's the fact that a conforming and performant JSON parsing and serialisation library doesn't require 22kloc in C++. That's madness. I also struggle to call a library "modern" that uses goto-statements. Especially if the library is even slower than smaller alternatives like [1]. But that's just my personal opinion, I understand that other people have different priorities and are fine with including 785kb of C++ template headers as long as the public interface suits their needs and taste. This is just an example for the kind of freedom software allows for, because it doesn't cost you anything and there is no objectively "better" in this case. [1] https://github.com/kazuho/picojson https://github.com/kazuho/picojson