481–490 of 585 posts
"Your grandfather was a brilliant man and his peers all praised him. Go ask him about it!" "Grandfather, what did you spend your life on?" "I made people click ads. Don't worry, it's all technical debt or deprecated now ..."
"Your grandfather was a brilliant man and his peers all praised him. Go ask him about it!"
"Grandfather, what did you spend your life on?"
"I fixed people's shoes. Don't worry, ..."
Earlier quoted context omitted.
To be blunt, the code you copied out as example is crap. I don't know what you expect how it's being interpreted. It says more about the programmer than the language. > functions returning closures with mutable captures That sounds like another bad design, but to each his own.
My apologies if I hit a nerve. I'm just trying to have fun chatting about the foibles of contemporary software development with fellow nerds on HN. I expected something like urthor's post, where they seemed to appreciate the levity of my comment, and responded with some interesting insights. I also appreciated the follow up comment raising a serious concern about the prevalence of cloning and resulting confusion in r…
Earlier quoted context omitted.
Your last paragraph is really interesting to me. It obviously makes total sense. Yet, three environment I've used most in my career is Rails which also splits these things into folders by type rather than feature. It's never bothered me. Now I wonder if that because Ruby isn't Java and folders aren't packages or because I'm so very used to it.
I've worked in a few codebases that tried to group things by feature. In my experience, it never really worked that well. Usually there would either be poor isolation between them or they'd be so well isolated that I'd wonder why they were even in the same project. In the latter, they'd often be difficult to maintain because of a web of dependencies pulled in by the little isolated subfeatures. I prefer the separatio…
The point is that the feature is its own "project" which would likely be loaded in the host application as a gem. I don't think this is actually a strong convention either way in Rails, so it would still be compatible with convention-over-configuration to build an app this way.
(Kinda just thinking out loud. FWIW, I have worked on an application with a similar sort of "engine-primary" structure but not what I currently work on.)
Earlier quoted context omitted.
I'd rather claim that the main reason is that the author seemed drawn towards proprietary tech stacks that the companies behind them wanted to fully control and that contributed to their demise. It was clear from the start that Flash and VB and ColdFusion and all that wouldn't last long, just because no open ecosystem could form to keep them adapting and vibrant. I feel that's substantially different with Python, Go,…
I love go, but still, one of those things is not like the others.
I made a whole bunch of things that have not been deprecated or tech debt. It's about which technologies you use. C is not deprecated. Maybe in a 100 years it will be, but it seems unlikely. It's very rare to find someone who has C as their favourite language, but it's incredibly persistent. C is the opposite of the latest JS framework. I regularly fix bugs in open source, where when checking when the bug was introdu…
> It's very rare to find someone who has C as their favourite language Hello, I visit here every day. Nice to meet you
Earlier quoted context omitted.
But tbf, that happens once in a billion recipes. 99% of new recipes are forgotten, often after a week or two.
Even some of the most famous recipes can change over time. I’m sure that things like McDonald’s burgers are slightly different now. Perhaps the most enduring a chef can do is invent a new technique.
Don't get attached to your code, ever. You are not building the Pyramids of Giza, no one will study your work 3000 years from now, or 15, for that matter. ALL of your code will be dead in a few years. The company goes under, or some punk CTO comes in and commands a "full rewrite ASAP!". Even with normal evolution and refactoring, your original work will be unrecognizable. Either way, you take experience and friendshi…
But I appreciate the Picasso joke. Too many devs try applying over-engineered abstraction to simple problems.
------
From this place I want to greet one such "Picasso" whose code from over 20 years ago I was debugging last week... I know your name...
I've been down on myself about this. I've been at it for coming up on 30 years. I've written scores of programs and applications. There are only a couple still in use. Rather than be upset about it, I find that it's more helpful to think of coding as tooling. As in, actual tooling that machine shops make: dies, jigs, gauges, etc. You know, the stuff that's used to make the actual stuff. Tools go out of date. Tools ge…
(I guess here I should mention the context that I'm not coming up on 30 years; instead it's a little over 10.)
The "no longer in use" part is something I think I ultimately disagree with. It's kind of an "application of Theseus" situation. Where did this data really come from? If it was an older application, did that application ever really go away or did it just become what replaced it? Anyway, I guess I just have to hope I still have this outlook in ~20 years.
The dude equivocates programming in Perl to programming in FoxPro, both are simply "deprecated" and "hard to find." Is this true?
Perl is not so much deprecated, more like the community performed collective jump off the cliff with Perl 6. If you think Python 2->3 transition was ugly, you haven't been watching that slow-mo trainwreck.