Knowing a little about the history of imba, I know it is very heavily inspired by ruby.
However, I notice that the relationship between types and objects in imba is quite different than that of ruby. In ruby, everything is an object. This means that any data in ruby is going to share some common behavior, for example:
1.nil? "String".nil? nil.nil? Object.nil?
all return either true or false, we can send the
nil? message to anything without concern for what the thing is-- there is no concern of returning an error. In imba, if I want to gaurd against a null input I need to write:
return if subject == null
which is bulkier and less human-readable than
The example I provide is not fantastic, but there are many methods defined on the ruby
object that are amazingly useful and contribute significantly to the brevity/readability of ruby code and result in much more significant gains to the readability/brevity of the code (such as
Object.then). I’m wondering what the reasoning is for not replicating this pattern in imba. Possible reasoning’s I could come up with were:
- It was too much work for the payoff?
- It conflicts with the vision/philosophy of imba? (we don’t want this kind of syntax in imba even if it was just as easy to implement and as performant)
I am just trying to get a good understanding of what imba is trying to accomplish (beyond the goals stated on imba.io), what is motivating it’s design, so that I can manage my expectations for it!