
The people trying to save programming from itself - phodo
https://killscreen.com/articles/people-trying-save-programming
======
taneq
It's interesting how often we see these articles (and associated discussions)
saying that programming is harder than it should be, and that if only we had a
better language, it would be much easier.

In my experience, choice of language makes only a superficial difference to
the difficulty of a project. The real challenge is always figuring out exactly
what you're trying to do, and exactly how you're going to achieve it. And
these questions aren't solved by a language because they're questions about
your project itself, not about the implementation.

Sure, some toolchains are better suited to some types of project - I would
really not want to do serious number crunching in JavaScript, or an
interactive GUI in COBOL. But there's generally at least one (and usually
bogglingly many more) solid, freely available toolchains to suit any given
application.

~~~
Cthulhu_
It's the same logic used when people decide to build their own framework, or
advocate against not using a framework - by writing everything yourself,
you'll understand everything. It boils down to "other people's code is hard to
read", which can probably be extended to entire languages and other concepts
as well.

It's in part laziness - reading and understanding someone else's code takes a
lot of focused effort. But it's also a matter of gratification - writing code
is far more satisfying (IMO) than reading and comprehending others'. Most
developers I know - and probably myself included - are of the "I get paid to
write code" mentality, and often not really being mindful of whether what they
write now will still be understandable in 5 - 10 years time. Sure, they will
follow best practices, clean coding and all that stuff, but what about (high-
level) documentation? Revisiting the user stories from which the code was
born? Writing good commit messages and pull request descriptions? These all
seem secondary to the code itself, which I guess is true to a degree, but all
that other stuff is important too.

Getting into a new project is hard. Starting from scratch and writing your own
is easy. Writing code and other stuff so that others getting into your project
is easier is hard (as is allowing others into your domain and code for that
matter)

~~~
wolfgke
> It's in part laziness - reading and understanding someone else's code takes
> a lot of focused effort. But it's also a matter of gratification - writing
> code is far more satisfying (IMO) than reading and comprehending others'.

No, it is rather the problem that other people's source code changes all the
time. If the other programmer can assure me that his source code is good
enough that it can be used for 10-20 years without any problems (and will be
maintained this long time) and the only changes that will happen are small
bugfixes, I can easily be convinced to read into all the gory details of it
(of course only if the source code is useful), since I know that the knowledge
that I gain by diving into these details will help me for many years after.

The situation that we have is that every few months a new framework comes out
and such a deep reading into is not worth it since in a few month something
new will come and in few years the original framework will be forgotten,
making all the investment into understanding it deeply worthless.

------
jcoffland
> Roberts explains: “We’re in the mess that we are in now because of software
> engineering preferences from 30 years ago, made by people that just didn’t
> write enough code to have those preferences be worth anything.”

This is a typical attitude of younger programmers towards the previous
generation.

> he decided to create his own programming language

And this is the typical solution.

It's happened so many times before it's either really funny or no longer
funny. I'm not sure which.

The reason why "everything is broken" is because writing correct software,
that does all the things, in any language, is difficult. That's not to say
that new solutions cannot make improvements but it is naive to think that new
solutions will solve all the problems. A good rule of thumb is to make sure
you really understand a system before you replace it.

------
tehwalrus
This sounds like something that should have a simple description, but I'm not
sure the article tells enough to work out what it is.

(Unless the simple description is Not Invented Here syndrome, which I imagine
it's not).

I had a quick look at the website linked at the end but it's just a site with
a list of projects like a text editor and some game debugging components.

~~~
taneq
I'm not really sure, it rambles a bit. It seems basically to be advertising a
coding community or something, with a fair amount of indie superiority complex
on the side?

------
jamii
As usual, the article grossly oversimplifies the position of the people in it,
and the discussion on HN focuses on the gross oversimplifications.

Better to hear it from the horse's mouth eg:

[https://www.youtube.com/watch?v=k56wra39lwA](https://www.youtube.com/watch?v=k56wra39lwA)

[https://mollyrocket.com/casey/stream_0019.html](https://mollyrocket.com/casey/stream_0019.html)

[https://mollyrocket.com/casey/stream_0020.html](https://mollyrocket.com/casey/stream_0020.html)

You might still disagree, but at least you'll have something coherent to
disagree with.

