I disagree. I prefer talks, most of the time, especially on stuff that isn't nitty gritty technical. Do I want someone explaining to me on stage how to install minikube and deploy a container? Hell no.
But take what Fowler did, namely talking about refactoring, organizing and structuring your code - the broad strokes stuff. I think it's a lot more enjoyable and effective to listen to a talk (esp in person) for that, than it is to read about it.
Humans are social creatures, and I do enjoy the human aspect of learning from another human. Teaching is performative. I don't get that from a text as much as from a talk.
Of course, everyone's different, and that's why it's good it doesn't have to be either or.
That's perverse. You shouldn't have to self-censor out of fear. The fact that Amazon (Doordash, Google, ...) can get away with just cancelling people's accounts willy nilly and they'd have no recourse is a gaping hole in regulations.
BTW, it's off-topic, but this right here is the among best arguments we can make for strong privacy, and against mass surveillance. If people are willing to swallow monetary damage out of fear to upset an algorithm that may cut back their privileges, imagine what happens to political free speech when you have to fear govt surveillance and black vans.
There are crucial differences between Java applets and JS.
- Applets tried to render their own GUI, Wasm doesn't and defers to the browser.
- applets needed a big, slow to start and resource hungry VM. Wasm is running in the same thread your JS is also running in, it's light, and loads faster than JS
- Java and flash were plugins, which needed to be installed and kept up to date separately. Wasm is baked into your browser's JS engine
- Wasm code is very fast and can achieve near native execution speeds. It can make use of advanced optimisations. SIMD has shipped in Chrome, and will soon in Firefox
- The wasm spec is very, very good, and really quite small. This means that implementing it is comparatively cheap, and this should make it easy to see it implemented by different vendors.
- Java was just Java. Wasm can serve as a platform for any language. See my earlier point about the spec
So it's apples and oranges. The need to have something besides JS hasn't gone away, so their use cases might be similar. The two technologies couldn't be more distinct, though.
I disagree. As a software engineer, R is a nuisance, it's a terrible language, and I hate doing complicated things in it.
But it's very powerful, it's exactly right for these use cases and its ecosystem is mindbogglingly huge. Also, it tends to be easier to grasp for folks who don't have prior programming knowledge (anecdotal, but I've seen people pick it up very quickly who struggled a lot with, say, Python. And Python is the only language/ecosystem that comes close to R.)
So, yeah, a lot of languages could be used for the use cases in TFA, but R is uniquely suited, weaknesses notwithstanding.
On my 6 year old mobile phone, I can do the same thing in Signal. Takes seconds to find arbitrary strings in years long very active conversations.
Honestly, I've no idea how we can accept bad performance in Teams and Slack. I can grep hundreds of megabytes of text in seconds on a raspberry pi. You have to actively try to make your software shitty to not be able to do that on a modern desktop.
Adobe did not birth Flash, they bought it, through Macromedia.
Also, Flash gets a lot of flak, but it saved us from applets and ActiveX. It also enabled multi media content on a web that was not yet as standardised and functional as today's.
Acrobat reader on the other hand, is pure cancer, and has seen many security holes. PDF is useful, but there are far better PDF readers.
I hear this sentiment a lot, and its proponents usually don't spend any thought on disproving other views. Such as, maybe it's better to have everyone motivated well, instead of having a few people excessively motivated while the rest trudges along.
Maybe it depends on the field? Do you need superstars or are you only as fast as you slowest team mate?
And maybe, but I barely dare say it out loud here, maybe compensation has less to do with performance and more to do with who eats dinner/cracks a beer with whom. In this case, how would the motivation argument even hold?
I don't know which one is true. I wouldn't try to sound too convinced of any one of these unless I knew the situation of the business very well.
The BBC is publicly funded. The entire idea behind publicly funded news and broadcast is that they shouldn't care about eyeballs, singe they don't need and money.
If it is indeed abuse related (whether there was any abuse or Google's algorithm just decided there was some abuse) then telling the abuser what got them banned is counterproductive from Google's PoV. Same reason reddit does vote fudging.
If you are concerned about your privacy, you can use an OSS keyboard app. Hacker's keyboard is one for android. There are some on F-Droid. You may even prefer them to Google's offering.
The idiomatic error handling mechanism of Java is the checked exception. This mechanism does not work with higher order functions.
You can emulate Rust's approach with Java, by creating what is essentially a sum type like Result. You'd have to enforce that any access to its content must also handle the error case, and I don't really know how to do that generally. There are various hacks, like having a bespoke sum type for that particular operation that twrows a particular exception on access to its content. But that gets really old, really fast.
Try to stick a function that may fail into a higher order function. The best example would be .map on streams/collections.
You can only do it with unchecked exceptions in Java. In Rust, you can transparently do it with iterators and the result type.
So given xs: [A] and f: A -> Result<A, E>, it is trivial to typesafely get Result<[A], E> by xs.map(f) where map: forall T. [T] -> (T -> S) -> [S]. This is outright impossible with Java. You have to circumvent the type system, or emulate Rust's approach.
Unchecked exceptions don't tell the caller something might go wrong. Fine for Python, where strong guarantees aren't a thing anyway, but any statically typed language cannot be content with essentially adding bottom to every single type.
Checked exceptions have failed, or at least I haven't seen anybody fix their issues. They proliferate spurious exception types in interfaces. They are inflexible, as they usually can't be generic. They suck at typing error cases for higher order functions. They're big heavy and expensive, so can't be used for hot code paths. They're exceptions but more often than not you want to signal expected failure...
> - but I'm only half-joking when I quip that PHP has evolved from its roots as a cargo cult version of Perl into a cargo cult version of Java.
It's a joke in so far as it is funny - but it's absolutely correct. When you only look at the language... When looking at the VM, Java has an absolutely world class VM, with great engineering and decades worth of research poured into it.
I would like to say that not all git front ends are like that. I used to be a CLI only user, but now you can pry magit from my cold, dead hands. It's very close to the command line in what it does, it's very easy to see what exactly it does, and where it abstracts from git commands, it does so while following Git's mental model very well.
It has great discoverability while at the same time being an amazingly streamlined power user tool.
In other words, there can be great git front ends. It's just that most of them suck, usually because of a desire to dumb down the git UI. If you don't do that, and accept Git's complexity it can work out great.
I started using Vim in mid/late 2000s, and successfully switched to Emacs. Without knowing your specific gripes, it's hard no know what'll end up helping you, but here are my two cents:
- use emacsclient and have aliases for emacsclient -c and and emacsclient -n for popping up a new frame or using the console, respectively. I even have a window manager binding to open a new Emacs client window
- Rainer König is the best at getting across org mode workflows. if you like watching nerdy videos, go watch him.
- keep vim around, I still use it, sometimes, but with no or veery minimal config.
- centaur tabs and the new tab stuff can help vim people who like tabs. I just got used to buffers.
- M-x is really Emacs' primary UI. don't try to think of a million and one key bindings up front, just bind what you find yourself using M-x a lot for. You just need a nice completing read like ivy, helm or so, but doom has that.
- use magit. While many claim that org-mode is the Emacs killer feature, I'd say magit is even more important if you code. There simply is no better git interface, nothing comes close. You think git the new porcelain is cool? Magit is a git jacuzzi.
But take what Fowler did, namely talking about refactoring, organizing and structuring your code - the broad strokes stuff. I think it's a lot more enjoyable and effective to listen to a talk (esp in person) for that, than it is to read about it.
Humans are social creatures, and I do enjoy the human aspect of learning from another human. Teaching is performative. I don't get that from a text as much as from a talk.
Of course, everyone's different, and that's why it's good it doesn't have to be either or.