[HN Gopher] Development Environments
___________________________________________________________________
Development Environments
Author : 8b16380d
Score : 98 points
Date : 2022-06-27 10:51 UTC (2 days ago)
(HTM) web link (phaazon.net)
(TXT) w3m dump (phaazon.net)
| sirsinsalot wrote:
| Many people seem to think using a commercial proprietary IDE
| means you somehow forget how to use the CLI or other editors to
| get the job done. Like they're junk food that makes you dumb.
|
| This is as ridiculous as saying an electrician will forget how to
| correctly wire because their wire cutters are too good.
|
| I used to be a build-my-own IDE person via VIM. After using
| PyCharm and realising an IDE is more than an editor, I realise
| the productivity gains every day.
|
| If I need VIM or something else, it's just another tool in the
| box and the partisan fist shaking has no place in a mature
| profession and trade.
| pessimizer wrote:
| > This is as ridiculous as saying an electrician will forget
| how to correctly wire because their wire cutters are too good.
|
| Or as ridiculous as people forgetting huge parts of their first
| language because they haven't spoken it in years. Which
| absolutely happens.
| anotherhue wrote:
| It's not that one has forgotten, it's that one never learned.
|
| I watch senior engineers struggle with basic CLI usage daily.
| In the modern sense of Senior of course.
| sirsinsalot wrote:
| Well the modern sense of senior leaves it likely that they
| have not yet learned to dress themselves either.
|
| That aside, what one doesn't learn doesn't mean the mistake
| is what one does. Just that they didn't.
| annowiki wrote:
| I consider myself quite adept at cli, I can sed, grep, find,
| vim, and git quite well.
|
| However, what I never found convenient in cli was debugging. I
| was a print debugger for years until my job convinced me to try
| PyCharm.
|
| I've always thought the reason I never found a suitable
| debugger in cli was just because I was either too dumb to
| figure out integrating something like vimspector, or too lazy
| to get used to gdb/pdb. Ctrl-f on this article has no mention
| of the word "debug." I think I'm not the only one that never
| used a debugger before I tried an IDE. I wonder how many people
| still feel superior in their CLI-Vim/Emacs-only workflow and
| are just print debugging.
| jrop wrote:
| I use NeoVim for everything except debugging. For that I
| (frequently) open up VSCode or Chrome to debug (NodeJS). I
| haven't figured out a good debug workflow for Rust, though,
| because I hate print debugging.
| yesbabyyes wrote:
| I'm similar to you (but with vim instead of neovim - I have
| to say VSCode with the vim extension is winning me over
| though).
|
| VSCode with rust-analyzer (edit: and CodeLLDB) provides a
| very nice environment for Rust development in my
| experience, including debugging.
| mcint wrote:
| The workflows enabled by Jupyter and iPython address some of your
| biggest concerns.
|
| You have references to previous outputs, don't recompute things,
| and in browser can have GUI interactive elements. You can likely
| find live streaming monitors too. Though that starts to break
| what the environment is best at: composing an edited, rational
| path through a process based on interactive exploration, trial
| and error.
|
| https://en.wikipedia.org/wiki/Project_Jupyter#Jupyter_Notebo...
| anothernewdude wrote:
| The problem with in browser anything is that editing text in
| the browser sucks. It steals a lot of key bindings you can
| never get back, it allows for selection of the wrong element.
|
| Also notebooks are a horrible way of working. They encourage
| code to get extremely unwieldy and make managing state harder
| than it needs to be.
| davidkunz wrote:
| "Modern" IDEs suck. They are not meant to be _fully_ controlled
| by the keyboard, have delays, cluttered UIs and interrupt your
| workflow with popups. That's why I prefer Neovim.
|
| https://youtu.be/9wsl6wvjdCg
| aaws11 wrote:
| site gives 404 error when I try reloading it. firefox on windows
| timberfox wrote:
| My experience is quite different: I feel extremely productive
| working in the terminal, and what is described in the article as
| "The frozen world" is for me a virtue of the UNIX philosophy: the
| structure is not embedded in the data, but the programs can
| project a structure on it. That allows programs to be filters,
| and text to be the only format for exchanging information. What
| the article describes as "The nightmare that is composition
| iteration" is for me a very pleasant experience: the terminal
| provides a very fast feedback loop where I can iteratively
| examine the output of a command and refine the filters I apply.
| As a result, I am able to prototype commands quickly and
| accurately.
| namaria wrote:
| I understand where the author is coming from and I myself
| sympathize with the idea of sticking to Unix philosophy of
| composing small focused tools instead of using complicated tools.
|
| That said, I have learned to stick to defaults and start from a
| clean slate every time. I often say that the main problem in
| software is containing complexity. When you need to deliver a
| product that works reliably, you want to remove all but essential
| concerns from your routine work. So I'd rather create a clean VM,
| install git CLI, VSCode, write a Dockerfile and get a nice clean
| package. If I learn how to use everyone of these tools out of the
| box with the default configuration, then I never have to think
| about dotfiles, plugins, set up etc.
|
| I think we need more software hygiene. Keep environments clean
| and ready to go.
| mid-kid wrote:
| While I agree that this sort of workflow keeps development
| environments reproducible, I disagree with freezing editing
| tools like this. Nothing about your project should require
| specific IDEs or similar software. Like you said, less
| complexity is easier to make more reliable, so stick to purely
| the tools necessary to build and run the software, rather than
| including the tools to edit it.
|
| If I need a VM for things, I typically start a small rsync or
| ftp server on the host so the VM only has to mirror the files,
| build and run.
| chriswarbo wrote:
| > write a Dockerfile
|
| I was sort-of agreeing with you until this point. In my
| experience "write a Dockerfile" usually means "run a bunch of
| fragile, non-deterministic nonsense, like `apt-get update &&
| apt-get -y install`, `yum install`, `pip install`, `npm
| install`, etc.; often all at the same time!"
|
| (AWS are a serial offender IMHO, e.g. their documentation
| recommends this sort of crap
| https://docs.aws.amazon.com/lambda/latest/dg/images-create.h...
| https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-dat...
| etc.)
| anothernewdude wrote:
| Default configurations change too often. I maintain two scripts
| on github that revert Ubuntu and MacOS to a stable setting
| where UI and UX things don't change.
| samsquire wrote:
| I completely agree. I find the idea of using someone else's Vim
| or Emacs config horrifying. They'll do everything differently
| and not necessarily better.
|
| I memorise how to configure vim how I like it and do it each
| time. Or how to change tmux bindings to use ctrl-a which I
| still need to memorise.
|
| Then I'm someone who remembers commands and switches and
| doesn't need to use recursive search to find commands I type
| in.
|
| Starting from fresh each time gives you a perspective of what
| is easier. Reader, can you write a Java application
| build.gradle, C makefile or Kubernetes YAML without copying and
| pasting from the web? Can you SSH jump from a bastion host from
| memory with -W? Can you create the directory structure of a
| Java project without copying from existing? Or do you write
| some terrible static configuration generator that doesn't get
| updates I've seen that so many times on projects. Saving time
| on the wrong thing rather than just learning the thing to begin
| with.
|
| I also prefer IntelliJ to Emacs and vim to Emacs. But I use
| Emacs keybindings in bash. Also I prefer bash to the other
| shells.
| invalidname wrote:
| I've been programming since well before we had IDEs... I love
| them. Proper modern IDEs provide a level of insight and tooling
| that the anti-IDE crowd just don't get.
|
| A couple of decades ago they were problematic. But today's
| unified toolchains and improvements made them far better. The one
| semi legitimate problem people have is performance. I run on an
| M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ
| (Ultimate). It flies. As professionals we need to spend on our
| tools and on our hardware to get the most out of both.
|
| The depth of insight that IntelliJ allows me at a glance when
| debugging, reviewing, refactoring, etc. is as a league that is so
| beyond what the CLI enables. I can't even begin to describe that.
|
| To be fair, this isn't universal. E.g. for kernel development,
| some embedded use cases, etc. the IDE might have less of a
| benefit. But for most day to day app development avoiding an IDE
| seems like a Luddite approach.
| anonymoushn wrote:
| It seems like Java is in a pretty unique place in terms of the
| quality of the tools and the frequent need to use complex tools
| to get even a vague idea what's going on.
| spullara wrote:
| The only reason Java can even have the most powerful tools is
| because it is easy to see what is going on. Also, JetBrains
| does really well with all languages, generally more than any
| other IDE.
| anonymoushn wrote:
| I haven't encountered features in other languages that are
| pervasively used and work by leaving meaningless markers in
| the code which some other (typically undocumented,
| typically in another repository) code will eventually use
| to do codegen, AST rewriting, and so on. But other than
| this feature that's like way more difficult than macros in
| Lisp or C, which makes up like 20% of non-whitespace lines
| in Java code I have encountered in the last few years, I
| agree.
| EdwardDiego wrote:
| Any large code base benefits from complex tools to get an
| idea of what's going on.
|
| Intellij / PyCharm does remarkably well with large Python
| code bases lacking type annotations, even if it has to take a
| guess here and there. But when you add type annotations, it's
| even better.
| invalidname wrote:
| True. But Idea Ultimate works surprisingly well with
| JavaScript and very well with Typescript including react
| code, etc.
|
| It's so much easier than going through NPM noise. Just auto
| fix and in 95% of the cases it's just what I need.
|
| The JetBrains IDEs for other platforms have almost the same
| level of capabilities. I also worked a lot with xcode, its
| not nearly as good as AppCode but it's still an improvement
| over trying to build iOS from the command line... I did that
| a lot and that isn't a pleasant experience in the least.
| [deleted]
| jillesvangurp wrote:
| I think a professional software engineer can be
| expected/required to use proper tools. That includes using
| decent hardware. Fast computers allow you to wait less and
| waste less time. If you are any good, the accumulated savings
| in time are worth more than the hardware in a matter of days or
| weeks. So, don't cheap out on hardware. It's unprofessional.
| Within reason, you can actually get away with some budget
| hardware these days. And you can also use remote tools to make
| your hardware matter even less. But whatever you do, minimize
| the waste of time. And if you use e.g. rust, kotlin, or js
| based development tools, you likely have some non trivial build
| times that can benefit greatly from good CPUs, fast SSDs and
| enough memory. Those build times add up quickly.
|
| I'm old and wise enough to not get between developers and their
| tool choices no matter how odd they are. So, I tend to give a
| lot of freedom to my people; and also take that freedom
| occasionally because I love trying out different things and
| optimizing my workflow. I love learning from others on how to
| improve my own workflow.
|
| I have a simple rule: your code must be properly formatted,
| refactored, and free of warnings when you create a pull
| request. Boy scout rule basically. Anything less than that is
| sloppy work and I'll call it out and will make you fix it.
| Always be refactoring and cleaning up code. I don't care how
| you do it and whether you do it the smart way (using proper
| tools) or the dumb way (manually using notepad and staring at
| compiler output) as long as you do it and know how to do it and
| when to do it.
|
| If it looks like you are being clumsy/sloppy/negligent with
| your tools, I'll have to have a word with you and tell you how
| to improve. That may include some not so subtle hints about
| your tool choices.
| analog31 wrote:
| What finally pushed me to use an IDE was the code inspection
| tools running in the background, and lighting up my likely bugs
| and style mistakes. So it's actually reacting to my code and
| _doing_ something, rather than just flooding me with
| information.
|
| For now, Spyder (for Python) is just right. VSCode is too much,
| and I haven't figured out how to turn off the features that I
| don't care about.
| dhzhzjsbevs wrote:
| Yea but you only need all that junk because you use Java.
|
| The rest of us just don't have that many files to refactor when
| we change things.
|
| I don't really hate ide's, I get the appeal, and sometimes it
| works out useful. It's just that most of the time it comes back
| to enterprisey software being the source of your problems, not
| the lack of features in your editor.
| EdwardDiego wrote:
| It doesn't matter how many files you have, it's how many
| functions or types or methods etc. ...and where they're used
| and how they're used.
| eklavya wrote:
| Calling IntelliJ and Java junk is probably an indication that
| you are inhibiting your professional growth.
| dhzhzjsbevs wrote:
| I was calling ide features in general junk but sure,
| project away.
| eklavya wrote:
| Apologies if I misunderstood. It seemed like the ide
| features and why they were required only for Java was
| pointing at something. Probably not.
| the_gipsy wrote:
| Ah yes Java and IntelliJ are clearly enterprise
| professional, the rest is amateur hippy toys.
| eklavya wrote:
| No, Java good doesn't mean everything else is bad. Why
| would I ever limit myself in such silly ways :)
| emsy wrote:
| Not everyone works on small codebases. Encouraging
| refactoring is a good thing.
| pjmlp wrote:
| Good IDEs precede Java, e.g. Borland products for Turbo
| Pascal and C++, Common Lisp and Smalltalk environments.
|
| The anti-IDE crowd seems to like to pick on Java.
| [deleted]
| invalidname wrote:
| I write most of my code in Java but I have a lot of C,
| Objective-C, JavaScript and many other languages. In fact I
| found IDE's to be even more useful for JS since it's such a
| mess. It's much easier to shoot yourself in the foot in other
| IDEs.
|
| I started with Java 27 years ago and back then text editors
| were the only option for years. So I can use them just fine
| for Java.
| ainiriand wrote:
| CLion for C++ is just brilliant.
| tpoacher wrote:
| I realise I'm probably alone in this, but this "depth of
| insight" is exactly one of the curses of IDEs for me.
|
| When you write on a terminal, you are encouraged to make good
| choices so that your code is clean, with a well-thought-out
| structure and conventions that allow it to be read and
| processed by a number of tools as painlessly as possible.
|
| When you're on the IDE, your code structure invariably reflects
| whatever workflow template has been defined for that particular
| IDE, and good conventions matter less because you can always
| use live links and stuff to inspect stuff via the IDE.
|
| Of course, you could argue that there's nothing stopping you
| from following those good practices on your IDE too, or making
| the extra effort to configure it with good structure and
| conventions. But in practice, it's a bit like making the extra
| mental effort to choose salad when there's steamy melty pizza
| right in front of you every single time. The temptation to take
| shortcuts and not think your code out properly and just rely on
| the IDE to dump its defaults is just too great. In the end,
| when you compare (professional) well-thought out code written
| in a terminal vs templated code written in an IDE, I feel that
| the difference in quality is often palpable.
|
| Also, I reject the idea that "tooling" is a concept unique to
| IDEs (or, in any case, that IDEs should necessarily imply
| superior "tooling"). Yes they offer the convenience of a
| suitethat is (hopefully) interoperable by design, but for me
| arguing that this makes them better tools is a bit like saying
| the Apple Store has better software than "the internet" and you
| should therefore only stick to Apple Store stuff.
| ASalazarMX wrote:
| > When you write on a terminal, you are encouraged to make
| good choices so that your code is clean, with a well-thought-
| out structure and conventions
|
| And then you realize you have to refactor 25% of it, or the
| requirements change, or a newly incorporated library suggests
| a naming convention change would be wise... IDEs not only
| show the code, you can pick a function argument, rename it,
| and get it renamed across all source files, comments
| included.
|
| If your terminal editor does that, then you've partially
| transformed it into an IDE.
| stonogo wrote:
| You don't even need a terminal editor to do that; sed will
| do it fine. If you want to be pedantic about the mechanism
| by which you achieve the result, you can just use ctags,
| which even plain vi and emacs support.
|
| What really set IDEs apart from text editors was integrated
| build tools and the ability to directly consume (and act
| on) build errors and the like. Search-and-replace long
| predates IDEs, as does 'code comprehension.'
| ASalazarMX wrote:
| I've coded in plain text editors all the way to full
| blown IDEs, and you're partially right, it's not the
| tooling that sets IDEs apart, but the seamless
| integration between several useful tools.
|
| I like small editors for small jobs, but I wouldn't dream
| of doing a new business application without an IDE these
| days. With sed a simple search and replace would need to
| be manually checked for unintended effects, but an IDE
| will do it without problems in seconds, unless you go out
| of your way to confuse it.
| invalidname wrote:
| I worked on the mess of make file and C dependencies created
| on Emacs in Sun Microsystems back in the day. You can make a
| mess with any tooling.
|
| It was impossible to navigate and I spent most of my time
| constructing complex regexes for grep just to follow the
| flow. In an IDE I can right click an element to find
| usages/dependencies, etc. Some of them are just highlighted.
| anonymoushn wrote:
| As a point in support of this comment, I recently perused
| the xxhash sources looking for the actual implementation of
| the hash functions, but it's difficult because there are
| like 20kloc of mostly preprocessor macros. This probably
| was not created using an IDE, and if it was, the IDE is not
| the cause of these issues...
| Narishma wrote:
| > I run on an M1 Max with 64gb of RAM and gave a lot of RAM to
| IntelliJ (Ultimate). It flies. As professionals we need to
| spend on our tools and on our hardware to get the most out of
| both.
|
| The problem with that is you'll more than likely create
| applications that work fine on your fancy high-end systems but
| end up unusably slow on normal people's hardware.
| a-dub wrote:
| the problem i have with ides is that you never know when some
| boss or it department will stand in the way of your favorite
| being available.
|
| from open source work at home to the most paranoid of high
| security environments, vim tends to be there pretty reliably.
| jacobyoder wrote:
| i got stuck with 'vi' at a place a few years back because
| "that's good enough - they're pretty much the same". I don't
| mean as main development tool, but on server builds, 'vi' was
| 'good enough' and also "it's smaller - we need to keep this
| small". So any time anyone had to do anything on those remote
| servers... years of muscle memory gone because... oh yeah,
| it's 'vi' not 'vim'. it was jarring to be reminded of how
| different they are.
| invalidname wrote:
| This is like saying the problem with using my hands is that I
| never know when my next job will be a football (soccer)
| player.
|
| I get that it's a muscle you need to practice. But limiting
| yourself to fit a potential restriction makes no sense.
| a-dub wrote:
| i've made use of various windows based microsoft ides,
| intellij, eclipse, wind river tornado, the qt creator,
| various activestate ides, various notebook ides and others
| i probably cannot even remember.
|
| i've encountered these ides in various corporate
| environments in varying degrees of broken where fixes are
| essentially impossible. (assuming they're available in the
| first place)
|
| i like vim, and other simple open source tools as they work
| reliably and are reliably available.
| bandrami wrote:
| There's something to that argument, though. You probably
| shouldn't use an IDE when you're learning a language. You
| should at least understand what it's doing behind the
| scenes and why.
| soggybutter wrote:
| 100% agree with this. I've seen plenty of devs who type a
| couple dozen characters in a session and spend the rest
| of their time clicking around on IDE prompts. This isn't
| necessarily a bad thing, but I've seen newer devs become
| completely crippled if their IDE misbehaves. And it's not
| uncommon for them to have very little understanding of
| the project structure because their IDE abstracts most of
| it away.
|
| It also promotes a pet peeve of mine, which is
| programmers that can barely type. I know plenty of people
| will yell at me saying that doesn't actually matter, but
| it's wild to me in a profession where typing is the
| primary way you interact with your work that so many
| folks can barely manage a typo-ridden 60wpm
| invalidname wrote:
| I think that when you're learning you should take the
| easy route and the IDE reduces some of the frustration we
| get when dealing with simple errors.
| jacobyoder wrote:
| Good IDE will usually highlight style and basic issues as
| you're typing them, and you can get a better idea of what
| 'canonical' foo-lang is. I'm not a ruby expert, but using
| RubyMine I'm reminded of some things while I'm coding,
| and (some) errors (or just style issues) are spotted
| before I run.
| tsujp wrote:
| What happens when you now want to work in say.. Crystal, or
| Shell, or Rust, or Zig, or any other language for which there
| is not an IDE (even those also by JetBrains) which is 1:1
| feature compatible to IntelliJ? Not all JetBrains IDEs have the
| same features. Rider (for .NET) only recently got remote
| editing support which IntelliJ already had for instance.
|
| Now you're only as good as your tool (IntelliJ) and you cannot
| work with any other language or tool which isn't 1:1 feature
| complete.
|
| If you had an extensible text editor beit vim, neovim, Sublime
| Text, emacs, VS Code or others then you could add extensions or
| features per language and keep using your single core tool
| (said text editor) with a configuration per-language.
| invalidname wrote:
| I can use text editors and other IDEs just fine. An IDE gives
| me more power and for 99% of my work I can live within it.
| I'm just slower.
|
| I used Visual Studio when working with C# which is fine. Not
| as great. Didn't get a chance to do either Zig or Rust in
| practice (both look great and I would want to go there).
|
| This argument is like arguing against shoes because of "what
| will you do when you're barefoot".
| the_gipsy wrote:
| That's the neat part, you don't.
| a_imho wrote:
| I have to admit I'm guilty of this, so much so that I'm
| tending towards discussing programming language features is
| moot without discussing the available tooling. In fact, I'm
| starting to think tooling is (slightly) more important.
| jacobyoder wrote:
| Tooling and an active ecosystem around a language are
| generally more important for most projects. Lang-feature-X,
| on its own, is almost never the reason a project succeeds
| or fails. An active community fostering discussion about
| the best ways to address particular problems, with an
| ecosystem of libraries and examples that show one or more
| ways to deal with those problems - that is useful. As the
| language develops, the ecosystem will incorporate those
| newer features to build on the previous approach.
| pjmlp wrote:
| Same here, heck even James Gosling, the author of XEmacs and
| many UNIX utilities, says he would rather use an IDE nowadays.
| lispm wrote:
| James Gosling is the author of XEmacs?
| pjmlp wrote:
| I got it wrong,
|
| https://en.wikipedia.org/wiki/Gosling_Emacs
|
| XEmacs is the Lucid one,
| https://www.emacswiki.org/emacs/LucidEmacs
| eikenberry wrote:
| Makes sense as XEmacs was an attempt to make Emacs more IDE
| like.
| eikenberry wrote:
| IMO this has 2 issues.
|
| #1 If you need an IDE to handle simple things like you list I
| think the language's development model is designed with IDEs in
| mind (eg. Java). Better language support and tooling makes all
| these things trivial without an IDE.
|
| #2 There are no good Free Software IDEs and I will not make
| ethical compromises with my maker tooling.
| pech0rin wrote:
| I dunno. I have used a lot of IDEs in my day but I always go
| back to emacs. I know its not for everyone but I can still have
| a running python, ruby, etc process and send bits of code to
| the process and interactively iterate on ideas smoothly. Also
| with the advent of language servers jump to definition, large
| refactoring of symbols, etc are pretty straightforward.
|
| The number 1 thing I hate about IDEs and will always hate about
| IDEs is that you open a "workspace" you cannot access all of
| your files at once. So often I am working with multiple git
| repos or various things scattered around my computer. In emacs
| I can simply open the file and have all the syntax
| highlighting, linting, etc just work. Instead of waiting for
| 10s for a whole new IDE workspace to open. And then not even
| have the ability to switch between them easily.
|
| Anyway, I don't think I am Luddite and I try to love modern
| IDEs and editors because everyone says how much more productive
| they are in them. I honestly have to think that editors are not
| whats holding back software development, and seems disingenuous
| to say shying away from them is somehow negative.
| zorr wrote:
| The way I get around that is by opening multiple workspaces
| so I can alt-backtick between them. At least on my setup the
| ideavim copy buffers are shared between workspaces so I can
| easily yank from one and paste in the other.
|
| It requires a bit of memory though as IJ just works better if
| you give it a lot of memory. Not really a problem for me as
| my dev machines have at least 32 or 64G and besides IJ,
| firefox and a terminal I don't have much open.
| bmj wrote:
| > The number 1 thing I hate about IDEs and will always hate
| about IDEs is that you open a "workspace" you cannot access
| all of your files at once. So often I am working with
| multiple git repos or various things scattered around my
| computer. In emacs I can simply open the file and have all
| the syntax highlighting, linting, etc just work. Instead of
| waiting for 10s for a whole new IDE workspace to open. And
| then not even have the ability to switch between them easily.
|
| This is a different workflow than the average use of an IDE,
| particularly for, say, Java or C# development. Personally, if
| I am working on a web app with a fairly large codebase, I use
| VS Code, but if I am editing a few scripts or other files, I
| absolutely use Neovim from the terminal.
| invalidname wrote:
| A lot of my friends used emacs back at Sun. Modern IDEs
| really improved since then and I haven't seen a feature that
| emacs can do that they can't.
|
| Yes a JetBrains IDEs will take longer to build the AST model
| in RAM but once you have it they do amazing things with it.
| E.g semantic search and replace, etc. The debugger
| capabilities are spectacular, they literally show the values
| of variables on the side of the line you stepped over.
| Another cool thing, inferred types just show next to the
| variable definition, parameter names appear in the method
| call, etc. These are small things that add up to a lot on the
| day to day.
|
| About projects. JetBrains do create project files but don't
| require a project structure in newer versions of their IDEs.
|
| The problem is that IDEs are very simple to pick up and
| people stop after that basic usage. They have depth that
| exceeds emacs in some respects.
| eadmund wrote:
| > Modern IDEs really improved since then and I haven't seen
| a feature that emacs can do that they can't.
|
| Easy extensibility. Read email. Run a calculator. Run Lisp
| ...
|
| Meanwhile, there is literally no feature any IDE has which
| Emacs cannot do. It's just a simple matter of programming.
| invalidname wrote:
| Everything is "just programming" but deep semantic
| heuristics from an IDE can't be done reasonably in Emacs.
| Most of the big features require keeping a full AST model
| of the project in RAM. That would make emacs/vi really
| slow.
|
| IDEs are 100% extensible via plugins. Wrote a few of
| those myself.
| eadmund wrote:
| > Most of the big features require keeping a full AST
| model of the project in RAM. That would make emacs/vi
| really slow.
|
| That's what LSP does, and emacs supports LSP. Heck, it
| even has _two_ packages implementing support for LSP.
|
| For that matter, I don't see any reason why Emacs would
| be any worse at keeping a full AST in RAM that is an IDE.
| Emacs Lisp is not the _most_ efficient runtime out there,
| but it 's acceptable.
|
| > IDEs are 100% extensible via plugins.
|
| Plugins are not 100% extensibility: they only enable one
| to extend the IDE in the ways the plugin system was
| designed to allow. Emacs, OTOH, enables one to extend or
| replace _all_ editor functionality implemented in Lisp. I
| am not aware of any other IDE which offers, for example,
| all of the following: multiple email clients, a net news
| client, an IRC client, a Slack client, multiple web
| browsers, a Git UI, a spreadsheet, a personal organiser,
| multiple calendaring systems, a computer algebra system,
| multiple file managers, multiple shells and terminal
| emulators, an RSS client, a music player and Tetris.
| invalidname wrote:
| I haven't written LSP so I'll reserve the opinion at
| that. What I understood about emacs is that it doesn't
| have a concept of a project so I don't see how it can
| form dependencies that are more sophisticated. But maybe
| I don't understand something about that.
|
| I can totally write these sort of plugins for any IDE I
| worked with. Notice that all of these capabilities are
| symbols of a bygone time where you stuck everything into
| an editor. There's no motivation for a plugin developer
| to do these sort of things. Instead we have plugins like
| Lightrun, TabNine/Copilot, etc. Stuff that's actually
| useful for development.
|
| JetBrains (and some other IDEs) have a builtin file
| manager, terminal, etc. These make some sense for
| development.
| funklute wrote:
| > What I understood about emacs is that it doesn't have a
| concept of a project
|
| Not built-in, but there are packages available for that.
| imaltont wrote:
| > Yes a JetBrains IDEs will take longer to build the AST
| model in RAM but once you have it they do amazing things
| with it. E.g semantic search and replace, etc. The debugger
| capabilities are spectacular, they literally show the
| values of variables on the side of the line you stepped
| over. Another cool thing, inferred types just show next to
| the variable definition, parameter names appear in the
| method call, etc. These are small things that add up to a
| lot on the day to day.
|
| Emacs has all of the things mentioned, either through
| plugins (LSP, Tree sitter, DAP) or built in (tags, GUD).
| Especially LSP-mode has over the last few years made sure
| you can integrate your favorite text editor into pretty
| much any language, for certain languages/technologies it
| still makes sense to pull up the specialized tools for e.g.
| debugging, deploying, building, publishing etc, but you can
| do a lot with the more general tools too.
| invalidname wrote:
| Curious, does it have some of the more advanced
| capabilities discussed here: https://www.youtube.com/play
| list?list=PLVuaPU1nEcV_bslGd23_4...
|
| Are things highlighted directly in the editor as you step
| over the lines.
| imaltont wrote:
| Things are highlighted as you go through, the buffers
| showing various values in scope is updated all the time,
| you can add certain variables/objects to be watched. GUD
| (built in) supports pretty much anything GDB can do (and
| also supports JDB afaik and a some others), check the
| manual for full feature set https://www.gnu.org/software/
| emacs/manual/html_node/emacs/De.... DAP
| (plugin/extension) is a bit more flashy and "modern", I
| haven't used it too much though, but it looks interesting
| https://emacs-lsp.github.io/dap-mode/page/features/. A
| nice video showcasing some of it can be seen here:
| https://www.youtube.com/watch?v=0bilcQVSlbM.
| aerique wrote:
| Emacs is an IDE in my opinion.
|
| Whenever there's some hot new IDE feature it'll end up in
| Emacs sooner or later. Sometimes better than the original
| implementation, sometimes not.
|
| What I like about Emacs is that it is timeless, works on a
| lot of platforms, supports a lot of programming languages
| (while a lot of modern IDEs are focused on a single
| language[1]) and also supports e-mail, Twitter, IRC, Matrix,
| etc. etc.
|
| [1] Which makes them very good for that specific language, I
| get that. But I prefer Emacs' "just good" support if that
| means I don't have to learn a new IDE again.
| Communitivity wrote:
| I've used Emacs for development before, and like it. I also
| like the more purposed IDEs. I consider Emacs a general
| purpose IDE because with all the packages I add it has IDE
| functionality (source jumping, refactoring, syntax
| highlighting, debugger interface, compiler interface, code
| completion, etc.). It takes a bit to get it set up just right
| for a given language though.
| pjmlp wrote:
| Meanwhile the author of XEmacs says he prefers modern IDEs.
| parentheses wrote:
| I've yet to give VSCode a fair shake. I used IntelliJ a lot
| back in the day.
|
| IntelliJ is special. Last I had seen they employ their own
| language tooling for almost everything. Nowadays the CLI (TUI)
| experience is capable of a LOT. CLI editors have fantastic
| integration with languages via LSP. You end up with similarly
| fat but more modular tooling. They offer a modularity and
| options that give you more choice in building the experience
| you want. (Not just color schemes and layouts)
|
| You have to do more work to configure and learn your tools but
| it makes so much more personalization of workflow possible.
|
| My personal CLI tooling for git is really nice and hacking on
| it keeps teaching me more about git creating a flywheel of
| optimization and joy from using things I made.
|
| There is a cost to changing your personal workflow. As nice as
| some new and shiny things appear I don't like flip flopping on
| my personal/professional setup. There comes a time when you
| start fresh. That will be when I try something different.
| soggybutter wrote:
| This has been my experience. I'm by no means an IDE power
| user, but the only things I really missed while using vim
| were finding references and going to definition. Nowadays I
| can do that in vim for every language I care about without
| much configuration or effort, and there's a bunch of
| additional features available I still leave on the table
| chriswarbo wrote:
| I agree that it would be nice to cache a command's output, so we
| can iterate processes on it. I'm a heavy user of Emacs, which is
| based around "buffers", so should naturally support such a
| workflow; yet in the decade I've been using it, such a workflow
| hasn't really occurred to me.
|
| Emacs makes it easy to run commands, e.g. with M-&; the output
| goes into a buffer called `Async Shell Command`. Unfortunately,
| that buffer gets _replaced_ each time we run a command. It 's
| common to override this behaviour (as I do), so a new buffer gets
| spawned each time, which gets a bit closer to that workflow.
| Still, I've never really used this to chain commands together;
| this post has inspired me to try that a bit more :)
| jrop wrote:
| This is how I use NeoVim's terminal: run a command, visually
| select the lines I want to operate on and yank them, then paste
| them in a new buffer. After that, it's a matter of transforming
| the text via whatever means one normally does (macros, text
| objects, search/replace, etc.)
| chriswarbo wrote:
| Manipulating text _within_ the editor is pretty common; e.g.
| I use shell-mode in Emacs, which is mostly just a normal text
| buffer (except Return acts differently when the cursor is
| over the commandline!); eshell is similar.
|
| What I was describing above is manipulating such buffers with
| _external_ commands (similar to Emacs `shell-command-on-
| region`)
| linguae wrote:
| One part of the article that resonates with me is the need for
| composable software that uses a more sophisticated mechanism than
| Unix pipes to connect components to provide an integrated
| experience. Over the past few years I've been interested in the
| idea of component-based software through IPC protocols and
| metaprogramming. This year I've been playing around with Plan 9,
| and I've found its ideas of component-based software through the
| 9p protocol interesting. I also got to spend some time using
| acme, which is one of the editors that comes with Plan 9. What
| makes acme interesting is that I can run external commands in the
| editor to perform various tasks, ranging from text manipulations
| to tasks such as compiling code. Each output shows up as its own
| window pane. One could create a sort of IDE using acme's ability
| to run external commands.
|
| While acme can seamlessly support external commands, a
| limitation, however, is there is no metaprogramming facility for
| changing the functionality of the editor itself. This makes acme
| less powerful than Emacs, which has the Emacs Lisp subsystem for
| extending and modifying the behavior of the editor. For example,
| suppose I wanted to add syntax highlighting to acme. Doing so
| requires modifying acme's source code. However, if acme provided
| some type of metaprogramming interface to the editor, then I
| could write code adding syntax highlighting. Ideally, this
| metaprogramming interface should be language-agnostic and take
| advantage of the 9p protocol. This would make acme just as
| powerful as Emacs, and in fact would give acme an advantage since
| extending acme won't require a specific language.
|
| Come to think of it, some of this metaprogramming capability may
| already be present in Plan 9 through the use of the /proc
| directory, thus obviating the need for application-specific
| metaprogramming mechanisms, though its offered at the binary
| level. I'll have to investigate this some more, though.
|
| My thought is that sophisticated IPC protocols and support for
| application-level metaprogramming can provide the rich
| interoperability that the writer of the article wants for
| creating composable development environments.
___________________________________________________________________
(page generated 2022-06-29 23:01 UTC)