It's frustrating at best. On any tiling WM on Linux, I can hit Meta+<#> and be taken to that workspace.
On macOS, the moment I fullscreen an app, it's taken out of that flow. So for so many years, I've had my terminal full screen on workspace 2. Meta+2 it in my muscle memory for "go to terminal".
Show them a Quentin Tarantino film? ...or any film for that matter where the main characters seem so "cool, unfazed and untouchable". To a young (mostly male) mind, that's the ultimate goal; to be in charge. For most beginning smokers, it's not about the inhalation of tobacco, but the subversive "screw the rules, those don't apply to me" façade. This might sound obvious but, if we want 7th graders not to glorify smoking, we quit glorifying it in our media. Make the stupid guy in the movie the one that's dumb enough to smoke. Make everyone laugh at him every time he tries to look cool.
This has been tried before. In Waterworld, the bad guys are literally called the "Smokers" and smoking is a big part of their culture. It's so over the top it seems more like a parody of anti-smoking campaigns. I doubt it ever convinced anybody not to smoke, and I think any similar attempt is doomed to fail in the same way. Kids are good at detecting when you're trying to manipulate them, and it doesn't matter if you have good intentions.
It's kind of both. For some strange reason I watched that movie again recently. I guess they were supposed to be the distilled version of whatever was considered bad in society in the 90s: hyper-masculinity, smoking, oil tankers, guns, religion (they went on "crusades", the leader was "The Deacon") etc.
Yeah I think I’ve seen that movie three or four times and I never made the connection between the name and smoking cigarettes. Figured it was all the oil they had, and engines they could run with it.
The only thing I remember is they made some old dude row around the oil tank on a tiny boat because they had apparently forgotten how fuel gauges and dip sticks work.
Thinking back on it, were they powering their pirate jetskis with heavy crude? Was there a distillation column set up on the oil tanker? I probably shouldn't think too hard about Wet Mad Max because I bet a lot of that movie doesn't really make sense on closer inspection.
Yeah the lack of a refinery does seem like a problem. Maybe they were making something close-enough to diesel out of it with some crude process? No way they were making gasoline, nor most other petroleum fuels.
Kids want to do what they see, if they see people smoke, they want to smoke. If mommy and daddy drink coffee in the morning, it doesn't matter that it tastes like ass, a literal 3-year-old will just by sheer force of will drink that bitter nectar just to feel like they belong.
> If mommy and daddy drink coffee in the morning, it doesn't matter that it tastes like ass, a literal 3-year-old will just by sheer force of will drink that bitter nectar just to feel like they belong
Then I must be quite different from that "literal 3 year old". Mom and Dad both drank coffee, and around the 3-year point I did want to try it, for the reason you say, because it was something "they" were doing. And, yes, that sip did taste like ass. So much like ass that to this day 54 years later, I do not and will not drink coffee.
Negative advertising and positive advertising are quite different.
I'm definitely affected by both, but generally if I feel I'm being nannied my instinct is to go the other way. People don't need to be "convinced" to do things that are good for them - if they're not doing it, they likely just have reasons that you don't understand.
Makes me wonder if over-protecting children from negative feelings backfires. Pulp Fiction was a risk-free and simple way to make vivid the risks of heroin.
I would put Pulp Fiction near the top of the list for "films with surprisingly wholesome moral examples". The overdose, Butch coming back to help Marcellus and their subsequent parting ways, Jules' acknowledgement that he's "buying" not "giving"... to top it off, nobody is trying to moralize or patronize the viewer. Jules was getting close enough to agitate Vince but that just strengthens the film; it's okay to feel Vince's side more and not feel what someone else does despite witnessing the same thing. I was probably late teens when I first saw it but pretty sure if I saw it as a kid that I'd have gotten the good with the bad.
> over-protecting children from negative feelings backfires
it definitely hit differently to "see it myself", versus having it introduced by a parent/guardian, who probably would shy away from making the lesson so graphic
The ultimate thing that convinced me not to smoke was watching my uncle die of lung cancer, and being unable to quit the thing that was killing him.
I'm somewhat relieved that tobacco references are considered "adult" now in entertainment. The amount of smoking I saw in movies and TV (and around my uncle) normalized it for me, even though I knew how unhealthy it was.
For my high school cohort the video interview of the person still smoking after having had a laryngectomy really drove home the powerlessness of addiction.
The problem is seeing all that... And then seeing family members and friends smoke on the weekend... It puts it in this weird "safe to try, but not safe to keep doing" slot.
Nicotine addiction is very subtle, for many it's hard to recognize until you're hooked.
Rather than uncool, just kill them. In british historical drama there is an old standard that any character that coughs will soon die. If the butler even sniffles, they are doomed. So make smoking the new coughing. The kids will then associated smoking with death, living in fear every time their favorite characters go anywhere near cigarettes.
As a non-smoker, I’ve never felt like I needed a cigarette more than when the credits rolled on Requiem. Certainly scared me off of harder drugs, though.
It is remarkable how dramatically smoking was intentionally removed from even period movies, and in some cases edited out of old content.
Perhaps silence works better than negative mention? There's a real problem with anti-war or anti-violence media accidentally making it look cool, similarly with biographies of "troubled star" types detailing their drug uses.
> This might sound obvious but, if we want 7th graders not to glorify smoking, we quit glorifying it in our media
There was quite obviously a concerted effort to remove smoking from movies and shows. It's been going on for more than a decade. It's quite abrupt, go back far enough and everyone smokes, especially the cool guys and gals. Then fast forward and almost nobody smokes, not even the villains. Ads for smoking are gone from my country's TV and cigarette packs by law must display horrifying photos of emaciated cancer patients.
Media is part of it, but seeing the real life adults in your life smoke influences you a lot. It’s not necessarily about emulating people you admire, it’s about adopting a signifier of adulthood.
Smoking by most teenagers is easy to solve: Make all cigarettes hot pink with garish other colors in ugly, ugly patterns. Teenagers don't like looking conspicuously ridiculous.
Friend: Do you have anything that doesn't taste like middle school girl lip gloss?
Gas station attendant: *chuckles* No, sorry.
Friend: Fine, cherry-berry then.
I've had 50/50. These days I'm fairly okay with just taking the Macbook Pro. I did have one instance where I got one my first week and used my Dell XPS with Linux the entire 10 months I was at the place. I returned the Macbook basically unused.
Only one time did I interview with a place where I asked if I'd be given a choice what hardware/OS I could use. The response was "We use Windows". My response was, "no we do not. Either I will not be using Windows with you, or I will not be using Windows NOT with you". I didn't get an offer. I was cool with it.
They had Core. Base is their new attempt at sort of a "standard" lib. Not all OCaml-ers use JS libs though. There are some Batteries users out there. When I do Advent of Code, I almost always try to do it with OCaml's built in standard lib.
I have to disagree. I'm on record here lamenting Go. I've never really enjoyed writing it. When I've had to use it, I've used it. Lately though, I've found a lot more pleasure. And much of that comes from the fact that it does NOT have all these features. The code I write, is going to look like the code written by most other on my team. There's an idiomatic way to write Go, and it doesn't involve those concepts from other languages. (For better or for worse) So I'm super hyped that we'd have a "compiles TO Go" language, but I'm not as excited as using it as a catalyst to get new (and perhaps wrong for the language) features into Go.
I'm open to alternatives, but I haven't experienced any language constructs that strike as good of a balance between forcing you to handle errors/options when a function indicates it returns them, and allowing you to do so without too much ceremony. I don't think match is enough on it's own, but when combined with if-let/let-else/?-operator I don't feel like I'm sacrificing significant time and effort in dealing with Results/Options, so I'm not encouraged to cut corners and write worse code to avoid returning them in the first place.
The idiomatic way to write Go discourages you from robust error handling; return an opaque error, which callers will probably deal with as a string (or bubble-up as much as possible) because knowing its potential concrete types requires either reading source code or having documentation available (as the idiomatic function return type won't tell you anything about it). The path of least resistance only goes as far as forcing you to acknowledge there might be an error, it doesn't help you make good decisions about how to deal with it.
I think without also having to learn about lifetimes and dealing with async that this still presents an attractive trade-off for people who want to be quickly productive and don't care as much about garbage collection.
I agree with you. I’m not the biggest fan of Go and would personally love these features, but they’re very counter to Go’s purpose. These feel Rust-y to me.
Go was designed to be simple enough that developers can’t write code too complicated for others to read, with a particular eye towards junior devs (and ops/infra people, I think).
This usage of sigils for error handling and union return types is very cool and very expressive, but also going to confuse the shit out of your new devs or infra people. It’s just not a good fit for what Go wants to be.
I’m even sympathetic to the idea that generics are similar, though personally I think the alternative to generics is code generators, which are worse.
Anecdotally, I recently wrote some Go code at work (infra team) that used generics, and I had to look outside my team to even find someone that felt comfortable reviewing generic Go code. I see a fair bit of code using interface{} or any that would be much simpler and better with generics.
A lot of people said the same about generics, and some even still do. I could barely stand Go before generics, and still don't think they go far enough.
From my experience, things I think Go could really benefit from, like I believe it has benefited from generics:
* A way to implement new interfaces for existing types and type constraints for custom types, like `impl Trait for T`. This would obsolete most uses of reflection in the wild, in a way generics alone haven't. This isn't about syntax, it's about an entirely different way to associate methods to types, and with both Go and Rust being "data-oriented" languages, it's weird that Go is so limited in this particular regard. It has many other consequences when combined with generics, such as ...
* Ability to attach receiverless methods to types. Go concrete types may not need associated methods like "constructors", but generic types do, and there's no solution yet. You can provide factory functions everywhere and they infect the whole call graph (though this seems to be "idiomatic"), or make a special method that ignores its receiver and call that on a zero instance of the type, which is more hacky but closer to how free functions can be resolved by type. There's no reason this should be limited to constructors, that's just the easiest example to explain, in Rust associated methods are used for all kinds of things. Speaking of which...
* `cmp.Ordered` for custom types. Come on people. We shouldn't still have this much boilerplate to sort/min/max custom types, especially two full years after generics. The new `slices.SortFunc()` is the closest we've ever come, and it's still not associated with the type. We would basically get this for free if both of the above points were solved, but it's also possible we get something else entirely that solves only ordering and not e.g. construction or serialization.
* Enums, especially if the need for exhaustiveness checking could be balanced with Go's values of making code easy to evolve later. When I need them, I use the `interface Foo { isFoo() }` idiom and accept heap boxing overhead, but even the official `deadcode` analysis tool still to this day does not recognize this idiom or support enough configuration to force it to understand. The Go toolchain could at the very least recognize idioms people are using to work around Go's own limitations.
If we had solutions to these problems, I think most Go folks would find enough value in them that they would still be "Go". In fact, I think people would have an easier time consolidating on a new standard way to do things rather than each come up with their own separate workarounds for it.
This is where I feel "The code I write, is going to look like the code written by most other on my team" the least, because that's only true when a Go idiom has some official status, it's not nearly as true for workarounds that the Go team has not yet chosen to either endorse or obsolete.
> From my experience, things I think Go could really benefit from [...] Enums
Obviously it already benefits from enums.
type E int
const (
A E = iota
B
C
)
Which, once you get past the superficiality of syntax, is identical to, say, what you find in C.
enum E {
A,
B,
C
}
Enums are just a numbering mechanism, after all. No different than hand numbering constants, but without the need to put in the manual effort. Enums kind of suck, though. Are you sure any language actually benefits from them (as compared to better alternatives)?
> especially if the need for exhaustiveness checking
It is true that gc doesn't make any effort to determine how the enums are used, but if it were to it would be a warning like as is seen in many C compilers. As enums are values, not a type, it's not a fault to use them "inappropriately". While it may be all fine and dandy to add such warnings to gc, the Go team has taken a hard line stance that warnings have no place in the compiler. Of course, the external analysis tools like you speak to can still be used to provide these warnings for you. All the information you need is there.
But it seems what you really want is a more expressive type system – specifically sum types. Then you would be able to describe how you expect identifiers to be used without resorting to using generated number values as placeholders. Enums are just a hack to work around a limited type system anyway. If you are going to improve the type system in order to gain improved compilation constraint, you don't need enums anymore.
Rust doesn't have enums and nobody has ever noticed. Hell, many are even somehow convinced it has enums – but it does not. It provides tag-only unions (with, optionally, fully tagged unions) instead. Seemingly that is what you really want in Go as well. And fair enough. It is undeniably the better solution, but at the cost of being more complex to implement.
I've built POC apps with both this and Elysia recently. Elysia is really cool, it has a bit of its own ecosystem. Eden Treaty for example, is the way it handles backend to frontend type-safety. Hono on the other hand, seems like such a nice ExpressJS replacement. I wouldn't hesitate to ship either one.
This definitely kills the low-intent watcher. Twitch sends me daily emails to hop on and watch streamers that I follow. Every once in awhile, I'm not busy so I click the link, "Sure I'll watch that person write OCaml...". And 30 seconds in, I'm almost ALWAYS, "nah... I'm not into sitting here this long, I didn't even intend to be here".
If they could let someone watch like 3 to 5 minutes, they could likely increase engagement.
You'd think or hope they'd be tracking, A/B testing to see how this goes - and I wonder if incentives are perfectly aligned between Twitch's profits-costs and of the streamers they have to share ad revenues with?
It might also give worse insights on how you interpret the data. I'd imagine that those with huge followers/events will have most people grit through the ads. I myself do this when watching esports tournaments. I don't mind the pre-roll because I'll be there for 30+ minutes.
But as you and the other poster mentioned, that wouldn't necessarily be true for smaller streamers. In fact I share the sentiments posted elsewhere; where if you want to check out a smaller channel but don't want to waste 1.5 mins in ads. I'll just immediately bounce.
It's a doom cycle were those with popularity will always out compete smaller streamers. Smaller streamers get cannibalized by site's practices.
The only thing missing is a competitor but as we see from past competitor's streamers/viewers seem to be a very fickle bunch. They like the platform not the streamers, but the platform is now hostile.
If you do A/B testing you should be trying to control as many variables as possible.
It makes sense for twitch, given its skewed distribution, to compare the behaviour of users engaging with the different types of streamers.
Under this logic, I presume they might actually see that engagement is not substantially harmed for big time streamers while getting actually millions of views on their ads as opposed to engagement harmed for low viewership streamers who don't really give the platform much money anyway.
I think it's a flaw in your thinking to assume twitch might have the interests of small streamers in mind. They probably don't. Once a big streamer retires, another takes their place. The viewership remains.
The tracking is presumably extensive, but I would guess that the metrics are wrong. I would assume that Twich is optimizing for ad revenue, not engagement, entertainment, or utility.
It's a pretty classic case of a startup sacrificing profit for growth until they reach critical mass and move to maximizing profit. Twitch probably decided they were as big as they were going to get and are no longer focused on user growth.
Unfortunately, it's not likely to help with FOUC. Flash of unstyled content happens when CSS isn't parsed and applied before the DOM is loaded and displayed. Even if one applies classes directly to DOM elements, if the stylesheet is still loading, you're going to see that flash. The only way to deal with it, is block rendering until the styles are parsed. (put it in the HEAD of the doc, etc)
You can, and that is effectively doing something similar to putting a style tag in the head of your document. It'll block until the styles are parsed and applied. If you have a ton of styles, your Lighthouse score will suffer because your first contentful paint will take longer.
Well yeah if you want to avoid a flash of unstyled content then you have to wait for the browser to style the content. The main problem is the style duplication issue which someone else pointed out elsewhere in this thread.
The browser cache doesn't help on the first visit when the cache is empty, and the cache will also have to be invalidated whenever the component's CSS changes. And if the CSS file isn't cached then you also have to contend with the flash of unstyled content problem while the browser loads the CSS file. The Lit docs do a good job of explaining this: https://lit.dev/docs/components/styles/#external-stylesheet
This means that if you have the multiple instances of the same web component on the page, you need to duplicate the whole style tag in each (right?), which seems unwholesome.
I'd never thought of this but you're totally correct. The only way to encapsulate styles within a shadow dom is to create that style tag (or use the CSSOM to generate a CSSStyleSheet), but either way it's the same outcome. The styles themselves are copied to each individual instance. Yuck.
This is a great point. If you have many instances of a web component and those components have a lot of styles, you're better off hoisting your styles into the document head and styling those components using the css `::part()` pseudoselector.
That avoids duplication at the cost of an extra network request. The browser has to make a full network round trip to download the html page, find your link element, and then make another network round trip to fetch the linked css file.
When the CSS file is served from the same host and preloaded, the same connection is reused and multiplexed in HTTP/2, and subsequent requests are being served from browser cache.
HTTP2 multiplexing is great for issuing multiple requests within the same HTTP connection, so that you don't have to deal with the overhead of establishing separate connections for each resource that's being fetched, but that doesn't solve the problem I'm talking about. Link preloading is great for having the browser fetch resources in the background before you need them, but if you're server side rendering your components you presumably need those components to be styled immediately (otherwise why are you server side rendering them in the first place), so that also doesn't solve the problem I'm talking about.
What I'm saying is that if you inline your styles in a style tag (either in the shadow DOM or in the head of the document) then the browser doesn't have to make any additional requests at all, because the styling information is present in the initial document already.
If you don't inline your styles, then the browser has to make two separate requests if the cache is empty: one to fetch the document and figure out which additional resources need to be loaded, and then an additional request to actually download those resources. There's no HTTP protocol shenanigans or link preloading that can change the fact that packets are being transmitted from the browser to the server and back again twice. It's basically another formulation of the N + 1 query problem. Once the CSS file has been cached you only have N requests instead of N + 1, but then the cache has to be invalidated every time you update your styles so you're back to square one again. The documentation for Lit explicitly recommends avoiding external stylesheets for web components, because it can lead to a flash of unstyled content while the browser makes an additional request to load the external styles: https://lit.dev/docs/components/styles/#external-stylesheet
External CSS in `<link rel="stylesheet">` has been used since the beginning of CSS and they are render-blocking by default (see https://web.dev/articles/critical-rendering-path/render-bloc...), so as long as CSS is small and on the same server, it won't cause FOUC. On the other hand, putting all the CSS inline in `<style>` makes HTML document download the same style on each reload instead of from cache. The best from both worlds is to embed a lightweight basic CSS stylesheet inline and the rest in cache-able external CSS files. What I am proposing is not to use JS at all, just pure CSS + pure HTML out-of-order streaming (e.g. https://github.com/niutech/phooos), which is very performant.
The introduction of the shadow DOM API changed the semantics of the link element. If the link element is placed inside of the shadow DOM, then it's not render blocking and you will experience a flash of unstyled content. That's what the lit docs are referring to. I've mentioned this because you originally joined this comment chain with a comment about putting link elements inside the shadow DOM.
If you place the link element inside the head of your document, then it is render blocking, which means the browser has to make two round trips to the server if the CSS file isn't in the cache before it can render (one to download the HTML file, and then another after it discovers your link element, and has to download the corresponding CSS file).
> The best from both worlds is to embed a lightweight basic CSS stylesheet inline and the rest in cache-able external CSS files.
This is the absolute optimal way of doing it. You would have to analyze your styles to see which styles are applied to elements above the fold, then extract them and put them in an inline style tag. The rest of the styles would have to be downloaded via a link tag, but you'd have to place the link tag at the very end of the HTML body tag to prevent the browser from blocking as soon as it encounters the link element or alternatively use JavaScript to add the link element after the page has been rendered. There are tools to automate this for static sites [1], but doing this for dynamically generated HTML is kind of a pain, and I've found that browsers parse CSS so quickly that the overhead of just inlining it all is very low in many cases.
You have basically found the Reddit /r/technology contingency. Most stories I see there are laughing at a single man's failures. There's just a lot of hate. I wanted a Tesla because other friends and family let me ride in theirs. I liked the car. I also like Chick-fil-a Chicken, and Papa Johns Pizza. From time to time, I visit Hobby Lobby. If I did digging on EVERY CEO, and found things that I disagreed with, I'd likely have few places left to shop. Instead, I try to focus on the other "non-crazy" folks that work at these places.
When it comes to Tesla technology... it's actually really good.
I don't know anything about r/technology, but I do know that Musk has alienated his core customer base, and is continually making massive noise about politics, unlike most other CEOs. And even more stupidly, he is aligning with an anti-EV, anti-solar, anti-energy storage political faction in his attempt to alienate early adopters. Makes him seem extremely weak and self-hating.
And that's before all the bad decisions in the direction of the product over the past six years. Musk's made a great product far worse by being so involved and making boldly bad decisions left and right.
On macOS, the moment I fullscreen an app, it's taken out of that flow. So for so many years, I've had my terminal full screen on workspace 2. Meta+2 it in my muscle memory for "go to terminal".
reply