This place was amazing, and worth a whole afternoon every time I went there. The owner was even more interesting, and a whole story in his own right. (I just looked at his wikipedia entry- wasn't aware there have been features on him! https://en.wikipedia.org/wiki/Ed_Grothus)
He was not just an interesting person, but had a fantastic memory for what was in the place (though I think that was quite selective.) I came in one day looking for an aluminum plate I could use as a heatsink, but I was hoping for something with rounded edges so it wouldn't cut my car seat (for my overly-hot laptop.) He squinted for a few seconds, and then walked directly to a giant pile of random metal debris, and threw a bunch of things aside, reached in up to his shoulder, and pulled out _exactly_ the piece I needed, including chamfered edges on one side.
I am sad places like this are going away quickly. I made a map a long time ago dedicated to documenting places like The Black Hole - scraphounds are welcome to update it with interesting destinations. https://www.google.com/maps/d/u/0/edit?hl=en&mid=1Y1XmPsqClK...
I have 15+ years of PCB design experience. Mostly hobby stuff but a fair amount of processional work. Kilowatt range brushless motor controllers, basic RF stuff, lots of microcontroller stuff.
I had Fable design an LED earring. Rechargeable coin cell, RP2350 cpu, IMU, 45 addressable LEDs. It made two mistakes - missed the through holes on the coin cell holder footprint and made the center pad too small. I was able to have JLC swap the through hole battery holder for a surface mount one, and I put a little solder on the small center pad to make it stick up above the mask. They work great! It took 6 days of Fable usage, so about $50 on my Max plan. Very cheap for hardware dev.
I was sufficiently impressed that I’ve been going over old circuit board designs. Some half finished, some completed but in need of a next rev, and I’m getting so much done.
To see it hit the mainstream like the OpenAI announcement, I think big things are coming for this world and by and large they are not ready for it.
For my part, I have always loved PCB design and layout but I simply can’t keep up with the amount of labor required to build what I want, so I welcome this change.
I have also begun exploring more advanced algorithms for PCB manipulation. I have a fairly dense board that needs a few more small chips added. I have an algorithm now that can kinda shuffle and jostle things around so you take up all the spare microns of space across a region of the board and make openings to squeeze a little more in there. It’s pretty cool to see the visualizations as I have it generate movies of the component drift. I foresee much more powerful tools like this in the future.
One tip: have it make a project web page with a chronological list of big changes and detailed visualizations for everything that happens. I can actually prompt all of this on my phone while I am out and about, and view the results on a Tailscale served local page. I’ve always wanted to be able to do PCB design when away from home and now I can!
... Ted Nelson’s 1974 manifesto, Computer Lib/Dream Machines, extolling the vision of Project Xanadu hypertext.
Computer Lib/Dream Machines was not about project Xanadu, it merely mentions it on a few pages.
I recall Computer Lib/Dream Machines was the most influential thing Ted Nelson did, far more influential by than Xanadu. It was seen all over at the beginning of the personal computer era. Try to get a look at a copy if you can, it's fascinating.
This self-published book was very much of its time - it had the same oversize-on-newsprint format and DIY look as the Whole Earth Catalog, which was popular at the same time.
It was important because it pursuasively made the case that computing was about to become a medium for self-expresson - a "dream machine" - that was an unheard-of concept at the time. You can use a computer to produce graphics! To play games! How about that! He told about Sutherland's Sketchpad, Englebart's NLS, and the Arpanet at a time when these were completely invisible to almost everyone. Xanadu gets a few pages in the book but it is not at all a work of self-promotion - almost the whole book is about the work of others. It's a survey of the computing scene right before personal computers appeared.
This book was very timely and I think it provided a lot of inspiration for the personal computer movement. It made you want to try out computing! It has one page about microprocessors: "Here they come ... Microprocessors are what's happening" (the MITS Altair appeared the next year, in 1975).
I think Ted Nelson is one of those people whose main effects are through their influence on others, rather than through what they directly produce themselves.
A marker of progress will be when Amazon converts to automated picking. They've been trying hard for almost a decade now. They had an annual competition for years. They have a decent picking robot developed in house.[1] It's not being deployed in quantity yet.
Nor does it have anything like a humanoid hand. Just a two-surface gripper.
Amazon's production robots are mostly automatic guided vehicles, not manipulators.
I'm impressed with how far legged locomotion has come. But as yet, nobody seems to be using legged robots for any commercial purpose beyond the demo level.
Is Tesla still going to produce vast numbers of humanoid robots by the end of 2026?
There's been a lot of progress on the hardware side. Motor technology from drones has produced much better robot motors. The sweet spot on gear reduction seems to have been found. (Too much reduction, and you can't back drive. Too little, and the motors have to be too big.) The volumes are now large enough to justify making robot-specific components. Robot arms are much better than a decade ago. So are robot legs. Control is better, too. It looks like a humanoid robot will cost about as much as a car.
But they're still not quite good enough to be useful.
We'll know they are real when an Amazon Prime truck drives up and a robot does the last 100 meters of the delivery.
Story time: I worked the night shift at a motel during college. "Bored to tears" was an understatement. I was poking around the front desk computer system one night, as one does, and found its data file. Lacking anything else to do, I wrote a little hex dumper in BASIC so I could explore the file. The first thing I noted was that customer names were spaced exactly N bytes apart. Oooh, fixed records! Then I spent the next week or so reverse engineering the DB file format. I'd twiddle a field in a random customer record then look at their record in the hex dump to see what changed, then update my notes.
Eventually I wrote another little BASIC program to run analytics, like which customers spent the most with us, and auto-fix mistyped names ("This says 'Bb Jones'. Did you mean 'Bob Jones'?") by writing directly to the file.
I cofounded Nameplanet, which morphed into GNR, and my name is in the ICANN docs for .name...
Basically, .name came out of us starting out as a webmail provider offering people to pick from ca. 60k domain names covering most common last names, because one of my co-founders and I both had firstname@lastname.tld email addresses.
When ICANN opened up for new TLDs we decided to try to offer the same more broadly.
So it wasn't just the registration, but initially also email forwarding..
None of the first batch of TLDs did as well as projected, and demand for .name was well below what we'd hoped, sadly.
For .name, it was a match of less demand than we thought and people not getting the third level thing, which led to eventually abandoning it as the main offering (after I'd moved on).
We ended up selling to Verisign a few years later.
Sometime around 1980-81 I had a part time job while an undergraduate in college doing system programming/admin for the Caltech High Energy Physics department.
Rob Pike was the system programmer/admin before me when he was a grad student in high energy physics, but he left to go work at Bell Labs.
One day another student, Karl Heuer, and I both were engaging in the common programmer pastime of complaining about the screen editors of the day and saying we could write something better.
Somehow this turned into a competition, and we both spent all night racing against each other writing our editors. It was mostly silent except for the typing, interrupted by the occasional announcement of some feature that was now working to hopefully rattle the other.
In the morning the other student system programmer/admin, Norman Wilson, got in and saw what Karl and I had been up to.
Norman mentioned this in an email to Rob Pike. His response was something close to this:
> Everyone writes a screen editor. It's easy to do and makes them feel important. Tell them to work on something useful.
It was only a couple years or so later that Rob Pike wrote a screen editor. I wonder if it made him feel important? :-)
A family friend had a yellow ~73 Duster. Tim Curry autographed her hood in spray paint. This was back in the early Rocky Horror days - a live performance in NYC, I think. Everyone adored the signature.
ff to mid 80's: She is leaving work. She gets to her parking space and sees that her hood is just yellow; the autograph is gone.
She's staring in shock when the attendant walks up to her and says in a heavy Arabic accent: "I'm so sorry that happened to you. I scrubbed and I scrubbed all morning until I finally got it all off!" and is just beaming at her. Her shock hasn't let up any. She manages to squeak out a "Thank you" and leaves.
Long before I ever encountered Richard Wallace's AIML (which was quite unintentionally silly, but not actually a joke, unfortunately), around 1996 I wrote some joke web pages to parody VRML, announcing "AIML: Artificial Intelligence Marketing Language", by taking a couple of gushing articles about VRML, strategically replacing "VR" with "AI", and tweaking just a few words.
The point being that the VRML hype back then was as bad as the AI hype right now (well maybe not QUITE as bad). I don't have a very high opinion of VRML obviously! They didn't bother integrating it with an extension language at the time, so it was useless.
To go along with the AIML parody, and give it a whiff of authentic scientific research, I formatted as html and published an actual AI research paper with the funniest title ever, by a company called Roanoke AI Laboratories, Inc., from The Journal of Theriogenology. (NSFW, unless you work in the Artificial Insemination industry!)
The author Jim Crump, Jr. actually found it by googling his name, and sent me a sincere email thanking me for formatting and publishing his AI paper on my web site, because his own publisher wouldn't allow him to publish his own paper on his own web site, due to draconian copyright restrictions. So I left it up because he was linking to it. Apparently it's well known in the AI Industry as the "Crump Technique". Attention is all horses need, too.
Eh everyone I know in YC answered this in an ethical way. In fact, I suspect YC keeps this wording to catch people admitting to something unethical while rewarding people who see something in a system that could be different.
My answer that got me accepted was that there was a lip syncing competition at my college that was dwindling because everyone had to submit a CD and sign up in advance. It also was held in an auditorium.
When I took over, I moved it to Spotify and moved the venue to the lawn, and we went from ~20 people the previous year to 1.2k the year I ran it.
I can shed some light here! This is going to be longish comment, but hopefully by the end of it you should understand _why_ we decided to avoid using the disk initially, even if you don't agree with that decision.
Historically, the decision to not use disk traces back to this comment https://github.com/rust-lang/rfcs/pull/1317#issuecomment-150..., which is perhaps the single GitHub comment that influenced my life most. Very high impact, thanks dgrunwald! Specifically,
>Don't store anything to disk. It's likely the oracle can be fast enough without doing this; and unnecessary complexity creates bugs. "Have you tried deleting the .ncb file?" (I remember having to do this a couple times per day when using VS, ca. 2005)
>Use lazy evaluation. The IDE is only interested in very specific bits of information, almost always restricted to a couple of lines around the cursor. Avoid calculating stuff that might never get used before it gets invalidated by the next code change.
>At least for C#, laziness saves so much time that incremental compilation is unnecessary for IDE purposes
The other part of historical context was that the motivation for creating rust-analyzer was that I didn't want to write a second Rust compiler (having been doing that for a couple of years at JetBrains). So it was explicitly an experimental project to prototype the right architecture for an IDE, to ultimately change how rustc works internally, so that, down the line, an IDE and a command-line compiler could use the same core. Given that rust-analyzer is now effectively a separate rust compiler, it's safe to say I am not good at achieving my life's goals!
In that context, I believe that avoiding disk was the _right_ decision:
* It's not really germane to the problem space, if all you need is literally a cache, it can always be added later.
* Disk is a can of worms of data consistency problems. They can be overcome with engineering effort to ultimately give better user experience, but user experience wasn't the primary goal. And using disk wouldn't actually illuminate the interesting aspects of the architecture, the intended primary goal.
* Finally, _not_ using disk would be a forcing function to keep analysis fast enough, to not make startup prohibitive.
The last one was a particularly big argument in my mind --- I didn't want to reach out for "easy" solutions prematurely, to avoid avoiding hard problems. And, again, my recollection is probably not 100% correct, but, until we added support for proc macros and build scripts, it was fine-ish from the perspective of startup time (RAM usage is a different story). The problem with proc_macros and build.rs is that they need to run the rust code, so they have to run the real rustc compiler, so all our usual IDE tricks ("information ... restricted to a couple of lines around the cursor") just don't apply.
The reason why we didn't add it later was that it seemed a relatively lower priority task than the work to share the parser between rust-analyzer and rustc. So that's what I was focusing on, though, I didn't deliver that. I still think we should do it! There's no _insurmountable_ technical reasons why the parsers can't be shared! It's just (a lot of) engineering work. And, while the parser is the boring part of compiler, it's the interesting part of an IDE.
Anyway, that explains how we ended up where we are.
That being said, I don't think that "just adding disk cache" is the right approach --- the salsa in-memory data structure is very sparse and pointy. Dumping that to disk would help somewhat, but wouldn't be a great long term solution. What is needed (I also explain this in https://matklad.github.io/2026/08/21/rust-glancer.html) is to design a compact, first class data format for representing analysis information about the crate, and than teaching rust-analyzer to be polymorphic in the source of data. For current workspace, you want to use a lazy incremental in-memory data structure (I do think we sadly need incrementally for Rust, given its compilation unit structure). For dependencies, you want to work off a compact on disk index. And, if the user "goes to definition" and mutates its file in place, we want to transparently switch between the two. The _pre requisite_ for that was to define a backend agnostic analysis API, and that work was always slowly progressing in the background (https://hackmd.io/ytd82QNiT_Ku2XFr1EAtiQ), but it generally took the backseat, while sharing the parser was the main focus.
I've posted this here before but I have been creating animations using a similar process with a regular camera and manually splicing the frames together. [1,2,3] The effect is quite interesting in how it forces focus on the subject reducing the background into an abstract pattern. Each 'line' is around 15px wide. I think I went through exactly the same thought process as the author, funny how ideas can come up independently like this.
I also shot a timelapse of the Tokyo skyline at sunset and applied a similar process [4], then motion tracked it so that time is traveling across the frame from left to right[5]. Each line here is 4 pixels wide and the original animation is in 8k.
In the mid-90s I taught a night class on Unix, and was experimenting with shell scripts from The Unix Programming Environment. There was an example using a loop and the who command to alert you when someone logged onto your local system. My cousin was a professor at a university several states away, and we had already figured out the talk command. So I decided to expand the examples in the book to use finger. By parsing the reply, somehow I could tell if my cousin was logged on, and I would send myself a notice. There was an ISP in the same building, and one day the ISP engineer came to visit me with a stern look. He asked, "By any chance are you sending a finger command every two minutes to this university's mainframe?" I proudly answered, "As a matter of fact, yes, I am!". I eagerly got out my Unix book to show him what I was doing. He just said, "Stop doing that. They have a system console logging program that has churned out dozens of pages of paper printouts because of you". I sheepishly acknowledged my mistake and quit running the script.
Ward Cunningham and I did something similar back in 2008.
We were both at a startup in Portland and our office was along the railroad tracks east of the Willamette. We were up on the 4th or 5th floor right above a lot of train traffic including Amtrak.
I brought in some extra Mac gear I had including one of the early iSight cameras which back then was an external device you stuck on the top of your display and connected to the Mac via FireWire. We set it up and rolled the desk over to the window in the office and turned the camera around pointing down at the tracks and Ward got to work hacking something up to do a slit scan.
It was a fun little project; the speed of the trains affected the horizontal compression of the images. We could tweak the software to expand or contract the size of the image by adjusting the number of slit scans per unit of time. Of course, that affected the exposure but I recall the camera having some automatic adjustments that gave us trouble.
That's about all we did with it. Just a quick afternoon hacking project. Neither of us thought much about it at the time so we didn't save anything.
Amit Patel was employee #7 at Google and built many things including the little geo display in the lobby that would show live search queries as dots color coded by language.
It's worth realizing that, before computerized central offices, telephone wiretapping required running physical wires. Back when Rudi Giuliani was prosecuting organized time, not only did physical wires have to be run, the cops were billed for them as expensive private lines. His task force was spending about a million dollars a year with New York Telephone on wiretapping.
In one case, law enforcement didn't pay their bill, resulting in the person being wiretapped having the wiretap connection show up on their bill, blowing the case.
That resulted in the Communications Assistance to Law Enforcement Act, which mandated that central offices offer remote wiretapping. Capacity up to 1% of lines is required.
Back in the electromechanical era, the only call data that could be collected was outgoing dial pulses, using a "pen register".[1] (The one shown in Wikipedia is mine. It's a beautiful piece of antique brass telegraph technology. It records dial pulses as dashes, and has to be wound up like a clock, with a big brass key.) The Supreme Court decision allowing "pen registers" without a warrant refers to these "extremely limited" devices. That definition has been stretched and stretched by law enforcement into all non-voice data collected by telcos.
> In 2001 Mark Probst implemented tail-call optimization in GCC
That's me.
The motivation back then was to allow compilers that target C to assume that tail calls will be "proper". That's different from an optimization, which is usually optional, and which compilers don't guarantee.
The LWN post briefly sketches why this is hard: C allows variable-argument functions (like printf) where only the caller knows for sure how many arguments it passed, which means that only the caller can clean up the stack, unless the stack frame size is also communicated, which "normal" C calling conventions don't do. But when the callee does a proper tail call, the stack frame that returns to the callee is not the stack frame that the callee originally sent. This is explained in more detail in my thesis starting on page 16: https://hostr.flingit.run/s/proper-tail-calls.pdf
I got rid of mine for a year thanks to a comment on HN. The only reason it came back is because of my lack of discipline. It's bearable as I only notice it when I actively listen for it now. Anyway, I am sure this would just work again.
So there was a comment that claimed it was related to bad neck posture. Being a keyboard warrior in my late 30s at that time I suffered the same issue: Tinnitus and generally bad posture. I figured that even if that wasn't true, working on my posture might be a good invest either way. So a couple of YouTube videos later I started working on it. Turns out the process to straighten your neck - even after like three decades - with just some casual invest everyday only takes about a month or two. To my surprise the tinnitus was actually also gone.
As I haven't build a real habit around the exercises eventually a bad posture came back, and so did the tinnitus. Both are generally not as bad as they were before, though.
I ran a few research tasks at JPL, small dollar studies.
We'd often recruit part time work from engineers around the lab through informal networks, (instead of the official channels that segment by "specialization").
One year, one of the developers on my task was the apparently last person who could encode the command sequences for Voyager 2 (hoping memory serves me correctly - event though it was only 8 years ago). She would occasionally come late to meetings because they were dealing with some trouble with the old satellite.
Pretty amazing how little is set aside for these projects that most the staff keeping it alive have "day jobs". I hope she's still uploading
This kind of observation is a big deal for solar physics.
It's been believed for decades that these small-scale (~100km and below) turbulent features are critical to understanding how energy dissipates in the Sun. And thus, how sunspots and flares form.
The subject has been very qualitative but is yielding on both observational and simulation fronts. I worked adjacent to this area from the 1990s-2010s, and it had been true that MHD numerical simulations of significant volumes of the Sun (but at a scale fine enough to resolve these features) were not possible. That has obviously changed!
Additionally, it had been that the best solar observatories could not quite resolve these features. In the late 1990s some of the best images came from a couple of observatories in the Canary Islands (e.g., the 1-meter Swedish telescope -- https://svs.gsfc.nasa.gov/4715/). The spatial resolution was perhaps in the ~100km range.
Of course, these are absolutely mind-boggling images. You're looking at a slice of the solar photosphere that has a temperature such that it activates a spectral line around 400nm. By isolating that wavelength, we can see what's happening at that temperature, and thus, sample a slice of the photosphere.
So, that had been the state of affairs. Now DKIST (4m aperture), with the particular instrument highlighted in OP, appears to be at a spatial resolution ~5x finer than the above imagery -- see Fig. 1c in the Nature paper (https://www.nature.com/articles/s41586-026-10871-3). It appears also (https://dkist.virtualsolar.org/vanNoortfastcam/) to be observing at 740Hz (!) for speckle reconstructions at ~1Hz.
At this scale, vortices of the flow are well-resolved -- where before you just resolved the convective cells but not the turbulent features around them. It's these turbulent features that are transporting energy.
To contextualize with respect to a HN perennial topic: DKIST (commissioned 2021) is funded by NSF, from the same pile of money that once funded Arecibo (up to 2020).
This is beautiful work! First, I thought this would involve using PCA to go from 3D to 2D, which would result in an easier selector to use, but at the expense of representing every person.
Then, I thought this would stop at using the U-space vectors (the ones that form the basis of the PCA image) and their corresponding ellipse to form our color space, but no, the function fitting is a very slick idea, even if it was executed by hand.
Lastly, I love the presentation of sampling from different r values. Whether you sample from a fixed r value or a range of r values, I bet this has great applications in game design or animation.
I still don't quite get the manual data labeling process at the beginning? It seems like it would encode some bias, but the consistency of the first point cloud and the results certainly speak for themselves.
Oh, this again. I should put a website with this up...
I was the person who personally ran 10.6 security updates at Apple (10.6.1+), the "DRI". My team in the Updates Program office and I reviewed every single bug to determine if it should go in a security and stability update or wait for the next major version. Seriously, every morning we group triaged all Mac OS X bugs, both incoming and those nominated internally for us to look at and determine if it should go in an update. I packaged and audited the builds and tuned the delta vs full updates. I built the system that largely automated diffing "trains" for software updates (automastering).
The new version of the OS was always being developed in a branch/train, and fixes were backported to the current version as they were found. They weren't developed linearly / one after another. So, if you are comparing the most stable polished/fixed/stagnant last major version with the brand new 1.0 major version branch, the newer major is going to be buggier. That would be the case with every y.0 vs x.8. But if you are comparing major OS versions, Snow Leopard was different.
Snow Leopard's stated goal internally was reducing bugs and increasing quality. That is a fact, not marketing. I am not sure why people on the internet don't believe that, but I was there. If you wanted to ship a feature you had to get explicit approval from leadership and the bar was high. In normal feature releases it operated bottom up "here is what we are planning to ship" and in Snow Leopard it was top down "can we ship this?".
AFAIK Snow Leopard was the first release of this kind (the first release I worked on was Jaguar or Puma), and was a direct response to taking 8 software updates to stabilize 10.5 and the severity of the bugs found during that cycle and the resulting bad press. Leopard was a HUGE feature release and with it came tons of (bad) bugs.
The first .1 or .2 ALWAYS fixed critical bugs, because:
1. You had to GM / freeze the software to physically create the CDs/DVDs around a month before the release. Bugs found after this process required a repress (can't remember the phrase we used), which cost money and time and scrambled effort at the last minute and added risk. This means the bar was super high, and most "bad, but not can't use your computer bad" bugs were put in software updates...which was developed concurrently with the end of the main release (hence why .1 came out right away)
2. Testing was basically engineers, internal QA, some strategic partners like Adobe and MS, and the Apple Seed program (which was tiny). There was very little automated testing. Apple employees are not representative of the population and QA coverage is never very complete. And we sometimes held back features from seed releases when we were worried about leaks, so it wasn't even the complete OS that was being tested.
Software updates are always needed, though the issues they fix became less severe over time due to larger seeds (aka betas), recovery partitions, and better / more modern development practices. But I can tell you FOR A FACT that Snow Leopard had fewer major bugs over its lifetime, coalesced very quickly, and was extremely solid when Lion was released.
It should be relatively straightforward to imagine — we already have that in gasoline-powered internal combustion engines.
The Watt-hours per kilogram of good Lithium Ion batteries is around 250-280 Wh/Kg; for Lithium Iron Phosphate it's about 180 Wh/kg, and for Sodium-Ion about 170 Wh/Kg.
The raw energy in gasoline is about 12,300 Wh/Kg but automobile internal combustion engines get only about 20-30% efficiency yielding about 2500-3600 Wh/Kg. For aviation piston engines it is a bit better at 25-30$ so 3000-3600 Wh/kg.
So, the batteries, instead of being 10-12X the weight of the gasoline for the same net driving/flying range, could weigh about the same as the gasoline. So, a typical car with maybe a 16 gallon tank and 30 miles per gallon fills up with 128 pounds (58 kg) of gasoline to get 480 miles of range. The Li-Ion battery for that range would weigh something like 1300 Lbs (590 kg). That is a substantial additional weight for a car that could be 2800-3800 Lbs in ICE configuration, so 35-45% added weight (a bit less because of savings on the ICE engine, etc). This requires everything else to also be heavier, from the structural frame, the suspension system, and even the wheels and tires (which is also unsprung weight, further impairing performance).
With a 130Lb/60kg battery instead, and saving the weight of the ICE engine and fuel system, the overall car design could go much more lightweight, regaining a lot of performance and range, all while gaining the huge torque of electric motors.
In aviation, a battery systems of that weight would enable all-electric aviation to go from small performance niches to the default for general aviation.
So yes, it would be a HUGE benefit to achieve 10X energy density batteries, and we do have reference points for people to imagine it.
Something I learned awhile ago is that most people that I consider "celebrities" really aren't that famous, and as such are generally pretty happy to respond to emails.
In ~2014 I sent an email to Joe Armstrong (one of the creators of Erlang) asking some questions about concurrency because I still didn't fully understand why Erlang was supposed to be better for it. I expected him to just point me to an FAQ or simply not respond [1], but instead he wrote a very long, detailed explanation about the rationale of Erlang's design. It was well-written and it made a lot of things "click" in my brain.
That simple act by Joe was extremely instrumental in my career, I think for the better. I became very interested in Erlang, but also just concurrency theory and distributed systems, and I would like to think I almost understand it now :)
He and I would exchange emails occasionally over the next few years and he seemed genuinely enthusiastic about programming, Erlang, and people using it, and despite me barely knowing the guy, I was genuinely pretty sad when he passed away in 2019.
I think about that a lot; if I hadn't sent a dumb cold email my entire life would likely be very different.
[1] Which, to be clear, would have been perfectly fine!
I can’t speak for other startups, but I applied to the most recent YC batch with my idea for making AI proactive instead of reactive, and pre-being selected I’ve published a paper on recursive self-improvement mapped to the Epoch AI data.
I contacted a professor from a university in the UK and he responded since he was working on similar work, then asked me if I wanted to meet with him. We talked for about an hour since we had overlapping results and different methods, specifically different assumptions.
I say all that to say, as a physics student getting my undergrad, simply doing independent research and speaking to experts about it enabled me to network with someone I otherwise likely wouldn’t know. For young people getting into any business, research is a great way to meet new people.
I had an argument with Steve Jobs about pie menus at the Educom conference in Washington DC, October 26 1988 -- right after he finally shipped NeXTSTEP (people had been teasing it as vaporware with "NeVRSTEP" t-shirts).
I was demonstrating the work I'd done at the UMD Human Computer Interaction Lab on a color Sun 3/60 that Sun lent me to use at their booth, which happened to be right across from the NeXT booth.
Ben Shneiderman dragged Steve Jobs over to the Sun booth, and I gave him a NeWS demo for about half an hour: HyperTIES, UniPress Emacs, pie menus, PostScript windows in arbitrary shapes — the Hubble Space Telescope in orbit, Bill Joy's head popping up when you pointed at it, that kind of thing. Jobs has RELIGION about UI, and he argued wonderfully. He also has volume. On the show floor, in a suit and tie, he was jumping up and down yelling:
"That sucks! That sucks! Wow, that's neat! That sucks!"
Not discouraged, I figured one neat to three sucks was a good score from Steve Jobs. When I explained how flexible NeWS was -- programmable PostScript in the window system, malleable windows, extensible UI, transforming all menus of all apps into pie menus, etc -- he told me:
"I don't need flexibility -- I got my window system right the first time!"
Okay, agree to disagree. Then I gave him a free NeWS "NeRD" button, which he gracefully accepted, then he departed leaving my reality intact and undistorted.
So empthought's joke isn't far from the design philosophy. NeXT was world-class software, but malleability for the user was exactly what Jobs was proud of not offering. That's a big part of why the Emacs / NeWS / PostScript / Smalltalk / Self / Oberon / JavaScript / AJAX branch of computing and the Mac / NeXT / Display PostScript / Objective C / Cocoa branch diverged.
Also, during the conference I was giving essentially the same rolling demos to anyone who walked by, and some scruffy looking dude was hanging out and watched the whole series until it looped back to Emacs, then he finally remarked "I used to use EMACS on ITS." (i.e. the original TECO version)
...I said "Wow, what was your user name? Mine was A2DEH@AI!" and he replied "WNJ".
Only then did I realize I had been giving demos to Bill Joy, the author of VI, of UniPress Emacs for NeWS, and of HyperTIES embedded graphical pop-up links demo with his own inflatable pop-up head. I didn't recognize him because he'd shaved his beard!
When I was in grad school, I had the opportunity to take a course from my adviser in which he discussed his current research and some open questions. It was a relatively accessible subject area and the questions were sometimes easy enough that we could meaningfully contribute.
On one particular Friday afternoon, he stated a conjecture that he hoped was true, and invited us to try to help him prove or disprove it. It was the sort of thing that he really wanted to be true; he liked things smooth and beautiful. I, on the other hand, hoped it was false as I like the weird and exceptional in mathematics. It was also the case that I had absolutely no command of the sort of machinery that one would use to prove such a thing, but I could certainly look for a counterexample.
I learned on Monday that he had spent the entire weekend trying and failing to prove it. I, on the other hand, had put all my energy into finding a counterexample and had one within an hour.
My single (quite small) contribution to mathematical research was a counterexample because it was all I could do. The story does illustrate that it can be helpful to have people with different tools, hopes, and motivations working on a problem, though. I was not, and will never be, even a shadow of that great mathematiciam I studied under, but on that occasion, I had reason to look in a different direction than he did.
He was not just an interesting person, but had a fantastic memory for what was in the place (though I think that was quite selective.) I came in one day looking for an aluminum plate I could use as a heatsink, but I was hoping for something with rounded edges so it wouldn't cut my car seat (for my overly-hot laptop.) He squinted for a few seconds, and then walked directly to a giant pile of random metal debris, and threw a bunch of things aside, reached in up to his shoulder, and pulled out _exactly_ the piece I needed, including chamfered edges on one side.
I am sad places like this are going away quickly. I made a map a long time ago dedicated to documenting places like The Black Hole - scraphounds are welcome to update it with interesting destinations. https://www.google.com/maps/d/u/0/edit?hl=en&mid=1Y1XmPsqClK...