4 ms·

Of course that's what we end up doing in practice, using external tools (CLI or IDE) to work around a limitation in expressiveness of the language. This advice

Of course that's what we end up doing in practice, using external tools (CLI or IDE) to work around a limitation in expressiveness of the language. This advice is a testimony that there's indeed a problem upfront :) And it comes short when searching from commonly used names...

nitrogen 5y ago
This advice is a testimony that there's indeed a problem upfront Indeed, and the problem is that IDEs have encouraged developers to write convoluted code and to forget how to navigate a filesystem. Reading code and commit history is a much faster path to understanding a system than an IDE's autocomplete. I learned this from Ruby, and it serves me well in C, Kotlin, Scala, PL/SQL, Typescript, etc.
- maccard 5y ago
  > IDEs have encouraged developers to write convoluted code and to forget how to navigate a filesystem. I would argue the exact opposite. Developers who force tools designed 30 years ago to dictate programming language best practices today are holding back the entire industry. There is no reason for my tooling to depend on my filesystem; imagine if my IDE integrated directly with vcs, and a language server provided both of those tools semantic information about my code, available on any device. Let's not kid ourselves either, utf-8 isn't human readable on disk, it's still a binary-like format.
  - rhizome31 5y ago
    You're right to remind that the filesystem is a metaphor, a model and not the reality of what's going on on the computer. The thing is it's still the common denominator between different IDEs and text editors. IDEs cannot be used in every situation so any professional developer who uses an IDE also knows his way around with a text editor. If we were to come up with a better abstraction than the file system, it would have to be shared between different IDEs for interoperability. My understanding is that Smalltalk was such an attempt but somehow that aspect of it didn't really spread. Are you aware of current progress being made in this area?

nitrogen 5y ago

This advice is a testimony that there's indeed a problem upfront Indeed, and the problem is that IDEs have encouraged developers to write convoluted code and to forget how to navigate a filesystem. Reading code and commit history is a much faster path to understanding a system than an IDE's autocomplete. I learned this from Ruby, and it serves me well in C, Kotlin, Scala, PL/SQL, Typescript, etc.

maccard 5y ago
> IDEs have encouraged developers to write convoluted code and to forget how to navigate a filesystem. I would argue the exact opposite. Developers who force tools designed 30 years ago to dictate programming language best practices today are holding back the entire industry. There is no reason for my tooling to depend on my filesystem; imagine if my IDE integrated directly with vcs, and a language server provided both of those tools semantic information about my code, available on any device. Let's not kid ourselves either, utf-8 isn't human readable on disk, it's still a binary-like format.
- rhizome31 5y ago
  You're right to remind that the filesystem is a metaphor, a model and not the reality of what's going on on the computer. The thing is it's still the common denominator between different IDEs and text editors. IDEs cannot be used in every situation so any professional developer who uses an IDE also knows his way around with a text editor. If we were to come up with a better abstraction than the file system, it would have to be shared between different IDEs for interoperability. My understanding is that Smalltalk was such an attempt but somehow that aspect of it didn't really spread. Are you aware of current progress being made in this area?