Many developers nowadays use code auto-formatters and linters. Modern
languages like Rust even have these tools built in with their
environments (cargo fmt
, cargo clippy
).
You may write a piece of Python code like
if a:
something_long(that_should_be_split, to_several_lines, because_we_dont, like_horizontal_scrolling)else:
if b:
c()else:
d()
And then click a button to auto-format it to:
if a:
something_long(
that_should_be_split,
to_several_lines,
because_we_dont,
like_horizontal_scrolling,
)else:
if b:
c()else:
d()
Afterwards you may handle linter suggestions from a tool such as sourcery to turn it to:
if a:
something_long(
that_should_be_split,
to_several_lines,
because_we_dont,
like_horizontal_scrolling,
)elif b:
c()else:
d()
This is certainly an improvement over eras when those suggestions came from manual code reviewers work in pull requests.
But I can't help but notice how many steps are in the programming process:
Wouldn't it be awesome if this was a non-issue? I think it would, and that's how it works in Lamdu:
- Code layout is automatic as you edit. Formatting happens in real-time and doesn't require an extra step. It's even responsive and will break lines differently depending on the available width.
- Syntax sugars like
elif
apply automatically whenever the code matches the pattern, always. We still aim to get out of your way if you want to make changes that would not fit the sugar anymore, and it will automatically switch back to unsugared form.
For more info on Lamdu's approach see the demo in this video:
Notes
- The back-end deployment state-machine adds even more steps to the development process and Dark is taking steps to simplify this
- Header image: Scene of Hal fixing a light-bulb from Malcolm in the Middle