I added the following at the top of the blog post that I wrote yesterday: "All words in this blog post were written by a human being."
I don't particularly care if people question that, but the source repo is on GitHub: they can see all the edits that were made along the way. Most LLMs wouldn't deliberately add a million spelling or grammar mistakes to fake a human being... yet.
As for knowing what I'm talking about. Many of my blog posts are about stuff that I just learned, so I have many disclaimers that the reader should take everything with a grain of salt. :-) That said: I put a ridiculous amount of time in these things to make sure it's correct. Knowing that your stuff will be out there for others to criticize if a great motivator to do your homework.
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.
My experience with Tcl is 30 years of using EDA tools, all of them equipped with this language from hell. Luckily, I've been to restrict the scripting part to the minimum. I'm sure that if you know the language well, you can see the foundational model that's behind it, but for occasional users, there's nothing predictable about it.
I couldn't tell you exactly all the thing that are wrong with it. Let's just say that a language where this is ok:
Similar amount of experience with tcl here (since dc_shell-t was released). I love working in tcl. It can be expressive, redable, sufficiently performant, and makes it easy and fast to develop and test new features and functions in even very complex EDA design flows with 100k lines of code.
I find it curious that so many of the criticisms of tcl are that it doesn't have some feature or behavior of some other language. That has never stopped me from accomplishing what is needed with clear, elegant code.
Rule #10 in the Dodekalogue [0] explains why your preferred comment style is not supported: a command is not expected immediately after the last argument of the previous command. Terminate the command per rule #1 and it is perfectly fine:
puts "Hello" ;# A comment
Isn't that the same number of characters one would type to start a javascript comment? //
Almost any programming language can be beautiful in its simplicity if you work with it on its own terms. tcl doesn't deserve the hate.
Of course it's still a thing. It takes 30 seconds, but it's there and requires energy.
Compare the smell of exhaust next time you do a cold and warm start of a combustion car. That smell is the engine running rich, because the fuel can't initially vaporise properly.
I used to think that getting admitted to YC was a major accomplishment. Maybe it was at some point, but at the college graduation parties of my daughter it seemed like pretty much everyone who tried had gotten in. Most collapsed after a few months due to infighting, funds mismanagement etc. It was fascinating to watch.
I think you mean "prestigious" rather than "major accomplishment". You're right, there was a small period of time when it was. However, that window didn't quite align with "best time to do YC" (several years prior to such prestige) nor with "best time to be doing YC" (the prestige embellishes your resume, which is useless if you're otherwise occupied).
It's interesting to me that YC has managed to dilute this prestige to a large extent. I don't think it's an inevitable result of scale: look at Google. I think "Xoogler" prestige has diminished, but it's not nearly as bad as what has happened to the YC label.
My theory is: YC never figured out their formula. The whole formula is essentially Paul Graham, who had a knack for trusting his gut (and sometimes his wife) when everything else in his "system" was saying NO.
Once they lost that, they had to rely on what was left, and it simply wasn't competitive anymore. It's like Apple in their John Sculley era. While Sculley is credited with growing Apple's revenue from $800 million to $8 billion, his approach created a "mess of dull SKUs" that eventually confused customers and diluted the brand.
They also have a (bad) habit of removing access to bookface for all the founders who aren't "active", decimating their network and in some ways discarding valuable knowledge around what didn't work.
AV1 has the CfL (chroma from luma) prediction tool. h.266 has CCLM (cross component linear model) and AV2 has improved CfL.
When you see the AV2 version, it’s very similar to h.266, which is more advanced than AV1 CfL: they are using filters that cover up to 6 luma pixels to determine the chroma baseline.
The algorithm described in this blog post is pretty close to what AV1 CfL does.
> The algorithm described in this blog post is pretty close to what AV1 CfL does.
This checks out. I've played around with AVIF, and noticed that it kinda traces high contrast edges and smudges the rest. Higher quality settings mean less smudging.
I'm just surprised that my blog post from almost 6 years ago suddenly made it to the HN front page...
That said: only when I need it the same day and it's not too complicated will I use protoboard. Otherwise it's JLCPCB every time, even if it's just a small debug interface board. I recently bought a cheap wire-wrapping tool and that's so much faster than messing around with enamel wire.
The board that is featured in this blog post was the first prototype of a skunkworks design for work that was on the shelves of Best Buy 7 months later. It was started just a week or two before COVID shutdown. I created PCBs soon after. Another month or 2 later and you'd have had a really hard time getting any PCB out of JLCPCB due to the supply chain disruption.
This is just being released now, which probably means its been in the R&D pipeline for the last few years. I would wager this is last gamer feature tech that Nvidia develops for quiter a while.
Similarly, if you have one of those office chairs with a pneumatic shock, dropping down hard on the chair may induce an electromagnetic or ESD pulse that shocks the monitor.
There’s a video on YouTube about this somewhere and we were able to confirm their findings.
reply