Not to me. It says "System Initiative is an Intuitive, Powerful, and Collaborative replacement for Infrastructure as Code" but I still don't understand what it does or why I would want to use it.
They get to it if you scroll! I came to the comments with the exact same concern, but they eventually spell out the value-add in (IMO) very clear terms:
First, we turned everything into data - a rich system of digital twins that enable safe, easy simluation of changes, and map 1:1 to the upstream resource.
Second, we made it all programmable and reactive by modeling it on top of a hypergraph of functions. When one property on a model changes, anything dependent on that property automatically re-calculates.
Third, we built a multiplayer user interface that makes working with the model fast, safe, and fun.
Seems cool, though I'm far from needing it. AFAIU: it's an attempt to build a reactive infrastructure system from the ground up using a cute Functional Programming paradigm, not just building off of code-like YAML files like we do today.
Personally the GUI gives me flashbacks to the dark days where "programming" in my mind was "using Eclipse", but that's a biased take! I can see why WYSIWYG-style functionality was considered too fundamental to make optional.
The trick is that we’re not replacing programming with the UI - we’re just making it easier to compose things together. Plenty of code in SI - just not the way you write IaC today.
https://purismspc.com (the backup domain they registered after the 2018 outage) is sort of working. It responds, but links all go to puri.sm so they don't work, stylesheets don't load, etc.
He meant approximately half a bit. Base64 uses 64 characters, which means 6 bits per character. 50 characters gives you about 5.64 bits per character. Unlike Base64's 3-bytes-equals-4-characters, that never comes out evenly.
Let's face it, the Perl 5/PCRE regex syntax is atrocious. The only reason it exists is that (? was a syntax error in earlier regex syntaxes, so it could be redefined to mean anything.
Raku is an attempt to design a sane regular expression language from first principles, now that we know what we want them to be able to express. The alternative is being stuck with (?:this|(?>or that)) for the next 30 years.
Yes, awful. It takes a crack in the wall and drives a bus through it, at a significant penalty to readability. The compatibility advantage doesn't matter when you're evaluating syntax in a vacuum.
It is terse for a reason. You're ordering a parser around in 10 characters. Which makes them fit everywhere! A longer more readable version starts taking up multiple lines and looking like shitty react code. Or you're just using your language's string primitives. But there is a reason that nobody does that any more -- who wants to read 50 lines of string parsing code when a couple dozen characters of regex will do the same thing?
Perhaps. But that will become very difficult indeed.
Because in Raku, grammars are just a different way to write code. Grammars are really just specialized classes. And tokens / rules / regexes are just specialized methods. It all compiles down to bytecode, rather than something you can feed a statemachine.
This has several advantages: if a grammar doesn't provide functionality you need, you can write it in Raku code as part of the grammar.
It also means that when you improve execution of the bytecode, you will also improve the performance of grammars and regexes.
Finally: Raku grammars are very powerful. They are used to parse the Raku language itself. Which is a testament to its power. But also brings a whole set of challenges for the core developers :-)
I admit that I was partly being facetious, but I also don’t think it is entirely impossible. For example, a hypothetical RCRE could provide hash tables for storing named regexes, or could take function pointers for looking up names so that the library user could implement their own storage for them. And so on, and so forth.
I think that a hypothetical RCRE could be as influential as PCRE was, if someone could find the time to do it.
On the other hand, I am very weary of C these days. A Rust crate with procedural macros to provide compile–time grammar compilation would be a lot more fun. If I had some funding I could easily see spending a year or three on that.
I made a silverware holder custom-fit to my silverware.
I found a half-inch thick HDPE cutting board at a restaurant supply store, cut it to fit my drawer, then drilled holes in it and inserted short wooden dowels to hold the stacks of silverware in place. To position the dowels, I wrapped a nail in tape to match the diameter of the dowels, then placed my silverware on the board, slid the nail up next to it, and gave it a tap to mark the board where the holes needed to be drilled.
It worked really well and was quite easy to do. I highly recommend it.
I've been using Joplin for a while now, syncing via Nextcloud.
One tip: I set up a cronjob to export into a Git repository so I have a complete history. The core of the script is:
joplin sync
joplin export --format=raw "$tmpdir"
# Rsync that directory to the repository
# This deletes files that no longer exist in the current export.
/usr/bin/rsync -a --quiet --delete --exclude=.git "$tmpdir/" "./"
/usr/bin/git add -A
My browser can't even read that. It renders as "In Hamlet, Act [2163], Scene [2168]..." (where [2163] means a small box with those 4 digits). What font do I need to install to be able to read that as "In Hamlet, Act IV, Scene IX..."? (I'm using Firefox on Arch Linux.)
It is:
Contractors' Handbook: The Expert Guide for UK Contractors and Freelancers (3rd Edition; 13 Nov. 2017)
by Dave Chaplin (ISBN-10: 1527216039; ISBN-13: 978-1527216037)
