7 ms·

Analog – An analogous, indented syntax for the Rust programming language

58 points by asvln 5y ago

rappatic 5y ago
This is gross
- dang 5y ago
  "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
Zababa 5y ago
See? Rust's original syntax isn't that bad!
lpointal 5y ago
Readability note: 0
- dang 5y ago
  "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
xtagon 5y ago
The src directory is empty. Is there no implementation, this is just a specification?
- asvln 5y ago
  Correct. I'm not even sure if it is worth implementing, but the idea is there.
chrismorgan 5y ago
I’m curious: • Why? • You’ve made two mostly independent major changes in the syntax: to depend on significant indentation, and to switch from keywords to symbols. Why both, rather than just indentation while keeping it otherwise as familiar as possible? • Why change lifetimes from ' to `? (Nothing obviously collides with keeping it '.) • Why change closures from || to //? (You’ve then reused | for other things, but why not the other way round?) • What does the word “analogous” mean here? (I don’t believe it can be the normal English sense I’m used to because that requires something in the syntax to be compared to—I’m not sure what the proper grammatical term is on the adjective, but it’s like the distinction between intransitive and transitive verbs, with the sense I know being strictly transitive (by analogy) but you using it intransitively (as it were).) Finally, macros are a knell for alternative syntaxes like this: it’s not possible to make them work interoperably, because macros consume Rust token trees, but can interpret the body however they like, and you can’t reliably detect what they’re trying to do, so you can’t compensate. In your println! example, you are apparently saying it must translate the body from Analog to Rust, which would work in that instance because it’s largely consuming Rust language syntax (though named arguments add a little fun); but in your json! example, it needs to not perform any such translations, because json! doesn’t consume Rust syntax. (Perhaps in that specific instance the translation would be harmless, but it’s trivial to show macros where that’s not the case.) Attribute macros will be OK, and you might be able to get most structural macros working, but many structural macros (especially those that deal with token trees) and all non-attribute procedural macros are going to be a dead loss. I’m afraid I see only three solutions for macros in such an alternative syntaxes: (a) give up on interoperability, and maintain a completely distinct macro system; (b) have macro bodies always be in Rust syntax, which would break your very first example’s use of println!; or (c) on macros where there is any uncertainty, require what basically amounts to FFI bindings, which the language could provide for the standard library but it’d mean pain for calling macros from third-party crates, and could basically entail falling back to Rust syntax in complex cases. Hmm… that’s actually interesting to think about, as the uncertain nature of macros already causes some trouble for developer tooling. (rust-analyzer works well with structural macros, but can’t cope very well with most procedural macros, and something along these lines could actually be genuinely useful.)
- codesections 5y ago
tyfighter 5y ago
Dangling parens? This is terrible.
- SomeCallMeTim 5y ago
  The biggest downside to Python's popularity is the uber-fans' tendency to think it's a Good Idea to wreck other languages with significant whitespace. Like CoffeeScript. So far I believe every such attempt has ultimately failed. Like CoffeeScript. This seems to be a particularly execrable example of that phenomenon.
- avmich 5y ago
  You should try working with APL family of languages, dangling parens likely won't bother you after that.
- dang 5y ago
  "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
kator 5y ago
My first impression was "Oh, CoffeeScript for Rust". What is the goal of this specification? Maybe I missed it in the point. Also the name might be a bit challenging considering the overall footprint and overloaded nature already of the word `analog`.
- asvln 5y ago
  The goal is experimentation.
codesections 5y ago
This is great! Its amazing how much more readable programming languages get when they drop the visual noise created by unnecessary keywords – there's a reason math is so much easier to understand when it's expressed with symbols than with words, and it's very surprising how few programming languages recognize that. (I notice a few comments describing this syntax as less readable. My first thought was that these comments were sarcastic/trolling, but I've concluded that they're serious – but written by programmers who think very differently than I do!)
- kbenson 5y ago
  Math is easier to understand with symbols if you've been trained in what all the symbols and syntax means, and virtually impossible to understand if you haven't. This is easy to miss because for the most part we have one unified syntax taught in most the world. Words may not be the optimal format to express equations, but are the lowest denominator that would allow everyone to understand if they knew the concepts. That should illuminate why your opinion and other people's opinion of this differ. You likely each have different relative opinions and skills reading syntaxes like this.
  - avmich 5y ago
    I think you're too categorical. We don't only use words in written communication - there are pictures and symbols too, so restricting ourselves to spoken words in largely symbolic activity seems a disadvantage. For both math and programming it makes sense to invest into training of symbols and then get to the matter with expanded toolset, rather than keep using something more similar to COBOL. Tools are important for the progress. It's not a random event that digits - essentially symbols for numbers - were invented millennia ago.
    - kbenson 5y ago
      I wasn't making a case that words are better than symbols, only that there's always a trade off between representing something using existing known syntax and a somewhat less known but more concise and exact syntax, and that tradeoff is largely defined by how familiar your target audience is with that syntax. C-like syntaxes are more popular than lisp syntax(for example) not because it's inherently better but because most people have some exposure to it at this point through other languages they have been exposed to. Interestingly, that actually does make it inherently better in some aspects when choosing a syntax to adopt, such as learnability. For the person that only knows C and the person that only knows Lisp, which might have an easier time with the average rust program? What about someone that only knows Prolog? The issue is not about only using words, the issue is about using things your audience already knows. People use numbers in letters not just because words are less convenient, but because words are less convenient and they know the people on the other end know Arabic numerals so that's a valid medium to rely on. For programming languages it's less that words are better and more that there are either different or conflicting meanings for many symbols leading to confusion for those that deal with multiple languages or are new to the current language, so time needs to be taken to internalize what they mean in this new context. That doesn't make them bad or worse than words, but often they necessarily are less obvious in meaning to those new to the language to benefit those that are more familiar or experts.
potiuper 5y ago
Where is the source code or release?
junon 5y ago
For those reading, this appears to be vaporware. The idea is in the readme, but it's not been built yet. Also, OP, you cannot post your own stuff to HN without "Show HN:" at the beginning of your title.
- gpm 5y ago
  I don't believe this is correct > Off topic: blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out, so can't be Show HNs. Make a regular submission instead. https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html Judging by your first sentence it is correct for it to not be a show hn.
  - deleted 5y ago
    [deleted]
- pvg 5y ago
  Show HN has its own rules and you don't have to use it to show hn your own work. https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html
- deleted 5y ago
  [deleted]
nextaccountic 5y ago
What's sorely lacking is a comparison of identical Rust and Analog pieces of code, side by side
zengid 5y ago
This is a neat experiment, kind of making Rust look more like f# or haskel. I admit that Rust can get a little verbose, so I'm happy to see folks taking a fresh perspective towards it. While I like `^` for marking mutability, other things might not need to be so abstract (`=:` instead of `fn`) or re-purposed, like using `|i|` for loops instead of a Rust closure.
- zozbot234 5y ago
  Rust does get a little verbose, but this syntax proposal isn't doing much to simplify it either. It's mostly a lexical choice of symbols over reserved words, but the amount of separate symbols is IMHO a bit too high for comfort. (The choice of semantic indentation leads to additional drawbacks when copy/pasting code.) Reserved words may be inelegant in principle (since they intrude on the namespace for identifiers), but at least they're easier to type on most keyboards. And Rust seems to be going for a rather minimalistic syntax already. It's certainly not as verbose as languages in the BASIC, Pascal or Ada lineage, let alone Cobol.
- bscphil 5y ago
  > I admit that Rust can get a little verbose Heh. As a self-taught developer with a dumb ape brain, if anything I wish it was more consistently verbose. I've read through the Rust book and tutorials multiple times, and I've still not been able to wrap my brain around how lifetimes work. Personally I think the incomprehensible <a'> syntax has a lot to do with that. I'd love to see a kind of pseudocode that compiles to rust simply for the purpose of making it easier to learn the real language. Maybe you're thinking "wait, lifetimes are easy, you just..." but I think the reality is probably that most people who want to learn programming on their own, don't have a job in the field, and have never had a compsci class are going to have trouble wrapping their heads around the concepts. I can write good Python code. I can write safe C code (because it's easy to understand explicit allocation and freeing of memory), but I've never been able to make lifetimes work in my head. The complexity of rustc's error messages doesn't help much either, last time I tried it.
  - zozbot234 5y ago
lostdog 5y ago
I feel a sense of relief when working in a language where you can paste some code, hit autoformat, and not worry if any lines might have been accidentally added or removed from a for, if, or while block.
- andi999 5y ago
  Looking at python here...
ibraheemdev 5y ago
There was a pre-proccessor for Rust without curly brackets that I can't seem to find now... It actually looked very nice. The two biggest changes I would probably make are square brackets for generics, and in-band lifetimes everywhere.
- asvln 5y ago
  If you remember the name of this I would love to see it.
aappleby 5y ago
Code is read far more often than it is written. Optimize for readability.
nixpulvis 5y ago
Oh cool, let's make a (mostly) ergonomic language and throw it away for the sake of a few keystrokes. Scope is a lie anyway, right!? I'm glad to see they didn't start implementing anything.
- dang 5y ago
  "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." "Don't be snarky." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - deleted 5y ago
    [deleted]
  - nixpulvis 5y ago
    Honestly, where should I post this?
robocat 5y ago
It is so frustrating seeing someone work so cleverly to create a new syntax but restricting themselves to ASCII; I know the reasons why of course. The semantic meaning of the 32 ASCII non-whitespace punctuation characters are so tragically overloaded between languages (with subtle, major, or even contradicting meanings). The difference in meanings of ASCII characters usually varies within a language or requires “digraphs” like := or “trigraphs” like <=> and I laugh at our ancestors* using 6-bit* trigraphs (then I feel shamed that we have only progressed to 7 bit trigraphs). * poetic facts + punctuation. PPS: Any recommendations for a reliable swype keyboard for iPad that also accesses common Unicode characters such as dagger? I find Gboard on Android to be far superior to the Apple virtual keyboard.

58 points by asvln 5y ago

rappatic 5y ago

This is gross

dang 5y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

Zababa 5y ago

See? Rust's original syntax isn't that bad!

lpointal 5y ago

Readability note: 0

dang 5y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

xtagon 5y ago

The src directory is empty. Is there no implementation, this is just a specification?

asvln 5y ago
Correct. I'm not even sure if it is worth implementing, but the idea is there.

chrismorgan 5y ago

I’m curious: • Why? • You’ve made two mostly independent major changes in the syntax: to depend on significant indentation, and to switch from keywords to symbols. Why both, rather than just indentation while keeping it otherwise as familiar as possible? • Why change lifetimes from ' to `? (Nothing obviously collides with keeping it '.) • Why change closures from || to //? (You’ve then reused | for other things, but why not the other way round?) • What does the word “analogous” mean here? (I don’t believe it can be the normal English sense I’m used to because that requires something in the syntax to be compared to—I’m not sure what the proper grammatical term is on the adjective, but it’s like the distinction between intransitive and transitive verbs, with the sense I know being strictly transitive (by analogy) but you using it intransitively (as it were).) Finally, macros are a knell for alternative syntaxes like this: it’s not possible to make them work interoperably, because macros consume Rust token trees, but can interpret the body however they like, and you can’t reliably detect what they’re trying to do, so you can’t compensate. In your println! example, you are apparently saying it must translate the body from Analog to Rust, which would work in that instance because it’s largely consuming Rust language syntax (though named arguments add a little fun); but in your json! example, it needs to not perform any such translations, because json! doesn’t consume Rust syntax. (Perhaps in that specific instance the translation would be harmless, but it’s trivial to show macros where that’s not the case.) Attribute macros will be OK, and you might be able to get most structural macros working, but many structural macros (especially those that deal with token trees) and all non-attribute procedural macros are going to be a dead loss. I’m afraid I see only three solutions for macros in such an alternative syntaxes: (a) give up on interoperability, and maintain a completely distinct macro system; (b) have macro bodies always be in Rust syntax, which would break your very first example’s use of println!; or (c) on macros where there is any uncertainty, require what basically amounts to FFI bindings, which the language could provide for the standard library but it’d mean pain for calling macros from third-party crates, and could basically entail falling back to Rust syntax in complex cases. Hmm… that’s actually interesting to think about, as the uncertain nature of macros already causes some trouble for developer tooling. (rust-analyzer works well with structural macros, but can’t cope very well with most procedural macros, and something along these lines could actually be genuinely useful.)

codesections 5y ago

tyfighter 5y ago

Dangling parens? This is terrible.

SomeCallMeTim 5y ago
The biggest downside to Python's popularity is the uber-fans' tendency to think it's a Good Idea to wreck other languages with significant whitespace. Like CoffeeScript. So far I believe every such attempt has ultimately failed. Like CoffeeScript. This seems to be a particularly execrable example of that phenomenon.
avmich 5y ago
You should try working with APL family of languages, dangling parens likely won't bother you after that.
dang 5y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

kator 5y ago

My first impression was "Oh, CoffeeScript for Rust". What is the goal of this specification? Maybe I missed it in the point. Also the name might be a bit challenging considering the overall footprint and overloaded nature already of the word `analog`.

asvln 5y ago
The goal is experimentation.

codesections 5y ago

This is great! Its amazing how much more readable programming languages get when they drop the visual noise created by unnecessary keywords – there's a reason math is so much easier to understand when it's expressed with symbols than with words, and it's very surprising how few programming languages recognize that. (I notice a few comments describing this syntax as less readable. My first thought was that these comments were sarcastic/trolling, but I've concluded that they're serious – but written by programmers who think very differently than I do!)

kbenson 5y ago
Math is easier to understand with symbols if you've been trained in what all the symbols and syntax means, and virtually impossible to understand if you haven't. This is easy to miss because for the most part we have one unified syntax taught in most the world. Words may not be the optimal format to express equations, but are the lowest denominator that would allow everyone to understand if they knew the concepts. That should illuminate why your opinion and other people's opinion of this differ. You likely each have different relative opinions and skills reading syntaxes like this.
- avmich 5y ago
  I think you're too categorical. We don't only use words in written communication - there are pictures and symbols too, so restricting ourselves to spoken words in largely symbolic activity seems a disadvantage. For both math and programming it makes sense to invest into training of symbols and then get to the matter with expanded toolset, rather than keep using something more similar to COBOL. Tools are important for the progress. It's not a random event that digits - essentially symbols for numbers - were invented millennia ago.
  - kbenson 5y ago
    I wasn't making a case that words are better than symbols, only that there's always a trade off between representing something using existing known syntax and a somewhat less known but more concise and exact syntax, and that tradeoff is largely defined by how familiar your target audience is with that syntax. C-like syntaxes are more popular than lisp syntax(for example) not because it's inherently better but because most people have some exposure to it at this point through other languages they have been exposed to. Interestingly, that actually does make it inherently better in some aspects when choosing a syntax to adopt, such as learnability. For the person that only knows C and the person that only knows Lisp, which might have an easier time with the average rust program? What about someone that only knows Prolog? The issue is not about only using words, the issue is about using things your audience already knows. People use numbers in letters not just because words are less convenient, but because words are less convenient and they know the people on the other end know Arabic numerals so that's a valid medium to rely on. For programming languages it's less that words are better and more that there are either different or conflicting meanings for many symbols leading to confusion for those that deal with multiple languages or are new to the current language, so time needs to be taken to internalize what they mean in this new context. That doesn't make them bad or worse than words, but often they necessarily are less obvious in meaning to those new to the language to benefit those that are more familiar or experts.

potiuper 5y ago

Where is the source code or release?

junon 5y ago

For those reading, this appears to be vaporware. The idea is in the readme, but it's not been built yet. Also, OP, you cannot post your own stuff to HN without "Show HN:" at the beginning of your title.

gpm 5y ago
I don't believe this is correct > Off topic: blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out, so can't be Show HNs. Make a regular submission instead. https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html Judging by your first sentence it is correct for it to not be a show hn.
- deleted 5y ago
  [deleted]
pvg 5y ago
Show HN has its own rules and you don't have to use it to show hn your own work. https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html
deleted 5y ago
[deleted]

nextaccountic 5y ago

What's sorely lacking is a comparison of identical Rust and Analog pieces of code, side by side

zengid 5y ago

This is a neat experiment, kind of making Rust look more like f# or haskel. I admit that Rust can get a little verbose, so I'm happy to see folks taking a fresh perspective towards it. While I like `^` for marking mutability, other things might not need to be so abstract (`=:` instead of `fn`) or re-purposed, like using `|i|` for loops instead of a Rust closure.

zozbot234 5y ago
Rust does get a little verbose, but this syntax proposal isn't doing much to simplify it either. It's mostly a lexical choice of symbols over reserved words, but the amount of separate symbols is IMHO a bit too high for comfort. (The choice of semantic indentation leads to additional drawbacks when copy/pasting code.) Reserved words may be inelegant in principle (since they intrude on the namespace for identifiers), but at least they're easier to type on most keyboards. And Rust seems to be going for a rather minimalistic syntax already. It's certainly not as verbose as languages in the BASIC, Pascal or Ada lineage, let alone Cobol.
bscphil 5y ago
> I admit that Rust can get a little verbose Heh. As a self-taught developer with a dumb ape brain, if anything I wish it was more consistently verbose. I've read through the Rust book and tutorials multiple times, and I've still not been able to wrap my brain around how lifetimes work. Personally I think the incomprehensible <a'> syntax has a lot to do with that. I'd love to see a kind of pseudocode that compiles to rust simply for the purpose of making it easier to learn the real language. Maybe you're thinking "wait, lifetimes are easy, you just..." but I think the reality is probably that most people who want to learn programming on their own, don't have a job in the field, and have never had a compsci class are going to have trouble wrapping their heads around the concepts. I can write good Python code. I can write safe C code (because it's easy to understand explicit allocation and freeing of memory), but I've never been able to make lifetimes work in my head. The complexity of rustc's error messages doesn't help much either, last time I tried it.
- zozbot234 5y ago

lostdog 5y ago

I feel a sense of relief when working in a language where you can paste some code, hit autoformat, and not worry if any lines might have been accidentally added or removed from a for, if, or while block.

andi999 5y ago
Looking at python here...

ibraheemdev 5y ago

There was a pre-proccessor for Rust without curly brackets that I can't seem to find now... It actually looked very nice. The two biggest changes I would probably make are square brackets for generics, and in-band lifetimes everywhere.

asvln 5y ago
If you remember the name of this I would love to see it.

aappleby 5y ago

Code is read far more often than it is written. Optimize for readability.

nixpulvis 5y ago

Oh cool, let's make a (mostly) ergonomic language and throw it away for the sake of a few keystrokes. Scope is a lie anyway, right!? I'm glad to see they didn't start implementing anything.

dang 5y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." "Don't be snarky." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- deleted 5y ago
  [deleted]
- nixpulvis 5y ago
  Honestly, where should I post this?

robocat 5y ago

It is so frustrating seeing someone work so cleverly to create a new syntax but restricting themselves to ASCII; I know the reasons why of course. The semantic meaning of the 32 ASCII non-whitespace punctuation characters are so tragically overloaded between languages (with subtle, major, or even contradicting meanings). The difference in meanings of ASCII characters usually varies within a language or requires “digraphs” like := or “trigraphs” like <=> and I laugh at our ancestors* using 6-bit* trigraphs (then I feel shamed that we have only progressed to 7 bit trigraphs). * poetic facts + punctuation. PPS: Any recommendations for a reliable swype keyboard for iPad that also accesses common Unicode characters such as dagger? I find Gboard on Android to be far superior to the Apple virtual keyboard.