4 ms·

I remember, during a short-lived consulting gig back in 2012, trying to convince a company to use Scala. They panicked about the lack of IDE support and refacto

I remember, during a short-lived consulting gig back in 2012, trying to convince a company to use Scala. They panicked about the lack of IDE support and refactoring tools. "IDE support is immature." Response: well, true, but you don't need an IDE. Java makes IDEs mandatory because it's a crappy, verbose language. Scala doesn't. Clojure especially doesn't. Haskell doesn't (although convincing that company to move off the JVM would have been impossible). "Where are the refactoring tools?" Response: when you have good static typing, the compiler is far better at enforcing refactoring safety than any tools on the market. (Java itself combines the worst of static and dynamic typing.) People-- especially non-programming managers-- have become dependent on the trappings of productivity that they've forgotten what actual work looks like. Java culture is full of this nonsense. The business becomes so dependent on a convoluted toolchain that it doesn't need for most purposes. Then there is the myth of the "full stack developer". It's a good idea in theory, but no one knows what it means. It's just management "at the end of the day, it's all about leveraging our core synergies" bullshit. What's really going on is that execs and professional managers can't evaluate the work in most specialties, so they've decided to pretend that specialties don't exist. All types of programming get thrown together into "it's all code; just make the thingy work" and what that means is that programmers get stuck cleaning up any kind of technical mess they have the bad fortune of having thrown to them. The result is that a good number of programmers (those who aren't savvy enough to play the game and be selective in what work they do) end up learning a bunch of crappy, parochial, non-transferrable "how we do things here" details but (a) never get a coherent career or develop the ability to protect a specialty, and (b) are constantly learning "new" but ill-thought-out and incoherent things. For what it's worth, I used to think that this was a "new" problem, or a symptom of the industry getting worse. I'm not so sure that it's very new. Maintenance programming, 20 years ago, was the same slog that it is today. If anything, the situation is getting better. I agree that Git is not user friendly at all, but the damn thing works, and it's far better than other VC tools (e.g. Perforce).

pnathan 12y ago
Great point. Many devs won't touch a tech stack that doesn't have tons of tooling and lots of ceremony possible. (To those used to such things, you will find something tremendously freeing if you drop down to using no language specific tools but the compiler/interpreter).
- izacus 12y ago
  That's because we mostly know just how much time and frustration a good debugging (note: not editing!) toolchain saves. There's a huge difference using IDEA with it's integrated debugger to for example, typing everything out manually in GDB. And here Scala isn't any different - it's noticably easier and takes way less time to debug a complex piece of software since we have good IDEA integration. And that's what most of people bashing IDE's don't get: it's the ease debugging that's important, not typing code!
  - pnathan 12y ago
    Honestly, I've seen people who swore by their IDEs and paired with them... usually what was going on is they were writing code they literally did not understand, and used the IDE as a lever to help them get by without understanding. IDEs simply allowed them to write very bad systems without any conceptual integrity, and they did. Which wasn't my original point really.
    - michaelochurch 12y ago
      Personally, I'm a believer in the concept of a read-only IDE. Sometimes code visualization becomes easier with a GUI. I'll grant that. Likewise, IDEs can make debugging easier. Writing of code with an IDE has the problems you discussed.
hibikir 12y ago
Back in 2012 Scala already had some decent IDE support in IntelliJ. It's far better now, as pretty much everything that is supported in Java works in Scala too. Clojure is in a different situation though, but that's because its type system, or lack thereof. Just like in Javascript, people end up falling back to REPLs and other such primitive tools, because the IDE just can't tell you very much about your code. Code is data is not a strength, but a double edge sword. As for Git's usability, yes, it's not very good, which interestingly seems to be a key reason of why it has so many advocates: it forces you to understand a whole lot of internals to be proficient at it, and while git's command line interface is pretty ugly, its internals are elegant. It's kind of the opposite of what happens with Mercurial: It's easier to start working with it, so people don't look into it long enough to fall in love and start advocating. What I really find interesting about this whole 'let me code' thing is that, while I really don't want to spend valuable mental space dealing with a complex environment, I do not want to use it instead on code, but on figuring out what is the right code to write. We obsess over the mechanics of coding, over our tooling, but what really matters is that we are actually solving the right problem. I spent some time this month with some code written by my predecessor at this job: A well known library designer and speaker. He had looked at a hard problem, wrote a proof of how to solve it, and wrote a mathematically correct implementation matching his paper. The problem is that his premises were incorrect: He failed to account for some unavoidable issues. That made his last 4 months of work here a waste because he was just solving the wrong problem. I want to spend less time coding, and more time making sure that the coding is actually solving the real problem at hand, not an incorrect idea of the problem.
- codygman 12y ago
  I think proving your implementation correct can be a great thing after it's had some time to verify your implementation accounts for issues that come up in production.
kyllo 12y ago
People-- especially non-programming managers-- have become dependent on the trappings of productivity that they've forgotten what actual work looks like. Java culture is full of this nonsense. The business becomes so dependent on a convoluted toolchain that it doesn't need for most purposes. Web programming is now, too. Look around at job postings for frontend dev positions and you'll see basically just lists of fashionable tools, e.g. "Grunt, Bower, Angular, Phantom, Karma, Jasmine..."

pnathan 12y ago

Great point. Many devs won't touch a tech stack that doesn't have tons of tooling and lots of ceremony possible. (To those used to such things, you will find something tremendously freeing if you drop down to using no language specific tools but the compiler/interpreter).

izacus 12y ago
That's because we mostly know just how much time and frustration a good debugging (note: not editing!) toolchain saves. There's a huge difference using IDEA with it's integrated debugger to for example, typing everything out manually in GDB. And here Scala isn't any different - it's noticably easier and takes way less time to debug a complex piece of software since we have good IDEA integration. And that's what most of people bashing IDE's don't get: it's the ease debugging that's important, not typing code!
- pnathan 12y ago
  Honestly, I've seen people who swore by their IDEs and paired with them... usually what was going on is they were writing code they literally did not understand, and used the IDE as a lever to help them get by without understanding. IDEs simply allowed them to write very bad systems without any conceptual integrity, and they did. Which wasn't my original point really.
  - michaelochurch 12y ago
    Personally, I'm a believer in the concept of a read-only IDE. Sometimes code visualization becomes easier with a GUI. I'll grant that. Likewise, IDEs can make debugging easier. Writing of code with an IDE has the problems you discussed.

hibikir 12y ago

Back in 2012 Scala already had some decent IDE support in IntelliJ. It's far better now, as pretty much everything that is supported in Java works in Scala too. Clojure is in a different situation though, but that's because its type system, or lack thereof. Just like in Javascript, people end up falling back to REPLs and other such primitive tools, because the IDE just can't tell you very much about your code. Code is data is not a strength, but a double edge sword. As for Git's usability, yes, it's not very good, which interestingly seems to be a key reason of why it has so many advocates: it forces you to understand a whole lot of internals to be proficient at it, and while git's command line interface is pretty ugly, its internals are elegant. It's kind of the opposite of what happens with Mercurial: It's easier to start working with it, so people don't look into it long enough to fall in love and start advocating. What I really find interesting about this whole 'let me code' thing is that, while I really don't want to spend valuable mental space dealing with a complex environment, I do not want to use it instead on code, but on figuring out what is the right code to write. We obsess over the mechanics of coding, over our tooling, but what really matters is that we are actually solving the right problem. I spent some time this month with some code written by my predecessor at this job: A well known library designer and speaker. He had looked at a hard problem, wrote a proof of how to solve it, and wrote a mathematically correct implementation matching his paper. The problem is that his premises were incorrect: He failed to account for some unavoidable issues. That made his last 4 months of work here a waste because he was just solving the wrong problem. I want to spend less time coding, and more time making sure that the coding is actually solving the real problem at hand, not an incorrect idea of the problem.

codygman 12y ago
I think proving your implementation correct can be a great thing after it's had some time to verify your implementation accounts for issues that come up in production.

kyllo 12y ago

People-- especially non-programming managers-- have become dependent on the trappings of productivity that they've forgotten what actual work looks like. Java culture is full of this nonsense. The business becomes so dependent on a convoluted toolchain that it doesn't need for most purposes. Web programming is now, too. Look around at job postings for frontend dev positions and you'll see basically just lists of fashionable tools, e.g. "Grunt, Bower, Angular, Phantom, Karma, Jasmine..."