skysight-inc/HackerNews huggingface dataset:
Most wireless networks seem to have loss in the range 0.1% - 1% due to congestion (ie. when a packet is clobbered by noise of some far off transmitter that the media access control algorithms could not protect against).

In that case, Layer 2 retransmission (ie. retransmission at an individual link rather than needing to retransmit a packet across the entire route) becomes absolutely necessary if there are many wireless links on a route.

What systems use layer 2 retransmission? My home wifi does not seem to...
Money printing became decoupled from anything real in 1971.

See here what happened to the correlation between productivity and labour income after this https://wtfhappenedin1971.com/
The distinction made between "longhand" vs. "typewritten page" metaphors of editors is an interesting one.

I've used WordStar (decades ago), it's one of a long chain of editors and wordprocessors I've had experience with on DOS, CPM, Mac, VMS, MVS, Unix/Linux, and MS Windows systems. For the past few decades, vi/vim has been my principle editor. In the past five years, largely with either Markdown, LaTeX, or HTML markup languages (there was a time I composed uni papers using nroff, long since passed...).

The notion of markup languages, with commenting, and vi/vim's movement and "editing language" seems to capture pretty much all of what Sawyer describes as "longhand" editing. With vim, I move throughout the document, either within the principle window or splitting the window to either get an additional view on the current document or open an additional one.

With markup languages, comments may be included (HTML-style for both HTML and Markdown, '%' leaders in LaTeX, etc.). And of course, what you type is what you mean rather than what you see.

To that extent I'd argue WordStar's legacy lives.
When Julia finally comes of age, there will be a new, emerging language claiming it will eat Julia for lunch.
It's been used as singular for as long as modern English has existed.
As someone who does data science, I roll my eyes every time I have to touch Python. It’s ubiquitous, but it actually sucks once you get used to better languages.

It is somewhat circular: it was preferred because your earlier alternatives were Java or C(++) both of which had their shortcomings. SKLearn is still one of the most feature-complete and powerful libraries and it was Python only and thus drew a crowd.
A lot of people who write data science code, I would be confident to bet that if you taught them Julia first, they’d prefer that.
I'm pretty sure they changed that just recently.

https://blog.google/products/photos/storage-changes/

> Starting June 1, 2021, any new photos and videos you upload will count toward the free 15 GB of storage that comes with every Google Account or the additional storage you’ve purchased as a Google One member.

> Any photos or videos you’ve uploaded in High quality before June 1, 2021 will not count toward your 15GB of free storage. This means that photos and videos backed up before June 1, 2021 will still be considered free and exempt from the storage limit.
> But that's better than the experience I had with the app when I paid at a McDonald's recently. I was expecting a screen which said something like "You are about to pay $9.72 to McDonald's Corporation. CONTINUE/Cancel.

That's written on the payment terminal. Google Pay is just a standard NFC payment. You might be prompted if the payment is large depending of the legislation in your country but for small amount, it's fast on purpose.
> Running ~1000 iterations for a 483px wide Mona Lisa on the google colab GPU runtime only takes around 40 seconds!. Compared to the CPU version which takes several hours to do the same for a smaller image

Isn't this excruciatingly slow? I remember my old 486 computer did run life at full-screen full-resolution in realtime (probably 25fps at 800x600 ?) How it has come to that after 20 years? How can a 20 year old CPU outperform a modern GPU by one order of magnitude? Is it all fault of lots of useless intermediary language layers?
It's easy to romanticise the early days of the internet but seeing this brought a tinge of depression.
I'd say yes.

The programming/software development industry is HUGE, and there's room enough for most anyone.

But beware though, in a lot of SV-oriented forums/boards, there will (naturally) be a gigantic bias towards Big N or startup careers. In those cases, it might be more difficult to get a foot inside, as you get older. There's just a ton of applicants, and some recruiters at some firms might assume that with higher age, you won't be able to commit to work as much as fresh grads, due to family and such.

There's quite a difference between joining Google or the hottest unicorn, compared to becoming a coder for some insurance company out in nowhere.
I don't think everyone else is a clueles idiot, but there are a lot of them around.

If you have a small(ish) team of great people you can get a lot done with a very informal process. When you start to grow, or you're not necessarily hiring the best there are, you start to need this stuff.

And you don't always need the self-motivated, highly productive builders. Someone has to make small tweaks, pad out the automated test cases, maintain things, document etc etc.
That sounds more like a comment meant to further divide people, than a realistic picture of what normally happens. You're also being intentionally vague. What kind of articles are being shared and people then getting "cancelled"? "Top 10 cute dog photos"? It's never the act of "merely sharing something" that gets people in trouble.
For a similar challenge: https://en.wikipedia.org/wiki/Proof_game
Software is composed of algorithms but most software engineers aren't writing the algorithms they use themselves. If algorithms are only a part of software production, maybe optimizing our languages around this subset of problems isn't actually optimal.

Higher-level languages really should mean languages that operate on another level of abstraction - programs that themselves are interpreted by other programs. Raising the level of abstraction requires also hiding details that aren't important at a higher level so, arguably, modern high-level languages are rarely all that much higher-level than C (even if they are safer/easier/faster).

Knowing a Turing complete language will probably always be a valued skill but it might one day become similar to knowing Assembly today - it's important to know if you care a lot about implementation details but it's not the language you use to reason about the overall program. Libraries, frameworks and system components all need to be able to express a level of detail which makes algorithmic thinking ideal but it's not necessarily the best model for specifying the behavior of information systems or making devices end-user programmable. There's a whole world of relatively unexplored possibilities here for language designers to explore.

(NOTE: I'm using a backup account to work around my anti-procrastination settings but I'm the author of the original comment)
Where is the best 3D game engine based on the scratch scripitng?
Yes, but that particular quirk is unique to Wokeness which is very new even to most Westerners.
"something that can possibly be interpreted as 'racism' is 'basic niceness/politeness' for someone else. If we're celebrating diversity then let's embrace it properly. "

Thank you for your wisdom. I have been saying something along these lines for a long time, but never so eloquently.
We're clearly getting one side of the story and missing the broader context. That's normal for journalism these days. That is, ramp up controversy, and omit countervailing factors and wider context.

Let's take a step back and look what this article would have us believe ... namely that in 2021, when race and talk of race is an incredibly sensitive topic (and has been for a couple of decades now but there is certainly extra sensitivity now than before), a tech company in Silicon Valley, based in one of the most progressives areas in the world, would be staffed with people who go around commenting on people's skin color? I need a little bit more journalism to understand the context because at face-value this doesn't pass the 'smell test'.

>They seem to systemically do that to people who make complaints about sexism or racism.

How do you know that? Why would you trust that NBC News is accurately and objectively laying out the case here? What is it in their general reporting, especially on highly contentious and sensitive issues, that tells you they will provide you with the facts and context so you can reach a balanced conclusion?
If domestic production is enough to satisfy domestic demand no worries but that's not always the case.
You can't uninstall what was burned into the OEM ROM, only disable them so they no longer run nor get updates.
There's a variant / corollary of the Efficient Market Hypothesis here, though.

Let's say the GP's XML library has The GTA Bug, i.e. it uses a quadratic-performance loop when parsing. The bug will go undiscovered until any one consumer of the library a) sees enough performance impact to care, b) has the expertise to profile their application and finds that the library is at fault, and c) reports the problem back to the library owner so that it can be fixed. This combination might be unlikely but since only one consumer has to have all those properties, the probability scales inversely with the number of library users.
I do not know enough Zig to be sure, but an oft overlooked wrinkle in custom allocators is the width of pointer types aka labels for the allocated regions. Focus is usually on "packing efficiency" or MT-sharing and such of the allocation arenas themselves, not labels of allocated items. Perhaps you could speak to this?

For example, a binary tree with <65536 nodes could use 2 byte pointers and in-node space overhead might be just 4B and if you had, say, 4B floats as key-values this might be "only" 100% space overhead with 8B per node total instead of C++ STL-like 8B x 3 (parent pointers) + other extra junk overhead. (IIRC, I measured it once as 80 bytes per node in the default `std::set` impl...).

In Nim, one could probably address this kind of situation with distinct types:

type nodePtr = distinct uint16

and overloading `[]` and so on in terms of this new `nodePtr` type.

Since virtual memory dereference needs no extra "deref context", global variables/closures/local context (like an ever present proc parameter) may be needed to fully convert a narrow pointer to a VM pointer (or to otherwise access data). I think that this is all do-able in Nim, the language, but the stdlib has no direct conventions.

You might be able to keep using the rest of the stdlib by swapping out the impl of newSeq or newString to take a named parameter defaulting to some global arena, but call site-specializable to whatever you want and then replacing the `string` and `seq` types which propagate this not quite hidden optional parameter, getting the nice usability/brevity of a global arena with the nice tunability of specialized allocators. A macro pragma might even make propagating the allocator handle to called procs that also allocate semi-automatic (but someone would need to get PRs in to annotate all needed stdlib procs...). I am unaware of any Nim project which has done this yet. So, there could be compiler/run-time bugs in the way or other blockades. And it may not be possible to have narrow pointer types as with my binary tree example (but this may also not be possible with Zig's conventions).

This is all really just a little color on your probably correct conclusion (and a question about how flexible Zig's pointer types can be in its stdlib convention).

EDIT: Oh, and though that Forum asker was not you, you may get better answers than from just me here by making an account there and asking on the Nim Forum.
Good intent and bad results are not mutually exclusive though. One way to handle this would be for HR to talk to the person who made the original comment about skin color and say, we assume you had a good intent but please try not to do that again (and a short explanation why).
It has caused career-ending eye damage though - e.g. https://www.theguardian.com/world/2015/nov/23/ba-pilots-eye-...
I'm not implying you don't find marriage in ancient times that resembles modern marriage. I'm pointing out the bold generalizations.

> We know for sure, since Old Egypt/bronze era, marriage was almost universal.

For sure almost. Earth's experienced a larger number and variety of cultures than some people give it credit for. Let's not make generalizations about human nature based on someone else's generalizations about human past. Noone owes a justification for acting the way they do. When you introduce justifications, you enter the realms of dogma.
> Since the final payment amount is often not known at the time you tap/dip/swipe your card

As a foreigner, I have trouble understanding this.

How can the final amount of a transaction not be known when you are paying it? Is that one of the usual nonsensical shenanigans stores like to play with taxes in the USA?
Scaling vertically is problematic in the cloud where it’s very common to have instances and even entire regions come and go at any time.

It’s one of the big reasons why horizontally architected applications have thrived in the cloud era.
Both approaches have their advantages, IMO. Inclusive ranges are usually easier to understand, but e.g. when picking a (uniformly distributed) random element from an array, nothing beats a[floor(rnd() * len(a)].
Decolonizing Light – Tracing and countering colonialism in contemporary physics
In a large complex application you are going to want to use the same allocator everywhere, or close to everywhere, and almost all functions may allocate memory directly or indirectly, in which case this Zig convention will require most every function to have a useless parameter. That sounds enraging.
These boom bust cycles are caused by fiat money, inflationary debt/spending, government stimulus and over regulation that causes false market signals and creates bubbles, it’s not a capitalism problem, capitalism would be the solution.
No civilization in sight? There are actual houses in the background of that photo.
For a senior dev 90k is the low-end, not the average I would say. But this highly depends on where you are in Germany. In Munich or Hamburg salaries will be substantially higher than e.g. Ludwigshafen or Cottbus
> That said, you're absolutely right that neither the Dutch not any other European country is anywhere near as corrupt as the US, where corruption seems to be baked deep into its political system.

It's not baked, it is rotten. It started with noble intentions and designs. European countries reformed mostly in the 20th century to become what they are. US has continued it's system since the funding of the republic and the rot has set in deep until now.
Right, but not at scale, whereas you can just get a leaked password list and get access to 1000 random accounts easily.

For the average user having no password is 100x more secure than the rubbish password they picked.

For the high value target the opposite is hopefully true, then again solarwinds123
I think that the errors you are making are that EE does not do away with expected utility, and expected utility is not a strict requirement for the development of a theory to describe economic outcomes.

1) It seems to me that it is only utility, rather than its expectation, that is the concept you are treating as necessary. There are an infinity of ways to reduce a distribution of utility-weighted outcomes to a single summary, albeit not with the same simplicity (and perhaps value) as the expectation.

2) All of the phenomena you list could be described by some mechanism other than the agents involved computing expected utilities - whether or not this is a useful
or effective description is beside the point, it is possible. (Expected) Utility is not required to describe these phenomena.

3) The basic EE claim is that the ergodic hypothesis, roughly that the temporal and ensemble distributions are the same, is false in the context of these economic systems. This has nothing to do with whether or not you can associate utility values with states, nor whether it is possible to compute expected utilities, but instead is a claim about how, and from where, those utilities should be measured, in particular when considering problems like optimising long-term returns.
That's what sum types are for.
I have a few questions since you have a broader view.

What other languages do you prefer ?

What python traits do you think are weak ? (I'm no python fanatic but I like it as a tiny swiss army knife)
Leetcode.
If I switch off wifi of my phone mid call, it drops 20+ frames. That isn't exactly seamless. It's far worse if I just walk out of range
> Now they're doing away with the web interface. They don't say why, so the reason has to be pretty shady.

The article explains why.

> Just like with Google Allo, SMS-based authentication means there's no desktop support at all. The Google Pay website is being stripped of all its useful functionality because a browser does not have a carrier SIM card and therefore can't be authenticated by the SMS-reliant system.
I opened Microsoft Edge and Apple got angry
Kmdr Learn command syntax. Fast
kmdr browser extension transforms code blocks to help you understand Terminal commands where and when you find them
> does that mean we should make the app not bother to get your finger print and just have nfc on all the time?

You don't need to unlock your phone to pay amounts under 30€ in my country. You just need the screen to be on.

I'm quite glade it's like this actually. If I had to fiddle with the phone every time I wanted to pay, I would just use my card.
Lines like that[0] sound like the goal is to please the industry, without questioning why the industry loves these things. It's good to question established best-practices, but it's also good to understand why they are best-practices.

[0] "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love."
There is https://juliadynamics.github.io/Agents.jl/stable/
But is it?

A lot of what we do today is not algorithmic in nature. Arguably the majority. For example, take your phone and tell me how many apps follow a computational/algorithmic paradigm, that is, you give them some parameters, they compute an answer and then terminate. But we have to express all of this algorithmically, and the mismatch is a source of a lot of the pain we have in software development today, IMHO.

I am not sure that Turing completeness is really the main driver here, but it is at least a symptom.

As Guy Steele put it:

Another weakness of procedural and functional programming is that their viewpoint assumes a process by which "inputs" are transformed into "outputs"; there is equal concern for correctness and for termination (and proofs thereof). But as we have connected millions of computers to form the Internet and the World Wide Web, as we have caused large independent sets of state to interact–I am speaking of databases, automated sensors, mobile devices, and (most of all) people–in this highly interactive, distributed setting, the procedural and functional models have failed, another reason why objects have become the dominant model. Ongoing behavior, not completion, is now of primary interest. Indeed, object-oriented programming had its origins in efforts to simulate the ongoing behavior of interacting real-world entities–thus the programming language SIMULA was born.

https://dreamsongs.com/ObjectsHaveNotFailedNarr.html

But of course objects are also highly procedural, at least as we have conceived and implemented them today:

Instead, objects use procedural abstraction to hide
behavior. This difference has significant consequences for use of
the two forms of data abstraction. Object interfaces are
essentially higher-order types, in the same sense that passing
functions as values is higher-order. Any time an object is passed
as a value, or returned as a value, the object-oriented program
is passing functions as values and returning functions as
values. The fact that the functions are collected into records
and called methods is irrelevant. As a result, the typical
object-oriented program makes far more use of higher-order values
than many functional programs.

William Cook, On understanding data abstraction, revisited

More here: https://2020.programming-conference.org/details/salon-2020-p...

My current attempt at overcoming: http://objective.st
This is of something I've often seen in GPU-accelerated code: people get really amazing speedups because they're comparing to something that started out dog slow. Every example given is 10 generations or fewer, so 1000 iterations is probably not more than 10,000 generations. That should not take several hours to run.

The code looks reasonable enough to me, so I assume this is just Python being Python.
The insane proliferation of SPA’s, electron apps and the general attitude of “dev time is more important than app performance” of the front-end community suggests performance isn’t a real concern.
This is a university in Montreal, Canada.

"Even more than other sciences, physics is a white male dominated field and, thus, a mirror of colonial patterns and social inequality."

"We are engaging Indigenous ontologies and epistemologies for knowledge creation, we are studying colonial anchor points in the history of physics in the context of light, we are studying the views of scientists on colonialism, we’re investigating the discourse on contemporary largescale light experiments"

Our civilization tolerates this kind of pseudoscientific mumbo-jumbo at its own peril. It is not any better than Lysenkoism under Stalin and it will come crashing down one day. Unfortunately, that day may be the day we capitulate to China or other ruthless opponent that didn't eviscerate its own R & D with utter nonsense.
probably 99% of time shuffling data around, 1% of time calculating
In the UK, last year we had a terrible shortage of bread flour in the supermarkets.

Actually, what we had was a sudden reduction in the amount of flour being used by bakeries, and an increase in the amount of flour being used at home. There wasn't a shortage of flour - there was a shortage of small bags to put it in for selling at a supermarket. The industry was all set up for selling a decent proportion of flour in really large bags.

Likewise, for simple goods like vegetables, dairy, and beer, some suppliers have suddenly had their customers disappear, because they normally sold to restaurants, pubs, and caterers, where other suppliers have not been able to keep up with demand, because they sold to supermarkets. The obvious solution is for the suppliers who previously sold to caterers to sell to supermarkets instead, but it takes a while for these contracts and logistics to be sorted out.
software is a factory that produces data.

The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with principle-based Warehouse/Workshop Model

https://github.com/linpengcheng/PurefunctionPipelineDataflow
With regards to they, that is correct. Thank you for pointing that out. I do feel slightly daft, tho them is always a plural, and I stand by my thoughts on it feeling divisive.
Hard disagree.

Having "probable cause" to test a hypothesis is an important part of science. Testing neutral hypotheses is only a recipe for pointless p-hacking, I'd say that's not science.
> And I don't understand why people would need a citation instead of just saying its calculated using the trapezoidal rule.

They didn't know the trapezoidal rule.
Interesting, I've never seen that. I'm genuinely curious, do you have an example?
Same in cryptography, where the research community manages our own preprint archive (http://eprint.iacr.org/). My experience has been that preprint archives are often used to "mark territory" i.e. get credit for an idea quickly so that it can be discussed more openly.
Typo correction: the equivalent in spectre returns a vector (not a map)