5 ms·

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) Gura

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.

Aperocky 7y ago
c) Not much else, the ability to jump to code is the primary benefit.
- socialdemocrat 7y ago
  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 ;-)
  - Aperocky 7y ago
    More trouble than ctrl-B though
  - istjohn 7y ago
    Which terminal lets you do that?
  - alkonaut 7y ago
    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.
threatofrain 7y ago
e) Some kind of debugging or program introspection.
zozbot234 7y ago
> 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.
jrockway 7y ago
> 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.)
alkonaut 7y ago
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 7y ago
  > 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 7y ago
    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.
lgunsch 7y ago
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.

Aperocky 7y ago

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

socialdemocrat 7y ago
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 ;-)
- Aperocky 7y ago
  More trouble than ctrl-B though
- istjohn 7y ago
  Which terminal lets you do that?
- alkonaut 7y ago
  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.

threatofrain 7y ago

e) Some kind of debugging or program introspection.

zozbot234 7y ago

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

jrockway 7y ago

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

alkonaut 7y ago

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 7y ago
> 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 7y ago
  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.

lgunsch 7y ago

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.