> Clojure for instance or arc use conventions like that to reduce the number of parentheses
Clojure also reduces parentheses by introducing more characters for various data-structures (good and bad, many would say), like [] for vectors, which are for example used for arguments when defining functions
Very cool! I'm curious whether you're using it (or planning to use it) yourself for anything serious or if it's just to see if it could be done. Are you planning to support classes beyond Java 8 at some point?
I'll definitely use it when it becomes usable. And, yes, it needs to support newer versions of Java. Crawl.. walk.. run. But you are right.. part of my motivation was just to see if it was possible. Many years ago, I worked on gcj, which was similar in concept, except that it mapped Java classes to C++ classes (as implemented by g++). I've been on a Common Lisp kick for the past few years, so it seemed like a fun challenge. The fact that the OpenJDK class libraries are free software now makes this more practical.
I definitely get the Common Lisp kick. I dabbled with it before, but then got sidetracked by other languages and back then the REPL didn't click for me. After I understood the power of the live image concept though (and after switching to Emacs), I just want to do every personal project in CL only.
Huh, did you stop watching after episode 1? The HBO series was all about how it was the system that caused the accident to happen. The fact that it was a known failure mode was a major plot point.
If you watch the court scene at the end they clearly repeat the KGB line that the local operators were primarily to blame for "reckless" decisions. Perhaps you missed this obvious conclusion of the series.
People are free to draw their own conclusions from the movie. The conclusions I drew are:
1. Blame game started right away ("Of course you are responsible. I was not even in the building" Bryukhanov to Dyatlov in the night of the explosion)
2. During the test some actions were taken with a complete disregard towards safety and consequences. Some people would call this reckless.
3. If this accident did not happen at Chernobyl it would have happened somewhere else.
As the article mentions, this makes it quite similar to a bytecode vm. I think the traditional wisdom is that an AST walker is easy to write, but for speed you'd want a bytecode interpreter. It'd be interesting to see how close the performance gets with this flattened AST.
In practice I think there are more differences. E.g. AST interpreters tend to pass environments around while bytecode interpreters often store these on a stack (though I guess there's nothing stopping you from doing this with an AST either). I wonder if there's some goldilocks zone for ease of implementation with decent performance.
If you instead flatten the expression tree into RPN, then you can execute it like that, with a stack machine.
I seem to recall that the Red Dragon Book (Compilers: Principles, Techniques and Tools, Aho, Sethi, Ullman [1988]) describes a technique whereby intermediate code is represented in RPN, and transformations are performed by pattern matches on it.
I think it would be more like RPN if it used a stack, and operands were specified as relative offsets (i.e., stack offsets). In the version I wrote, operands are still represented as absolute offsets in the expression table.
Yeah, it's important to note that this design is specifically for local side streets that are only expected to get destination traffic. If it's a busier street, there would typically be a separate turning lane, i.e. a bigger buffer.
As a Dutch person living in the US, a big difference is also that almost every driver in the Netherlands is also a cyclist themselves. In the US there is this almost cultural divide between drivers and cyclists where it becomes part of people's identity. In the Netherlands most people will just choose their mode of transportation depending on the specifics of the trip.
In practice this means drivers tend to do a much better job anticipating cyclists, e.g. by checking for cyclists before making a turn.
The analogy holds in more than one way. For example, iPhones will gain/lose features at the convenience of Apple (even the bigger screen had to wait until a new CEO was in charge). You buy it as it was designed, the same as you buy a Cybertruck. They behave like designer brands.
Chinese EVs are more focused on what people need, and brands have a wider range of offers, similar to how you can find budget or flagship Androids to suit your tastes. They behave similar to traditional auto makers.
> if a function takes a list of records all of which need an x field of type int, then you cannot pass it a list of records where all contain the x field of int but some also contain an irrelevant y field and others contain an irrelevant z field.
Can you explain that a little more? Intuitively I would imagine that those y and z fields would 'disappear' into the rest part.
With subtyping, the type checker would understand that the list type is covariant and would accept a record with more irrelevant fields, because that's a valid subtype.
Without subtyping, the rest part needs to be identical for each element of the list. In fact you cannot even express the concept of a list with different rest parts. The key thing to understand is that the rest part never really disappears. The type checker always deduces what the rest part should be in every case. In languages like Haskell you can work around this by using existential quantification but that's a whole different extension to the type system, and one that's certainly not as flexible as full subtyping.
> It is possible to use a JIT model for this but AFAIK it is typically not done.
Isn't this what the last line of the article is hinting at?
> our WebAssembly team is making great progress rearchitecting the Wasm compiler pipeline. This work will make it possible to Ion-compile individual Wasm functions as they warm up instead of compiling everything immediately.
Your attitude to call out where htmx might not be the best solution, makes me respect the project even more. It's refreshing to see this compared to lots of other projects that always seem to claim to be the best solution for everything.
I'm curious in particular about the call out around drag-and-drop. Is that something you agree with? Is drag and drop difficult with htmx and if so, is that something you plan on tackling?
Like most of the examples on the htmx site it is pretty bare bones (we keep it that way to focus on the concepts) but it's a reasonable demonstration of the integration. Whether that is good enough of course depends on your use case
If you want an integrated and polished ecosystem that's something htmx isn't going to provide: it's a library focused (mainly) on one thing: generalizing hypermedia controls. So, when you want client side functionality like this, you are going to have to glue things together a bit. I completely understand the desire of having an integrated ecosystem to avoid doing that.
after having used both: sortablejs is better than reactdnd.
that being said: htmx makes it too hard to quickly add a fat frontend to a page when necessary. The points about the react ecosystem are very valid, even if drag and drop is an exception. The network effects of react and others are hard to beat. Its probably even more npm as a whole than just react.
Thanks! That actually seems very smooth. Trying out htmx has been high on my list for a while when I finally get time to do a little personal side project. Real life keeps getting in the way, but this is a good nudge. The appealing thing about htmx to me is that it seems like it should be very easy to keep everything in your head.
I've used hotwire a bunch, and with minor differences, I think the list of things that htmx is not good for is spot on.
I don't think I'm explaining this well, but maybe this will help someone: Hotwire / htmx are about server-side rendering and making that work more smoothly with the client. eg fewer page navigations, more rapid update of the client, etc. But it's still, through and through, server render with server state.
It works well as long as the server is always the source of truth. The things that it isn't good at, such as drag and drop or complex, multi-state forms on the client side, are basically because you temporarily have a split source of truth: the client is the source of truth with complex state.
That said, my strong suggestion would be to use Hotwire or htmx for 95% of your project even if the main interaction loop is done in react. Your app will still likely have tons of crud around user management, settings / config, onboarding, etc. You can make all that work more nicely.
edit: in case it wasn't clear: for the things that are in the hotwire/htmx wheelhouse, the tech works really well. It's a fantastic improvement.
> 95% of your project even if the main interaction loop is done in react
The trick is to be very honest with yourself (and team) about how much complex front-end UI the application actually _requires_. Using React where it isn't necessary is very expensive in the long run. The older I get, the more the grug brained developer makes sense.
The more I work with React, the more I realize I just don’t have the motivation to learn and keep up with more than one way of doing front-end. Using it everywhere is working out pretty well for me.
Sometimes it’s not the best choice for the app I’m working on, but it’s always thr best choice for me.
Me neither. In the 2000s, Tor did something similar (a "what Tor can't do" page) and prominent linked to it on the front page, which definitely improved the project's reputation with a coterie of infosec professionals.
It might not have helped with wider adoption though. People would send me the link saying "Look at all of these bad things about Tor", and it would be links to Tor explanatory pages.
It was around that time that I realised that when trying to give people an intuition for what software many Internet professionals trust, the list of "green flags" I identified was, in fact, the exact opposite of what the majority might guess as being good signs. "Large list of attractive sounding features" vs "Lists problems with the tool as prominently as benefits" ; "Sold and marketed by a large well-known company" vs "Developed by a small, volunteer team" ; "Free to download" vs "Costs money"; "Modern, professionally-designed website" vs "Looks like it was built in 1997", etc, etc.
It's not quite the same but SQLite has a page where they clearly present its limitations and how to identify the situations where you should choose something else.
Which is exactly what shouldn't happen. Every serious proposal/RFC needs to have an honest stab at what the competition looks like and why it won't work there.
> I often see people believe in their solution and think theirs are better than the others. They defend their cases without having an exact reason. These situations often create long and meaningless discussions that go nowhere.
Agreed. Too often you'll see HN's claim that PHP / Java / MySQL are the best choices for everything, where often times they are blind to specific problems and use-cases that other developers are trying to solve.
See e.g. cond in clojure: https://clojuredocs.org/clojure.core/cond