[meiraleal]

> this is an engineering discipline

oh, well. I just checked all 7 old and new wonders of the world and all of them needed engineers. I don't think being an engineering discipline limits software in any way related to what can be achieved with it.

[mustache_kimono]

> I don't think being an engineering discipline limits software in any way related to what can be achieved with it.

I don't either. I think programming can be art, etc.

My issue here is that I don't think favoring artisanal methods are part of the appeal of software. We are much more interested in what software does.

For instance, it might be useful to know x86_64 vector assembly. It might make your program run faster. It might even be necessary for you to know it for your program to work correctly. What I am saying is -- if a higher level construct exists, like C, C++, or Rust, which can produce an equivalent program, but you choose to write your entire program in x86_64 assembly, because that is/was the artisanal way, that's mostly unimportant/irrelevant to the user, except as an oddity.

[meiraleal]

Got it. I don't think writing in x86_64 is any more artisanal than Python or JavaScript. It's actually quite easy to make the distinction. Assembled software - using multiple libraries in place of crafting (almost) every piece of it - is the opposite of artisanal software. You can have that with assembly, C/C++, Java, or JavaScript.

As an example, I'm developing an IDE from the ground up. The current conventional approach would be to fork VSCode, a bloated, slow, over-engineered, ultra-complex Electron app reliant on Microsoft's standards.

Alternatively, I can code it artisanally, which will likely result in something worse in many ways and break in unexpected ways. But for my specific use case, it provides a much better user experience than taking the assembly-line approach to software development. The chances of this project failing are much higher using this customized approach than if I used the assembly-line method, but it doesn't matter to me - coding it this way is already so much more fun.

[mustache_kimono]

> Assembled software - using multiple libraries in place of crafting (almost) every piece of it - is the opposite of artisanal software.

> The chances of this project failing are much higher using this customized approach than if I used the assembly-line method, but it doesn't matter to me - coding it this way is already so much more fun.

I am sympathetic to this way of thinking about "artisanal". I guess for me it has so much baggage re: food, I don't think of it this way. I'd perhaps call that/your way the "DIY way", because you're right -- it is sometimes appealing and advantageous, even if I'm not certain that's what the article intended.

[meiraleal]

> even if I'm not certain that's what the article intended.

I have the impression that was exactly the intention of the article:

  > In the coming years, we’ll see more and more people making software like someone building a table in their backyard or garage, they’ll enjoy the process and add their own personal touch.
  > If you love coding the way we do it now, keep at it! enjoy every moment, improve yourself, learn new things, keep coding!

[mustache_kimono]

> > I don't think writing in x86_64 is any more artisanal than Python or JavaScript. > I have the impression that was exactly the intention of the article:

Okay, but you seem to be ignoring the first half of the article. You know the part that tells us it is a great big joke:

"Real Programmers wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly."

[meiraleal]

True, I think I really skipped that quote. I disagree with this part and think it doesn't link very well with the conclusion or with software artisans. Not sure if I mixed it up or the author :)

[wavemode]

Sure but demand for world wonders is low. Demand for basic cookie-cutter houses is very high.

An engineer's job isn't to build something perfect or beautiful, it's to build something that's just good enough for its intended use case. Lots of software engineers forget that.

[meiraleal]

> An engineer's job isn't to build something perfect or beautiful, it's to build something that's just good enough for its intended use case.

Why? Who is responsible for making it look good? fast? resilient? The architect? In software development the engineer can be the architect, the decorator, the user. AI will unleash the age of artisan software - which already exists, so many great free software developers came before us but now it will spread like a "plague". It has the potential to disrupt SaaS as we know it today.

[jairojair]

Sometimes is ok write code just for fun.

https://jairojair.com/articles/coding-just-for-fun/