LLM fatigue is real. It's not just em-dash — it's the overall tone of the writing that clues people in. But if your viewpoints and approach are unique, your typesetting won't raise suspicion of machine-generation, except in the most dull of readers. Just be you and it will be fine.
If you'd like more tips on writing I'd be happy to help.
When Seagate (then a reputable hard drive manufacturer) purchased Maxtor (then the bottom-of-the-barrel for both price and reliability) I hoped Seagate would rehabilitate their newly acquired facilities and bring them up to the same quality.
Being informed of what? Whatever their dad tells them? Although the pitfalls of social media are many, the answer lies with regulation and moderation, not banning a significant portion of the population from them. The diversity of perspective and opinion is what allows people to gain the exposure needed to develop informed opinions. What blows my mind is that governments have the world's biggest media market makers by the throat and they refuse to force regulation. If they removed AI, made the algos public/modifiable, and actually moderated content for age restricted stuff this wouldn't be an issue.
Before COVID, the median US High school grad could not pass a middle school reading or math exam by merit. The trend has worsened so that today's median grad cannot demonstrate knowledge they were presented after elementary school. By the numbers, scrolling is inhibiting education on a societal scale.
The GP implied that nefarious forces might be working to remove social media from youths in order to control them better. My argument is that social media has them pretty well under control.
I don't think this is what social media provides. With social media people are able to choose one perspective and seem to just immerse themselves in a bubble so that they only get exposed to the view of their choice.
> never understood why his stuff is well-regarded here.
He appealed to proponents of basic income.
Years ago, forward thinking identified the trend of decreasing ipv4 availability. Pundits built html clocks to countdown to the depletion of ARINs IPV4 pool, prominently warning of an epoch after which no business could function without fully implementing ipv6. The countdown clocks looked scary and the situation sounded believable, inevitable even, we all wanted to hear, but something would finally force the boss to upgrade.
But hubris blinded these pundits to the possibility that a few large businesses implementing IPv6 and reselling their v4 allotments would indefinitely sustain ipv4 as the internet’s source of truth. With a simple workaround, the old model held.
Like the IPv6 pundits of old, Andrew Wang has correctly identified a trend in AI, but he projects it will erase all jobs and require redefinition of social contract. This is a wild claim, yet proponents of “basic income” are excited to hear anything that bolsters the ideas they prefer to believe.
But I suspect in this case too that the old model will adapt, just as it did with every other increase in human office productivity.
It's a combination of cumbersome syntax and the vendor's poor API design and execution environment.
For a syntax example, compare python to Tcl. In python, there's a compact array lookup operator, and dictionaries allow string keys:
mydata["channel"][2]
Tcl, however, requires a function call to access an array index, resulting in nested function calls with magic numbers for the simplest expressions:
lindex [lindex $mydata 35] 2 # Tcl
Then there isn't any static type checking so you have to run code to see if it would work; the shape of a return may surprise you. Connecting to hardware may be your only opportunity to exercise certain code paths.
So for any non trivial task, Tcl becomes effectively write-only.
Some tools allow you to export Tcl scripts that automate tasks like project creation to help you avoid tracking intermediate objects in source control, but because the Tcl cwd path can change throughout a script, they export every source path as a hard coded absolute path, including whatever developer's home directory it might be residing in. This is not suitable for source control (because it would preclude building on any other machine) so then you have to post process these scripts before tracking them. But since it's Tcl there aren't good scriptable tools for programmatic Tcl AST manipulation, so you have to modify these files with some sort of a state machine, looking for various sentinels to trigger the various string replace behaviors you need. It's not all Tcl's fault, but if a vendor is only using Tcl for automation and you need automation, you have a battle ahead of you.
Outside the language, you'll often find that your runtime tool locks the UI thread to run your scripts, so long running operations are impossible to pause or cancel. And I've never seen a vendor expose adequate objects to allow full control, so often, the critical actions you hoped to automate are only possible through the GUI.
In the 90s, an integrated Tcl interpreter was a good sign that your vendor cared about developers. Today it's more a sign of neglect.
> Tcl, however, requires a function call to access an array index, resulting in nested function calls with magic numbers for the simplest expressions:
I do understand how that one can be frustrating to a newbie, but I can't fault that implementation choice when thinking about Tcl as a "Lisp but it's strings".
> Then there isn't any static type checking so you have to run code to see if it would work; the shape of a return may surprise you. Connecting to hardware may be your only opportunity to exercise certain code paths.
This, though, yeah. I feel this in my whole body. I haven't checked out Tcl 9.0 to see how it's changed, but Tcl 8.6's abbreviated compilation phase definitely doesn't leave any room for type much type inference ahead-of-time.
> sentinels
Tangential, but man I wish Tcl had `gensym` out of the box. That alone was enough to start my own programming language over a decade ago.
Everything else, I largely agree with. Short of a hard fork or the Tcl team splitting their time between maintaining for the sake of EDA vendors, and trying different approaches, I don't see much changing.
I really appreciate the time you took to share your experiences here.
Yes, but this kind of dashboard was never going to be accessible anyway. It's a dense visual representation of vast system state with constant real-time fluctuation. Even in a browser, it would be hell to navigate the constantly changing state with a screen reader. And visually increasing the scale and contrast defeats the purpose of the density of the original display.
If you need to support screen readers, your UI would have to be totally different: You should allow the user to snapshot the system state and navigate it. Generate succinct summary text to impart the same sense that a dashboard would to a visual user. "Normal: All systems OK" "Critical: Boeing RPA servers down since 2:17PM PDT and 54 others". Once you've done this work, a CLI tool could expose this just as screen-readable:
$ cli status
all systems OK, last outage resolved 2:27 PDT
$ cli topjob cpu
117 Boeing RPA, 78% CPU
434 SAIC PDM, 43% CPU
$ cli downtime today 117
Boeing RPA down 10 minutes today, resolved now
I’m not just talking about screen readers, though they are important. I mean “accessible” more generally. Yes you could build a specific UI for each kind of user, but that seems far less likely to cover as many uses as building one UI that is structured, programmatically navigable, etc.
If you'd like more tips on writing I'd be happy to help.
reply