Show HN: Vy – a powerful but retro and minimalist IDE | Hacker News Reader

Show HN: Vy – a powerful but retro and minimalist IDE

github.com

143 pointsiogf45 comments

What I love about this project is that a lot of it is glue code.

It is an integrated development environment because it takes existing tools and integrates them, not rewrites.

I also like that you can develop plugins in the core language (like elisp + elisp, unlike C + vimscript), this removes some of the "impedance mismatch" between "native" and "scripted" parts.

You may be interested in the significance of the repo's "aggressive militarized snake smoking a pipe" avatar.

https://en.wikipedia.org/wiki/Brazilian_Expeditionary_Force#...

(Avatar here: https://github.com/vyapp)

Thanks!

I don't understand what could that mean in this context. How do you read it?

It's written in Python and the developer is Brazilian.

I don't think it has a link to the repo, I guess they just liked the cool picture with a snake, and a Python is a type of snake.

I just wanted to draw attention to the fact that an aggressive snake smoking a pipe has a particular symbolism.

So it's either "when pigs fly" or "shit is going to go down". In the context of the project I hope it's the latter :-)

One "truly retro" experience I had recently at the Computer History Museum was messing around with QBasic. The instant feedback of the documentation, in particular, was really powerful.

This looks interesting. On editors in general - if I'm working with an interpreted language, what I need from a code editor is:

- decent autocomplete and inline documentation

- good REPL which can send a block of code to the interpreter and preserve state so I can work interactively

- to have a variable inspector

- to work with plain text files

RStudio has been by far the best IDE ticking all the boxes for me. Still haven't found anything that comes close for Python - RStudio's support for Python simply isn't reliable, VSCode's Python extension has a bad REPL, Jupyter doesn't use plain text, Spyder's REPL isn't great either, PyCharm's scientific mode isn't free, I gave up on setting up Emacs several times because of how frustrating the whole process was. Any suggestions?

eclipse + pydev?

Emacs + company-mode + lsp-mode + pipenv-mode (for virtualenv packages) work great for me. What was your setup and what kind of issues did you have with it?

Similar workflow with Emacs and CIDER. CIDER automatic nREPL with TRAMP (edit files over SSH transparently, and run a remote REPL) is spectacular.

Thanks, I'll have a look at these.

What I tried last time is following this - https://realpython.com/emacs-the-best-python-editor/ and I ended up with a glitchy autocomplete which was filling a big part of the screen without showing any text.

I recommend using Emacs Prelude, which already auto-configures most of what I've described. You just need to enable a few modules for it and you're good to go.

I like the idea. The scrollbar jail bars are pretty jarring with regard to 'minimalist' sensibilities.

Engineers tend to misuse “minimalist” when they mean “brutalist” or “spartan”.

Minimalist in the code doesn’t reflect on minimalism on the interface, and when you apply an adjective to the description of your product you are characterizing the overall experience and visible surface (UI)… not the “backend” that makes it possible!

You can have very baroque UIs without writing that much code, and it would still be considered “minimal” on the code side.

I think in this context, minimalism doesn't mean "lacking important parts" like a keyboard or mouse produced by apple, but rather, something you can use without a graphical server, not gobbling up memory by embedding your program in a locally running browser.

I’m an emacs user, but barely know lisp, know python very well, and feel there are some limitations to emacs extensibility (namely wrapping external applications and debugging).

Convince me to switch

What? Why? It sounds like you convinced yourself to try it...

What features make it the editor or choice?

Why don't you just try it instead of asking someone to convince you that you should?

Do you have any more particular feelings about the limitations you mention? Wrapping external applications works (though I personally don't like doing it, as it makes porting configs between machines/OSes painful - I prefer to have everything done in Elisp), and there are debugging tools built into Emacs.

Learn elisp and continue using emacs. Problem solved.

Why would you call it Vy? Doesn’t that seem a little self defeating?

They're clearly vying for a place next to vi. Or maybe the v language, depending on how you pronounce it.

It's just a portmanteau of vim and py(thon). What's wrong with it?

Because `vi` pronounced as "vee eye" (/vi ai/) and I'm assuming `vy` pronounced as "vie" (/vai/) are extremely similar.

Funny, I’ve always pronounced “vi” like “vai”

Little known fact: "vi" is short for "visual". So, that's how I pronounce it.

Vy vouldn't they?

lost me at 'python'. if this is still fast in another year I will be amazed.

I wonder if you could add a `python --fast` mode that disables certain rarely or uncommonly used dynamic features that enabled the python runtime to JIT or do something clever.

Alternatively, doesn't disable, just does unwinding like speculative execution on processors.

Alternatively, is basically just adding PyPy to CPython.

I guess no new ideas here.

Or just ensure that Vy works on PyPy.

Yep, it was tried. See: Unladen Swallow - an experimental CPython fork trying to speed up execution by removing some of the least used dynamism. It started 10 years ago and was abandoned 8 years ago. Retrospective at http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect...

It's a long running process, so pypy should do well.

Seems the projects is nearly 5 years old and at it's third major-version. I doubt at this point much will change in a year.

This meme about Python being slow needs to end. While it's not as fast as some other interpreted languages it is not slow for any general use case unless you're doing number crunching (which is slow in any interpreted/bytecode language anyway).

Python is slow when you leave the comfort of the standard library and start doing a lot of the app logic in pure python. Often it is not a problem, but I can see how it could be a problem for a text editor where input latency might be a problem.

Vy will probably be just fine, but considering people think JS is slow, I doubt the idea that python is slow will die soon.

Projects like this can help though.

If your performance benchmark is, say, computational fluid dynamics, then then pure Python isn't going to fare well since languages with less overhead will be able to more efficiently leverage the available hardware.

However, a text editor / IDE has relatively fixed performance requirements based on users' perception, such that selective optimization is tractable. Once an application can satisfy human expectations without devouring system resources, additional gains are moot.

I have a very low tolerance for UI lags in my text editor. I'm a vim user, but can't use macvim, since it tends to be laggy, for instance. I find the jetbrains IDEs to be painful to use for the same reason.

python being slow is not a "meme," it's just reality. The performance issue for a text editor or other GUI is latency, which is a difficult problem even when you have more control from using a lower-level language. A dynamic scripting language with a garbage collector is just not going to cut it. not to mention python's demonstrated history of becoming unwieldy as project size increases.

pythonistas either say, "it's not slow!", or, "it doesn't matter if it's slow". In some cases, it truly doesn't matter that it is, in fact, slow as molasses. But a text editor is not one of those.

Python is probably faster than Elisp (or at least at the same order of performance), and Emacs is fine performance wise. And when Emacs is slow, generally the problem in those cases are architectural/algorithm decisions of Emacs, not because of Elisp itself. And like Elisp, if Python is really slow for some specific part of the code (for example, a function that is used everywhere in the code and it is expensive to run), you can write it in native code (i.e.: C) and call it from Python.

So I can totally see a text editor written in Python being fast enough, probably faster than an editor written in Electron since the runtime is much smaller (Node is faster than Python, however Electron runtime includes a whole browser with it).

python ... or electron. choices, choices!

Does the world really need another retro "IDE" (especially one written in Python).

Just use VIM, NeoVIM, or Emacs.

Can you please read the Show HN guidelines and follow them in Show HN threads?

https://news.ycombinator.com/showhn.html

Note this also from the site guidelines:

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

or use nvi (not nvim) or original vi

Reply on news.ycombinator.com