656 karma · joined June 23, 2014
edit: no hard data after a quick google but every article on the first two pages estimates 5-8 years.
Why not? You click on the link and if Teams is installed it opens the local copy. If not then you can do the call in a browser. What is the difficulty?
Over time the original meaning may fade or be forgotten, and the residual symbol in the language becomes the thing itself. Etymology is full of examples.
But that much history has not yet passed since the introduction of the term "curbstomping" and so using it is still a choice that conveys some meta-meaning about content and style.
As mentioned further up in the thread it is unnecessarily violent for conveying the meaning in the comment.
The claim that you make here is not true, and the example that you give does not support your claim. A programming language is more than just syntax - it is the combination of both syntax and semantics together to give a computational meaning to the strings in a language. This is not controversial, this is emphasized in the introduction to any textbook on compilers / language theory so I'll just give you one easy to google reference for this claim:
* https://www.cs.mcgill.ca/~rwest/wikispeedia/wpcd/wp/p/Progra...
A programming language is more than a well defined set of strings. Each of those strings defines a particular computation. This is not true of natural language, where any definition of semantics relies on the semantics of the natural language.
For your specific example of lisp, here is the original 1958 letter:
* https://dl.acm.org/doi/10.1145/368405.1773349
As you can see the description is more than just the syntax of expressions - it describes the evaluation process and how to perform it. This is different from a modern description of semantics as it predates the introduction of operational and denotational styles by a couple of decades.
From the same era here is ALGOL, again it is more than the syntax as a description of the semantics is required to defined which computation is being written down in the language:
* https://www.softwarepreservation.org/projects/ALGOL/report/B...
One of the pillars that you are building your argument upon is very faulty, and I think it would be good to take a moment and consider what that means. Marsha is clearly a program synthesis tool. It is clearly automated in the production of programs. It looks useful in the overall process of programming. But describing it as a programming language is not helpful or useful. Watering down language and definitions does not help to explain what Marsha is or can do, and when you have made something new there is no particular need to try to fit it into an old label that means something else.
You are sticking to the term "militarily crippled" but is it justified? Yes, Japan had lost the war by that point. But crippled implies that they could not fight back, or inflict losses on an invading force. There is no evidence to suggest that.
If the two bombs had not been used, when would the war have ended and how many lives would it have cost on both sides before it was over? More or less than 200 000? Would that have been better or worse morally?
Those are difficult questions. I don't claim to have good answers to them, but I would not glibly dismiss them with sarcasm.
Certainly the death toll would have been higher without the two bombs. By what measure would you claim that there is no dispute that Japan was "militarily crippled"? There is difference between losing a war and being unable to mount a punishing defense.
If you have not watched https://en.wikipedia.org/wiki/The_Fog_of_War then it provides an interesting point of view to counter the simplistic "the war was already over we only did it to scare the russians" viewpoint.
Does anybody have a link to a relevant discussion here? I would like to read about the creative process that goes into defining model weights, and how it differs from the mechanical output of running the training algorithm.
> After all, it had been Wiener who discovered a precise mathematical definition of information: The higher the probability, the higher the entropy and the lower the information content.
This seems jarring wrong and a little digging reveals that in 1948 Weiner wrote:
> the notion of information attaches itself very naturally to a classical notion in statistical mechanics: that of entropy [...] just as the amount of information in a system is a measure of its degree of organization, so the entropy of a system is a measure of its degree of disorganization; and the one is simply the negative of the other.
The broad idea is there (and perhaps Weiner deserves credit for the observation), but it is the same year that Shannon published A Mathematical Theory of Communication, and two years later Weiner is quoted with the more precise description:
> Just as entropy is a measure of disorganization, the information carried by a set of messages is a measure of organization. In fact, it is possible to interpret the information carried by a message as essentially the negative of its entropy, and the negative logarithm of its probability.
The later quote using Shannon's definition. I've not seen information theory being credited to Weiner before and that makes me curious - what is the story here? Parallel invention is commonplace in scientific history, yet Weiner and Shannon are listed as collaborators in other sources.
find . -exec grep -Hn regex \{\} \;
How would you do that with the du | grep combo?
It's great for learning the muscle memory of basic motions.
There is no new direct evidence in the article, simply the weight of existing indirect evidence synthesized together. There does not seem to be another hypothosis for how the virus emerged that has as much indirect evidence pointing towards it?
The main gist of the article is:
* The institute applied for funding for a specific piece of research (inserting a furin cleavage site).
* The institute claims it did not perform the research.
* Covid is what we would expect if somebody did perform that research.
* The research would have been performed at the time and place where covid emerged.
It is not direct evidence, but under a weaker burden of proof (e.g. balance of probabilities) it is fairly convincing.
The correct number is somewhere between a multiplier of 1 and 2 depending on the setup of the display. But 2x 4k screens is only 16 megapixels, and so it also depends on where the other 7 megapixels are.
Drawing is a task that is more like aiming - attempting to hold your gaze at a precise location for a period of time. It is possible, but you are fighting against the natural saccade pattern of your eye and it becomes tiring very quickly. You can expect fatigue / eye-strain within a few minutes.
Assuming 4k resolution per eye and 120 degree FoV would give 3840*2/120 = 64 ppd.
Using the link that you gave a 4k screen at 60cm is 73 ppd, so it is reasonably close.
Apple haven't said what the FoV is yet, so I'm guessing 120 based on the pi-max and an early impressions video from mkbd. The horizontal range isn't clear either: 23 megapixels would be about three 4k screens so it depends on the overlap region between the eyes.
It's not that far off 4k, and when sitting that close to a 28" 4k screen I find the pixels barely noticeable, i.e. I can see them if they are aliased but would not notice them when the colour gradient is smooth.
The technology looks nice: foveated rendering, eye tracking controls and geature recognition. The image quality could be amazing and the battery life is still bad enough that it will be v2 or v3 before it is worth looking at.
Start with Java, but don't work in Java directly. Add a layer of meta-programming on top. In this case it was an aspect-weaving system that allowed injecting methods into classes. By itself that would not have been too harmful, but this system had been used at scale, for more than a decade. The result was the emergent effect of aspect weaving on a code-base, which I have not seen before. The entire code-base had been splintered into thousands of small pieces that only existed to be injected into other contexts. It was very strange code.
The aspect-weaving system worked as an extension to the parser, so that all of the code written in it was essentially action rules for the parser. Data was constructed as synthetic or inherited attributes in the parse. The "hairy control flow" that is normally eliminated after the initial parsing phase existed in every pass in every part of the compiler. Essentially parsing never finished, as even late in the code-generation backend we were still tracing the emergent effect of grammar production rules.
Layered on-top of this was a pattern-heavy approach that tried to eliminate all remaining structure, shape and form. Days could be spent digging through scaffolding and layering code to try to find the pieces of functionality that went together to handle a particular construct or feature.
The layers of maintained- and generated- code meant that nobody actually knew how large the system was. I spent an afternoon trying to count it properly and I think my estimate of 1.5m lines was probably the closest that we had come.
I still have nightmares occasionally, but they are becoming less frequent over time.