48 karma · joined September 22, 2023
Anyway, Word «collaborative» features are so much worse than git repository and pull requests! And even you need to collaborate with some extremely non-technical folks, in the case of LaTeX they still use add comments to the PDF file — and this workflow is still way more productive than editing the same Word document.
Other reasons to not to use Word in collaborative pipelines are already mentioned in neighbor threads.
From my experience Word from Office360 breaks complex formatting of desktop Word document even worse, than LibreOffice/Google Docs does.
But Word for collaborative work is a nightmare. Sometimes fastest way to work with the science text or documentation in a Word document is to hire a freelancer to retype all the text in LaTeX or something else.
It's a kind of Trolley problem: sometimes Word fanboys, unfortunately, _should_ suffer to let all the team get the job done.
My «second brain» now is almost 300Mb of text, pictures, sound files, PDF and other stuff. As I already mentioned, it contains tables, mathematical formulae, sheet music, cross-references, code samples, UML diagrams and graphs in Graphviz format. It is versioned, indexed by local search engine, analyzed by AI assistant and shared between many computers and mobile devices. And (last but not least) it works: it allows me to solve my tasks way more faster than with the assistance of external, non-personalized tools (like ChatGPT, StackExchange or Google).
I know no tools for all this tasks except org-mode. Well, maybe Evernote in the 2010-s was something similar — but with less features, with more bugs and with worse interface.
Personal note-taking _is_ a complex task per se (well, at least for someone like typical HN visitor). I've seen many note-taking tools, that were ridiculously featureless, stupid and inconvenient because they were _not_ complex enough.
> Sure if one wants to do emacs-gardening it is fine.
1)You can use org-mode outside Emacs. See for example Logseq (https://logseq.com/), organice (https://organice.200ok.ch/) or EasyOrg.
2)Org-mode works in Emacs out of the box, you don't need any «emacs-gardening» to use org-mode.
3)The term «Emacs-gardening» itself sound a bit like hate-speech for me. The complexity of Emacs customization is overrated, mostly due to opinions of people who never used Emacs or used it in the previous millennium.
If you use Emacs, you will have great editor with powerful preview features (images, formatting, table processor with formulae, code execution inside the text), and the pipeline for generating HTML or PDF will be approximately the same as with .md/.rst (org-mode is even supported by GitLab and GitHub web interface, although not perfectly). But the support of the org-mode outside Emacs is worse than of Markdown and reStructuredText.
I tried to use org-roam, but it's too complex to adopt my already written notes to the org-roam format and structure.
It's an another experimental programming language with the static reference counting. «Morphic uses a borrow-based reference counting scheme which is able to eliminate almost all reference count increments and decrements for a large class of programs»ⓒMorphic developer team.
See also Anton Felix Lorenzen's master thesis: https://antonlorenzen.de/master_thesis_perceus_borrowing.pdf
Mr. Feldman also mentioned some «alias analysis» library «Morphic Solver» from Berkley University, but I cannot find anything about it.
BTW compile time reference counting was already discussed on HN, for example here: https://news.ycombinator.com/item?id=19567666
> Example: A linked list.
IIUC recursive data structures like linked list and trees are not the problem for the static reference counting. Mutation (and, therefore, link cycles) _is_ a problem, but Roc is a clean language with no explicit mutation. =)
> I can see so many basic cases in which it doesn't work
Sometimes runtime reference counting is still used. But, of course, in way more complex situations than just processing a linked list.
> Nitpick: Rc and Arc are not traits.
Of course, my fault. I haven't written on Rust for a long time (and never used this language in a serious project).
edit: link added
But Roc counts references in _compile_ time. So it's like _usual_ (not wrapped in Rc<>) values in Rust. But in Rust the value is deleted from the heap when the stack frame with the _only_ link to it («the owner») is deleted. And in Roc the value is deleted from the heap, when the _last_ link to it leaves the stack.
So we have the machine code _almost_ as efficient as a Rust-produced machine code, but the source code with a much simpler semantics.
The only «sine qua non» optimization through opportunistic mutablity is AFAIK tail call optimization. But it is probably too well-known to call it «clever optimization» in 2023.
But, for example, applying a function to a list will produce the code allocating new list in, say, OCaml and Haskell, at least by default. And Roc will produce the code for mutating the list in-place _from the source code with the same semantic_ (see example for the Quicksort algorithm in the video above).
Compile-time lifetime analysis (that probably is not needed at all in functional languages with GC) and widely used unboxed values are way not common in functional language implementations. For example, in OCaml those features are still experimental (and probably never will be used by default, as in Roc).
Many other things are features or bugs depending of your preferences. For me, for example, eager evaluation is a big improvement, but YMMV.
The unique selling point of Roc is clever optimization to convert purely functional source code to deep-imperative fast machine code, while keeping all the correctness of functional algorithms.
See this video of Richard Feldman for details — «Outperforming Imperative with Pure Functional Languages»: https://www.youtube.com/watch?v=vzfy4EKwG_Y
Among those clever optimizations:
- static reference counting (no GC, like in Rust, but with no borrowing and borrow problems);
- stack allocation of the data with no external links;
- hidden («opportunistic») mutability even in the cases, where Haskell or Lisp will copy the value.
edit:markup
Supported and battle-tested OCaml or StandardML for BEAM would be great, of course. I'm waiting for something like this for years.