Programming breakthroughs we need • Hacker News Board

Re: Programming breakthroughs we need

#321

Post by int0x80 » Wed, Aug 17, 2022, 10:00 PM UTC

bsedlm wrote: post #318

int0x80 wrote: post #236

Earlier quoted context omitted.

Something very close to this can be done and it's in fact done already by static analysis. Static analysis doesn't have any Turing complete problem. Static analysis has a limitation of providing complete answers because of the halting problem, but it can provide instead sound answers. That is, static analysis can provide all possible runtime types for any given (e.g. python) expression. This can be accomplished by do…

do you know any textbooks on abstract interpretation?

"Principles of Program Analysis" covers the subject very well. It's not an easy or beginner book because it's very formal, but very complete and with plenty of examples.

Re: Programming breakthroughs we need

#322

Post by solomatov » Wed, Aug 17, 2022, 10:00 PM UTC

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…

Go and Rust with go and cargo commands correspondingly have great tooling in this respect. As long as you use one language, everything is very convenient.

Re: Programming breakthroughs we need

#323

Post by dkottow » Wed, Aug 17, 2022, 10:00 PM UTC

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.

True, but just using Excel does not lead to decent data models, though. IMHO, what we would need is for "regular" folks to grasp the basics of relational database first (at least 1:n and n:1) and then build an easy to use excel-like tool around it.

Re: Programming breakthroughs we need

#324

Post by fegu » Wed, Aug 17, 2022, 10:02 PM UTC

It sounds like he needs to try Haskell, or strong typed functional in general. Less boilerplate, less testing, less worry when changing code later.

Re: Programming breakthroughs we need

#325

Post by solomatov » Wed, Aug 17, 2022, 10:02 PM UTC

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.

>More and better tools that let "regular" people program.

There's one catch with Excel, the more complicated your spreadsheet gets, the closer it gets to programming. And at some point, it's more cost effective to write in a proper programming language than continue to maintain mess.

However, until this complexity level, Excel is great, and empowers a lot of people who barely know the basic features of Excel to solve their computational problems.

Re: Programming breakthroughs we need

#326

Post by rileyphone » Wed, Aug 17, 2022, 10:06 PM UTC

Banana699 wrote: post #88

bsedlm wrote: post #63

Earlier quoted context omitted.

yes. I wish I could somehow get to work on a blend between: a decompiler, debugger, emulator, static analyzer, memory profiler, and so on. The idea being some kind of a runtime for assembly code which does not actually execute the program but allows one to understand it in different sematinc levels, or dunno.. this is a very raw idea. needs a lot of work (and a lot more knowldedge) to set down. too bad none of the pr…

I think dynamic analysis is incredibly powerful and criminally underused in IDEs and other dev tools. I have thought of an idea about 6 months ago that has been fermenting in my mind since then : what if (e.g.) a Python VM had a mode where it records all type info of all identifiers as it executed the code and persisted this info into a standard format, later when you open a .py file in an IDE, all type info of the o…

The idea of runtime type feedback was originally explored by the SELF group for optimization [0], and is currently used by JS runtimes like V8. The obstacle your vision faces today is that program editors are almost all completely separate to the languages they are used for, and thus such communication with the runtime is enormously painful and complex. Time to return to the truly integrated development environments of Smalltalk/Lisp with modern niceties like gradual types and multicore processors, methinks!

[0] https://dl.acm.org/doi/pdf/10.1145/178243.178478

Re: Programming breakthroughs we need

#327

Post by probablypower » Wed, Aug 17, 2022, 10:06 PM UTC

csours wrote: post #100

probablypower wrote: post #93

For me it is the separation of business logic and data from the programming implementation. Often the workflow in automating a work process is: - Worker has intuition on how things work - Specialist starts automating and running into exceptions, walls - Worker explains exceptions as they're discovered - Specialist adds spaghetti to the 'clean' business logic model they started with - This keeps going until the end re…

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 one set of data into another. For example, taking financial transaction data and using business logic to convert this into data that measures company profitability.

> Excel is an implementation that does not care about business logic and data.

Yes and no. Consider the example of transaction data -> profitability measures. If you compute this in excel, you are hand entering data (or using data inputs if you're not a neanderthal) and you're inserting business logic into cell formulas that relate to other cell formulas. Maybe you're even using VBA. Business logic is embedded in the worksheet. This is why you end up with a lot of small companies that have "THE" accounting spreadsheet and "THE" inventory management spreadsheet. It is the extent to which they can automate.

I don't know if you've ever tried to detangle the business logic from an excel spreadsheet, but it is a pain in the ass, and it is very bug-prone. Tracking down bugs and errors in an excel spreadsheet is spiritual torture.

> Anyone can add their own business logic and data.

I guess you may have read my post from the perspective of a small company, where it is entirely feasible to store your company's data and business logic in spreadsheets. I'm coming from the perspective of a large enterprise where having excel spreadsheets on the critical path of any business process is a disaster.

Re: Programming breakthroughs we need

#328

Post by synergy20 » Wed, Aug 17, 2022, 10:07 PM UTC

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…

A huge opportunity here: ways to assist developers to figure out how existing code base works by generating code flow, class hierarchy, etc.

yes there are a few tools on the market, nothing really standout though, maybe it's for AI/ML to innovate in this field.

Linux kernel is well designed, in that I can add code relatively easy into its subsystems, it's those Object oriented or FP code base that bothers me the most, especially when they're large, often times they just made me feel hopeless, good tools desperately needed.

Re: Programming breakthroughs we need

#329

Post by bmitc » Wed, Aug 17, 2022, 10:17 PM UTC

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 would argue that a huge or maybe even the primary reason why maintenance is so hard, though, is because a lot of software was originally not written "correctly", that is without maintenance and longevity in mind.

The hardest part of maintenance, in my experience, is that programs were developed under needless or incorrect constraints and then expected to be magically maintained. There is a huge downstream effect of decisions made early on in a software system's life.

The story of "just get it working" that evolves into "now that's it's working, don't change it but add these new features" repeats itself over, and over, and over. It's not surprising why maintenance in systems developed like that is hard.

Re: Programming breakthroughs we need

#330

Post by akomtu » Wed, Aug 17, 2022, 10:21 PM UTC

The #1 thing we need is a paradigm shift w.r.t complexity. We know that complexity, as the number ofvthongs you need to keep in mind to see the big picture, grows with the size of the project, but that growth varies greatly. A bad programmer writes code in such a way that complexity grows quadratically: it quickly crosses the threshold of being understandable by anyone and then the project is better to be redone. A decent programmer keeps the complexity linear by separating it into pieces with clear interfaces and behaviors. A great programmer can keep this growth sublinear, logarithmic maybe, but it's an art - this is what makes huge projects possible (linux, etc.) The paradigm shift would be a formal way to enforce low complexity growth, so even mediocre programmers can't f-k it up, similar to how syntax correctness is enforced.

The #2 thing is documentation, which is in a very sad state right now: everyone writes boatloads of unstructured text that vaguely amd loosely explains something, and newcomers have to either parse this mess, or ask those who know for a digestible summary. This happens because text, the way we write it, poorly represents our thought models. We've learned to split text into words, words into paragraphs, and paragraphs into chapters, and we've even invented content tables, but all that isn't enough to deal with the enormous complexity of software we have today.