111–120 of 191 posts
Earlier quoted context omitted.
Notation is a tool for thought. You want to optimize it for the problem you're solving. Not that PL notation is optimal, but being beginner-friendly is about the last thing one should care about.
The learning curve is definitely important when I decide what language to use.
The comments actually hit on the real solution to notation issues: it should be executable. It might require a library or file of accompanying "assumptions" that enables a concise "display" notation that appears in the text, but it would allow anyone to examine and understand what was being specified by having a common, concrete base of reference and the ability to query and examine it from whatever angle works for t…
I can take some pseudo-code and turn it into a working C (or python) implementation to poke at without too much trouble but papers with pure algorithmic notation usually get put in the "I'll look at that later" folder which I never get around to looking at.
Granted, I'm not the intended audience for most of the papers I read since I have no formal CS (or math) education -- though enough information is out on the interwebs depending on how motivated I am to try out whatever shiny-new I'm learning about.
Earlier quoted context omitted.
Everyone is a beginner before they become a practitioner. Look at Perl for an example of what happened to a language with syntax that appealed only to people who were already Perl-practitioners.
> Look at Perl for an example of what happened to a language with syntax that appealed only to people who were already Perl-practitioners It became for several years one of the most successful and widely used scripting languages on Unix?
Meh Notation in any field is a barrier to entry. See programmers takes on both math and music notation that are often posted here. The thing about notation that people sometimes don't think about is that it's used by many different types of people. Some things that would be convenient when notated implicitly make thinking about other things difficult.
The issue is that no one in CS seems to care that "Notation in any field is a barrier to entry". Almost all CS Ed research presently focuses on the problem-solving skill of CS rather than the technical literacy. There is almost no interest from educators to train this literacy despite work from myself [1] and others [2] saying that explicitly training these skills improves student performance. The issue, in my opinio…
Every field develops jargon and writing shorthand. It doesn’t have to be an artificial barrier to entry, and it’s a bit weird to me that this seems to be the case in programming.
Some time later I did learn Python and I really love it.
Earlier quoted context omitted.
Actually basic Haskell syntax is very simple, it's lot closer to basic math symbol and equation. What make it hard to understand is the use of abstractions like Monad, Transformers etc, and people use it a lot in Haskell. It's very hard in fact to make a useful Haskell program without a Monad. That said, I don't think another mainstream languages that use advanced abstraction like Haskell is gonna be easier to read e…
It's easy, it's just like higher order forms of math! Mathematic notation is horrible. We have to teach kids the forms for _years_ and most are still shaky at it once they're adults. You have to memorize everything because the syntax is basically shorthand, nothing is self explanatory. Then we wonder why kids struggle with math. If a programmer decided to replace his function names with single characters from a diffe…
To this day, when I'm reading computer science papers, I have to look really hard to make sense of the math gibbrish and get at the actual meaning, and often when I do I realize that it would have been much clearer in a few lines of JavaScript or Python or Go or Rust or just about anything else.
Well, perhaps anything except Haskell, OCaml, and similar. Even after learning the syntax, I still haven't internalized it as effortlessly as I did with other languages. Note that lisp is not very algol-like and I have a much easier time parsing it than I do Haskell despite relatively equal familiarity. I think Haskell has given us a lot of great ideas, and thankfully they've filtered down from the Ivory Tower of academic languages into pragmatic mainstream languages, such as Rust.
In this I agree with Paul Graham (and note I don't worship the guy). When talking about some lisps, he wrote [1]: > As names, car and cdr are great: short, and just the right visual distance apart. The only argument against them is that they're not mnemonic. But (a) more mnemonic names tend to be over-specific (not all cdrs are tails), and (b) after a week of using Lisp, car and cdr mean the two halves of a cons cell…
In this I agree with Paul Graham (and note I don't worship the guy). When talking about some lisps, he wrote [1]: > As names, car and cdr are great: short, and just the right visual distance apart. The only argument against them is that they're not mnemonic. But (a) more mnemonic names tend to be over-specific (not all cdrs are tails), and (b) after a week of using Lisp, car and cdr mean the two halves of a cons cell…
The community exhausted the entire design space (along with some full-blown prototypes). Eventually, the core Julia team chose to use more forgiving scoping in the REPL (virtually always the first point of contact for beginners), while actual projects enforced stricter scoping rules.
My key take-away is to consider how the language interacts with its ecosystem, not just how it should ideally operate in isolation. I have found the Julia team to be consistent in this pursuit. If the first point of contact is intractable for beginners, the project is dead on arrival. A technical tool should be tailored for experts, but you don't want to kill adoption along the way. Engineering is tradeoffs.
This article goes more in depth along the same lines: https://pchiusano.github.io/2016-02-25/tech-adoption.html
[1] https://discourse.julialang.org/t/another-possible-solution-...
Earlier quoted context omitted.
Everyone is a beginner before they become a practitioner. Look at Perl for an example of what happened to a language with syntax that appealed only to people who were already Perl-practitioners.
PG's point is that language syntax and notation should be aimed at practitioners. For beginners, almost anything will be a hurdle till the get the hang of it. Afterwards, they'll be practitioners. Being a beginner is a temporary situation; practitioners are forever.
Earlier quoted context omitted.
PG's point is that language syntax and notation should be aimed at practitioners. For beginners, almost anything will be a hurdle till the get the hang of it. Afterwards, they'll be practitioners. Being a beginner is a temporary situation; practitioners are forever.
I'm pretty sure I hated writing Perl before, during, and after I was any good at it. It's unnecessarily full of ultra dense symbols, many of which are made dense for no reason. ($| means "hot pipes" means you want to flush all characters always. Set it non-zero to make it do that. Want saner names? Why don't you `use English;`, you rube?) Sure, being a beginner is a temporary situation, but let's not excuse absurditi…
The argument actually says "don't optimize notation for beginners, optimize for practitioners". It doesn't imply making things difficult for beginners on purpose; just that they are not the priority.