3 ms·

If you infrequently use a language and you are not planning on writing write-once/throw-away code. Then don't use any library/framework. The overhead of dev

If you infrequently use a language and you are not planning on writing write-once/throw-away code. Then don't use any library/framework. The overhead of development today as I see it is not just the languages, but the cognitive overhead of having to learn gigantic libraries and frameworks. I'm seeing libraries/frameworks that are 20x-100x times as complex as the language. Shed those bloat and free your mind. If the language is also fairly large, constraint yourself and restrict yourself to a subset of the language. It's not a must that one must use every feature of a language. The suffering of developers that use an infrequent language is self inflicted. Hell, don't use a language that you don't plan to use often unless it truly offers something that other languages don't, which is rarely so.

nissimk 9y ago
I would generalize this for accelerated learning: Identify the minimum you need to learn to complete your next task and learn only that. This is difficult for two reasons. First, without the knowledge it's hard to identify what is the minimum you need to learn. And second, as someone with an interest in technology it's hard to stop yourself from going deeper. Solve the first problem by guessing with a bias towards learning less and solve the second problem with discipline. If you proceed with this accelerated learning process you can start knocking out tasks using new technology rather fast and you will achieve better results. You may not know all the details of every language and tool that you use but you'll know how to get things done.
jakevn 9y ago
I also recommend avoiding unnecessary libs/frameworks for any code that you expect to run for a long time without change. I do this at work when writing small services in Go and it works out well. Some have been running for three years now without being touched yet there is no code rot and anyone can easily pick it up.
- kstenerud 9y ago
  Absolutely this. Even the base dev environment is often an exercise in madness. I loathe every new iOS version because Xcode will break my code in new and interesting ways, requiring me to recheck every single library I've developed to make sure they still compile (often they don't) and run (almost always they don't). And then, once I've got that headache handled, I update the version number, type 'pod lib lint', and watch all the new and interesting ways that cocoapods has broken things since I last used it. Every 3rd party component you rely on is something that WILL break as soon as you need to rebuild your project.
  - oblio 9y ago
    Not necessarily. People make fun of Java, but any half decent Java place, especially the ones using Maven, won't have this problem. Maven is quite verbose and it forces you to pin a lot of things down. Where it doesn't outright force you, the general practices are to pin them regardless. All the dependencies are in the same immutable Maven repo (or your own proxy/cache), all the build tool extensions/plugins/etc. are there as well. Java is generally very good at backwards compatibility, as is Maven itself. So you can come back a few years later and do a : mvn clean install and things will work. Of course, humans are fallible and things could still break due to various factors, but in this sense the ecosystem helps you and either offers stability already bundled it or guides you towards achieving it. The downside: Maven is boring. Developers don't like boring :)
    - zamber 9y ago
      In JS world we got a package lockfile fairly recently. Locking your own package.json version wasn't enough because packages have deps too. Beforehand running npm install on newly checked out repos was a gamble, especially given that we have packages for every minute "feature" like leftpad (which is a horror story of its own).
- segmondy 9y ago
  I absolute agree. The only reason I didn't really mention this is that I don't want to push for the "not invented here" behavior. Once in a while, there are times when some library/frameworks are worth it. More often than not that's not the case.
- oblio 9y ago
  The thing I don't like on this front for Go is the whole "dependencies on Github" thing. If the dependencies are not vendored or pointing to the correct thing (tags, always tags!), 3 years from now your project might not build. I like the Maven approach of the immutable binary repo. One day a long, long time ago, I found a broken dependency from IBM uploaded on the Maven Central repo, I think. I sent the Maven Central repo maintainers a mail saying that the dependency was broken. They replied saying that they don't ever touch uploaded releases. At the time I was kind of pissed off cause it was a transitive dependency that was breaking stuff. I had to hack around it. But over the years I've come to appreciate that wisdom. Contrast: npm.
  - jakevn 9y ago
    > The thing I don't like on this front for Go is the whole "dependencies on Github" thing. Agreed. I really dislike the GOPATH concept that the original tooling is built around, but I strictly make use of vendoring.
unpwn 9y ago
Sometimes though I think it can't be helped. I for one find myself in charge of maintaining a lot of code that I didn't originally write. For the things that need to be updated and maintained the most I find myself owning and becoming more of a frequent developer of it, but there are still a lot of things that I need to fix if some issue arises, but I have not touched in years if not ever. I can see why the original author wrote it the way they did--they are most likely a frequent developer in that language and in those patterns--but as someone stepping in, I can feel the pain of infrequent developers in that case.
toss1 9y ago
THIS^^! Even as you get deeper into a particular domain, always ask "What is the return?" on investing in any extra toolset. If the cost and mental overhead of the bigger toolset will provide solid improvements in process efficiency and/or quality, then by all means, go for it. But if not... This also applies to other domains, including design & manufacturing, which I'm in now. Sometimes the best, most expensive tool is worth 10x what it costs, and sometimes it's better to just use the basic tools. Caveat emptor, and even more for your time than your money

nissimk 9y ago

I would generalize this for accelerated learning: Identify the minimum you need to learn to complete your next task and learn only that. This is difficult for two reasons. First, without the knowledge it's hard to identify what is the minimum you need to learn. And second, as someone with an interest in technology it's hard to stop yourself from going deeper. Solve the first problem by guessing with a bias towards learning less and solve the second problem with discipline. If you proceed with this accelerated learning process you can start knocking out tasks using new technology rather fast and you will achieve better results. You may not know all the details of every language and tool that you use but you'll know how to get things done.

jakevn 9y ago

I also recommend avoiding unnecessary libs/frameworks for any code that you expect to run for a long time without change. I do this at work when writing small services in Go and it works out well. Some have been running for three years now without being touched yet there is no code rot and anyone can easily pick it up.

kstenerud 9y ago
Absolutely this. Even the base dev environment is often an exercise in madness. I loathe every new iOS version because Xcode will break my code in new and interesting ways, requiring me to recheck every single library I've developed to make sure they still compile (often they don't) and run (almost always they don't). And then, once I've got that headache handled, I update the version number, type 'pod lib lint', and watch all the new and interesting ways that cocoapods has broken things since I last used it. Every 3rd party component you rely on is something that WILL break as soon as you need to rebuild your project.
- oblio 9y ago
  Not necessarily. People make fun of Java, but any half decent Java place, especially the ones using Maven, won't have this problem. Maven is quite verbose and it forces you to pin a lot of things down. Where it doesn't outright force you, the general practices are to pin them regardless. All the dependencies are in the same immutable Maven repo (or your own proxy/cache), all the build tool extensions/plugins/etc. are there as well. Java is generally very good at backwards compatibility, as is Maven itself. So you can come back a few years later and do a : mvn clean install and things will work. Of course, humans are fallible and things could still break due to various factors, but in this sense the ecosystem helps you and either offers stability already bundled it or guides you towards achieving it. The downside: Maven is boring. Developers don't like boring :)
  - zamber 9y ago
    In JS world we got a package lockfile fairly recently. Locking your own package.json version wasn't enough because packages have deps too. Beforehand running npm install on newly checked out repos was a gamble, especially given that we have packages for every minute "feature" like leftpad (which is a horror story of its own).
segmondy 9y ago
I absolute agree. The only reason I didn't really mention this is that I don't want to push for the "not invented here" behavior. Once in a while, there are times when some library/frameworks are worth it. More often than not that's not the case.
oblio 9y ago
The thing I don't like on this front for Go is the whole "dependencies on Github" thing. If the dependencies are not vendored or pointing to the correct thing (tags, always tags!), 3 years from now your project might not build. I like the Maven approach of the immutable binary repo. One day a long, long time ago, I found a broken dependency from IBM uploaded on the Maven Central repo, I think. I sent the Maven Central repo maintainers a mail saying that the dependency was broken. They replied saying that they don't ever touch uploaded releases. At the time I was kind of pissed off cause it was a transitive dependency that was breaking stuff. I had to hack around it. But over the years I've come to appreciate that wisdom. Contrast: npm.
- jakevn 9y ago
  > The thing I don't like on this front for Go is the whole "dependencies on Github" thing. Agreed. I really dislike the GOPATH concept that the original tooling is built around, but I strictly make use of vendoring.

unpwn 9y ago

Sometimes though I think it can't be helped. I for one find myself in charge of maintaining a lot of code that I didn't originally write. For the things that need to be updated and maintained the most I find myself owning and becoming more of a frequent developer of it, but there are still a lot of things that I need to fix if some issue arises, but I have not touched in years if not ever. I can see why the original author wrote it the way they did--they are most likely a frequent developer in that language and in those patterns--but as someone stepping in, I can feel the pain of infrequent developers in that case.

toss1 9y ago

THIS^^! Even as you get deeper into a particular domain, always ask "What is the return?" on investing in any extra toolset. If the cost and mental overhead of the bigger toolset will provide solid improvements in process efficiency and/or quality, then by all means, go for it. But if not... This also applies to other domains, including design & manufacturing, which I'm in now. Sometimes the best, most expensive tool is worth 10x what it costs, and sometimes it's better to just use the basic tools. Caveat emptor, and even more for your time than your money