tuddman

I suspect these companies view upgrading core functionality tech as a cost center to be avoided at all costs and for as long as humanly possible. "If it ain't broke, don't fix it", I hear them bark from their bean-counting management perch. So too were the companies that were content with their horse drawn delivery trucks to move their goods around town.

We now have a better, faster, cheaper (by orders of magnitude) way to move not goods but value through a network.

Obviously neither of us know how long it'll take for the legacy systems to completely die off, but they will. So I'll simplify the bet to: when, not if. Still game?

As with most technological advances and innovations, people - even laggards of technological adoption - tend to over-estimate in the near term and under-estimate in the long term in terms of predicting the 'impact' of a given technology. So based on nothing at all other than witnessing corporations and industries rise and fall for more than 2 decades now because of new technologies, let's say 7 years before you're out. Fair?

I stopped using the term 'technical debt' with non-technical people a long time ago to describe needing to maintain code. One guy even tried to convince me he was correct that the term is BS because, 'he heard from some other <unnamed> guy that technical debt is programmer BS code-speak for wanting to work on pet projects, and not what the business wants or needs.' And that he should ignore anyone who tries to tell him otherwise. Ignoring the fact that if development slowed to a crawl, basically the company would fold and we'd all be out of a job. Anyway.

I liken maintaining code to maintaining a car/engine.

The engine/pit crew analogy has worked well on more than a few occasions: - We're trying to keep this thing running, right? - We want it to run fast, and be impressive, right? - We want to be able to corner quickly, right?

Well, when's the last time you had an oil change? If there's a bunch of gunk in the engine, and we're carrying this 1000lb load of sugar that that one customer asked us to carry, how fast do you think we can go?

If we tend to the engine, we can keep it running smoothly, if at all.

So, we have a choice: Do we (a) take it to jiffy-lube once every 5 years, or never because who wants to invest in maintenance? and let that one kid who doesn't know what he's doing change the oil? Or do we (b) let an experienced pit crew tune, monitor and clean the engine and tires regularly so we can fly around the track and win races and make lots of money?

You like cars, right? Hopefully you get it. You decide.

> Clojure has other weaknesses which become apparent rapidly.

Clojure has lots of strengths which also become apparent the more you works with it: async, thread-first, thread-last, transducers, core.logic, (partial f a), flexible composition, expressive-ness unrivaled in Dayjob language, hundreds of functions that just work on whatever data you're dealing with, tapping into java "dayjob" libraries without having to deal in actual java. The list goes on.

I've re-written a few applications & libraries from javascript (and other dayjob languages) -> clojure(script). In every case, the lines of code drastically dropped, the functionality expanded, the readability improved, and performance was always on par or better. It's not a silver bullet for everything, but its strengths far outweigh its weaknesses. Like any good mind-expanding drug/language.

> Clojure learning will leave you yearning.

It has been my experience with learning clojure that with each new problem, it has left me yearning ... to learn the more elegant, composable, flexible, robust solution ... in clojure! YMMV.

I also built a system that extracted structured and unstructured text from images/pdfs. For the generated pdfs, I found pdftotext could pull with 100% fidelity, and so that was 'option #1'. for scanned-images-saved-as-pdfs, then tesseract could sometimes extract with 90+% accuracy. But never 100%. Combining pdftotext (with the right flags set) with some of the other associated pdf-tools, we were able to achieve what we were after: Building a searchable DB and auto-informing corpus of information derived entirely from various pdf sources. All in-house. No sending off to 3rd parties.

> Anyone putting their money in IOTA is an absolute idiot.

I bought in when it was trading well under $1. I'm holding long term so I don't much care about today's price, but it _is_ nice to be up >700% so far.

I don't consider myself an absolute idiot on this one.

> It's 100% premined, which smells as scammy as Ripple. It's not a coin, it's an entity handing you gift vouchers with their name on it.

No scam. There was an announced, publicly available crowd sale available to anyone paying attention & interested in 2015. Sorry you missed it.

kerl comes from the fact it wraps & extends keccack hashing library. So the name is actually quite fitting.

To disable that deceptive snooping in 6.0 (Marshmallow):

Settings -> Location -> Improve Accuracy -> Toggle Wi-Fi scanning.

Author is projecting. Replaced "me" with "people" in writing this. Considered himself smart; tried to wrap head around Bitcoin, but lacks math/cs/finance background, and or curiosity to dig below surface level hype or read blockchain-y things beyond what's written by other lazy journalists ...? (now I'm projecting).

Doesn't 'get it'.

Plenty of people understand Bitcoin. Go read the whitepaper.