Mojo REPL roadmap

Thanks! Just to document my usecase here, I find very convenient to write most of my tests on my struct/function doc-strings. Because it’s all in the same file, easy to track changes and keep tests updated, easy to refactor things, etc.

The REPL made that possible. Hope we can keep this feature.

2 Likes

Hello, everyone.

I trust all is well.

Regarding the repl, during my time using Python, I found using the repl to be very useful for prototyping.

The repl is (IMO) one of Python’s “killer features”:

  • It is great for debugging, because it allows the user to fully explore the state of a program.
  • It is great for teaching because it allows a new dev to explore the state of the program, with little consequence. The thing you wanted to figure out didn’t work? Just type something else in the repl and try again. Because of the easy of exploration, new users will also get a better mental model of the language, which would be great for adoption.

Having said the above, I agree that it is better to focus on a smaller set of problems, get those sorted in a correct and meaningful way, and then attend to these kinds of problems.

Lastly, I hope that Mojo will be able to retain the expressiveness of Python (although, I respect the fact that Mojo will be Python-like, as apposed to a full superset).
If Mojo could find a balance between Rust’s performance and Python’s expressiveness, Mojo would see immense general adoption.

  • The main issue with Rust is that it is difficult to prototype in.
  • The main issue with Python is that it is slow (fine when staring a project, but performance may be an issue as the project scales)

The repl, in my mind, represents the fast prototyping that Python offers. If this could be combined with the performance of a compiled language, Mojo would allow devs to “move fast” while still writing performant code in the long run.

Lastly, as a practical example of using a repl, I currently work in Ruby, with Rails, which I believe would be very unenjoyable without a repl.
I understand that most debuggers offer insight into the current state of a program, but being able to actively interact with the state of the program, is a game-changer.

Thank you,
Best regards.

3 Likes

Just throwing in my two cents here.

I’ve been coding professionally with Python for over 16 years now. I’m a physicist who’s only ever worked as a software engineer. My first programming experiences were with low-level languages used for astronomy instruments and electronics—things like assembly, C, and (back in school) Fortran (yeah, I’m that old). Not having a formal CS background has always been a challenge.

The reason I bring this up is because I never had a formal computer science education, and learning languages like C++, Java, Haskell, Rust, etc., has always been tough for me. Breaking out of old mental models was the hardest part. The one thing that helped me overcome the mental blocks—especially with C++—was literally the Python REPL.

When I first heard about Mojo, I was thrilled. The beauty I see in Python’s syntax was being taken to another level (yeah, not a fan of curly braces). The fact that Mojo is part of the Python family, and that new learners might get to experience some “real” language programming benefits in a more accessible way, really resonated with me.

I understand the reasoning behind postponing a REPL for later stages of Mojo’s development. But honestly, I think it’s worth having—even as a half-feature or technical debt. It’s something the community could iterate on until the core team is ready to focus on it.

These days, I rarely use the REPL—unless I need to do some heavy calculations (@owenhilyard, great minds think alike) or I’m mentoring and explaining a concept to a junior dev. But when I was starting out, I would write hundreds of lines in the REPL every day just to play and learn.

Of course, I’ll support whatever the team decides—Mojo is here for all of us, and I’m confident it’ll only get better with time.

Thanks!!! :raising_hands: