This is precisely why I avoid using IDEs whenever possible. When manipulating text files, there is absolutely no good reason for any part of the user interface to be slower than my brain.
Even a lot of straightforward text editors can’t figure this out. I tried to use Atom for a while, but the multiple-second delay for launching Atom and opening new windows was just too frustrating. Although I prefer Atom in most respects, this forced me back to Sublime text, which is sufficiently fast (probably <50ms) both on launch and for any other UI action.
I think this actually forces me to write better code. When I can’t use the IDE as a crutch to help me remember the name of a function, or which module something comes from, or what the type of a function is, it forces me to organize everything in a way that helps me keep everything in my head. This usually boils down to more genericism, more considered names, and better module layout.
They mentioned boilerplate. Boilerplate code should be viewed as a design failure of the tools and framework you’re using. At some point, you’re going to need some, simply because on some level, we actually do need redundancy in language, but it should be minimal. Code generators, especially code generators that automate boilerplate, are a special evil. They demonstrate either that your language lacks expressiveness or your approach to the problem is a poor fit for the language in question.
They mentioned boilerplate. Boilerplate code should be viewed as a design failure of the tools and framework you’re using.
Yes, but it is only one of the many ways that your tools and framework can fail.
Some other notable ways they can fail:
Behaving unpredictably when changed (eg dropping an optimization that makes your code too slow on prod-sized datasets)
Not having dependency management solved well
Not having correct, performant, robust implementations for common protocols/algorithms
Not having good tooling for automatic refactoring
I could go on for at least 2-3 more before I get into the esoteric stuff.
Demanding ‘no boilerplate’ means you lose access to the (many!) tools that solve those other problems well (typically because they deliberately chose boilerplate to support those features).
This is precisely why I avoid using IDEs whenever possible. When manipulating text files, there is absolutely no good reason for any part of the user interface to be slower than my brain.
Even a lot of straightforward text editors can’t figure this out. I tried to use Atom for a while, but the multiple-second delay for launching Atom and opening new windows was just too frustrating. Although I prefer Atom in most respects, this forced me back to Sublime text, which is sufficiently fast (probably <50ms) both on launch and for any other UI action.
I think this actually forces me to write better code. When I can’t use the IDE as a crutch to help me remember the name of a function, or which module something comes from, or what the type of a function is, it forces me to organize everything in a way that helps me keep everything in my head. This usually boils down to more genericism, more considered names, and better module layout.
They mentioned boilerplate. Boilerplate code should be viewed as a design failure of the tools and framework you’re using. At some point, you’re going to need some, simply because on some level, we actually do need redundancy in language, but it should be minimal. Code generators, especially code generators that automate boilerplate, are a special evil. They demonstrate either that your language lacks expressiveness or your approach to the problem is a poor fit for the language in question.
Simplify your shit
Yes, but it is only one of the many ways that your tools and framework can fail.
Some other notable ways they can fail:
I could go on for at least 2-3 more before I get into the esoteric stuff.
Demanding ‘no boilerplate’ means you lose access to the (many!) tools that solve those other problems well (typically because they deliberately chose boilerplate to support those features).