There are some old stereotypes of detail-obsessed Germans - far too busy measuring the growth rings of a tree with micrometers, and wondering why those are so close together - but never noticing that the tree is small, and growing in a well-shaded part of a large forest.
MIT's Living Wage calculator is mentioned in the article. It's a great project.
A while back, I toyed with a project which needed to propose/estimate hourly labor prices for a service marketplace. Not wanting to contribute further to gig-economy exploitation, I used the data as a per-hour payment floor.
Although freely readable on their site, structured data is only available upon request. I think having the data more readily available would allow socially conscious businesses to actually fix part of the inequality problems we have, instead of just knowing how bad it is.
My request went un-answered, but I put together JSON and CSV serializations anyway. If this would be of use to anyone else, contact info is in my bio.
> Use the facilities your host OS provides just as you'd do with Ruby, Python or Perl.
Well that's the thing: I don't know anyone who actively develops in Ruby, Python, Perl or Node that uses the OS-packaged runtimes. The system packages and the language-specific package managers live in different universes.
I've seen this situation blamed on both OS packagers or language ecosystems, but now I just think the goals between the two just are fundamentally at odds.
> I've seen this situation blamed on both OS packagers or language ecosystems, but now I just think the goals between the two just are fundamentally at odds.
I hate language-specific package managers. I can see their value to packagers (less work), but they end up arguing with the platform package manager.
It's like there's a load of CS graduates churning out lots of new, better languages; but what's really needed is just one better language. Similarly we have a score of new package managers, creating incompatibilities; so we add some more package managers, to paper over the incompatibilities.
I'm inclined to the view that perhaps there are too many coders in the world, creating compilers and package managers because they can't get a job doing something useful.
> I'm inclined to the view that perhaps there are too many coders in the world, creating compilers and package managers because they can't get a job doing something useful.
I truly hope that this outlook on the world does you better than it did me when I was younger.
Once you have a small sheet you go to a scrap yard and say your dead grandpa was a hobby jeweler and nobody wants to continue the hobby. The important part is make it into a form where nobody can recognize it.
The grade isn't as pure as industrial processes, but it isn't too bad. Likewise, while the yield isn't good, even if you collect 50% the value is high enough.
Yeah: No one thinks it's mechanically difficult to remove identifiers. The point is to make such altered parts illegal to buy. Similar to VIN restrictions or handgun signifiers in many states.
The thieves do not care about this and neither do the scrappers. They’ll both grind the serials off within a minute of taking possession if they’re still there.
It's a spurious comparison. I wouldn't pick COBOL as part of my stack for a greenfield project. I would definitely 100% pick SQL as part of my stack for a greenfield project.
Because COBOL has been replaced with better languages for most purposes. SQL is entrenched. I'd also pick SQL for a greenfield project, because... what else?
This says nothing about the quality of SQL as a language.
What I think is more interesting is: if you were to greenfield a language for a relational database, how much would it look like SQL?
Considering (a) how big and important its domain is; (b) its utter lack of any credible competition whatsoever; (c) the wealth of attempts to displace it, yes, I'd say it says something about the quality of SQL as a language.
As a language, i.e. as a vehicle to concisely, effectively, efficiently expressing ideas, it's unquestionably successful.
> if you were to greenfield a language for a relational database, how much would it look like SQL?
Save for secondary concerns like syntax, it would be exactly the same in all respects except easier composability.
There is no low-level API to SQL servers to create competition, so this is like saying CSS has no competition in browsers whatsoever. Yes, it does not, because it was never allowed. Let's go make a browser competition as part of our weekend, or at least RDBMS, sure /s. ORMs with their "relations" etc are basically better DSLs over SQL databases which try to hide rough edges from an innocent user.
Yeah, "group by case when cond1 then v1 when cond2 then v3 else v3 end" instead of "group by alias1". Because, you know, it's declarative, but not really: https://stackoverflow.com/a/3841804/3125367
Or fetching thousands of rows out of explosion of "select t.a, t.b, p.propname, p.propvalue from items t left join props p on t.id = p.item_id". Or inability to join two different subtables like 'props' and 'per_city_prices' simultaneously without exploding into infinity. Of course you can always make 3 queries and join at your place, which is neither effective nor efficient nor concise. A business wants simple [{a, b, props:[{name, value}, ...], per_city_prices:[{city, price}, ...], ...]. Can SQL do that? It can not.
Or getting corresponding non-aggregate values along with min/max results, which requires very funny self-joins if it's already e.g. a windowed aggregation.
SQL is cool for these relational... matrices(?), but sucks as a programming language in both syntactic and semantic parts. Some servers fixed few dumb parts of it, but not generally.
> There is no low-level API to SQL servers to create competition, so this is like saying CSS has no competition in browsers whatsoever.
Yes... but there is only one Web, and many databases. Some of them don't use SQL. They are, in my opinion, and in the opinion of many other developers, inferior. They lost in the market in a fair fight.
Also if SQL sucks so much you can compile to SQL, like TS->JS. Many such solutions exist. All worse than SQL.
> ORMs with their "relations" etc are basically better DSLs over SQL databases which try to hide rough edges from an innocent user.
ORMs are developed by software engineers for software engineers. It's kind of silly to picture them as "innocent" or incapable to understand the relational model.
Does having an operational semantics make a language not declarative? That's not how I use words. Is Haskell not functional because it runs on a GRS?
For the rest of your post you're arguing about either syntax, stuff you solve with CTEs, or stuff you would just hand off to the programming language, so I'll just leave it at that.
So the hard parts were left at that and easy parts were dismissed as usual because one can CTEs all the way down. I shut up and go write three queries, manual joins and funny five-story self-joins, cause there is no problem. Who said it’s a language problem when it’s mine. Thanks for the explanation!
It is as though we lived in a world where, like our own, Lisp invented garbage collection. But unlike our own world, in 2022, Lisp is the only garbage collected language anyone uses. Others were invented but that mostly stopped by the 80s.
Many people would like to replace Lisp, and keep in mind this is Lisp so lexical scope is only available in some implementations and people who want cross-platform compatibility don't use it. But without it, you have to manage your own memory.
That's SQL and relational databases. Relational databases with ACID guarantees aren't optional, they aren't a nice-to-have, they're foundational.
And we talk to them in SQL because... we talk to them in SQL.
Thanks for this project. I found SingleFile a year or two ago, and used it to take "HTML Screenshots" of third party sites I could embed in guided walkthroughs with modified/example data changed, instead of just PNGs.
SingleFile was ultra-valuable for this.
If anyone has a similar use-case, I wrote some pretty rough (and slow) code to post-process SingleFile's output to remove any HTML that wasn't contributing to the presentational render by launching puppeteer and comparing pixels. It's available here: https://github.com/mieko/trailcap
One very useful thing you could add to this (if you feel like it) would be to make it work with snapshotted directories, rather than a single HTML file with inlined data. You can get the former with SingleFileZ and then extracting the resulting zip file.
I like these because it makes it easier for me to make manual edits when necessary and it's a better solution for long term archiving (IMO). But I would love to add your project to my workflow.
