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

41–50 of 60 posts

Re: On Scaling Mental Models

#41

Post by hinkley »

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…

My most recent Orwellian moment was reading about an old heuristic algorithm with high complexity that has been abandoned as the middle ground between a simpler heuristic and much more complex ones because of its computational complexity.

The problem as I see it is in how they represent the data in a way that makes one think of linear algebra. Refinements brought the naive original implementation down to cubic time, and the literature, as far as I can tell, stops there.

But here’s the thing, when I tried to unpack the logic to figure out what is actually going on under the hood, I realized that a quadratic subproblem could be restated as a sorting problem. Sorting is very much nlogn these days, if not lower due to radix sort being an option.

Which means that this heuristic has the same computational complexity as the naive solution. I’m not saying I’ve discovered anything new, except perhaps that this algorithm is homomorphic to another one. It’s just that it’s so stuck in one representation that you can’t see it for what it is unless you stare pretty hard at it.

Re: On Scaling Mental Models

#42

Post by drewcoo »

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

Re: On Scaling Mental Models

#43

Post by noelwelsh »

oddthink wrote: post #36
noelwelsh wrote: post #24

Earlier quoted context omitted.

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

How you handle this gets into the details of the programming language used for implementation.

The usual implementation technique is type classes, and the issue of having multiple type classes (implementations of, say, monoid) for a given type is known as "type class coherence".

In Scala you could just pass a type class instance explicitly. If Haskell you'd have to change the type.

Re: On Scaling Mental Models

#44

Post by mdrachuk »

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…

Swift extensions are a perfect way to achieve this.

Re: On Scaling Mental Models

#45

Post by Terr_ »

hinkley wrote: post #40
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…

> if the terminology in your code is different than the terminology of your domain that it’s a code/design smell.

Hence the idea/label of Domain Driven Design [0].

IMO like unit-testing it's valuable but you can't hope for 100%. There will always be some concepts that are unique to how the data is being packaged or calculated which aren't part of the business-domain, but hopefully they'll be safely locked down beneath domain-centered abstractions.

[0] https://en.wikipedia.org/wiki/Domain-driven_design

Re: On Scaling Mental Models

#46

Post by Terr_ »

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…

Two more possibilities to add onto the pile: Transpilers (like Typescript to Javascript) and custom Domain Specific Languages.

Re: On Scaling Mental Models

#48

Post by AzzieElbab »

mason55 wrote: post #27
AzzieElbab wrote: post #16

Earlier quoted context omitted.

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

Re: On Scaling Mental Models

#49

Post by harperlee »

This is an interesting hypothesis, and I've also heard something similar said of clojure: it makes lisp just a little bit less opaque (by way of macros not being so popular, introducing {} and [] as a little bit of extra syntax, emphasizing a very targeted philosophy on several aspects, etc.

Re: On Scaling Mental Models

#50

Post by msla »

noelwelsh wrote: post #34
msla wrote: post #30

Earlier quoted context omitted.

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.

And I'm pointing out how useless of a definition that is, because it renders us unable to distinguish between some languages which do have and use type information and other languages which do not. If a language has enough type information to automatically convert a number into a string, it isn't the same as one where everything is simply a machine word.

Plus, my comment about stringly-typed Haskell demonstrates that it's a property of programs more than languages anyway.

Post reply on HN