Interestingly, I feel like this comparison to an IC and input(s) -> output(s) is more akin to functional approaches, and many people complain about OOP being the opposite.
To quote Joe Armstrong:
> I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.
Heck, many mixed-signal ICs are much harder to use correctly than a typical object; Things like "Vdd must be brought up to +6V or higher before CLK begins toggling" are not too uncommon to see.
FP comes with the same jungle, especially if you consider that when most people talk about FP, they're allowing for closures. Even if you don't, though, and you do only have pure functions, it's a similar bog.
Consider a function f that itself relies on being able to call function g. In FP, you have to either bind by name, which introduces coupling on par with OO ("the jungle"), or you make it parametric, so f doesn't know anything about g per se, but somebody does―perhaps f's caller, or its caller, etc. OO is parametric, too, but in that case they live as slots on the objects, rather than being passed as arguments.
People can try to squidge this end of the problem and find that it shquoshes up on the other side, or vice versa. There's no real escape from the problem of dealing with state.
Probably the real silver bullet boost to productivity will come when we adapt program execution environments to our dumb brains by way of VR. Think of something like a cellular automaton such as von Neumann's universal constructor:
... only in 3 dimensions. When we want to debug a program, we project it into a 3-dimensional space, and we trace its execution the way you can look at something progressing through the assembly line on a shop floor, with pieces that you can reach out and touch, and even pick them up and mark some with blue dots and some without, etc. That looks a lot more like OO than FP.
I was a senior engineer at a startup that evolved into this space – basically, we started as a browser for kids and slowly started adding more "social" features. I thought I'd add a few notes in case you (or someone else) goes down this road:
- Monetization is hard. As much as parents vocally _desire_ a safe space for their kids online, it doesn't translate to their wallet. If you end up going for more indirect revenue (ads, branded experience, etc), you'll find yourself in ethical gray areas quickly.
- Read up heavily on COPPA. It is by no means insurmountable, but it adds more work and restricts what you can/can't do.
- Social interaction needs to either be severely limited or heavily moderated, both of which have serious problems. You can't just throw a kid into peer-to-peer chat rooms or private chat for obvious reasons. Likewise, a kid gets bored quickly with a pre-determined set of "emotes" or canned text. Finding a balance between the two is very difficult.
- Parents care less than they think they do. Every parent, from casual conversation to focus groups, will light up at the idea of a kid-safe internet/social network. However, we found parent engagement to severely drop after initial sign up, despite how active the kid might be. We did weekly reports on kid activity and interests, ways to share content and engage with your kid, etc – all of which was rarely used.
Granted, it's quite possible (probable) that we missed the mark, and that we just didn't have the right timing/vision/execution, but there was enough friction that I came out the other end with a strong bias against working in the kids' space again.
If your product depends on parent supervision, it's not going to work. As a parent, the last thing I want to do is spend more time looking after my kids!
If you work on a kid product, make sure that kids can use it on their own, without supervision.
It's not so much parent supervision but just parent buy-in. If you're a game, no problem, you just need to appeal to the kid. If you're trying to be a safe portal to the wider internet, you probably need parents onboard.
What's the benefit/reasoning here for another distro? I just want rock-solid hardware with strong Linux compatibility. It seems like the man-hours would be better spent contributing to drivers to ensure stability and accessibility across all Linux distributions.
Did this not work for Android? I seem to recall that every Android phone manufacturer shipped their own customized Android with different home screens, navigation, widgets, apps, etc. Did not stop consumers from buying the phones. Even today the number of Android phones released with stock Android each year is laughably low.
Depends. Do you ever have to look down at the keyboard? If so, then you really should learn to touch type. If you can fluently type without ever looking down, it would probably be a low return on the investment. The only caveat would be RSI-related issues, but I'm really not qualified to opine there.
IANAL but my understanding is that patents cover the implementation not the idea. If you aren't capable of practicing (yielding the product), you probably shouldn't be holding/filing a patent.
Let's say you invent a doodad in your garage. You have the implementation, you have a working device, but you don't (yet) have a product you can sell. You are unlikely to be setup to manufacturer this, so you'll you need to find a partner to produce that doodad. Patents protect you during this process, so that a manufacturer can't just go "oh cool we'll not pay you and instead just go do this under our house brand without you"
At least that's the theory. The reality is it's increasingly unlikely you'll be able to invent anything physical by yourself in a garage anymore in the first place and things like software have no barrier to mass distribution like physical goods do.
Loved using nvAlt. I need to get back to playing with my cross-platform version of nvAlt in Qt. I got as far as getting a search as you type with minimal file create/load/save going and then trailed off to work on other things.
To quote Joe Armstrong:
> I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.