I wonder about whether I will always be in the business of Legacy development, spend a lot of time looking at different languages, new stuff, functional et al. Messed with Go for a minute, always seems to circle back to some coversation on C. COBOL and C are pretty similar anyway. The question in my mind is always When will the Mainframe be replaced? Am I limiting my skill set by staying with it, having not used OOP style languages much, am I slowly structuring my brain in such away that it will be difficult to adapt to newer stuff I have to? How can I make myself a better developer, and more adaptable in lue of that? Should I focus on staying close to the metal with C like Noodle, or move onto Python/insert language.They've yet to C why they need the D. Everyone needs the D.
But really, C is probably not going to go anywhere in our lifetimes because the truth is that for x86 architecture C is basically it in terms of performance. C was so well designed out that gate that there's no reason to use anything else if you're looking for raw performance, you can add more features, but in terms of hypothetical speed you can't make anything significantly better than C(it's possible, but we're talking low single digit differences here). So the community as a whole sees no real reason to re-invent the wheel, when they do, we get things like D, Rust, etc, which claim to be very fast with essentially just more features or different paradigms, but they're still essentially C.
I expect this to change once X86 architecture starts dying in the next 15yrs~, because C is not optimal for ARM assembly, and I predict that either ARM will over-take x86 in the future or Quantum computing will make this all pointless. Whichever gets there first!
Right, I gave him the benefit of the doubt at first but now I'm vague. He confided in me that he's worried because he's worked in our group for a month and not submitted any code. He doesn't understand that our job is 90% debugging and 10% coding when you're new. People like me are adding new features but new people are working through our bug reports and addressing or fixing them.Re: People asking questions ad infinidum: I think the best way to handle it is to become increasingly vague with the more questions that are asked.
"How do I convert to hex in java?"
"Integer.valueOf(String.valueOf(n), 16);"
ten minutes later...
"How do I convert to binary?"
"https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html"
an hour later...
"How do I parse a number out of a string?"
"google.com"
However, depending on the situation some people get tasked with shit they shouldn't be doing in a field they know nothing about and care nothing about. If I'm tasked with a day long project of why my passwords aren't being salted right ( I know and care nothing about encryption etc), you're damn right I'm not going to go crack open a book on encryption to solve my problems. I'd rather lean heavily on the folks who should probably be doing the work in the first place but they fucked up somehow and now I'm involved. Obviously this isn't true in a lot of cases, and it reeks of entitlement but I think it's true.
Yeah, there have been many times I've realized a solution while trying to explain it on a StackOverflow post. But I wouldn't literally place a rubber duck at my desk...lol so this is common..
Rubber duck debugging - Wikipedia, the free encyclopedia