3 ms·

The problem with this question is that, if it's not engineering, what is it? A better question is motivated by studying the history of chemistry and its progeni

The problem with this question is that, if it's not engineering, what is it? A better question is motivated by studying the history of chemistry and its progenitor, alchemy. That is: is software development alchemy or chemistry? Software development is alchemy. Just like alchemy, software dev is not standardized, everyone has their own idiosyncratic naming systems, classifications and rules-of-thumb. Like alchemists, software engineers are often jealous of their proprietary knowledge. Just like alchemists, they are admired, feared and loathed for having secret knowledge. And just like alchemists, you have to be exceedingly brilliant to work in such a chaotic field and get anything done. So, what changed alchemy into chemistry, and what will be the analog to that in software? Arguably the change started with notion of conservation of mass and energy, and the development of the periodic table (thanks to Lavoisier and Mendeleev, respectively). As for what that analog is for software, first we need a characterization of the field. With alchemy and chemistry both, it's essentially mixing stuff together, heating and cooling it, and seeing what happens. But what is it for software? First, software engineering is not computer science. Computer science is a tiny subset of software engineering. In daily practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live. (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work). I'd characterize software engineering as the set of solutions to a boundary value problem[0] described as "a set of interacting screens with behaviors pleasing to humans". The current solutions to this problem have been idiosyncratically defined by resource constraints that relaxed exponentially over time[1], and characterized by elements discovered at random, by necessity: e.g. kernels, processes, files, procedures, terminals, etc. In this analysis "language" functions as a kind of "coordinate system" as in physics[2][3], within which each of these elements are described, and within which elements are combined to make new elements, which eventually yield a solution to the boundary problem (which is termed "application"). There is some coorespondence with chemistry, in that we have "elements" which combine into higher-level structures, but we lack an analogy to "conservation of mass and energy". And our elements are still highly partitioned according to coordinate system (although there have been several[4] heroic[5] attempts to unify them within a single framework.) I don't particularly know what the standardization of software alchemy into software engineering will look like, but I'm certain that this analysis, or something similar to it, is the first steps in the right direction. Personally, I look forward to the day we can shed the considerable weight of our alchemical origins! 0 - https://en.wikipedia.org/wiki/Boundary_value_problem https://en.wikipedia.org/wiki/Boundary_value_problem 1 - https://en.wikipedia.org/wiki/Moore's_law https://en.wikipedia.org/wiki/Moore's_law 2 - https://en.wikipedia.org/wiki/Coordinate_system https://en.wikipedia.org/wiki/Coordinate_system 3 - https://www.rosettacode.org/wiki/Rosetta_Code https://www.rosettacode.org/wiki/Rosetta_Code - the same problem is solved in many languages. For applications: https://todomvc.com/ https://todomvc.com/ 4 - https://en.wikipedia.org/wiki/Lambda_calculus https://en.wikipedia.org/wiki/Lambda_calculus 5 - https://en.wikipedia.org/wiki/Turing_machine https://en.wikipedia.org/wiki/Turing_machine

zeroonetwothree 3y ago
The entire world runs on software now. It seems absurd to equate it with alchemy which produced no practical value.
- simpaticoder 3y ago
  I think you need to review the history of science. Alchemy did indeed yield many things of practical value, all of which were systematized and rolled into chemistry. And besides, the fact that an alchemy of one kind might be more valuable than an alchemy of another doesn't invalidate my point. It just means that once our field changes phase, it will be even MORE valuable.
dasil003 3y ago
Definitely an interesting analogy, I find it uncharitable towards the state of software engineering though. Whereas alchemy/chemistry had to unlock a model of the microscopic world based on observation of the macro world we were born into, software engineering was the entire creation of a new world that we built from the ground up. It’s not that we don’t have a sufficient understanding to build great and precise software works, it’s just that the macro space is so large and unconstrained without the physical limitations that keep problem spaces of physical sciences more tractable and comprehensible. I do agree SWE is still early days and will develop a lot, but I don’t think it will coalesce the way you’re suggesting though because we’ll keep dreaming up new things to do with arbitrary data and logic.
seabass-labrax 3y ago
> Computer science is a tiny subset of software engineering. In practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live. I agree with that... > (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work). ...but not so much with that! Computer science is immensely useful in real world work: it helps to be able to look at a task and recognise it as an application of a few, general theorems, say in the field of graph theory or distributed systems, and let that knowledge guide your implementation. Just knowing that the problem you're facing is mathematically undecidable tells you more than weeks of experimentation would, for instance. Perhaps it's often a mistake to ask about it as an interview question, but it's not a mistake to familiarise oneself with the theory. The issues are twofold with the relationship between computer science and software engineering. Firstly, typical computer science courses are simply not advanced enough. At the pace of a typical university education, one would need to get to doctorate level before being able to reliably make novel developments in a given field, but that probably won't sound like a good investment of time and money when one could be earning significantly above-average salaries in industry even without the education. I personally believe that making more intensive courses available would be ideal for a large number of otherwise very competent programmers who are limited by their lack of academic computer science education. Secondly, computers are too luxurious of an environment to necessitate rigour! If you're building a shelving unit, you won't need to perform complicated calculations to measure stress-strain curves or cantilevering forces. The tolerances are so wide that you can get bolt together about any planks of wood and make a piece of furniture that is mechanically adequate. Does that make cabinet-making alchemy? I think it makes it more like craftsmanship, but it's definitely not engineering! Likewise, most computer applications always have CPU cycles to spare, data storage on tap and flexible timing requirements, so innovation only really happens at the limits of the technology: hyperscale applications, safety-critical or embedded software. I still think it's slightly unfair to say that software development is alchemy, when it is to me more like a well-established but rather conservative craft, which is only occasionally pushed into academic study and engineering rigour when the stakes are high enough.

zeroonetwothree 3y ago

The entire world runs on software now. It seems absurd to equate it with alchemy which produced no practical value.

simpaticoder 3y ago
I think you need to review the history of science. Alchemy did indeed yield many things of practical value, all of which were systematized and rolled into chemistry. And besides, the fact that an alchemy of one kind might be more valuable than an alchemy of another doesn't invalidate my point. It just means that once our field changes phase, it will be even MORE valuable.

dasil003 3y ago

Definitely an interesting analogy, I find it uncharitable towards the state of software engineering though. Whereas alchemy/chemistry had to unlock a model of the microscopic world based on observation of the macro world we were born into, software engineering was the entire creation of a new world that we built from the ground up. It’s not that we don’t have a sufficient understanding to build great and precise software works, it’s just that the macro space is so large and unconstrained without the physical limitations that keep problem spaces of physical sciences more tractable and comprehensible. I do agree SWE is still early days and will develop a lot, but I don’t think it will coalesce the way you’re suggesting though because we’ll keep dreaming up new things to do with arbitrary data and logic.

seabass-labrax 3y ago

> Computer science is a tiny subset of software engineering. In practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live. I agree with that... > (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work). ...but not so much with that! Computer science is immensely useful in real world work: it helps to be able to look at a task and recognise it as an application of a few, general theorems, say in the field of graph theory or distributed systems, and let that knowledge guide your implementation. Just knowing that the problem you're facing is mathematically undecidable tells you more than weeks of experimentation would, for instance. Perhaps it's often a mistake to ask about it as an interview question, but it's not a mistake to familiarise oneself with the theory. The issues are twofold with the relationship between computer science and software engineering. Firstly, typical computer science courses are simply not advanced enough. At the pace of a typical university education, one would need to get to doctorate level before being able to reliably make novel developments in a given field, but that probably won't sound like a good investment of time and money when one could be earning significantly above-average salaries in industry even without the education. I personally believe that making more intensive courses available would be ideal for a large number of otherwise very competent programmers who are limited by their lack of academic computer science education. Secondly, computers are too luxurious of an environment to necessitate rigour! If you're building a shelving unit, you won't need to perform complicated calculations to measure stress-strain curves or cantilevering forces. The tolerances are so wide that you can get bolt together about any planks of wood and make a piece of furniture that is mechanically adequate. Does that make cabinet-making alchemy? I think it makes it more like craftsmanship, but it's definitely not engineering! Likewise, most computer applications always have CPU cycles to spare, data storage on tap and flexible timing requirements, so innovation only really happens at the limits of the technology: hyperscale applications, safety-critical or embedded software. I still think it's slightly unfair to say that software development is alchemy, when it is to me more like a well-established but rather conservative craft, which is only occasionally pushed into academic study and engineering rigour when the stakes are high enough.