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

231–240 of 511 posts

Re: Programming breakthroughs we need

#231

Post by mike_hearn »

Here's a few thoughts on how to make strides towards what this guy wants, but with tools and features that largely exist today.

RE: Boilerplate

A significant amount of the boilerplate he talks about comes from the web stack not being designed for what we use it for. That leads to a need for a complex three tier architecture, ad-hoc app-specific protocols layered on top of HTTP, and then lots of ad-hoc logic to convert that protocol to and from the underlying database protocols.

Consider how much less code you'd have in a two tier architecture that looks like this:

1. An app that runs on the user's machine, which connects directly to:

2. Your RDBMS, which knows about every user of your app and imposes security/privacy ACLs on them in the standard manner using views/row based security/etc.

In this architecture there is no web server, no REST, no JSON, no JWTs, and therefore also entire classes of security bugs are eliminated in one go (XSS, XSRF, SQL injection, non-transactionality triggered race conditions etc). There are also no load balancers because your DB driver already knows how to do client side load balancing, and a variety of other advantages. When you need more than just standard SQL CRUD operations you write server side function plugins for your RDBMS in a language of your choice and let the DB protocol and servers act as an RPC protocol that happens to support batching, transactions, large result streaming/paging all built in. In effect the RDBMS itself becomes the application server.

Today we don't build apps like this for a few different reasons, mostly related to the inconvenience of distributing desktop software outside a web browser. But that's solvable! And in fact my current project is a company that makes a tool that makes distributing desktop apps as easy as distributing web apps is [1]. With that and a technology like Kotlin Multiplatform + Jetpack Compose, or with JavaFX, you can write a single frontend app that runs on every desktop OS, Android and iOS (where you can write a custom SwiftUI GUI with shared business logic or re-use the Android UI code if you don't need pixel perfect native UI.

There are a few other issues that are all also solvable e.g. tunneling DB protocols through proxies, OAuth/SSO integration, streaming code to the client etc. And as a pattern it really benefits from a powerful RDBMS. But once you have the foundation of brain-dead simple app packaging+signing+notarization from your laptop, with smooth auto update to clients, suddenly you have lots of options to massively simplify up and down the stack.

RE: Text vs abstract code models.

Another big win if you go this route is you suddenly have way more language freedom. The author talks about wanting a database to store his code, but then talks about Rust, for which IDE support is limited. If you use a language with really good IDE support like Kotlin or Java, then your IDE is building a database like the one he wants already. He says it's painful to query that DB but that really depends a lot on what you know and what languages you use. IntelliJ has a structural search+replace feature that lets you do example based queries, and it also has a console and plugins that let you do on the fly queries and structural changes by writing code against their PSI API. You don't have to write full blown plugins [2].

[1] https://www.hydraulic.software

[2] https://plugins.jetbrains.com/plugin/7282-liveplugin

Re: Programming breakthroughs we need

#232

Post by wizofaus »

bcrosby95 wrote: post #170
choeger wrote: post #140

Earlier quoted context omitted.

> It's way-ay-ay more effort Just because you tend to ignore the many complexities that are actually involved in a form on a web page. It's exactly this bias that stems from untyped languages and that needs to die. Http is a complex beast and we should either replace it with something more simple and robust or at least acknowledge the complexity in our programming. Generally speaking, if doing something with a proof…

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.

2-4 single use type definitions per endpoint sounds pretty atypical to me, but I agree choice of language helps here, e.g. TypeScript has pretty powerful typing facilities (Pick/Partial etc) that make type reuse far more practical. It's bookkeeping yes, but definitely not pointless.

Re: Programming breakthroughs we need

#233

Post by mpweiher »

This resonates deeply with me (and my research project).

1. Glue code and boilerplate waste

Yes, yes and yes! Glue code is the dark matter of software [1]

My hypothesis is that the reason we have to write so much glue code, and that it's always sufficiently different is that we don't have the right architectural abstractions. Specifically, our programming languages only support (essentially) procedural abstraction (procedures, functions, methods).

With Objective-S [2][3], I've been introducing language support for other architectural styles. It's been a slog, but recently things are starting to really click together, particularly the combination of "stores and streams" is very powerful and eliminates tons of boilerplate, often reducing it to the "connection operator" →

Which not only happens to be very brief, it's also generic/polymorphic.

3. Why don't frameworks work?

Also really very perceptive observations. Frameworks sort of work, but they tend to be limited by having to represent their domain in terms of procedural abstractions.

4. Non-textual code/modeling

I don't think this is the problem. Modeling is a problem, but a large part of that is because the systems/models we need to build are non-procedural, and so our textual code can only be a meta-program or meta-system that then constructs the actual system. Which is not visible/present in the code we write, but only exists in the running system and in our heads. If we close that semantic gap, having that model expressed textually shouldn't be a huge problem.

The problem is not the text, it's the wrong abstractions that our text expresses.

5. Testing

Not sure the idea of generic testing is that useful, because the key to testing (for me) is its concreteness. That said we can reduce test friction a lot, I think. [4]

6. UI construction

You don't need UI mockups and prototypes - you just program the real thing, because it's that simple. If the user doesn't like it, you can completely restructure it easily.

Yes. I've seen a lot of mockup tools, and it always seemed obvious that writing the real UI should be just as easy (or easier). With NeXT's Interface Builder, we had a large part of that, but sadly Apple has had it languish so horribly that nowadays even imperative code is often preferable, and the fluent APIs such as SwiftUI or React, Flutter etc. seem vastly preferable, despite their deep flaws.

[1] https://blog.metaobject.com/2021/06/glue-dark-matter-of-soft...

[2] http://objective.st

[3] https://news.ycombinator.com/item?id=32444300

[4] https://blog.metaobject.com/2020/05/mpwtest-reducing-test-fr...

Re: Programming breakthroughs we need

#234

Post by david927 »

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…

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 maintainable systems. Yes, currently, it's the best way we've found; just as horse and buggy was the best current form of travel 150 years ago. But it takes very little imagination to expect we'll find better.

Re: Programming breakthroughs we need

#235

Post by Qem »

callinyouin wrote: post #187

The whole "program is a model" part makes me think of Smalltalk's image-based system. I never really got used to programming this way myself, but I do think an image-based environment might check some of the author's boxes. With the right tooling, a Lisp might even be a decent choice.

For those wishing to experiment what a current image-based development environment feels like, I recommend Pharo. Probably is the most advanced open-source development environment in the tradition of Smalltalk, available today. Main site: https://pharo.org/ MOOC: https://mooc.pharo.org/

Re: Programming breakthroughs we need

#236

Post by int0x80 »

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…

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 doing Abstract Interpretation, or Constraint Analysis and Dataflow Analysis (kCFA), which is in way similar to what you suggest of running the program in a profiler, but instead it runs the program in an abstract value domain. With static analysis you will get some imprecisions (false positives) but no false negatives, so it can effectively be very useful for a developer in an IDE. The precision (amount of FPs) and performance are mutually dependent, but good performance and reasonable (read useful) precision can be achieved, although it's a non-trivial engineering problem.

Additionally, some programs cannot be easily and/or quickly executed to cover all possible paths, so parts of the program will remain uncovered by the profiler. That is one place where static analysis becomes very powerful, because you can cover all the program much faster (in linear time making largish precision tradeoffs, but analysis still yielding a usable result).

source: I work on a flagship static analyzer.

Re: Programming breakthroughs we need

#237

Post by lcall »

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…

What I would like, as a step forward at least, is something that fills your ruby (or python) niche, but based on Rust, and when in doubt thinks like rust, so that one can migrate from it to full Rust, with a minimum of re-learning. Same libraries, making them as good as Rails and as easy as Ruby in general, garbage collection, etc. But when you flip a switch (or incrementally, in 2-4 levels?) the full compiler checks kick on, garbage collection is off by default, and it lets you specify the details that give rust-like performance, features, and, of course, ease of distribution (a single, smaller binary). With no re-learning of a whole new language -- taken in steps, if/when one is ready to grow.

That way it could be recommended to someone who would otherwise not be willing to take on a harder language, and they have a growth path. Or for a computer science program, to grow into it all incrementally.

And then yes, make whatever improvements in the OP article, from there.

Re: Programming breakthroughs we need

#238

Post by commandlinefan »

jacknews wrote: post #57

"Writing tests is time-consuming, usually doesn't scale, and it easily creates tight coupling with implementation, which makes change difficult." Amen.

> The only thing worse than testing is not testing, but testing is not much better.

Even more amen.

Re: Programming breakthroughs we need

#239

Post by IshKebab »

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…

Yeah I think you'll realise how bad dynamic typing is when you stop working on solo projects.

Re: Programming breakthroughs we need

#240

Post by the_af »

UglyToad wrote: post #230
Lichtso wrote: post #95

Earlier quoted context omitted.

Actually, I think we have already moved away from pure text a long time ago. Think about it this way: If "text" (so only the sequence of tokens) was the valuable representation, then we would all program without any formating (no additional spaces and linebreaks). Now, you might say well formating is important for readability. These spaces and line breaks do matter. But, just adding them randomly where they are synta…

I actually started writing a blog post along this theme but never got very far with it. I'm not against code storage and representation as text per-se, merely that typing/editing it (text) is a not particularly efficient way of thinking about code. A lot of people I'd characterise as 'words-per-minute is everything' style thinking are seeking the most efficient way to convert thoughts into text input. From punch-tape…

To be clear: I don't think about text and text input in terms of efficiency. Well, that too -- almost every other form of input feels clumsier to me, but that may be because I'm more used to text. But I think typing efficiency is a red herring, a fetish of hackers who also worry about mechanical keyboards and keyboard layouts and "you cannot code unless you use three 4K monitors at a minimum". That's a fetish -- time with code is spent thinking about it, not typing words or even clicking with the mouse. Still, many here will fight to the death to claim these are very important things, even crucial; and I'll politely disagree.

I think text reigns supreme because it's more universal, less convoluted, and has zero vendor lock-in. If you want, the tools to read and edit source code come with your operating system!

There have been tons of musings, thoughts and even projects to replace text representation of code. Where is their widespread success?

I think text is the ultimate "worse is better", in the positive sense of that concept.

Post reply on HN