Nilesh Trivedi 2024-11-11 09:49:39 Somewhat off-topic but I saw a lot of people moving to BlueSky, decided to read up on the underlying AT protocol and its promise of decentralization and found things I did not like. Posted some thoughts.
Konrad Hinsen 2024-11-14 07:26:05 @Nilesh Trivedi
The reason why I am only superficially active on BlueSky for now is exactly the single-point-of-failure (and control!) character of a network that has a single hub. As Cory Doctorow explained in detail, this means that BlueSky is so far a lock-in based network, in spite of the promises to set up a federation of servers. I don't want to be locked in!
Medet Ahmetson 2024-11-18 05:01:45 I've seen the rise of decentralized social networks. BlueSky is one of these. Did you check others such as Mastodon with Activity Pub, Nostr (from bitcoin maximalists), and others on this trend train?
Konrad Hinsen 2024-11-18 07:48:29 Mastodon (which I use) and Nostr are indeed decentralized networks. BlueSky so far is a centralized network that promises to become decentralized.
Sam Gentle 2024-11-15 23:50:36 Random thought about Things Spreadsheets Got Right – I've heard a lot about "no invisible state" etc, but another interesting thing about spreadsheets is that they treat data as a first-class citizen in a way that most programming models don't.
In a conventional programming language, you model processes and leave the data implicit; in a spreadsheet, you model data and the processes are implicit. The data is what you see in the cells, and the processes are plumbing that you only see by inspecting the cell that the data lives in. What other programming systems start with the data you want to process before you write the process itself?
And maybe spreadsheet programming's lack of implicit state is actually a consequence of this data-first paradigm, rather than an end in itself. In fact, even calling data "state" implies a kind of process-first mindset, only conceptualising data through its relation to a process. And this could be a key blind spot for programmers creating systems for non-programmers, or rather process-first people creating systems for data-first people.
Dany 2024-11-16 08:04:48 Algorithms and Data Structures. These are the ying and yang of computer engineering. I always felt that it's missing the actual data. We have a trinity: Algorithms + Containers + Data. In a way, first data engineer.. then big data and now LLMs is computer science discovering data.
Konrad Hinsen 2024-11-16 09:09:24 In Glamorous Toolkit, I often work mostly data-first. This short video shows how this works. Once you have the raw data in your system, you write views to display it in a domain-specific way, and then you go on writing the code to process.
Full data-first, like in a spreadsheet, is possible only if your programming system provides entry forms for exactly the data structure you work on. E.g. a grid of cells in a spreadsheet. In any other scenario, you first need some code to get your data into the system.
Jari 2024-11-16 16:06:20 Again, imho, worth thinking: what if your data consists of millions of rows. Data-first aspect gets a twist then.
Ivan Reese 2024-11-16 20:09:40 ^ also, worth ignoring. There’s a popular rejection of ideas that don’t have line-of-sight to use “at scale”, which manifests as a pressure to validate ideas based on how they scale and reject other kinds of validity. It’s quite harmful in situations like the one Sam raised where we’re interested in human factors, because considering scale is often a consideration of the machine factors (or business factors).
I don’t want to disregard scale entirely, but just caution that it’s too often given too much weight (especially here in FoC circles).
Ivan Reese 2024-11-16 20:11:06 On the other hand, I hope some people see it as a design challenge and go do cool human-centered things that scale to massive datasets. That’d be interesting. But it’s not necessary, and often misleading.
Jari 2024-11-16 23:05:20 It is worth thinking and gaining perspectives. Some thoughts are then worthy - or not, it depends. For instance for me, it is clear that data-first has certain limits, and eg. model-first thinking is more powerful approach. If a cell in a spreadsheet has a lot of data, there is basically no practical way of inspecting it. If it has a lot of functions, there is a little chance to make sense out of it, which is at least possible with programming langs
Konrad Hinsen 2024-11-17 10:32:44 Size is a distraction, in my opinion. The two most relevant asepcts of data are (1) its representation in the computer and (2) its representations suitable for humans, both for inspection and for manipulation.
The relation between (1) and (2) is highly domain-dependent, and that makes it difficult to come up with general principles.
