Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rubysyn: Clarifying Ruby's Syntax and Semantics

github.com

Post reply on HN
Print view View original

1–10 of 17 posts

Re: Rubysyn: Clarifying Ruby's Syntax and Semantics

#3

Post by SeriousM »

> This is an experiment in clarifying some aspects of Ruby syntax and semantics. For that we're going to introduce an alternative Lisp-based syntax for Ruby, preserving Ruby semantics.

Lisp? Then I would use Lisp...

> The goal is to define a comprehensive, trivially-parsable and sugar-free syntax.

Ruby has syntax sugar, no need to remove the funny parts.

Re: Rubysyn: Clarifying Ruby's Syntax and Semantics

#4

Post by pansa2 »

Smalltalker-80 wrote: post #2

I prefer the postcard ;-) https://richardeng.medium.com/syntax-on-a-post-card-cb6d85fa...

Yes, Smalltalk's syntax fits on a postcard - and it's possible to go even more minimal than that, e.g. Lisp or Forth.

OTOH Ruby doesn't need a postcard, it needs a full poster.

Re: Rubysyn: Clarifying Ruby's Syntax and Semantics

#5

Post by petalmind »

SeriousM wrote: post #3

> This is an experiment in clarifying some aspects of Ruby syntax and semantics. For that we're going to introduce an alternative Lisp-based syntax for Ruby, preserving Ruby semantics. Lisp? Then I would use Lisp... > The goal is to define a comprehensive, trivially-parsable and sugar-free syntax. Ruby has syntax sugar, no need to remove the funny parts.

> Lisp? Then I would use Lisp...

Lisp has completely different runtime semantics. Even the lexical scope in Ruby is extremely peculiar. One of the hard parts of writing this document was to remove the intuitive influence of Lisp because it just doesn't make sense for Ruby.

Re: Rubysyn: Clarifying Ruby's Syntax and Semantics

#6

Post by petalmind »

SeriousM wrote: post #3

> This is an experiment in clarifying some aspects of Ruby syntax and semantics. For that we're going to introduce an alternative Lisp-based syntax for Ruby, preserving Ruby semantics. Lisp? Then I would use Lisp... > The goal is to define a comprehensive, trivially-parsable and sugar-free syntax. Ruby has syntax sugar, no need to remove the funny parts.

> Ruby has syntax sugar, no need to remove the funny parts.

This is just an intermediate representation, it's not meant to be used directly (even though you can do that, of course).

Re: Rubysyn: Clarifying Ruby's Syntax and Semantics

#7

Post by amomchilov »

Smalltalker-80 wrote: post #2

I prefer the postcard ;-) https://richardeng.medium.com/syntax-on-a-post-card-cb6d85fa...

I never understood the appeal of this talking point. It’s just an accounting trick that moves the complexity to the standard library.

For example, SmallTalk is a class based OO system, yet this postcard doesn’t slow you how to create a class.

Re: Rubysyn: Clarifying Ruby's Syntax and Semantics

#8

Post by petalmind »

amomchilov wrote: post #7
Smalltalker-80 wrote: post #2

I prefer the postcard ;-) https://richardeng.medium.com/syntax-on-a-post-card-cb6d85fa...

I never understood the appeal of this talking point. It’s just an accounting trick that moves the complexity to the standard library. For example, SmallTalk is a class based OO system, yet this postcard doesn’t slow you how to create a class.

Yeah, I was also going to say that conflating trivial syntax and "supremely easy to learn" is a very weak flex.

The first Smalltalk-80 book you randomly find is 560 pages.

Also, there is a weird bargaining with "but not block temporaries" and "not an instance variable". Why not? Half of the postcard is basically empty. Also, "except primitives" — how many primitives are there?

Re: Rubysyn: Clarifying Ruby's Syntax and Semantics

#9

Post by amomchilov »

petalmind wrote: post #8
amomchilov wrote: post #7

Earlier quoted context omitted.

I never understood the appeal of this talking point. It’s just an accounting trick that moves the complexity to the standard library. For example, SmallTalk is a class based OO system, yet this postcard doesn’t slow you how to create a class.

Yeah, I was also going to say that conflating trivial syntax and "supremely easy to learn" is a very weak flex. The first Smalltalk-80 book you randomly find is 560 pages. Also, there is a weird bargaining with "but not block temporaries" and "not an instance variable". Why not? Half of the postcard is basically empty. Also, "except primitives" — how many primitives are there?

Next up: “all the characters you need fit on a single keyboard!”

Re: Rubysyn: Clarifying Ruby's Syntax and Semantics

#10

Post by Smalltalker-80 »

petalmind wrote: post #8
amomchilov wrote: post #7

Earlier quoted context omitted.

I never understood the appeal of this talking point. It’s just an accounting trick that moves the complexity to the standard library. For example, SmallTalk is a class based OO system, yet this postcard doesn’t slow you how to create a class.

Yeah, I was also going to say that conflating trivial syntax and "supremely easy to learn" is a very weak flex. The first Smalltalk-80 book you randomly find is 560 pages. Also, there is a weird bargaining with "but not block temporaries" and "not an instance variable". Why not? Half of the postcard is basically empty. Also, "except primitives" — how many primitives are there?

The appeal of having a very simple, base syntax and almost everything in the library / primitives, would be that code is always easy to read and write, also on the 'reflection' level, where most languages have specific keywords that cannot be used 'first class' with the rest of the language. E.g: Types next to class objects or operator overloading, look at Swift.. (Of course the complexity of a full working system (library) does not disappear in Smalltalk, it's just easier to read and modify. :)
Post reply on HN