An easy way to do this that I’ve used when resizing images in photoshop is to first scale it to the closest larger integer scaling factor of the target output using nearest neighbor, and then scale that down to the final result with bilinear or bicubic.
I meant the opposite: with only a small mouse movement you can fling a knob wildly, which is great if you want to do a quick transition on eg a high pass filter or a low pass filter
I'm sorry, it's a really inefficient format. I don't want to sit and listen for two hours to what's most likely half an hour of content by reading. Just write down what you have to say already!
I guess you could do double-speed, but I find that somehow stressful.
Edit: I just read the paper. It took me 21 minutes. It's not long, only 11 pages.
For me, podcasts are useful for learning while I drive. They are also useful for refreshing my recollection.
Finally the are useful for synthesis…a podcast can talk about tenuously related topics that would not usually be appropriate for an academic paper; use analogies, metaphors, and similes; and simply go off topic and discuss other interesting ideas that turn out to be more applicable than the formal subject.
I don't particularly like the podcast format either, but it's not inherently less efficient. You can potentially do other tasks while listening to one which would be difficult while reading. I personally find it difficult to concentrate on the content of the podcast when I do this (I don't take in information well from auditory sources), but others don't (and some actually find it hard to remember things they read).
Same for me. I only can listen to podcasts when I'm folding laundry, and my laundry folding needs are limited so it takes ages to get through a single episode.
I listen to podcasts while walking our dogs. Might not be enough for some of these really long episodes, but generally enough to know whether I'm going to finish it or not.
I sympathize, but just happened to listen to this episode over several days. The discussion actually adds a lot to the paper, and they seem very qualified to critique it. One of the guests(?) has written several esolangs. There must be a way to generate a transcript.
Slight spoiler: they have lots of criticisms of the paper.
That's Lu, one of the regular hosts now. All very bright and interesting people, different from each other. I think only Jimmy has a formal CS education, but he'll talk as much about philosophy sometimes.
Also, show notes link to the paper that they talk about that they do like much better.
I really enjoy listening to people talk about things. I get the same enjoyment out of talk radio and any news radio that is editorialized. I enjoy lots of shows on the various NPR member stations.
This format isn't inefficient, you're just judging it based having a different goal than it does.
Could you explain what you like about it? I feel like I'm missing something. I've listened to half an hour now and there have been a like five minutes of substance, the rest is self-references and jarring editing.
If I listen to a podcast I want to learn something, gain a new perspective, listen to a well-moderated conversation or at least laugh.
This podcast does none of those things. Literally doing nothing and letting my thoughts wander is more interesting than listening to this.
I agree with this. This a remarkably bad podcast. And also pretty bad paper to focus on. As the podcast was quite bad, I just read it and it was about nothing at all.
Like, it's a basically blogpost that muses about uhhh couple examples it pulled at random from esolang wiki and has literally no point. Beside prescriptive one. Formatted as a paper, which I admit takes some skills.
No, and not before that either. It’s a bizarre thing to say, honestly. React is used near universally, despite there being alternatives that are better in almost every way. That is the opposite of being under appreciated. Hype about a new technology, deserved or not, doesn’t mean that everyone is throwing their old code away, especially not their jobby job code.
I think it's because around 2015 or so there was a lot happening with front end frameworks, and the sentiment comes from then and people have just not updated their priors since.
AngularJS was pretty popular at the time, Angular 2 migration was looming, backbone still existed, jQuery (standalone or paired with both) was going strong, Polymer hit 1.0 and it looked like Web Components might actually be something and useful, React was gaining a lot of popularity, Vue was gaining a small amount of popularity, svelte an even smaller amount, Meteor was somewhat popular and had its own front end library.
Of course in addition to all that, traditional server rendered sites were more popular then than now and there were even more options there.
However, React quickly became pretty much the default. Not that there's 0 churn there. The "right way" to do React has changed quite a bit in the last decade. And early on before all the libs people liked to glue together somewhat matured/settled it was common to have to replace stuff that just got abandoned.
More than once I had to pick up someone's old unmaintained project to do a bug fix only to find I couldn't even get the project to install/run because it was in the pre auto lock file era and nobody ever ran `npm shrinkwrap`
It is absolutely true that companies were rushing to rewrite their code every few years when the new shiny JS library or framework came out. I was there for it. There was a quick transition from [nothing / mootools?] to jQuery to Backbone to React, with a short Angular detour about 13 years ago. If you had experience with the "new" framework you could pretty much get a front-end gig anywhere with little friction. I rewrote many codebases across multiple companies to Backbone during that time per the request of engineering management.
Now, is React underappreciated? In the past 10 years or so I've started to see a pattern of lack of appreciation for what it brings to the table and the problems it solved. It is used near universally because it was such a drastic improvement over previous options that it was instantly adopted. But as we know, adoption does not mean appreciation.
> React is used near universally, despite there being alternatives that are better in almost every way.
Having worked in both over the years the main technical thing React had going for it over Vue, in my humble opinion, was much better Typescript support. Otherwise they are both so similar it comes down to personal preference.
However 0 of the typescript projects (front and back end) I've worked one (unless I was there when they started) used strict mode so the Typescript support was effectively wasted.
No, I was also around when React was new, moving to it from tangles of jQuery and Backbone. I absolutely know React brought several lasting innovations, in particular the component model, and I do appreciate that step change in front-end development. But other frameworks have taken those ideas and iterated on them to make them more performant, less removed from the platform, and generally nicer to work with. That is where we are today.
I agree that there was a period where many organizations did rewrite their apps from scratch, many of them switching to React, but I think very few did it ”every couple of years”, and I think very few are doing it at all today (at least not because of hype - of course there might always be other reasons you do a big rewrite). We should not confuse excitement about new technologies for widespread adoption, especially not in replacing existing code in working codebases.
I read parent's comment as an assertion that the current "fast-moving JavaScript world" expects everyone to rewrite their app. Personally I've never seen this, but since React became popular ~13+ years ago, I struggle to believe this has actually been true for others in any meaningful way.
> despite there being alternatives that are better in almost every way.
This right here is the under appreciation. The new way to signal to others on forums that you are a really really great dev seems to be to bring up how much better some bizarro templating engine that abuses a niche JS language feature is.
These are not tradeoffs, these are bugs. We don't gain anything from them.
That's why React introduced a compiler. Because problem 1 is a big deal. But it's not a code problem, it's a React problem. Other tools simply do not have that bug. Which is why the exact same react code can be compiled and run much faster.
You haven't described those "fundamental problems" that you call bugs, but I think these are irrelevant for me from a ClojureScript point of view. As an example, immutable data structures mean that equality comparisons are cheap and I can often avoid re-computing and re-rendering huge parts of the tree.
More importantly, I don't have a React performance problem. I don't really need "much faster".
JSX is just sugar around JavaScript, and interops nicely with it. I'm okay with that. The more I write JSX, the better I become at the programming language I'm using. Concepts and patterns in JS can be adopted in my components.
If I learn Vue's templating language, then I'm spending my time learning a system with no wider applicability, a much narrower tooling space, that doesn't utilise my previous or future experience from JS. That's not a good calculus for me.
React's API has guided the developer to learn about events. If they move outside the React ecosystem they have transferable knowledge. As someone unfamiliar with React, but used to the DOM you're surely comfortable here. Yes, the syntax isn't identical to how you might use this in vanilla JS, but it's clearly the same concept. It's just been made a little nicer to use - the sugar.
Vue's API has reinvented the wheel. There's one place this syntax is useful and one place alone - Vue itself. It hasn't used my existing knowledge, or pushed me to become more familiar with the platform upon which I'm building. That's not sugar, that's a new language.
I've probably got the vanilla example wrong - when you don't do it frequently it's not the most ergonomic thing in the world. React takes that API, doesn't deviate far from it, and makes it easier to use. Sugar.
Fun example! Strange conclusion. React actually uses a synthetic event system that is subtly different from the native one in all kinds of little ways. In reading the docs it’s hard to even get an overview of what’s different. Bubbling is a bit different, onChange works like the input event for some reason, various props and methods have been added. This is not the case for Vue! It just uses standard events.
The .prevent modifier in Vue is completely optional, you can call .preventDefault() yourself. Note that React also uses a kind of modifier but only for capturing events (onClickCapture etc). It does not have any way that I know to add a passive event, for some reason.
Vue is the one that actually offers syntax sugar, and does so much more consistently, with the semantics identical to the browser. React changes the semantics for unclear, historical reasons, and then adds half-baked syntax sugar on top.
I'm not claiming React is perfect by any means, and like any popular relatively longstanding project is is bound by sometimes unwise historical decision. It just seems to be currently in vogue to take a pop at it. If you want to extol the virtues of Vue/Svelte/whatever then great, but React is still IMO a great option and deserves some defense.
React often gets lumped into general JavaScript hatred of the form “the entire ecosystem of tooling/frameworks/libraries changes every few months.” That’s despite React existing for one third the lifetime of the World Wide Web. React is older now than jQuery was when React was first released.
Although aside from JSX, so much has changed it could’ve been a new framework at least once, and part of its longevity is that it doesn’t bundle a router, form handling, etc, and the popular ones of these have changed many times.
The "in some circles of the fast-moving Javascript world" is important - they're not saying everyone or even most, they're saying proponents of the "better" systems (who do rewrite regularly) dismiss React's stability as unimportant or indicating it's dead when it's not.
I cancelled my Disney+ subscription through App Store, but since payment is monthly and in advance I still have access for a few more days. So I wonder if my cancellation has even registered in these numbers yet.
I've never understood monthly subscriptions. It's not like it's technically difficult to implement prorating or even look back and see that I haven't used Disney Plus at all and refund me for non-usage.
This event probably triggered a lot of their inactive subscribers like me to look at their bills. Not only will it lose a lot of these people but the required marketing efforts to bring me back would cost a lot more now too.
Has nothing to do with ease of implementation. Has everything to do with the bottom line. Not refunding the remaining half of the month, not refunding the previous unused three months - this keeps money in the corporate bank.
Nothing that involves time and/or money is easy to implement. Not (only) because the code would be hard to write, but because what is at stake. Also, letting money flow back to the customer can lead easily to money laundering/legal problems. So, maybe it is not "technically difficult", but it sure costs more money to make it possible, than other things.
While it will give a little more revenue, I suspect keeping users longer in a "self-paid trial" might ended up change their mind and keep the subscription.
The only reason I would subscribe would be an interesting movie/tv show that I cannot find anywhere else. Frankly, these days if I find those, they just go onto my backlog... then there are also my games, books, bucket list things to do backlogs. So, I'm not subscribed to anything.
You’ve picked a difficult way to make your first typeface. A monoline design with a strict vector grid doesn’t leave a lot of room for the kind of optical adjustments needed for balanced and readable letter shapes. But I think even if you want to be strict about those restrictions there is a lot of room for improvement in consistency and composition of each shape.
I started to write actionable suggestions about individual letters but realized it’s probably better to drop this link, which starts at how to draw an ”A” and continues with every letter of the alphabet. https://ohnotype.co/blog/ohno-type-school-a
Calling it some 1999 iMac stuff is fair, but in that case it was replaced with some 2007 iPhone stuff. I’m not so sure that’s a step forward for a desktop OS.
