tmerr

My read of Turing's paper is that he proposes replacing the question of "Can machines think" with a behavioral test. I doubt he would try to argue that passing the test implies that a machine is conscious, he's saying that harder question is practically not important. Maybe the most relevant thing quote from the paper

[of consciousness] I do not think these mysteries necessarily need to be solved before we can answer the question with which we are concerned in this paper.

So I feel like Dawkins is kind of strawmanning what Turings argument was, or arguing based on a confused popular understanding of it. There is another answer between "yes it's conscious" and "no it's not" that is "I don't know", or "it's not a meaningful question", that feels like the more honest position right now.

I agree with another commenter here that Dawkins piece is interesting in another sense though. As I'm reading through the conversation with Claude, the response "That is possibly the most precisely formulated question anyone has ever asked about the nature of my existence" jumped out to me as a little sycophantic. Maybe it is easier to believe that a machine is conscious when it is agreeing with you and making you feel closer to it.

Where to start. The process I see work well in practice is.

1. Generate an idea. 2. Let critics help identify flaws. 3. If it's unsalvageable give up. Otherwise, modify the idea and go to (1).

This works well in a collaborative environment where people share ideas early.

The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.

Assuming this blog post is based on real world experience, I want to point out that this describes a very slow feedback loop, and it's not necessarily typical or a good thing.

My personal site is tmerr.com

There is one post, and I haven't shared it publicly before so that's something!

This is interesting to hear, but I don't understand how this workflow actually works.

I don't need 10 parallel agents making 50-100 PRs a week, I need 1 agent that successfully solves the most important problem.

I don't understand how you can generate requirements quicky enough to have 10 parallel agents chewing away at meaningful work. I don't understand how you can have any meaningful supervising role over 10 things at once given the limits of human working memory.

It's like someone is claiming they unlocked ultimate productivity by washing dishes, in parallel with doing laundry, and cleaning their house.

Likely I am missing something. This is just my gut reaction as someone who has definitely not mastered using agents. Would love to hear from anyone that has a similar workflow where there is high parallelism.

Yes the situation sounds similar to regular files to me. Iiuc mmap can implicitly sync to files, but it is only guaranteed after unmapped (akin to closing a file) or an explicit call to msync (akin to fflush).

This has me thinking, it could be a fun project to prototype a convenient file interface based on pointers as a C library. I imagine it's possible to get something close to what you want in terms of interface (not sure about performance).

I suspect in some cases it will be more convenient and in other cases it will be less convenient to use. The write interface isn't so bad for some use cases like appending to logs. It's also not bad for its ability to treat different types of objects (files, pipes, network) generically.

But if you want to do all manipulation through pointers it should be doable. To support appending to files you'd probably need some way to explicitly grow the file size and hand back a new pointer. Some relevant syscalls would probably be open, ftruncate, and mmap.

I mean. I've owned several IoT devices that work either locally or over the internet. Some of this you can just blame on local networks being fiddly in ways that are difficult to control.

Over local network it's an unreliable assumption that device A can discover device B through some form of broadcast. There are ways to intentionally or unintentionally block that. And then even if you know each party's IP, some networks will intentionally isolate different users for security reasons.

Is it an Apple/Android limitation or a more basic networking limitation that drives devices to communicate with centralized servers on the internet?

And yes I agree it does seem ridiculous.

For another data point: last week I ordered my first PCBs from JLCBCB. 2 fully assembled (parts already soldered) and 3 bare. $40 for the boards themselves, $40 for shipping, and $20 for US Tariffs, for total $100. Should take a week to arrive, shipping's cheaper if your willing to wait a month.

Re help: I asked for some help on libera ##electronics. I think there are larger communities on reddit that would also take a pass over designs.

My impression is that for straightforward circuits (not very high frequency or high power) you can get away with almost anything as far as layout goes. You punch in some generous setting for spacing of traces etc in the CAD software and it does some basic validation. (Are all the parts connected, not too close?).

I used KiCAD. It works well, though for assembly EasyEDA is probably lower friction. I had to dig around to find the right footprints for certain parts.

Heh, I'd recommend replacing dead links on the blog with https://web.archive.org/ ones.

Based on how broken the site's external links were I incorrectly concluded the whole blog was created by genAI. Then I thought to check web.archive.org and found they're legitimate links & it's just internet bit rot.

A more optimistic takeaway is that if you set out to solve a hard problem then you might be surprised about your tech's applications elsewhere. Between 1983 and 1989 they built a company that they went on to sell for ~25 million, or ~64 million in 2024 dollars. I don't know how much went into it but it doesn't sound like an obvious failure.

http://pqasb.pqarchiver.com/latimes/access/60130710.html?did...

The ideal set of building blocks depends on the problem.

If the building blocks make it easy to write concurrent code (Go, Erlang), then it becomes easier to write a server. If they make it easy to represent "A or B or C" and pattern match on trees (ML-like languages), then it becomes easier to write a compiler.

Add to that: if you are trying to make an easy to onboard language, you want to look at how beginners use it, not experts. Someone writing a compiler for language X is certainly an expert in X.

Maybe the decline of desktop applications (Java, C#) and Android (Java)? And then Go coming out with some killer frameworks? I have to stretch my imagination to imagine anything causing Go to outpace C# or Javas ecosystem.

I'm 30 and have been using vim since college. Usually I'm not actually using the vim editor, but some IDE that has vim keybindings. Good enough for me since I don't customize it much anyway. And then I get the best of both worlds: IDE features for navigating around files (jump to definition, display references), and vim for navigating within a file. Professionally I never paid attention to how many people are using it. Off hand I know a couple people that use emacs, and zero that know vim, but this is probably because emacs users talk about emacs :)

Social media is played up like reality TV. Perks are good but working at a faang is 90% just work, like anywhere else.

FWIW, the default concurrency has been changed to "unlimited" since the 0.1.0 release.

Nice! Will that end up on Github?

Out of curiousity, what do you want

Most often I want to return just the first error. Some reasons: (1) smaller error messages passed across RPC boundaries (2) original errors can be inspected as intended (e.g. error codes) (3) when the semantics are to cancel after the first error, the errors that come after that are just noise.

A couple other thoughts

  - I think the non-conc comparison code is especially hairy since it's using goroutine pools. There's nothing wrong with that and it's fast, just not the easiest to work with. Often goroutine overhead is negligible and I would bound concurrency in dumber ways e.g. by shoving a sync.Semaphore into whatever code I otherwise have
  - I like that errgroup has .Go() block when concurrency limit is reached. Based on a quick skim of the code I think(?) conc does that too, but it could use documentation

Ahh having a generic pool abstraction that collects results is tempting... nice work. I likely won't use this library though, since

  - I don't want to mess with panics.
  - The default concurrency GOMAXPROCS is almost never what I want.
  - Aggregated errors are almost never what I want. (I haven't read the implementation, but I worry about losing important error codes, or propagating something huge across an RPC boundary).
  - Using it would place a burden on any reader that isn't familiar with the library

My advice:

Tell the teammates that you want to see them grow to become code reviewers. At first require PRs to be approved by two people: first someone else reviews it. once they LGTM, then you review it for final approval. Do this for a while, until you start noticing like you have little to add. And then grant the relevant reviewer the privilege to review in a single pass. Bus factor += 1, and better knowledge transfer.

That is the process you'll have when you get back. But in the short term, it's probably fine to let them approve each others code while you're gone. Yes they might they break something.. but you can always roll back (I hope). Blocking all PR merging until you return sounds a little overkill to me, but there might be some reason the stakes are so high that I'm missing.

That's a great question. What I've seen is versioning de emphasized. Good unit & integration test coverage to prevent refactor breakage. And when you make a large change that affects consumers of your library, you find a way to do it incrementally. E.g. instead of changing a function's parameters, you can create a second function, migrate everyone over, then delete the old one. And of course, you would not ordinarily modify another teams code without first getting their LGTM.

Better to tune this out even if you're a beginner. You normally don't say "The big O of the algorithm is ..." because it's ambiguous whether you are talking about time complexity or space complexity. Also, when someone says O(n), then n has to refer to something, normally the input size. The text area doesn't even have you define your input, and will say things like

for (i =0; i<x; i++) { }

is O(N), without even knowing what x is (could be a constant).

Code becomes tightly intertwined and the dependency graph becomes unwieldy

One way to combat this is to use a build system with a notion of visibility, https://bazel.build/concepts/visibility

I think you might be over-extrapolating from your experience, but it's true going off the well-trodden road leads to surprises. And not that many smaller companies know the ins and outs of monorepos.

I absolutely believe in this after working both ways. With feature branches I would waste time rebasing, resolving merge conflicts, to then come up with the perfect pile of commit messages before sharing with the team. Committing to master forces early collaboration & tighter feedback loops.

Edit: I don't know about post merge code reviews, that seems like a risky idea to me at scale

I've never worked anywhere that deadlines were set with enough precision that +/- 20% would be distinguishable from noise. I think it would be lost to more significant factors like differences in employee productivity and unexpected roadblocks

Sure. But without every piece of the pie accounted for we can't tell whether the increase in money to funds is representative of the whole, or caused by shifting preferences

Thanks. It might include more than I expected, but still "exchange-traded and long-only funds" would be missing anything that's not considered a fund, like individual stocks, that are still nonetheless in my mind part of "Stocks" in aggregate. Maybe they account for this, maybe not, it's really hard to understand without real sources in the article. All it really says it is some BofA report without any link to it.

Probably cherry-picked stats. The article says "Investors have poured almost $900 billion into equity exchange-traded and long-only funds in 2021". So does that sum together to all "Stock"? What about mutual funds? And what even are long-only funds, are those popular?

https://web.archive.org/web/20211125175105/https://www.bloom...

It prints "Me Too." then "I love Geeksforgeeks". What is strange about this?

Another inconvenience with this approach is that you can keep thousands of paths in memory no problem. But thousands of FDs may cause you to exceed per-process limits.

I do something similar but take it a step further and statefully track the progress of the workflow. The code generates a file that is like a TODO list, and a separate command runs a single step before marking it complete. Great for longer running workflows (days).

I wonder if there are any examples of Google previously spinning off companies and selling them. It's hard to imagine it given how entrenched most products are in its internal software ecosystem

IMO the video and the home page grain-lang.org dive too quickly into features without giving a compelling answer to "Why should I use Grain?".

"Powered by WebAssembly": Other languages can compile to WebAssembly as well as other targets. Why is limiting to only one target considered a good thing? What does it buy you? (if it's unique that it has a GC, or if the GC is performant that may be a good reason. Advertise it!).

The vision of bringing ideas from functional/academic languages into the mainstream is noble. But the language features seem very run of the mill? I don't understand what it's referring to.

Comments on the standard library:

* Reference docs should make more clear the differences between Array and List. I assume Array is a fixed size contiguous array of data with constant time get and set? And List is an immutable linked list. But I had to wander around docs and implementation to reach that conclusion.

* Reference docs should probably mention List syntax in the List docs. Ditto for Arrays. You normally expect to see that at the top of the page, vs as a surprising comment "An alias for normal syntactic array access, i.e. array[n].". It's hard to tell what is a library feature vs primitive to the language.

* {Array,List}.append: In most languages I have used append means to append a single element (or in Go's case it is variadic). I would probably rename this to concat and remove the existing concat function.

* What is the benefit to having a separate Stack type vs adding convenience functions to List?

  let List.push = (value, list) => list.
  let List.pop = (list) => (value, list).