Hacker News Reader

> I think the false premise here is that non-experts can build on the work done by experts.

I'll take a different side to that argument - it is dependent on the expert to establish the bounds and rules of change to a system. How a system naturally grows from people with less context is one of the architectural traits of the system that can be traded on.

I have often seen systems which can ONLY be worked on by the so-called "expert" who wrote it. Even when you hire a new "expert" level person to work on it, it takes forever and success is not gauranteed.

On the other end - a system that actively works against doing things the wrong way. It has an established core idea with clear boundaries between the roles of interlocking parts. For the intended usecase of the system, it is as extensible as it needs to be, while still remaining within the bounds of the intended usecase. It does now allow a vacuum cleaner to become a microwave oven, but it does let you add custom attachments, modify and swap out drive systems, adjust suction power, and change body style and hoses for the vacuum. Those can absolutely be done by non-experts, and the system is still very malleable.

Think of all the code on github for libraries people use every day that is added by non-experts, or hobbyists, or people who are new.

Emacs makes a pretty good example from my perspective, but if you haven't used it I suppose it makes little sense. Perhaps AutoCAD from what I understand, but I don't have enough experience with extending it to say for sure.

It's not that you have to extend it yourself, the point is to make it possible.

Annie in accounting (can't believe you got away clean with that one :) might ask someone else in the company to help her add a shortcut or whatever, or the company might hire an outside consultant.

There's an entire gradient from non-technical to expert that's effectively shut out from modifying most software.

Now I'm as guilty as anyone, getting a client to pay for an advantage they can't imagine the consequences of isn't happening much. But I can certainly see the value.

Whoa! What do you have against hillbillies? :)

Jokes aside, imagine if Annie in accounting has the ability to define her own malleable tools, on top of a solid/robust system for centrally managing data? (version, backup, secure via IAM, etc)

Or will we really be stuck writing procedural code for the next 20, 30, 50 years?

--

[1] Caveat: chief hillbilly of https://mintdata.com here, where we think you really can have your cake (create expressive tools) and eat it too (centrally control, manage, and version your data) .

Sure, but that's not "modifying the original system" any more. That's taking the original system (original abstraction) as a fixed/static foundation, and then expressing things in terms of it.

Which, I mean, if the tooling you've made is Turing-complete (Excel, Unix) then you can certainly say that the person working on top of your system is "programming"; but they're not programming your system. They're not writing plugins that interface with it on the same terms that its components interface with one-another (as you would be if you e.g. wrote your own POSIX shell utilities in C); they're trapped "above" that abstraction, in a sandbox, one from which they can only access the narrow subset of the API surface that you explicitly chose to expose to them.

Let me put it this way: you can get pretty far using e.g. Postgres as a custom data platform, by defining custom functions and types. But at some point, you'll need to write a Postgres extension. There's a big difference between a system that makes it easy for someone who's not a professional programmer to work on top of it (PG functions/types) and a system that makes it easy for someone who's not a professional programmer to extend it (PG extensions.) I've not yet seen a constructive proof that the latter is even possible.

I'll give you an example that mid-way [1] disproves the above.

Think of a typical "product tour" in a SaaS product. We're building the MintData product tour, in MintData itself. We then "publish" this "product tour application", and include it with the original blank design that a user gets when they first enter MintData.

So, in a way, our MintData onboarding is built in/on MintData itself, a bit like how you can have a bootstrapping compiler (one that compiles itself).

So, is the above us "modifying the original system"?

I think to some extent yes, although we have special spreadsheet functions that help jump the gap between Onboarding Application and Blank User Design (akin to the Postgres extensions [2] above).

So I think it is possible to build a system that allows you to then customize the system's own behavior (earlier versions of MintData could not build the onboarding experience, similarly to how the first compiler has to be built in a lower level language).

Genuinely curious -- derefr, do you agree or disagree with the above?

--

[1] Chief abstraction wrangler at https://mintdata.com, so YMMV on the above.

[2] As a person who was held at Grade-point and forced to write PostgreSQL C code to "modify the original [Postgres] system", I can only say it's an acquired taste :) Even Prof Franklin at UC Berkeley I think would back me up on this :D :D

Seeing your product shilled so blatantly repeatedly as one goes down the comments in this thread is pretty off putting.

Ouch! That hurts!

My only response is this: https://youtu.be/Mm4epcGApnY?t=14

Bootstrapping means only one thing: The entirety of a system is implemented within itself. This feat is binary: Only 100% means anything.

Your example is also very clearly not related in any way to "modifying the original system". Instead, it just means that you yourself have used project A (MintData) as a customer to make a distinct project B (an onboarding system that happens to be for MintData itself).

Modification is not assembling provided building blocks. Rather, it is changing the building blocks themselves. Say, you provide a HTTP JSON API, and I want to add support for websockets. Maybe I want to add entirely new data ingress/egress facilities. Or perhaps add a JavaScript interpreter to the backend to allow for rules and cron jobs written in JavaScript.

In your case, I see an ERP system which can be configured by users to do various things. From the perspective of the user, the original system is immutable, and they are no more able to change your product as a user than they are able to change Squarespace, GitHub, or for that matter Netflix and Spotify.

If you have navigated PostgreSQL C, you must surely understand the difference between configuration and modification.

---

General marketing trick: Use the product name less. It makes it stand out more to put it in one, well-placed spot. Use it too much (like above), and it instead becomes noise.

I think I get what you're talking about. Some systems are designed in such a way where the "platform" is formed in two layers: a low level, which exposes a set of primitives; and then a set of abstracting core libraries, implemented in terms of those primitives. Users are expected, idiomatically, to create business logic by making calls into the core libraries; but they're also free to call on the low-level primitives directly. In such a system, the "userland" sits directly on the primitives, with the core libraries as a sibling.

This is the pattern adopted by some, but not all, "runtimes." For example, Erlang has the low-level BEAM VM, and then has the Erlang "kernel" implemented as BEAM bytecode, rather than as native emulator support code. For another example, MOOs (object-oriented MUDs, e.g. LambdaMOO) only had the barest object-graph infrastructure specified in native code; everything else about the foundations of a MOO was defined in terms of objects and classes held in the MOO's state database.

In such systems, you have a sort of "intermediate" level of access to the native API surface, greater than the kind you have from the userland of a traditional VM or OS kernel.

Still, this "intermediate" level of access still doesn't allow you to break through the abstraction layer that the low-level primitives are founded upon. If there are any "complex" primitives implemented entirely natively (e.g. Erlang's `term_to_binary` function), then you can't "break into" that primitive to extend it unless the native runtime has been extended with an explicit "upcall" hook back into the VM userland.

You've linked to your site on at least 4 comments in this thread, which is really taking away from the comment experience. I am glad you're enthusiastic, but make sure the disclaimers don't take away from your (otherwise great!) comments.

Point taken :)

Is it ok to shill Roosevelt?

[1] https://youtu.be/Mm4epcGApnY?t=14

Hillbillies are some of the best mechanics.

I strongly disagree, and I think your example actually supports this position. Most people don't modify their cars at all, but for the people that do find great pleasure in it. We see this with software, too. I think that opposing people who would like to mess with the things they use is limiting and fundamentally somewhat disappointing. It's essentially impossible to make software that caters to everyone's needs, but I think the best you can do is make something that works for most people out-of-the-box and let the few people who want to tweak things to their liking themselves. (To extend your analogy, I don’t know the first thing about cars but I have very few complaints with mine. If I didn’t like something about it, locking me out from changing it prevents me from taking it to my car-enthusiast friend.)

But this is a lot of effort to please a small part of the audience. And if you don't get it exactly right, it'll expose your entire customer base to security concerns.

I'm old enough to remember the rounds of Word viruses spread by email.

90% of the users of a piece of software won't modify it if they could. 90% of those who modify it, will create crap. 90% of those who write something useful will be benign. But the remaining 0.1% will write something evil that means everyone suffers. And suddenly it's your fault for allowing this, and your problem to fix.

>> from the hillbilly type VM bug/truck combination to the amazing Cobra replica that few can tell from the real thing.

lol! I'm a hillbilly living in the Ozarks who used to make custom cars for movie stars in Hollywood and race cars for guys like Larry Fullerton and Tony Nancy.

Thanks for the laugh!

Your comparison to physical systems is spot on. There are very few physical devices that are malleable in this sense. We'd be better off advocating for more open source, better development tools, and new programming paradigms or languages designed to help novices learn. However, we are overdue for a revolution in how computers are programmed. Editing text on a screen is straightforward and fairly universal but we should be trying to take advantage of cheaper and more widely available user interface devices to improve how we translate thoughts into programs.

Yet automobiles are malleable :) And what about farmer's equipment? The farmers, for example, definitely want it malleable (see e.g. ["Nebraska farmers vote overwhelmingly for Right to Repair"][1]).

[1] https://news.ycombinator.com/item?id=21805633

I would say that the more generalized software is, the larger the audience, the more likely there will be Strong Boundaries between the Practical and the Theoretical.

That said, Licklider was a very special person.

This video from Alan Kay talked about him @ 32:42

https://youtu.be/id1WShzzMCQ

It's mostly a pipe dream but it's not an absolute zero.

See how Nintendo crafts its games, they layer complexity through symmetry in early levels.

I agree that most users are not in a place to solve their problems, especially with the state of software as it is (too many ad-hoc rules). But when presented with the good lego bricks, I believe people can progress.

And yet there are tens of thousands of userscripts, even without any "malleability" intended by website authors, just because platform allows some introspection and extension:

https://userscripts-mirror.org/scripts.html