swift

Regular expressions are part of the language, so it's not so unreasonable that TypeScript should parse them and take their semantics into account. Indeed, TypeScript 5.5 will include new support for syntax checking of regular expressions[1], and presumably they'll eventually be able to solve the problem the GP highlighted on top of those foundations.

[1]: https://github.com/microsoft/TypeScript/pull/55600

I agree with a lot of your comments, but just FYI, you can do a couple of those things:

> (I can't even compile FOSS apps on my own without owning a mac + 100$/year dev licence - this is a real shit show for me!)

You do need a Mac, but you can build FOSS apps and deploy them to your own iPhone, iPad, or Apple TV with a free developer account. You only need the paid license to distribute them to others.

> Finally I have a device that could replace things like a Wacom Tablet connected to your computer but that opportunity was missed.

There have been apps that support this for a while, but this is now a built-in iOS/macOS feature called "Sidecar".

There are definite tradeoffs here, but one thing to consider is that dev tooling generally can't benefit from that kind of massively distributed parallelism. If you make a change to a widely-included header file, code intelligence tools suddenly have to do a huge amount of work to reevaluate their internal model of all affected translation units. This can really result in an unpleasant and laggy editing experience, even on medium-sized projects. That's the kind of thing that modules can help with; I certainly wished fervently that they were already a thing when I used to work on C++ static analysis tools years ago.

FWIW, Bison (which I'd expect most people are using rather than the original yacc, though I can't be sure) does support GLR parsing.

I haven't seen GLR used in production either, but my experience with projects I've been involved in is that this is sometimes just due to inertia. Taking full advantage of GLR's support for ambiguity requires reworking both your grammar and your early stages of semantic analysis, and even if people agree that the result might be nicer, nobody has the time or motivation to do all that work.

PEG uses ordered choice instead of alternation; all PEGs are thus deterministic. The article's description of PEG is so off-base that it makes me question the entire article.

The compression MP4 (or any other modern video format) offers is much better than what you can obtain with GIF. MP4s are, perhaps surprisingly, actually the better choice in terms of bandwidth and load time.

The hypothesis that life on Earth originated elsewhere is somewhat independent of abiogenesis, really. At least in my experience, most supporters of the former also support the latter.

2 works on macOS too, for what it’s worth. (My memory of this, which may not be entirely reliable, is that Linux and OS X both had 2 forever. I wish I could say the same for 1.)

There’s definitely a schism along the fault lines you describe. If you’re not familiar with the concept of a “TERF”, look it up.

I’m probably making a mistake here by commenting before reading the article, but I’ve seen many cases where issues with food prices and food supply have been diagnosed as long term effects of food aid or cheap imported food. What can happen is that local farmers go out of business or stop growing staple crops because prices collapse. When conditions change and the food aid stops or the price of imported food rises, there aren’t enough local farmers left to feed everyone. That will obviously cause food prices to go through the roof. It’s always something that has to be considered when planning aid to a country.

It’s generally a bad and dangerous idea, especially for someone who is schizophrenic, but antipsychotics can have very serious side effects, and I think it’s painting with a brush that’s a bit too broad to suggest that someone would only stop taking them for “some psychotic reason”. People who take these medications are often facing some very difficult trade offs.

People misunderstand this stuff in part because of the failure to make a distinction between a theory (which is often a mathematical description of a system, though this depends on the discipline) and an interpretation (which really is an idea in someone’s head, though often one we have good reason to believe). Scientists mostly work with the former day-to-day, but the general public is mostly interested in the latter.

Usually this distinction isn’t really a big deal, but in some cases - quantum mechanics, for example - there’s a big difference between the two, with multiple interesting interpretations to consider.

When we don’t make this distinction it creates an opening for people with poor understanding (or, occasionally, bad motives) to nitpick extremely well-established theories on the basis of quibbling about interpretation. I worry about this with respect to climate change specifically: deniers come up with a million reasons that climate change may be partially natural, or that this or that industry may be unfairly maligned, but we can’t get sucked into those debates so much that we forget the big picture painted by the data and models we have.

I’d argue that you have to get pretty deep into experimental GHC language extensions to get into anything as weird as some of the SFINAE-based template metaprogramming tricks I’ve seen (and used, sadly) in C++.

It’s probably hard to see it this way when you’re starting out (and you may need a certain personality type as well =) but for me, programming in Haskell is a genuine pleasure because it’s so easy to express yourself in it. Things that require a huge amount of code in other languages are effortless and elegant in Haskell, and the compiler is extremely effective at finding mistakes in your code and often even your design, so you start treating it as a partner that helps you write your program. The experience always puts a smile on my face. YMMV, of course.

I do suspect that in the near term Idris may overtake Haskell as my favorite language to program in, though. I haven’t had a chance to sit down and learn it yet, but everything I’ve read about it so far has left me very excited.

This is genuinely good advice.

I'm a bit surprised that so many commenters here are reacting to the second paragraph as if it described an extreme lifestyle that would inevitably lead to ruin, or as if you need to make a choice between having these kinds of experiences and being a successful, fulfilled adult later in life. Neither of those things are true.

Here's what I believe the parent post is saying, but stated differently: try all the things that life has to offer, and get outside your comfort zone. Let yourself make mistakes. Explore. Try to connect with many different kinds of people, especially people who aren't like you. Push the boundaries a little. When you find something you're passionate about, dive in, but be sure to come up for air regularly and enjoy the simple pleasures of life.

Don't let the anxieties or negativity of others stop you. If you do those things, I promise you you won't regret it.

I will say this for C++: post C++11, it’s one of the few languages in widespread use to have an explicitly defined memory model. The people working on C++ definitely do care about concurrency and parallelism. I’d still choose Rust over C++ for that kind of program any time I was given the choice, though. =)

That's not accurate. I keep my iPhones for two years, and when I upgrade I give them to family members who have always gotten another 2-3 years of use out of them. (And Apple has continued to support them during that time with software updates.)

It's actually one of the main things that keeps me in the iPhone ecosystem.

There are options other than "tough laws" for helping communities struggling with high rates of addiction.

Your breakdown of this situation makes it sound like you think it doesn't matter what you do, because someone will call you a racist no matter what. In other words, that accusations of racism are totally arbitrary. That's not true.

An even better question is "faster by what metric?". Once it has been running for a while and the JIT has done its work, it can definitely happen that a Java program will outperform an equivalent C++ program because of the JIT's improved knowledge of the whole program and the dynamic execution environment. C++ can gain much of the same benefit with LTO and PGO, but it's definitely not trivial (particularly PGO) and there's not really a slam dunk win for C++.

Now if the metric is startup time, that's a different story. (Though I believe there's been a lot of work on hybrid AOT/JIT since I left the world of managed languages, so maybe things are better now.)

Can you clarify what makes you say that the EPA is "so large that it is no longer effective"? Everything I've heard about the situation inside the EPA makes it sound more like they're desperately short on staff and funding and they're doing the best that they can within those limitations. The problem isn't lack of focus; it's lack of resources.

It's not as if the EPA has been growing unchecked; conservative politicians have been doing their best to gut its funding or render it toothless for decades now, going back at least as far as Reagan. If you're not happy with the current situation, it seems unlikely that continuing down the path of defunding the EPA will improve it.

I'm not 100% sure what's meant by "native" method in this context, but if you're programming for macOS/iOS, try Grand Central Dispatch. It's a very nice task parallelism library with some extremely smart design choices.

macOS already does present a list of apps that are using a lot of energy if you click on the battery indicator. I thought that Windows had a similar feature, but I'm not sure.

This is true ideally, but there are several factors which make it not always true in practice.

(1) Often your grammar admits inputs which are not in your language. Less often, it forbids some inputs which are actually valid. This is usually because an accurate grammar would be extremely complex to write and inefficient to parse using a generic algorithm. Languages which combine a context-free grammar with parsing decisions based on semantic information fall into this category (think C++); the "true" grammar would usually be context sensitive and quite hard to work with.

(2) You are sometimes compiling a layered language. Again, consider C++. The program you're compiling is generally actually written in the C preprocessor language! Conceptually, it's translated to C++, and then the C++ code is compiled in a separate phase. In practice, that layering will make it difficult to produce good error messages, and a formal grammar for the combined language would be a mess to say the least.

(3) The structure of the grammar may just be awkward for producing good error messages, and refactoring it to eliminate the problem may not be possible, or it may only be possible by making problem (1) even worse.

In general, the decision of what goes in the lexer, what goes in the grammar, what is handled in semantic actions, and what is dealt with at a later semantic layer is always a trade off. Each layer has different characteristics in terms of computational power, performance, static analyzability, programming flexibility, composability, modularity, and maintainability. It doesn't make sense to insist that you solve all problems at one particular layer. You look at the problem you need to solve and decide how it'll be partitioned between these different layers to maximally benefit from their strengths and minimize their weaknesses.

That's engineering.

This is a problem for a lot of languages, unfortunately, and it breaks the clean separation between syntax and semantics that we're hoping for when we write a formal grammar.

I've had some success in the past with using GLR or another algorithm that can handle ambiguity, and then choosing among the possible parse trees in another pass that takes semantic information into account. How applicable that is really depends on the language, though; if things are so ambiguous that you're getting an exponential growth in possible parse trees, you may not want to use this approach.

The question of shared state vs. message passing is orthogonal to processes vs. threads. Both techniques can be and are commonly used in both situations.

Sometimes a monotree is the only way. If your business model revolves around an open source core with some proprietary add-ons for paying customers, it's often not possible to merge those codebases into a single repo.

I use my Bluetooth earbuds and headphones to listen to music and podcasts on my phone, my tablet, and my laptop, and to connect to my TV to watch movies or play games late at night when my roommate is sleeping. I use them at the gym, where having a cable get in the way could be a problem. I also use them to make phone calls when my hands are occupied. They work wonderfully for all these uses. I'd say that covers a lot of peoples' needs, though it sounds like it may not cover yours.

I second this. I've been using Bluetooth headphones and earbuds for years and I was shocked at how well the AirPods worked. Zero dropouts.

If you're into higher-end headphones, I can heartily recommend the B&W P7 Wireless. Fantastic sound and the Bluetooth has been extremely stable for me. And they have a wired port as well, so if you want to go that route at any time they still have you covered.

The feature I'd be most interested in here is the integration with git, but I don't see an example on the site that demonstrates that. If the author is reading this, could you please add one? (Or maybe point it out, if I'm just missing it?)

It's more actionable than you might think. Attitudes can be changed - by social pressure, through the media, and through education. And while legislation may not directly change attitudes, it can also help create pressures that reshape them indirectly.