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.
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?
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?
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.
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).
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.
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.
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...
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).
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).
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 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.
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.
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.