It's specifically about cursor lag, but I think that's because it's more difficult to experimentally measure app rendering latency.
86 karma · joined July 7, 2013
It's specifically about cursor lag, but I think that's because it's more difficult to experimentally measure app rendering latency.
In fact, I also love Scala. I've dedicated lots of my time to working with it (almost 15 years at this point!), I've been with it since 2.8.x days. And I really lament that it fell out of favor and huge swaths of the community left.
> Stating this, which is not, and never was true creates the impression you're talking about things you have no clue about.
Of course it is possible that I have misremembered, so I went and checked. It was a mistake on my part to make such a statement and not to provide an actual link.
Not only it was that way, it actually still is. See the official Scala 3 reference: https://docs.scala-lang.org/scala3/reference/
All the code examples there use the new syntax. And I would guess that "Scala 3 reference" is the document that Scala 2 veterans (like myself) would have been using when learning about new features and contemplating migration to the new version.
> You need a degree to understand something such obvious? Never mind…
It might be obvious, but I felt that it wasn't obvious to some people (including the ones that were in charge of the documentation for Scala 3), so I wanted to expand a bit on that.
> The point is: New syntax is only new in the first few hours of contact with it.
Of course, but these "first few hours" are exactly the hours that were spent reading the documentation for the Scala 3, and I feel that making those hours harder wasn't the smart choice.
I think that Scala development team made a decision to chase growth, focusing on attracting new users and disregarding the old ones. Looks like they lost that bet - new users didn't come, and many old users were disappointed and left.
New syntax isn't the only problem of Scala 3, and probably it isn't even the biggest one. But it was the most glaring and visible issue - for me, almost every code example in the reference really felt like a spit in the face. Exactly this kind of off-hand dismissal of old-time users was one of the reasons some of the users started moving away from Scala (myself included).
> Braces in code are 100% redundant, useless noise.
The debate about "braces vs significant whitespace" is raging literally for decades. Like many similar debates, it seems that there's no "true solution" and no "true winner" - both sides have heaps of valid arguments.
I assume that both sides have their merits, and it's always a tradeoff between pros and cons of each approach. I use languages that have braces, and I use languages that use indentation - I see pros and cons of each approach. Outright dismissing the other side of the debate by saying that it's "100% useless" seems to be missing lots of nuance.
But safety is not the only important aspect of a programming language. For me personally the community (libraries, tools, forums, blogs, etc) became much more important over the years, and I feel that Scala 3 really hurt the community angle.
If I recall correctly, later they added a switch allowing one to choose between syntax versions in the online docs. But it wasn't done right from the start, and when that was finally added most of the damage was done, people already lost interest.
I understand that removing braces might feel harmless - but it really makes the code harder to read for people that use braces all the time.
If someone's brain is accustomed to seeing braces everywhere, reading code with them becomes almost automatic, handled by "low-level" parts of the brain. If the syntax is changed, then "low-level" brain areas have to pass work to "higher-level" areas, which increases energy requirements and processing latency. So reading unfamiliar syntax is literally harder.
Incidentally, that's also why many people are so picky about grammar - grammatical errors make the text noticeably harder to read.
Source: have a degree in neurophysiology.
I don't see the chart with changes of number of companies using Scala over time. But even without the chart - if after 15 years there are less than 300 companies in total, that's a bit depressing.
Of course legacy never goes away, and even 20 years down the line there will still be some demand for Scala programmers. Similar to how Cobol still lives on. But in my experience the language isn't growing anymore, even slowly dwindling in userbase. And this became way worse after Scala 3 mess.
1. Spending dollars on US soil from an US bank account won't incur extra fees (at least visible to the person - I know about interchange fees, but they are borne by the merchant), while using card issued by a foreign bank can incur fees for cross-border transactions (at the level of 2-3% usually).
2. Sanctions and KYC concerns also make different dollars have different value. Money in US bank account of an US company employee can be used at face value - money in some less-favored country bank, not so much.
So in fact "-S" is not passed as a separate argument, but as a prefix in the first (and only) argument, and env then extracts it and acts accordingly:
``` $ /usr/bin/env "-S echo deadbeef" deadbeef ```
-S causes the string to be split on spaces and so the arguments are passed correctly.
I'm a frequent traveler, so I tend to overlook that not all people have that option, apologies for that.
But in many countries where there are some restrictions or crushing import taxes, I saw that there usually quickly appeared a flourishing network of people that utilize the travel loophole to bring in the necessary items - some even build sort-of-a-business out of that. Many just ask their travelling friends to bring them phones they desire (I've been such a friend on multiple occasions).
I'm a bit worried by their lack of focus, though - looks like they are spreading themselves a bit thin, they are trying to build a lot of different gadgets all at once (keyboards, speakers, laptops, headphones, etc). Building a phone is hard enough, trying to build all other things might dilute the valuable development resources.
But can you elaborate on how this is enforced? Probably by requiring IMEI registration? (supposedly with a carve-out for tourists, something like "a new IMEI can be used for two weeks without registration, after that it stops working")
If it's IMEI-based, then probably you can still have an alternative phone that will use WiFi hotspot from the "certified" one. Speaking from experience here - we had a problem in Indonesia where we were unable to register a phone due to bureaucratic shortcomings, and so we bought a cheap phone to serve as a hotspot. Inconvenient, true, but still workable.
Also, I don't know how IMEIs are implemented at hardware/software level. Maybe there are ways to spoof them somehow?
Wasn't for latency or throughput - I didn't notice any difference in latency, and difference in throughput is only visible when cat'ing 3MB of text.
However, for me the selling point was a text config file, which I can edit, backup, or store in git (unlike gnome-terminal, where customization was done either in GUI or in gconf, and while it's also text files somewhere they are difficult to work with).
There was the Waymonad project, but AFAIK it was never usable and is now abandoned (last commit 4 years ago).
$ host archive.is 1.1.1.1
archive.is has address 192.210.214.166
$ host archive.is 8.8.8.8
archive.is has address 192.210.214.166- in Demo 1 tool wrote "Switch to colored output..." while in the diff we can see that colored output was already present;
- in Demo 3 tool wrote "Add installation options and demo link to README", while in the actuall diff we only see a link being added, no changes to installation options.
Props to the author for being honest and not cherry-picking the examples.
So the output of the program that outputs a newline looks like:
$ program
output
$
And output of the program without trailing newline: $ program
output%
$
There is an issue if the program is expected to output "%" at the end, of course.Total US budget income for 2019: $3.422 trillion. US population: 328 million.
Assuming that we simply divide the entire budget amongst everyone, we get:
>>> 3.422e12 / 328e6 / 12 = $870 per month
Minumum wage in US is $7.25, so assuming usual 40-hour work week minimum income is about $1300 per month.
So even if US just drops all other concerns - healthcare, military, infrastructure - and just distributes money among the population, then it's still less than 70% than minimum wage. If we assume that only 50% of the budget is spent on UBI (still unsustainable in my opinion) then the number will get even lower.
And that's US, arguably the richest and most powerful country. For other countries this calculation is even worse.
Maybe there's an error in my calculations? How is UBI even supposed to work, where the money should come from?