[samsquire]

What is it about an IDE that you need?

a) The ability to do an end-to-end build with one click (we've lost that with cloud being part of the equation)

b) Guranteed buildability

c) Intellisense/autocomplete

d) Widgets that can be moved into any which way.

I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click, there's some technology to be shared or extracted here from desktop IDEs.

[jrockway]

> I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click, there's some technology to be shared or extracted here from desktop IDEs.

I use "bazel test ..." to build stuff on the command line and my CI system runs "bazel test ..." to build stuff in CI. They can even share the same cache, and the cache actually works. (I admit for that 90% of go stuff I just use their build tool, though.)

I think IDE-integrated build systems are an artifact of times where people didn't write multi-language projects and there weren't good open source build systems. Things have changed a little, and now you can have your cake and eat it too.

(Autocompletion has also moved out of IDEs and into things maintained by languages themselves.)

[zozbot234]

> I feel that we're missing a trick with CI/CD if IDEs can do a end-to-end build with one click

Isn't that what "make" is for? A Makefile and an IDE project file are quite similar in structure.

[alkonaut]

An full build is always the easiest build.

Building as little as possible and having quick iteration is the hard bit when you have statically typed languages and large projects. If I edit a file and change the name of the function, the call sites should all light up with red squiggles. In a statically compiled language. Without requiring a recompile.

[jcelerier]

> If I edit a file and change the name of the function, the call sites should all light up with red squiggles. In a statically compiled language. Without requiring a recompile.

which is what all IDE support ? most even allow you to automatically fix it nowadays

[alkonaut]

Well it requires quite a bit from the compiler/language server infrastructure to not just behave like a batch compiler and give up after e.g. a failed parse. The ability to analyze incomplete or incorrectly parsing syntax is very tricky compared to doing it in sequence parse -> analyze etc.

Many IDE's manage this but far from all languages (compilers) do, simply because their compilers are simple batch compilers.

[threatofrain]

e) Some kind of debugging or program introspection.

[Aperocky]

c)

Not much else, the ability to jump to code is the primary benefit.

[socialdemocrat]

Pretty much every programmer editor lets you jump to code. I can even do that from my Terminal program. If I run a program and it produces and error my terminal interprets paths in the error message and let me click them to open my code editor at that file and line number. No IDE needed ;-)

[alkonaut]

That's presumably because the error had some format including rows columns and filenames.

Navigating from a symbol to another symbol (e.g. from a variable use to its declaration) requires more than simple pattern matching.

The editor needs to know (or be able to find out) the symbolic meaning of every word on the screen to do that. If syntax hihglighting isn't just basic regex matching, e.g. if you want different colors for mutable/immutable fields etc, then the editor needs to know the syntactic meaning of everything not just when navigating but when displaying.

[istjohn]

Which terminal lets you do that?

[Aperocky]

More trouble than ctrl-B though

[lgunsch]

The features that really set it apart are the sophisticated refactoring tools that are context and language aware. It goes so far beyond snippets and auto-complete.

Being able to dive into any source by clicking, and also full awareness of unused or incorrect code is very valuable.