If you asked an "agent" to make something for you, you yourself did not create it. By definition. Whether it's AI or a person. You contributed only a piece. It's no longer yours. This is why any piece of art/music has everyone involved documented in credits. The phonies in the industry have ghostwriters write songs for them, like a majority of pop artists. Pop music is going to be even more fake soon.
When smartphones took over computing and landed in everyone's pockets, and the shareholders realized they have access to every single eyeball on Earth, and so the squeezing of tech for profit began. The big watershed moment for me was when Google Reader was killed off; it signaled the end of the web for users.
Man, they just take away one of implementations, RSS lives as a standard! It is actually good to understand how cloud services are never going to benefit us, long term.
Health insurance isn't tied to a company? Your ability to survive and feed your family isn't tied to your company? Lack of opportunities in the job market? Lack of equal salary/benefits at alternative companies? Non-competes, H1-B visas....
> so if you don’t like how they chose the leader or what they’re doing, you can leave.
Just one small thing Ben: leave to work for who? Who isn't hiring CEOs and running businesses the same way as everyone else?
Many of these are uniquely American problems, and the many of the people and especially the highest in power in the United States have chosen and continue to choose to bind all of that to the company you work for (or don't).
Yes, it's ironic that a democracy has exactly created the situation they lament about, the lack of universal healthcare. Unfortunately there is no political will to do it, while ironically an autocrat could cut through the red tape and get it done, as it had been enacted in several Asian countries in the last half century.
I mean.... ParEdit [1] and ParInfer [2] have been around for a long time now. Structural editing is basically ancient. Lispers have been doing this for a long while, `slurp`ing and `barf`ing their parens.
I have no problem with anyone jousting with the windmills; I have a problem when they don't realize they are windmills. Hundreds and probably thousands of programmers have taken a crack at this problem. That doesn't prove it's a bad idea but it is effective proof until shown otherwise that if it is a good idea it is not such a good idea that it can instantly catch up to the decades of work in text editing. And the way some people talk about it, it's clear that a lot of programmers think that it should be that good.
This is up there with "everything would be solved with visual programming" and "hey, what if we could put down different syntax on top of the ASTs?". If your mental model is that it must just be because nobody has put any effort into the question, update your model, because in fact tons of effort has been expended and I'd suggest anyone interested in adding to the pile and actually solving the problems (as opposed to playing about, anyone can play with anything they like) is best served by examining the large pile of previous efforts and figuring out what they will do better than before.
Creating a language designed for being manipulated this way is at least a bit more rare than just declaring structural editing is the way forward in a general sense. Still, I'm skeptical. The existence of a textual serialization of programming language concepts is not the problem, nor is the usage of said serialization. Every serious tool already immediately deserializes the text into an AST, and when you really get down to the nitty-gritty of how one represents these things in memory, it is not at all clear that there is necessary a "better" way to serialize these structures, or one that is really very different in the ways that matter. There's a number of well-known (by those who look) pitfalls built into the idea of structural editing and it is not clear at all that the fundamental disadvantages can be overcome. Maybe they can. But the evidence at this point is effectively proof it's going to take more than waving "structural editing!" and some excitement at the problem.
> Creating a language designed for being manipulated this way
AFAIK, Lisp wasn't created for structural editing, it was just a "happy accident" that it lends itself so well to the technique. Even without the paredit and parinfer plugins, emacs already has good support for structural editing built-in. It reminds me of VIM text objects, but geared directly for Lisp syntax, ie. symbolic expressions.
How is it faster to press `*` than `Ctrl-I` in any other rich text editor?
> The idea that it is meant to be seen is no more than a personal preference.
Actually, the entire philosophy of Markdown is that, even if you didn't process it into HTML or some form of rich text, it uses common conventions that have been used across Usenet, IRC, and plaintext files for years, and is thus readable without ever being processed. In fact, you can likely take various plaintext files and process them and they'll gain many incidental markups and highlights.
Meaning, Markdown is Markdown without needing to be turned into HTML or rich text. It is, in itself, a great way to universally markup text as people have been doing online for years.
i haven't pushed it to github yet, but i have a keybinding for alt-* similar to the alt-` binding at https://github.com/kragen/kragen-.emacs.d/blob/master/init.e... which italicizes the previous word. that way, to italicize a single word, which is the most common case, i only have to press alt-* once. successive presses expand the italicized region leftwards over more words (this happens whenever the cursor is directly to the right of a *; it isn't activated by an invisible bit that remembers whether the previous command was also an alt-*)
(it also ought to italicize the selection when there's an active selection, but i haven't implemented that yet)
i think this is a superior interaction paradigm to the paradigm where ctrl-i sets an italics mode that doesn't visibly change anything near the cursor, but affects the future text you type. that design not only usually requires more keystrokes but causes mode errors. this is how ctrl-i and ctrl-b should always have worked, and if larry tesler had thought of the idea by 01983, that's how they always would have worked
however, the keystroke ctrl-i is easier to type than the keystroke alt-*
Stolen, thanks! I just played around with something like that in vim¹, and it works great.
I have a tooling issue with your method, perhaps in the same manner as you feel about C-i. To me "italicize $count previous words" makes far more sense than expanding the region on repeated calls. Although to be fair I can wrap over visual mode for that functionality which would feel more comfortable to me; "ge" end of previous word, "v", $navigation, ...
My point - to the extent I have one - is that there is probably a degree of personal comfort that colors our reactions to people using C-i.
¹ Basically "imap <C-S-8> <Esc>bcw*<C-r>-*<C-o>w". I'll give it some more thought, along with adding v:count and non-* support, before it hits my vimrc.
You may not be aware that Ctrl-I toggles the mode of new text, not just selected text. I think that poster was saying this:
If you're writing a new sentence in MSWord, you type "Emphasize words <Ctrl-I>like this<Ctrl-I>."
If you write a new sentence in Markdown, you type "Emphasize words *like this*."
The keys are neighbors even, at least in a US keyboard layout, so there is not a reason most US users would say it's "faster" to type * than Ctrl-I. (And if other layout users disagree, okay, but I don't think that was in the scope of the original point.)
I think in practice, people write "Emphasize words like this.", then <left> *, then <C-left><C-left> *. At least I myself usually add markup immediately after writing the words to be marked up.
The problem with Word-like editor styling is exactly that the boundaries are invisible, and the style is applied destructively to everything within highlighted range, instead of non-destructively by the range itself. What I mean is, if in the example above, I want to change the emphasis to only italicize "this", I can kill the first * and place it a word later. In Word-style editing, I'll have to highlight the whole "like " sequence and un-italicize it, hoping I didn't miss a space or a dot that invisibly retains the italics and then screw up editing for you down the line.
> I think in practice, people write "Emphasize words like this.", then <left> , then <C-left><C-left> . At least I myself usually add markup immediately after writing the words to be marked up.
Is this very different from "<left> <Ctrl+Shift+left> <Ctrl+Shift+Left> <Ctrl+I>"?
I do not know what exact keystrokes people use. When I am writing a lot of text, I eventually converge into writing like I described. Because it is faster and I know what I want.
What I also know is that when out company switched to visual editor only, people stopped using these. They stopped writing long texts - and those were those the most valuable.
Not sure whether most people do that? I nearly always press * or Ctrl-I before the italicized text I’ll type, and see that often among other people in the office.
I'm guessing it depends whether you type at approximately the speed of thought or not; in my case, I'm often halw-way through a passage before I decide I want it italicized.
> An old employer used this instead of Docker for managing build distribution. Can the Guix stuff be used the same way?
Yes, and, Guix is actually a "meta" package manager that understands other packages like Python PIPs and Node NPM packages, so you can define all of that in one build config file.
Wait, this is a big deal. Will it work with any package manager or only things that it explicitly supports?
One thing that has become a persistent headache for me with Nix is trying to get reproducible builds with Julia, due to the fact that the package manager doesn't have direct integration with Nix, and `nix build` purposefully restricts network access. I'd happily move to Guix if they have an elegant way to deal with this.
Since it's all just Guile Scheme, a full programming language, you can extend it in any way you want, and use the Scheme libraries you want, doing whatever network access you please.
The builder is sandboxed, the whole model goes out the window otherwise.
Also, I really doubt Guix moves the needle much here. It can't make Julia magically more reproducible without effectively doing the same techniques you'd have to use in Nix.
Looks like Google is pushing or at least trialing full-screen, non-media-content, loud advertisements on their "Google TV" branded products. While this is for Chromecasts, it is possible it's coming to regular Google TV next...
> it is possible it's coming to regular Google TV next
We've all seen this show before and we all know how it plays out:
1) "We have an ad free service!"
2) "We're going to start showing promotions for our own products - they don't count as ads"
3) "We're going to start showing ads for our partners but they'll only be a few seconds long and you can skip them"
4) "We're introducing unskippable ads"
5) "We're now injecting ads directly into the content"
6) "That sure is a nice TV/media service you got there. It would be a shame if we injected so many ads that it becomes unwatchable. LUCKY FOR YOU we have a Premium ad-free tier"
