a:b is almost universal as a range designator at this point. / is a _terrible_ choice, especially in a context where a fractional value would also make sense.
That was just an objectively bad syntax choice, but probably keeping on track with CSS.
No, the title and book focus on Ireland’s role but that does not in any way diminish the contributions of others. The relationship of Moors in Iberia and Seljuks in Anatolia was more adversarial however.
> but there's also merit to letting the kids choose to hit pause
Why is there a "but" there? Nobody is implying that children should be strapped to a chair with their eyelids propped open with toothpicks so that they have to watch all the gory details of a horror movie.
Looking at the original article, that was for sure the subtext (especially in light of the fact that its coming from an unapologetically Christian source). Their pushback seems to be "parents are trying too hard to protect kids from disturbing images/themes", but also (quoting directly here) "have we swung so far in our attempt to protect children that we don’t tell stories that help them process dark things?"
I resonate strongly with the idea that children today are sheltered too much from how the world really is. But I definitely disagree with the idea that we should force them to listen to those "truths" when they can tell for themselves that they aren't able to deal with them. The article expends a lot of words on the idea that good and evil are atomic unto themselves, and not at least partially determined by both outcome, intent, and method. I guarantee that kids in general, and my kids specifically, won't be helped by hearing about (as expressed in the article) Cinderella's step-sisters hacking off their toes and heels to fit into the glass slipper. There are loads of other tropes in classic fairy tales that I'm also uncomfortable with; physical beauty is a reflection of inner beauty, step-mothers are always cruel to their step children, princesses (or marriages in general) as prizes for the heroic feats of princes/knights errant/other adventurers, etc.
Fairy tales often seem needlessly cruel given the current state of our society, and they also pack in a lot of warning messages that just don't apply anymore, and clinging to them is itself harmful to kids.
You might want to read the TFA, it's describing a "whole other language" they call Hyperscript
on click send htmx:abort to #contacts-btn
on htmx:beforeRequest from #contacts-btn remove @disabled from me
on htmx:afterRequest from #contacts-btn add @disabled to me
hyperscript is a completely separate technology from htmx, it is designed to be an alternative to javascript and is very speculative
htmx generalizes hypermedia controls, that's pretty much it, and it can be used with any scripting tool you'd like: AlpineJS, hyperscript (if you are brave), vanilla js, etc.
All the hx-* attributes constitute a separate DSL with its own semantics and it requires the server to conform to this DSL that also subsumes a bunch of existing HTTP semantics like redirects.
<!-- Some kind of inline DSL in an attribute? Check -->
<div hx-get="/example"
hx-swap="innerHTML show:#another-div:top">
Get Some Content
</div>
<!-- Some kind of inline DSL that is sorta kinda JS? Check -->
<div hx-get="/clicked" hx-trigger="click[checkGlobalState()]">Control Click Me</div>
<!-- Some kind of inline DSL that is marked as Javascript and with magic values passed in? Check -->
<div hx-get="/example" hx-trigger="keyup" hx-vals='js:{lastKey: event.key}'>
<input type="text" />
</div>
<!-- Is it Javascript? Jinx, it's custom DSL -->
<button hx-get="/info" hx-on::before-request="alert('Making a request!')">
Get Info!
</button>
<button hx-get="/info" hx-on="htmx:beforeRequest: alert('Making a request!')
htmx:afterRequest: alert('Done making a request!')">
Get Info!
</button>
we are tentatively working on a proposal with the chrome team that takes the most important concepts of htmx and integrates them into HTML using more standard attributes. Alex Petros, a core htmx dev, gave a talk at Big Sky Dev Con on this idea here:
I'm convinced you can get most of htmx by extending standard attributes to other elements and using the standard on* attributes. htmx basically acts as a "universal/general event handler" that translates DOM events to requests and back to DOM events and modifications. It breaks down like this:
* use on* html attributes to delegate events to a universal event handler
* event handler pulls out the form attribute (if set), then pulls out action, method, target from element, or from the form if unset on the element (elements inherit these from the form they are tied to)
* if action is a URL, then initialize a fetch request using specified URL and method; if method is POST, then add a FormData payload for the specified form
* on fetch complete, the returned MIME type should match with the target attribute, which is extended to also accept a css selector:
yep I think you could do a lot in this direction (see Alex’s talk) I would be hesitant to hijack existing attributes for more than a proof of concept at this point but maybe that’s me being too timid.
htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes: https://htmx.org/reference/#attributes
--- end quote ---
All my examples come directly from htmx documentation
sorry! Got you crossed up w sapling-ginger above and thought I was talking w the same person.
agree that htmx has a regular language core for config options but, as hyperscript indicates, I’m not afraid of even a recursive language when I think it’s useful.
Hopefully we can get some of the ideas into HTML in a more standard form!
I would love for the authors to consider a book on Hyperscript.
I initially dismissed wanting to add another scripting language to an app, but after some experimenting I have used it to replace 100s of lines of JS. Mainly for UI animations.
It’s not for the faint of heart, but enjoyable to learn.
I find the docs difficult to follow and would enjoy another hardback manual to sit next to this book, which is superb.
The point isn’t to erase the need for JavaScript entirely, but to make it possible to integrate and interact with a backend in a meaningful way using just mainly html.
It's enough to read the context of the discussion, don't you think?
Original complaint: "it's describing a "whole other language" they call Hyperscript"
Response: hyperscript is a completely separate technology. htmx generalizes hypermedia controls, that's pretty much it, and it can be used with any scripting tool you'd like
My response:
In reality [1] htmx defines its own non-optional DSL that you have to use.
---
I will add that as with any organically grown nice-to-have utility DSLs it's quite haphazard (it's hyperscript-like in one place, js-like in another place, both in some other places etc.). But that's the nature of such ad-hoc informally specified DSLs
[1] which can be easily verified by just visiting https://htmx.org
The only place where it talks about anything else is a small section on scripting with a link out to a huge meandering essay with small examples lost in all the philosophical discussions.
Edit: Don't forget also that this is entirely non-optional because if you use htmx, you will load the full support for it whether you use it or not
If the owner cannot generate any revenue from owning the plot, then it is not a "land-like asset" and it just doesn't factor into this discussion. A "land" in LVT is not necessarily literally land, although the way most virtual worlds are programmed, the "land" in the game often has functions similar to real-world land, which makes it LVT "land".
a) HN is more than 1 person. People will have various opinions
b) NPM is a repo for open source. Garbage can be easily inspected. I have no issues with packages I am using. Decompiling APKs is not something I am keen to do
c) 20 testers won’t raise Play store quality. Scammers already have click farms or can purchase this for cheap. Better automated review tools and more importantly more humans in loop can help the quality. Maybe submitting code to 3rd party to get some “seal of approval” (not mandatory but boosting score?)
The upper estimate of the number of galaxies in the observable universe is 2 trillion, which is far too few to find Shakespeare written with "galaxy dots".
No, you don't need a massive dictionary. Remember that the topic of this thread is a circle composed of galaxy "dots".
An elongated circle can be the letter O or perhaps zero. You can similarly compose other letters visually using galaxy dots, and that's presumably what the original poster meant when talking about writing out a Shakespeare. If the universe was infinite, this would be a possibility.
You say "just add copy and move contructors", but that requires function overloading, which is exactly why he spent a third of the article ranting about name mangling. The point is that there is a tangled network of interdependent features that make C++ work, and you can't ""just"" take a small piece to put into C without dragging a whole bunch of other stuff along.
The author first says that CL people usually avoid dependency hell:
>When programming applications in Common Lisp people will often depend on a small(ish) number of stable libraries, and library writers often try to minimize dependencies by utilizing as much of the core language as possible.
But then try to expound on CL's extensibility using libraries:
> No one has been clamoring for a new version of the specification that adds features because Common Lisp's extensibility allows users to add new features to the language as plain old libraries
Very contradictory, and these two paragraphs are in two adjacent sections.
As other pointed out, there's no contradiction. I would like to add that CL often avoids dependency hell with:
- Standardized Specification: Common Lisp has a stable and comprehensive standard that reduces the need for external libraries.
- Load Time Flexibility: Its dynamic nature allows loading and reloading of code at runtime, facilitating easier management of dependencies.
- Isolation through Packages: The Lisp package system provides a way to encapsulate code and manage namespaces effectively, reducing conflicts.
- Backward Compatibility: Common Lisp places a strong emphasis on backward compatibility, which helps in maintaining stability across versions.
- Mature Ecosystem: Many Common Lisp projects are long-lived and stable, leading to a mature ecosystem with less frequent breaking changes.
I can't claim to be a very experienced CL coder, but I wrote enough Clojure, and similarly, rarely ever see dependency problems, even though Clojure heavily relies on the JVM ecosystem, inheriting both its strengths and complexities. Clojure emphasizes interoperability with Java and uses many Java libraries, which can introduce complex dependency trees and conflicts common in the Java ecosystem, yet at the same time, Clojure emphasizes small, composable libraries (often referred to as the "small libraries" philosophy), reducing the likelihood of large, monolithic dependencies causing issues. The community prioritizes modularity and ease of composition, leading to the prevalence of smaller, more focused libraries. Common Lisp in contrast tends to favor more extensive libraries or systems that provide a broad set of features within a single package.
The thing is that’s once you’ve casted most external inputs to lisp data structures, you don’t really need anything else other than utility algorithms (crypto,…). And with metaprogramming, it’s easier to do stuff without special classes and decorator. You can visualize the code as data being transformed, as a chain of transformers, or when you do metaprogramming as data generating code and code generating data. It’s all organic and you can do a lot without external code, because very soon you’re coding with a language adapted to your problem domain.
To GP: Think about how simple the HTTP protocol is (the core), so if you want a web framework, you want something that will map the headers and the body to cl data structures and then you can go to solve smaller problems like routing, auth, response generation,… Then you notice boilerplate and you macro them out. Same for most client libraries. It really easy to add an ad-hoc library that solve your problems. So you do that instead of reaching to others’ code.
The lisp world has a rather different idea of extensibility via library than you are used to.
For example, the Common Lisp Object System (CLOS, object oriented programming in lisp) originated as a library. Lisp's main looping mechanism (loop) also originated as a macro (although long before CL standardization).
You just don't do js levels of dependencies when they're adding big features like that. You don't need 100,000 programming paradigms in your code base.
