> Performance notice: values of type int64 occupy more memory space than values of type int
I just couldn't even imagine that a 64-bit int would require MORE memory than an int that is one bit less (or 33 bits less if on a 32-bit architecture).
It really makes absolutely no sense discussing OCaml as a possible systems-level programming language.
bruh, it's just saying single scalar Int64 types are boxed. This is totally normal thing that happens in garbage collected languages. There's no semantic loss.
OCaml does this 63-bit hack to make integers fast in the statistically common case where people don't count to 2^64 with them. The top bit is reserved to tell the GC whether it manages the lifetime of that value or not.
For interoperating with binary interfaces you can just say `open Int64` at the top of your file and get semantic compatibility. The largest industrial user of OCaml is quant finance shop that binds all kinds of kernel level drivers with it.
(and yes, 64-bit non-boxed array types exist as well if you're worried about the boxing overhead)
> just involves lecturing about the same material over and over again
It doesn't, specifically not in primary education. Also definitely not for subjects with any kind of amount of practical work. Let's see.. foreign languages, sports, physics, chemistry, biology...
Which part of these relevant quotes understand? Or perhaps have counter-arguments?
> shows how low our appreciation of pedagogues has fallen
> Dropout rates for these classes hovered around 90 percent
> learning is a social experience
> an expert is watching you and cares whether you succeed or fail
I beg to differ. Tried to use a kaios nokia 800 tough. Firefox/KaiOS using a stupid kind of webview for every UI, you get two consequences: first, everything is ugly: wrong padding everywhere, complex layout with non-integer number of list items fitting on screen (this is important, vertical list is the primary widget on small screen dumbphones). And second: everything is sluggish. My true "series 30" nokia launches app instantly, whereas i'm sure the SoC is order of magnitudes slower.
So the UX definitely shows complete absence of culture of design in this kind of space (eg gameboy UI design, classic dumbphone UI, ...). Small screens need very simple widgets (most importantly grid and vertical list), hand made paddings and proper space optimizations, most likely some bitmap font tailored to the resolution.. You can't just slap some dynamic layout and expect it to work nicely on such a small screen. Everything vectorized will be both costly and of dubious rendering quality, etc..
And of course these things only have "decent", but definitely not "1 month scale" battery life. I guess LTE is the real culprit here.
The user interface / language design. See talk "LaTeX: It's Not You, It's Me" by Martin Haug (cofounder). TeX's language design is at the level of Basic's. Which is in fact not surprising given the timeframe.
Ah I see, so not exactly the kind of thing you'd notice making a document but you would if trying to extend the actual language. I mean TeX is basically an overpowered lambda calculus with a focus on text markup and generation.
I suppose the fact that LaTeX works at all is a testament to TeX's power, but yes I can imagine a better base language could be relevant for something like Typst.
> so not exactly the kind of thing you'd notice making a document
By "user interface" I mean (like Martin, in the linked video) the surface language, the way you interact with TeX, its syntax and how it presents itself to the user, the programming model. So definitely the kind of thing you'd notice making a document. Leaky abstractions and footguns are basically everywhere when you write a big LaTeX document.
> I mean TeX is basically an overpowered lambda calculus with a focus on text markup and generation.
No, lambda calculus has capture-avoiding substitution, aka hygienic macro expansion if you will. TeX has naive substitution. By the way, macro expansion is typically CBN, which is very much a rare and weird evaluation order (yes, Haskell, i know). TeX is much closer to some kind of assembly language for a virtual machine.
Speed and nice error messages in (La)TeX, and to some extent ease of programming, are entirely doomed because of fundamental design choices. Being based on unhygienic macro expansion means that there is only one way to evaluate (the slow way), there will never be incremental compilation (everything can possibly be stateful in horrible ways), there will never be good error messages because there's basically no AST information anywhere (begin/end is a joke).
Regarding ecosystem: tons of undecipherable LaTeX packages are basically one-liners (ok, 10 liners) in typst. I know it from experience: I've written my PhD manuscript in typst. So perhaps one reason why there are so many (basically frozen) packages in LaTeX is because they are so hard to write and maintain.
edit: of course, being only a few years old, typst is nowhere near as solid as TeX, but you can already use it for a lot of things and its a breeze to use.
It's a Java-based implementation of TeX, forked from NTS, that was optimized to render 500 to 1,000 equations in real-time on commodity hardware. My text editor, KeenWrite, uses the KeenType library to preview the document. The final output is passed to ConTeXt for typesetting, by way of first converting Markdown to an XHTML file. (This means that KeenWrite can export as both HTML and PDF.)
AST information, hygienic macros, and a ton of other things can be added without starting over. What do you think of LuaTeX? I think we as an industry habitually overestimate the difficulty of evolving older platforms and underestimate the value of doing so.
This! My first actual project (besides some testing) has been my phd manuscript, and after ~2 days i actually had a tufte-style 1.5 column layout going, written from scratch. And its probably like ~250 lines.
There are some rough edges still, the dom model and advanced programming stuff is not quite there yet (user-defined elements, user-defined settables, advanced layout like chaining blocks for laying text flows). But like the quality of the user interface is several orders of magnitude better than (La)TeX.
There are 3 syntactic modes in typst: markup, code and math. In markup, everything is literal, unless you put a `#` sigil like `#expr` in which case `expr` is parsed in code mode. In code mode everything is an identifier, as usual in programming. In math its a bit of an ugly tradeoff but its ok: single-letter things are parsed as literals but multi-letter tokens are parsed as identifiers. Finally, in code you can enclose in `[...]` to parse in markup mode. So typically, your document will be mostly in markup mode and you will encounter stuff like `#something[An argument]`, which is a function call to which you pass one content-typed argument.
So above, `y` is parsed as literal, while `dt` is parsed as an identifier, hence function call.
> In markup, everything is literal, unless you put a `#` sigil
Unless it's a "=", then it begins a new section. And unless it's a "-" or a "+" or a "/", then it's a list item. And unless it's a "<", then it defines a label, or a "@", then it's a reference to one. And unless it's a "_" or "*" or "`", then it changes font or style.
Right. Markup mode supports markup features - including all of that stuff for headings, lists, bold, italics and so on. It’s clearly inspired by markdown and similar languages. Personally I prefer * to \em{xxx} since it’s easier to type and it makes the text easier to read while I’m editing. (Or maybe just more familiar since give written so much markdown at this point).
I think I would have preferred a consistent sigil, but I guess with fast enough feedback you'd get used to the quirks.
I do wonder if this has over-optimised on short equations—to me heavy maths use implies multi-page equations with very specific formatting requirements (something amsmath has no issues with, which isn't surprising given who the authors are).
there is a really interesting space between queries and prolog which includes mundane junk like encoding and rendering and data formatting changes that benefits in evaluation from having less power but maintains the lovely expressibility and analysis that we get from 'real' logic programming.
