Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

361–370 of 511 posts

Re: Programming breakthroughs we need

#361

Earlier quoted context omitted.

Programs are ideas that need to be understood, modeled, and manipulated by humans. Text is the best available way to incept ideas into the minds of humans.

If that were true, text books wouldn't contain any diagrams. So I think it's fairly uncontroversial to say that there are cases when text is not the best way to incept ideas. So why should we be confined to just text when writing code? Should we not be free to choose the best tool for the job?

You should check out IDEs :)

IDE takes plain old text as input, and lets the coder to interact with the model of the program.

1. Various graphical hints in text (highlighting keywords, selections, …)

2. Visualisation tools (draw database and class diagrams)

3. Navigation capabilities (go to implementation, definition etc)

4. Refactoring capabilities (“rename, “extract variable”, …)

In my view, IDE is already “book with diagrams”. (“Diagrams” can still be improved, but concept is really there)

Re: Programming breakthroughs we need

#362
I can't find the article now, but I remember reading about SecDB and comparing it to programming in traditional languages. The point that stuck with me is that the software industry has spent decades taking other industry's data and lifting it from flat files into databases, yet our own code is still in flat files.

Re: Programming breakthroughs we need

#363
Good luck trying to create something more powerful and versatile than text to create programs.

Text is a seemingly basic, simple and even crude format. Ancient, outdated even?

My opinion is that our perception about the simplicity of text is related to Moravec's Paradox, and is an illusion.

Reading and writing text is something we take for granted, but this is a skill we all have to painfully learn at a young age, and we're so good at it that it seems transparent.

Text is very abstract, the fact that we, humans, are trained to easily parse and decipher it is the reason why it is so powerful for us.

I don't see any replacement in the foreseeable future.

Re: Programming breakthroughs we need

#364
post #184

Earlier quoted context omitted.

It's not complexity. It's pointless bookkeeping. If you don't cut corners on your static typing, you're looking at 2-4 single use classes per API endpoint: 1-2 for the web layer, and 1-2 when going into the domain logic layer. Many people skimp and just re-use the core domain class for everything, which is the worst of both worlds. I'll take a map, spec, and select-keys over this all day long.

That's if you write it in Java. With a type system like TypeScript's you can write largely the same code as before, with a few annotations to clarify what you mean, and you get the exact same runtime only you also will get compile errors if a change elsewhere in your program violates the assumptions of that code.

I don't view Typescripts as a good argument against dynamic languages.

I view it as a good case for a well-designed gradual type system for dynamic languages.

All valid Javascript is Typescript, in a profound rather than trivial way.

Re: Programming breakthroughs we need

#365
post #342

I believe already some 2 decades ago Bill Gates said that the biggest failure in software is the lack of productivity gains in software development. Just to cherry pick a dramatized example. In the late 90s, one of my first programming experiences was in Delphi. It's a very visual way to program. You drag and drop a UI together from standardized elements. You could data bind things like input fields to a data source.…

> JavaScript has no standard library.

    >> Math.sin(1.57)
    0.9999996829318346
This would be pretty surprising output if there were no standard library.

Re: Programming breakthroughs we need

#366
post #126

Earlier quoted context omitted.

The main problem with more and more abstract forms of describing "what you want" instead of "what the computer should do" is that the program still needs to run on a computer, and those are inherently non-abstract. There is no duck typing on the CPU level and figuring out what exactly you passed as an argument takes up a lot of time. Don't get me wrong, I love me some Ruby and it makes up the majority of my income. B…

> describing "what you want" instead of "what the computer should do" Actually, static typing is describing "what you want" and leaving it up the compiler to make sure you were consistent.

Prolog, and SQLite dialect of SQL, are both declarative and dynamically typed.

Static typing is neither necessary nor sufficient here, the gradient from declarative to imperative is largely orthogonal.

Re: Programming breakthroughs we need

#367
post #342

I believe already some 2 decades ago Bill Gates said that the biggest failure in software is the lack of productivity gains in software development. Just to cherry pick a dramatized example. In the late 90s, one of my first programming experiences was in Delphi. It's a very visual way to program. You drag and drop a UI together from standardized elements. You could data bind things like input fields to a data source.…

> JavaScript has no standard library. >> Math.sin(1.57) 0.9999996829318346 This would be pretty surprising output if there were no standard library.

I think the gp meant standard UI library...

Re: Programming breakthroughs we need

#368
post #342

I believe already some 2 decades ago Bill Gates said that the biggest failure in software is the lack of productivity gains in software development. Just to cherry pick a dramatized example. In the late 90s, one of my first programming experiences was in Delphi. It's a very visual way to program. You drag and drop a UI together from standardized elements. You could data bind things like input fields to a data source.…

I agree with the general sentiment of your post.

Regarding Java and C#, I am stunned by how good are IDEs now. To be clear, when I say IDE, I am specifically talking about a tool that enhances the edit-compile-debug cycle. Compared to 20 years ago when I wrote C, C++, and Perl, the IDEs were mostly terrible, except Visual Studio for Windows. The majority of my development cycle was all terminal-based: vim to edit, make to build (C/C++ only), gdb/perl -d to debug. Hoi, awful. (And, I still enjoy those all three languages!) As mega-corp computing slowly migrated to Java & C#, my productivity has increased dramatically. I guess at least 2x, if not more. Yes, some of this comes from how forgiving a modern VM can be (NullPointerExceptions, debugging, etc.), but a lot can ascribed to the incredible ecosystem of IDEs.

Regarding JavaScript, in the context of a modern web browser, high school students (in almost any country in the world) can easily Google a little bit, read some blogs, and then start GUI programming. And this doesn't require expensive, licensed software, like Delphi 30 years ago.

Re: Programming breakthroughs we need

#369

Earlier quoted context omitted.

> JavaScript has no standard library. >> Math.sin(1.57) 0.9999996829318346 This would be pretty surprising output if there were no standard library.

I think the gp meant standard UI library...

There's a standard library for that, too, but it's not exactly high-level.

https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...

At a higher level, that's pretty much what React is.

Re: Programming breakthroughs we need

#370

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.

> Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby. I didn't work hard to make Ruby perfect for everyone, because you feel differently from me. No language can be perfect for everyone. I tried to make Ruby perfect for me, but maybe it's not perfect for you. The perfect language for Guido van Rossum is probably Python.

–Yukihiro Matsumoto, creator of Ruby https://www.artima.com/articles/the-philosophy-of-ruby

Post reply on HN