>I think we need to differentiate: Visualize a program vs. Visually program.
Not necessarily, programming with visual DSL is already a thing in the field of language oriented programming. Visual programming refers to different thing, but not impossible to make a connection between the two fields.
Visual programming is now more like umbrella term for projects (and research) exploring new ways of programming beyond the textual representation. Probably better to call it non-textual programming, because some of its ideas not tied to visuality, like structural editing.
Visual programming enviraments offers a concrete way to program general-purpose code, DSLs offers a very specific language to program in a domain (language orinted programming offers ways to invent these DSLs). Often visual programming applied to a specific domain, as an alternative to textual scripting languages. Maybe this confuses people, thinking they are less powerfull, non general-purpose.
What described in the article is a visual DSL based on diagrams, using as a source for the programming itself (which is exactly the same as UML). But the whole thing are not well thought, and I think only serves the purpose of dunk on visual programming or the people how are working on them for "not understanding what professional programmers need".
Yes, but in that case you need to reencode every video in realtime at playing. Maybe you speed up the process with capturing the different parts of the video in parallel and concatenating the parts in the end, but if you want good compression then you need to reencode the whole video again. This is far from just getting a video file from a CDN server. If you want to try it, just few line of code with MediaRecoder API in any browser.
Problem with generators and this scheme, they allow regeneration. Most people not using the first version, they generate a new until they like it enough to stop, which is not that random anymore as they think.
It's just a bare minimum that you reduced, if you add some preference it's worse than that.
I did some test, maybe I'm just lucky, but i got password with a word starting with b at the 3rd generation, and i got adjective-noun pair in that order at the 5th generation.
No, it's the -maximum- that I reduced entropy by. If I choose randomly from 4 possible passwords, I've shaved off --no entropy--.
If I choose with a strongly predictable preference (say, everyone knows I'll pick the password that's first alphabetically) I've shaved nearly 2 bits off the probable search space: you probably only need to look in the first 1/4th of the search space.
Choosing with some subtle, individual preferences is something inbetween.
No, your example has nothing to do with preference, your method (picking out of 4) just less random than picking from one (the first).
Preference is, when certain passwords more likely to be picked than others or at those passwords less likely to be stepped over to generating a new one. Wtih strong preference you regenerate until you got that preferred password, for example you prefer short words and the attacker know that, at first trying combinations with short words has better chance to cracking the password.
You're just talking past me, bro. Regenerating and picking your favorite from a few is reasonable and isn't a big entropy penalty (the penalty is easily bounded).
Infinitely re-rolling until you get the exact phrase "correct horse battery staple" obviously has a severe entropy penalty, and this is not a reasonable course of action.
Sorry for over explaning, but I feel it necessary.
Sticking with your example and making more formal. Name it pick function and let its three modes, random, deterministic and preference. In the random mode, the probability of picking one from the inputs are equal to picking to any other. In the deterministic mode, with the same inputs the function always picking the same and the probability of others are zero, but if the inputs change or any input, it could change the picked one. In the preference mode the function not just picking one, but making a sorted list of the inputs. In the preference mode, changing one input not changing the others sorting. In this mode using pick function on several inputs you got some information about the inputs overall probability distribution aka entropy (more precisely entropy is the measure of that).
The important from this, determinism not imply preference, but not random also. Cryptographic hash functions doing the extreme version of this determinism, the output is well "distributed", but not random. (PS: Sometime that characteristic called pseudorandomness, that is how PRNGs works with random seed)
Deterministic pick applied to random pick just less random than random pick alone on the same set, because random pick has the maximum of the entropy and adding some deterministic part just reducing that. But most people not picking with a well distributed deterministic function in their mind, more likely they pick with preference, which is I think much worse. So, that why I call it the bare minimum.
Yes, if the regeneration depends on your preference of the generated words, the words order or link between them. The individual generations independent from each other, so if your choice – how many regeneration you do - not depends on the generations outcome, for example on your birthday date or favorite number, their randomness are equal.
But randomness are not enough, it's possible the first generated version correlate with your preference and that situation does not really matter why are you stopped generating new password.
Predictability of this scheme very good, because the strict rules. All implementation using common english words. For words smaller length, easy spelling, less ambiguity are preferred. Mixing nouns verbs and adjectives are more meaningful, order also adds more meaning. Word count very limited. Preference on the separator character also very rigid. Personal preference more known, because hidding your preference on all english words very hard and mostly unconscious.
On the other hand, I'd wager that the set of words that you can recognize is vastly larger than the set of words that you're likely to come up with on the spot. Hence, using a generator would still result in higher entropy then trying to come up with a password yourself.
Random numbers picked by humans are notoriously biased. I'm guessing it's even worse when you ask them to come up with random words.
