beeforpork

A good analysis. The stated vigilance problem is well known, actually, but it is ignored, supposedly in the hope that humankind is on a progressive path to fully autonomous self-driving, and that we need this phase of experimentation to advance technology.

Completely autonomous self-driving cars (without any steering wheel, so even incapacitated or clueless people may 'drive' (like drunk or in labour or children)) indeed seem like a good solution. (Except we need less individual traffic for env reasons.) Unfortunately, the problem is very hard, technologically, and the current interim solutions will stay for a while.

How about 'ifnot'?

Although I like 'unless' in Ruby, Perl, CommonLisp (sometimes a condition is just naturally the other way of how 'if' wants it), I acknowledge that people get emotional and really hate it. Maybe a better alternative would be 'ifnot' to avoid the ! operator and the parentheses.

How locally a variable is used should matter for selection of a name, too. I don't find i, j, k, o, p, k, v at all offensive if their scope is just a few lines of code. Usage is often idiomatic (e.g., k, v for iterating a map or i for an integer loop variable) and using a longer name would just make it less idiomatic and less obvious.

This discussion is important!

Nutriscore is a proposed system to mark products as 'healthy' on a scale of 5 colour-coded values. It takes into account fat and salt and sugar (high amounts are 'unhealthy'), but not artificial sweeteners or other additives like preservatives or MSG.

I hate this. It will push sugar out of products, but, of course, artificial sweeteners will be put in instead. I've already seen artificially sweetened sweet-n-sour hering without any normal sugary alternative, because companies will of course try to produce few variants for efficiency. This is awful. I find the whole idea of condensing 'healthy' into a single small integer rather absurd as no amount of sugar or fat or salt or MSG is simply 'healthy' or 'unhealthy' on a scale of 1..5.

I like Vallader more.

Ergo: we quickly need laws to forbid chilis!

What else could be the conclusion?

I'm waiting for it and will say 'told you so!'.

Zettelkasten is the opposite and usually considered genius. :-)

> I hope that you will agree that this is not that much more complicated.

Sorry, but I do not agree. The current Unix time API is good enough. Especially with the leap seconds gone. We need no more complication by innovation here.

Any extensions inevitable lead to a lot of people starting to use those additional APIs, others trying to fix old code to use new APIs, and a few will start religiously fighting for the use of the new 'right' API. Software that handles time would be more diverse. And you will never live to see that old API gone anyway, because we don't know where it hides, so in the future, we would have to deal with bugs in the (mis)usage of more APIs.

> In my opinion it's somewhat silly to have the timekeeping standard of the world changed because someone at Bell labs made an unfortunate design decision regarding Unix time, rather than changing Unix time itself.

Well, maybe it is silly. But that's really irrelevant. Don't be stubborn to insist on API changes/extensions, because you think a past decision was wrong. You can't change reality anyway: the vastly bigger problem is changing Unix time, because code is written and is running in critical systems.

And because leap seconds were inserted manually anyway, we already have a solution that works: don't insert any more leap second manually.

Also note that the danger was to do something new: remove a second. That is a very dangerous experiment. E.g., the German DCF77 cannot even announce that (I think the UK and US time signals can, IIRC -- I am not sure about Japan and the other time signals). Of course you could start to postulate we need a new time signal format in Germany (and effectively half of Europe) to fix that, but that is just a much more dangerous approach.

These are 'interesting', but ultimately naive ideas, and the headline is presumptuous.

Instead, the world needs agreement. And, wow!, an agreement among countries to simplify time keeping is an achievement!

We do not need a more complex POSIX time spec, but we need to cope with billions of written lines of code from the past that use the existing API. We need that API to be as stable as possible to reduce complexity. We need to see that no changes are needed to existing code.

We need to reduce complexity, e.g., by removing an irregular, unpredictable drift between TAI and UTC.

We do not need to rewrite legacy code to use a shiny new API, but we need to make sure that legacy code will not break, because we do not know, unfortunately, were all that code hides.

Times are so crazily different. I tried what a really bad algorithm would take in CommonLisp. It is seconds it took.

    (defun find-factor-aux(n div stop)
        (cond
            ((= 0 (rem n div)) div)
            ((> div stop) nil)
            (t (find-factor-aux n (+ 2 div) stop))))
    (defun find-factor(n) (find-factor-aux n 3 (floor (sqrt n))))
    (compile 'find-factor-aux ) ; need tail recursion to avoid stack overflow
    (find-factor (1- (expt 2 67))) ; this takes just a few seconds on my laptop
    ; 193707721
    (find-factor (/ (1- (expt 2 67)) 193707721)) ; check for more
    ; nil
    (/ (1- (expt 2 67)) 193707721) ; get second factor
    ; 761838257287
    (* 193707721 761838257287) ; check result
    ; 147573952589676412927
    (1- (expt 2 67))
    ; 147573952589676412927

But its definitely memory safe. :-)

Shoot, no Perl!

> This static analyzer causes programmers to use 2 extra characters when using smart pointers, -> vs (*)., since the overloaded -> operator returns a pointer.

This renders it completely impractical -- sorry. You need to figure out a way to make it work, otherwise this is, errrm, useless.

And what is 'this' static analyzer anyway. I thought this is about a language extension introducing possible general static analyzers. Is this a concrete one now? Or why do you already know that it cannot handle '->'? Did I miss something? What is this?

Go spaceship!

Photons. Each annihilation event emitted a photon, and they are still around. IIRC, about 5e9 times as many photons are observed as there are baryons, and that seems to match up well with the calculated imbalance of the baryosynthesis.

Do you have examples of 'nuisance crimes' related to cocaine? I am currently trying to wrap my head around passive cocaine snorting. Some of the images in my head are quite disgusting. :-)

If you hide pointers and destructively update variables, this happens easily. I'd say the Go problem is a bit worse because there are also exposed pointers via that '&' operator.

But the problem should have been known when the language was designed. In CommonLisp, i.e., quite a mighty but old language, it is the same: the capture is on a loop variable that is destructively updated:

    (setf refs (loop for i in '(1 2 3) collect #'(lambda () i)))
    -> (#<function) #<function> #<function>)

    (mapcar #'(lambda (f) (funcall f)) refs)
    -> (3 3 3)

The same done with a fresh function parameter works. And since this is the usual style in Lisp, I suppose the problem will not be that obvious like in Go:

    (setf refs (mapcar #'(lambda (i) #'(lambda () i)) '(1 2 3)))
    -> (#<function> #<function> #<function>)

    (mapcar #'(lambda (f) (funcall f)) refs)
    -> (1 2 3)

> That Latin word "varius" is pronounced like "/vəˈɾiws/"...

What? No. It was pronounced /'waɾius/ in Latin: stress on first syllable, because the penult is light, then no schwa, but /a/, and no glide /w/, but /u/ (three syllables, not two)).

Looks like this person looked up the pronunciation of 'varius' in Wiktionary and copy-pasted the (Balearic) Catalan pronunciation (of a different word, spelled the same), which is the first to pop up...

4cm, not 4inches, IIRC. Plus concrete, again 6cm, not 6inches. Still massive.

The weight ist 13 tonnes steel + 13 tonnes concrete per segment, IIRC, diameter is 1.1m and segment length is 13m. Steel is ~7kg/dm³ => You can now calculate the wall thickness.

OK, OK, let's not talk: 130 dm * ((11/2dm + X)² - (11/2 dm)²) * \pi * 7kg/dm³ = 13000kg => X = 0.39dm

EDIT: Corrected the sign...

> The is/as pair seems like a tremendous improvement to the dismal C++ type inspection and casting status quo.

No, unfortunately, it further complicates C++, because the original ways of expressing the same thing will not be removed. You'll just need to remember another level of sugar, but must not forget the lower levels -- e.g., if you want to extend your own type to work with this, you'll need to provide the right plugin definitions. I was especially appalled by the 'x.get()' and 'x.value()' equivalences -- this is just a layer of obfuscation.

That table Herb provides will be added to C++ -- but nothing will be removed.

Each time (e.g., Rust, Go, Carbon, Cppfront, ...) before clicking, I hope that people would remember that Pascal pointer syntax is better than C's convoluted '*' and '->' and '.'. So far, I've been disappointed. I mean:

    'p.x'   just like 'p.x' in C, but
    'p^'    instead of '*p' and 
    'p^.x'  instead of 'p->x' and 
    'p^^.x' instead of '(*p)->x'.

Just admit it: Pascal is nice, clean, compositional, and less surprising.

Don't you remember? Or do you honestly think that C syntax is better?*

Huh, I put 30kg of lead on each leg for fun when hiking, when jogging to work, anytime, really. Plus that heavy backpack, of course!

No.

...'better'...

I stopped reading there -- maybe it's prejudice, but it's also my spam filter.

Well, I kinda like it -- less things to care about, more reason to leave at 5.

But it's counterproductive for the company, and some experiments a developer may want to quickly do will never be done at all. It kills a lot of creativity. The same holds, of course, for restricting internet access so a dev might never find out whether an interesting looking github tool really is good (for doing productive work!). Also, the company probably wants their products to run on a diverse zoo of machines and OS versions prior to release.

So why a company would take away such access on dev machines is a mystery to me -- probably misguided (and futile) attempts to keep in 'control'.

Faszinating: I also thought about exactly '&==' in the past. It seems to be natural choice for this.

But then, continuing that thinking, if you have '&==', you'd also need '&!=' -- that looks really confusing.

Can't we turn that into a '==0' test somehow? Maybe '^&', because '((a ^ b) & b) == 0' is equivalent to '(a & b) == b'. And, as somehow said: '~&' also works: '(~a & b) == 0' is also equivalent to '(a & b) == b'.

    if ((a ~& b) == 0) { ... }

Wait -- we can swap that into '&~' and we're back in C. However, it reverses the logical order, with the test bits first:

    if ((b & ~a) == 0) { ... }

    if (((WGPUColorWriteMask_Alpha|WGPUColorWriteMask_Blue) & ~mask) == 0) {
        ...
    }

So we're back -- this is standard C now. But I find it incomprehensible.

Can I rid my body of these nasty chemicals by eating lye bread?

Thanks for the clarification of how this works! :-)

Local production is always good, so this is good news.

But I fail to see that 'this changes everything'. That tone of the article just feels patriotic. What will change, exactly? Did I miss some facts?

As for quality, regardless of whether it's with or without power, I doubt there is a big difference in US, German, Japanese, Australian tools -- it's a matter of preference and workshop organisation (e.g., for cordless power tools, the batteries should fit what is already there). One company may have a slightly better circular saw (Festool?) the next has a slightly better plunge router (Triton?) -- whatever. But most of that is marketing and branding policy (DeWalt is for the tough and sweating man and Festool is for the clean and thoughtful engineer -- but is there a quality difference in their cordless drills?) Milwaulkee is good and in the same league and I don't see changes coming by this.

It's not related. But suffixing is a very common way of expressing stuff also in unrelated languages, e.g., your Finnish locative works just like it does in Japanese or Tamil (structurally, not literally: it is a different ending) -- and those three are totally unrelated.

Structurally, Finnish endings are also quite different from Latin as the ending is always the same (almost, except for vowel changes), while Latin has an array of endings for the same function and you need to learn about declension classes of nouns to understand how to select the right one. Finnish 'cases' are more like suffixes like '-ne' or '-que' in Latin. E.g., '-ssa' or '-ssä' is 'in (location)': 'Amerikassa' 'in America', 'Sveitsissä' 'in Switzerland'. In Japanese the ending for 'in' is '-de' and in Tamil, it is '-il'.