So glad to see him articulate what I've always felt about x-exprs.
It often gets overlooked because we all understandably want to hype something in a language that's really cool, original, abstract or otherwise reflects well on us. But being able to intuitively, iteratively and rapidly work on XML & HTML files is lush, and the IDE with built-in REPL is just gravy for this purpose.
Even if working on XML and HTML files is boring and a technically solved problem in most languages, it feels better in Racket to me, and the essay did explain why it feels better.
>some staff "sympathetic" to the Muslim Brotherhood
I think you're accidentally overstating the strength of their case, probably just the clause-level equivalent of a typo.
They actually said:
> some of whose staff have links to organisations sympathetic to the Muslim Brotherhood.
So, just to be clear, they're excluding anything with (interpreting the vague language generously) <=3 degrees of separation from the Muslim Brotherhood (organisation -> staff member -> an organisation -> Muslim Brotherhood) as a reliable source.
Totally unscientific, but to put this in a kind of very loose and silly context, Facebook claims that its users are on average connected to every other user by 3.57 degrees of separation. I suspect that the figure for this kind of connection is actually, relatively, much higher, but I sincerely doubt it's all that much higher than 4 (i.e. enough to make this sort of connection relevant) - especially when you think that these aren't even friendship relationships, but something so much weaker!
So, I just started learning Haskell and I learned a bit of Standard ML in the past.
I was/am expecting Haskell to be broadly similar to ML - what's the main way the two languages differ?
edit: never mind, from the reddit discussion you linked:
> while these languages are undoubtedly strongly typed, they are not referentially transparent by default, and actually embrace some levels of imperative programming.
Especially for cases like that - if someone has more 'sway' on Wikipedia than you, they can (and will often) just say something like "Thanks for the source - I'll verify and if it says what you think it says, I'll add it in to the article." Then do nothing, ever again. In fact, unreliable citations, or citations that don't actually say what the citer thinks they say, that can be easily checked online are far more acceptable on Wikipedia than citing a book.
Inertia like this leaves useless pages like "Oplomachi" (https://en.wikipedia.org/wiki/Oplomachi) live way after they should have been merged, as well as leading to the deletion of useful pages/sections/references.
The major articles, which are more likely to get attention, tend to be less dysfunctional than niche interests. That said, there are of course far more articles relating to niche interests than there are major articles.
Oh, believe me, there is sway - there is a hidden hierarchy. If you think you are equal in an edit war, and only need to be persistent, you're wrong. Can you lock an article or part of one?
Theoretically 6 & 7 should be a big red flag (the biggest possible UX red flag) to Google regarding the specific Quora page visited - I know that I almost never see Quora results in search, for example.
Following Bartosz Goralewicz's post about how well botting works to manipulate Google in...2014 I think? there's a small black hat industry that's sprung up around imitating this kind of user reaction, and it does reportedly work to remove pages from Google. I've had my suspicions that it's been used against sites I've worked on a few times (2 or 3).
TL:DR; Quora should generally not be ranking so well (but Google's complex enough to be unpredictable on a page-by-page basis these days).
I don't personally think that is a hatchet job - the quote seems harsh, but it's not the full extent of the review.
> The sublime moments come when Donen calms down and concentrates on melody.
That's a pretty glowing quote!
Overall, the review gives two stars - bad, but not exactly a hatchet job. The criticisms are fair, and well-justified - and Syd Barrett is a pretty cool point of comparison. If anything, I would say it suggests that the hatchet job really is dead if this is the worst that can be found - it's negative, but it really works to justify its negativity and struggles throughout to pick out bright spots.
A hatchet job, in my opinion, must be unremittingly & deliberately brutal, or slash quickly and leave the target all-but-beheaded. Coldplay saw many examples of the former, as reviewers struggled to explain why mediocrity in sufficient quantity became something somehow worse, while I think it was Terrorizer magazine (maybe Metal Hammer?) who managed a one-word review of Fall Out Boy.
"Hatchet job" carries an implication of more than just a brutal/negative review. It suggests a critique that's done for malicious reasons or in support of a pre-ordained conclusion. Of course, that's often in the eye of the beholder--if you're on the receiving end of a particular biting critique you probably don't think it's fair.
What's wrong with writing JSON by hand? I've never touched YAML before, but JSON seems pretty clear to me - doesn't feel much different to writing a list naturally.
Is YAML one of those things that proper professional programmers need but us amateurs can botch our way around?
The single fact that JSON doesn't support comments makes it pretty bad choice for configuration files, where you often want to document why a specific value was chosen for a setting.
Yes - I know that some JSON parsers will allow comments and strip them, but IMHO you shouldn't rely on this, and lots of editors will complain if they encounter any non-standard JSON.
These aren't dip-switches. Description of the logic behind the configuration settings doesn't need to be embedded into the config file. It can be in the manual.
That's just asking for the temporary fix to never be reverted because the guy who closed the ticket out didn't read it carefully enough. Or the ticket is marked as "fixed" because the workaround works and it has been open for too long. Keep the documentation next to the fix and someone may eventually find it again. Keep it apart and it can be lost forever.
Yes, the ticket should say that. However, if TICKET-432 is still open, and someone from SysOps comes along to make a change to that config file, how would they know that they shouldn't turn on feature-that-should-usually-be-enabled?
They could read through every open ticket to check, but they're only human, and things can be overlooked. If the comment lives right next to option, it's much harder to miss.
> If the names/values are chosen well their purpose will be self evident.
I don't see how. If I pick a particular value for a config setting, it's obvious what value was chosen, but there's nothing to suggest why that value was chosen.
It takes many years for people to figure out what the right level of commenting is. It's more of an art than a science. Worse, the level of comments depends on the reader. An old veteran may find one distracting that a beginner finds extremely helpful. But they can also be a liability if they aren't maintained with the code or if they make statements about other code that fails to be true after awhile.
A comment like:
# Add 1 to the length of this buffer to work around an off by 1 error in this function in library foo
Can quickly go stale, but sometimes not and could otherwise be accidentally reverted by someone who notices that the buffer is 1 element too long for no apparent reason.
A better comment:
# Add 1 to the length of this buffer to work around an off by 1 error in function foo from library bar (version 1.7.3b circa Nov 1997)
The YAML spec is huge, too large IMO for config files (you can use it while knowing only a subset, but you'll be lost as soon as someone uses a feature you don't know).
I think TOML strikes a good ballance between simplicity and features for config files. It ends up being easy to read and write.
IMO TOML is syntactically messy, especially when dealing with hierarchical data, and a whole new config format to deal with the fact that YAML has too many features is somewhat unnecessary.
I agree. You often want to parse and/or generate configuration files programmatically. For these cases it's good if parsing and interpretation of the file format can be easily implemented (or is already implemented in high quality). YAML has a quite big featureset and definitely doesn't fall into the "easy to parse" category. I'm also quite happy with using TOML for configuration files for these reasons.
JSON for configuration is a cute idea that doesn't scale at all. I've personally experienced this in a project at my job. Once the config gets substantially large, it becomes a headache. The real pain is when a sysadmin without any experience in JSON screws up the formatting or tries to change the config and can't decipher the parse errors.
JSON for config is a bad, bad idea - especially if your config will get large.
No comments, too tedious to write all the delimiters (mainly string quotes,
but lists and hashes add to that), and trailing comma is disallowed, so moving
list or hash elements around needs more attention.
> Is YAML one of those things that proper professional programmers need but us amateurs can botch our way around?
I really don't understand this attitude. If you already call
`json.load(some_string)', there's no difference to change to
`yaml.load(some_string)' and go with that. YAML data model is similar to JSON.
JSON is a format mainly for machines, and is somewhat readable for humans.
YAML is the reverse: it's mainly for humans, but can be processed by machines.
Tons of useless {} and quotes, useless in a configuration file, I mean. Just rewrite an nginx configuration file in JSON and you'll notice the difference even if nginx has its share of {} and ; Do the same exercise on docker compose yml file.
Actually YAML should be easier to amateurs than to professionals. Pros have tools that deal properly with XML, JSON is a lesser problem.
If you think this is stupid because surely everyone uses an editor with automatic scope highlighting etc, I don't think that is the case when you are remotely editing config files via SSH.
I have dozens of small web projects. Part of my project boilerplate is a Fabric file that runs tests and deploys. There's no reason to hand-edit a file on the server unless something is already on fire. And even then . . .
I assume that you already have Apache, your firewall, etc etc set up on the server though? You likely manage OS package updates somehow outside of Fabric?
A fair bit of my stuff co-exists with other things on the same server, so a per-project deployment system couldn't manage everything without occasional conflicts.
Personally I deploy everything in Docker containers now, so I test a static image and push a bit for bit identical image. (EDIT: Even for individual / one-off setups, yes)
But even if you want to do "manual" changes without Docker, or without a configuration management solution like Puppet etc., I'd do them locally in a git repo or similar and either git pull'ing it or rsyncing it over. Both because it'd mean flexibility in terms of tooling, but also because it makes it easy to actually test it first, or at the very least e.g. syntax check them.
Poorly worded by me - it doesn't really matter how hard it is to write - it does matter how compact and readable it is - how long it takes to get an overview of what's wrong.
It's nice if it's easy to write - but the real test is read, comprehend, modify.
JSON merges the worst and most redundant parts of C and lisp.
