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

341–350 of 511 posts

Re: Programming breakthroughs we need

#341

Post by 082349872349872 »

marcosdumay wrote: post #313
082349872349872 wrote: post #33

> usually the biggest problem is an enormous amount of CRUD boilerplate that looks very similar in each project, but it's nevertheless different in important details. Once upon a time, a lot of microprocessor code was written in assembly. Then C came along, and many of the assembly people said: "whoah, hold on, I use different calling conventions in different places for good reason; what do you mean every C function…

The interesting part is that no, function calls do not all use an entire stack frame, unless you compile your code for debugging. Compilers are smart enough to reencode the calling into just registry shifting, or even inline the entire thing.

Agreed, compilers do now. In 1978, they did not. (although maybe even then things like BLISS, on minis, did?)

The machine I learned C with maxed out at 64K data. Needless to say, the compiler was not doing much beyond peephole optimization.

Re: Programming breakthroughs we need

#342

Post by fleddr »

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. You'd double click a button and it takes you to the already created "onclick" event where you do the actual coding. In a way, this is still similar to how you can "program" Microsoft Access today.

In this same period (I was in a computer science study) I was moaning to my teacher how tricky programming in C was. I made tiny memory management errors crashing the entire PC, with zero debug output.

His words: "Don't worry. By the time you get to work, you'll just do modeling".

Now I work on the web. It's been 30 years since Delphi and instead of productivity gains, we've taken steps in the opposite direction. There is no standardized UI library. JavaScript has no standard library. There's no single unified architecture. There's no standard tool chain. It's all very low level after which we stitch together fragile semi-abstractions.

I know it's an imperfect comparison, but I hope it gets the point across. It's all far too low level and fragile.

This doesn't just hurt productivity, also accessibility. It's simply not beginner friendly.

Re: Programming breakthroughs we need

#343

Post by rileyphone »

PeterWhittaker wrote: post #19
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.

Excel programming errors cost business $$$ https://www.cnbc.com/amp/id/100923538

Many more such cases [0], but Excel and spreadsheets in general also save businesses $$$$$, which explains their pervasiveness. Calculations take a long time and are easier for a human to mess up, which is why the initial spreadsheets were so popular as to drive the adoption of the personal computer in general [1]. The gulf between Excel and Python is pretty obvious, but there recently there have been few with their sights set on it, as most programmers looking to improve programming do so from their own experienced vantage point.

[0] http://www.eusprig.org/horror-stories.htm

[1] https://www.wired.com/2014/10/a-spreadsheet-way-of-knowledge...

Re: Programming breakthroughs we need

#344

Post by [deleted] »

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

[deleted]

Re: Programming breakthroughs we need

#345

Post by fleddr »

galdosdi wrote: post #247
dlojudice wrote: post #159

Earlier quoted context omitted.

the problem is that a large amount of code produced is to support the accidental complexity of the software (let's call it infrastructure code) while the value generated by it comes from its essential complexity, that is, the application domain, as cited by the article . while Domain Driven Design and Clean Architecture are a first step in the right direction, languages and frameworks are still limited in supporting…

I think, as OP alludes, ultimately explorability is the heart of the problem that stops people from writing code this way. If you don't care about other people being able to read and explore your code without a lot of preperation, you can go full hog creating layers of DSLs and metaprogramming, and with enough dedication you can end up with all your real domain level business rules in one place separate from the "inf…

A long time ago, I presented to my manager a carefully crafted application, a stereotypical multi-layered architecture and then some more.

His response: wow, that's a lot of crap just to run a sql query.

He was fully right.

Re: Programming breakthroughs we need

#346

Post by david927 »

preseinger wrote: post #319
david927 wrote: post #234

Earlier quoted context omitted.

I couldn't disagree more. You don't buy a drill, you buy a way to get a hole in, say, wood. That's the core product. The core product of 'programming' is a software solution. So far, the best way to approach it is text. But... text is an incredibly poor model! It's almost literally an accounting system of "Jake spent fifty dollars." It's text which is "actively harmful," and we see it all around us in the absence of…

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.

> Text is the best available way

I said exactly that. I added that it's horrific and it's not hard to imagine that we will find a better way.

Re: Programming breakthroughs we need

#347

Post by tomphoolery »

metaltyphoon wrote: post #180
deepakkarki wrote: post #142

Earlier quoted context omitted.

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.

I mean, a green field project is about as clean code as you can get. It's (reported) bug-free!

Re: Programming breakthroughs we need

#348

Post by sdashner »

deepakkarki wrote: post #142
danielvaughn wrote: post #53

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 :)

Whenever I do a big refactor it’s so that it will be messed up my way instead of being messed up their way.

Re: Programming breakthroughs we need

#349

Post by simonblack »

tacitusarc wrote: post #273
metaltyphoon wrote: post #180

Earlier quoted context omitted.

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.

My metric for clean code is how quickly a developer unfamiliar with it can understand it

Much as we denigrate COBOL, that is still its greatest advantage. Yes, it's wordy, yes it's old. Yes, it needs to be really updated. But it's still easier for a new hire to understand the COBOL old code than any other old code.

Re: Programming breakthroughs we need

#350

Post by csours »

probablypower wrote: post #327
csours wrote: post #100

Earlier quoted context omitted.

Wow. I would say the complete opposite. Why are you writing a program for work unless you are helping to solve a problem? The implementation only exists to work with business logic and data. Excel is an implementation that does not care about business logic and data. Anyone can add their own business logic and data.

>Why are you writing a program for work unless you are helping to solve a problem? I'm not entirely sure what your point is here other than implying that the programs I/we write aren't solving a problem, which is not the case. > The implementation only exists to work with business logic and data. This is true. I would say that any implementation of automation is really an implementation of business logic that turns o…

We may be talking past each other.

> "There needs to be better separation of business logic from models so that programmers don't need to 'dig' into business processes and exceptions, and workers don't need to deal with part of their responsibility being shoved into a black box that they're not sure they totally trust or can adapt easily should a need arise."

I agree that this is unsatisfying, but I don't see programming tools fixing this, and especially not "separation"; however, I don't know what you mean by separation. I think UX* is the way to approach this, so that developers account for the actual data and decisions in a workflow. I think you convince the business with better observability.

* UX is not UI.

Post reply on HN