October 27

FWIW, from Stefik and Sibert, «An Empirical Investigation into Programming Language syntax», ACM Transactions on Computing Education, vol. 13, No. 2, 2013:

Both programmers and non-programmers had their preference for boolean and ordered as: x and y, x&y, x&&y. With a dip in interest for the && version. Which isn't surprising.

For boolean or there was more deviance. Non-programmers preferred: x or y, either x or y, x and y (!). Non-programmers seemed to have problem grasping the concept of logical or. Programmers preferred: x or y, either x or y, x||y.

For string concatenation programmers had a preference for: +, &, _ and a dislike for: -, ?, $

(The authors list many other constructs.)

October 27

On Wednesday, 27 October 2021 at 14:07:42 UTC, Ola Fosheim Grøstad wrote:

>

FWIW, from Stefik and Sibert, «An Empirical Investigation into Programming Language syntax», ACM Transactions on Computing Education, vol. 13, No. 2, 2013:

Another paper, Altadmri and Brown, «37 Million Compilations:
Investigating Novice Programming Mistakes in LargeScale Student Data», SIGCSE’15.

They point out that using "&" instead of "&&" is a mistake that it takes a long time to fix since it does not lead to a compilation error. It occured a bit more often than having a mismatch between a function return type and the type of the variable it assigns to.

October 27

On Wednesday, 27 October 2021 at 16:54:07 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 27 October 2021 at 14:07:42 UTC, Ola Fosheim Grøstad wrote:

>

FWIW, from Stefik and Sibert, «An Empirical Investigation into Programming Language syntax», ACM Transactions on Computing Education, vol. 13, No. 2, 2013:

Another paper, Altadmri and Brown, «37 Million Compilations:
Investigating Novice Programming Mistakes in LargeScale Student Data», SIGCSE’15.

They point out that using "&" instead of "&&" is a mistake that it takes a long time to fix since it does not lead to a compilation error. It occured a bit more often than having a mismatch between a function return type and the type of the variable it assigns to.

I'm a bit surprised by the results of these studies. I'd say that what people prefer actually does not matter because they dont necessarily have in mind the consistency criterion mentioned earlier. (side note: there's actually a proglang, Quorum, that has part of the design bassed on surveys !)

What's important is that the compiler should prevent reasoning errors, just like when AssignExp is rejected if used as condition.

October 27

On Wednesday, 27 October 2021 at 17:41:40 UTC, Basile B. wrote:

>

I'm a bit surprised by the results of these studies. I'd say that what people prefer actually does not matter because they dont necessarily have in mind the consistency criterion mentioned earlier.

My phrasing may have been a bit imprecise. The students were asked to rank the phrases as to how well they thought they matched up to the concept. So, basically, how intuitive they found them. They had C++ experience.

>

(side note: there's actually a proglang, Quorum, that has part of the design bassed on surveys !)

Yes, I found some papers on that one too! It appears to have been developed for blind programmers (?!), but has been adopted more widely in teaching.

I also found a paper that created and played melodies when debugging programs so that you could hear how the program executed. I assume this means that you could hear when a loop was exited, a branch was taken etc.

Surprising things to be found when looking around! Unfortunately there has been very few controlled usability studies of programming language designs... I found a presentation that claimed there has only been 22 studies (over 50 years?).

>

What's important is that the compiler should prevent reasoning errors, just like when AssignExp is rejected if used as condition.

I think there are many aspects to focus on. I'll keep it short here. Some dimensions I think are relevant:

  • learnability: how intuitive and natural is the syntax?

  • retention: how easy is it to remember what you have learned (consistency, mnemonics etc)?

  • skimmable: how good impression of what goes on do you get by skim-reading?

  • legibility: how quickly do you get a correct understanding of what goes on when reading?

  • error prevention: is the syntax resistant to typos that go undetected?

Clearly "and"/"or" is more resistant to typos than "&&"/"||", and also more skimmable with high learnability/retention (especially for "or").

But, if you don't allow implicit conversion to/from bool then the compilation stage should catch most such typos in the type system. So the impact of syntax also depends on language semantics.

October 27

On Wednesday, 27 October 2021 at 18:35:24 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 27 October 2021 at 17:41:40 UTC, Basile B. wrote:

>

I'm a bit surprised by the results of these studies. I'd say that what people prefer actually does not matter because they dont necessarily have in mind the consistency criterion mentioned earlier.

My phrasing may have been a bit imprecise. The students were asked to rank the phrases as to how well they thought they matched up to the concept. So, basically, how intuitive they found them. They had C++ experience.

May also add that the number of years they had used C++ did affect how well they thought the C++ phrases matched the concepts, as we might expect.

October 27

On Wednesday, 27 October 2021 at 01:05:22 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 26 October 2021 at 23:59:34 UTC, ClapTrap wrote:

>

On Tuesday, 26 October 2021 at 22:11:29 UTC, Ola Fosheim Grøstad wrote:

Is that why you bought it? So you can feel cool?

What do you mean? Stihl and Husqvarna are technically comparable, but I prefer Husqvarna, which is nordic and looks and feels better. Basically an identity issue.

Exactly!! If they are technically comparable then you would choose the one that looks more nordic. If this identity nonsense comes in it only does so after technical requirements are met.

And chainsaws are pretty simple machines, I mean in terms of design they are pretty much all at the same place. So you can probably find very similarly specced machines by all the big manufacturers.

Programming languages are not like that, they're not technically comparable, you pick any two languages you can find a shed load of technical reasons to chose one over the other.

> >

Fashion, or thinking how they tie into my ego, didn't factor into the decision to buy them.

Nobody thinks about identity issues, but they are there for sure. How can you know that one tool is better than any other tool, or what is good enough? You dont know until it breaks. So you navigate by some external source.

You read up on the web, or you ask someone you think will be able to help. But you don't go and ask them "I need a chainsaw, which is the most nordic?".

Or maybe you do? :)

> >

It's not hype plays into peoples ideas about themselves. It's not "Learn Java and be cool", its "Write once run anywhere".

I am fully aware that PhP is sufficient for webwork, but I don't feel empowered when using it. It does not feel like a professional tool, and that has a lot to do with syntax. From a rational point of view, you might argue that PhP is just as good as any other tool. But it does not fit with my identity.

Saying PhP is just as good as any other tool is not a rational point of view.

And if you use statements like that in your reasoning then you end up in stupid places where you cant dislike like something just because it's crap. It has to be because it doesn't fit your identity.

October 27

On Wednesday, 27 October 2021 at 21:31:05 UTC, ClapTrap wrote:

>

And chainsaws are pretty simple machines, I mean in terms of design they are pretty much all at the same place. So you can probably find very similarly specced machines by all the big manufacturers.

Hm, I don't think anyone are making high speed chainsaws anymore (I think they max out at 11000RPM now). Only matters slightly when delimbing really. RPM goes down real fast when you enter anything with thickness (it is a thinning saw, so not very powerful, but easy handling).

>

Programming languages are not like that, they're not technically comparable, you pick any two languages you can find a shed load of technical reasons to chose one over the other.

Most people tend to go with what-other-people-are-going-with. For instance, C++ is pretty much a lonely king-on-the-hill for graphics and audio. You go with the group that you identify with is using. Java for business applications. And so on.

I don't actually think average developers look for new opportunities when picking a language. When they pick a framework, they might. For language choice, I think average programmers go with something that makes them feel safe.

>

You read up on the web, or you ask someone you think will be able to help. But you don't go and ask them "I need a chainsaw, which is the most nordic?".

Or maybe you do? :)

Heh, when I was young I totally wanted the Jonsered 20xx TURBO. That "TURBO" made it seem totally awesome (but probably was no better, clever marketing ;^).

All the pro saws in stores were either Husqvarna or Jonsered back then (Swedish brands) IIRC. I doubt I would have considered any other brands, just assumed other brands were crap. And I still feel/assume that Husqvarna is better than Stihl in handling and build quality, and would not consider other brands than those two. Taking down windfalls can be dangerous, I don't want the saw to fail on me. As I said, you don't know if a tool is robust until it fails.

>

Saying PhP is just as good as any other tool is not a rational point of view.

The syntax isn't great, but the semantics in "modern" Php is good enough. I personally don't feel the package is up to a professional standard, although people obviously use it in a pro setting. So it is a feeling, more than a dissection. If I am going to spend a lot of time focusing on a language I want an aesthetics I like, so that I can write code I from time-to-time feel is beautiful. Can you be truly satisfied with a language if you don't like the looks of the code at the end of the day? I doubt it, but then we are in a very subjective landscape!

It is kinda like why I want the pro line Husqvarna, I want the top handle to be in metal. It gives me a better feeling and I can focus more on the work (and forget about the tool). It is kinda subjective though, whether one feels a metal handle is better than a plastic handle.

October 28

On Wednesday, 27 October 2021 at 14:07:42 UTC, Ola Fosheim Grøstad wrote:

>

FWIW, from Stefik and Sibert, «An Empirical Investigation into Programming Language syntax», ACM Transactions on Computing Education, vol. 13, No. 2, 2013:

Both programmers and non-programmers had their preference for boolean and ordered as: x and y, x&y, x&&y. With a dip in interest for the && version. Which isn't surprising.

For boolean or there was more deviance. Non-programmers preferred: x or y, either x or y, x and y (!). Non-programmers seemed to have problem grasping the concept of logical or. Programmers preferred: x or y, either x or y, x||y.

For string concatenation programmers had a preference for: +, &, _ and a dislike for: -, ?, $

As with all statistics the answers are heavily biased by the choices that were not asked for:
I would strongly prefer ∨ for or, ∧ for and (and ⊻ for exclusive or btw) and I think ~ for cat is a good choice (and far better than +), but I would prefer ∘.

October 28

On Thursday, 28 October 2021 at 07:05:47 UTC, Dom DiSc wrote:

>

I would strongly prefer ∨ for or, ∧ for and (and ⊻ for exclusive or btw) and I think ~ for cat is a good choice (and far better than +), but I would prefer ∘.

"v" was available, but I don't think they got unicode alternatives.

October 28

On Thursday, 28 October 2021 at 07:17:00 UTC, Ola Fosheim Grøstad wrote:

>

On Thursday, 28 October 2021 at 07:05:47 UTC, Dom DiSc wrote:

>

I would strongly prefer ∨ for or, ∧ for and (and ⊻ for exclusive or btw) and I think ~ for cat is a good choice (and far better than +), but I would prefer ∘.

"v" was available, but I don't think they got unicode alternatives.

https://tryapl.org/

uni: ∨∧
asc: v^

13 14 15 16 17 18 19 20 21 22 23 24 25