Yeah, shared context over time is the answer to all these problems and has been for both history and prehistory. Patience appears to be the scarcest resource of all these days.
For a long time I avoided projects written in Python for this same reason, though they seem to have resolved the issues over time. The only stack these days that gives me pause is nodejs, but for different reasons.
Yeah, I think the Ruby world burned out of the whole "make everything nice" aesthetic when they alienated the everloving fuck out of _why. Now it's a post-apocalyptic wasteland where if you want nice things, you better be prepared to become a right expert because you will have no one to turn to when it breaks. I don't mind, I don't make money coding anymore and the challenge makes me feel alive again.
If I ever get to the point to where I gotta learn the C API, I'll do it through mruby. But it'll be a much easier path to systems work to interop with Rust instead.
She's very hit or miss in her quality IMO. Also, she's explicitly disclaimed the title of "science communicator", so she might not want to be on this list anyway. :)
I kind of wish they hadn't included Veritasium either. He seems to have gone downhill.
Her content is mostly meta, vs science comm/teaching. I am really torn on her: Great communicator, funny, accomplished. Seems confident/smug?/conservative for a scientist. Something about her word choice and style feels more politician than learner/researcher. Not sure how to phrase this.
That's an interesting perspective. I definitely don't get a "politician" tone from her. Her tone seems very casual to me. Conservative in the broad sense, maybe (definitely not politically).
I think this tone is definitely a deliberate creative choice, and is something I personally enjoy. I'm reminded of this line from Taylor Swift's new album: "did you girlboss too close to the sun?"
It's borne out of the mountains of disrespect women scientists have to deal with, something she talks about towards the end of her video on Richard Feynman.
Author gives own take on what they thinks servant leadership means, then invents a supposedly different kind of leadership that is just servant leadership, taken into a different context than the original church one, then gives it a new name, one that doesn't really tie into their definition.
v, then t/T or f/F if staying on the same line, j and k if it’s within a couple line, / or ? for anything else. With the repetition commands ./,/n/N if I do not land at the correct place.
This article made me laugh and cry at the same time. I've spent so much time in my career trying to make things nice and seamless only to see my own team members throw out my careful work for something newer, shinier, and shittier. I was on a team that used Bazel. Like two devs took the time to figure out how it worked, everybody else just either worked around it or complained endlessly about it.
I am now thoroughly convinced that software engineers, if there is currently no snake whispering in their ear to throw away the paradise garden they're been handed on high, will find a way to do it anyway. Coders will, to the last, prefer self-inflicted misery over the heaven they've been gifted for free.
And if you don't believe me, let me tell you we already have a fully-vertically integrated tool stack, a whole family of them. It's called Smalltalk, it's been around since the 70s, and modern variants of course exist. You can build stuff in it today, and thoroughly enjoy your computing life as a result.
The second you turn your head though, your fellow teammates will conspire to replatform onto Go or Rust or NodeJS or GitHub Actions and make everything miserable again.
Don't buy the nonsense that vertical integration is hard. It's not. You just hire really sharp folks, get them excited about the idea, and they do all the hard integration work, then you release it to the community and let them build on it. Rails was like this back in the 2010s, there was this golden age where everything just worked. Then all of a sudden javascript took over the web world like cancer and the web stopped being fun.
It's not that it's hard, what it is is brittle. A vertically-integrated stack, by its very nature, cannot survive forces that jostle it in the horizontal direction. And coders are too afraid of falling behind that they end up fetishizing any new idea that comes along, no matter how daft. Javascript on the server?!?! Your solution to js's, let's call them problems, is gradual typing? That snake's never gonna run out of ears to whisper in, lemme tell ya.
Integrated toolsets can, have, and are still being done. You can use them now. But you don't want it. Even if you do, nobody you work with will trust it or keep it after you leave. And so companies have no motive anymore to sell them to you. Microsoft themselves stopped trying after 2019.
> It's not that it's hard, what it is is brittle. A vertically-integrated stack, by its very nature, cannot survive forces that jostle it in the horizontal direction.
Is this not exactly the whole problem, though? Fault tolerance.
My chisel doesn't need to integrate with my hand plane which doesn't need to integrate with my band saw. One of them breaking doesn't break the others.
This is why experienced developers gravitate toward powerful tools that they trust deeply but that have extremely hard boundaries. It's why we're still stuck with ASCII text as the primary artifact for coding, for example. The moment we try to move off of that a single fault can bring down the whole house of cards.
It is but 90% of this horizontal pressure is just nonsense. Not actual faults that need to be tolerated. Cooler heads stick around and solve the problems, but by the time that happens, the larger dev community has already moved on to something thoroughly crappier.
ASCII is perhaps a poor example, all modern tooling is UTF-8 capable.
The Rails experience of 15 years ago is still achievable, with Rails, today. It's even better if you can believe it. You just have to throw out the notion of SPA frameworks and be willing to actually learn how HTML / CSS works. I read an article here a month ago about how nobody's willing to do that.
The deficiency in web standards that SPA frameworks were invented to resolve have all been fixed, there's nothing they offer anymore that you can't do without them. But they hang over the neck of the web world like an albatross.
> The second you turn your head though, your fellow teammates will conspire to replatform onto Go or Rust or NodeJS or GitHub Actions and make everything miserable again.
Curious how would you use use Smalltalk in replace of GitHub Actions assuming you need a GitHub integrated CI runner?
All any build toolkit is is automations over bash. You can make your own. GitHub integration need not be any more than the most trivial thing that works. Your coworkers, naturally, won't be disciplined enough to keep the integration trivial and will build super complicated crap that's realty hard to troubleshoot, because they can.
Meh, I think its just hubris to ignore your users (in this case the rest of the team) and tell yourself they're just dumb for not using your clearly perfect system.
There is a slight amount of NIH you have to fight, but for the most part, if a process is truly seamless, that NIH will get pushed to a different part of the stack that's more front of mind.
The real issue is that you're trivializing needs that live outside your purview and because of that you can't fathom why a js dev who wants a server to do something would want js on the server.
Ignore them? I did anything but. I know the new solution was shittier because I was the one who implemented it. Every single time. It never made my life better, only worse.
I wanted to like modal editing in Emacs. But I had to come to terms with the fact that it's always going to be a kludge. Boon is the best I've seen it get, but when I wanted to improve it, I realized it would be less work over the long run to just make my own text editor, though that's mostly because my chosen language, ruby, just doesn't have very good tooling yet.
If you're willing to live in elisp, Emacs is amazing. I'm not, I'm always going to want to do it with ruby, and well, Emacs doesn't let you do that.
When I went to go look for a platform to implement a personal text editor on, I somewhat quickly settled on the vt100 terminal api with kitty extensions, particularly its keyboard protocol. Everything else locks you into, not only a language, everybody codes frameworks these days, nobody writes apis, but also what's essentially already a legacy solution, a framework is going to get updates at the speed of the developer's passion.
Whereas when kovid made the kitty terminal protocol, it got implemented by the next 3 or so new terminal emulators. You don't get this kind of modernization from any other UI solution save browsers. And no way do I want to do web development for my own stuff. I suppose I could target Dillo or something like Servo, but I'd be more inclined to consume the base X11 protocol, as Vidar H did.
My Ruby terminal protocol implementation has smooth abstractions from methods performing the bare VT control calls up to semantic methods with better naming, to flexible and extensible text field abstractions. All the concerns are separated nicely and Ruby lets me scope everything just right, so I can call a debugger anywhere as the necessary logic is scoped module-wide.
I simply cannot imagine having any kind of fun doing this in a static compiled language. And I'll be able to build on top of this to make things that aren't editors.
