Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

171–180 of 511 posts

Re: Programming breakthroughs we need

#171

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. St…

I agree with you that "Re-write your Ruby project in Rust" is a terrible suggestion. Pretty much only "Re-write your C++ project in Rust" makes any sense. But it's not all bad. Elixir is pretty widely considered to be the Ruby successor. Types are replaced almost everywhere by pattern matching, the widely accepted unexpected behavior response is to just not handle it, crash the "process" (green thread) and continue o…

> Elixir is pretty widely considered to be the Ruby successor.

Really? That feels really odd, once you get past the surface level syntax, Elixir doesn't really resemble Ruby to me, unless you've conditioned yourself to write purely functional Ruby?

Re: Programming breakthroughs we need

#172

Earlier quoted context omitted.

> Static typing everywhere. I think the industry has generally recognised that static typing makes more reliable software. I started with PHP and have seen its type system evolve. Similarly Typescript. I since moved to other staticly typed languages. I wouldn't want to go back.

Depends on the context. When you're programming a transactional banking system? Heck yeah I want static types. When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix.

> It's way-ay-ay more effort

No, it's not. Initially it's not any more effort and in the long term it's significantly less effort. Having spent equal amounts of decades in static and dynamic typing (and strong/weak) I would absolutely take the former any day for both ease of development and correctness.

Re: Programming breakthroughs we need

#173

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. St…

Do you think that perhaps functional programming can be a happy compromise between high level abstractions / declarative code style and strong math / logic foundations? My programming experience is largely in Python and Java and so I can relate to both sides you present - I feel constrained by the aggressive static typing of Java but also feel that Python can be a bit too fast and loose with typing and I often find that dealing with unexpected behaviors takes as much time as it would to just have them written formerly and properly into the code to begin with through a strong type system.

Re: Programming breakthroughs we need

#174
> Program is not a text, [it is] a model

I don't think so. In fact, I think this perspective is actively harmful.

A program is whatever the human beings who maintain that program operate against. I mean there are many possible representations of a program, and there are different ways to evaluate those models, but the model that most precisely expresses the AST of the logic of the program, or the call sequence of the von Neumann execution of the program, or whatever else? These models are incidental. The thing that matters is whatever humans read and interpret and mentally model. And for the moment that's source code.

Re: Programming breakthroughs we need

#175

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. St…

Oh really? Suppose x = 123 and x = "123" were "THE SAME THING". What's x + "42"? What's x + "042"? What's x + "a"? What's x + "e2"? What's x + "e2" + 12345? What's x + "1,500"? What's 1 / x?

To be fair, that's more weak vs. strong and not static vs. dynamic. You can have a dynamic typed language where all these are cough runtime errors.

Re: Programming breakthroughs we need

#176

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. St…

> for the contexts I care about (small web applications largely written by solo devs).

found your source of disagreement. this is, generally, not the domain anyone writing languages cares about. no one writes a language for an individual.

Re: Programming breakthroughs we need

#177

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. St…

I get your and the article's drift, but saying it won't come to pass because of grumpy programmers is IMO a bit unfair. I believe it'll come to pass, but it'll take a while because there's not a huge need for it right now. I believe the whole computing ecosystem is very shallow at the moment. There are lots of tools and lots of programming languages, but they are all shockingly similar. There is just too much monocul…

Re: your edit, I think the real answer is that the correct translation is fully context dependent, and the people who want it strict want to basically force/precompute the context, vs the people who want it loose want the context itself to smartly decide what the string means to itself. The problem is that modern paradigms are squishy about this, and aren’t smart enough to consistently do the right thing, so real systems end up both too strict and brittle for the real world domain but also too loose and ambiguous to be bug free.

Re: Programming breakthroughs we need

#178

Earlier quoted context omitted.

I always tell my clients - the difference between writing code and maintaining it, is the difference between raising your hands and keeping them raised indefinitely.

Or the difference between conceiving a child and raising one :)

Ha, love this one.

Re: Programming breakthroughs we need

#179
> We spend endless amounts of time bikeshedding the right syntax, indentation level, tabs vs spaces, or where to put code in the structure of files, but this all feels just pointless - these are all properties of text, but the text is just a tool to manipulate some abstract model of the program.

This is why I always use black for Python, cargo fmt, prettier, etc. for my code.

Re: Programming breakthroughs we need

#180

Earlier quoted context omitted.

I always tell my clients - the difference between writing code and maintaining it, is the difference between raising your hands and keeping them raised indefinitely.

Or the difference between conceiving a child and raising one :)

I always smile when a green field project starts and then they claim its “Clean Code”. No, you won’t known if it was clean code until years down and the system will need updates. Then and only then you can reflect and see how hard it was to changes things in it.
Post reply on HN