Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

Post reply on HN
Print view View original

471–480 of 511 posts

Re: Programming breakthroughs we need

#471

Post by garfieldnate »

>IntelliJ helps you with things like "extract parameter" or "inline function", but I wanted to do stuff like...

In the same vein as the developments around LSP, TreeSitter, etc. I had the idea that one could create a scripting language dedicated to refactors. The language would make it simple to talk about the AST of your programming language and provide simple primitives for safely transforming it.

Doing this in a language-agnostic way is pretty difficult, though. There seems to be some discussion among the LSP folks here (https://github.com/microsoft/language-server-protocol/issues...) but no resolution. It's worth thinking about!

Re: Programming breakthroughs we need

#472

Post by pyjarrett »

nextos wrote: post #400
troutwine wrote: post #358

Earlier quoted context omitted.

At least from the systems programming perspective I think productivity gains have been significant. Valgrind had _just_ appeared as I was doing my undergrad and it allowed me to focus on the high-level math of data structures -- as an example -- compared to my non-Valgrind using classmates that were struggling with memory bugs (which, of course, I did too, but to a less degree). C++ has noticeably improved since then…

> Ada has made real strides back from the dead, especially if you can stick to SPARK Ada. We're even seeing more formal verification of complex bits of software in systems-land, something that seemed basically impossible when I first read about Coq twenty something years ago. I really agree with this. The situation is a bit crazy. Since formal proofs are hard, the alternative taken is giving no guarantees at all. Tha…

The great thing about Ada/SPARK is that it has a package manager now (Alire). This means there are existing SPARK packages you can use, and you can share what you make. SPARK is also an Ada subset, so you can use verified components inside your Ada programs.

Re: Programming breakthroughs we need

#473

Post by salawat »

fleddr wrote: 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's Standard Library is basically NodeJS + Browser WebAPI's.

UI libraries/toolkits were really only considered a part of any standard library in like one language, (Java) which is still a stretch, because even Seing and AWT were toolkits.

Standard libraries are small. That's the point. You use primitives to build up the rest.

Re: Programming breakthroughs we need

#474

Post by salawat »

hutzlibu wrote: post #460
Ygg2 wrote: post #451

Earlier quoted context omitted.

> Yes. This this is exactly what I want. But the more abstract you go, the less efficient does your editor become. And speed of development goes down. It's not a simple - just put more abstraction.

"It's not a simple - just put more abstraction." Of course not. It is about the right level of abstraction. Abstracting all the details away, I do not need to accomplish the task at hand. If done right, this also will not slow things down, rather the opposite. Imagine programming a button in assembler and opengl. There you have all the details (and power). But chances are, you will be way slower and with a worse resu…

Stop. Abstraction is not a magic pill that absolves you of the need to know wtf you are doing.

At best, it allows you to defer the deeper reading for a time. You might not even have to do the deeper reading for this piece of functionality, but the time will come when you have to figure out where an impedance mismatch is.

This quest for abstraction is the most infantile attitude I straw to squash in ever developer I meet. If you aren't reading the code that your code depends on to work, you have no idea what you're actually doing.

Re: Programming breakthroughs we need

#475

Post by mikewarot »

andsoitis wrote: post #467
mikewarot wrote: post #421

Earlier quoted context omitted.

I make $0/year, so my choices are more restricted.

How about the Delphi community edition? https://www.embarcadero.com/products/delphi/starter You can use it for free util your revenue reaches $5,000.

Yeah, I've had it installed, more than once in the past few years, but I just can't bring myself to use it.

Re: Programming breakthroughs we need

#476

Post by chakkepolja »

hsn915 wrote: post #387
smallstepforman wrote: post #25

I’ve been programming for over 30 years, and never been as productive as before. Need to load and decode a jpeg/png, I grab stb_image.h. Need to decode an ogg file, libogg. Need to decompress, libz. Need to decode video, libavformat. Need physics, libbullet. Need truetype fonts, freetype. Need a GUI, Qt. Need SSL, libssl. My day becomes selecting libraries, integrating them, and testing integration. My business code…

> My day becomes selecting libraries, integrating them, and testing integration. This is why I hate modern programming. When was the last time you had a job where you could actually learn how to actually program something? The prolifiration of libraries means that all your bosses and managers would extremely frown upon anyone handrolling a solution instead of using an existing library. Which means the more time you s…

I find this comment amusing because most tasks the GP mentions are so specialized that you wouldn't actually have time to learn them. If your complaint is left pad and similar libraries, that's not what GP comment is talking about.

Re: Programming breakthroughs we need

#477

Post by chakkepolja »

ecopoesis wrote: post #284

I would love to see a language that considers tooling a first class problem. Most (all?) languages barely consider complex projects with 100s of dependencies and large multi-step builds. Java shouldn't have to wait for Maven and Gradle to come along, and Python shouldn't be shackled to piss-poor systems like pip. This is something Rails gets very right. Bundler and Rake make Rails one of the nicest development enviro…

I think new languages with sufficient popularity (go, typescript, rust, dart) do it pretty well.

Old languages also have gained good tooling, but IMO the problem is that they are not as well documented as in-built systems of newer languages.

Re: Programming breakthroughs we need

#478

Post by salawat »

AndyMcConachie wrote: post #335
agumonkey wrote: post #280

Earlier quoted context omitted.

I sincerely don't know why uni don't make more classes on that only. - pick any software - try to change something - give a precise impact analysis - generate a few potential implementation paths - measure how fast you did all that and what failed / worked

I agree. A fundamental problem with how we teach programming is that we focus on writing, instead of reading, software. To borrow terminology from the language arts; we don't focus enough on reading comprehension.

This. So much this. I have devs I oversee vomiting forth code with nary a thought of how it integrates with anything else.

Re: Programming breakthroughs we need

#479

Post by hutzlibu »

salawat wrote: post #474
hutzlibu wrote: post #460

Earlier quoted context omitted.

"It's not a simple - just put more abstraction." Of course not. It is about the right level of abstraction. Abstracting all the details away, I do not need to accomplish the task at hand. If done right, this also will not slow things down, rather the opposite. Imagine programming a button in assembler and opengl. There you have all the details (and power). But chances are, you will be way slower and with a worse resu…

Stop. Abstraction is not a magic pill that absolves you of the need to know wtf you are doing. At best, it allows you to defer the deeper reading for a time. You might not even have to do the deeper reading for this piece of functionality, but the time will come when you have to figure out where an impedance mismatch is. This quest for abstraction is the most infantile attitude I straw to squash in ever developer I m…

"Stop. Abstraction is not a magic pill that absolves you of the need to know wtf you are doing."

Erm, a beginner who wants to place a button that calls his defined method foo, really does not need to know about all the framework details to get the job done.

When I was a beginner, I was happy that I could place a button and link it with whatever with ease and it worked!

I simply did not needed to know about event loops, rendering algorithms, or internals of the framework. Now I happen to know quite a lot about it, because I designed a UI framework from scratch to solve a custom need.

But most use cases with UI are to display text, images and give text input and buttons. Ordinary programmers should be able to do that, without having to learn the graphic stack. Thats why we have frameworks. They just could be easier with better tooling.

Re: Programming breakthroughs we need

#480

Post by igouy »

samatman wrote: post #375
preseinger wrote: post #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…

That's a tenable way to view a program until you hit a compiler bug. Mostly, you don't hit a compiler bug. When you think you've hit a compiler bug, it's not a compiler bug. There's an easy workaround: write a compiler. It will have bugs. There are other non-trivial ways that a program isn't its source, but in fact, systems which treat the source code as the ground truth are an important foundation. Many Smalltalk us…

> Many Smalltalk users would paint themselves into a corner by…

?!

Most Smalltalk users were transitioning enterprise systems from green screen terminals to guis.

> … no way to restart it…

It's important properties were captured in the .changes log file — so workable modifications can be made again in a new image.

https://eng.libretexts.org/Bookshelves/Computer_Science/Prog...

Post reply on HN