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

301–310 of 511 posts

Re: Programming breakthroughs we need

#301

Post by treis »

heurisko wrote: post #105
jaredcwhite wrote: post #99

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…

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

I don't think that the industry has generally accepted that. It seems pretty hotly debated AFAICT.

What is not debated much, AFAICT, is that it's much much easier to work on large/old codebases when you have types. That's really where Rails runs into issues.

But it's not like legacy rails monoliths start throwing NPE or other type errors everywhere. It's just that developer productivity grinds to a halt. Mostly for two reasons:

(1) You have little idea where the code your modifying is used. Metaprogramming and indirection through send and constants make it hard to find every place it's called.

(2) If you're the 5th function in the chain you have no idea where your parameters are coming from. So you have no idea what type they are and method autocompletion doesn't work. Especially annoying when things get complex and you end up with multiple similar but slightly different representations of things.

Re: Programming breakthroughs we need

#302

Post by preseinger »

preordained wrote: post #216
wvenable wrote: post #172

Earlier quoted context omitted.

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

> Having spent equal amounts of decades in static and dynamic typing I hear this, as well as "eliminates whole classes of run time errors" (as if Ruby and other such codebases are just ablaze everywhere on account of this...), but I wonder if people dabbled in this and think they have it all figured out, or if they've used a modern dynamic language like Clojure that has default immutability or been in a modern Ruby c…

> as if Ruby and other such codebases are just ablaze everywhere on account of this..

They literally are, I think? Ruby is a notoriously unreliable language, in large part due to its dynamic type system... (also all of the unsafe idioms it promotes, a separate discussion)

Re: Programming breakthroughs we need

#303

Post by unixbane »

the_af wrote: post #78

Everytime someone proposes a non-textual representation of code I cringe. There's a reason no one single alternative has triumphed over text. And many have been proposed! Standards are hard. Proprietary tools lock you in. Text is universal (OK, restricted to plain ASCII, which is a big deal but has already happened). You can open and modify a text file with whatever editor of your choice, the simplest possible editin…

Standard boomer rant.

> There's a reason why the status quo exists

Yes, it's called the status quo.

> text is universal

Which one, ASCII, code page 9000, or UTF-8? Are you saying just restrict to ASCII? Then we need custom solutions every time someone wants to talk a different language.

> lock in

I am locked into using retarded insecure terminal emulators because all my tools depend on it to render what you people call "text" which is supposdedely "simple" or "universal". Even vim breaks from unicode already. The primitive language of the OS should not be some poorly defined idea of "text", but algebraic data types.

> reading important

Which is better done by graphics that text. Just the fact that with a structural editor - an if statement spans the amount it appears to span, instead of having to trust someone to format it correctly - is already enough reason to ditch text.

Re: Programming breakthroughs we need

#304

Post by lazyjones »

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…

And still you're typing repetitive text. My dad was punching cards and able to read code from punched tape. I grew up writing code on a home computer's display. And now, 35 years later, it's long overdue that some visual NoCode tool should be the default for mostly repetitive programming jobs. If I want to build a Finder Quick Action to resize an image, for example, I certainly won't open a C editor, I'll just use Automator.

Re: Programming breakthroughs we need

#305

Post by vlunkr »

SKILNER wrote: post #34

Great post - the one word missing, "maintenance." Most programming work is done maintaining/enhancing existing code. The greenfield work is a piece of cake by comparison. You want to do the hard stuff? Maintain existing code you're not familiar with. The problems around maintaining unfamiliar code are huge, largely unsolved, expensive and risky. There's a little branch of computer science called Program Comprehension…

I've also wondered if it's time to back off on agile a bit. Or at least "agile" as it is implemented generally, which means we get to make up new requirements every two weeks. In my experience, the hardest maintenance problems occur because we're trying to re-shape code into something that the developers never knew would be coming down the line. Spending lots more time up-front deciding requirements would go a long ways towards more maintainable code.

Re: Programming breakthroughs we need

#306

Post by plafl »

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…

>But we can and should do better. Why is DLL-hell still a thing? Imports should specify versions, defaulting to a default if none is specified. Languages barely even consider versions today, they are almost always hacked on via magic text strings in filenames.

So suppose you fix the version number when you import the library. You then need to copy paste the version number to other imports in your code base? Or maybe you mean each import may have different versions? which is all right until you need to pass some data between two versions of the same library. This wouldn't be so difficult if semantic versioning or another equivalent was respected, but we know it's a lie. This wouldn't be a problem at all if there were some kind of contracts in place when using modules/package/whatever instead of a silly number based on convention but how to specify the contracts is not that easy, and it's similar to say having static typing. I think improving versioning it's doable but it's very hard.

I'm all about improving tooling, I have been obsessing for a few months about the sad state of program documentation and navigation. Why is the computer doing nothing while I think so hard while I'm programming? Why there is so little money in this space?

Re: Programming breakthroughs we need

#307

Post by barnabee »

ziddoap wrote: post #215
sleepybrett wrote: post #194

Earlier quoted context omitted.

This argument also just assumes, 'anyone can sit down and use excel'. Which is not true, excel has a learning curve like anything else, most people learn 'just enough' to do their job, maybe there is a guy in their office that knows a little bit more and they can learn from them. But excel proficiency acquisition is very similar to a programming proficiency acquisition, maybe the track runs out faster (at some point…

> excel has a learning curve like anything else, Agreed. > But excel proficiency acquisition is very similar to a programming proficiency acquisition Strong disagree. Maybe if you only consider those extreme cases you referenced (ray-tracing, heavy VBA, etc.), sure. But in general? No shot. Excel gives immediate feedback with a visual interface. There's no need to learn about variables or syntax or memory or compilin…

The amazing thing about Excel is that many (most?) people start using it without EVEN knowing how to make a simple formula.

They literally start using it as a way to lay out tables (usually of data). Then they make graphs. And add more tables. And learn how to use it like a basic pocket calculator (half of the formula I see that should be sums are actually =B21+B22+B23+B24+B25…) Then comes SUM. Then VLOOOKUP. Perhaps some IFs or COUNTIFs.

This process can take years for someone to go from first use to anything even slightly programming-like, if you squint at it.

A tiny fraction of these people ever do anything complex enough it looks even much like low-code or no-code "development". Even less write macros.

But you know what? In the first half hour, when all they wanted was to email round a list of team members and their lunch preferences, they already achieved something with Excel that they found useful, and they felt productive ever since. Most Excel users spend almost NO time learning the tool compared to how much time they spend getting (what they see as, and what probably is) value out of it, even when we are sat in sheer terror as we witness the horror they have unleashed on the world.

That is the bar you have to clear to make a "better Excel".

Re: Programming breakthroughs we need

#308

Post by baobabKoodaa »

zwkrt wrote: post #6

There’s a lot of complaining and not a lot of suggesting going on in this article so I don’t take it for very much. I feel like the author got a job and realized that it almost exclusively involves writing glue code and tests and looking at text diffs, so how convenient to imagine a world where they didn’t have to do the boring parts of their job.

I think you're being unnecessarily harsh. I get your point about OP presenting problems, not solutions, but on the other hand, they are a programmer & they are clearly trying to automate the repetitive parts of the job. Isn't that basically the essence of programming: what good programmers should be doing is automating as much of their job as possible.

Re: Programming breakthroughs we need

#309

Post by preseinger »

hzhou321 wrote: post #204
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…

Yes, I agree! In fact, the break through we needed is to view programming as a human cognitive operation and embrace the text, and treat manipulating text as a main component of coding. For example, I want to code foreach item in list_A do_something(item) This text is the native code in the programmer's mind, and we should allow programmer to just do so. Then, in a second layer, the programmer should code up the tran…

Agreed. Programs are not equations, they're recipes.

Re: Programming breakthroughs we need

#310

Post by thrown_22 »

jrm4 wrote: post #9

Eh, unfortunately the one programming breakthrough the world actually needs is one that would drastically change, and perhaps harm, most of the people around here. We need more "Excels." More and better tools that let "regular" people program.

>We need more "Excels." More and better tools that let "regular" people program.

The only reason why more people don't program is because Windows is antithetical to programming _anything_. The second you remove people from a windows environment is the moment they start coding, even by accident.

Post reply on HN