Hacker News Reader

> The implicit return at the end of a statement for instance make it harder for me to visually parse what's being returned, since I really depend on that keyword.

Cutting my teeth on Schemes and MLs and now working in Python, I have the complete opposite experience. It's jarring to have to specify return. What else would I want to do at the end of an expression? It seems tautological. The real reason it's there in Python is early return, which is even more dangerous and jarring.

I know it's not very FP, but you might explicitly not want to return anything and just modify the data.

That's perfectly acceptable and expected. F# supports OOP and imperative just as much as it does functional programming. In the case of such functions and expressions, the value returned is of type `unit` with a single value of `()`. In F#, expressions that return `unit` have the value explicitly ignored if they are not the last expression in a code block. Other expressions returning non-`unit` values that aren't at the end of an expression will generate a warning. In such cases, for example where a function performs a required side effect and returns a value other than `()` but you don't need that value, you can use `|> ignore` to get rid of the warning since it says you are explicitly wanting to ignore the returned value.

Give it time. The syntax differences are real, but not insurmountable. I grew to prefer the location of the return type in function syntax despite having 15 years of C++ under my fingers.

I’m in the middle of working through The Rust Book, and I haven’t written any serious code with it yet, so interpret this through that lens.

When I looked at rust code before, it all seemed a bit weird. I couldn’t immediately understand it, but I’ve since come to realize this was because the dozen or so languages I can read well don’t really resemble rust, so my pattern matching was a bit off.

The more I learn about the syntax and core concepts, the more I’m learning that my brain absolutely loves it. Once I started to understand matches, lifetime syntax and the core borrowing mechanics, things clicked and I’m more excited about writing code than I’ve been since I taught myself GW-BASIC 25 years ago.

Just sharing this anecdote because I find it interesting how differently people experience languages. I also have an ongoing friendly debate with a friend who absolutely hates Python, while I rather enjoy it. I’ve tried to understand why he hates it, and he’s tried to understand why I like it. And it all seems to come down to hard-to-define things that just rub us in different ways.

I hope the benefits of rust find their way into more types of languages in the future.

Yeah, I think at some point we all have some internal wiring that is hard to change, while other parts are flexible.

For instance, I'm fine to write C++, Javascript or Python (with types at least). Ruby or Rust for some reason do rub me the wrong way, no matter how much I try to tough it out.

It's interesting that you mention Ruby, because Ruby is another language that just fits the shape of my brain for some reason.

I've always really struggled with the various Lisp variants.

> Code in general is hard for me to mentally read. I know it sounds nitpicky, but to me all keywords should be obviously pronounceable,

Have you tried Ada?

> so something like "func" instead of "fn" would be mandatory.

What about no keywords, like:

    x => ...func body

> Have you tried Ada?

I have tried Pascal in that sphere, which was on the too verbose side.

Arrow notations like in JS/Typescript are fine to parse for me. Some clear symbols are actually easier to read than an unpronounceable alphanumeric.

IMO the main thing that made Pascal verbose is begin...end for all compound statements. If you ditch that - as even Wirth himself did in the next iteration, Modula-2 - the rest is much more palatable. Consider:

   (* Pascal *)
   if a > b then
   begin
       blah;
       blah;
   end
   else
   begin
       blah;
       blah;
   end;

   -- Ada
   if a > b then
       blah;
       blah;
   else
       blah;
       blah;
   end if;

   // C
   if (a > b) {
       blah();
       blah();
   } else {
       blah(); 
       blah();
   }

Pascal is clearly very verbose here, but the other two are pretty similar.

That said I think that punctuation to delimit blocks makes more sense because it makes program structure clearly distinct. Although by the same token I think I'd prefer conditionals and loops to also be symbolic operators, so that there are no keywords inside executable code, only identifiers. Basically something like "?" instead of "if", "@" instead of "while" etc.

{} are isomorphic to 'begin' and 'end' in that snippet, though. Part of the reason why early programming languages were comparatively heavy on keywords is that the symbol set was not standardized across machines, so you couldn't count on some symbols being available. It's why C still supports <% %> as digraphs for curly braces, or <: :> for square brackets. Also why languages such as COBOL go as far as supporting syntax like DIVIDE X INTO Y, because the machine character set might not have a slash or divide sign.

They are, but it makes all the difference in practice. You can write "then begin" and "end else begin", but I haven't ever seen Pascal code written in that style, and I can understand why - it's just much less readable.

OCaml is nice in that "begin" and "end" are aliases for "(" and ")", so you can use whichever one makes the most sense for readability.

Anyway, the point is that the way to go is either 1) make structured programming constructs implicitly compound, so that you don't need braces for multi-statement bodies, or 2) make those braces as compact as possible so that being explicit is not so painful.

> all keywords should be obviously pronounceable

I hear you. Internally, I always pronounced "var" as rhymes with "care", but then a colleague pronounced it "var" as rhymes with "car". I think the same guy pronounced "char" like char-broiled, whereas I had thought of it like "care". And he would say "jay-SON" for json, which I pronounced like Jason.

How would you feel about a notation that is not meant to be pronounced at all?

+Employee {

}

where + indicates a class definition.

:Rename() where : indicates a class method.

~DoStuff() where ~ indicates a static function

Interesting, for all the examples you gave, I'd prefer to see a keyword, since you'd need to use a lot of symbols for a lot of different things in this way. I do find arrow notation or other symbol for lambdas fine, since it's a unique case and not a generic type of using symbols for keywords.

> I know it sounds nitpicky, but to me all keywords should be obviously pronounceable, so something like "func" instead of "fn" would be mandatory.

Keywords only? How about function names like strspn or sbrk? And how do you feel about assembly language, using mnemonics like fsqrt or pcmpeqd?

BTW, thinking about it, I notice, that I need all these lexemes to be pronounceable too, and I have my ways to pronounce sbrk or pcmpeqd. Probably if I do it aloud no one will understand me, but it doesn't matter because these pronunciations are for internal use only.

I'm not sure how many codebases started after 2010 I've seen that have "pcmpeqd" as a method name. This is something I think makes sense only in highly optimized code, but in business logic it's a pain to read.