XML, JSON, YAML, RDF, EDN, LaTeX, OrgMode, Markdown... Plenty of plaintext, but structured information formats that are "yes, and". Yes, I can process them as lines of plain text, and I can do structured data transformations on them too, and there are clients (or readers) that know how to render them in WYSIWYG style.
If that’s our definition of “plain text”, sure. I would still rather our tools were more advanced, such that printable and non-printable formats were on a more equal footing, though. I always process structured formats through something that understands the structure, if I can, so I feel that the only benefit I regularly get out of formats being printable is that I have to use tools that only cope with printable formats. The argument starts getting a bit circular for me.
Hm, you made me think about non-printing characters as metadata, which is of course immediately lost on printing and therefore does not round trip between digital and printed versions.
Many nonprinting characters imply some directive; line break (hard-wrap the text here, but this is not a paragraph), page break (let the rest of the page be blank, start the next paragraph overleaf), EOL (file over, bye bye), nonbreaking space (keep these two words together, always, till death do them part).
This is out-of-band information spliced in-band (with the text corpus), which a computer program can "see", but a person can't.
Yes, I thought of what you mentioned too, and in my opinion, DER is a better format, and it is a binary format rather than text.
(In my ideas of an operating system design, there is a structured binary format (similar to DER but different) used for most files and data, so that the tools (and the command shell) would be usable consistently with most of them; and if some need special handling, you can use other programs and functions to convert them and/or handle them in a way that can be interoperable.)
XML arguably isn’t plain text, but a binary format: If you add/change the encoding declaration on the first line, the remaining bytes will be interpreted differently. Unless you process it as a function of its declared (or auto-detected, see below) encoding, you have to treat it as a binary file.
In the absence of an encoding declaration, the encoding is in some cases detected automatically based on the first four bytes: https://www.w3.org/TR/xml/#sec-guessing-no-ext-info
Again, that means that XML is a binary format.
Another way that the character encoding could be declared is ISO 2022. When using ISO 2022, the declaration of UTF-8 is <1B 25 47>, rather than the <EF BB BF> that XML and some other formats use.
However, whether you do it that way or another way, I think that the encoding declaration should not be omitted unless it is purely ASCII in which case the encoding declaration should be omitted.
Yeah, "Nobody every got fired for purchasing IBM"... a story as old as time itself.
But that is the "fear" side of the enterprise sales equation... The "greed" side of it is for the buyer to make the long / short hedge.
The exec who gets the value of the working product can potentially come out shining, when their peers will be furiously backpedalling next year. And this consummate exec can do it by name-associating with their "main bet" which is optically great for the immediate term but totally out of their control (because big corp vendor will drag its feet like every SAP integration failure they've seen), and feeling a sense of agency by running an off-books skunkworks project that actually works and saves the day.
A fine needle to thread for the upstart, but better than standing outside the game.
Another way I see it is... Mind is process. LLM is (very lossy) snapshotted state of process/mind. LLM in-process is mind-emulator with potential to explore the state-space of the mind-snapshot. Consequently, and by its very construction, LLM cannot be mind.
May I offer a little code riff slicing FizzBuzz using transducers, as one would do in practice, in real code (as in not a screening interview round).
Demo One: Computation and Output format pulled apart
(def natural-nums (rest (range)))
(def fizz-buzz-xform
(comp (map basic-buzz)
(take 100))) ;; early termination
(transduce fizz-buzz-xform ;; calculate each step
conj ;; and use this output method
[] ;; to pour output into this data structure
natural-nums)
(transduce fizz-buzz-xform ;; calculate each step
str ;; and use this output method
"" ;; to catenate output into this string
natural-nums) ;; given this input
(defn suffix-comma [s] (str s ","))
(transduce (comp fizz-buzz-xform
(map suffix-comma)) ;; calculate each step
str ;; and use this output method
"" ;; to catenate output into this string
natural-nums) ;; given this input
Cool! Also, carrying forward the post author's tongue-in-cheek humour... I see your lua and raise you ~350 lines of Bash (excludes HTML templates). Take a good hard look at this shite [0]. Have you seen anything that is more obviously HTML-about-to-be-expanded-into-a-full-page?
That is... a cool trick! I don't know C, so it would have never occurred to me. (Let's be honest; it would have not occurred to me even if I knew C :))
What I like about the Bash + Heredocs + substitutions approach is that it looks and feels declarative to me. Template "expansion" is just in-place substitutions (parameter expansion, shell substitution, process substitution); no string munging needed to "place" or "inject" content in the HTML tree.
Anyway, I spent way too much time figuring that out, and it works well for me, so I'm going to just roll with the sunk costs :D
> I have to address the elephant in the room:
> hot-rebuilding isn't true hot-reloading.
> To get the browser to magically inject CSS without
> a refresh requires WebSockets, background Node
> processes, and a lot of external baggage.
OR... you could just use inotify again... Behold this abomination (that works so well (on my machine) I can't believe it):
__shite_hot_cmd_browser_refresh() {
local window_id=${1:?"Fail. We expect window ID to be set in scope."}
printf "%s\n" \
"key --window ${window_id} --clearmodifiers 'F5'"
}
__shite_hot_cmd_goto_url() {
local window_id=${1}
local url=${2}
printf "%s\n" \
"key --window ${window_id} --clearmodifiers 'ctrl+l'" \
"type --window ${window_id} --clearmodifiers --delay 1 ${url}" \
"key --window ${window_id} --clearmodifiers 'Return'"
}
... and a few functions later ...
__shite_hot_cmd_exec() {
# In debug mode, only show the actions, don't do them.
if [[ ${SHITE_BUILD} == "hot" ]]
then stdbuf -oL grep -v '^$' | __tap_stream | xdotool -
else cat -
fi
}
shite_hot_browser_reload() {
local browser_window_id=${1:?"Fail. Window ID not set."}
local base_url=${base_url:?"Fail. Base URL not set."}
__shite_hot_cmd_public_events ${browser_window_id} ${base_url} |
__shite_hot_cmd_exec
}
... and finally ...
# RUN PIPELINE
shite_hot_watch_file_events ${watch_dir} |
__shite_events_dedupe |
__tap_stream |
tee >(shite_hot_build ${base_url}) |
# Perform hot-reload actions only against changes to public files
tee >(shite_hot_browser_reload ${window_id} ${base_url})
In your case, bike or drive around and talk to SMEs in your city. Have friends refer you to their contacts, so it's a warm intro. Build software for free, and maintain it on an annual maintenance contract basis. "Value-price" each AMC. Initially, be fine with "leaving money on the table". Within two to three deals you will figure out a mutually profitable pricing strategy.
I think it was more like Emacs got Clojure development niceties early, particularly tight REPL integration.
Things have been different for well over five years --- about a third of Clojure's life. There are so many first-class options now. When teaching Clojure, I direct everybody to either VSCode + Calva, or Intellij + Cursive.
LSP has really upped the game too. I rebuilt my Emacs development workflow around LSP for all the things.
These days, I sometimes forget to fire up the REPL, because of all this fantastic "static analysis style" developer tooling by borkdude and eric dallo.
Much gratitude to all the toolsmiths from all over the Clojure ecosystem. Special shout-out to LightTable for upping the game for everybody. I was very sad when the project went dormant.
Thank you Colin for the outstanding work and selfless, continuous gifting and self-generosity. Cursive remains one of the important pillars of Clojure journey for many beginners and seasoned pros.
You just can't ignore the amazing collaboration and camaraderie between Clojure tools builders. - you Colin, Peter (Calva), Eric (clojure-lsp), Michiel (babashka, kondo, etc.), Bozhidar (CIDER, clojure-mode), Juan (flowstorm), Chris (Portal), and many others.
Everyone, instead of competing with one another just wants for people to find their best way of using Clojure, and that is really awesome. You can see the ideas freely circulating between spaces and creating great of awesomeness for everyone in the community. I'm telling you all this as someone who doesn't even use Cursive. I still can see your work. I can tell how valuable, important and vital you are for me personally and for many of my friends and colleagues. I salute you, and every other tool-making hero. Thank you, guys!
reply