Not even in the tech world. Microsoft did more than its fair share of cutthroat business practices, but there are tech companies out there that are quite literally thriving on worker exploitation.
I hate recurse to authority, but after a markup slash programming language has been written by Don Knuth and a macro system for it has been developed by Leslie Lamport, maybe one should take some notes so as to why things were done in a certain way?
I actually think Typst should ignore the design of TeX and LaTeX more—and especially the well-meaning advice of LaTeX veterans who have only ever known one way of typesetting.
The situation reminds me of how Julia’s evolution was guided in some aspects by some opinionated and vocal {Python, R, MATLAB} developers who never had any intention of transitioning to Julia, whether or not their advice was implemented.
I was not implying they should make the same design choices, but there should be a deeper understanding of the underlying problems.
Case in point: backslashes and braces in TeX were there for a reason. You can say they make TeX code look ugly, and you would not be wrong. But when you throw them away without addressing the reason they were introduced, well, you end up with blog posts like this one.
The backslashes are not really relevant to the problem discussed in the post. The ambiguity between symbols and argument-taking macros exists just the same in LaTeX. Consider:
$ f_\abs{x} $
$ f_\pi{x} $
LaTeX just happens to do what the post calls "runtime parsing" because LaTeX doesn't really distinguish between different compiler stages at all. If you look at a macro, you can't know whether it will eat up the following braced argument.
In fact, not using backslashes for symbols can actually give an _edge_ with this problem because it would allow distinguishing `pi` and `#abs` (option E in the post).
This seems like a counter-example. The `=` was for time the only syntax (presumably taken by MATLAB--which in turn adapted it from IDL/Fortran--that initially Julia was heavily influenced from) with `in` (and `∈`) added afterwards (`in` being the only syntax used by the much more popular {Python, R}). Imo `=` alone was fine since as you say `=` means assignment, just within `for` it's an assignment applied iteratively. Opposite to that, `in` is also used as membership operator (`1 in [1, 2, 3]`) that is entirely different from its `for` role.
They're not infailable, though. For example, TeX's primitive for fractions is actually {a \over b}, LaTeX's \frac is a macro on top of that. The consequence is that while typesetting a formula, the engine does not know the current text size, since an \over further down the line may put the entire thing into a numerator. Dealing with this can be quite a pain when writing math macros.
Still, it is technically correct. The model produces a next-token likelihood distribution, then you apply a sampling strategy to produce a sequence of tokens.
Depends on your definition of the model. Most people would be pretty upset with the usual LLM providers if they drastically changed the sampling strategy for the worse and claimed to not have changed the model at all.
Sure, but they went slightly overboard with that headline and they knew it. But oh well, they have a lot of eyes and discussion on their paper so it's a success.
I feel like, if the feedback to your paper is "this is over-done / they claim more than they prove / it's kinda hype-ish" you're going to get less references in future papers.
That would seem to be counter to the "impact" goal for research.
Fair enough, that might be more my personal opinion instead of sound advice for successful research. Also I understand that you have a very limited amount of time to get your research noticed in this topic. Who knows if it's relevant two years down the line.
LLM providers are in the stone age with sampling today and it's on purpose because better sampling algorithms make the diversity of synthetic generated data too high, thus meaning your model is especially vulnerable to distillation attacks.
This is why we use top_p/top_k on the big 3 closed source models despite min_p and far better LLM sampling algorithms existing since 2023 (or in TFS case, since 2019)
So, scientists came up with a very specific term for a very specific function, its meaning got twisted by commercial actors and the general public, and it's now the scientists' fault if they keep using it in the original, very specific sense?
I agree it is technically correct, but I still think it is the research paper equivalent of clickbait (and considering enough people misunderstood this for them to issue a semi-retraction that seems reasonable)
I disagree. Within the research community (which is the target of the paper), that title means something very precise and not at all clickbaity. It's irrelevant that the rest of the Internet has an inaccurate notion of "model" and other very specific terms.
In a field with as much public visibility as this one it is naive to only think of the academic target audience, especially when choosing a title like this. As a researcher you are responsible for communicating your findings both to other experts and to outsiders, and that includes choosing appropriate titles. (Though i think we fundamentally disagree about the role of researchers here)
It's like writing a title that says "drinking only 200ml of water a day leads to weight loss" which is technically true, but misleading.
THAT is the source for the bloat? Oh dear. Absolutely shambolic. It is embarrassing that iOS gives no way to just completely nuke an app's cache, short of reinstalling the app.
I know they do, but the effectiveness of these "clear data" settings varies wildly and it's mildly infuriating. For instance, in my experience Telegram's works pretty well, X's not at all.
I dunno about the situation with the languages of Italy, from a cursory glance at Wikipedia it seems a _lot_ more complicated than Frysian/Dutch in NL, so I really don't think it's anything "like saying" that.
But "official" means exactly what it means, and when I'm saying "Frysian is an official language of the Netherlands", it means that it's recognized as an official language of Netherlands, by the Dutch government. And if it was up to the provinces I dunno, but it's not. Frysian is the one that's considered one of the official languages of the Netherlands.
I also don't think comparing to Italy makes sense at all because countries are different and decide what are their official languages for very different historical reasons. For instance you can look up what Dutch government body is responsible for deciding the Frysian language is an official one in the Netherlands and why, and you will very likely find no Italian equivalent of that.
It's not really that difficult, an official language OF a country is recognized at a national level. Thus all official government communication must be issued in that language. In the Netherlands, only Dutch has that level of recognition. Same in Italy for Italian
Then there are other, regionally-rocognized language that local governments use alongside the national one (West Frysian in Friesland, German in South Tyrol, etc.), and may even enjoy a majority of speakers within those regions, but they are not "an official language OF" the wider country.
I think it's the other way around. I agree that NextCloud is overkill for personal use, but it does feature a ton of bell and whistles that become useful at larger scales.
> Governments don’t have that much software integration to do
...What? Most European governments rely on herds and herds of pachidermic, segregated software systems and databases. There's surely enough to keep a whole team busy for years, if not decades. And I'd be surprised if the final costs would be higher than hiring consultants again and again.
You are mistaking technical issues and organisational issues.
Projects are driven by business requirements and values not a desire to share more or rationalise. Segregation is more often a matter of governance and processes.
That's not things you will solve using a bunch of developers. This discussion makes me realise that most of the people commenting on HN probably work for software companies and have very little experience of how big projects, be them IT or organisational, are conducted in traditional companies and what are the challenges they face.
Well of course going towards integration vs segregation is an organizational (in this case, political) decision. I was saying that the average EU state machinery has a lot of room for integration, should there be a political intention to go that way.
Case in point: in Italy, different towns used to have different systems for their resident registrations. I doubt there was an extreme need for customization in this context, it was just that bigger/wealthier towns had a chance to digitize earlier and so on, leading to extreme fragmentation. Moving to a nationwide register took literally a dozen years or so, for a single service of a single country.
It's not like a white male cannot get mentored in Python by anybody. By 2019 Python was already one of the most popular languages in the world. Surely any dev on Earth who wants to learn Python has plenty of people and resources at their disposal, and it would take a very good set of reason to turn to the language inventor himself.
I agree that DEI often acts as a fig leave over a whole bunch of other systemic issues, and the European vs American cultural and historical landscapes are already so different as to make any cross-the-pound discussion on DEI extremely hard to navigate, but I still commend the PSF for not taking clearly ideological orders from a funding body. That road would have lead to nothing but trouble.
There are plenty of smartphone companies locking down their bootloaders, but there are others that will let you unlock your bootloader by just running the basic command.
A much bigger problem for running Linux on phones is that standard Linux runs like crap on phones. It doesn't have the mainline driver support amd64 computers have, and the battery life optimizations that make Android usable need to be reimplemented on top of Linux to get a day's worth of use out of your phone. Unfortunately, most Linux applications are written for desktops where they expect the CPU to be running all the time, the WiFi to be accessible whenever they want, and for sleep/suspend to be extremely incidental rather than every two minutes.
