Not to throw a spanner, just wondering. But isn't the whole problem that there's no neutral "conceptual difficulty" independent from the language used?

Pretty sure there is.

At the very least, from the information theory.

Interesting. What I find hard to take apart is the language itself vs the provided functionality via libraries (core lib, external) what makes some tasks easier/harder. Like if something requires sorting and your language doesn't provide sorting functionality then it looks harder than the same thing in a language that does provide it. Same thing for immutable datastructures, or other high level stuff. But if we take into account all libraries that can be made, maybe all lines are almost the same? Does a language with a bigger core library counts as "more powerful" in some sense? I think it is hard to take apart because some things that are core to a language are libraries to others.

Yeah, they're all turing complete, making them all a straight line in some sense. The difference is in the "cenceptual" difference at the human understanding level and how much the tax is there

I assume the graph would also be pretty academic in the sense that it's displaying ideals. Like Clojure may be "better" at problem X than Java, but if I'm less proficient in Clojure than Java, the reality could be quite different for me. The graph may be accurate only if I was equally expert in both

Of course. Or, if it somehow was tailored to your proficiency.

Another tough metric to measure, I think. Random aside: it always made me giggle when we received student resumes at work that showed a "skill rating" for languages with stars or percentages. Like here's a uni kid with 90% Java proficiency

what I think could be pretty different between languages is how hard is it to modify/extend/evolve something. Since that will depend a lot on the basics of the language.

Yea I think an easy example for the leftmost curve would be if you had no standard libraries.

@U04RG9F8UJZ > This is ten percent shell, twenty percent C > Fifteen percent concentrated knowledge of Zig > Five percent Java, fifty percent Perl > And a hundred percent reason to coil up in a curl

This kind of graph feels like a place where the undelivered promise of a digital AI assistant could shine: it knows me so well, it can construct a graph for a problem based on my personal strength and weakness metrics

"hey google, help me choose a programming language for this problem"

"According to your recent search queries and your psychological profile, due to accumulated frustration you have a 95% chance of giving up on this problem before solving it, in any programming language. I suggest you look at these images of funny kittens instead."

I guess another way to measure a language like that is, "What is the shortest path between idiom 1 and idiom 2, for languages A, B and C? Which language has the most shortest paths for most common idioms?"

But maybe you can hack every situation by just making some inscrutable interpreter every time, so the shortest path is always some irreducibly complex thing

Too much thinking in the morning @U2FRKM4TW I need more coffee lol

@U2FRKM4TW this is interesting but I wonder if you aren’t just trying to avoid your original problem. No more distractions! Go solve that thing.

> But maybe you can hack every situation by just making some inscrutable interpreter Somewhat similar to archiving tools. You can always include a whole movie in the tool itself and then the compressed version can be exactly one bit. :)

@UTFAPNRPT Naah, it can wait. Actually, it's a bit weird one. I know how to solve it, there's nothing unusual about the problem. The solution itself also has a manageable amount of moving parts, so to speak. But the overall domain is kinda nuts, I can't hold it in my head all at once. Akin to walking in a grim forest on a well-trodden path. You know how to walk, the path is perfectly fine, but you can't help but look around and think if there are any problems lurking behind the trees all around you.

This reminds me of sth -- ah, it was a promo for Remarkable tablets: writing by hand slows us down, letting is think differently. I just use a big legal pad and ink pen. A friend told me I was doing "free writing". Works great when "I can't hold it in my head all at once.". The handwriting causes me to deal with fewer bits, pun unintended, at once. Works great.

Yeah, I do that when, continuing the forest analogy, there's no path or when I'm limping. But with spooky trees, you can only march through and chant some mantra of choice. :)

This video and the corresponding paper might be of interest. https://pwlconf.org/2019/shriram-krishnamurthi/

This we call procrastination :rolling_on_the_floor_laughing:

On that topic though. Difficult, hard, those are all feelings. And while it's true we often will feel similar when put in similar situations as someone else, I've found in programming there's a matter of skill, knowledge, familiarity, and way of thinking. And that can dramatically influence if you'll find something hard or difficult to understand. This is very relevant in Clojure. You can write the simplest of functions, like a hello world, and already many will find it very hard. The parenthesis work differently, the name of things are different, the order of operations doesn't make sense, there's no separation between anything, they can't follow the indentation, etc. And similarly, is recursion hard ? I don't find it hard, but lots of people do. I used too as well. That means developing skills and acquiring knowledge can change things from hard to easy. Well, if that's the case, can we qualify the problem as hard? Is hard a measure of the amount of skills and knowledge you'll need to acquire? Or is it more the problem itself we can quantify? How many parts, how large is the solution, how much memory is required to fit it all in, how many layers, or special cases, etc.

Everything is easy when you already know how

Is it though? I'm asking honestly, I think it's a great question. You know how to jump, but if there's an arrangement of rocks over a creek you have to jump on to get to the other side. I can imagine different rock formations, heights, width, surface angles, sliperynes, the footwear you have, all can affect how hard it is to cross.

The better at jumping the easier you'll find it, true. But I believe what trail is hard for you to jump over, it will also be a harder one relative to others to a more adapt jumper. So like, it might be easier for someone more skilled. But the problem is still harder than other problems.

yeah, intrinsic hardness

I think this is what I'm getting at. You don't know how to swim, swimming is hard to you. But swimming in a heated luxury pool isn't hard. It's the easiest swimming problem ever. What's hard is you don't know how to swim lol. And that's not really hard, it just requires time investment to learn. It's not like you're going to learn an overly complicated swimming technique that makes learning to swim harder.

Factoring large primes doesn't get easier just cause you're a mathematician

I think it means you kind of have the difficulty of the problem itself. That can probably be objectively quantified, though it's harder for algorithm problems or computer problems I feel, because sometimes knowing the properties of a problem is itself a difficult task. Then you have the investment needed to learn the tools, techniques and knowledge to even solve the simplest of problems, and to begin to even have the capability to solve more complex ones. This in itself isn't hard, it's annoying, and requires time/effort. And finally you might have certain techniques, tools, or knowledge that are actually harder to learn or make the problem harder. If I teach you to swim going backwards for example. Ya, not only is that harder, it also won't be very effective and will make swimming in anything harder.

I find the question of how much energy it takes to "discover" something in computer science takes, and why, is interesting

I think it's fair to say there's some sort of objective "hardness" ordering for things. Like, by your jumping analogy, I'd be screwed quickly, but someone who practices parkour wouldn't be. But that doesn't make the parkour jump "easy" to the degree of jumping on the spot. My point was more about difficulty that arises from unknowns, or what people like to call "skill issues". There's a significant impact on the (subjective) difficulty scale from "nearness" or familiarity (as Rich mentioned in one of his talks) So, I guess to be less cheeky, what I mean is: when you know the "trick", the mountain often isn't unclimbable. But that doesn't mean it turns into an ant hill

Re: factoring primes. True, but it's conceptually easier if I'm a mathematician vs someone who's only just heard of prime numbers

Yeah that was just a hot take 😉

socratic devils advocate stuff

So the "incidental hardness" is a shortcoming of the language relative to the problem space, right?

So, what languages have less incidental hardness on average?

I like this topic, because I've often experienced other engineers I teach Clojure where they say Clojure is hard. Or even outside of Clojure, I've had scenarios where I'm using say Java streams, or I'm using recursion, or I'm using some other technique/pattern, and they will say it's hard. And then you have the people who'll say, that's why Go is awesome, or why Java 6 was perfect. Don't "overcomplicate". No need for generics, higher order functions, etc. If and a for-loop is all you need. And I've often felt like, it's not true lol. You find it hard, because you don't know it. But I'm using it, because it actually makes solving the problem easier. So really, it makes things easier. You having to learn the technique/tool/pattern is annoying and means you have to spend time to learn it. But in reality, it's easier, not harder.

yeah, incidental is going to be subjective to the problem, the language and the developer

Now, there's a place where like, what you already know might be sufficient already. Even if something else could make solving this a little bit easier once you know it just as well, it's not worth the ROI of learning it for a little improvement. So sure, stick to your thing. Or there might also be just what you end up being better at, for whatever reason, could be your brain is wired in a way that just has one style work better for it. That can play a role as well. But again, I guess in the objectiveness, it's not really harder. Except to your personally it might be.

Well, I can say for sure esoteric langs have more intrisic hardness, since they try to obfucate and make things harder haha.

For other languages, I think it depends. Some problems they might have less, some they might have more. An then it gets hard to reconcile that into like which language totals less/more of it. Take C, you can say it has a lot of hardness that is inherent to it, and not really tied to the problem. But when high performance is your goal, you could argue Python has a lot more intrinsic hardness than C.

But what attracts me to LISP-likes, such as Clojure, is their ability to offer you more tecniques/tools than most languages, because they can be user extended to higher degress with less effort.

I would also say interactive programming, live program introspection, and well-delimited code blocks mixed with structural edits/formatting tend to make most problems easier, because they allow you to iterate faster. Real-time type checking is another good one and IDE auto-completion also make most things easier. Clojure isn't as good on those ones. Java is great for them for example.

Immutability often makes things easier as well. But in some cases, not, like some leet-code problems are a lot harder to solve with immutability, especially if you want to achieve the same BigO

algol/in-fix notation solves two problems: 1. modeling the problem 2. modeling human language We think that modeling code as spoken language will make it easier for humans to model the problem domain. Instead, we waste our time dealing with problems incidental to spoken language system rather than to the problem domain. And we make some solutions simply impossible because we decided to model them in spoken language syntax. Maybe it's like binary vs decimal. Slowly, binary takes over more and more of our lives, replacing use-cases for decimal because, even though using decimal made sense when humans were the only computers, binary actually becomes easier in some situations because it makes less human assumptions.

There may even be some quantifiable extent to which a pattern of making code more like spoken language causes friction against that code's ability to model some domains

Lisp is to algo as binary is to decimal

"Yeah, base ten really got me into numbers... I was like, 'You like ten too?' hahah"

"But then I had to crank out widgets for acme number co and binary is just way easier for most things"

They say to us, "But it's so alien! All those ones and zeros!"

And we say, "Oh, but have you met our friend, Hex?"

I might be pushing this metaphor

Haha, I'm following. It's true though. Some cultures used to count in Roman numerals. Practicality meant, people realized base 10 Arabic numbers just worked better for actually counting, and math, and all that. And prefix notation, aka, Polish notation, predates computers. Mathematicians thought of it, because you don't even need parenthesis, or to learn precedence rules. We can get used to these. I'm sure base 10 felt alien to people used to Roman numerals. Similarly, in the US, people find metric system confusing. The metric system was a other one where people were like, ok, the way we measure scales is terrible for actual problem solving. So some people switched to metric, some adopted it fully. You can see the resistance to the familiar here a lot, especially in the US.

And we’ll finally reach enlightenment when we convert to dozenal.

I think a useful metric for "difficulty" of a language would be a metric (in the mathematical sense) measuring the distance between the syntax of correct code and the syntax of incorrect code. Easy-to-use languages should have the property that code is as obviously correct as possible. This is totally unrelated to aesthetics. However, readability is important. Not sure how to measure readability. For syntax I expect a simple edit distance gets you half of the way there, but it ignores readability of code. (e.g. APL assigns lots of unique characters to distinct operations, so d(x,y) is at a maximum whenever x and y use distinct operations, but this takes time to learn how to read compared to languages composing tokens with the alphabet)

To steal som terminology, I get the impression you're mapping simplicity (x axis) to ease (y axis).

Hm, perhaps.