Anything that doesn't force you to remember arbitrary ordering - square brackets first? Or parentheses? It's the textual equivalent of plugging in usb upside down.
An alternative would be to simply use square brackets for both clauses of the link.
The problem with this is that if you want to render this “pretty”, there’s no way to know whether the link should be “my website” or “website” or even the whole sentence. So you add brackets to clarify.
My issue is remembering that the square brackets come first, not the parentheses. I do like asciidoc's method: https://example.com for bare link, or https://example.com[pretty text] if alternate text is desired
Edit: It took me a re-read to fully understand your comment, I can see how square brackets might be an incremental addition. This may also help remember the syntax, thanks!
Excerpt from my notes when I was deciding on a link syntax for my own lightweight markup language:
AsciiDoc doesn’t actually have a real link syntax—what it has is more or less an natural consequence of other syntax choices, but isn’t actually URL-aware, and will mangle some less common URLs. Still, what you get is mostly this kind of thing:
But woe betide you if you go beyond what it supports, its techniques when you need escaping are grotesque, monstrous horrors. Seriously, when you fall off the happy path, AsciiDoc is awful.
Someone (maybe on this site) suggested to think of the bottom bars of the square brackets around the linked text to kind of frame the underline. Somehow worked really well for me, haven’t forgotten the syntax since.
This is great! Not an emacs user (as yet) but this and org-mode's /italic/ _underline_ *bold* +strike+ feel that much closer to the oft-touted "source looks kinda like formatting” ideal of markdown. Not sure why we ended up with the mediocre version as a defacto standard.
The only keyboard shortcut for org-mode and markdown-mode I consistently remember is C-c C-l for inserting links. Much easier to remember that than to remember the syntax, and the fact that both modes use the same easy-to-remember shortcut is a major win.
Sadly, most other keybindings differ between org-mode, markdown-node, and auctex. I would have loved more consistency, and often end up typing the syntax instead of tripping up keybindings.
Enjoyed the article, and the "less can be more than you think" mindset in general.
To the author - on Android Chrome I seem to inevitably load the page scrolled to the bottom, footnotes area. Scrolling up, back button, click link again has the same results - I start out seeing footnotes. Might be worth a look.
I'm interested in this. Code review, most egregiously where the "author" neglected to review the LLM output themselves, seems like a clear instance. What are some other examples?
Something that should go in a "survival guide" for devs that still prefer to code themselves.
Well, if you take "review the LLM output" in its most general way, I guess you can class everything under that. But I think it's worth talking about the problem in a bit more detail than that, because someone can easily say "Oh I definitely review the LLM output!" and still be pushing work onto other people.
The fact is that no matter whether we review the LLM output or not, no matter whether we write the code entirely by hand or not, there's always going to be the possibility of errors. So it's not some bright-line thing. If you're relatively lazier and relatively less thoughtful in the way you work, you'll make more errors and more significant errors. You'll look like you're doing the work, but your teammates have to do more to make up for the problems.
Having to work around problems your coworkers introduced is nothing new, but LLMs make it worse in a few ways I think. One is just, that old joke about there being four kinds of people: lazy and stupid, industrious and stupid, smart and lazy, and industrious and smart. It's always been the "industrious and stupid" people that kill you, so LLMs are an obvious problem there.
Second there's what I call the six-fingered hands thing. LLMs make mistakes a human wouldn't, which means the problem won't be in your hypothesis-space when you're debugging.
Third, it's very useful to have unfinished work look unfinished. It lets you know what to expect. If there's voluminous docs and tests and the functionality either doesn't work at all or doesn't even make sense when you think about it, that's going to make you waste time.
Finally, at the most basic level, we expect there to be some sort of plan behind our coworkers' work. We expect that someone's thought about this and that the stuff they're doing is fundamentally going to be responsive to the requirements. If someone's phoning it in with an LLM, problems can stay hidden for a long time.
I'm currently really feeling the pain the side bar stuff. The non "application" code/config.
Scripts, cicd, documentation etc. The stuff that gets a PR but doesn't REALLY get the same level of review because its not really production code. But when you need to go tweak the thing it does a few months or years later... its so dense and undecipherable you spend more time figuring out how the llm wrote the damn thing than doing it all over yourself.
Should you probably review it a little harsher in the moment? sure, but thats not always feasible with things that are at the time "not important" and only later become the root of other things.
I have lost several hours this week to several such occurences.
AI-generated docs, charts, READMEs, TOE diagrams. My company’s Confluence is flooded with half assed documentation from several different dev teams that either loosely matches or doesn’t match at all the behavior or configuration of their apps.
For example they ask to have networking configs put into place and point us at these docs that are not accurate and then they expect that we’ll troubleshoot and figure out what exactly they need. It’s a complete waste of time and insulting to shove off that work onto another team because they couldn’t be fucked to read their own code and write down their requirements accurately.
If I were a CTO or VP these days I think I'd push for a blanket ban on committing docs/readmes/diagrams etc along with the initial work. Teams can push stuff to a `slop/` folder but don't call it docs.
If you push all that stuff at the same time, it's really easy to get away with this soft lie, "job done". They can claim they thought it was okay and it was just an honest mistake there were problems. They can lie about how much work they really did.
READMEs or diagrams that are plans for the functionality are fine. Docs that describe finished functionality are fine. Slop that dresses up unfinished work as finished work just fucks everything up, and the incentives are misaligned so everyone's doing this.
Exactly. The problem is instead of getting a raise because "you can do more now" your colleagues will be laid off. Why pay for 3 devs when the work can be done by 1 now? And we all better hope that actually pans out in whatever legacy codebase we're dealing with.
Now the job market is flooded due to layoffs, further justifying lack of comp adjustment - add inflation, and you have "de-valuing" in direct form.
I love it too. Appears to be accomplished with this CSS, which you can tinker with by finding the :after element at the bottom of the <body> tag in browser devtools:
i figured that's what it was, but i didnt know how to find it in the browser tools but i missed the "after" part, so yeah it's in the "pseudo-elements". nice!
Just don't give it write access, and rig it up so that you gate success on a file generated by running the test suite separate from the agent that it can't influence. It can tell me it has fixed things as much as it like, but until the tests actually passes it will just get told the problem still exists, to document the approach it tested and to document that it didn't work, and try again.
Aren't the impacts perpetual if we're creating new contrails every single day?
Taken from another comment, this seems pretty clear:
> Contrail cirrus may be air traffic's largest radiative forcing component, larger than all CO2 accumulated from aviation, and could triple from a 2006 baseline to 160–180 mW/m2 by 2050 without intervention.
It seems like you're misunderstanding what parent meant by "prerecorded" - not a screen recording, just pre-writing of commands to be executed during the demo. Would you consider it "deception" to hit up arrow a few times in a terminal during your demo to execute a command from shell history? This is effectively the same. Take a look at the linked repo, it's very clever.
The original link for itsalive says it works by making it not live and the op says just as much.
This is very different from practicing a script and you actually doing all the actions in real time. You're allowed to rehearse for your live performance but unless you're doing it live then it's not live.
People also hate lip syncing because it's a deception of being live.
And yet, ~all singers lipsync, because the point isn't to show off what the artist can do vocally every single night, but to entertain the audience, which lip syncing achieves.
Are you assuming or do you have evidence to back up that claim. Because I actually go outside and watch musicians perform. Are you telling me they fake the errors too? LOL
This is great! Asciinema is well-made and a lot of fun, but it sadly doesn't show the recordings in motion right there in the markdown/README. Looks like vhs neatly solves that problem, appreciate the share.
An alternative would be to simply use square brackets for both clauses of the link.
reply