EuAndreh

As free advertisement to rsync.net, I also like the service and support.

I have not deleted any of my daily borg backups for many years, covering my laptop and some servers. Borg has an equivalent `borg serve` feature as detailed in the article.

I use borg mount every other week. After the initial config, you can just type:

  $ borg mount :: borg/

Even though I count the rsync.net backup only once in the 3-2-1 backup rule, its geo-distributed under the hood, so there's also that.

I forgot to update the payment credit card once and got a few months of grace with periodic notices, but no service cut and excellent customer support.

I'm also fond of their stance on pretend standards, like PCI compliance: https://www.rsync.net/resources/regulatory/pci.html

IIRC I created the account for use as a git-annex remote, but I've used it for archival and sshfs, which is very convenient.

Despite its flaws and issues, email is federated and has been working at scale for decades.

Besides being the stardand, it also has a standard:

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/e...

Come on, these three phrases aren't equivalent or comparable.

They "can arguably be construed as the violence" from a discriminatory argument. An honest argument wouldn't provide us this false equivalence.

There are many other factors that influence language popularity besides technical quality, like:

  - marketing;
  - big companies using it;
  - familiarity;
  - history of the creators;
  - history of the influencing languages;
  - timing;
  - luck;
  - regional usage;
  - etc.

That's fine for a primitive compiler built for a school project, but not much else.

Not true.

On the one hand, just see how many non-compiled languages are used outside of primitive school projects.

On the other hand, this simpler approach is actually faster for writing actually fqst compilers. Many modern compiled languages have compilers that work on the order of ~100ms on a simple file with 1k LoC, when it could (and arguably should) work on the order of ~1ms, IOW, imperceptible given the syscalls overhead.

A 100x faster compiler that generates meh code is more useful 99% of the time: when one is recompiling all the time during development.

I have the impression you're mixing single-pass compilation and O(1) memory use of the compiler.

As is, C already is single-pass compilable, modulo some unnecessary syntax ambiguities.

As the compiler reads the text, it marks some character strings as tokens, these tokens are grouped as a fragment of code, and some fragments of code are turned into machine code. A simple function of a 100 lines doesn't need to be parsed until the end for the compiler to start emitting machine code.

Like the parser, this requires memory to keep tabs of information and doesn't work for all types of constructs, like a jump instruction to a label defined later in a function. The code emitter soaks input untill it is possible, and does so, like when the label is already known and can be jumped to.

Thanks, but no thanks.

The parser being stand-alone means it is much simpler to understand and unittest.

Stand-aloneness and single-passness are orthogonal.

I found no advantage to a single pass compiler. It isn't any faster.

A gigantic advantage: a single-pass-compilable language is simpler. By definition.

Implementations may or may not be simpler or faster.

C++ doesn't allow forward declarations either.

Well, that's not what I meant.

C++ is "C with just this thing" done way too many times.

The trouble with such sayings is like following a google map that says cross this bridge, but wasn't updated with news that the bridge is out.

TBH, I didn't really get this. Is this about sticking to C as is, but it is outdated as is?

C would be outdated if it didn't have, say, long long for 64-bit numbers. Having "true" be a keyword instead of a macro doesn't change how outdated it is or isn't, just like compile-time evaluation also doesn't.

They are once you use another language that doesn't have those restrictions.

I have used many, and I still don't find them obvious.

C adds new things all the time to the Standard, like normalized Unicode identifiers, which are a complete waste of time.

I agree that many/most are a waste of time, and shouldn't be added to C. The fact of C adding things to the standard all the time shouldn't justify adding even more things, but make one question if those are needed at all, and how to accomplish the goal without it.

Every C compiler also adds a boatload of extensions, some good, some wacky, many ineptly documented, all incompatible with every other C compiler extensions.

I know about that, and my position is the same: just don't.

I don't use them also.

I have my own list of things that could "easily" be added to C, but I'd rather them not to be.

Good suggestions, but also meh, e.g.: forward declaration requirement enables a single-pass compiler to emit code on-the-fly.

I have a much better list for things to add to C: Nothing. C isn't perfect, or nearly as good as it could be, but simply adding things onto C gets you C++.

Adjusting what sircmpwn says: in C you don't solve problems by adding features, but by writing more code in C.

I liked an answer on stack overflow on a question on "how to write a generic function wrapper in Go", or something similar. Many suggestions included reflection, but the author wanted something simpler with varargs without reflection. A comment simply said: "wrong language".

I'd rather adopt this position for some languages, instead of add more and more to C3X. I do away with things in C23, and don't want even more things added in to C.

Making a strech of OP's arguments: "look at all this cool things that C could do, and that D does!". Well, go on and use D, nothing wrong with that.

(BTW, I do write test targets for every file in my C projects, but I'm not so much into jogging).

Those things aren't that obvious, and I'd rather not have them added to C.

Wrong language.

    LISP doesn't really read well the bigger the codebase

There is nothing wrong with using PEGs for SQL parsing, but this article (I didn't read the paper) presents flawed arguments:

- tech $X is from the 60s, therefore it is bad and/or outdated: one doesn't need to "disrupt" or innovate in everything to become modern. There are plenty of things from the 60s that still don't have a better replacement, and its OK to keep using it.

- "YACC-style parsers" clumps together parsers that are generated at compile-time, from declarative grammars, using LALR(1). But that's not inherit to the technique or algorithm: a parser can be LALR(1) from a declarative grammar and still extensible at run-time, or provide LL(1) alongside, or be built from statements instead of a grammar. There's nothing wrong with using PEGs over "YACC-style" parsers, but not for these distorted reasons.

Not key value dictionaries, just pointers are needed.

A closure with no behaviour is just a pointer to the enclosed variable. A closure with 2 pointers is a pair, which you can get the car and cdr.

The runtime needs to make the pointee available outside its definition, so escape analysis, garbage collection, etc. But no dictionary is needed.

Zero accessibility =/

As great as it may be, this isn't something I'd pick as it'd be unusable in this cases.

From the same article:

Brazil’s Supreme Court has drastically expanded its power to counter the antidemocratic stances of Mr. Bolsonaro and his supporters.

The title is a leading question. I can come up with different titles for the same article or topic, that could be leading somewhere else:

1. Brazil Top Court's Actions to Defend Democracy

2. A View On Moraes' Decisions In Face Of The Crisis Created By Bolsonaro

3. Brazil's Supreme Court Reaction After The Presidency Went Too Far

---

A legitimate question I have is:

What other institutions (or democratic tools) should have acted to halt the extremist anti-democratic movement lead by Bolsonaro?

(Not a trick question, an honest one given the crisis)

Yep, that says not to include generated files in VCS.

I've also seen the bison and flex output included in VCS, and the same guidelines apply.

Oh god why. I thought (and hoped) that GP didn't actually mean this.

I see how a team or an organization can eventually get to this point. It just saddens me that they got there.

s/generated/generate/

Nowadays it's not that big a deal.

The same can be said about autotools itself :/

Historical and current use indeed vary, and many times even using autotools itself isn't as appropriate.

That's not the case for autotools output, or flex and bison output.

If the generated files are what you say? Well, just embed the generation step into the build system. A simple approach like that is easily made reproducible, and we avoid introducing noise into the repository.

IIRC Debian has a policy on preferring to generated files themselves. I couldn't find the link to it right now, though.

yacc and lex, their description and some implementations are simple. Flex and certainly Bison are not.

In this case, I can say autotools's advice is outdated at best, and one shouldn't follow it.

It adds unneeded complexity.

No unauditable generated code for me, either manually or automatically, thanks.

I disagree based on the existence of a standartized but diverse ecosystem.

The languages listed above all have:

- a language specification; - more than one competing implementation.

Erlang doesn't have a specification, so you're actually writing code that runs on the maintained implementation of the VM. This effectivelly ties yours software to the lifecycle of the VM implementation, unlike a situation where diverse implementations and platforms that can execute some code.

JavaScript does have a spec, and it does have competing implementations. So if you're to restrict yourself to no dependencies, a standalone webapp could be added.

But not for JavaScript outside the browser: there have been efforts to make a coherent interface to the OS, but none stuck. So now you need to pick a platform to restrict yourself to.

---

I've explicitly highlighted the lack of dependencies with JavaScript just because how pathological this ecosystem is in this aspect. It doesn't have to be zero, and it does apply to other languages and ecosystems, but "a simple react app" absolutely fails this rule.

Any complaints or criticism on the lack of some widget on Motif?

Also, I'm curious: is the app accessible? AFAICT, Motif doesn't even mention accessibility, and is where Sun made real progress in the past.

Not that big of a deal. Lisp has a drastically simpler syntax, but can behave is the same way.

This thing that is different from other languages is having a static lexer and parser, versus having a fynamic one. In Perl you modify it indirectly, and in Lisp you can modify it directly.

The fact that this happens has nothing to do with Perl's syntax complexity, but everything to do with dynamism in parsing.

From the fact that the LoC count of the implementation is beyond "millions".

How about this equivalence: I appreciate how extremely sophisticated GCC is, and the very well optimized output it generates. It is still is 100x more complex internally (and thus, error prone, buggy, more complex to modify when needed) than TinyCC, for instance.

Not GP, but nothing wrong with kubernetes per se. It is simply unnecessary.

You can get to gigantic success and extraordinary scale by growing vertically, without needing to add a very complex layer that kubernetes is.

Think of the many literal millions of lines of code, and thus, potential bugs and liabilities one inherits by "just using kubernetes".

It's not a requirement, neither problematic. Its simply unnecessary for anything remotely resembling a "one-person tech startup".

Besides unnecessary features like horizontal scaling, necessary features like restarting a service already exist, and most likely are already installed in the base distro and being used by the rest of the system. Its not like this couldn't be done before, all kubernetes provides is a conveniet and streamlined package for all that, at the cost of black-hole levels of extra complexity via several added indirections.