Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

101–110 of 585 posts

Re: My 20 year career is technical debt or deprecated

#101

https://phrasegenerator.com/ , one of my first web projects, has survived since 1996 (almost 30 years, wow). It's definitely required a few "tech debt collections" - the original was in ColdFusion, the hot stuff of the time. Then an asp.net / xml phase when that was cool. Now hopefully a boundless future of stability and modernity with python and JavaScript. At least until the world sunsets any pre-4 python versions,…

This is what blows my mind about web stuff. You needed to completely change framework and even languages 3 times in not even 30 years?! Just to keep things maintainable? I don't feel that it's the same for other area's of programming: desktop apps, embedded stuff. Maybe I'm wrong...

[deleted]

Re: My 20 year career is technical debt or deprecated

#102

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.

Re: My 20 year career is technical debt or deprecated

#103

https://phrasegenerator.com/ , one of my first web projects, has survived since 1996 (almost 30 years, wow). It's definitely required a few "tech debt collections" - the original was in ColdFusion, the hot stuff of the time. Then an asp.net / xml phase when that was cool. Now hopefully a boundless future of stability and modernity with python and JavaScript. At least until the world sunsets any pre-4 python versions,…

This is what blows my mind about web stuff. You needed to completely change framework and even languages 3 times in not even 30 years?! Just to keep things maintainable? I don't feel that it's the same for other area's of programming: desktop apps, embedded stuff. Maybe I'm wrong...

A website made in 1999 still work today, the browser is like an OS and the concensus is that you should never break userland, eg. You don't break the web. Then there are as many frameworks that there are developers.

Re: My 20 year career is technical debt or deprecated

#104

Earlier quoted context omitted.

Queue rust apologists… I think C and its direct descendants will slowly fade away over the next 20 years as new developers want to get away from the legacy of language specifications that span existing codebases. There are so many sharp edges in C that have automatic fixes/detections/etc in newer languages and don’t get me started about multiprocessing complexity in C.

My coworker and I were pair programming some Rust today. We were working on a convenience wrapper whose whole purpose is to reduce boilerplate. So, by its nature there's a lot of internal generic traits, thread safety, etc. He knows Rust well but software design not so much. I know software design well but Rust not so much. My experience can be summed up with: let &mut writer = Writer ::writer::new( connection.clone(…

I'm sorry but that doesn't look normal. Code smells with all those clone()'s and unwrap(). It allocates a new Writer and then clones it?! "let &mut writer=" isn't right. The new'ed Writer is a struct; why is there a need to get a reference to it? Why is data being clone() and then immediately de-referenced to create a copy of the clone?

A normal writer API would look like one of the variations:

    Writer::new(&connection).write(&data)
    Writer::new(&mut connection).write(&data)  // if conn needs changes.
It's rare to unwrap(), which can cause a crash at runtime, but to handle the result. E.g. to write more data if the previous write is successful.

    let mut writer = Writer::new(&connection);
    let mut written_len = 0;
    written_len += writer.write(&data1)?  // ? returns the err if it's Err
    written_len += writer.write(&data2)?  // or unwrap the result value
    written_len += writer.write(&data3)?
As you can see, "writer.write(&data1)?" is equivalent to the C++ version.

Re: My 20 year career is technical debt or deprecated

#106

I am somewhat amazed at the list of tech from that article, it's like he has a magical knack for picking dead ends. C was the 2nd language I learned and I'm still using it. The big surprise for me has been javascript - it's so...bad it became good or at least ubiquitous.

JavaScript is that guy you knew who didn’t have a lot of talent but has stuck at it for the last 30 years, so is now embarrassingly doing much better at his thing than you are.

Interesting thought experiment, how much worse would JS have to have been to have been abandoned and replaced?

Re: My 20 year career is technical debt or deprecated

#107

I will say that the core idea of SOAP/WCF services is honestly pretty sound. There is no sensible reason (imo, anyway) that everyone needs to be using stringly-typed data and manually parsing REST responses when the underlying code all has type definitions. I get that it came with headaches (and I suppose people wanted to work in untyped languages) but jettisoning the entire idea of generating the client feels like i…

But you know what happened to SOAP? It was smothered by its own success. The allure of interoperability and extensibility attracted everyone and their cat to the party. With so many stakeholders involved, it became a classic case of "too much design by committee." It's like trying to paint a masterpiece by having a thousand artists contribute strokes—chaos ensues.

And let's not forget the influx of junior developers during that time. I mean, we can't blame them entirely, can we? SOAP standards were complex and enormous. It's no wonder they struggled to grasp the underlying paradigms. We had an army of fresh faces flooding the scene, and the sheer complexity overwhelmed them.

So, SOAP ended up being the baby tossed out with the bathwater. It had its merits, but the challenges it faced were just too much to bear. Still, it's worth reflecting on its strengths and the lessons we can learn. Maybe someday we'll find a way to strike a balance between the elegant core idea and the practical realities of implementation.

Re: My 20 year career is technical debt or deprecated

#108

I will say that the core idea of SOAP/WCF services is honestly pretty sound. There is no sensible reason (imo, anyway) that everyone needs to be using stringly-typed data and manually parsing REST responses when the underlying code all has type definitions. I get that it came with headaches (and I suppose people wanted to work in untyped languages) but jettisoning the entire idea of generating the client feels like i…

But you know what happened to SOAP? It was smothered by its own success. The allure of interoperability and extensibility attracted everyone and their cat to the party. With so many stakeholders involved, it became a classic case of "too much design by committee." It's like trying to paint a masterpiece by having a thousand artists contribute strokes—chaos ensues. And let's not forget the influx of junior developers…

It's not like people don't find a way to screw up REST semantics and make that complicated anyway.

Re: My 20 year career is technical debt or deprecated

#109
post #36

Earlier quoted context omitted.

People are commenting core OS libraries and kernels, but the Space Jam movie website from 96 is still up. I bet the guy that wrote that didn't think it'd be around nearly 20 years later, I hope it never goes down. https://www.spacejam.com/1996/jam.html

It's comforting to think that 2000 years from now, all that may remain of the early web and modern culture is the Space Jam website. Maybe Space Jam the movie will be looked at as our Gilgamesh or Iliad.

And the Galaxy Quest site -- will people in the future know it is a parody?

http://www.questarian.com/

Re: My 20 year career is technical debt or deprecated

#110

Earlier quoted context omitted.

But you know what happened to SOAP? It was smothered by its own success. The allure of interoperability and extensibility attracted everyone and their cat to the party. With so many stakeholders involved, it became a classic case of "too much design by committee." It's like trying to paint a masterpiece by having a thousand artists contribute strokes—chaos ensues. And let's not forget the influx of junior developers…

It's not like people don't find a way to screw up REST semantics and make that complicated anyway.

Absolutely. The lasting ideas are KISS and Occam's Razor.
Post reply on HN