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

21–30 of 60 posts

Re: On Scaling Mental Models

#21

Post by melling »

hhas01 wrote: post #19
wyager wrote: post #14

Earlier quoted context omitted.

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.

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.

Re: On Scaling Mental Models

#22

Post by AzzieElbab »

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…

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

Re: On Scaling Mental Models

#23

Post by topologistics »

hhas01 wrote: post #17
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…

Bad example is bad example. Programmers are awful for using algebraic symbols to describe non-algebraic semantics. Algebra is already its own language; a lingua franca of math. If you’re abusing it for a different purpose then you’re doing both of them wrong. Otherwise, article is basically arguing we should drag everyone down to the lowest-common denominator “to be safe”, rather than allowing individuals and groups…

> What’s the software equivalent to “Churnalism”?

Basically anything consumer-facing from the past 15 years, especially if it's "mobile"

Re: On Scaling Mental Models

#24

Post by noelwelsh »

AzzieElbab wrote: post #22
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…

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).

Re: On Scaling Mental Models

#25

Post by noelwelsh »

hhas01 wrote: post #19
wyager wrote: post #14

Earlier quoted context omitted.

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.

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 ‘＋’.

Both set union and number addition are examples of monoids, a maths concept from the field of abstract algebra. So there is a maths abstraction that unites these ideas.

Re: On Scaling Mental Models

#26

Post by xyelos »

noelwelsh wrote: post #25
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 ‘＋’.

Both set union and number addition are examples of monoids, a maths concept from the field of abstract algebra. So there is a maths abstraction that unites these ideas.

Uhh quick limiting thing here (although I agree that the addition symbol is fine): the existence of a unifying math concept alone does not justify using the "+" symbol. By that argument, notating permutation conjugation with a "+" is fine, but that would be a notational sin as the "+" operator is reserved for commutative operations.

However, with that disclaimer, noting that both operations form monoids and both are commutative justifies the "+".

Re: On Scaling Mental Models

#27

Post by mason55 »

AzzieElbab wrote: post #16
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…

Curious what happens when V1 and V2 cannot be "plused"

In a statically-typed language you’d just get a compile error. The compiler knows the types of the values in the map and whether or not the (+) operation is valid for them. You’d likely need a little more code than what’s in the GP post, something restricting the values in your map to types that implement “addable” or whatever the terminology is for your language.

In a dynamically-typed language you’d get some kind of runtime error.

Just think of (+) like any other function and what would happen in your language if you call a function with types that the function doesn’t support.

Re: On Scaling Mental Models

#28

Post by msla »

wyager wrote: post #13
hellofunk wrote: post #6

This article also supports why the Go language has been so widely adopted and successful, despite its young age. The language can be rather limiting and somewhat disappointing for an individual developer, but offers great benefits to the agility of a team.

> why the Go language has been so widely adopted and successful That's because it has tons of funding and support from Google, not because people did experiments and found that it worked better.

If marketing was all it took, .Net would have destroyed Java back when Sun was dying and Microsoft was still the monopolistic gorilla of the corporate universe.

Re: On Scaling Mental Models

#29

Post by karmakaze »

amboo7 wrote: post #4

How about this? http://www.linusakesson.net/programming/kernighans-lever/ You can try with a smaller team and make everyone improve rather than complain.

I'd read the 'not clever enough to debug' bit before but not this description. Like the diagram on 'flow state' though it usually a combination of lack of time as well as proficiency that leads to frustration.

Re: On Scaling Mental Models

#30

Post by msla »

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…

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.
Post reply on HN