7 ms·

> Fast programmers build hacky tools to get around the hacky tools that they built to get around the hacky tools that they built to help them code. This resona

by cesarbs 12y ago

> Fast programmers build hacky tools to get around the hacky tools that they built to get around the hacky tools that they built to help them code. This resonates so much with me. Sometimes I worry that I'm falling behind on keeping up with technology, but whenever I try to learn something new it seems like I have to install a package manager, then another package manager inside the first one, then pull a million other tools and libraries and frameworks before I can even begin doing something with this stuff I'm trying to learn. No, thanks. I love computers, I love computing, I love thinking about solving problems using computers, but I hate the direction things seem to be taking. I'm seriously considering a career change in the immediate future because all this crazy tooling truly burns me out.

NateDad 12y ago
Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.
- cesarbs 12y ago
  That sounds awesome, I'll definitely give it a try.
  - keyle 12y ago
    I am afraid a language change is not going to help your burn feeling
    - NateDad 12y ago
      I don't know that I agree with that. Tooling bloat was specifically mentioned, and Go is quite good with respect to that. There's just the one go tool to install, which can be installed just by unzipping a zip file. From there on in, you don't need any other tools. It just uses VCS for package management. You don't need an IDE... the single go tool has support for pretty much every part of the development cycle - compiling, testing, code formatting, profiling... there are no other tools you need to create real deliverable software. I've been writing Go for over two years and still haven't added any other tools to my standard workflow - git and go are the only two commands I type while writing go code. (At work we use a revision pinning tool, but I haven't needed that on my side projects.)
- deleted 12y ago
  [deleted]
- woah 12y ago
  I found go to be quite cumbersome in comparison to npm. Magic folders in the filesystem and such. With node you never have to do more than npm install and everything is ready.
  - burke 12y ago
    Go has a couple wonky conventions, but it's a very very simple system. Once you accept and learn to deal with the GOPATH quirks, that's pretty much the only tooling weirdness in the whole ecosystem.
  - sysk 12y ago
    <rant> npm (and the CommonJS module system) is the #1 reason I use Node.js. I don't care if Javascript is ugly, npm totally makes up for it. I don't get why most module systems implicitly import symbols in the scope (Python, Ruby) or worse, those that pollute the global scope (PHP). Brew (Ruby) is not that bad but Python's package ecosystem is a complete mess (distutils, setuptools, pip, etc.). Cabal (Haskell) is pretty good too in comparison to C/C++ (installing dependencies usually involves following instructions in a README file, that is, if there are available instructions for your OS). I haven't tried Go. I believe the language of the future will be built around, and win mainly because of, its package system/ecosystem. </rant>
    - ploxiln 12y ago
      <rant> npm is easily the worst. Python is a lot better. I hold the C library model as the golden standard, so we're not going to see eye-to-eye. The worst part of npm is the sub-dependencies. Having enabled them, they proliferate endlessly. Each time I improve the efficiency of deploying a strictly controlled tree of modules, the front-end devs manage to double the number in use. 200, 350, 650, over 1000... oh and these improvements come from realizing that npm-shrinkwrap isn't 100% reliable, and ending up with scripts comparing npm-ls output and doing full wipe and replace with a tarball for even the slightest change to the dependency tree. If some serious bug is discovered in one of these things, there's no way the 20 copies of it at various levels of this tree of 1000 modules are going to get patched. No one really has a handle on what's in these hundreds of megs of various versions of modules. This is the true fast code movement - serious problems can't be fixed in there, they'll just be ignored and replaced with other bugs in the twice-yearly full rewrite. Don't get me wrong, our frontend devs are among the best I've seen, but the pressures and environment they're in make them focus on churning out the latest fad in web design and skimping on engineering quality everywhere possible. Python doesn't do implicit import of symbols into a scope if you don't use "from blah import (star)". Don't use the (star). Managing, and using, a list of python modules, each at a particular version, is way simpler, more reliable, and more efficient (than npm style). Pip can reliably list installed module state (freeze) and install from source tarballs or git tag checkout. You need to fully control and understand the versions of all libraries installed and used on a system in order to have a fully reproducible deployment state, and be able to reliably roll back to a previous state. Given that, the Python or C model is much easier to work with. </rant>
- burke 12y ago
  Yeah, I was also about to post a comment recommending Go. It's not completely immune to tooling bloat, but it's actively reductionist in that respect. It's relatively pleasant.
- simplify 12y ago
  No package manager or dependencies seems strange. What would you call all the projects on this page? https://code.google.com/p/go-wiki/wiki/PackageManagementTools https://code.google.com/p/go-wiki/wiki/PackageManagementTool...
  - NateDad 12y ago
    There's no required package manager. By default, your VCS is your package manager. You can write code for a long long time with just the default go tool. Those are optional tools that you can use once you become comfortable with the language and understand their tradeoffs. You really don't need any of those tools until you want to write a professional project with multiple people on a team.
allendoerfer 12y ago
It is not the fault of these tools. You can think of code as data, and programmers producing this data, just like many other professions are producing data, too. Programmers often have a variety of far better tools to handle this data. I think the reason for this are of course the programmers dogfooding, but also the culture of life-long learning, which minimizes UI design to just API design. An intuitive GUI for a crowd less open to learning new things is so much harder to make. I nevertheless see this as a gift. It is your attitude with these tools, that makes you unhappy. I I often have this strange feeling of missing out on an even better technology, the cool kids might be using. I think the key here is to be confident with your choices of tools, improve them, when their is pain and identify when something is good enough for some time (measured in years) before you should reconsider again. In the end it is also about handling the tools. This sounds very reasonable but in practice it is often hard to overcome the urge to use the new shiny tool, which seems to make you a better programmer, when you define yourself as one. I don't think the extremist view of skipping them altogether and condemning the whole thing is the solution. I believe people, who feel they can't keep up in this imaginary race either search for ways to define themselves in another way e.g. in alternative careers (like you) or in their opposing way of programming (like the article author) throwing the others in a bottle of people, who do it wrong. There is a middle-ground between the Node developer and his weekly changing recursive package managers and the Coldfusion shop not doing scm.
ternaryoperator 12y ago
One treatment of this exact problem: Just let me code [1] [1] http://www.drdobbs.com/tools/just-let-me-code/240168735 http://www.drdobbs.com/tools/just-let-me-code/240168735
- cesarbs 12y ago
  That was a nice read, thanks. I'm glad to know there are more people that share the same feeling as I do towards the state of our craft.
balls187 12y ago
Curious which languages you use that don't have this problem? Usually the point of package managers is to allow you to leverage the work of others, so you don't have continually reinvent the wheel. I've yet to run into a programming environment that did not have it's shares of headaches and nuances.
- cesarbs 12y ago
  > Curious which languages you use that don't have this problem? None. It's why I'm burnt out and want to so something different. Not something different from my current job. Something different from developing software. I've lost count of how many times I've spent entire work days battling against the environment which is supposed to help me write the code I need to, to make a customer happy. Entire days of trying to figure out why IIS is acting crazy, or why Visual Studio is crashing, or why is Windows so damn slow all of a sudden. Entire days of trying to align the planets so that service A can talk to service B, because for some reason there's a cryptic SSL error that's not giving me any helpful information as to what's happening. Or entire days just pulling things from a dozen different sources and figuring out where to place each other so they can work together. I've recently been to the Living Computer Museum in Seattle. You can play around with old computers there. I was fascinated by the old machines where you'd boot into a REPL. The shell was a REPL to the language you programmed the system in. I think despite all the advances we've made in the past decades and all the great performing technology we have nowadays, we've lost that essence of simplicity along the way.
  - woah 12y ago
    Sounds like you have a problem with the shitty ms stack. Have to do some c# at work and I feel your pain.
  - jnbiche 12y ago
    > Windows so damn slow all of a sudden VS is an awesome development environment, but I was having your problems with Windows and programs running under Windows for most of my adult life. I switched to Linux full-time at about 5-6 years ago, and I've been happy ever since. I can leave the OS running for weeks with no issues, and it would probably go for months but I'll turn the power off. Oh, and with Linux, if you don't run a graphical desktop environment like Gnome or KDE (which most distros have the option of doing), then you boot into a REPL you can program the system in (Bash shell). Windows used to have the same with DOS, but no more...
pnathan 12y ago
> Fast programmers build hacky tools to get around the hacky tools that they built to get around the hacky tools that they built to help them code. Yes, this is extremely problematic. The hacky junk built by hacky developers is frustrating and a direct contributor to my burn-out quotient.
innguest 12y ago
I feel the same way you do about everything you said, including considering a career change for this same reason. I'm now fiddling with Tcl/Tk as a way to quickly throw some visual ideas around. I'm using it to build an idea for a tabular programming language that is more visual and allows for letting go of incidental details like syntax, argument order, etc.
4ydx 12y ago
This is why something like golang is appealing. Simple simple and more simple.
- eropple 12y ago
  Simplicity for simplicity's sake isn't a virtue. I often feel that Go chooses that path ideologically, whereas real world use cases should have more innings (yes, it's the generics and shitty type system thing again, I'm not expecting us to agree, I'm just pointing it out). To that end, Go doesn't work for me. I use a fairly straightforward stack atop the JVM because I can hold the whole thing in my head (nothing in either Dropwizard or Play is deep magic) and have the expressiveness in Scala to be clear with my code.
  - 4ydx 12y ago
    Parsimony my friend. Parsimony. All else is academic tail wagging.
  - 4ydx 12y ago
    And the issue isn't so much whether or not a programmer can hold the "entire system" in their head so much as, if they don't need to, they can be doing a whole lot more. This is, after all, what computers are good for.
    - eropple 12y ago
      I can do a lot more when I can trust my system to evaluate my code and throw compile-time errors. I can't trust Go's you're system in the same way I can Scala. I noted the simplicity of the stack mostly to forestall the usual tired complaints about complexity, nothing more. What you call "academic", I call "building at scale."

by cesarbs 12y ago

NateDad 12y ago

Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.

cesarbs 12y ago
That sounds awesome, I'll definitely give it a try.
- keyle 12y ago
  I am afraid a language change is not going to help your burn feeling
  - NateDad 12y ago
    I don't know that I agree with that. Tooling bloat was specifically mentioned, and Go is quite good with respect to that. There's just the one go tool to install, which can be installed just by unzipping a zip file. From there on in, you don't need any other tools. It just uses VCS for package management. You don't need an IDE... the single go tool has support for pretty much every part of the development cycle - compiling, testing, code formatting, profiling... there are no other tools you need to create real deliverable software. I've been writing Go for over two years and still haven't added any other tools to my standard workflow - git and go are the only two commands I type while writing go code. (At work we use a revision pinning tool, but I haven't needed that on my side projects.)
deleted 12y ago
[deleted]
woah 12y ago
I found go to be quite cumbersome in comparison to npm. Magic folders in the filesystem and such. With node you never have to do more than npm install and everything is ready.
- burke 12y ago
  Go has a couple wonky conventions, but it's a very very simple system. Once you accept and learn to deal with the GOPATH quirks, that's pretty much the only tooling weirdness in the whole ecosystem.
- sysk 12y ago
  <rant> npm (and the CommonJS module system) is the #1 reason I use Node.js. I don't care if Javascript is ugly, npm totally makes up for it. I don't get why most module systems implicitly import symbols in the scope (Python, Ruby) or worse, those that pollute the global scope (PHP). Brew (Ruby) is not that bad but Python's package ecosystem is a complete mess (distutils, setuptools, pip, etc.). Cabal (Haskell) is pretty good too in comparison to C/C++ (installing dependencies usually involves following instructions in a README file, that is, if there are available instructions for your OS). I haven't tried Go. I believe the language of the future will be built around, and win mainly because of, its package system/ecosystem. </rant>
  - ploxiln 12y ago
    <rant> npm is easily the worst. Python is a lot better. I hold the C library model as the golden standard, so we're not going to see eye-to-eye. The worst part of npm is the sub-dependencies. Having enabled them, they proliferate endlessly. Each time I improve the efficiency of deploying a strictly controlled tree of modules, the front-end devs manage to double the number in use. 200, 350, 650, over 1000... oh and these improvements come from realizing that npm-shrinkwrap isn't 100% reliable, and ending up with scripts comparing npm-ls output and doing full wipe and replace with a tarball for even the slightest change to the dependency tree. If some serious bug is discovered in one of these things, there's no way the 20 copies of it at various levels of this tree of 1000 modules are going to get patched. No one really has a handle on what's in these hundreds of megs of various versions of modules. This is the true fast code movement - serious problems can't be fixed in there, they'll just be ignored and replaced with other bugs in the twice-yearly full rewrite. Don't get me wrong, our frontend devs are among the best I've seen, but the pressures and environment they're in make them focus on churning out the latest fad in web design and skimping on engineering quality everywhere possible. Python doesn't do implicit import of symbols into a scope if you don't use "from blah import (star)". Don't use the (star). Managing, and using, a list of python modules, each at a particular version, is way simpler, more reliable, and more efficient (than npm style). Pip can reliably list installed module state (freeze) and install from source tarballs or git tag checkout. You need to fully control and understand the versions of all libraries installed and used on a system in order to have a fully reproducible deployment state, and be able to reliably roll back to a previous state. Given that, the Python or C model is much easier to work with. </rant>
burke 12y ago
Yeah, I was also about to post a comment recommending Go. It's not completely immune to tooling bloat, but it's actively reductionist in that respect. It's relatively pleasant.
simplify 12y ago
No package manager or dependencies seems strange. What would you call all the projects on this page? https://code.google.com/p/go-wiki/wiki/PackageManagementTools https://code.google.com/p/go-wiki/wiki/PackageManagementTool...
- NateDad 12y ago
  There's no required package manager. By default, your VCS is your package manager. You can write code for a long long time with just the default go tool. Those are optional tools that you can use once you become comfortable with the language and understand their tradeoffs. You really don't need any of those tools until you want to write a professional project with multiple people on a team.

allendoerfer 12y ago

It is not the fault of these tools. You can think of code as data, and programmers producing this data, just like many other professions are producing data, too. Programmers often have a variety of far better tools to handle this data. I think the reason for this are of course the programmers dogfooding, but also the culture of life-long learning, which minimizes UI design to just API design. An intuitive GUI for a crowd less open to learning new things is so much harder to make. I nevertheless see this as a gift. It is your attitude with these tools, that makes you unhappy. I I often have this strange feeling of missing out on an even better technology, the cool kids might be using. I think the key here is to be confident with your choices of tools, improve them, when their is pain and identify when something is good enough for some time (measured in years) before you should reconsider again. In the end it is also about handling the tools. This sounds very reasonable but in practice it is often hard to overcome the urge to use the new shiny tool, which seems to make you a better programmer, when you define yourself as one. I don't think the extremist view of skipping them altogether and condemning the whole thing is the solution. I believe people, who feel they can't keep up in this imaginary race either search for ways to define themselves in another way e.g. in alternative careers (like you) or in their opposing way of programming (like the article author) throwing the others in a bottle of people, who do it wrong. There is a middle-ground between the Node developer and his weekly changing recursive package managers and the Coldfusion shop not doing scm.

ternaryoperator 12y ago

One treatment of this exact problem: Just let me code [1] [1] http://www.drdobbs.com/tools/just-let-me-code/240168735 http://www.drdobbs.com/tools/just-let-me-code/240168735

cesarbs 12y ago
That was a nice read, thanks. I'm glad to know there are more people that share the same feeling as I do towards the state of our craft.

balls187 12y ago

Curious which languages you use that don't have this problem? Usually the point of package managers is to allow you to leverage the work of others, so you don't have continually reinvent the wheel. I've yet to run into a programming environment that did not have it's shares of headaches and nuances.

cesarbs 12y ago
> Curious which languages you use that don't have this problem? None. It's why I'm burnt out and want to so something different. Not something different from my current job. Something different from developing software. I've lost count of how many times I've spent entire work days battling against the environment which is supposed to help me write the code I need to, to make a customer happy. Entire days of trying to figure out why IIS is acting crazy, or why Visual Studio is crashing, or why is Windows so damn slow all of a sudden. Entire days of trying to align the planets so that service A can talk to service B, because for some reason there's a cryptic SSL error that's not giving me any helpful information as to what's happening. Or entire days just pulling things from a dozen different sources and figuring out where to place each other so they can work together. I've recently been to the Living Computer Museum in Seattle. You can play around with old computers there. I was fascinated by the old machines where you'd boot into a REPL. The shell was a REPL to the language you programmed the system in. I think despite all the advances we've made in the past decades and all the great performing technology we have nowadays, we've lost that essence of simplicity along the way.
- woah 12y ago
  Sounds like you have a problem with the shitty ms stack. Have to do some c# at work and I feel your pain.
- jnbiche 12y ago
  > Windows so damn slow all of a sudden VS is an awesome development environment, but I was having your problems with Windows and programs running under Windows for most of my adult life. I switched to Linux full-time at about 5-6 years ago, and I've been happy ever since. I can leave the OS running for weeks with no issues, and it would probably go for months but I'll turn the power off. Oh, and with Linux, if you don't run a graphical desktop environment like Gnome or KDE (which most distros have the option of doing), then you boot into a REPL you can program the system in (Bash shell). Windows used to have the same with DOS, but no more...

pnathan 12y ago

> Fast programmers build hacky tools to get around the hacky tools that they built to get around the hacky tools that they built to help them code. Yes, this is extremely problematic. The hacky junk built by hacky developers is frustrating and a direct contributor to my burn-out quotient.

innguest 12y ago

I feel the same way you do about everything you said, including considering a career change for this same reason. I'm now fiddling with Tcl/Tk as a way to quickly throw some visual ideas around. I'm using it to build an idea for a tabular programming language that is more visual and allows for letting go of incidental details like syntax, argument order, etc.

4ydx 12y ago

This is why something like golang is appealing. Simple simple and more simple.

eropple 12y ago
Simplicity for simplicity's sake isn't a virtue. I often feel that Go chooses that path ideologically, whereas real world use cases should have more innings (yes, it's the generics and shitty type system thing again, I'm not expecting us to agree, I'm just pointing it out). To that end, Go doesn't work for me. I use a fairly straightforward stack atop the JVM because I can hold the whole thing in my head (nothing in either Dropwizard or Play is deep magic) and have the expressiveness in Scala to be clear with my code.
- 4ydx 12y ago
  Parsimony my friend. Parsimony. All else is academic tail wagging.
- 4ydx 12y ago
  And the issue isn't so much whether or not a programmer can hold the "entire system" in their head so much as, if they don't need to, they can be doing a whole lot more. This is, after all, what computers are good for.
  - eropple 12y ago
    I can do a lot more when I can trust my system to evaluate my code and throw compile-time errors. I can't trust Go's you're system in the same way I can Scala. I noted the simplicity of the stack mostly to forestall the usual tired complaints about complexity, nothing more. What you call "academic", I call "building at scale."