5 ms·

The people trying to save programming from itself

21 points by phodo 10y ago

tehwalrus 10y ago
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.
- mifreewil 10y ago
  I don't think this article should be on HN, there is nothing here.
- taneq 10y ago
  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?
taneq 10y ago
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.
- Animats 10y ago
  The main thing a language can do for you is prevent the situation where the thing crashes in production and you have no idea why.
  - jcoffland 10y ago
    Let me guess, you're a Rust programmer.
    - cousin_it 10y ago
      I think Java does it better than Rust, because in Java you can see who threw the exception, but in Rust you can't see who originated the empty Result.
  - taneq 10y ago
    In general I'd argue that that's a tooling issue rather than a language issue - it should be possible in theory to provide tooling for any language that will give you a sufficiently detailed crash dump to diagnose the problem. In practice, very few languages do so, and the ones that do so require a fair bit of work to set up, which is really annoying. The only thing worse than being told "but it worked on my computer" is being the one actually saying the phrase!
- deleted 10y ago
  [deleted]
- Cthulhu_ 10y ago
  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)
jcoffland 10y ago
> 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.
jamii 10y ago
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.

21 points by phodo 10y ago

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.

mifreewil 10y ago
I don't think this article should be on HN, there is nothing here.
taneq 10y ago
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?

taneq 10y ago

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.

Animats 10y ago
The main thing a language can do for you is prevent the situation where the thing crashes in production and you have no idea why.
- jcoffland 10y ago
  Let me guess, you're a Rust programmer.
  - cousin_it 10y ago
    I think Java does it better than Rust, because in Java you can see who threw the exception, but in Rust you can't see who originated the empty Result.
- taneq 10y ago
  In general I'd argue that that's a tooling issue rather than a language issue - it should be possible in theory to provide tooling for any language that will give you a sufficiently detailed crash dump to diagnose the problem. In practice, very few languages do so, and the ones that do so require a fair bit of work to set up, which is really annoying. The only thing worse than being told "but it worked on my computer" is being the one actually saying the phrase!
deleted 10y ago
[deleted]
Cthulhu_ 10y ago
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)

jcoffland 10y ago

> 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.

jamii 10y ago

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.