This is neat. I've used Latex before, and it definitely suffers from poor ergonomics. Both the language and tooling contribute to this.
The selling point seems to be that this is more similar to Markdown. That makes sense, Markdown is objectively more common and has more users than Latex. I've used both, but Markdown way more often.
Here's something I don't understand: it would be trivial to make Typst even more similar to Markdown, and yet it exists at some strange middle point in the language design space, arbitrarily far from Markdown.
Well maybe it’s good to make it clear that it isn’t markdown to avoid confusion? Also Typst has less syntactic sugar which also has benefits.
More generally, I am really impressed by Typst’s abstractions. I have typset my whole PhD thesis in it without needing any external packages. It was so easy to use the basic building blocks and write a few extra functions for the rest.
The plots were all created with Makie.jl [1] and lots of fiddling and manually writing code to get things right. Although I think Makie is great, I guess it would also be possible with other plotting libraries.
Places I’ve switched from LaTeX to Typst: My resume, research papers. Markdown was never a serious contender for my resume, since I want to control the rendering and the layout.
Places I’ve switched from Markdown to Typst: Slides. There are some okay Markdown-to-HTML solutions, but they have this unfortunate side-effect that you move the slides to some other computer, and something breaks in your rendering. PDFs ftw.
Perhaps you can use pandoc to turn Typst into Latex and then do the little dance of making it compatible with the provided headers?
[ The latter is painful no matter what; once, I had a paper that I simply could not get to compile with the journal's header and had to give it to a wizard for examination. He did some manual TeX shenanigans resulting in a big blob of raw TeX at the preamble and it all worked. ]
the pandoc typst reader is a bit barebones, it doesn’t support packages (understandable) and seems to get confused with functions for me…though it’s been a bit since i tried it
I'm not sure the selling point is similarity with markdown, but rather, to improve, or modernize LaTeX/TeX-the-language/s: TeX is really archaic: if you're curious, there's a series of articles by overleaf[0] detailing some of TeX's inner-working, quite insightful.
I remember reading — but can't find a source at the moment — that TeX originally didn't had counters; people came to rely on Church numerals[1] instead, before Knuth finally implemented them.
It may be similar to Markdown if you squint your eyes real hard, but it's not Markdown.
Furthermore, quoting a random snippet without any elaboration is unhelpful and only serves to confuse people (as it already did for the other comment!)
# means "evaluate". figure(...) is the function being evaluated.
The syntax inside figure(...) is fairly regular, not too different from what you'd see in typical programming languages (but with a document-oriented twist like the %).
<figure> may seem to be related syntatically to #figure(...), but it's not. It's just a label. Like an HTML div tag with id="figure". It can very well be changed to <foo> in your example and it'd still work.
These 6 lines actually put me off. Probably I have to read more about Typst syntax but, same for me, consistent syntax which covers necessary complexity wins over bending a markup language for purposes for which it was never intended.
It’s best not to think of it as a markup language. It’s a programming language designed around the needs of outputting pdfs.
Structurally it’s like a modern, nice version of php, only it’s built for academic articles rather than emitting websites.
The code snippet there packs in about 8 typst concepts all at once. It’s like if someone showed off how “simple” c++ is by showing some template-heavy magic. It’s straightforward once you’ve spent time with the language, but it’s a pretty terrible place to start learning typst. (That example shows expression mode, block mode, function calling, tags, named arguments, and probably more. Whew!)
That is a great analogy.
When I wrote my note/hws in latex, I had the urge to go look for a package more frequently. When I started converting those docs into typst, I was able to hack around more easily, it really did feel like a modern programming language that has great error messages and that I enjoyed writing in.
It did not feel complex, especially with the help of compiler errors messages
It's a little odd at first. I would recommend reading through the tutorial (which is quite good) and you might start to see some of the method to the madness.
It's not a tag, there aren't even HTML/XML tags in Typst. The effect of that <figure> is giving the #figure(...) element the label `figure` (i.e. the name is what's inside the <>). Probably using the label "figure" was not the best choice for an example, something like <my_figure> would have been a bit less confusing showing that it is an arbitrary name/id that you choose.
Edit: and I think you also misinterpreted the other comment about the <div>. It wasn't about using <div> in place of <figure>, but rather that using <figure> in typst does the same thing as id="figure" in HTML.
Personally, I don't really care about it being similar to Markdown. After all if someone wants Markdown they can just use that... For me the selling point is that it provides almost the same features as Latex except with a sane scripting language. This allows me to actually write my own scripts, as opposed to Latex where even understanding how basic stuff worked was a huge pain.
As a side note, TeX engine could support Markdown or HTML or many other syntaxes too: it's easy to redefine control character in TeX to be anything instead or in addition to "\" (I've actually done that with Plain TeX a couple decades earlier to allow two-byte UTF-8 input by making all first-bytes of valid 2-byte UTF-8 sequences into control characters).
So, LaTeX being "unergonomic" is only relative — it's pretty ergonomic compared to things like HTML but especially DocBook or TEI SGML/XML schemas, but less ergonomic than Markdown or even Plain TeX. However, it inherits the most complex part where it is extremely ergonomic from Plain TeX (for the most part): editing math formulae.
But it's also much richer in expressing intent than any of those, and from what I can see, compared to Typst as well — LaTeX is basically semantic markup for excellent printed output (where Plain TeX is excellent printed output with no semantics, DocBook/TEI are pure semantic markup, and HTML/Markdown/Typst are somewhere in the middle too).
Could you give an example of how it could be more similar to Markdown? I recently used Typst for my bachelor's project and never really thought that it needed to be simpler
You are describing the best kind of manager for two reasons:
1. They understand what their reports do, can mentor the less experienced ones, and are a competent peer to the more experienced ones, rather than an obstacle.
2. If they turn out to be bad managers, there is a low stakes, no hard feelings, path for them to go back to being an IC. There is a huge aversion to firing people, so bad managers who can't do anything else tend to stay around creating problems much longer than bad managers who can also contribute.
Your presentation of "experience" and "preparation" as the most important things for a manager is typical gatekeeping that we see from the bureaucratic class--parasites without any real skills.
Strange that you’d say that. What I’ve seen is that promoting homegrown ICs to line management is a favored strategy of nontechnical MBAs in upper management. Any large organization is bureaucratic. Given the intensely bureaucratic record of communist governments, your invocation of Marxist rhetoric here is frankly laughable.
What promoting inexperienced managers from within does is place them at a tremendous informational disadvantage. Never having worked anywhere else, they don’t understand the coded language of bureaucracy and they have no perspective on what constitutes normal behavior. This gives the MBA latitude to abuse them as pawns in organizational power games they don’t understand, until they either burn out or wise up.
> he used the word "class", let me find Marxism in my dialogue tree.
If you were unaware of the term "bureaucratic class", it's not a pro-marxist shibboleth. It refers to the population of aging white collar workers without useful skills, usually in management positions. They can be found parasitizing most large companies. If their incompetence could be reliably detected, it would trigger a massive unemployment crisis. They are often unwilling or unable to learn new skills; the productive skills that originally got them in the door have atrophied or become irrelevant.
Any organization as dysfunctional as you describe isn't going to be meaningfully affected by choice of managers. If politics are that prevalent, then the company is coasting on laurels, and it's not really about getting anything done to expand the pie. It's about in-fighting over the predictable, fixed-sized pie that comes in every quarter.
"bourgeoisie" refers to the capitalist class. Made more rigorous, we can say the set of people who do not need employment to pay their bills, they can live off of investment income. They often still perform labor, but as a part of their own businesses.
The bureaucratic class depend heavily on employment income. They are very lucky to have their jobs, and could be easily replaced or eliminated. They are desperate to maintain the structure of the bureaucracy in which they thrive. They create a cost born by both the "working class" and the "capitalist class". They consume the resources of the capitalist class, and mis-allocate the labor of the working class. If the investors and employees could coordinate without them, more value would be created for the capitalist and more wages could be kept by the worker.
The best advice (organizationally) is to just do everything in a single transaction on top of Postgres or MySQL for as long as possible. This produces no cognitive overhead for the developers.
Sometimes that doesn't deliver enough performance and you need to involve another datastore (or the same datastore across multiple transactions). At that point eventual consistency is a good strategy, much less complicated than distributed transactions. This adds a significant tax to all of your work though. Now everyone has to think through all the states, and additionally design a background process to drive the eventual consistency. Do you have a process in place to ensure all your developers are getting this right for every feature? Did you answer code review? Are you sure there's always enough time to re-do the implementation, and you'll never be forced to merge inconsistent "good enough" behavior?
And the worst option (organizationally) is distributed transactions, which basically means a small group of talented engineers can't work on other things and need to be consulted for every new service and most new features and maintain the clients and server for the thumbs up/down system.
If you make it hard to do stuff, then people will either 1. do less stuff, or 2. do the same amount of stuff, but badly.
Attempts to arrive at an objective notion of good are always motivated by a desire to extract rents from the group. Got 'em with the ole "greater good" trick.
Clearly the problem in all of this is that these markets are rigged. Imagine if the most knowledgeable investors were banned from trading stocks, or had artificially low bankrolls. It wouldn't be practical for individuals to invest in the market because everyone would assume they were getting ripped off, and the price was totally separated from the value of the business.
The fact that the most successful investors have the largest effect on the price is exactly what makes the market fair. A layman can login to manage their 401k, put in a market order, and know they are getting a fair price because many people, much more knowledgeable than the layman, are competing to set the price.
The difference between a betting company the stock market is that in the stock market you have regulation to separate the exchange from the market maker. So in the stock market you go to the exchange, you buy or sell at the market price (or place an offer in the book) the exchange takes a commission but you're trading with a 3rd party. In the gambling world that generally doesn't happen, the exchange and the market maker generally are the same person - and there's good reason for that, if you can do it it's a better business model.
But either way, the same effect occurs. The sharks in the stock market profit from making good trades and in order to account for that the market makers have to quote a wider spread in the book, which effectively means the retail trader pays a larger spread. The net effect is money transfer from the retail trader to the smart trader. Would it be better for the market maker to just refuse to trade with the smart trader and then give the retail investor a better spread? Welcome to payment for order flow. Could a smart investor pretend to be a retail trader and get some good trades through Robinhood? Maybe, that's pretty analagous to what these guys are doing.
These are different mechanisms for the same thing but I'm not certain one is clearly morally superior.
> I suppose there's some noise in any voting system, and it's fine if the magnitude is small and its distribution random.
This is the right answer. It's amazing how many people insist that elections have absolutely no fraud or other sources of error. In most elections throughout the world, it's apes counting paper with their squishy hands and blurry eyeballs. It's remarkable that we even get 3 significant figures reliably.
It's not unbiased noise though. People with the highest likelihood to die soon (elderly men) have different voting preferences than the general public.
I'm not sure I'm thinking about this correctly, but I'm not sure that it's relevant that elderly men die younger than elderly women. I think it would only be a bias is they were dying at a faster rate, relative to their population size, than other groups. That is, the size of the elderly male population was shrinking compared with the elderly female population.
The biggest argument in favor of sports betting is that it's a prediction market.
Prediction markets are the best way we know of to synthesize the opinions of many parties. They should be protected as a class of economic free speech, but in the US there is an effort to eliminate prediction markets on the most important issues (like the outcome of an election).
Think about what it implies for the government to be against a kind of organized assembly that causes citizens to become more informed and allows individuals to de-risk the outcome of events.
> As with prior layoffs, or "resource actions" to use IBM's euphemism, we're told those affected are substantially in the 50-55 age bracket with 20-24 years of seniority.
> Despite numerous past and ongoing age discrimination lawsuits, IBM maintains it does not systematically discriminate on the basis of age.
Lawsuits of this sort are a little ridiculous. If you work at a company that pays people more just for being older, then you shouldn't be surprised when the "more experienced" people are the first to get laid off.
It's crazy that anyone could believe a corporation cares about anything other than profits.
If IBM actually had the ages of their employees available to the system that did the layoffs, then that would be age based discrimination. But I'd be willing to bet that wasn't a factor.
If you start with a pool of people with large salaries, and look for people not adding at least that much value to the business, you are going to find people who have that salary for reasons other than merit.
The discrimination, if any, was in their favor until the business couldn't afford to discriminate in their favor.
Discrimination doesn't have to be so explicit. Saying "I'm going to fire everyone over 50" is obviously discrimination, but so is "I'm going to fire everyone near the top of the salary range for their job family". It has the same impact, but it's discrimination is cloaked behind a layer of misdirection. The law isn't so blind
Depends on the company, but even in ones that do, it's usually new hires are paid on the higher end of the band.
That means a junior engineer hired yesterday makes more than a junior engineer hired two years ago, but it doesn't mean that the junior engineer hired yesterday makes more than the staff engineer hired a decade ago
IBM today is mostly a service provider - with those in the 50+ age bracket being "kicked out" there will be at least 2 groups:
(1)The ones with skills "to keep the lights on" for these services - those will be hired back as "consultants" - let's hope at twice the daily rate they worked before if they want to continue to work.
(2) The others - for them, the tax payers will pick up some of the balance, but generally, it will be dire for them to find new ways to continue.
Overall, age discrimination is a topic on which most companies and the public are mostly in denial while trying to please everybody else or demonstrate how inclusive they are.
Within many industries you will be excluded "quietly" during the selection for up to mid-level jobs when you are 50+ - quietly, because companies know that such discrimination openly could result in reputational or potential legal challenges.
On exec jobs, it is even more ludicrous - people who are much older than the candidates, block (competent) 50+ candidates based on their age to become their peers.
At the same time, often these companies also do not promote staff above a certain age e.g. when taking on new responsibilities that gets all others promoted (aka substantial pay rise / cost). As a result, while in a few countries here in Europe, 50+ workforce will have more holidays or pension contributions, the salaries of 50+ high achievers might be lower than younger staff in comparable roles. Give the above, some swallow that pill, but those that can afford leave (independent of age the old saying: good people leave, wood stays). Might not apply to most of the 50+ workforce, others might just have better employment contracts (historically), e.g. in the German car factories you have people on payroll with the company, some as contractors through 3rd party, and at the end of the food chain some with a low paid contract for work and labour with a body shop - all doing the same work at very different pay for the workers. In such setups, getting rid of the older workers might result in a higher bonus for top management, achieving KPIs for middle management, and certainly in high consultancy fees for restructuring advice from McKinsey e.a at daily rates per (senior) consultant at about the monthly salary of the worker made redundant - after these "cost" making younger or older workforce redundant becomes a marginal difference.
Overall, from what I've seen, where competence is key and valued, age and other things will not be used to discriminate the best candidates or staff. I've seen 70+ old engineers being hired by top-names for their knowledge, experience and achievements.
With aging societies in many western countries, TMK, in about 5 years the majority of the workforce will be 50+ in most of them.
In the west, during the last 40 years we have shifted from "engineering pride" to prioritising financial markets vs innovations & products. This has certainly created many activities, tasks /jobs particularly in large orgs, that will become "redundant" when the music stops or when some of these orgs fade away due to lack of product, market, leadership or competencies.
We need to look into how our "established" companies stay or become competitive and innovative again with their products and services in a global environment short / mid and long term vs. making most of their money on financial markets. Such companies don't need to care about the age of their staff - they care about skills and competencies.
With the baby boomers leaving the job market, low-birth groups / demographic change of those entering the job market plus technology advances there is now a chance that this puts pressure on companies (and employees) to re-invent themselves.
> wouldn't be a bug if everything was happening exactly according to expectations
This isn't quite true, especially concerning distributed systems. It's relatively common for a software system to be broken by design. It's not that the developer didn't know how to use the programming language to get the computer to do what they want. It's that what the developer wanted reflects a poor model of the world, a logical inconsistency, or just a behavior which is confusing to users.
Keep in mind I said that this is advice I give junior engineers specifically; they shouldn't be the ones responsible for designing distributed systems in the first place. For someone in that part of their career, this advice is meant to help to learn the skills the need to solve the problems they're dealing with, and it's not intended to be universal to all circumstances, just a useful thing to keep i mind.
"a poor model of the world, a logical inconsistency, or just a behavior which is confusing to users"
I expect when I pull from the queue (but it was designed non-atomically) that I will be guaranteed to only grab the item once and only once, even after a failure. That expectation is wrong, but the developer may have implemented their intent perfectly, they just didn't understand that there are error cases they didn't account for.
They are routinely administered in hospitals and for recovering from most traumatic injuries. For people who frame the use as episodic e.g. "until my leg heals" and try to get back to their lives as quickly as possible, there is rarely a problem.
For some people the drugs are better than the life they had before and so getting off them is very difficult.
They are a poor choice for chronic pain, since that population doesn't have particularly high life satisfaction. But they are an excellent choice for acute pain e.g post surgery, tooth extraction, etc. and people shouldn't be afraid of taking them in that context.
The epidemic you have heard about in the US is incentivized malpractice. Doctors giving a class of drugs which should not be used habitually to people with shitty lives.
The selling point seems to be that this is more similar to Markdown. That makes sense, Markdown is objectively more common and has more users than Latex. I've used both, but Markdown way more often.
Here's something I don't understand: it would be trivial to make Typst even more similar to Markdown, and yet it exists at some strange middle point in the language design space, arbitrarily far from Markdown.
reply