Hacker News Reader

Comment by catnaroek | Hacker News Reader

> I wish I could do this with larger code bases but unfortunately, from my own experience, planning time is exponentially related to the projected lines of code.

Hence more work has to be done on expressing solutions to big problems as the composition of solutions to smaller problems. Which is fundamentally an algorithms problem.

> Current abstraction methods are subpar: they require inherent complexity, are language specific, and are not easy to change after you've using them (unless you have adapters on every part of the code base which in it's own right becomes a mess).

Programming languages exist to implement algorithms, which in turn exist to solve problems. If your language of choice is getting in the way to implementing the algorithms you need to solve problems, you have to switch languages, not anything else.

View on HN

Not everything can be done through algorithms, actually, a lot of programming involves just designing parts, where to hold state, interactions between components, basically what is called architecture.

> where to hold state

Wherever it makes the most sense for the algorithms you want to implement.

> interactions between components

Again, driven by the needs of the algorithms, and, most importantly, their proofs of correctness.

That is a very simplistic 1D view of programming. Quicksort is an algorithm, algorithsm are often reused. A UI framework is not an algorithm, and it is most definitely if you are writing a UI.

> A UI framework is not an algorithm

I think it is. A framework is a pattern of behaviors. You have inputs, transforms, and outputs. Some are connected, some you leverage by use case - standard library of a utility or core namespace (e.g. from flask import jsonify)

You have those, but you don't have core algorithmic property of an effective method that can be computed within a finite amount of time and space. It isn't even very meaningful.

In the meta sense, you might be able to come up with an algorithm that makes connections automatically, but then...it is meta.

Unifying algorithm and architecture has been somewhat of a holy grail of PL, being able to express your whole program (including your frameworks) as just procedures would be very convenient, but no one has figured out how to do that.

> you don't have core algorithmic property of an effective method

If a software framework doesn't have idioms, I'm not sure it's a framework. Examples of frameworks that have no case for using it dont do well.

It’s more like it doesn’t make sense. Of course they have idioms, but idioms are not deterministic decision methods.

Don't be dense. How a controller in an MVC framework maps to a url and provides an execution path through the framework is an algorithm. The fact you plug in multiple values to make that happen (including the executing function) is the idiom that results in a consistent algorithm. You can alter this, which isn't a compelling argument.

A UI framework is better understood as an algorithm plus a psychological model of your user. You must understand what they are thinking at every step of the way, guide them to the answers they want, and help them avoid pitfalls.

This is by its very nature a less deterministic solution than a pure algorithm.

Reply on news.ycombinator.com