Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking the IDE for the 2020s

movingfulcrum.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Rethinking the IDE for the 2020s

#31

Post by jupp0r »

I completely disagree with the article (but I realize that this is only my opinion and IDE choice is something that comes down to personal preference):

Here is what I think IDEs need to do different in the 2020s:

- configuration needs to be in human-readable configuration files, not obscure XML configs that can realistically only be edited through UIs.

- how to build the project needs to be completely decoupled from the IDE

- compilers and language services need to be separated from IDEs. LSP and automated refactoring tools using the same infrastructure as the code that's doing code completion makes sure that everything is consistent

- emphasis on input latency is needed for editors to feel snappy. Lots of full blown IDEs are not great for editing text.

edit: typo

Re: Rethinking the IDE for the 2020s

#32

Post by jhasse »

92g3r2ogr9asof wrote: post #23
The_rationalist wrote: post #14

Earlier quoted context omitted.

Have you considered buying a zen cpu? It's worth it

Should I have to upgrade my CPU to get acceptable performance out of a TEXT editor?

Yes. It's way cheaper. You can get a new CPU for $200, but you can't rewrite VSCode in the time that money would provide.

Re: Rethinking the IDE for the 2020s

#33

Post by akiselev »

I think long before IDEs implement any of these things - which represent a rather niche dev setup IMO - we need some way for libraries and applications to expose higher level metadata to language servers. Cross-repo search and replace is nice and all but it does't solve the problem currently filled by adhoc scripts and build steps that pull schema information from Swagger/Graphql/JSON schemas to generate types. Especially in the case of microservices where API boundaries are most often URLs or codegened RPC cliets, symbol renaming just isn't as useful outside of a single repo or workspace. Having, say, a protobuf or GRPC or OpenAPI language server feed information to the language server doing autocomplete and refactoring would be much more useful.

Re: Rethinking the IDE for the 2020s

#34

Post by TylerJewell »

A number of interesting points that are thought provoking, but also a bit of flame bait about cloud IDEs "dying off". As founder of Codenvy, happy to say that Eclipse Che is an active and growing open source community and after our happy acquisition by Red Hat they sell it as OpenShift CodeReady Workspaces.

Cloud IDEs provide value for specific portions of the market: 1. Training 2. Remote contractors in secure environments 3. Support 4. Classrooms 5. Vendors who want embedded dev envs in other products 6. Open source clones / snippet evaluations

Codenvy was strong in the embedded dev envs for other products. When you look at the various vendors that have emerged like Coder, Repl.IT, among others, they have a tendency to specialize in one of these areas.

That is quite different from the first generation cloud IDEs which tried to compete with classic desktop IDEs.

Re: Rethinking the IDE for the 2020s

#35

Post by thom »

paulryanrogers wrote: post #29
muglug wrote: post #4

Basic summary: "a modern IDE should be optimised for my particular use-case". The author then proceeds to describe a very atypical use-case. One example: "The IDE should ask for the Github org eg, github.com/astradot and it should create a single project that contains all the repo as modules. It should then manage lazy-loading/lazy-checkout or whatever is needed to give me a seamless experience browsing the code of m…

Is that a monorepo? Or just one organization with many repos?

I think they’re saying it’s both. They work on a single monorepo. Other repos exist in the org but they do not interact with them.

Re: Rethinking the IDE for the 2020s

#37

Post by pdeva1 »

reissbaker wrote: post #30

Context: I most recently worked at Facebook, which develops and maintains an in-house IDE, Nuclide, for working with its massive codebases; currently it uses VSCode as a base, although it previously used Atom. In a previous life I led the DevTools team at Airbnb (and before that did various other things at Airbnb). This article hits most of the nails exactly on the head, at least from the perspective of large corpora…

I do think Facebook has the correct direction on this.

Re: Rethinking the IDE for the 2020s

#38

Post by The_Colonel »

One big opportunity for IDEs to explore is the code visualization. Especially in languages like Java the abstraction, decomposition, delegation are heavily used for (sometimes) good reasons but at the cost of simplicity, and it's more difficult to see what's really going on (compared to simplified spaghetti).

There have been some weak attempts in IDEs (e.g. auto generated UML), but it's not really useable. Closest seems SourceTrail but that has many issues ...

Re: Rethinking the IDE for the 2020s

#40

Post by cain »

jhasse wrote: post #32
92g3r2ogr9asof wrote: post #23

Earlier quoted context omitted.

Should I have to upgrade my CPU to get acceptable performance out of a TEXT editor?

Yes. It's way cheaper. You can get a new CPU for $200, but you can't rewrite VSCode in the time that money would provide.

Why is the only other option to rewrite VSCode? How about another editor? Vim, emacs...?
Post reply on HN