josevalim
In Elixir we are continuously trying to improve the experience for developers learning the language. However, there are still common road blocks users run into, despite of the tips and warnings put into the learning materials.
This proposal is about a hints mechanism for IEx that will allow us to print some information and guidance to users in common situations.
As an example, imagine the situation where IEx prints a list as a char list for the first time, a situation newcomers often find themselves in:
iex(1)> Enum.map([0, 1, 2], & &1 + 10)
‘\n\v\f’
In such cases, we could print hints, such as (don’t worry about the hint content for now):
Did you expect a different result than '\n\v\f'?
By default Elixir prints a list of ascii characters in single quotes.
Since [10, 11, 12] is a list of characters, you saw the '\n\v\f' result
above.
Whenever you are in IEx and you are not sure about what a data type means,
use the `i/1` helper to give you more information:
i('abc')
Each hint will be show only once. There will also be a function to disable all hints.
Before moving forward, the Elixir team has two questions:
-
Would such hints be generally helpful?
-
More importantly, which hints do you believe we could show on IEx? Hints should be valid language idioms that may be confusing when you first experience it. If an invalid construct is confusing, let’s say it has a poor error message, then we should improve the error message instead of adding a hint.
Please let us know when the hint should trigger and what we should suggest.
Thank you.
Note: This is an on-going discussion. Before joining the thread, please check the current discussion and see if your feedback and concerns haven’t already been brought up.
Where Next?
Trending in News
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
OvermindDL1
I’d personally think that would be greatly useful for new people yes.
dimitarvp
I’d like to see hints about the “no function matches…” once in a shell session. Having a better-communicated lack of matching function is IMO paramount in a language with pattern matching.
Imagine I have a function that accepts either map or list, and somebody tries to pass a tuple to it. The default message was confusing to me the first several times.
I realize we’re talking rookie mistakes, yes, but there’s nothing wrong to hold the hand of the people here and there. It’s also nothing major, but IMO worth a once-in-a-session hint.
jmitchell
Generally I like the idea a lot and think it would be valuable to have enabled by default. My only concern is it might get too noisy for those more familiar with Elixir.
Is this per IEx session, or will the history and the disable option be persisted between sessions? I’d very much like some form of persistence.
OvermindDL1
Maybe instead of ‘default’ persistence it defaults to per-session, but at the bottom of each it says to run ‘some’ command to disable globally, which would add some kind of flag or so into the
~/.iex.exsor whatever file that disables globally.I can very much see it being slightly irritating on new installs, but something like that would make it very easy to disable.
sotojuan
Yes but as mentioned have a way to turn it off via a config file
Otherwise it’s an awesome proposal and I’d love to contribute to it.
josevalim
As I have mentioned in the proposal, hints are not about error messages. If an error message is unclear, then we should improve the error message, there is no reason to keep such cases as hints.
To quote the proposal:
An issue has been opened to track function clause error improvements.
Hints will be shown only once per computer. Once a hint is shown or you disable them, you should never see them again.
michalmuskala
Something, that I often see people struggle with is the “no process” exit. With the things people are doing when starting out, it usually means some application is not started, or they forgot to add something to their supervision tree.
I’m not sure, though if this is a good candidate for that kind of additional messages, or maybe improved error.
josevalim
v1.4 already has an improved error for that, let’s see how it will go. If your hint is related to an error or an exit message, then it is not a hint. Instead open up a bug report to make the error message clearer.
Eiji
@josevalim: To answer your questions:
iexmostly to two things: try Elixir or library API (and in this case its a good idea) and for debugging code. I can’t imagine that I’m browsing bigger debugged (more than one) data and have mixed it with tips. We could have a case that tips could decrease readability of debugged data.For example:
What I suggest is to add one more
tips/tutorial(or similar name) executable for that or add this tips at start of iex. Maybe with prompt to optionally display next …or tutorials:
Where No (default) will clear console and display another tip and yes will open a docs in default browser, clear console and display next tip. To exit we could add info to press
Ctrl+C.Think how GUI apps work. They don’t display a tip when you click on specified button, but at start of app in separate window. I think that
iexcould have something similar (but of course in console).What do you think about it?
2. I suggest to add hints based on Elixir’s biggest gotchas? topic.
josevalim
The problem with anything opt-in, such as a different command line tool or a flag, is that newcomers won’t know/remember to do so, which pretty much defeats the purpose of having IEx hints.
This is also not meant to be a tutorial, we already have plenty of mechanisms for teaching Elixir, we are not planning to introduce another one. The goal is to have a simple and unobtrusive system for hints. We are not going to stop the user workflow and ask questions. Those would be too disruptive.
That’s why I am not worried about the debugging aspect because hints will be shown only once per computer and won’t interrupt the workflow. Hints are also based on iex’s input/output, so it wouldn’t interfere on the IO.inspect examples you mentioned above.
Those are very good concerns but I think we are safe for now.
Good call!