4 ms·

I’ve been programming in Java for about 10 years now. I would consider myself an expert - I’m not just some guy who built crud apps, I’ve gotten messy with Java

I’ve been programming in Java for about 10 years now. I would consider myself an expert - I’m not just some guy who built crud apps, I’ve gotten messy with Java. I came up programming for minecraft servers - lots of interesting challenges there. The only time I have ever used javac was for fun. Not once professionally.

kaba0 5y ago
I have yet to write java byte code manually, but a high level understanding of them do make me a better developer in my opinion. It’s not about the number of times one uses it, but knowing about the underlying abstraction.
FpUser 5y ago
I spent bout 3 years in the 90s when I needed to mess with Java code. Would not dream about going through all those giant piles of enterprise code without IDE.
- saagarjha 5y ago
  It’s good that we don’t throw people directly into a professional environment when teaching them how to code, no?
  - FpUser 5y ago
    I see no point in wasting time. I learned programming on my own. Started with machine codes. But I grabbed every tool that can help (including IDE) as soon as they appeared. Programming to me was / is a tool I use to make products. I see no point in suffering for the heck of it. Instead of fucking with 10 miles long command line and remembering every squiggly thingy I think it is better to explain to students how computers really work instead.
    - saagarjha 5y ago
      It's nice to learn how tools work internally, so you can fix them when they break. Once you know how to do that, it's fine to graduate into something that does the work for you.
ajuc 5y ago
It's not that you need to use it. It's that you need to understand classpath and classloaders to solve some problems. And if you always use IDE automation there's no incentive until it's too late. Stuff is autoimported and autoinstalled. There's dozens of forms where you can add paths to classpaths depending on what button you press to run stuff. It's all magic when it works, and when it doesn't work it's random changes in random places to fix it. There's many more variables than if you just run the compiler from the command line. Good education should give you understanding of the basics, not just higher-level stuff. It's easier to learn high-level stuff when you got the basics down than to unlearn the "magic black box" approach and dive into basics when you need it.
- KronisLV 5y ago
  > And if you always use IDE automation there's no incentive until it's too late. Too late for what, though? At any point in time there's a certain subset of knowledge that's most relevant that you're trying to do. If it's learning overall programming concepts not the internals of a language which you may or may not use, then NOT using the IDE automation would be detrimental. Furthermore, in every single project that i've worked on professionally, attempting to manually manage dependencies and the way things are compiled would earn me odd looks, since that's far more tedious and less productive than just using Maven/Gradle. Not only that, but manually attempting to manage imports as opposed to letting my IDE do everything that's needed in the background would provide me precisely 0 benefit. In my eyes, "It just works", isn't a bad thing at all, as long as you: - can look into the lower level mechanisms (but only once actually needed) - can find information about all of it, to make the above easier Why would you "unlearn" something if you'll still use it in 95% of the cases, the lower level approaches being the outlier?
  - ajuc 5y ago
    > in every single project that i've worked on professionally, attempting to manually manage dependencies and the way things are compiled would earn me odd looks, since that's far more tedious and less productive than just using Maven/Gradle Of course, we're not talking about doing javac manually when you're working, we're talking about learning the basics before going on to use the automation. BTW Maven and Gradle have plenty of gotchas of their own. If you don't understand what exactly happens you won't solve "magical" problems like old builds of non-snapshot versions remaining in the repo for example. > manually attempting to manage imports as opposed to letting my IDE do everything that's needed in the background would provide me precisely 0 benefit. you say that, and just last month I've had to help a guy manually remove an import of Token class from a wrong package that "magically broke his code" :) > Why would you "unlearn" something if you'll still use it in 95% of the cases, the lower level approaches being the outlier? Because I've seen a lot of people decide something that always worked is not their responsibility to fix when it doesn't work. That's how you end up with 1 guy in the company that understands the build system :)
lordnacho 5y ago
I think I'm in your camp. When you're a programmer, there's a lot of things you rely on that have been done by someone else and you don't really understand, neatly packaged. There's not much point in teaching specific things, because there are thousands of specific things that make a program work. Yesterday my code failed because the whitelist at the server was checking my ipv6 address instead of the ipv4 on the website interface. The day before I was stumped on a Rust borrow checker thing. You end up learning the things that you run into. If you've never needed compiler flags, it's actually not that easy to learn without a motivation. Same goes with memory barriers, garbage collection, and so on. There's just so many rabbit holes. Telling people they need to know this or that is futile, what they need to know is how to figure out whatever their issue is. Some common tools with some common comments about pros and cons, warnings about where the caves are and what's more trivial than it looks. My wife is starting a CS degree, and I'll be looking over her shoulder providing this kind of advice, rather than recommending anything in particular.

kaba0 5y ago

I have yet to write java byte code manually, but a high level understanding of them do make me a better developer in my opinion. It’s not about the number of times one uses it, but knowing about the underlying abstraction.

FpUser 5y ago

I spent bout 3 years in the 90s when I needed to mess with Java code. Would not dream about going through all those giant piles of enterprise code without IDE.

saagarjha 5y ago
It’s good that we don’t throw people directly into a professional environment when teaching them how to code, no?
- FpUser 5y ago
  I see no point in wasting time. I learned programming on my own. Started with machine codes. But I grabbed every tool that can help (including IDE) as soon as they appeared. Programming to me was / is a tool I use to make products. I see no point in suffering for the heck of it. Instead of fucking with 10 miles long command line and remembering every squiggly thingy I think it is better to explain to students how computers really work instead.
  - saagarjha 5y ago
    It's nice to learn how tools work internally, so you can fix them when they break. Once you know how to do that, it's fine to graduate into something that does the work for you.

ajuc 5y ago

It's not that you need to use it. It's that you need to understand classpath and classloaders to solve some problems. And if you always use IDE automation there's no incentive until it's too late. Stuff is autoimported and autoinstalled. There's dozens of forms where you can add paths to classpaths depending on what button you press to run stuff. It's all magic when it works, and when it doesn't work it's random changes in random places to fix it. There's many more variables than if you just run the compiler from the command line. Good education should give you understanding of the basics, not just higher-level stuff. It's easier to learn high-level stuff when you got the basics down than to unlearn the "magic black box" approach and dive into basics when you need it.

KronisLV 5y ago
> And if you always use IDE automation there's no incentive until it's too late. Too late for what, though? At any point in time there's a certain subset of knowledge that's most relevant that you're trying to do. If it's learning overall programming concepts not the internals of a language which you may or may not use, then NOT using the IDE automation would be detrimental. Furthermore, in every single project that i've worked on professionally, attempting to manually manage dependencies and the way things are compiled would earn me odd looks, since that's far more tedious and less productive than just using Maven/Gradle. Not only that, but manually attempting to manage imports as opposed to letting my IDE do everything that's needed in the background would provide me precisely 0 benefit. In my eyes, "It just works", isn't a bad thing at all, as long as you: - can look into the lower level mechanisms (but only once actually needed) - can find information about all of it, to make the above easier Why would you "unlearn" something if you'll still use it in 95% of the cases, the lower level approaches being the outlier?
- ajuc 5y ago
  > in every single project that i've worked on professionally, attempting to manually manage dependencies and the way things are compiled would earn me odd looks, since that's far more tedious and less productive than just using Maven/Gradle Of course, we're not talking about doing javac manually when you're working, we're talking about learning the basics before going on to use the automation. BTW Maven and Gradle have plenty of gotchas of their own. If you don't understand what exactly happens you won't solve "magical" problems like old builds of non-snapshot versions remaining in the repo for example. > manually attempting to manage imports as opposed to letting my IDE do everything that's needed in the background would provide me precisely 0 benefit. you say that, and just last month I've had to help a guy manually remove an import of Token class from a wrong package that "magically broke his code" :) > Why would you "unlearn" something if you'll still use it in 95% of the cases, the lower level approaches being the outlier? Because I've seen a lot of people decide something that always worked is not their responsibility to fix when it doesn't work. That's how you end up with 1 guy in the company that understands the build system :)

lordnacho 5y ago

I think I'm in your camp. When you're a programmer, there's a lot of things you rely on that have been done by someone else and you don't really understand, neatly packaged. There's not much point in teaching specific things, because there are thousands of specific things that make a program work. Yesterday my code failed because the whitelist at the server was checking my ipv6 address instead of the ipv4 on the website interface. The day before I was stumped on a Rust borrow checker thing. You end up learning the things that you run into. If you've never needed compiler flags, it's actually not that easy to learn without a motivation. Same goes with memory barriers, garbage collection, and so on. There's just so many rabbit holes. Telling people they need to know this or that is futile, what they need to know is how to figure out whatever their issue is. Some common tools with some common comments about pros and cons, warnings about where the caves are and what's more trivial than it looks. My wife is starting a CS degree, and I'll be looking over her shoulder providing this kind of advice, rather than recommending anything in particular.