5 ms·

I went to a college that taught CS in ADA, and I never took CS because I tested out of 101, but I ended up fixing attempts at the problem sets for about half my

by jl2718 5y ago

I went to a college that taught CS in ADA, and I never took CS because I tested out of 101, but I ended up fixing attempts at the problem sets for about half my dorm section (this was okay as long as and they documented it). Well anyway, I found it to be very easy to pick up just by reading, hard to make semantic errors, and easy to modify without breaking things. The pace of learning for the entire cohort, mostly non-CS students, was, I think, much faster than e.g. C++ and possibly more complete than e.g. Python. It’s pedantic and exact, but it uses real english language keywords and modifiers. I went to a different school later where I did the same thing but it was taught in C++. It seemed like many students would get by purely by repeating patterns that they didn’t understand. And I started to catch myself in that trap as well, realizing that I had a lot to learn. But I wasn’t going to be a programmer; I was going to be a theoretical physicist cogitating on the deep mysteries of the universe. Fast forward…. D’ohhhh.

zozbot234 5y ago
Does "real english language keywords" actually make it easier to learn programming? AIUI, this was popular in the past simply because many computing systems used bespoke, pre-ASCII character sets, sometimes with few symbols available and no distinction between uppercase and lowercase (hence why Ada is case insensitive as well!). Typing stuff like DIVIDE A INTO X can come in handy when your machine literally doesn't have a / character.
- formerly_proven 5y ago
  Pretty sure it does. Line-noise languages (e.g. math, C++, Rust, Perl, K) optimize for expert use, the trade-off being that they're difficult to parse and understand for newcomers and infrequent users. There is of course also a huge difference between languages were the meaning of symbols/notation is largely context-independent (e.g. the three types of braces in C) and those were this is not the case (e.g. C++, math).
  - tialaramex 5y ago
    I agree C++ is worse about the context dependence than C but they're both pretty bad about this. Notice that C has two different operators named * and two named & for example.
    - mst 5y ago
      perl: there's more than one way to obfuscate it C: there's more than one way to segfault it
      - mst 5y ago
        looks at vote count I see I have enraged the C programmers. My apologies for being terrible at C memory management, though in my defense I am sufficiently self aware of this to realise that means it's safer for me to stick to perl as a weapon of choice.
- SkyMarshal 5y ago
  Ada intentionally prioritizes readability over write-ability, hence English-language keywords and the like. It’s designed for large, long-running systems that must be maintained over years or decades. The thinking is that over their lifetime, such systems will be read more than written, by rotating teams of programmers who need to get up to speed with a complex codebase, repeatedly. In maintenance mode, modifications will be less frequent than reads.
  - zozbot234 5y ago
    "Real English language keywords" for readability was probably the most sensible choice back in the early 1980s when Ada was first standardized. They're rather less popular today, of course. The interesting question is, does using, e.g. BEGIN and END instead of curly brackets really make it easier for novices who are learning to code today. It's an interesting topic and one that isn't often seen here.
    - foerbert 5y ago
      "begin" and "end" are probably the most arguable, but in the context of everything else being a real-word keyword I think they make sense. Ada was not my first language, and I was a little dubious about the keywords at first, but I quickly changed my mind. Now I wish every language did it (obviously, not literally every). It's really nice for a couple reasons. One is just googling. You pretty much have a built-in shared lexicon, so there's no trying to remember the right name for the problematic symbol, or figuring out the best way to describe it. There's also no trying to remember what symbol does the thing you want, which is really nice even when just coming back to a language feature you haven't used recently enough to be fresh on. I have no idea how much these things would matter in a more structured environment. I pick up words way faster than symbols and my memory isn't so great, so I think it would have helped me even there. But I don't know how universal that is. Though given the number of times I had to help the actual CS majors with basic syntax stuff, even after the 101 course... I can't help but suspect it would be useful.
- kqr 5y ago
  I think science is divided on this question. There's that one study showing that many languages with C-like syntax are as easy to learn to read as languages with tokens picked completely at random[1]. But that talks about learning the language. What about once you're proficient? I vaguely remember reading about a study that concluded more terse symbol-based syntax is better because the programmer can use visual organisation of the code to greater extent because the syntax occupies less of the screen. But I could also be making it up because I can't find it now. There's also the interesting (but slightly irrelevant) result that abbreviated identifier names may be just as effective as ones spelled out![2] [1]: https://dl.acm.org/doi/abs/10.1145/2534973 https://dl.acm.org/doi/abs/10.1145/2534973 [2]: https://link.springer.com/article/10.1007/s11334-007-0031-2 https://link.springer.com/article/10.1007/s11334-007-0031-2

by jl2718 5y ago

zozbot234 5y ago

Does "real english language keywords" actually make it easier to learn programming? AIUI, this was popular in the past simply because many computing systems used bespoke, pre-ASCII character sets, sometimes with few symbols available and no distinction between uppercase and lowercase (hence why Ada is case insensitive as well!). Typing stuff like DIVIDE A INTO X can come in handy when your machine literally doesn't have a / character.

formerly_proven 5y ago
Pretty sure it does. Line-noise languages (e.g. math, C++, Rust, Perl, K) optimize for expert use, the trade-off being that they're difficult to parse and understand for newcomers and infrequent users. There is of course also a huge difference between languages were the meaning of symbols/notation is largely context-independent (e.g. the three types of braces in C) and those were this is not the case (e.g. C++, math).
- tialaramex 5y ago
  I agree C++ is worse about the context dependence than C but they're both pretty bad about this. Notice that C has two different operators named * and two named & for example.
  - mst 5y ago
    perl: there's more than one way to obfuscate it C: there's more than one way to segfault it
    - mst 5y ago
      looks at vote count I see I have enraged the C programmers. My apologies for being terrible at C memory management, though in my defense I am sufficiently self aware of this to realise that means it's safer for me to stick to perl as a weapon of choice.
SkyMarshal 5y ago
Ada intentionally prioritizes readability over write-ability, hence English-language keywords and the like. It’s designed for large, long-running systems that must be maintained over years or decades. The thinking is that over their lifetime, such systems will be read more than written, by rotating teams of programmers who need to get up to speed with a complex codebase, repeatedly. In maintenance mode, modifications will be less frequent than reads.
- zozbot234 5y ago
  "Real English language keywords" for readability was probably the most sensible choice back in the early 1980s when Ada was first standardized. They're rather less popular today, of course. The interesting question is, does using, e.g. BEGIN and END instead of curly brackets really make it easier for novices who are learning to code today. It's an interesting topic and one that isn't often seen here.
  - foerbert 5y ago
    "begin" and "end" are probably the most arguable, but in the context of everything else being a real-word keyword I think they make sense. Ada was not my first language, and I was a little dubious about the keywords at first, but I quickly changed my mind. Now I wish every language did it (obviously, not literally every). It's really nice for a couple reasons. One is just googling. You pretty much have a built-in shared lexicon, so there's no trying to remember the right name for the problematic symbol, or figuring out the best way to describe it. There's also no trying to remember what symbol does the thing you want, which is really nice even when just coming back to a language feature you haven't used recently enough to be fresh on. I have no idea how much these things would matter in a more structured environment. I pick up words way faster than symbols and my memory isn't so great, so I think it would have helped me even there. But I don't know how universal that is. Though given the number of times I had to help the actual CS majors with basic syntax stuff, even after the 101 course... I can't help but suspect it would be useful.
kqr 5y ago
I think science is divided on this question. There's that one study showing that many languages with C-like syntax are as easy to learn to read as languages with tokens picked completely at random[1]. But that talks about learning the language. What about once you're proficient? I vaguely remember reading about a study that concluded more terse symbol-based syntax is better because the programmer can use visual organisation of the code to greater extent because the syntax occupies less of the screen. But I could also be making it up because I can't find it now. There's also the interesting (but slightly irrelevant) result that abbreviated identifier names may be just as effective as ones spelled out![2] [1]: https://dl.acm.org/doi/abs/10.1145/2534973 https://dl.acm.org/doi/abs/10.1145/2534973 [2]: https://link.springer.com/article/10.1007/s11334-007-0031-2 https://link.springer.com/article/10.1007/s11334-007-0031-2