> I'm curious to see how long these gains can hold
The gains can hold long. The dollar may not.
6,504 karma · joined July 5, 2010
The gains can hold long. The dollar may not.
Interesting detail about the NK-12 (according to Wikipedia):
The design that eventually became the NK-12 turboprop was developed after World War II by a team of Soviet scientists and deported German engineers under Ferdinand Brandner, who had worked for Junkers previously; ... Thus, the NK-12 design evolved from late-war German turboprop studies.
It does exist, just hasn't reached some corners of the world. Neobanks are a great example. I had great experience with TransferWise (renamed recently to Wise). Transfers, checking accounts, wire transfers are several times less expensive than with traditional banks. Works like a charm.
So maybe it's time for Europe to shine.
1) Historically, everything on the web used to be "free" and this is still an implicit assumption for internet users.
2) Payments are not part of the HTTP protocol; micropayments never materialized
3) The web is too good for advertisers - targeting, reach, scalability are unmatched compared to off-line advertisement. This supports p.1 above and hinders p.2.
It's a vicious circle.
I would easily pay $300-400 for a de-Googled Android phone with 3-3.5" screen and no bloatware. It should be just right to use apps like Uber, Telegram, or maps, but the small screen would discourage mindless media consumption.
And it would fit in pocket much better.
On the other hand, it's a glimpse into the future and it's scary. Apparently, the Belarus government collected a centralized database of all citizens' communications. And it was hacked and leaked. I think it's reasonable to assume that any centralized database of extreme value will be hacked and leaked one day, and it's just a matter of time. Any backdoor demanded by government will at some point be exploited by a rogue actor.
Total trip time: 17h42m.
Driving time: 11h18m (64% of the total trip time).
Charging time: 6h24m (36% of the total trip time).
- A decade of near-zero interest rates
- A lack of investment opportunities: real estate usually has a below average ROI but there is nothing else to invest in nowadays (look at startup valuations to understand how desperate investors have become)
- Too much money printed worldwide (again, look at startup valuations)
- The desire to park money earned (or stolen) in developing countries in a Western country that hypocritically turns a blind eye on money origin because banks, construction industry, and legislators (who own real estate en masse) all are interested in heating up the market as much as possible (looking at you, Canada)
What makes it worse, is that all stakeholders are now locked up in this situation. Increasing interest rates is not possible because it will bankrupt millions of families with mortgage. Western countries are in the late industrial cycle, so creating new investment opportunities is problematic until a new industrial cycle begins. In this situation central banks have no choice but to print money and lie about inflation as long as possible because there is no way this whole situation can be resolved without money losing value.
First of all, no-code tools are not intended for developers. Although, developers can and do benefit from them by using them occasionally for prototyping and mundane automations. The main beneficiaries of no-code tools are "citizen developers" - people who get paid for something else than software development (e.g. marketing analysts, accountants, lawyers, etc) but who need/want to automate things to be more productive in their main work. For them, no-code is a godsend. It's like not having hands and asking someone else to do something for your with their hands all your life, and then suddenly getting your own pair of hands. No-code is a super-power to them because now they can do things they need but couldn't do earlier. For instance, querying databases without knowing SQL, pulling data from web APIs without having a clue about HTTP, or renaming a thousand of files in a loop. No-code is not about doing everything. No-code is about being able to do something, because previously its target audience could do nothing. Remember that excitement when you wrote your first Hello World program and it worked? This is exactly how "citizen developers" feel about no-code.
Second, no-code is not a replacement for general-purpose computing and never meant to be. There is only a limited set of tasks, that can be efficiently automated using no-code and high-level abstractions - ETL, file/folder manipulations, RPA, certain things from gamedev and ML, and maybe robotics. However, these tasks are very common and no-code saves a lot of time and money for them.
Third, no-code creates a new class of people that can do programming, because no-code is programming. It just uses higher-level abstractions and can be imperative, declarative, or functional. This class of programming is here to stay because it works.
I'll stop here because I can talk about no-code for hours :)
So it's for companies that aren't profitable even at IPO. Not my cup of tea.
Something that is as simple as this: https://www.youtube.com/watch?v=RYCtoRTEk84
In theory, yes. But the reality, nobody does that unless an error is apparent and needs to be investigated. The vast majority of calculations in Excel spreadsheets are done using cumbersome, multi-line, unreadable formulas that try to pack as much logic as possible into one expression. Such obscure formulas are the main reason why lots of business-critical Excel spreadsheets contain grave errors, many of which are are never discovered.
In a similar fashion you could've posted a link to running an SQL join query from Excel (which is surely doable for a trained user). Technically it's possible, but it would be wrong to pretend like the join is done in Excel.
I don't think spreadsheets are a good way to program data transformations at all. Data transformations are inherently a pipeline/function abstraction, and even non-technical users understand that. Spreadsheets don't offer a good way to decompose a data transformation process and inspect each step for correctness. This alone makes them prone to calculation errors. Also, tables are an afterthought to spreadsheets, therefore even trivial joins are always a pain in Excel.
I have a good practical experience with building visual pipeline-based data transformation tools [1] for non-technical users and they have been a success.
Take a few lessons from people who live in 2nd- and 3rd-world countries. They used to not rely on government or expect financial stability for decades ahead. Yet, they survive pretty well and some even thrive.
People didn't always have stable currencies, pension funds, and unemployment benefits over their history.
What they offer is a data plane and it makes sense. Although, it doesn't contradict the idea of webhooks, but rather complements it. A consumer can get notified via a webhook when new data is available. Whether the data itself comes with the webhook, or is available via an additional API request, is a matter of design. Personally, I like the idea of separating the control plane from the data plane. However, in some cases it can be an overkill.