My favorite Tcl story is a little side note about how Tcl could have been the language of the web[1]
the founding of Netscape occurred at the same time I was deciding where to go in industry when I left Berkeley in 1994. Jim Clarke and Marc Andreessen approached me about the possibility of my joining Netscape as a founder, but I eventually decided against it (they hadn't yet decided to do Web stuff when I talked with them). This is one of the biggest "what if" moments of my career. If I had gone to Netscape, I think there's a good chance that Tcl would have become the browser language instead of JavaScript and the world would be a different place! However, in retrospect I'm not sure that Tcl would actually be a better language for the Web than JavaScript, so maybe the right thing happened.
Too humble Dr. Ousterhout! It would have been a far better language.
I was leading a Tcl project around then, and, though there were some very neat things about the unusual Tcl evaluation model, I wasn't a fan of using it for nontrival work. For example, it wasn't a natural fit for working with graph structures like I had to, and like you might want for browser DOM.
(That said, Tcl would've been much better than JS, and I suspect that Ousterhout would've figured out some smart things to make it good for the browser.)
Maybe 5 years later, I was meeting with Tim-Berners Lee, and I kinda pitched Scheme to him, without planning to, but he was very interested when he asked what I'd been working on.
But then he went and did a conference keynote, in which he promoted Python as the language for ordinary people doing Web stuff. And I think he referenced one of the things I'd written in support of Scheme... as an anti-requirement for his populist vision for the Web. :)
(I wish I could've been involved in that, because I could've made a case for a populist spin on Scheme at the time.)
TCL has an extremely loose runtime model, not to mention everything in the language is basically a string and all that entails.
I’ve been using JavaScript since the early 2000s, just before ES5 dropped.
Like all languages it has its curveballs but it really isn’t all that bad. It simply has oddities due to the quirky nature of the niche it was designed to fill (namely, to be a scripting language that was forgiving to web designers)
I don't get it either? I've only used it occasionally but it has always struck me as a really impressive example of what can be built on minimal (minimalist?) foundations. Its semantics can understood in 5 minutes.
It reminds me of Scheme in this regard. Writing an interpreter or compiler for it would be easily within reach of an undergraduate student. Contrast with other currently popular (more respected?) languages like Rust, C++, Java, C# or even Python.
I've only recently been expose to Typescript and again, I'm really impressed. I haven't encountered a type system so elegant and orthogonal since first being exposed to ML like languages.
Your definition of "semantics" must be different from mine, or you perhaps haven't seen https://javascriptwtf.com/ (linked in a sibling comment)
Your comment actually made me wonder whether those cited artifacts were implementation bugs or actually in the specification and ... lol, this shit reminds me of people who put comments above functions that just restate the function's name: https://tc39.es/ecma262/2024/#sec-addition-operator-plus
> Writing an interpreter or compiler for it would be easily within reach of an undergraduate student
Surely you don't really believe that? Or is the rest of the sentence "... eventually, over the course of their undergraduate career"
The 15th edition of the standard is 816 pages and now includes specifying the Memory Model. What I suspect you mean is "could write a parser for the 1st edition spec from 1997"
I'm claiming that its semantics are simple, not that they've made great choices in the design of the language. For example, I've barely used Javascript, but I think I would have scored fairly highly if that javascriptwft page was turned into a quiz. Most of the examples are fairly transparent once you know the implicit casting rules. I've read certain wtfs associated with C++ or even Java far more puzzling despite years of experience with them.
And yes I do believe that writing an interpreter for Javascript would be no more difficult than doing one for Scheme (which I had to do as a student) - the parser would be more difficult admittedly.
I can find oddities like this in all languages. Arguably C and C++ have more warts, particularly C++ where I always hear people talk about how it’s only reasonable to use a small subset of the language. Also how C/C++ compilers don’t all support the same features of the purported language they compile.
I won’t argue that JS doesn’t have warts - it does and if it wasn’t for backward compatibility I imagine they’d have been removed from the language - but the entries on that website are quite small compared to others - like C and C++ - that I can think of
> not to mention everything in the language is basically a string and all that entail
I disagree with that to at least some extent. Everything is a string works well in TCL because the language is built around that abstraction. It works at least as well as other dynamically typed languages in small projects, and is definitely preferable to Javascript's rather weird weak typing.
It also does async and multi-threading really nicely, and encouraged event driven long before it look off elsewhere.
I used Tcl briefly to build an interface way back with Tcl/Tk, and it is a terrible language. "Everything is a string" is not what you want in a solid programming environment for larger projects. It's a LISP-like gimmick, but without the advantages of LISP.
That said, plain JS is not a good fit for larger projects, either. It really needs TypeScript for that. But it does have some very fast engines.
In the early days at least part of the problem was marketing. The fact that it’s got Java in the name when it’s actually a very different language to Java confused a lot of people. They tried to use the language like Java, had a bad time and concluded the language was bad.
Honestly? I think the biggest cause of JavaScript hate is that a huge percentage of developers have very little choice but to use it.
The web ate almost everything else for a host of reasons, and JavaScript is still the only language that the web natively supports. You can compile to JS or use WASM with occasional callouts to JS, but you can't get away from it entirely.
Most other languages have a greater sense of choice surrounding them. For backend work you can pick pretty much anything, and mobile is still a small enough chunk of the ecosystem that if you really hate Swift you can just find a job that isn't iOS dev. It's not so easy to get out of web dev without dramatically shrinking your job pool.
All I can say is that’s the cost of doing business with the browser being the main platform.
If devs want to interact with it less then focus on moving more to the server. You can still serve HTML and CSS and get a long way without ever touching JS.
It’s no different than other domains where one or two particular languages largely dominate. Like I don’t hear developers decrying the existence of C/C++ every chance they get
I think the hate is entirely unjustified. It’s fine to have preferences but so often it goes beyond that.
I have, but they’re not quite as zealous. The anti JS campaign has been running almost as long as I’ve been using it, which is pushing two decades now.
Now I know why PHP devs sometimes get a little defensive
I think Tcl as it was back then especially would have been a terrible DOM manipulation choice. I love the language but the hacks frameworks like openacs used to use to imitate basic stuff like a list of database records are among the ugliest upvar/up level hacks I've seen.
But that being said it's an incredibly adaptable language and I have zero doubt it could have been adapted to make DOM manipulation ergonomic.
I like Tcl and I think it has some very admirable traits. That being said, I don't even want to picture the hellscape of an ecosystem that would have flourished if it became the language of the web. JS was the better timeline I will admit begrudgingly, and that includes the Scheme timeline as well.
Does Tcl have lexical scoping yet? If not, I'd have to disagree that it would have been a better language. JS is not one of the better languages I know, but it does have lambdas and lexical scoping. And as bad as JS's type system may be, at least it's not stringly-typed.
By incorporating DyT, Transformers without normalization can match or exceed the performance of their normalized counterparts, mostly without hyperparameter tuning.
Yep these are the only ones I’ve found essentially! I don’t find Kara swisher to be very intellectually interesting but Scott certainly is. What he needs, for his platform to really blow up IMO, is to host a show with a panel that argues like All-In, but again, on a more moderate or left-ish political al axis.
Interesting ideas. I think in any practical system, you'd still need some central authority that determines:
a basket of basic, thickly traded commodities should be chosen; perhaps a basket of specific amounts of basic elements, thermal and electrical energy, and basic food commodities, priced as delivered to several large markets.
and
A control algorithm such as the PID loop used in process control or robotics is employed to adjust K over time.
At a minimum, those aspects of this currency would need to be flexible such that they can be adjusted over time, as needed, to maintain the currency's stability.
An inflexible scheme seems like it would be doomed to failure. And yet, any tinkering could also be its demise and undermine its stability and faith in the system. It's a delicate balance.
Ultimately money is a social construct based merely on shared belief. Algorithms can used to enhance and support this social construct, but I do not see how it could wholly replace human/social interventions.
The "central authority" that determines the composition of the basket -- is the users of the money.
The thing about non-fraudulent, wealth-backed money is that there is no barrier to entry, nor is there a barrier to exit. Unlike usury-based money, a wealth-backed currency can cleanly decrease in usage, down to zero. People withdraw wealth pledged to created the money, by returning the amount of money created, and then take their wealth elsewhere.
Thus, if people don't like the valuations arrived at by the "basket" underlying the value of each unit of money (ie. something becomes undesirably in/deflationary), they can move to another form of money -- ideally, one that constitutes its "basket" based on a more representative set of the society's basic commodities. In the ideal embodiment, this basket would evolve over time (eg. as energy production moves from coal to oil to natural gas to nuclear to renewables over the years, for example, the energy commodity component of the basket would be revised automatically).
As for the PID loop, there are much more advanced controls methodologies that improve error rejection (eg. Kalman filtering), stability (Model Predictive or State Space control), etc. Furthermore, limits on the introduction (or withdrawal) of wealth (and hence newly created units of money) should reflect the current size of the ecosystem to limit shocks that would adversely interfere with the control stability. (ie. you can't create 10x the current size of the economy in newly issued money all at once.)
This is exactly the sort of thing that will make people seek out a replacement central authority. Most people don't want to, and won't, micromanage their "currency" like that.
They just want a medium of exchange that changes value slowly enough that they can be reasonably sure they know what the currency is worth. If cryptocurrency somehow replaces fiat money, people will turn to financial companies and pay an extra fee so that they bring back the advantages of the fiat money.
99.9% of users will just appreciate the fact that their money retains its purchasing power (as measured in civilization supporting commodities), across multiple generations. Not just for a few years; their grandkids will be able to purchase the same amount of "stuff" with it).
Those that want to create wealth and then monetize that wealth to (for example) purchase property or businesses will appreciate the non-corruptible value management features.
> will just appreciate the fact that their money retains its purchasing power
I don't see how cryptocurrency enables this, because I don't think this is the result of currency being fiat. I think it's a result of currency being a token of wealth rather than wealth itself.
> will appreciate the non-corruptible value management features.
I can't comment on this because I'm not really sure what you mean by it
And this is the architecture as designed and recommended by the KX consultants that you end up having to hire to “scale”
I think this hits on one of the major shortcomings of how FD/Kx have managed the technology going back 15+ years, IMHO.
Historically it’s the consultants that brought in a lot of income, with each one building ad-hoc solutions for their clients and solving much more complicated enterprise-scale integration and resilience challenges. FD/Kx failed to identify the massive opportunity here, which was to truly invest in R&D and develop a set of common IP, based on robust architectures, libraries and solutions around the core kdb+ product that would be vastly more valuable and appealing to more customers. This could have led to a path where open sourcing kdb+ made sense, if they had a suite of valuable, complementary functionality that they could sell. But instead, they parked their consultants for countless billable hours at their biggest paying customer’s sites and helped them build custom infra around kdb+, reinventing wheels over and over again.
They were in a unique position for decades, with a front row seat to the pain points and challenges of top financial institutions, and somehow never produced a product that came close to the value and utility of kdb+, even though clearly it was only ever going to be a part of a larger software solution.
In fairness they produced the delta suite, but its focus and feature set seemed to be constantly in flux and underwhelming, trying to bury and hide kdb+ behind frustratingly pointless UI layers. The more recent attempts with Kx.ai I’m less familiar with, but seem to be a desperate marketing attempt to latch onto the next tech wave.
They have had some very talented technical staff over the years, including many of their consultants. I just think that if the leadership had embraced the core technology and understood the opportunity to build a valuable ecosystem, with a goal towards FOSS, things could look very different. All hindsight of course :)
Get a free version out there that can be used for many things…
I think this has been the biggest impediment to kdb+ gaining recognition as a great technology/product and growing amongst the developer community.
Having used kdb+ extensively in the finance world for years, I became a convert and a fan. There’s an elegance in its design and simplicity that seems very much rooted in the Unix philosophy. After I left finance, and no longer worked at a company that used kdb+, I often felt the urge to reach for kdb+ to use for little projects here and there. It was frustrating that I couldn’t use it anymore, or even just show colleagues this little known/niche tool and geek out a little on how simple and efficient it was for doing certain tasks/computations.
I had to write some C++ code in the past to send data into kdb and also a decoder for their wire protocol. For both I definitely had a kdb binary to test against.
I just needed to test against it. Maybe Kx gave us a development license or something, it was a good few years ago.
Kerf1 has only been open source for a fairly short time, and prior to that it was proprietary. ngn/k is tremendously less feature-rich than Q/k4, has some built-in constraints that make building large programs difficult, and does not come with the "batteries included" necessary for building distributed systems. Neither is currently a credible alternative to kdb+ for production environments.
"Replika" was the app most of them were buzzing around last I checked. There was some boondoggle with paid plans, I think the app had tried to focus on that subcommunity as whales (singly focused big spenders).
Probably start there and see where they've gone now.
Not exactly AI girlfriend territory but has a lot of overlap with it (as well as a lot of overlap with mental illness and probably occasionally just plain old cringy teenagers) but r/waifuism is also pretty similar.
1 - https://pldb.io/blog/JohnOusterhout.html