mojuba

> Which means we need people like Alice! We have to make space for people like Alice, and find a way to promote her over Bob

The solution is relatively simple though - not sure the article suggests this as I only skimmed through:

Being good in your field doesn't only mean pushing articles but also being able to talk about them. I think academia should drift away from written form toward more spoken form, i.e. conferences.

What if, say, you can only publish something after presenting your work in person, answer questions, etc? The audience can be big or small, doesn't matter.

It would make publishing anything at all more expensive but maybe that's exactly what academia needs even irrespective of this AI craze?

You are not alone.

15 years ago I was thinking about switching my career to a different industry altogether, just didn't know what it would be. One thing I knew was that I was so tired of building web sites and backends. Boring, repetitive, uninspiring.

Then a friend asked me to write a simple iPhone app. I had no idea what development for Apple platforms would be like...

Fast forward to 2026, I'm 57 now, still in tech, building apps for Apple platforms, still enjoying it very much.

Good quote:

> AI should learn to say two things: ‘I don’t know’ and ‘you’re wrong.’

My guess is, the next evolutionary step of LLM's should be yet another layer on top of reasoning, which should be some form of self-awareness and theory of mind. The reasoning layer already has some glimpses of these things ("The user wants ...") but apparently not enough to suppress generation and say "I don't know".

> I would absolutely not call Rust a simpler Swift. Swift doesn't have and ownership/borrowing system

Swift already does have those things but unlike Rust, they are opt-in.

Not going to argue which language is simpler, but sorry, you don't seem like someone who knows Swift very well.

You don't even need to reinvent a walkable city, just look at any medieval historical town that is say ~500 years old, almost untouched, and has restricted traffic today (possibly with no public transport whatsoever). These towns are a pure joy to live in, they are walkable with no other options, quiet, pleasant and overall healthy to live in in all respects.

I'm a big fan of Swift (and SwiftUI), such a concise and elegant language. Beauty.

Also I appreciate how you made all backend calls just static functions which they always should be. People tend to overcomplicate these things and add a lot of boiler plate and unnecessary bureaucracy.

Going to try your app, thank you!

P.S. tried it, already miss the `threads` tab

Absolutely. Even worse, when you ask AI to solve a problem it almost always adds code even if a better solution exists that removes code. If AI's new solution fails, you ask it to fix, it throws even more code, creates more mess, introduces new unnecessary states. Rinse, repeat ad infinitum.

I did this a few times as an experiment while knowing how a problem could be solved. In difficult situations Cursor always invariably adds code and creates even more mess.

I wonder if this can be mitigated somehow at the inference level because prompts don't seem to be helping with this problem.

> AI will make this situation worse.

Being an AI skeptic more than not, I don't think the article's conclusion is true.

What LLM's can potentially do for us is exactly the opposite: because they are trained on pretty much everything there is, if you ask the AI how the telephone works, or what happens when you enter a URL in the browser, they can actually answer and break it down for you nicely (and that would be a dissertation-sized text). Accuracy and hallucinations aside, it's already better than a human who has no clue about how the telephone works or where to even begin if the said human wanted to understand it.

Human brains have a pretty serious gap in the "I don't know what I don't know" area, whereas language models have such a vast scope of knowledge that makes them somewhat superior, albeit at a price of, well, being literally quite expensive and power hungry. But that's technical details.

LLMs are knowledge machines that are good at precisely that: knowing everything about everything on all levels as long as it is described in human language somewhere on the Internet.

LLMs consolidate our knowledge in ways that were impossible before. They are pretty bad at reasoning or e.g. generating code, but where they excel so far is answering arbitrary questions about pretty much anything.

Nice! Sent you a message via the contact form.

So the market is going to be flooded with this type of soulless books that have no distinct character or style, just pure dry facts?

In a sense, "I wrote a book about it" is disingenuous and I agree the author's bullet list would probably be more interesting and would save us a lot of time.

Well I'm pretty sure the author can make a compliant C compiler in a few more sectors.

Compare that to the C compiler in 100,000 lines written by Claude in two weeks for $20,000 (I think was posted on HN just yesterday)

I have two problems with that. One is, you can do what you like quietly and without disturbing anyone around you. Second is the Dunning Kruger effect: witnessing it first hand is never fun.

> Doing it badly is doing the thing.

No it's not. Sometimes (or maybe most of the time) doing it badly means maybe it's not your thing.

I used to have a neighbour who liked to play the piano and sing. He was doing it consistently badly and he didn't have anyone to tell him that he should probably stop trying.

Yes but that doesn't explain why we aren't given a choice. Program code is boringly deterministic but in many cases it's exactly what you need while non-determinism becomes your dangerous enemy (like in the case of some Airbus jets being susceptible to bit flips under cosmic rays)

It didn't make pointers safer to use though. In Swift and some other modern languages you can't dereference an optional (nullable) pointer without force-unwrapping it.

It's a good article but I think you need to start explaining structured concurrency from the very core of it: why it exists in the first place.

The design goal of structured concurrency is to have a safe way of using all available CPU cores on the device/computer. Modern mobile phones can have 4, 6, even 8 cores. If you don't get a decent grasp of how concurrency works and how to use it properly, your app code will be limited to 1 or 1.5 cores at most which is not a crime but a shame really.

That's where it all starts. You want to execute things in parallel but also want to ensure data integrity. If the compiler doesn't like something, it means a design flaw and/or misconception of structured concurrency, not "oh I forgot @MainActor".

Swift 6.2 is quite decent at its job already, I should say the transition from 5 to 6 was maybe a bit rushed and wasn't very smooth. But I'm happy with where Swift is today, it's an amazing, very concise and expressive language that allows you to be as minimalist as you like, and a pretty elegant concurrency paradigm as a big bonus.

I wish it was better known outside of the Apple ecosystem because it fully deserves to be a loved, general purpose mainstream language alongside Python and others.

Yeah, it's especially handy in UI code where you can have asynchronous operations but want to have a clear start/end indication in the UI:

    busy = true
    Task {
        defer { busy = false }
        // do async stuff, possibly throwing exceptions and whatnot
    }

Huh, I didn't know about `return` in `defer`, but is it really useful?

I don't know Rust but, can this `defer` evaluate after the `return` statement is evaluated like in Swift? Because in Swift you can do this:

    func atomic_get_and_inc() -> Int {
        sem.wait()
        defer {
            value += 1
            sem.signal()
        }
        return value
    }

I like how Swift solved this: there's a more universal `defer { ... }` block that's executed at the end of a given scope no matter what, and after the `return` statement is evaluated if it's a function scope. As such it has multiple uses, not just for `try ... finally`.

Skimmed through the article, some interesting numbers but not a single statistic is per capita (or per million, whatever). How do I understand the scale of the phenomenon without the per capita figures? Sorry but seems a bit useless.

Thanks, that's a great explanation!

Definitely too many to be random. I think they are all mostly soviet era things, no? So the author is likely an émigré from the USSR.

Thanks. So no fear of losing important stuff to the noise?

Also mind you, this is not about productivity. If you don't want to act on something, you delete it.

> I apply a strong inbox 0 methodology

Tangential to the main topic, but this is the only sensible way of running an email inbox, always has been to me, and it boggle my mind, why would anyone let clutter and a piling number of unreads in their one and only inbox, one of the most important things in our digital lives?

Each email is an action item. If it's not or if it's been addressed, it's gone, period.

Archive vs. Delete is another question but not as important. Over time I've found that I'm probably deleting too much (e.g. where did I buy that <nice thing> 5 years ago? want it again, can't find the order). Then business emails are all archived with the exception of business spam of course.

So why would you have more emails in your inbox than items you’re supposed to act on?

> Groups of zeros can be omitted with two colons, but only once in an address (i.e. 2000:1::1, but not 2000::1::1 as that is ambiguous)

Can someone explain why it's ambiguous?

On the subject, IPv6 is one of the strangest inventions on the internet. Its utility and practically are obvious no matter how you look at it except... just one thing.

Network-related things are generally easy to remember and then type from memory: IPv4, domain names, standard port numbers. Back in the day it was the phone numbers, again, easy to remember and dial when you need it. IPv6 is just too long and requires copy/paste all the time. This is the only real reason in my opinion, why IPv6 is doomed to be second-grade citizen for (probably) a few more decades.

However once you learn that sed means stream editor, you won't ever forget it. libsodium is forgettable.

There's a shorter form of it:

  guard let self else { return }

which annoyingly the AI's don't know about.

I don't disagree but notice how it's about the second decade of Web 2.0, not the first one. Profit-driven algorithms is a separate era in its own right. I.e. you can't blame the skyscrapers themselves for your shitty life, you just need to demand more regulation.