Hacker News new | ask | show | jobs
by batteryhorse 2819 days ago
I disagree that engineering is the best approach to writing software. I think this is the fundamental difference between people who prefer static vs dynamic typing. People who prefer static typing are more likely to say that one solution is more "correct" than the other, whereas dynamic typing allows more flexibility.

I see writing software to be similar to writing music. Music has rules and structure, but leaves room for creativity and allows two or more highly skilled musicians to be able to play music together and improvise.

Static typing imposes limitations (kind of like government), whereas dynamic typing gives you more freedom (but requires responsibility)

11 comments

It's fine when we're talking about leisure-paced art, done by people who deeply care about what they do. But the reality of software development is different. Software is written primarily by people who treat it as a job, and care about it (on average) about as much as they're paid to - and they're being paid by people who don't care about the product, but its ability to make money. Software written in such environment is (unlike music) powering systems that affects livelihoods, health and safety of other people. With the market pushing quality down, we need a countering force pushing it up.

Or, imagine dropping all regulations around planes, cars, food, health care or infrastructure. Would things be handled better by artists, free to pursue quality? Maybe. Will majority of the providers be artists, or even care about quality? No.

Just a sidenote, reading your comment it occurs to me that I have no idea - and as far as I can tell never read anything about - what is the proportion of code that is done 'for fun' versus 'for pay'.

If anyone has any survey or any discussion on that please reply so I can take a look at it. I'd like to confront my expectations with data

You're conflating the act of building a product with the act of writing code. Even in the most expressive of languages, there are objectively good and bad ways of instructing your hardware to perform a particular calculation or set of calculations - and in the more rigid languages there is often a flat-out right and wrong way.

Design your product with as much free thought and creativity as you please, but never let yourself believe your actual code is art. That - among many other outcomes - is how your platform gets compromised and your customers' identities stolen - not to mention how the successors to your job end up cursing your name and wasting time and money replacing your code wholesale.

> I see writing software to be similar to writing music. Music has rules and structure, but leaves room for creativity and allows two or more highly skilled musicians to be able to play music together and improvise.

Bad music carries only the risk of people not liking it. Bad code on the other hand...

Usually risks people not using it or playing your game.

Rarely does it kill and in those cases (self driving cars, banking) those application usually has a company behind them.

If the RSS reader you're building has no guarantees of working it has no value to anyone. Not all software needs to try and be bug free but all software should strive to minimize the number of bugs in it.

Static typing helps to minimize bugs (when used correctly) by allowing function contract declarations and reducing the build up of defensive guards over time. I've seen code in dynamically typed languages with lines like `if (!foo is integer) raise;` which basically equate to onerous home-built static typing.

If it has no guarantee and it works it still has value for whoever uses it. If it didn't work it might have less value but still has some value.

Why would guarantee free software have no value. It's like buying a used phone.. no guarantee but it still has value.

Parent isn't saying his way is best. He's saying it's the appropriate mindset for some types of software. What you describe might make sense for bespoke web apps (and many other applications), but it may not be appropriate for, say, firmware development, or writing a web server from scratch.
That might work fine if you're throwing together a blogging system, but not in a critical-systems software-engineering context. When the stakes are high, it doesn't do to view your code as a creative outlet.

Critical-systems software engineering is not about your creativity, it's about building maximally correct software, to minimise the probability of a catastrophic outcome.

This idea that it's inherently virtuous to let software developers be creative, strikes me as quite wrong-headed. If a strict methodology produces better results (and it does), a strict methodology should be adopted.

Bridge engineers don't whine about their constrained creativity. They're too busy ensuring their creations don't get anyone killed.

With the curious exception of Erlang et al, few people serious about program correctness favour dynamically typed languages. There's a reason why Ada is statically typed, and strongly typed (it lacks the dangerous implicit type conversions permitted by C).

An excellent article on this kind of thing: https://www.fastcompany.com/28121/they-write-right-stuff

> Static typing imposes limitations (kind of like government),

where to begin

I program as you say 'similar to writing music'.

This is because given all of the levels of various languages, frameworks, and libraries- I'm just trying to get things to work.

However, I would very much like the methodical engineering approach at my day job applied to programming.

It really blows my mind we don't have full stack + auth that works cross platform out-of-the-box. It blows my mind my recent framework didnt show the post request exchange to get tokens and authenticate.

There are NOT that many people that program at this level. It seems most of my programming questions are answered by asking experts rather than reading a wikipedia article. Electrical and Mechanical Engineering are better solved reading rather than asking engineers. IMO.

But it's clear that one approach can be more correct than another. If it was supposed to save a document and instead it deletes all my documents, it's not right.
I hope you stick to webdevelopment and never touch anything remotely related to medical devices, or control systems.
So you're saying Python devs are all libertarians? :D

<braindump>

I agree that coding/development is an art, but I also am hard pressed to find anything that, when done well, isn't an art.

The difference is that music doesn't have any really notion of correctness or efficiency; sure, there are ideas such as "no parallel fifths" and "tritones must resolve to M3 or m6", but this isn't an issue of correctness, but rather stylistic guidelines. Schoenberg's compositions weren't incorrect in any universal sense.

Programs, on the other hand, can be incorrect or inefficient. This is because most programs have a concrete function that they produce.

Dynamic types are great for exploring your solution space. I can quickly whip together a prototype, try out different solutions, etc. I don't need to design my entire program ahead of time, and this is nice. However this does not prevent me from reasoning formally about my program. Once I've muddled around a bit and built up some scaffolding, it very well may behoove me to try to shore up my design, spend some time reasoning and designing a formal algorithm/specification/etc, etc.

And for the record, as a musician I definitely think formally about my compositions/pieces I'm playing. Granted, being a guitarist this usually doesn't involve me writing out my pieces with sheet music, but there is still a blend of intuition/exploration and brute computation.

As an example, I often times have two disparate parts that I need to connect together, maybe by modulating, maybe by changing registers, or maybe by altering my time signature. At that point I put the guitar aside for a moment and think about my formal requirements, and then try to find some 'convincing' way to get from point A to point B. Maybe I have some constraints (I have two measures, I need to start in this position and end in that position, this finger needs to pedal this note, etc). This quickly becomes a math problem where only a small set of viable solutions exist. After 'doing the math' I am left to evaluate my solutions aesthetic quality which, I suppose, is where most people think of the 'artistic' bit comes into play. But really, I'd say artistry abounds throughout the process.

And to be clear, I'm not thinking about this stuff as doing math as I'm doing it--I have my own system for thinking about this stuff that doesn't look like math.

Anyway, all of this is to say that formalism can be used even in music with very real benefits.

</brain-dump>

Isn't that why you have titles such as Software Engineer, Developer, Programmer? Software Engineer should have the engineering background and tackles hard problems whereas Developers and Programmers focus on products and features.
All of these terms are used mostly interchangeably, and it just depends on what company you are at. For example, Microsoft calls them all SDEs (Software Development Engineer) and Google calls them Software Engineers.
In many countries it is illegal to do so unless those people are actual engineers with accredited degree by the engineers' college.