I don't quite know how to put it, what follows is a rough draft of an idea, maybe someone can help me to reword it, or perhaps it's trash.
Since its inception, computer science has had two "camps": those who believe CS is engineering, and those who believe CS is mathematics. The reason why we are seeing all of this fuss around LLMs is that they are a new front of this feud. This "extends" the usual debate on emerging technologies between Thymoetes and Laocoon.
Something that works 99 times out of 100 is 99% correct from the first perspective and 100% wrong from the second.
LLMs are therefore a step forward if you take the first view, a step back if you take the second.
If you accept this interpretation, an interesting consequence of it is that your outlook on LLMs is entirely dependent on what amounts to your aesthetic judgement.
And it's very hard not to have rather strong aesthetic judgements on what we do 40 hours a week.
Camp 3: Those of us who have viewed coding as a craft.
Math - the study of well defined concepts and their relationships. Solving problems with proofs.
Engineering - solving well characterized problems based on math and physics (which can include materials with known properties, chemistry, approximations, models, …), and well defined areas of composability (circuits, chemical processes, structural design, …)
Craft - solving incompletely characterized problems with math, physics, engineering and enormous amounts of experience, intuition, heuristics, wisdom, patterns, guesses, poorly understood third party modules, partial solutions pulled from random web sites …
Art - Solving subjective problems by any means necessary.
> Engineering - solving well characterized problems based on math and physics (which can include materials with known properties, chemistry, approximations, models, …), and well defined areas of composability (circuits, chemical processes, structural design, …)
Eh, I think you’re overselling how precise and well defined engineering is in other fields. Engineering in other fields is just as much dealing with poorly characterised problems as it is when writing code (it takes quite a lot of characterisation to go from “we want a bridge here”, to an actual damn bridge, and that’s all an engineers work).
Really the core of engineering is just a very broad set of practices and principles that allows people to solve poorly characterised problems using maths, physics, enormous amounts of experience, intuition, heuristics, wisdom, patterns, educated guess etc in a reasonably consistent and repeatable manner. Doesn’t matter if you’re building a web browser, a motherboard, or a bridge. You don’t get a good result without a healthy dollop of wisdom, experience, educated guesses, and a handful of fuckups (which hopefully you notice before you let people use the thing).
Engineering in other disciplines is no less messy, haphazard, and experimental than it is in software. It just isn’t as publicly documented as it is software, probably because it’s hard to build an open source bridge.
Well, most engineering fields have well defined applied math that spans from the problem domain to the solution domain.
Logic in digital circuits.
Algebra and calculus for analog circuits, most physical objects, properties and processes.
Differential equations for dynamical systems and dynamical behaviors.
Sure there is a lot of creativity in engineering, but there is usually a whole area of math known to be suitable for expressing solutions clearly, given the area of engineering.
Contrast with the utter lack of standard notation across software tools and implementations, for describing all the trade offs, gotchas, glue, historical drift & complexity, theories of memory, caching, user affordances, potential overflows, races, etc. that is implied by a program’s code.
Sometimes a language provides islands of engineered code, like message passing in Erlang, or memory management in Rust, or a precise mathematical library like BLAS.
But most aspects in most software programs are created ad hoc, or inherited from someone else’s rats nest of an implementation, and never formalized completely, if at all!
Any clarity in representation quickly leaves planet applied math.
> Sure there is a lot of creativity in engineering, but there is usually a whole area of math known to be suitable for expressing solutions clearly, given the area of engineering.
Take it from someone who’s studied the maths you’ve described and applied it in a professional capacity. Just knowing the maths isn’t anywhere near enough. It’s like knowing how quick-sort works, interesting and useful, not even close to enough to actually build anything.
> Contrast with the utter lack of standard notation across software tools and implementations, for describing all the trade offs, gotchas, glue, historical drift & complexity, theories of memory, caching, user affordances, potential overflows, races, etc. that is implied by a program’s code.
The entire field of computer science is dedicated to developing and using this type of notation to describe and understand the basic principles that underpin every programming language, database and algorithm you’ve ever touched. The notation exists, you just don’t use it. In the same way an engineer in another field doesn’t bother doing structural analysis, or circuit analysis from first principles, they just grab a pre-finished tool and apply it to their problem. Normally by just passing the problem to a computer that does all the heavy number crunching, and checking the outputs make sense.
> But most aspects in most software programs are created ad hoc, or inherited from someone else’s rats nest of an implementation, and never formalized completely, if at all!
>
> Any clarity in representation quickly leaves planet applied math.
Again, I think you’re vastly overestimating the precision of other fields of engineering. There might be more rigour in design in some places, but only because “just making a thing and see if it works” is expensive, but other engineers absolutely spend huge amounts of time just making things to see if stuff works.
There’s a reason why “safety factors” are a thing, and reason why they’re usually 10x or greater. That safety factor is also the “we’re not sure how well this works, so we made it ten times stronger than we think we need, just in case, factor”. Engineering in other fields is people doing maths all day long, it’s mostly reading data sheets, assembling Lego brick components, and hoping to hell the manufacturer didn’t lie too much on their data sheet. Plus some design and simulation on a computer for good measure.
You wanna see “ad-hoc or inherited from someone else’s rats nest of an implementation” in a different field of engineering. Then go look at any electronics catalog, or lookup YouTube videos of people testing parts against the specsheet and discovering how wildly different they can sometimes be.
Dodgy, badly implemented, never formalised engineering exists everywhere. That’s why bridges collapse when they shouldn’t (Genoa Bridge), why planes crash when they shouldn’t (Boeing 737 Max), why cars emit more emissions than they should (VW), why buildings get emergency modifications after being built to prevent them from being blown over (601 Lexington Avenue). Software engineering does not have a monopoly on botches, last minute hacks, and dodgy workarounds. Engineers in other fields were merrily employing all of them to great effect for centuries before software turned up.
I recall a self taught dev (or maybe from a bootcamp) coming up with a cascade of nested if-else, nested 8 deep. Someone with a background in CS asked him what he was trying to do and basically concluded that what he was trying to do could be expressed as a state machine. To which the initial dev replied that it was "way too fancy" and that he didn't need the code to be fancy, just work.
The ugly part: The nested-8-deep solution was faster to market and costs less. And, it will be thrown away in 6 months during the "big rewrite after we scale". So the perfect-is-the-enemy-of-good state machine solution written by an expensive engineer has less value. Oompf.
Possibly. Or not. It could be that the elegant expression can be written in less time by the expensive engineer, doesn't need to be rewritten in 6 months, and it may be that both of these people are getting paid the same anyway. So you can make up any "just so" story that you like about a made-up anecdote. If programs A and B implement the same function and both have adequate performance, then the differences between the two artifacts come down to style.
> If programs A and B implement the same function and both have adequate performance, then the differences between the two artifacts come down to style.
What about maintainability? Extensibility and ease of debugging?
I've seen chunks of projects re-written, just because it was simply impossible to extend them without significant efforts!
Well yes, that's what we're talking about. I mean that the compiled artifact is equivalent, but of course you may have reason to care about the style of the code.
I have a camp 4: viewing coding as a roadblock. A necessary obstacle to achieving some result. This is how companies view programming. They don't know about it, don't care about it, they just know they have to do a lot of it to produce their next product.
Tacking roadblocks as they come up in service, creating a better product … that sounds a lot to me like engineering except with some words twisted around?
I cringe every time I see someone use the term "craft" in the context of computer programming. It feels like a desperate attempt to seek adoration as a "sub-genius" in a poorly understood field. Computer programming is hard because the platform is either poorly documented or changes very quickly. Too much of my professional work is about finding a "super hero" (their term, not mine) solution to a poorly documented problem. It is tiring, and not-at-all heroic. Coding bootcamps have taught us that when you tear down the gatekeeper walls, more people can write CRUD apps (that the world actually needs) than ever thought before.
[otherwise a (code) monkey could do it] is missing the point of programming.
I know managers who code (occasionally) who think similar. I thought so personally before I had actual prolonged experience with professional programming.
It is hard to express it concisely: why it is fundamentally wrong (category error: like thinking that perl regexes can be reduced to DFA--it is impossible in the general case even if DFAs can [sometimes even should] be used in many cases instead).
It is the same reason why waterfall programming fails most of the time. It is the same reason why generating code from UML diagrams produced by analysts is also a failure in the general case. It is the same reason why log normal distribution can be a good model for software estimation https://news.ycombinator.com/item?id=26393332
And no, you can't replace all programmers with a LLM prompt for the same reason (at least until [if ever] it reaches AGI and then humanity would have much bigger problems).
"agile" became a noun but if you look at the origins, you might get why "craft" may be applied to programming. Try "The Pragmatic Programmer" book.
Engineered projects, formally (or close to it) verifiable: 3D rendering pipeline, distributed database management, garbage collection process, ...
And craft. Which, based on the internet I have experienced, many apps unjustly inflicted upon me, and some memorable restarts between game saves, is most code.
Craft code necessarily involves amateur code, code which isn't economically worth engineering (when you can just throw unit tests at it. Or just wait for user reports!), code referencing weakly characterized libraries or interfaces, and code involving features that have become complex enough that the best reference model for its expected and unexpected behaviors is now itself.
Bzilion's Law of Coding Formalism Levels: "Any ambitious enough software project will descend into an exercise of pure desperate craft. Just before it becomes gambling."
I think this comment may miss the computer forest for the computer science trees. For a large portion of the world, computers aren’t engineering or math, computers are a tool to get something else done.
For those people, unless something fit within an existing (but large!) range of use cases, they were out of luck without having an engineer or mathematician figure it out for them. Suddenly, there is a glimmer on the horizon that all of that possibility the computer science people see every day could be unlocked for the users, and even if it only works 5% of the time, that is enough to get them excited in ways that are hard to describe to the computer science people.
This is a fantastic point, and it's what most software businesses have at their core. They just provide the tools to get something else done. A lot of these smaller places are going to be devastated when people become far more self reliant (or I should say reliant on the AI providers) than them.
For the rest of the world, while some might be excited by what you describe (and it that works for them, that's great!), I believe in general the interpretation is far simpler: me like shiny.
This is some very CS high-horse thinking. I work with people who are already using it in ways that meaningfully improve their existing workflows. It isn’t doing anything special to someone who makes a living on computers, but it is doing things they couldn’t do without those people.
Genuine question, are you seeing non-coders using it to do any useful coding? As a developer, I find that it is wrong more often than it is right and were it not for my domain knowledge, I would have no idea why (or sometimes when.)
A “tool to get things done” doesn’t seem to contradict the math or engineering point of view. Which is to say, a screwdriver is an engineered device that is also a tool (it also has a mathematical description I guess, just, a fairly boring one from a pure math point of view I guess).
Imagine going to school, a boot camp, or being self taught in everything about screwdrivers and screws. You can discuss at length the advantages and disadvantages of different shapes (Robertson bits > all), materials, screw threads, etc. You can custom design a screwdriver and screw for a specific application, taking into account all of the relevant constraints.
Now imagine the guy who needs to tighten a loose cabinet door.
Screwdrivers don’t have nearly the complexity or ability to generate work leverage that computers do, moving even a few percent of those capabilities from the first group to the second is huge. It is, at minimum, Excel huge.
This nails it on the head pretty much for me. I'm personally hugely interested in the potential of LLMs to enable me, a non coder, to create programs that might only have marginal utility to others, so are likely not going to get built by anyone who actually knows how to do this stuff, and aren't exactly important enough for me to actually learn how to code (I don't really have the right type of brain for it anyway) but are interesting / useful enough to me to figure out how to get LLMs to make them for me, as I don't really care how they work as long as they do.
> the usual debate on emerging technologies between Thymoetes and Laocoon.
Could you expand on this?
> Something that works 99 times out of 100 is 99% correct from the first perspective and 100% wrong from the second
Interesting. From a _manufacturing_ perspective, you can't achieve 100%, you can only get asymptotically closer to it with statistical process control. And of course there are limits to the perfectibility of humans.
This suggests that the big deployment of AI will be in areas where there is no clear boundary between right and wrong answer.
>> the usual debate on emerging technologies between Thymoetes and Laocoon.
> Could you expand on this?
Not important, it's just a rhetorical flourish. In the second book of the Aeneid, Thymoetes is the guy who says (paraphrasing) "let's bring the horse inside" and Laocoon is the guy who says (literally) "beware of Greeks bearing gifts".
> This suggests that the big deployment of AI will be in areas where there is no clear boundary between right and wrong answer.
"AI" is an umbrella term at this point. If by AI we mean LLMs or similar technology, then my hunch is to agree with the statement. I don't think this is particularly controversial though, IIRC Yann LeCun said something similar.
There's never been a camp of computer science that said anything but the truth, which is that CS is applied mathematics.
However, there is a pragmatic school of hacking, which says that results are all the matters. If you're in a startup, you should be pragmatic, and worse is better.
TIL I need to tell my school to change my degree on diploma
What reasoning are you using to come to conclusion that software is not engineering?
>The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property
Because engineering is a specific discipline that balances physical force, the nature of materials, and costs, to produce a physical thing (a building, a bridge, a sewer system, a reservoir... "Software engineering" is a metaphor for the body of knowledge and ability to design and construct software systems. Unlike engineering, there aren't that many right answers.
Whenever you have to qualify a noun with something else, the result is something narrower than the original noun, and often completely different:
Physical things are obviously subject to physical laws. With software, things may be less clear. Sometimes they are not. The key part of engineering that's highlighted by such cases is that mathematical models are relevant. This is why an engineer sometimes has to say "no, that won't work".
Then if you see yourself as a professional and if you have a strong character, you say it. If you're a real engineer, you and everyone knows this is part of the job, but if you're a SE, generally speaking you're going to meet resistance. Your resignation letter should be ready in your pocket.
The surprising thing to many of us is that the "software engineer" title has been specifically associated with deprofessionalization of the job and the view that is moving away from true engineering. See the Dijkstra link I posted elsewhere in this thread.
I think your definition of engineering is a curious mix of "No true Scotsman" fallacy and a bit of circular reasoning.
My parents were very respected traffic engineers. One was concerned with traffic inside cities, another with road design. One couldn't give less care about "nature of materials and physical force" while figuring out where to put traffic lights and close roads, while another had a set of standards (say a lorry's turning radius, sign sizes etc) which they've applied without thinking about costs or even producing a pysical thing. That was done by some other contractor in a sense anyway.
A friend of mine is an electrical engineer. He maintains electric motors and I guess he would fit your definition better. At the same time, how much an electrical engineer has in common with traffic engineer? Or say an air traffic engineer? Or a construction engineer? I would say what they mostly have in common is the "engineer" part as they are doing completely different jobs in completely different industries. I might even go further and say when someone calls "Alice is an engineer", it is just a shorthand for "Alice is a mechanical [or some other] engineer".
So those were the differences, but lets see the similarities. When a traffic engineer gets a project to see if they can increase the traffic flow from point A to B it usually follows the common pattern of finding out the current situation, figuring out a solution, testing/simulating it out and then making the project/solution on what should be done. Then when the solution gets implemented, some details can be re-adjusted etc. I did simplify it a bit, and I'm unsure in the exact english phrases, but I think you get my point. Software engineers that I know follow the exact same process. Oh, a database is overloaded, lets see what we can do about it. Can we give it more hardware? No, as thats too expensive? What about if we scale up/down the services/workers/instances/nodes/pods calling that database? Can we simulate that? What do the metrics say? Etc etc. You see where am going with this? In essence, there is no difference.
My point is, if you cannot call Software Engineering only by the word "Engineering", then you cannot call anything else (just) Engineering. You can dance around this whatever you like, and define Engineering either narrowly or widely enough not to include Software Engineering (just like you did), but at the end of the day this isn't a natural science like say Maths or Physics. You cannot say 2+2=5, but you can say Engineering is X. But then, lets be honest here, and I suspect this is the root cause of this: it's about exclusivity and status. Engineers, doctors, lawyers, electricians, plumbers and a myriad of different professions like having guilds (or similar organizations, speaking in general here), and like having artificial scaricity. This brings status, it brings money, it brings power and influence. It cannot work if everyone is allowed in. It's what's simply called gatekeeping. It's what hiding behind a dismissive, elitist sentence I've heard too many times: "Oh, but he's no engineer". So if we're honest here we can call a spade a spade.
I'm old enough, and have been in the profession long enough to recall "software engineering" as a new term attempting to make the profession sound fancier. When I started we were programmers. We wrote programs. Sometimes we were also called "coders" though that wasn't understood outside the profession, where "programmer" was. Then the term "software developer" came along, and we were all "developers." Now, when I'm talking about my team of "engineers" I'm speaking of all my programmers. They create software, with all the design, authoring of code, and wielding of infrastructure that entails. Does that make the actual practice "engineering?"
Let's resort to definitions, with apologies.
Engineering
> Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings.[1]
That certainly doesn't make Software Engineers what are traditionally thought of as "engineers." So... on to Software Engineering:
Software Engineering
> Software engineering [is] the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software and the study of these approaches; that is, the application of engineering and computer science to software. [2]
That description does not fit what most of us do when we write or create software. Perhaps it should. We'd be better off in many cases. But programmers are often closer to gardeners than engineers in that we approach solving problems through empirical processes, testing and verifying as we go. TDD is an admission of the need to do just that. So is Scrum (empirical process control). There absolutely are cases where algorithm optimization using the latest research must be applied just so. There absolutely are cases where applying gradient descent and convolutional neural nets in specific fashions applies. Most of us are gardeners growing our systems, or carpenters building out a feature, though. Programmers. Software engineer makes it sound loftier, just like sanitation engineer makes trash collection sound loftier.
I will absolutely concede that I still use the "engineer" terminology on a day to day basis, my opinion on the internet notwithstanding. But it is a label that is weakly applied for fashion and connotation, rather than for its distinct meaning, and I suppose that is what I tilt at here on HN. Apologies for the pedantry.
Even on the pages you've linked, Software or Computer Engineering is still Engineering. You might say that it just doesn't fit the definition (from the same exact page), but then you can either take the argument with the Wikipedia authors or just think on it on your own.
I'm sure that say a conteporary civil engineer would scoff at calling Nikola Tesla an [electrical] engineer, just like you're virtually scoffing at calling a Software Engineer only by Engineer.
Admittedly that the software field is young, but does it make it "worth" less? To entertain your argument, do you consider a person programming PLCs an electic engineer? What's the fundamental difference between a software programmer and them? I don't see any. So you cannot call one an [Electrical] Engineer and another one "just" Software Programmer.
Gardener is not an engineer. On a ship there are usually at least two departments: Deck, and Engineering. The latter are people in charge to make sure that ship's systems are up and running at all times. There is no theory behind it, or pretty much any maths. It is mostly boring maintenance. And I would be surprised that anyone would call those people non-engineers. So why bring this up? Engineering definitely has a vague connotation with certain terms like electrical power, mechanics, devices, construction, materials etc. As the gardener or a trash collector doesn't deal with any of those, noone is considering a gardener an Engineer.
One can say, oh it's the title inflation, but that actually applies to any profession then. Or to put it differently, what makes a person an engineer? The work that person does, or the title it was given to them by some institution? Is it both? Is someone an engineer but is a career politician? I sure know one, and the guy will always be legally an engineer. This is a classic "what makes an art, Art?" question which is another can of worms I'm not going to open.
So I'm not sure what you're arguing then when all of this is on a very shaky ground. My position is that it is just a matter of a title and social convention. If you're a part of a engineering department, then I'm sure people outside of that department will call you an engineer. Inside of that department you might be a programmer of say a backend service, I could be a platforms guy, Alice could be QA engineer, and Bob could be a hardware engineer. It just doesn't really matter in the end. All of those are just social constructs which change with time. Or if we take it to a institution level: in some countries you have legally recognized Software Engineers (as I found out in other threads), in a country like mine you don't have one, whether we like it or not. So as I said in my previous post, this isn't maths or physics, and it is just a social construct which varies all over the world. So arguing about it is like arguing about the definition of art. I like spending time on engineering more so that's it from me ;)
You can define engineering in many ways, and none of them is equally right in every possible context in which the term is used (so it has this in common with every other word).
However, there are some ideas clustered around that seem to have something to do with it. Engineering on a ship has to do with electrical and mechanical systems, and in a highly constrained set of outcomes, essentially reducible to a single bit at any point in time. (Either the systems are up and running right now, or they aren't.) Within this system of evaluation of outcomes, it's not surprising if the engineers in this context aren't using maths every day but are engaged mainly in more practical actions. However, you can be sure that they know a lot of safety tolerances and operational characteristics of various ship systems that would be characterized as mathematical, even if they are mostly operating well within tolerances that make these operations routine.
One reason why people argue about "software engineering" is that there are authors who define it specifically to include scientistic or bureaucratic rituals that have no mathematical underpinning, while excluding the difficult mathy bits of engineering. The further you get from actual engineering, the more common this definition gets.
Software used in medical devices, airplanes, and other applications where mistakes can lead to death does exist, and there has been tragic examples of software bugs killing people:
If you have full expectation and support from your superiors that you may shut down software development operations for ethical reasons based on your technical expertise, you might be a real engineer.
The software people who work on embedded systems like medical devices, speakers, sensors, electronics etc. are doing engineering all the time. Although I guess it's mostly EEs or computer engineers who do that kind of work, but many concepts of CS are still relevant there.
I find your observation about the two camps in computer science quite compelling, and it got me thinking about another analogy that might further illuminate the LLM debate: the evolution of cities.
Urban development can be seen as a balance between careful planning (akin to the mathematics camp) and organic growth (resembling the engineering camp). A city designed with a focus on aesthetics and theoretical frameworks might be visually appealing, but it could lack adaptability. On the other hand, a city that grows organically may not be as cohesive, but it's more practical and responsive to its inhabitants' needs.
This parallel can help us better understand the emergent properties of LLMs, which arise from their complex interactions. By appreciating both the engineering and mathematics perspectives, we can gain a more comprehensive understanding of these properties.
Moreover, the balance between early adoption and risks, as seen in urban development, can also apply to LLMs. Early adopters of LLMs can tap into their potential, but they must also be aware of potential risks, such as biases and ethical concerns.
Well, the interesting question is whether LLMs will enable programming to go back to being interesting.
So much of programming is rote boilerplate garbage simply linking things together and so little of it is actual creative thought. If LLMs could actually generate the rote boilerplate, programming would be soooo much better.
The issue I see with attempting to claim that these are merely differences of opinion is that it only takes a single bug in your code for someone well-versed in exploitation to not just steal all your data but often replace your entire program with their own evil one. I spend quite a lot of my outreach efforts essentially having to explain to the people who think software development is somehow unrelated to math that once you accept a bug into your codebase the effects tend to be as non-local as accepting "1+1=3" into a math proof, resulting in lost privacy, lost money, or even lost lives.
Since its inception, computer science has had two "camps": those who believe CS is engineering, and those who believe CS is mathematics. The reason why we are seeing all of this fuss around LLMs is that they are a new front of this feud. This "extends" the usual debate on emerging technologies between Thymoetes and Laocoon.
Something that works 99 times out of 100 is 99% correct from the first perspective and 100% wrong from the second.
LLMs are therefore a step forward if you take the first view, a step back if you take the second.
If you accept this interpretation, an interesting consequence of it is that your outlook on LLMs is entirely dependent on what amounts to your aesthetic judgement.
And it's very hard not to have rather strong aesthetic judgements on what we do 40 hours a week.