If you're quoting Wikipedia directly, you're doing it wrong.
Every non-obvious sentence on Wikipedia requires a reliable source that supports the facts. It's OK to learn about a topic at Wikipedia, but if you're going to spread that knowledge, you must a) read the original reference supporting the facts, and b) credit the reference directly, skipping Wikipedia in the chain of attributions. Reading the original source, you can detect when one of the facts stated in the article is not really supported by the reference.
This is the proper way to disseminate knowledge stored in an encyclopedia that "anyone can edit", just in case someone edited the facts in the few seconds before you loaded the article.
Besides, if you find a discrepancy between the source and the article, you *should* correct it at the article. Everybody can edit Wikipedia, after all.
The weakest security is always the human involved.
That's true. It's also the reason why password setups and protocols should be made as easy and enjoyable to use as humanly possible.
If you build a password system that's hard to use, hard to remember, and force the user top jump through hoops, you're putting a lot of strain over the weakest link in the system. I.e., you're making the system brittle and easy to hack.
The city councilmen refused the demonstrators a permit because they feared violence. Who feared violence?
The city councilmen refused the demonstrators a permit because they advocated violence. Who advocated violence?
Both instances of the schema are unambiguous, yet machines have difficult telling them appart and knowing who does what at each.
In these cases, you can't merely decide which one is the correct subject based on properties that only apply to that item in the sentence and discarding the others; you need to understand the situation.
Code can be copy-pasted with little knowledge. Also, it's likely that script-kiddies only find the activity profitable in these second world countries to the point of doing it full time; in developed countries you can get better rewards for that level of dedication.
Why because I'd take your statement of "I allow Mozilla to run experiments in my browser"at face value? If you make a public statement like that, have the courage to stand by it, and don't go whining that people followed up on your offer.
> After that, I immediately turned off telemetry and experiments, because they've now abused my trust with this stunt.
If you had those turned on, how is this an abuse of your trust? You had given them permission to do anything with your browser. If you don't want anti-privacy measures in Firefox, don't turn them on.
To all those predicting doom and gloom: Excel doesn't fit the role of an IDE, it fits the role of the debugger. Sometimes, much better than a debugger integrated in the IDE.
For those who know what we are doing, a spreadsheet is a wonderful tool for rapid prototyping business processes and gathering input from domain experts at the initial phase, when requirements are not at all clear and change quickly.
Having a modern language friendly to exploration and prototyping would be a welcome addition.
So what? Taking requirements over a functional prototype is orders of magnitude easier than taking them by abstract interviews over what "the system should do".
So the spreadsheet doesn't prevent you from taking requirements later (i.e. defining how it should be expanded and how it shouldn't), and wins by allowing you to take them in an easier way.
The thing about more expressive languages is that you can abstract away the most complex parts, like function calls, the program stack or memory management. For example, with constraint programming you specify some desired properties of the expected values, and the language searches all the solutions that match those.
That will surely work for accountants...they do love recursive programming etc.
Cells in a spreadsheet are kind of functional.
For accountants, why not? Domain-specific sub-languages allow professionals to use their expertise to solve problems in their domain without understanding the inner works of the computer.
And the word you're looking for is "reactive programming", which is the programming paradigm shared by spreadsheets and also modern asynchronous libraries like React. In addition to the side-effect-free expressions of functional programming, you get reevaluation of dependencies for free when any input parameter is updated.
Completely true. Though now that developers are beginning to understand why a tool like Excel is good for the people using it, there's hope.
Maybe there's chance that someone invents a new development environment with the same benefits of the spreadsheet for non-programmers, but updated to take advantage of the recent advances in programming language theory regarding type checking and asynchronous/distributed computing.
they exist because Office is actually pretty good at letting people who have subject matter expertise and subject matter problems bang out something resembling a solution without much IT or software engineering getting involved.
Hear, hear. When someone who knows what they're doing can create a functional workflow prototype in an evening using a spreadsheet, yet having a working application with the same or less functionality requires months of taking requirements and development iterations, it's no wonder that people use the tools at hand for most of their information, even if developers think that doing this is a monstrosity.
Excel use by information workers doesn't follow the typical patterns of other application software.
Spreadsheets belong to the family of End-User Development software, a research tradition which has more in common with IDEs than with office suites. EUD focus on allowing end users to create automations without the need to understand the logic of classic programming languages, i.e. without learning a formal grammar nor having to follow the execution path of a program runtime in your head.
In spreadsheets, in addition to a simplified domain-specific programming language, you get a dead-simple modeling tool for your data schemas (with simple visual queries), and mixing the data and code in-place, which helps as much as your preferred debugger. End users usually don't get as powerful debugging tools as developers, and spreadsheets are typically the only environment where a clever power user has access to similarly powerful tools.
You're not alone, and the ideological aligns with the pragmatics. It seems too many people have forgotten what happens when a monoculture browser engine takes hold of the web for a decade.
Except that users will perceive it as "this old website doesn't work", not "Chrome doesn't work", since the problems only happens in some websites and not others.
...developers should provide their own initial value for every parameter defined in the standard, and those non-standard parameters available in any popular implementation?
You may want to try again with the reMarkable, a new product in the same category as the Sony e-paper.
It is expensive, and it has very limited software, but that allows them to provide a very focused minimal interface that feels like using paper in a notebook - just editable, with layers and background templates.
Anyone who enjoyed this article and has ever played Magic the Gathering, may enjoy RoboRosewater, a neural network which invents a new Magic card every other day.
Who says it couldn't? You'd need to provide it with robotic actuators, a camera, lots of butter and bread, and a score function describing how sandwich-buttery is any given situation. But it's only fair that you provide a definition of the problem to solve, since a human would need it too.
Under these conditions, it's quite possible that the algorithm would learn how to make sandwiches. They've achieved it with playing video-games, after all.
If you're quoting Wikipedia directly, you're doing it wrong.
Every non-obvious sentence on Wikipedia requires a reliable source that supports the facts. It's OK to learn about a topic at Wikipedia, but if you're going to spread that knowledge, you must a) read the original reference supporting the facts, and b) credit the reference directly, skipping Wikipedia in the chain of attributions. Reading the original source, you can detect when one of the facts stated in the article is not really supported by the reference.
This is the proper way to disseminate knowledge stored in an encyclopedia that "anyone can edit", just in case someone edited the facts in the few seconds before you loaded the article.
Besides, if you find a discrepancy between the source and the article, you *should* correct it at the article. Everybody can edit Wikipedia, after all.
The weakest security is always the human involved.
That's true. It's also the reason why password setups and protocols should be made as easy and enjoyable to use as humanly possible.
If you build a password system that's hard to use, hard to remember, and force the user top jump through hoops, you're putting a lot of strain over the weakest link in the system. I.e., you're making the system brittle and easy to hack.
See also Winograd schemas which are more nuanced than that:
The city councilmen refused the demonstrators a permit because they feared violence. Who feared violence?
The city councilmen refused the demonstrators a permit because they advocated violence. Who advocated violence?
Both instances of the schema are unambiguous, yet machines have difficult telling them appart and knowing who does what at each.
In these cases, you can't merely decide which one is the correct subject based on properties that only apply to that item in the sentence and discarding the others; you need to understand the situation.
So, the AI is a tool that follows the ideology of those that educated it? Colour me surprised.
Code can be copy-pasted with little knowledge. Also, it's likely that script-kiddies only find the activity profitable in these second world countries to the point of doing it full time; in developed countries you can get better rewards for that level of dedication.
Why because I'd take your statement of "I allow Mozilla to run experiments in my browser"at face value? If you make a public statement like that, have the courage to stand by it, and don't go whining that people followed up on your offer.
> After that, I immediately turned off telemetry and experiments, because they've now abused my trust with this stunt.
If you had those turned on, how is this an abuse of your trust? You had given them permission to do anything with your browser. If you don't want anti-privacy measures in Firefox, don't turn them on.
To all those predicting doom and gloom: Excel doesn't fit the role of an IDE, it fits the role of the debugger. Sometimes, much better than a debugger integrated in the IDE.
For those who know what we are doing, a spreadsheet is a wonderful tool for rapid prototyping business processes and gathering input from domain experts at the initial phase, when requirements are not at all clear and change quickly.
Having a modern language friendly to exploration and prototyping would be a welcome addition.
So what? Taking requirements over a functional prototype is orders of magnitude easier than taking them by abstract interviews over what "the system should do".
So the spreadsheet doesn't prevent you from taking requirements later (i.e. defining how it should be expanded and how it shouldn't), and wins by allowing you to take them in an easier way.
So more complicated and unobvious than Lisp?
The thing about more expressive languages is that you can abstract away the most complex parts, like function calls, the program stack or memory management. For example, with constraint programming you specify some desired properties of the expected values, and the language searches all the solutions that match those.
That will surely work for accountants...they do love recursive programming etc.
Cells in a spreadsheet are kind of functional.
For accountants, why not? Domain-specific sub-languages allow professionals to use their expertise to solve problems in their domain without understanding the inner works of the computer.
And the word you're looking for is "reactive programming", which is the programming paradigm shared by spreadsheets and also modern asynchronous libraries like React. In addition to the side-effect-free expressions of functional programming, you get reevaluation of dependencies for free when any input parameter is updated.
How robust and useable is that model? I could use something like that as a basis to develop EUD applications and development environments...
Completely true. Though now that developers are beginning to understand why a tool like Excel is good for the people using it, there's hope.
Maybe there's chance that someone invents a new development environment with the same benefits of the spreadsheet for non-programmers, but updated to take advantage of the recent advances in programming language theory regarding type checking and asynchronous/distributed computing.
Hear, hear. When someone who knows what they're doing can create a functional workflow prototype in an evening using a spreadsheet, yet having a working application with the same or less functionality requires months of taking requirements and development iterations, it's no wonder that people use the tools at hand for most of their information, even if developers think that doing this is a monstrosity.
Excel use by information workers doesn't follow the typical patterns of other application software.
Spreadsheets belong to the family of End-User Development software, a research tradition which has more in common with IDEs than with office suites. EUD focus on allowing end users to create automations without the need to understand the logic of classic programming languages, i.e. without learning a formal grammar nor having to follow the execution path of a program runtime in your head.
In spreadsheets, in addition to a simplified domain-specific programming language, you get a dead-simple modeling tool for your data schemas (with simple visual queries), and mixing the data and code in-place, which helps as much as your preferred debugger. End users usually don't get as powerful debugging tools as developers, and spreadsheets are typically the only environment where a clever power user has access to similarly powerful tools.
A 4-light-years-away planet system is an awesome test bed for interstellar probes, though.
Seedship.
There are also native mobile versions of this space exploration game.
You're not alone, and the ideological aligns with the pragmatics. It seems too many people have forgotten what happens when a monoculture browser engine takes hold of the web for a decade.
This should be obvious, but the end user -the one who suffers the problem- can't update the website.
Except that users will perceive it as "this old website doesn't work", not "Chrome doesn't work", since the problems only happens in some websites and not others.
...developers should provide their own initial value for every parameter defined in the standard, and those non-standard parameters available in any popular implementation?
You may want to try again with the reMarkable, a new product in the same category as the Sony e-paper.
It is expensive, and it has very limited software, but that allows them to provide a very focused minimal interface that feels like using paper in a notebook - just editable, with layers and background templates.
Anyone who enjoyed this article and has ever played Magic the Gathering, may enjoy RoboRosewater, a neural network which invents a new Magic card every other day.
You don't need self-awareness to generate jokes, only to enjoy them.
Who says it couldn't? You'd need to provide it with robotic actuators, a camera, lots of butter and bread, and a score function describing how sandwich-buttery is any given situation. But it's only fair that you provide a definition of the problem to solve, since a human would need it too.
Under these conditions, it's quite possible that the algorithm would learn how to make sandwiches. They've achieved it with playing video-games, after all.
Having a reasonable way to navigate the music library didn't hurt, either. *Snark*