From: "rubyFeedback (robert heiler) via ruby-core" <ruby-core@...>
Date: 2023-02-23T19:53:36+00:00
Subject: [ruby-core:112556] [Ruby master Feature#17859] Start IRB when running just `ruby`

Issue #17859 has been updated by rubyFeedback (robert heiler).





I don't have a strong opinion on the topic. I am fine either way.



Both seem to have a valid point of view, e. g. the "it is convenient"

approach. This is kind of true. But, as said, I don't really have 

any particularly strong pro or con on it, be it a change, or no

change.



I wanted to comment on two other statements, though:



(1) The "it may be slow". Well, one could focus on a "bare irb" or

"base irb" behaviour, such as zverok showed (e. g. "python which

loads instantaneously, has no syntax highlight, and very

simplistic autocomplete"). People could modify the behaviour 

via irbrc and load add-ons. I once even loaded all my local

gems by also using Thread.new {} for loading them, since some

took some time, and I thought I could just "insta-start" irb,

and type commands, while background loading could proceed. It

did not seem to work quite in the way how I thought it would

be, so I switched to a "minimal IRB" again, where I really just

start the things I need on a daily basis, and load other things

only when I need it.



I don't know whether irb is slow or not compared to python startup,

but I feel that this question can be approached, even if it is just

a mini-irb with less functionality. The main question should be 

whether it is worth to change the default behaviour, e. g. if 

more newcomers would think this is better, than typing a separate

command (e. g. irb). That should be the primary question, the other

questions are secondary to that one, I would think.



(2) In regards to the "war", let's call it rather a "difference in approach"

(irb versus pry). The way how I see it irb adopted what seemed

useful from pry, even before the later rewrite that took place,

without necessarily going the full introspection route that pry 

adopted from the get go. So I see these two more as a separate projects

really, but irb learning from pry more than pry would learn from irb

(since it has a slightly different use case).



I don't think this is a bad thing. If anyone remembers, there was a

time we did not have BasicObject, and if memory serves me well 

_why was important in suggesting it, as he was testing an interactive

ruby on a website, and there having some "vanilla state" seemed

important (probably also with SAFETY or what old security checks

were still in place, to get it to work in a browser; of course since

then we can do so; I think there is a project on github that does

that, hsbt contributed to it if I remember correctly, but I forgot

the name of that project).



----------------------------------------

Feature #17859: Start IRB when running just `ruby`

https://bugs.ruby-lang.org/issues/17859#change-102006



* Author: deivid (David Rodr�guez)

* Status: Open

* Priority: Normal

----------------------------------------

Compare python:



```

$ python

Python 3.8.3 (default, Jul  8 2020, 16:49:12) 

[GCC 7.5.0] on linux

Type "help", "copyright", "credits" or "license" for more information.

>>> 

```



To ruby:



```

$ ruby

# just hangs

```



I think firing up a console it's a good default behaviour for beginners.







-- 

https://bugs.ruby-lang.org/

 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/