Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

551–560 of 585 posts

Re: My 20 year career is technical debt or deprecated

#551

Earlier quoted context omitted.

> If something is genuinely proven then everyone does actually accept it. This is demonstrably untrue. Vaccines. Evolution. Anthropogenic Global Warming.

Vaccines aren't proven compared to things like the color of the sky, are they? Who on earth still believes that after "95% effective against COVID infection and will end the pandemic" turned into whatever this week's version of the story is. COVID shots demonstrated unequivocally that scientists and officials will happily assert things with 100% certainty that are falsifiable, and then continue to assert them even af…

The colour of the sky is also culturally conditioned. (Ref: Guy Deutscher, Through the Language Glass)

And vaccines don't cause autism. Some things we actually do know.

Re: My 20 year career is technical debt or deprecated

#552

As I think about all the technologies that have come and gone, it's good to find some sturdy rocks as well. Here are some techs that withstood the test of time in my personal journey: * Simple, but reliable file formats: My old photos collection is 25 years old (jpeg) and I still look at them occasionally. * My influxdb/grafana/openhab setup is now 8 years old and has been operational with only minimal hickups. * Som…

Is jpeg really that simple or did it just happen to win the popularity contest big time?

Re: My 20 year career is technical debt or deprecated

#553

Earlier quoted context omitted.

C and Javascript are both worse-is-better languages, as is SQL. They have known gotchas and quirks and lots of them. But they basically work, they were good enough, and because of that they became so ubiquitous that it's impossible to replace them.

Not ... really. Those languages all became popular and got critical mass because they were the only way to access operating systems-like things. People wanted the value provided by those platforms and had to go through the language to get at them. So they buckled up, tolerated it and promptly spent decades and billions of dollars on creating wrappers, FFIs, transpilers and the like to avoid having to touch the underl…

That's exactly how worse-is-better works. You're not doing it well, but you're consistently showing up in the right place and interoperate well with the things people want to use so they are forced to get to know you.

Re: My 20 year career is technical debt or deprecated

#554

Earlier quoted context omitted.

Python is weird. It's a nice language but it was heading for tech debt status along with (maybe) Ruby, then the ML guys went all-in on it and that saved it. But how often do you find new programs being written in Python outside of the ML/AI space? People got burned repeatedly in the 2000s/2010s by building giant empires on the back of dynamically typed scripting languages and they all ended up either doing rewrites i…

Python is great for stuff which could technically be a shell script, but really shouldn't; it essentially replaced Perl.

Which is weird because Perl didn't really go anywhere, and only got better over time. I mean, at this point it's a large dose of network effect, but I'd love to learn how this transition happened in the early days of it.

Edit: I just tried to look it up and as far back as I can find data (which is early 2000s something), it seems that Python has always been more popular than Perl. TIL!

Re: My 20 year career is technical debt or deprecated

#555

Earlier quoted context omitted.

I wonder where python will fall in history - it seems one of the few common languages that gained usage because people like it.

Python is weird. It's a nice language but it was heading for tech debt status along with (maybe) Ruby, then the ML guys went all-in on it and that saved it. But how often do you find new programs being written in Python outside of the ML/AI space? People got burned repeatedly in the 2000s/2010s by building giant empires on the back of dynamically typed scripting languages and they all ended up either doing rewrites i…

But how often do you find new programs being written in Python outside of the ML/AI space?

Python is pretty huge in most numerical spaces outside of ML/AI, basically anywhere people would have used MATLAB in the past. It is also the go to language in GIS and quite popular in civil engineering.

Re: My 20 year career is technical debt or deprecated

#556

Earlier quoted context omitted.

I love go, but still, one of those things is not like the others.

This comment helped me realize that part of what I instinctively dislike about golang comes from ColdFusion PTSD. I just realized that golang reads to me like ColdFusion in the worst ways, including and especially its terrible approach to error handling.

I doubt though that error handling makes or breaks a language. How the ecosystem works seems to be what counts, and as long as Google doesn't close it down any further, it can stay with us for a long time.

I agree that Go is special in this list. If Google pulls the plug someday, then it would all depend on whether a strong community takes over the compiler and language maintenance itself.

Re: My 20 year career is technical debt or deprecated

#557

Earlier quoted context omitted.

I've seen people take Bob Martin's concepts and do some truly awful things with it. Mind-bogglingly awful contortions of concepts into classes in arrangements that have to be sourced from demonic inspiration. At the same time, I've seen the best code of my entire life formed from his concepts. Code that will last decades, far outlasting the UIs that feed it data or the databases that will store it. I think the differ…

> If you're working on a part of the code base you should just have to change classes in one single folder. A new feature should just be a new folder. That change alone speeds up teams by huge factors. This is a neat idea. Have you done this in practice, and how does it work over a long time frame? One of the big advantages of separate packages is purely for references: The model package has no reference to service o…

To the extent I feel the need to do this (in very large projects with many teams) I think it's best accomplished with separate modules. My favorite way is a single repo muktimodule project with the core code in one module, all the database implementations in another, and very small third "main" module that brings them together and has the startup code.

But there are other solutions. You could probably cook up some linters or some other compile time enforcer.

Re: My 20 year career is technical debt or deprecated

#558
post #540
post #538

Earlier quoted context omitted.

I see a benefit from having this options container: you can have a central place to set the options and then only pass down the decoder and the user of the function doesn't have to bother with the configuration

You can always pass a closure.

Or pass an options object.

Regardless, it’s a strictly worse api in the general case. And it’s on par with passing around an options object in the case you want to share the same options in multiple places.

If the current api is either the same or worse compared to a pure function version in all cases, I’d prefer the pure function version thanks.

Re: My 20 year career is technical debt or deprecated

#559

Earlier quoted context omitted.

> If you're coding in Java, you've better think OO is a great idea. It's an object oriented language. There's plenty of room in Java for nice, clean code. All "java is OO" means in practice is that your code needs to be in classes. Some things that work great in java: - Separates out value types from everything else. Value types should usually be tiny, and have public fields. They should not contain references to any…

You're one step away from loving Clojure... the quasi-official motto is "it's just data", and the resulting code tends to be simple and short.

A lot of smart engineers I’ve known have moved to clojure and fallen in love with it. I think you’re probably right.

Re: My 20 year career is technical debt or deprecated

#560
post #541

Earlier quoted context omitted.

The problem with Uncle Bub is that his views only work in sync within very limited situations such as hobby coding and small projects by a handful of developers who are starting on the same page. A lot about Uncle Bub's teachings and FrAgile isn't practical in most of the real world besides a minority of outlier stories (and the problem with those stories is they don't track whether practices continue working long te…

If you only write comments about intention, your code seems self descriptive, doesn't it? Why don't you write comments describing what the code does? > and even they often don't know because... surprise... nobody wrote anything down! Well, read the code

> If you only write comments about intention, your code seems self descriptive, doesn't it?

And who mentioned writing comments only about intention?

> Why don't you write comments describing what the code does?

Yes, why don't we?

> Well, read the code

Because code is never long and vague, and human language can never sum up complex ideas or code?

Post reply on HN