> You can't take a Cat from one program and a Dog from another program and have the dog interact with the cat. This is obvious in software - that's why we design APIs - but it's frustrating when all your programs exist in the same space
I also thought this, but learned that what I needed was an Alan Kay style "change of perspective".
The key for me was understanding the "wish" and "claim" concepts in Realtalk. In your example above, you would need to separate your "Dog" program into two programs: One that was simply a program claiming "I am a dog" and another that would encode dog behavior, something like "I wish that a bark sound would play when a dog is near a house" - then you'd leave it up to Realtalk to make that happen. Adding "Cat" behavior would mean adding two new programs: one to claim "I am a cat" and another "I wish that a meow sound would play when a cat is near a house". To make the "Dog" and "Cat" interact, you'd add a program that said "I wish that a growl sound would play when a dog is near a cat" and so on.
Another example that might help is how I learned this myself: I made a set of playing cards. What I ended up with was 52 pieces of card stock, each one had a program that was simply "Claim that I am card X" - and then I made separate programs the give those cards meaning. For example a program to give the cards a style would be something like "I wish that card 1 will have the Ace of Spaces printed on it, etc" and another program would be something like "I wish that the sum of all face values of the cards on this line is printed next to the line"
It took me several days to internalize this, but once I did things started getting fun pretty quickly. For example, I was able to make a program to "clone" a real world image onto a playing card by having Realtalk take a picture of a rectangle and then always project that image onto a particular card when it was face up. Because the cards just made claims about their identities, this let me separate the designs on the cards from the rules as well as add "training mode" programs to help teach basics. And they were all decoupled!
From the article: "It's true that networking can help you accomplish great things. But this obscures the opposite truth: Accomplishing great things help you develop a network."
This is something that I wished I had understood way earlier in my career. Basically that cause and effect are often inverted when people talk about the network effect. People who do some thing well, or are passionate about, often will accumulate a network of others who are interested in that same thing. And because they know a bunch of people who are also interested in that thing, when they hit a roadblock or a problem they have people they can reach out to for help or insights.
What is hard is discovery which is to say that the greatest programmer in the world who sits in his shack and writes perfect code that is beautiful and functional, is invisible.
There is a joke about the guy who complains "I make no money at all from stocks." and the friend says "What stocks do you own?" and the complainer responds "Oh I don't own any stocks, have no use for them, I just want money from them."
Attention and focus is like 'money from stocks' if you share what you're doing and your understanding with people you give them some advantage and perhaps some new understanding. That advantage comes back in the form of referrals or opportunities that you were not present to see when the person you shared with recognizes an opportunity as something you would be interested in. It also allows you to be "discovered" two or three hops down the road when someone says "Oh I know someone who is interested in that ..."
> I'd have a hard time implementing my own crypto,
Yes. Or, it's actually rather easy - but it's extremely hard to do well. That's why one shouldn't do it (or, you should, but perhaps for toying with and not for production). See, you obviously know enough about the topic to know this! This is exactly one of those nuggets of "broad knowledge" you need as a software developer. How much do you know about crypto:
- You need to know when to hash ansd when to encrypt.
- You need to know the properties perhaps of symmetric/asymmetric crypto and key exchange
- You must know that you never implement any of these algorithms yourself, you only choose from them.
That's about it. You need to know what you don't know (how to write reliable crypto) in this case.
> If you have a poor understanding of how indexing works, you'll probably have a hard time selecting the right data model.
Right. Basically understanding a database is around the amount you need to implement a toy database. You know the difference between an index lookup and a scan and so on. Lacking that understanding means the database is some oracle (haha) you feed SQL and it spits out data. If you do know a bit more you might have a vague idea about how data sits on pages that are oriented into a btree. You might know that how the disk tree is magically updated in both ends to be consistent even if power is switched off mid-write and so on (I don't know, this really isn't my area - I have coded 13 years without a db). You didn't invent or even deeply understand any of these algorithms to the point where you could write them on a whiteboard. But it does help you if someone asks "what happens to users' bookings if I cut the power?" or "will it be faster to join in the DB or later in the language".
Another pet peeve of mine is people who can't identify NP /exponential problems. It happens several times per year that junior colleagues of mine develop solutions that are exponential in time/space, because that's what the problem is.
Them: "Look, I optimized the order in which we pick the X from
the list"
Me: "That will take the remaining life of the universe already with 30 items!"
> Science fiction almost universally assumes the speed of light is not a hard limit.
Not at all, you need to look at other sub-genres. The social, economic and military structures that form around slower than light travel are a mainstay of hard science fiction. "A Deepness in the Sky" is a great example. So is the first half of "Neptune's Brood" or the second half of "Accelerando". Any story that uses a generation ship as the setting, like "Hull Zero Three", also assumes sub-light travel. Or what would happen if present-day society discovered an alien race next door, like in "The Sparrow". Or maybe we need to make ourselves slightly less human to survive sub-light space travel. "Blindsight" and "Echopraxia" explore the philospohical ramifications of that. Even "Ender's Game" doesn't have FTL travel.
Now space opera almost universally assumes that FTL is possible. Though there are exceptions, Ian Banks "The Algebraist" is my favorite sub-light space opera.
edit: Some hard sci-fi will still use wormholes, either as a normal thing or a macguffin. FTL communication is also common. Though FTL comms are getting less common in modern hard sci fi. Us readers like this and it makes for convenient plot devices as comm lag leads to misunderstandings.
TV and movies are almost always space opera, with "The Expanse" being the only sub-light TV production that comes to mind, and "2001" for film. But I don't know as much about film as books.
I also thought this, but learned that what I needed was an Alan Kay style "change of perspective".
The key for me was understanding the "wish" and "claim" concepts in Realtalk. In your example above, you would need to separate your "Dog" program into two programs: One that was simply a program claiming "I am a dog" and another that would encode dog behavior, something like "I wish that a bark sound would play when a dog is near a house" - then you'd leave it up to Realtalk to make that happen. Adding "Cat" behavior would mean adding two new programs: one to claim "I am a cat" and another "I wish that a meow sound would play when a cat is near a house". To make the "Dog" and "Cat" interact, you'd add a program that said "I wish that a growl sound would play when a dog is near a cat" and so on.
Another example that might help is how I learned this myself: I made a set of playing cards. What I ended up with was 52 pieces of card stock, each one had a program that was simply "Claim that I am card X" - and then I made separate programs the give those cards meaning. For example a program to give the cards a style would be something like "I wish that card 1 will have the Ace of Spaces printed on it, etc" and another program would be something like "I wish that the sum of all face values of the cards on this line is printed next to the line"
It took me several days to internalize this, but once I did things started getting fun pretty quickly. For example, I was able to make a program to "clone" a real world image onto a playing card by having Realtalk take a picture of a rectangle and then always project that image onto a particular card when it was face up. Because the cards just made claims about their identities, this let me separate the designs on the cards from the rules as well as add "training mode" programs to help teach basics. And they were all decoupled!