steinuil

> The package format is entirely static.

...what does this even mean?

Are all the packages linked without dynamic dependencies? That doesn't seem to be the case, since maintaining build rules for enough statically linked packages would have a bus factor of way more than 0, as the project claims.

Is it that the package manager's packages are all stored in a git repo? Tons of package managers nowadays do that.

Is it that the package manager's package definition use a custom format that is not well specified and has enough features to make parsing non-trivial, just because the author doesn't want to use jq or write their own json parser in shell? How is this pile of files more static than json?

If it's none of those things this just seems like a buzzword thrown in for no particular reason.

I also do the same for every album that enters my collection and I share a similar distaste for getting info directly off of online sources. Rather than an auto-tagger I've actually thought about writing a tag linter: something that checks that every track in my library is tagged according to my guidelines, maybe even reference online services for reference to check that there's no albums with missing tracks or that there's no typos, or that every track has cover metadata, and so on.

This is a good thing to think about if you want to make something a habit, or you simply wanna do it more often. I picked up some hobbies that I hadn't been doing very often since I started working by writing some glue code and setting up some programs so that when I want to do the thing, everything's already set up for me to start, and I don't have to dedicate any mental capacity to searching for the things I need and so on.

For an example more related to programming: in my last gig at work I had to develop some react components for this massive project, and there was a folder containing hundreds of components that had to have a specific file structure (one file for the component, one for the tests, one for the types, one for the SCSS styles, one for the storybook), so to create a new component there was a lot of boilerplate you had to write every time.

You could see that this was influencing the internal design of the components: people tended to prefer writing massive components that handled lots of state and displayed lots of things at once instead of breaking everything up into smaller, more manageable components.

Just writing a script that set up all that boilerplate automatically improved both the workflow of the developers and the design of the code, because people were more likely to create a smaller separate component when working on a feature rather than lumping everything into one monolithic component.

Middle school is bad just about everywhere, not just in the US. All the teachers I've talked with (mostly in Europe) also observed the same thing. Keeping kids in school at that age is just a bad idea, and if anything that's what should be abolished completely.

High school in Europe, where there's no extracurricular activities added into the mix, is mostly fine, and kids that have a bad time there are usually just carrying mental scars from middle school.

This actually makes reading comments tolerable.

> This seems rather a simple task, however, the app is expensive

It's easy to do it in an unreliable way. 1000$ a year doesn't seem very expensive if your business depends on it and you're saving a lot of time like in the OP.

> and limited with the templates for things it can count

It seems very specialized towards certain businesses, if you have a specific use case that isn't covered I'm guessing you can probably contact them and see if they can add it?

Apparently this is in preparation for the new "Proton UI", which is one of those things the design teams in big companies do to justify their existence.

I just downloaded Nightly, which already has the Proton UI, and indeed compact mode is hidden behind an about:config option and it's a bit taller than the one featured in the current UI. I really can't fathom why this has to be the case.

This is nothing new, "static" software with yearly licenses has always been around and if anything it's a guarantee that bugs will get fixed, features will get added and your data won't be sold to third parties.

4chan does strip exif data. Sometimes when people posted photos with location data somebody would notice and order a pizza to their location, back when it was still a relatively civil place, then at some point they started removing it.

I wasn't criticizing DSLs in general, they're great, but in the specific case of web development I prefer React's approach over using a DSL like most other frameworks.

> It's a set of AST nodes.

Ok, but you could make the same point about plain JS as in Svelte. I haven't looked into it too much, but from the readme Solid.js looks more like a compiler than a library, so whatever it outputs when it sees JSX doesn't have much to do with what JSX is usually used for, imo. I've only ever seen it used as syntactic sugar for function calls, be it `React.createElement` or `h` or `jsx`.

> At some point if one jumps the shark, so to speak, and starts making uncomfortable contortions to stay within the confines of "just javascript" and avoid DSLs at all costs, that amounts to leaving a useful tool unused at the table, where it could have been effective.

Personally I find it much more likely that I'll have to bend over backwards when I'm dealing with a DSL rather than just plain code, because the DSL will be really well optimized for one usecase, but has omitted another usecase that I will need at some point, and then I'll have to find some hack to accomodate the DSL rather than just add that one line of code that I could've used if it was just Plain Code.

The downside is that some other things will look kind of awkward and since you're now dealing with a turing-complete language you'll lose analizability, but IMO for UIs those are worth losing if I can just use plain code.

I should also explain what I mean by "thin syntactic sugar": JSX is a local transformation which doesn't need any external context to be translated to plain JS. `<div className="greeting">Hello</div>` will always compile to `React.createElement('div', { greeting: "hello" }, "Hello")` no matter what; in Svelte, `count += 1` will output different code based on its context because it will compile the whole component as a single unit.

Yeah, but it's still a DSL and that means that I can't be sure that everything I can normally do in JS is valid there, and external tooling won't be able to make sense of it without additional work.

> JSX is not "Just Javascript"

It's very thin syntactic sugar over a function call. It has a very simple 1:1 mapping to the output code, as opposed to "magically reactive `foo = bar`.

> I'm sure not many people would be willing to argue that throwing promises (as react suspense supposedly does) is a holy grail of frontend development, even though it is "just javascript".

I'll give you that hooks and suspense are straying further from normal js because they don't behave like normal functions do and have special rules for being called; hooks are a DSL for encoding incremental computations into js, and suspense is just the react team fawning over algebraic effects/delimited continuations and trying to reproduce them in js.

But then again, all of these can be defined in normal JS code as opposed to a DSL which compiles to who knows what, so all the rules applying to normal JS and its tooling apply to them.

Average users are absolutely not gonna read all that stuff, much less understand it, when they accidentally install a malicious extension. I'm all for more powerful browser extensions (I really miss vimperator...), and I agree that permissions should be more granular, but I don't think that's gonna fix the issues that the average user of chrome has with them.

In my region (Piemonte) we certainly do. One of the most distinctive dishes is bagna cauda, which is a dip sauce made mainly of anchovies and tons of garlic. It's usually recommended that you eat it before a day where you don't have to go out and interact with other people because you'll smell really badly of garlic :)

> Single-quotes don’t support interpolation but aren’t any more performant

Wrong!

> Single quotes are 2x faster than double quotes because you don’t have to hit shift when typing them. Half the keystrokes, double the speed

https://twitter.com/tenderlove/status/1353048163096031236

Nice, I never thought of testing with "__proto__"! "constructor" is also a fun one.

At least on PC, there have been a few minor patches that fixed some of the most pressing issues like broken quest lines or the save file becoming corrupted if it surpassed 8mb (which apparently could happen very easily if you played a lot on the same save). The last was released 19 days ago.

ATS is not really a theorem proving language, it's almost a superset of C with a very long list of type system and language features that lets you write anything from C code with no safety to very high level recursive functional code with lifetime tracking which will translate to efficient C code, if the transformations are proved to be correct. It's a weird beast, but I'm not surprised it outperformed some C implementations, because it is basically C with a lot more features.

This reminds me a lot of c-amplify. I didn't see it in the author's list of languages they tried so I thought I'd mention it, it has a lot of neat ideas for building a lispy C.

https://voodoo-slide.blogspot.com/2010/01/amplifying-c.html https://github.com/deplinenoise/c-amplify

This feels a lot like what happened to Hack, which at first was compatible with PHP and could be compiled to it, but later became its own language to better fit FB's needs, and it seems like they're giving OCaml the same treatment here with ReScript.

There was actually some effort being made to keep OCaml tooling compatible with ReasonML (which is supported by dune[0] with no additional configuration) and BuckleScript integration with dune, which was being worked on before this rebrand, so it's kind of sad to see FB going off on their own with ReScript because they don't wanna do the work to upstream the changes they need.

By the way, regular OCaml also has its own JS backend[1] which is of course completely incompatible with BuckleScript.

0: https://dune.build/ 1: https://github.com/ocsigen/js_of_ocaml

It's been a while since I've used Ruby for anything serious, but I think most people still use https://ruby-doc.org/ for the official docs. What you linked is the site generated by rdoc, which has never looked very good.

If you switch back enough times it will stop trying. Same with other things like suggested tweets in your notifications or likes from others, if you see those just click on the top right arrow on the option that says I'm not interested and after a few days it will stop showing them.

I have a friend who's working as a chicken sexer. From what I understand they don't teach how to do this anywhere in Europe, so they get people from the asian countries that do to emigrate and basically hold them hostage with temporary worker visas...

> Users often perceive aesthetically pleasing design as design that’s more usable.

Is that right? Personally I feel like the opposite is true; I'll take an ugly looking but very usable UI over one that has all the bells and whistles but is actually a nightmare to use. Surely when the UI is bad and the UX is also bad the effect is compounded, and first time users might very well perceive the combination of bad UI/good UX as much worse than good UI/bad UX, but I really don't think this should be given out as good advice.

Shouldn't be a big deal if it's properly split into subcomponents and their props don't change with every rerender as well.

The first one just feels like a premature optimization. Yes calling setCount forces a rerender of that component, but unless there's lots of subcomponents inside that component, I wouldn't bother. Chances are later you'll need that state in the view, and if you have "unexpected side effects" from rerendering then that is the problem.

The other tips are fine; effects should have a single responsibility and links and buttons should be accessible.

I think in those cases it would be better to implement pagination, but with a "from" ID, such that the first element in that page will be the one with that ID. I remember a post saying that this was faster, and more useful in cases like Facebook where the timeline is always updating. This happens to me all the time when I'm browsing news sites with pagination: I go back in the article history to catch up, then I leave it there a few hours and when I come back and go to the next page I see half of the articles on the previous page on top of the new one.

Lately I've been having some luck with using parser combinators to parse XML in OCaml. I just define a lazy list type that takes input from Xmlm's streaming decoder and a few parsers for xml elements (`data : string parser` and `el : string -> 'a Attr.parser -> 'b parser -> ('a * 'b) parser`), plus all the usual combinators. It's probably not as fast as using libxml2 but at least it's type safe.

EDIT: The Attr.parser above uses the same combinators but it operates on a simple list of Xmlm attributes using a function that takes an attribute name and returns the value of that attribute, if found, and the list without that attribute.