5 ms·

I strongly disagree. A lot of my peers in college were very bright and could write great code, but they were absolutely useless as developers because they didn

I strongly disagree. A lot of my peers in college were very bright and could write great code, but they were absolutely useless as developers because they didn't know any tooling. They couldn't compile, run, test, or source control their code if the professor didn't set it up for them. Yes, tools change, but the knowledge from one tool is almost always transferable. Once you're comfortable on the CLI and understand the concept that Java source is compiled to bytecode and then run on a VM, it's easy to switch to a new compiler. If you only want to know the absolute bare minimum, go to a boot camp. People go to college to learn, and being comfortable with tools is an essential part of being a developer that students need to learn.

sarakayakomzin 7y ago
>A lot of my peers in college were very bright and could write great code, but they were absolutely useless as developers being a useless developer doesn't make it not computer science. not all of computer science is software development.
deleted 7y ago
[deleted]
kqr 7y ago
In particular, command line compilers have been used virtually the same way since the first command line interfaces, so knowledge of javac is definitely transferable. IDEs change more frequently.
shawnz 7y ago
I agree that many developers are not very adept with tooling, but is that because they don't use the CLI? Or is it just that they aren't interested in those parts of software engineering? Eclipse is a tool too, and not a simple one either.
- 1test456 7y ago
  The author is specifically talking about students. The emphasis at this stage plays a key role in whether they'll have that interest or not. Knowing is a prerequisite to developing interest.
  - shawnz 7y ago
    I agree, but regardless of if they're exposed to a CLI, they will be exposed to tooling. Why is GUI tooling less likely to spark that interest?
    - NoraCodes 7y ago
      GUI tooling almost entirely uses the command line layers under the hood, so it is strictly more complicated while hiding more of the real process - the worst of both worlds. My point about Git is an example of this. Teaching Git is hard, partly because Git's command line UX is bad, but layering the complexity of, e.g., EGIT on top doesn't really remove most of that and makes it harder to teach (because expressing what to do in a GUI is strictly harder than communicating text commands, among other things).
      - shawnz 7y ago
        EGit doesn't call the git command line application, it uses a Java implementation of git. Although I can agree it's debatable whether they have improved on the command line interface or not.
- rubber_duck 7y ago
  IDEs are convenience layers, compilers are essential abstractions - if you don't know how it works underneath the GUI layer you will get stuck really fast and won't be able to troubleshoot when you eventually run in to inevitable problems with IDE, build, compiler.
  - shawnz 7y ago
    What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler, or that it's been around for longer? A GUI isn't necessarily just calling CLI apps in the background, it could be using programmatic interfaces too.
    - thewebcount 7y ago
      > What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler It's not simpler! It's way more confusing to figure out that your make file told your compiler to run a command with some unknown set of obscure options that are causing an error than to just have the IDE pop a dialog and tell you in plain words, or better, not even let you set an option incorrectly in the first place.
    - dahfizz 7y ago
      The CLI is more explicit than a GUI. In a GUI, compiling / running / testing your code is an afterthought that happens at the click of a button. In the CLI, you have to be explicit about what actions are taking place. You have to physically type in what command you want to run and the different arguments to it. The convenience of a GUI is fantastic, but the abstraction makes it a very bad learning tool. Being able to open up a terminal and fix the inevitable git / build / configuration errors is a very valuable skill that developers should have.
      - tonyedgecombe 7y ago
        I don't see the distinction. I started my career using command line tools and am completely comfortable with them. Yet for more recent projects I stay within the IDE (usually Visual Studio). It doesn't matter whether I tick a checkbox for compiler warnings or add that option to the command line. The only difference is the IDE makes options easier to discover. It's the same for Git. A decent GUI gives you a much better visual picture of the state of your working copy.
cle 7y ago
Agreed. The least effective developers I’ve had the displeasure of working with never understand how their code executes end-to-end. And the best ones have a deep knowledge of it. This is no fluke! If you don’t know how a classloader works with the Java classpath, how to set various JVM flags for operating the JVM, etc., then I’d argue that you’re an amateur, and I wouldn’t trust you to write correct code in a production setting. It’s critical knowledge to know how your code runs, and if you don’t know that, then stay away from production systems. If the goal of these courses is to teach students enough about Java to use it in a professional setting, then knowing how classfiles are produced, bundled, distributed, loaded, and executed by a JVM is critical knowledge. More succinctly, if you don’t know how your code makes it to a production server and gets executed, you’re not ready to work on it. (And if the goal isn't to teach students how to use Java in a professional setting, then why are they learning it at all? Use a teaching language so students can focus on the concepts instead of Java's idiosyncracies.)
- siphor 7y ago
  eh, I understand the sentiment - but it's a little overkill. Junior programmers can be code reviewed and taught these things over time, and also be wildly productive in a production setting.
  - cle 7y ago
    Sure you can teach junior programmers all kinds of stuff that they should have already learned or should know how to learn, I do it all the time. I'm arguing that this is crucial information that even entry-level engineers should know. If they don't, then I give them a link to the relevant documentation and politely ask them to read it. It's a prerequisite.
- ir123 7y ago
  Are there any books or articles that go through the things that you’ve mentioned like how the class loader works etc? Most of the tutorials or books I have seen do not even touch this aspect and I want to get better at it.
fossuser 7y ago
Maybe gradle then? Or actual tooling? I’d agree that some focus on that in CS programs would extremely valuable. Maybe things are better now, but when I went in 2008-2012 git wasn’t even mentioned and basically all tooling was learned on your own.
hluska 7y ago
I haven’t taken an introductory CS course since the mid 90s, so I don’t have enough knowledge to know whether I agree or disagree with you. What was the base level of knowledge like when you were in introductory courses? Back in the day, you couldn’t guarantee that everyone could even turn a computer on, so for loops were a second midterm thing. Edit - I should mention that my last sentence was the perspective of 18 year old me. I was 18, but in my defence I was 18. :)
xzel 7y ago
Isn't eclipse a piece of tooling? I mean I think the best argument against teaching eclipse is IntelliJ is much better, imo, and is more widespread than eclipse at this point. Student should have a module/class whatever about command line tools as well. I this comparison is comparing two things that aren't comparable, an IDE vs learning the CLI. I also think you contradict yourself in your last sentence. Teaching an IDE in class should help people be comfortable with their tools but at some point they might need to know what the tool is doing under the hood.
- jussij 7y ago
  > but at some point they might need to know what the tool is doing under the hood. The problem is the IDE makes it so easy to never have to look under the hood, to the point when people take a peek the get overwhelmed and quickly return to the comfort of the IDE. However, in real world of production environments there will be no IDE holding your hand and as such you can't get away without a good understanding of the engine under the hood.
  - xzel 7y ago
    Yeah they’d probably be using some build system or framework or script and still wouldn’t need to know the invocation for javac.
  - watwut 7y ago
    The situation in which you run javac or edit in vim in production is absurdly rare. In real world, you always use tools and in real java world there is always ide or application server or something.
- bluedino 7y ago
  I haven't really played around with java since the 90's, and I bought a Java book and tried hopping back in. It was really frustrating because the book uses 8 and I downloaded 9 and Eclipse was slightly diffferent, something with modules blah blah. Plus downloading the actual Java SDK was confusing, the versioning, it not being free anymore...
watwut 7y ago
IDE counts as tool too. And knowing it is not different the knowing other tools.

sarakayakomzin 7y ago

>A lot of my peers in college were very bright and could write great code, but they were absolutely useless as developers being a useless developer doesn't make it not computer science. not all of computer science is software development.

deleted 7y ago

[deleted]

kqr 7y ago

In particular, command line compilers have been used virtually the same way since the first command line interfaces, so knowledge of javac is definitely transferable. IDEs change more frequently.

shawnz 7y ago

I agree that many developers are not very adept with tooling, but is that because they don't use the CLI? Or is it just that they aren't interested in those parts of software engineering? Eclipse is a tool too, and not a simple one either.

1test456 7y ago
The author is specifically talking about students. The emphasis at this stage plays a key role in whether they'll have that interest or not. Knowing is a prerequisite to developing interest.
- shawnz 7y ago
  I agree, but regardless of if they're exposed to a CLI, they will be exposed to tooling. Why is GUI tooling less likely to spark that interest?
  - NoraCodes 7y ago
    GUI tooling almost entirely uses the command line layers under the hood, so it is strictly more complicated while hiding more of the real process - the worst of both worlds. My point about Git is an example of this. Teaching Git is hard, partly because Git's command line UX is bad, but layering the complexity of, e.g., EGIT on top doesn't really remove most of that and makes it harder to teach (because expressing what to do in a GUI is strictly harder than communicating text commands, among other things).
    - shawnz 7y ago
      EGit doesn't call the git command line application, it uses a Java implementation of git. Although I can agree it's debatable whether they have improved on the command line interface or not.
rubber_duck 7y ago
IDEs are convenience layers, compilers are essential abstractions - if you don't know how it works underneath the GUI layer you will get stuck really fast and won't be able to troubleshoot when you eventually run in to inevitable problems with IDE, build, compiler.
- shawnz 7y ago
  What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler, or that it's been around for longer? A GUI isn't necessarily just calling CLI apps in the background, it could be using programmatic interfaces too.
  - thewebcount 7y ago
    > What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler It's not simpler! It's way more confusing to figure out that your make file told your compiler to run a command with some unknown set of obscure options that are causing an error than to just have the IDE pop a dialog and tell you in plain words, or better, not even let you set an option incorrectly in the first place.
  - dahfizz 7y ago
    The CLI is more explicit than a GUI. In a GUI, compiling / running / testing your code is an afterthought that happens at the click of a button. In the CLI, you have to be explicit about what actions are taking place. You have to physically type in what command you want to run and the different arguments to it. The convenience of a GUI is fantastic, but the abstraction makes it a very bad learning tool. Being able to open up a terminal and fix the inevitable git / build / configuration errors is a very valuable skill that developers should have.
    - tonyedgecombe 7y ago
      I don't see the distinction. I started my career using command line tools and am completely comfortable with them. Yet for more recent projects I stay within the IDE (usually Visual Studio). It doesn't matter whether I tick a checkbox for compiler warnings or add that option to the command line. The only difference is the IDE makes options easier to discover. It's the same for Git. A decent GUI gives you a much better visual picture of the state of your working copy.

cle 7y ago

Agreed. The least effective developers I’ve had the displeasure of working with never understand how their code executes end-to-end. And the best ones have a deep knowledge of it. This is no fluke! If you don’t know how a classloader works with the Java classpath, how to set various JVM flags for operating the JVM, etc., then I’d argue that you’re an amateur, and I wouldn’t trust you to write correct code in a production setting. It’s critical knowledge to know how your code runs, and if you don’t know that, then stay away from production systems. If the goal of these courses is to teach students enough about Java to use it in a professional setting, then knowing how classfiles are produced, bundled, distributed, loaded, and executed by a JVM is critical knowledge. More succinctly, if you don’t know how your code makes it to a production server and gets executed, you’re not ready to work on it. (And if the goal isn't to teach students how to use Java in a professional setting, then why are they learning it at all? Use a teaching language so students can focus on the concepts instead of Java's idiosyncracies.)

siphor 7y ago
eh, I understand the sentiment - but it's a little overkill. Junior programmers can be code reviewed and taught these things over time, and also be wildly productive in a production setting.
- cle 7y ago
  Sure you can teach junior programmers all kinds of stuff that they should have already learned or should know how to learn, I do it all the time. I'm arguing that this is crucial information that even entry-level engineers should know. If they don't, then I give them a link to the relevant documentation and politely ask them to read it. It's a prerequisite.
ir123 7y ago
Are there any books or articles that go through the things that you’ve mentioned like how the class loader works etc? Most of the tutorials or books I have seen do not even touch this aspect and I want to get better at it.

fossuser 7y ago

Maybe gradle then? Or actual tooling? I’d agree that some focus on that in CS programs would extremely valuable. Maybe things are better now, but when I went in 2008-2012 git wasn’t even mentioned and basically all tooling was learned on your own.

hluska 7y ago

I haven’t taken an introductory CS course since the mid 90s, so I don’t have enough knowledge to know whether I agree or disagree with you. What was the base level of knowledge like when you were in introductory courses? Back in the day, you couldn’t guarantee that everyone could even turn a computer on, so for loops were a second midterm thing. Edit - I should mention that my last sentence was the perspective of 18 year old me. I was 18, but in my defence I was 18. :)

xzel 7y ago

Isn't eclipse a piece of tooling? I mean I think the best argument against teaching eclipse is IntelliJ is much better, imo, and is more widespread than eclipse at this point. Student should have a module/class whatever about command line tools as well. I this comparison is comparing two things that aren't comparable, an IDE vs learning the CLI. I also think you contradict yourself in your last sentence. Teaching an IDE in class should help people be comfortable with their tools but at some point they might need to know what the tool is doing under the hood.

jussij 7y ago
> but at some point they might need to know what the tool is doing under the hood. The problem is the IDE makes it so easy to never have to look under the hood, to the point when people take a peek the get overwhelmed and quickly return to the comfort of the IDE. However, in real world of production environments there will be no IDE holding your hand and as such you can't get away without a good understanding of the engine under the hood.
- xzel 7y ago
  Yeah they’d probably be using some build system or framework or script and still wouldn’t need to know the invocation for javac.
- watwut 7y ago
  The situation in which you run javac or edit in vim in production is absurdly rare. In real world, you always use tools and in real java world there is always ide or application server or something.
bluedino 7y ago
I haven't really played around with java since the 90's, and I bought a Java book and tried hopping back in. It was really frustrating because the book uses 8 and I downloaded 9 and Eclipse was slightly diffferent, something with modules blah blah. Plus downloading the actual Java SDK was confusing, the versioning, it not being free anymore...

watwut 7y ago

IDE counts as tool too. And knowing it is not different the knowing other tools.