151–160 of 356 posts
Earlier quoted context omitted.
> Ruby/Python are interpreted scripting languages This is not quite right since they both compile to bytecode and execute in a virtual machine shell scripting is, probably, the very rare example of "interpreted"
Python can be compiled to bytecode, but that's not the default or standard.
Somewhat playing devil's advocate, but if everyone joins that club, we keep the status quo and there's no more progress. If everyone joined this club in the 50's/60's we'd still be writing assembly. It's the guys pushing new shiny things that allows our domain to go forward, we just need to accept that 90% of the shiny new things eventually turn out to be crap. It's about the other 10%.
A huge part of our VC bubble in OSS infrastructure (NoSQL, clouds, middleware, automation) is fueled by a generation of technologists not choosing boring technology. This is a great presentation, and great advice. What this piece misses are the marketing, hiring practices and incentives in that capital pool that is fueling FOMO (fear of missing out) as the main driver of our technology trends. Most people orbiting IT…
You mention k8s and related stuff isn't always the answer. Seems you think it's somewhat valuable? I'd like to hear what sort of tech you think is creating a bubble by being so useless! Certainly k8s can't be it, because for large companies the automation abilities of such a system are quite clear. Does it intro new problems, of course, and if they aren't well solved yet you'll have to think hard about the benefits of adopting The New Way, but to call this a bubble is hard to accept.
Earlier quoted context omitted.
> For example, in 1974 when the new Altair 8800 made the cover of Popular Electronics[2], an excited Paul Allen showed the magazine to a 19-year old Bill Gates. The "boring tech" advocates would tell them they're wasting their time with the "new fad of microcomputers" and they should look at boring IBM 360 mainframes instead. I remember reading a book around the late 90s (the book was written in the early 90s) about…
That's a false analogy, because the micro was a category changer. It was literally the basis of entire new markets. A lot of people saw that coming. A lot of other people - like DEC and DG - didn't. IBM mostly didn't, but was lucky enough to have a small division that did in spite of the culture around it. (And they lost it. Too bad.) Node, Mongo, Clojure, etc were never category changers - they were solutions made b…
Rust is the killer micro of software development. It's all about getting rid of pointless hype and helping you "ship good working software out of the door". That's why people don't get it, and dismiss it as a "toy".
Earlier quoted context omitted.
Do you similarly feel like frontend stacks have seen no meaningful innovation? I think your argument works fine-ish for backends but it's bananas to suggest that jQuery is the same thing as React or Svelte. I do security for a living and maybe 100% of all jQuery sites have XSS. If I find a React page I can just grep for dangerouslySetInnerHTML and I'm 80% of the way there. (I am exaggerating, but hopefully my point i…
The procedural nature of jQuery just makes for buggy as hell websites as well. Manual DOM updates etc. etc. React being 'declarative' tends to end up with more stability in regards to UX (e.g. complex search forms). Makes the integration of third-party components smoother too.
1. Frontend was less mature to begin with
2. Frontend has a unique, definitional state management problem in the DOM
3. Actually, we can make real progress sometimes
4. Really, frontend hasn’t made strides, you’re just ignoring $x
5. Several/none of the above?
(I think real progress is possible and disillusionment with some new technologies should not prevent us from trying. But also that the DOMs unique state management problem is so overt that functional approaches almost couldn’t help but dominate.)
Another case of someone discovering, after 10+ years in tech, that code is a liability and you're supposed to solve problems instead of chasing trends and padding the resume. Great that he's spreading the word!
Yeah I thought that until I had to look for a new job and my resume just had boring old technology on it. Now I make sure I do some padding!
Earlier quoted context omitted.
You don't delete it because it's a liability in the maintenance account but it's an asset in the features account.
So everything is a liability?
A huge part of our VC bubble in OSS infrastructure (NoSQL, clouds, middleware, automation) is fueled by a generation of technologists not choosing boring technology. This is a great presentation, and great advice. What this piece misses are the marketing, hiring practices and incentives in that capital pool that is fueling FOMO (fear of missing out) as the main driver of our technology trends. Most people orbiting IT…
Not sure I agree with this perspective. Many of these companies are started by engineers or product managers who have seen the boring solutions not work for them. In some cases they either see it not work many times or see a future where other organizations get to that point and need a better solution. In digging into what these companies do it becomes clear that they aren't doing it just to push new tech, but maybe…
Kubernetes is a great piece of technology but it’s also hyped beyond the stratosphere. My point wasn’t Kubernetes about thoughtful adoption of Kubernetes in context, it was about buzzword bingo being played by those that want to use a set of newer technologies as weapons for their political battles or career aspirations. This requires active leadership to resist.
Author mentions Clojure a few times as an example of shiny-thing. Ironically, it's one of the few languages that I can reliably do in the browser, on the backend (on real servers or say, Lambdas), and build native binaries for -- which addresses the later "many tools" problem better than a "boring" programming language like Ruby. Unless you don't care about frontend code I guess :-) (Overall this talk is fine! I thin…
But: - good luck finding a Clojure programmer if your current one quits. - good luck finding answers for your exotic bug/performance issue etc. Code is a liability, it's much more than language/VM/compiler features
My anecdotal experience with posting a Clojure job online (especially in the Clojurians slack) has been several decent applicants applying in matter of a few days.
This so depends on the talent of your team. If you are normal then play it safe as most of us are. But if you want to make something great then you must resort to exploration, discovery and invention.
Part of the point of the article is that you probably don't need new technology to create a new _product_.