How big of a Carmack fan are you really, if you don't know one of his most well known takes on programming? (And you definitely don't need to be a fan.) Carmack has been heavily in favor of leveraging power tools since way back.
Direct quote from the man himself:
> I will engage with what I think your gripe is — AI tooling trivializing the skillsets of programmers, artists, and designers.
> My first games involved hand assembling machine code and turning graph paper characters into hex digits. Software progress has made that work as irrelevant as chariot wheel maintenance.
> Building power tools is central to all the progress in computers.
> Game engines have radically expanded the range of people involved in game dev, even as they deemphasized the importance of much of my beloved system engineering.
> AI tools will allow the best to reach even greater heights, while enabling smaller teams to accomplish more, and bring in some completely new creator demographics.
> Yes, we will get to a world where you can get an interactive game (or novel, or movie) out of a prompt, but there will be far better exemplars of the medium still created by dedicated teams of passionate developers.
> The world will be vastly wealthier in terms of the content available at any given cost.
I've seen that before. Re-reading it, I don't really get the same "vibe" as antirez's level of AI advocacy. You also conveniently omitted the last paragraph of the tweet:
> Will there be more or less game developer jobs? That is an open question. It could go the way of farming, where labor saving technology allow a tiny fraction of the previous workforce to satisfy everyone, or it could be like social media, where creative entrepreneurship has flourished at many different scales. Regardless, “don’t use power tools because they take people’s jobs” is not a winning strategy.
But yeah, it (almost) sounds like an ad for AI, but I like to believe it's still a measured somewhat neutral stance. The difference is that Carmack doesn't consistently post things like this unprompted, unlike antirez.
An influencer, who could more than likely blow 99% of us out of the water when it comes to programming by hand with absolutely no tooling, at whatever level of abstraction. Same probably applies to Antirez.
Why? I'm so confused why would you expect a build tool to depend on a x11 client library, besides the fact that both starts with the letter x. Does it also upset you that xamarin and xaml has nothing to do with xlib, xmake, or to each other?
A side thought, how would a natural number sequence of hypotenuses that satisfies the equation a^2 + b^2 = c^2 look like? Or what interesting properties would it have if any.
The difference is in the ownership and lifetime of the state used by the function. A pure function uses state that it owns or is not outlived by the mutable state it uses. Closures on the other hand uses that it doesn't own or is outlived by the state during the invocation.
The important detail here is that closures automatically moves the variable that lives in the stack frame into the heap. You can't do that with a regular function. In languages with manual memory management like C, if you try to store and use a pointer to a invalidated stack frame, you will either get a crash if you are lucky, or get a crazy bug that shouldn't happen within reason.
Your supporting and concluding statements are directed at a scarecrow though. The person you are replying to isn't contending that closures and objects are different, they are specifically saying that closures and (regular) functions has an important distinction, which I agree.
Although I would say the person you are replying to did have poor imprecise wording on their part.
It should be noted that most of those issues are created by opening a link that bun creates when it crashes, they are not yet reviewed/confirmed and most likely a lot of them are dulplicates of the same issue.
Kind of uneconomical that they have different designs for left-hand and right-hand. They could have just placed the trackball or a nipple in the middle of the keys, and mouse function keys on any side. The hand still need to move and travel anyway with the current design to reach for the mouse keys.
It's not the same, defer does not conditionally interrupt the flow of execution, it will always run at the end of a block. If I see a defer, I am absolutely certain that whatever is deferred will run. The same is not true for exceptions. If I am not mistaken defer just moves the code at the end of the block, no jumping is involved.
> It's not the same, defer does not conditionally interrupt the flow of execution, it will always run at the end of a block.
But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block.
> If I see a defer
The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need to read the entire function. That's non-local reasoning, which is what Zig professes to abhor.
And in fact defer is worse than destructors here, because a destructor runs the exact same code every time, whereas defer allows arbitrary code, so you need to review every single usage. And you also need to remember not to forget to use it in the first place (which is the classic footgun with defer), so in addition to vetting everywhere you use it, you also need to vet everywhere you might have forgotten to use it.
> But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block
Why bring up destructors, I was talking about exceptions. Destructors and exceptions are orthogonal concepts, one can be implemented independently of the other. I'm specifically referring to try-catch blocks like those in java.
Compare this:
try { foo(); }
catch { bar(); }
to this:
defer bar();
foo();
In the first one, bar() may or may not run depending if there's an exception. In the second one, bar is guaranteed to run. Thus, it means defer does not conditionally interrupt the flow of execution.
> The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need to read the entire function.
What? You don't need to read the entire function, you only to scan or check for defers scoped in a block, or in some cases, just the top of a function or block. Wanting to just read the end of a function is unreliable anyway with the existence of early returns (which defer fixes by the way).
You could have made a more compelling (but not necessarily a valid) case by citing zig's try-catch, which makes me think that you are just arguing in abstract without actually having tried writing code that uses defer, or any zig code for that matter.
I cite destructors specifically because Zig denounces destructors as "hidden control flow" while presenting defer as a non-hidden alternative to destructors, which I find to be an incoherent philosophy.
But you were originally talking about exceptions. As I said, destructors and exceptions are distinct concepts, you can't just suddenly interchange those two terms as that would invalidate my whole disagreement, unless you wanted to shift the goal posts a bit to the side.
Kotlin uses var/val too[0] which is what Java is trying to copy. I have never written any kotlin code before, so I don't know if this would be a problem in practice. On the plus side, var and val both have the same length, so the variable declaractions are properly aligned. The names are also intuitive as far as I can tell.In theory, I'd probably be okay with it.
Not a problem in practice as you use val 99.99% percent of the cases (which shows why immutability should be the default, because most often that is needed) and Idea underlines any mutable references, so the sticks out. It also suggests val when a var is not actually mutated.
Why should it be the router? A saner option is to let the parent component coordinate the data fetches for the child components. What you are suggesting is way out of the normal responsibility of a router.
The router is just the most parenty component. It’s the component that takes some input (like a url) and uses what is essentially a giant switch statement to decide what gets rendered.
reply