So are these "specials" being parsed by a grammar?
Would be interesting to see how the interpreter works actually...
I would guess it checks what `defun` is, which is a macro...then expands it, and the expansion should ultimately result in an s-expression, which is then parses? Is this right?
> I would guess it checks what `defun` is, which is a macro...then expands it, and the expansion should ultimately result in an s-expression, which is then parses? Is this right?
Yes, but macros (like special forms, but macros can be user implementable) have some "special" powers regarding controlling the evaluation of the code they produce.
(defun foo (a) (+ a 1)) is a s-expression. For evaluation Lisp expands the DEFUN macro then and this returns a new s-expression. Which then is evaluated.
> So are these "specials" being parsed by a grammar?
Every special operator (and there are only a limited amount and this is not user extensible) needs to be implemented by a Lisp source interpreter or a Lisp compiler. Other tools like a code walker also need to know the syntax.
> Another unusual feature is that methods do not "belong" to classes; classes do not provide a namespace for generic functions or methods. Methods are defined separately from classes, and they have no special access (e.g. "this", "self", or "protected") to class slots.
Love this.
And the multiple dispatch.
> :before, :after, and :around
Guess these are similar to aspect-oriented programming. Maybe useful for plugin systems.
> change-class
This looks pretty cool for GUI apps. So many times you want to change a component to something else.
When people talk about us living in a simulation...you have to wonder if they have ever tried to simulate real liquids (e.g. computation fluid dynamics).
Computer graphics in films gives people an unrealistic expectation of what we can do. I would think a lot of people look at this CGI and then think such things are possible in real-time gaming/simulation.
I love how the nytimes front page is just all Trump and political crap. Literally not a word about this, and if it's real, its like the biggest thing ever.
Yeah sure, but you're singling out them as if it's not the case with every mainstream media outlet. We already know that this type of story isn't what drives revenue and that's why it's not on the front page.
> guessing your current state & figuring out the next one
I look at React from a Backbone lens. In Backbone, you had view with a model that managed a dom element tree. You could render whenever you wanted and exactly when needed.
> functional components...reducing development complications
Hooks and the like just feel like an entirely different programming language. It's impossible to trace what is actually going on. Yet, everyone ends up having to learn all the nuances and rules and know somewhat how they are working under the hood, and then also contort their code to work with hooks too.
React and these big frameworks draw people in because under the hood they are so damn complex that people feel like they could never write something like this themselves. But they don't realize that the code they actually need is extremely simple and something they can easily step-through with their debugger.
> we got directed data flow
We kind of didn't need it though. Think about your SQL database backend. It's a big ball of mutable state, and people get by fine with it. If I have an object, and just listen to changes to it, and re-render, its much easier than having some complicated event-sourcing thing going on.
So much of React's design is chasing this functional-programming purity kind of thing. Contrived examples can be made to look super elegant and clean, but then there are all these edge cases and the realities of interop with a big ball of DOM state. Instead of chasing these kind of concepts, the goal should rather be day-to-day developer experience. Which mostly involves debugging and tracing through code.
> Flow
Ocaml was a terrible choice. Things moved so slowly. No one could contribute. There were just so many usability issues and waiting for things to compile. Just an excuse to use shiny tech. And oh boy did they tell you often about how Ocaml was a great choice for such a project.
...
The peeve I have is the distortion of the ecosystem. For many years to come, no one can stray too far for React to innovate because of the familiarity and risk. Look at projects like Solid, Qwik, etc. It's not Meta's fault but more the community hype machine.
> In Backbone, you had view with a model that managed a dom element tree. You could render whenever you wanted and exactly when needed.
In Backbone, many people over-rendered like crazy. And in a far more disruptive & costly redraw process than React's VDOM. React made rendering much faster & eliminated the complexity in figuring out what and when to render: just redraw, and it will be fast. This joins with Flux/Redux's advantage, to which you say:
> We kind of didn't need it though.
You talk about SQL being a big ball of mud / mutable state & saying we were fine with it. But what we get from Flux/Redux is selectors, where we can react to changes in data & only redraw what we need. Direct data flow let us make our apps much faster, and in a way where we didn't have to explicitly carefully manage all the data-flow dependencies ourselves: here's a pattern to subscribe, here's a pattern to write, and the store works it all out. It was hugely useful.
If anything, the battle here has just subtly intensified over the years. Observables keep simmering along. Lenses were a thing for a bit but faded. Signals seem to be the up-and-coming, with dozens of incredibly high performance frameworks and big names like Angular tracking to them, to much more precisely manage these data-flow problems, all in the name of doing what Redux did: letting the computer quickly figure out what work & rendering actually needs to be done.
Having a formal system for data also has huge upside. The Redux dev tools are an incredible window into what is happening in your app over time. Having a well defined world enables incredible powers of observation: it's a stunning & massive win.
> Hooks and the like just feel like an entirely different programming language. It's impossible to trace what is actually going on.
Anecdata here, but I've been at quite a number of pipelines with strong hire-from-college & hire-from-bootcamp pipelines, and my heavens. These newcomers definitely take to hooks much better, in my view. And it's much easier for me to code review & see the intent & to suss out weaknesses.
Contrary to your claim, struggle to think of coworkers ever actually having to dive into React codebase to understand or optimize code. Understanding when to useCallback is a micro-lesson, but makes sense if you know DOM. If you understand vdom basics you should understand why deps are there and what they're for, but that's still a micro-lesson that needs teaching or sometimes re-teaching, but usually takes 20 minutes. If anything, I think it's staggering & threatening how little people understand their frameworks, but it just doesnt matter.
> there are all these edge cases and the realities of interop with a big ball of DOM state.
What's the use case here? What are we talking about? Why do you need to interop with the DOM? I generally find that writing event handlers in React is no problem at all. Is that what you're talking about? What's the situation?
> Ocaml was a terrible choice.
In retrospect maybe perhaps, but I still think of Ocaml as a brilliantly smart programming language with a huge stock of incredibly talented developers. Maybe yeah it didn't work out, but I can absolutely see the signs of promise, and see why the vision here could have worked out and could have made sense & could have been powerful.
More generally, I don't think this is the avenue of consideration I'd be looking after. What about Flow was bad or overly complicated or otherwise bad? There's arguments against the community failing to take off, sure, but good tech badly supported is a different argument than the "overly complicated" "big ball of mud" grievances.
> For many years to come, no one can stray too far for React to innovate because of the familiarity and risk.
In this I share laments. I myself want to embody the radical revolutionary trying new things ever improving spirit, and the long era of React has been such a giant damper after so many years of tuning in daily to be thrilled with new ideas on Ajaxian & feeds. We have so much more to explore & improve, and we cannot stop here.
But I also think it's unclear what is worth switching for. There are some really alluring interesting concepts out there. Qwik's resumable-ness is a fascinating concept, and a compelling alternative to the typical SSR hydration. I am so excited to see where Solid goes and hope we can see some more shape towards 2.0 emerge. Threads on signals & new signalling libraries get semi-regular traction here on HN & are such a point of excitement & possibility. I keep hoping we'll distill out clear paths for WebComponents, and it seems like Lit does get shipped a decent bit but few others do. Overall it doesn't excite me but I recognize most people are trying to solve business problems, and they are replete with known viable choices & options if they stay somewhere in the huge React ecosystem. It's not just the hype machine to me: there really aren't the clear technical wins yet for most alternatives to become established worthwhile options one can feel confident picking.
It's amazing we don't have good personal content filtering yet. I would pay so much for an all-encompassing blocker.
There is so much content I would block if I actually could. Completely disable YouTube Shorts on mobile. All snarky/sarcastic/political/ad-hominem takes filtered.
There is an interesting take on this on Neal Stephenson's Termination Shock: wealthy people can afford to have personal curators that filter news and other content for them, while the lower classes have been driven off the deep end by the near future Internet's relentless stream of disinformation.
No-code/low-code tools are great for prototypes, but are awful for software that is large enough. for small businesses many will not get to that point because many businesses sink by that time, but absolutely unusable for many enterprise software. Those solutions slow down devs past a certain level of complexity (and that level isn't all that high) but no-code/low-code experts will either not know any better or won't tell you. I have legitimately tried using a few, but they become a pain to work it beyond the initial prototype. I put them in the similar territory as Wordpress because they remind me of the pain of maintaining them.
Non-devs always underestimate complexity of software at scale. Even devs do as well. It's not gatekeeping otherwise, devs would already be out of a job
But then I thought deeper and as an adult I realized that there is a cost/benefit to everything that somewhat didn't exist as a child. Most of us cannot escape triggers of anxiety anymore. If you have everything you need, and complete freedom, you still can't escape the arrow of time for example.
I still think zero pressure doesn't work in the way you think it does. It's exactly something someone says when they are pre-occupied most of the time. It's wishful thinking.
>I still think zero pressure doesn't work in the way you think it does. It's exactly something someone says when they are pre-occupied most of the time. It's wishful thinking.
You'd be surprised how much pressure can go down when you have fuck you money and you don't give a fuck about running some business, the "protestant work ethic", or getting more, just spend it and enjoy life. Met a few such types, and they feel zero pressure.
You still have inevitable stuff to worry about like relationships and health of course.
The unfortunate thing with procrastination is that the anxiety is bimodal. You avoid doing things because there’s anxiety about fucking it up.
Then as the deadline approaches, not finishing at all is a kind of “fucking it up” that is not at all abstract or hypothetical. So now the anxiety of the deadline is focusing you on the task. It’s exhausting for one, and for another when you get a good review on your work you feel like a fraud, because everyone else took weeks to do this and you slammed it out in 6-10 hours.
As someone with ADHD, this is a constant in my life. In an ironic way, the anxiety when shit hits the fan is what makes me deal with stuff. But it's absolutely exhausting.
Would be interesting to see how the interpreter works actually...
I would guess it checks what `defun` is, which is a macro...then expands it, and the expansion should ultimately result in an s-expression, which is then parses? Is this right?