Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Scaling Mental Models

buttondown.email

Post reply on HN
Print view View original

31–40 of 60 posts

Re: On Scaling Mental Models

#31

Post by jchook »

melling wrote: post #21
hhas01 wrote: post #19

Earlier quoted context omitted.

By all means, steal ideas from math. (Great artists, etc.) Math has had a couple thousand years practice in learning how (and how not to) express abstract ideas as formal written text. But don’t abuse math. Like redefining summation to mean any old thing under the sun. Least of all when it’s a fricking union, for which the math symbol is ‘∪’, not ‘＋’.

Union symbol is not on the keyboard. Sure, make it easy to type then we can use it instead of + However, anyone who has been programming for a while should be able to puzzle out what + is doing.

Emojis aren’t on the keyboard either but folks don’t seem to have a problem typing them, even on desktop.

Funny that software engineers can figure out complex parallelism and algorithms, but typing ∪ as a function name is next to blasphemy.

Re: On Scaling Mental Models

#32

Post by fjfaase »

noelwelsh wrote: post #7
fjfaase wrote: post #5

Articles like this are missing an important point. Namely, that generic data structures in programming languages are used to represent rich semantic data models. This is done by a process that I would call 'implementing'. It is a mapping of a certain semantic model to, often a rather limited, set of primitives. Some languages, are completely optimized for one type of data structure. Take for example the relational da…

Your comment in a good example of the very different world views that exist within programming. I'm not trying to bash on your comment, just illustrate the difference and show how this makes communication trickier than we sometimes acknowledge. In a modern typed language you wouldn't represent an ID as an integer or a string, you'd represent it is an ID. Then define addition as whatever makes sense for IDs. This can…

I thought I was trying to communicate just the opposite, that during implementation all kind of semantic information is lost. One could define a type as a semantic property, which goes much further than specifying it range of valid values. Think for example about the unit of a double value. I have not seen programming languages where units are an essential part of the language. Several billion dollar disasters could have been prevented if such a language had been used. And this is apart from where a language is statically or dynamically typed. Types can also be viewed as annotations that can be used to verify the correctness of an executable specification (program). One could had a type stating that a function terminates with less than C.n^2 operations of a certain type, where n is one of the parameters of the function. These are often things that are reasoned with at the semantic domain, but are lost when the actual implementation is made.

I realize that this requires a different mode of thinking about software engineering than is common among software engineers. I also wonder whether most software engineers could be called engineers, because it looks like it is more a craftsmanship than engineering, like mechanical engineering where they are able to accurately predict the properties of a certain object before it is actually being made with the help of standard methods, such as finite element analyses.

I have to admit that we are working in a far more complex domain, but it seems to me that not much progress is made in the field of software engineering. Probably also because technologies are moving too fast to build a solid foundation and that the demand for solutions is too high.

I am surprised how few software engineer understand that main problem boils down to the fact that computers are too slow for our demands. See: https://www.iwriteiam.nl/AoP.html

Re: On Scaling Mental Models

#33

Post by carapace »

> “powerful languages don’t scale”.

The "scale" he's talking about doesn't seem to be "of traffic" or "of data" but rather "of programmers required to work on it".

> it’s hard for other people to work with you. They don’t share your mental model, and they don’t come in with all your initial assumptions. This is somewhat addressable if you all start working on the project together but falls apart when people join on later. The expressivity doesn’t scale.

So that's a failure of documentation, eh?

Re: On Scaling Mental Models

#34

Post by noelwelsh »

msla wrote: post #30
noelwelsh wrote: post #7

Earlier quoted context omitted.

Your comment in a good example of the very different world views that exist within programming. I'm not trying to bash on your comment, just illustrate the difference and show how this makes communication trickier than we sometimes acknowledge. In a modern typed language you wouldn't represent an ID as an integer or a string, you'd represent it is an ID. Then define addition as whatever makes sense for IDs. This can…

Very few use untyped languages anymore, and only to the extent people program in assembly language or modify Deep Legacy stuff in Bliss. It's possible to lose information in a dynamically-typed language, like Python, but that's a matter of not using the language facilities, such as objects, and if you go down that route, you can write stringly-typed Haskell.

My mistake. I was using "untyped" in the sense it is used in programming language theory, which is the same as the term "dynamically typed" in colloquial programmer speak.

Re: On Scaling Mental Models

#35

Post by carapace »

wyager wrote: post #14
TuringTest wrote: post #8

The problem with powerful languages is they're great for allowing you to create new abstractions, but they're terrible at piercing that abstraction and let you know what's going on inside when you need it (such as, when learning what the abstraction means when you find it for the first time). Current modern languages are built around the false dicotomy that you have to choose between one of two representations, like…

Another strategy: Instead of creating new abstractions willy-nilly (which will probably be "wrong" in some sense you won't discover until much later, when it's too late to drop it), you base your abstractions off something that selects for "correct" low-entropy abstractions, e.g. by stealing ideas from math.

"Computer Science could be called the post-Turing decline in the study of formal systems."

Re: On Scaling Mental Models

#36

Post by oddthink »

noelwelsh wrote: post #24
AzzieElbab wrote: post #22

Earlier quoted context omitted.

Wrt to code sample in the original article, are you saying live would be so much easier if everyone knew what monoids are?

Saying life would be "so much easier" seems like a strong statement, but I expect programming would be. :-) When I read that example the semantics were obvious to me: adding a map (applying a monoid operation on a map) should add the elements (apply the monoid operation for the elements).

But one of the examples of adding maps would be for it to mean "upsert", rather than "use the monoid for the value types". I think that's still a perfectly good monoid over maps (it's not commutative, but that's not a requirement).

And yes, you can argue that using "+" implies commutative, and I can see that, but I think it's still a plausible meaning in this context.

(I'm probably rabbit-holing here, but it's interesting.)

Re: On Scaling Mental Models

#37

Post by DmitryOlshansky »

The problem with most great projects written by small group of brilliant people in any language:

- it introduces its own vocabulary, it looks like gibberish until you build up the context

- since the group is small and gifted they have no problem creating and using the power tools of their own

- there is no documentation so your only way is through experimentation and direct communication

- the folks who have built it had to move on to solve another (bigger) problem, leaving no traces of what the vocabulary is, where the design was headed, what should be changed with the new requirements and again next to zero documentation

Re: On Scaling Mental Models

#38

Post by hinkley »

DmitryOlshansky wrote: post #37

The problem with most great projects written by small group of brilliant people in any language: - it introduces its own vocabulary, it looks like gibberish until you build up the context - since the group is small and gifted they have no problem creating and using the power tools of their own - there is no documentation so your only way is through experimentation and direct communication - the folks who have built i…

Circular reasoning is hard to manage out of a project. Circular reasoning that has never been articulated is much worse.

Some of the best ergonomic improvements to my own code have come from trying to explain why my code is so stupid and figuring out that there is a fix that’s easier than this apology. When it’s three people there are no apologies even offered, and almost no feedback.

Re: On Scaling Mental Models

#39

Post by hinkley »

carapace wrote: post #33

> “powerful languages don’t scale”. The "scale" he's talking about doesn't seem to be "of traffic" or "of data" but rather "of programmers required to work on it". > it’s hard for other people to work with you. They don’t share your mental model, and they don’t come in with all your initial assumptions. This is somewhat addressable if you all start working on the project together but falls apart when people join on l…

No, it’s often a failure of architecture or design.

People who build systems that only make sense to them are never going to provide good documentation, no matter how often you ask for it. And it’s always describing something that is already ‘done’, so there is very little value as a feedback loop. You just stop asking when you either realize this is all you’re gonna get or figure out how batshit what they’ve described is.

Sunlight is the best disinfectant, they say. Ex post facto documentation provides almost none.

Re: On Scaling Mental Models

#40

Post by hinkley »

noelwelsh wrote: post #2

The problem is programmers crafting the language to their own mental model. One solution is languages that don't allow much abstraction. The other solution is to craft a shared mental model. This latter approach is the more powerful in my opinion. Taking the example of adding maps, you (where "you" means the language designers or language community) just need to define what `+` means for primitive types and the compo…

I’ve heard one of the early Agile luminaries say that if the terminology in your code is different than the terminology of your domain that it’s a code/design smell. Some day, if not already, that impedance mismatch will bite you in the ass.

Architectural astronauts are fond of their own terminology. It’s nuts. Especially if it’s from someone like my most recent perpetrator who tries to use big words all the time and either gets them wrong or uses obscure meanings that nobody else ever uses conversationally. You may be smart pal, but you’re the biggest idiot I know.

At least the last astronaut was personable and had a hint of humility.

Post reply on HN