As a longtime NYC resident with a vehicle, I experienced first-hand the unending frustration and anger amongst drivers over parking. I saw literal fights break out; windows smashed;
I myself grew tired and weary of circling the block looking for on-street parking in and around Manhattan and Brooklyn... only to see someone take a spot that I'd been desperately circling for, looking, hoping, praying I'd find. "If only I'd KNOWN they were leaving?!?!?!?"
So, to solve the problem for myself, I built BTON:
you signal that you're leaving... someone comes and hands you a bton - you can use it to find your next spot; BTONs also have floating value to incentivize the spot leaver. Its free and in the App Stores; Again - I built it for a problem I directly and repeatedly experienced (trying to find parking in NYC). Would love to hear your feedback.
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.
So, to solve the problem for myself, I built BTON:
https://bton.app/
you signal that you're leaving... someone comes and hands you a bton - you can use it to find your next spot; BTONs also have floating value to incentivize the spot leaver. Its free and in the App Stores; Again - I built it for a problem I directly and repeatedly experienced (trying to find parking in NYC). Would love to hear your feedback.