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

51–60 of 60 posts

Re: On Scaling Mental Models

#51

Post by pron »

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…

> One solution is languages that don't allow much abstraction.

I think we need to be careful here with what you mean by "abstraction." One kind, which we can call "syntactic abstraction" means the following: given a specific language, what portion of its syntactic patterns can be factored into a new construct that "abstracts" all of its instantiations. Languages with macros score very highly here. Another kind, which has been more studied mathematically, is what we can call "algorithmic abstraction" or "behavioral abstraction", which means that given a certain specification of a desirable observable behavior, what portion of the implementations of that behavior can be exposed with the same syntactic construct (the same API). On this front, Haskell has worse abstraction than Java (e.g. if you want to change the implementation of a map to support big data with disk writes, you have to change the syntactic construct), and a language like Rust has terrible algorithmic abstraction, as even different implementation details like memory lifetimes require different constructs. Every additional piece of implementation detail that is exposed in the syntax level (e.g. in the type) hurts abstraction. I don't think that proponents of exposing as much as possible in the type think that's a bad thing, though.

Both of these kinds of abstraction allow you to "leverage existing knowledge in new domains", and both have a certain "mental" cost. I don't think it is possible to relate "abstraction" in general to any bottom-line result, especially as no language choice seems to show any big impact one way or another, but mostly cater to different personal aesthetic preferences.

Re: On Scaling Mental Models

#52

Post by marmaduke »

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…

> craft a shared mental model. This latter approach is the more powerful

Isn't the crux of why programming is a technical activity second and a social one first?

Re: On Scaling Mental Models

#53

Post by erik_seaberg »

drewcoo wrote: post #42

So language/tooling choice should be a sort of a Harrison Bergeron* affair, to make sure that the least able to program will still be able? I'm not so sure I agree with that. Nor do I agree with its obvious counter-proposal, meritocracy. I have heard of teams using "communication" to bridge these gaps but I know little of that technology. * https://en.wikipedia.org/wiki/Harrison_Bergeron

You can't let anyone work at the top of the learning curve (where the payoff is, where professionals belong) unless the whole team is capable of getting there. This is part of what makes false positive signals in hiring so damaging.

Re: On Scaling Mental Models

#54

Post by amboo7 »

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…

3. You can actually try and understand most of what's been written through reading, given that you're allowed the time for that. It's an investment, prevents technical debt and promotes progress. No one is born with the mediocre skills of big teams, one can (almost) always improve.

Re: On Scaling Mental Models

#55

Post by AzzieElbab »

AzzieElbab wrote: post #48
mason55 wrote: post #27

Earlier quoted context omitted.

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 o…

Well, in Scala with default predef it would depend on the order or the arguments. If first one is a string it would just append string representation of the second one. One could use a random generator to guess what would happen in JavaScript. I do not know what Python does in these cases

Sorry for being cryptic, the point was that I prefer appenders being explicitly documented in types or method signatures instead of some built-in magic

Re: On Scaling Mental Models

#56

Post by jart »

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…

Notation is the word you want. For example, we can design our language to say ht[x]=y or HashInsert(hTable,key,value), but at the end of the day they both abstract computer science toil don't want to think about, e.g. should it cuckoo probe pascal triangle bucket tree big theta under the hood yadda.

My opinion is that terse notation only gains consensus when it's divinely inspired. That's the word we've traditionally used to describe the np-complete social phenemonon that happens every so often, where some guy's arbitrary mental model manages to allure a lasting self-evident appeal, e.g. LISP, C, and Python. So in some ways, we can think of guys like John McCarthy as modern programming prophets.

One interesting thing I noticed, reading John McCarthy's original paper, is he was actually trying his darndest to not introduce a new notation. He wanted LISP code to look normal, since it's usually not a good thing to come across to other smart people as claiming divine inspiration (see Dunning Kruger).

I disagree with the conventional wisdom though. If you'd want to take the more powerful approach of crafting a shared mental model, my advice would be one of encouragement. You can absolutely be the next John McCarthy. Folks only use wordy notation like HashInsert(hTable,key,value) because they want to go the safer route of being a small successful part of a large corporate machine.

Re: On Scaling Mental Models

#57

Post by erik_seaberg »

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…

I don't see how learning a vocabulary could ever be harder than continually trying to get the same concepts across without having vocabulary.

Re: On Scaling Mental Models

#58

Post by kazinator »

jasode wrote: post #12
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…

>you should be able to inspect the meaning of the more abstract syntax by expanding its definition in place and see how it works in context. [...] But why that approach is not integrated into the language itself, I have no idea. Are you asking why _all_ programming languages don't make their own Abstract Syntax Tree a 1st-class concept for self-reflection and manipulation of its own syntax like Lisp? Because there ar…

The main reason is that designers are not even aware of the techniques. You can get CS degree that includes compiler work, and have a head full of LALR(1), without knowing anything about the Lisp approach.

In my Alma Mater, at the time, there was a third year course in programming languages that had Scheme exposure. The follow-up fourth year course in compiler construction was all C hacking with Lex and Yacc, and that was that.

I was able to wriggle out of taking the prerequisite, too.

Re: On Scaling Mental Models

#59

Post by wyager »

xyelos wrote: post #26
noelwelsh wrote: post #25

Earlier quoted context omitted.

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…

Haskell doesn't use the + symbol for monoids, it uses .

Re: On Scaling Mental Models

#60

Post by TuringTest »

jasode wrote: post #12
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…

>you should be able to inspect the meaning of the more abstract syntax by expanding its definition in place and see how it works in context. [...] But why that approach is not integrated into the language itself, I have no idea. Are you asking why _all_ programming languages don't make their own Abstract Syntax Tree a 1st-class concept for self-reflection and manipulation of its own syntax like Lisp? Because there ar…

> Are you asking why _all_ programming languages don't make their own Abstract Syntax Tree

No, I'm asking why there isn't _any_ programming language (that I'm aware of) with an integrated IDE where you can make static code rewrite expansions (replace an function call instance with its definition) at writing time, and instead depend on waiting until runtime to have an in-memory stack and navigate between functions to see how a function call will run.

Post reply on HN