davidbalbert

Repeatedly, we’ve thought that humans and animals were different in kind, only to find that we’re actually just different in degree: elephants mourn their dead, dolphins have sex for pleasure, crows make tools (even tools out of multiple non-useful parts! [1]). That could be true here.

LLMs are impressive. Nobody knows whether they will or won’t lead to AGI (if we could even agree on a definition – there’s a lot of No True Scotsman in that conversation). My uneducated guess is that that you’re probably right: just continuing to scale LLMs without other advancements won’t get us there.

But I wish we were all more humble about this. There’s been a lot of interesting emergent behavior with these systems, and we just don’t know what will happen.

[1]: https://www.ox.ac.uk/news/2018-10-24-new-caledonian-crows-ca...

  #include <stdio.h>
  
  struct foo {
   uintptr_t p __attribute__((xnu_usage_semantics("pointer")));
  };
  
  int main() {
   struct foo f = { 100 };
  
   printf("%lu\n", f.p);
   return 0;
  }

I also just realized that the latest tagged release of https://github.com/apple-oss-distributions/clang is 800.0.38, my clang is reporting 1400.0.29.102. Is Apple no longer releasing the source for their compilers?

I can see references to these builtins in the latest xnu source[1], but not in upstream llvm[2], or Apple's forks of llvm[3] and clang[4].

It's been possible to build your own XNU[5] for a long time. Is that still possible now?

  [1]: https://github.com/apple-oss-distributions/xnu
  [2]: https://github.com/llvm/llvm-project
  [3]: https://github.com/apple-oss-distributions/llvmCore
  [4]: https://github.com/apple-oss-distributions/clang
  [5]: https://kernelshaman.blogspot.com/2021/02/building-xnu-for-macos-112-intel-apple.html

> Fun aside: I’ve always assumed this is why Core Foundation exists—to provide a common interface between Carbon and Cocoa. I don’t actually have a citation for this, though.

This (very enjoyable) blog post from 2006 confirms it: https://ridiculousfish.com/blog/posts/bridge.html. I believe ridiculous_fish was working at Apple at the time.

[1]. https://www.amazon.com/gp/aw/d/B01FIPHEXM

In the mean time, we'll tweet about every issue on https://twitter.com/hackerschool, but I know that Twitter isn't RSS and that subscribing to our Twitter feed in order to get the 4 tweets per year that you want to see might be silly.

r0ml is an software architect and systems designer with over thirty years of experience. For two decades, r0ml worked on Wall Street, developing market data, trading, risk management, and quantitative analysis systems. More recently, as chief technical architect at AT&T Wireless, he drove the improvement of their CRM, ERP, commission, and data warehousing systems. Over the last several years, r0ml has become increasingly interested in open source software strategy at large enterprises, and is a frequent speaker on the topic.

This is the same R0ml that thaumaturgy mentions in a sibling comment.

I've been lucky to meet a lot of very smart programmers over the past 3.5 years working at Hacker School, and R0ml is one of the people I respect the most. He has a lot of opinions about programming, many of them contrarian. I think this comes from his background. His career began in the '70s. He spent the first third of it working in APL, the next third in Smalltalk, and the most recent third in Java. Over the year or so that I've known R0ml, he's planted the seeds of a number of unconventional ideas in my head (program in the database, don't use libraries, write things from scratch, the expressive power of a language is partially derived from what's in its standard library). I'm sure these aren't all good ideas—maybe some of them are terrible—but they've profoundly affected the way I go about my programming. R0ml is on the short list of people I would want to work for if I was not running Hacker School.

I don't bring this all up to refute your opinions–R0ml may be wrong in this case or even in all cases–I mostly wanted to give some context explaining why the tone of your response made me sad and frustrated. The onus is on us to give readers context for what they're reading, and I don't think we did a great job of that, but if you're going to write such a mean spirited response, I think some of the onus is on you to do some research before accusing someone of being a novice and responding in a way that feels at least partially ad hominem.

Around a month ago, I read Programming with Managed Time[^2], the paper that you wrote with Jonathan Edwards for Onward! '14. I thought it was insightful, well written, and contrarian in the best of ways. The first things I thought when I finished it was "I bet R0ml would enjoy that."

I don't mean to compare Code Words to an academic journal (it's absolutely not), nor do I mean to compare R0ml's article to your paper in terms of scope, research, or time put into it (yours obviously took more time and has much greater insight than R0ml's short article). I'm just bummed that one person who's counterintuitive opinions and experience I respect would be so quick to dismiss the opinions of someone else who I respect for the same reasons.

I know that complaining about tone is often used to distract from more substantive issues, but I'm going to risk doing that anyway: Please be nice!

Thanks.

[^1]: http://conferences.oreillynet.com/cs/os2006/view/e_spkr/1551

[^2]: http://research.microsoft.com/pubs/211297/onward14.pdf

Another side effect of anonymized applications is that we get to read a lot of funny application names (Beet Manager, Pastry Magician, Bean Pain).

If you think the social rules don't treat people like adults, you're fundamentally misunderstanding them. The purpose of the rules is to make us all aware of the ways that we can unintentionally frustrate and hurt each other, not to shame people. The rules are not enforced top down, nor do you get in trouble if you break one. The way you treat a person like an adult is by being honest with them when they make you feel frustrated or uncomfortable and having an adult conversation about it.

Our job is to build an environment where everyone at Hacker School feels safe to focus on becoming a better programmer. I don't think you could find a single Hacker Schooler who would disagree that the social rules made for a better environment, and there've been well over 350 so far.

[1] cf. https://www.hackerschool.com/blog/28-treating-people-like-ad...

We put it in the job description because we think it's true[^1], but the last thing we want to do is scare people away.

[^1] If we get really big and you're in charge of operations, you'll be COO by definition. If we stay the size we are now, it seems unnecessary to call anyone a COO (or any of the other C*O roles).

Thank you for taking the time to make such a thoughtful and considerate comment. You have gotten to the nut of what I was thinking when I wrote the post and said it more eloquently than I did.

The primary reason to have a word is that we can have something to refer to ourselves (where "we" are members of the Hacker School community). I think most communities come up with words to refer to their members. It certainly happened in ours: there are a handful of words that people at Hacker School use to refer to themselves and new ones come up regularly.[^1]

The things to consider when figuring out what to call someone who does Hacker School is not what the outside world will think, but whether people who do Hacker School will feel comfortable wanting to use the word to describe themselves and whether we would be alienating anyone who would otherwise enjoy coming to Hacker School.

[^1]. The question of how much we as facilitators should try to influence that process is probably out of scope for this discussion. Let's just assume we've decided that we want to have some input. I can't resist footnotes, even in comments. Yeesh.

I agree that curiosity, tenacity, perseverance, patience, and imagination are all qualities that good programmers have, but when thinking about how I can improve, I find the question "How can I be more curious?" less helpful than "How can I be more systematic when I'm debugging?"

I'd very much like to do this.

One of the surprising things we've learned while running Hacker School is the extent to which your comfort level dictates how much you will learn. To learn effectively, you need to be able to ask questions without worrying about looking stupid, you need to be able to admit when you don't know something, and you need to be able to jump into things that are over your head and know that you'll be able to figure them out as you go. Your ability to do all of these things is related to how comfortable you are with your environment and the people in it.

When I wrote about the situations where people build friendship, comfort and trust, I wasn't thinking about pairing sessions (though it can happen there). I was thinking about all the other things you end up doing when you're in the same place with a bunch of people for an extended period of time. Comfort gets built during group lunches, on the weekends, at movies, concerts, in the park, at bars, the beach, etc. Hopefully this clears things up a bit.

EDIT: "talking" -> "thinking" in the second paragraph.

  (defn events [object type]
    (let [out (chan)]
      (.addEventListener object type (fn [e] (put! out e)))
      out))