Hello everyone, I would like to ask if there are any design errors in Crystal that have led to poor language consistency

Crystal Contrib
1

Hello everyone, I want to ask if there are any design errors in Crystal that have led to poor language consistency, I see a lot of inconsistencies in issues, and then what design in Crystal is counterintuitive? For example, what I have learned so far are … and … role in the range

2

Could you elaborate on “inconsistencies”? Crystal as a language is fairly consistent and the standard library doesn’t stray too far from consistency, although that is partially a biased viewpoint from someone that has used the language for a few years now.

If you’re referring to crystal-lang/crystal#13675 I wouldn’t call that an inconsistency, it’s more of a design preference.

4 Likes
3

Maybe this is a preference, but I think this preference will make the language unintuitive, using: < and: = You can see the meaning of the text.

Crystal has other syntax or APIs that are not intuitive enough, but can be designed more intuitively？

4

I don’t disagree with the change—I have also faced the issues z64 pointed out in the past—but I don’t see that as an inconsistency.

What syntax and APIs specifically? If we can get to the root causes then that will make resolving these “inconsistencies” much easier.

2 Likes
5

A difficulty with conversations like this is that the “intuitiveness” of programming syntax is heavily dependent on the background of an individual programmer. Many Crystalists come from a background that includes working with Ruby, which uses a..b for inclusive ranges and a...b for exclusive ranges. I do not have experience with Ruby, so I had to learn that syntax when I learned Crystal (along with implicit function returns, Ruby-style block syntax, and a number of other things). So a question when talking about intuitiveness of syntax (or function naming, or anything else along these lines) is “Who should this be intuitive for?”

Now, I think it’s much easier to back up the claim that Crystal’s range syntaxes (syntaces?) are difficult to distinguish visually. But that’s a claim about something along the lines of maintainability or safety or ease of debugging, not intuitiveness or consistency.

Finally, regarding consistency, I’m definitely interested to discuss the specific examples you have, but at the end of the day there will always be some inconsistency in the interest of making the language usable, because the inconsistency improves the usefulness of the language, the effort needed to make the language consistent is better spent on other language improvements, or making the language consistent would introduce unacceptable breaking changes.

8 Likes
6

Crystal stolen the most amazing part of Ruby(mostly), and discard a little, fix many wrong design come from Ruby too.

If you feel a little inconsistent or uncomfortable for Crystal, i guess the same goes for Ruby, perhaps, the first important things is, accept the beauty(difference) of Ruby at first.

In fact, i consider Ruby/Crystal is a quite consistent programming language.

3 Likes
7

Agreed.

As for the range syntax - I don’t get the problem. Two dots is clearly not three dots, and three is range exclusive. Instead of killing Crystal by a thousand cuts to resemble other languages, I personally would prefer things stick to Ruby’s syntax choices wherever possible. I don’t code in Crystal to be “consistent” with other languages.

3.2.2 :007 > (0..3).map {|i| p i.to_s} 
"0"
"1"
"2"
"3"
 => ["0", "1", "2", "3"] 
3.2.2 :008 > (0...3).map {|i| p i.to_s} 
"0"
"1"
"2"
 => ["0", "1", "2"]

and in crystal - the exact same code just works.

p "range inclusive: "
(0..3).map {|i| p i.to_s}

p "range exclusive: "
(0...3).map {|i| p i.to_s} 

yields-> 

"range inclusive: "
"0"
"1"
"2"
"3"
"range exclusive: "
"0"
"1"
"2"

There just isn’t a controversy here IMO.

2 Likes