MarquesMa
Joined 4 years ago
Joined 4 years ago
But I think it could be more straight forward if the first interpreter didn't use Java, but a modern main stream language that can avoid code generation and Visitor Pattern. Those parts feels like unnecessary detour.
It is forced upon us doesn't mean it can't be universal. On the contrary, it usually is. It's like how USD is kinda forced around the world but it's universal nonetheless.
No, it cannot make me write code I couldn't write before. It does not autopilot and does all the coding by itself. But it still boosts my productivity greatly, making me relaxed while coding and focusing on the important part rather than errands.
What's wrong with the rain though? A perfect simulation of rain is perfect rain. It's not rain in the outside world but it's perfect rain nonetheless.
A perfect simulation of brain is a brain. It has consciousness, it can think, it can suffer, and you can exchange information with it if you want.
What did I feel during the transition: Feel like an insulted because of the under-expressiveness. Everyday I find some ideas that are natural to me and non-tech people couldn't be codified directly.
Although statically typed languages are getting better each year, I still think there's a trade-off among three camps:
1. Dynamic (Ruby, JavaScript)
2. Under-expressive static (Java, C#)
3. Expressive static (Scala, TypeScript)
I worked on a full-stack project and people have different backgrounds and have to switch from time to time, here's my impression:
- Most "underexpressive-static -> dynamic" people hate dynamic programming, because they mostly lose typing for nothing - they usually don't leverage the expressiveness because that is how they were coding all along.
- Some "dynamic -> underexpressive-static" people liked the discipline, while some hated the under-expressiveness, it depends.
- The "Expressive static" was the new thing. Everybody need to learn some part. Usually, there's a learning curve, some people like the challenge while some people hate it. That also depends on how steep the curve is (TypeScript is very smooth but not Scala).
Even though I think it's still trade-off, I can see the balance is shifting toward the "expressive static" camp:
- People get more familiar when they're exposed to the concepts. Higher-order functions like map/filter/reduce were considered exotic in the 90s, but now they're everywhere. Monadic-like programming like Promise or Optional is also popularized, they're not hard at all once "everybody else" learned that. Advanced type systems are no different.
- Language creators have more experience in choosing trade-offs that makes sense. Scala was getting a bad rap during its day, but Kotlin didn't. In other words, the creators are getting better at spending their "novelty budgets"[0] to yield optimal results.
P.S. I still couldn't wrap my head that Dart spent NO "novelty budget" whatsoever... They have zero chance against TypeScript if there was no Flutter or other Google platforms that use Dart.
On one end of the spectrum are either neat platforms like Heroku or Vercel or ssh and bear-metal with simple scripts.
On the other end of the spectrum, we have Kubernetes.
Everything in between:
- The learning curve is much steeper than Heroku and Vercel
- The skill is not likely to transfer to the next job
- The ecosystem is not as complete as Kubernetes
Most mid-sized companies went for Kubernetes because the in-betweens are not very optimal and need to take some risks on betting them.
This matches my experience. People say otherwise might need to put more effort on writing better tests.
That said static typing usually catch minor problems like typo faster. But for dynamic typing it's going to catch by tests a bit later. But usually tests run faster with dynamic languages, so it's a tradeoff.
My favorite approach is the mixed approach like TypeScript:
1. Faster feedback loops: Usually statically typed languages compiles slower thus slower feedback loops. But languages like TypeScript can skip type check and emit only to the runtime, making test watcher very fast - as soon as I hitting Cmd-S I can see the result.
2. Optional typing: Sometimes a function signature is going to be 10x larger than the body, which is really a hassle. Sometimes I just skip them, or skip typing module private functions as long as it's properly tested.
The idea is not far from the stoic ones - try your best and stop worrying. It's like an idea from this classic debate on TDD [0]: Unit tests make you confident. You write it, you forget it. It makes you sleep at night.
In my first few years of my career, I was constantly and unconsciously thinking about the code, the business requirement, the team, even outside the working hours. That stressed and drained me a lot. In the end I realized I shouldn't have done that. If I am to worry about those things, I just book myself a calendar and go over those things within the time-box. If I need more time, I book another time block for the next day - as simple as that.
Now write that "unit test", forget it, and sleep well at night.
If you really need to worry about them, you should have a "quarterly/monthly worrying day" to reflect about your life, your career, strategies and all that. Outside that day, you just live your happy life.
Just think about Gitea vs GitLab.
The price is hugely affected by how many people in the whole world believe it's a decent currency.
Parents nowadays blame screens for short-sightedness, but the truth is back then my classmates are almost all doing reading and writing all the time, and nobody was using screens (Symbian Nokia only took off years later).
It's only me and the other two boys who spend all the time and money on online video games - the other two guys were almost score zero in every single exam.
Java strips type info and runs it as JVM byte codes. There's no native Java runtime, AFAIK(it doesn't enforce types at runtime, only at build time).
What's the problem?
But my point is people seem to assume sentience is a byproduct of high level intelligence, which might not be true. Maybe we need to focus more on "what is sentient", "what makes a sentient thing sentient" first and discover the basic elements of sentience.
If we can formally define sentience, or reverse-engineering sentience, or build a "MVP" or "bare-minimal" sentience. Thing would be much easier discuss.
Here are some random thoughts: Self-awareness might be a consequence of evolution - it might be more optimal to grow self-awareness than other perks to survive. Just like occasionally using reflection in programming could solve hard problems elegantly. Sentience and emotions might also be consequences of evolution - they can be seen as efficient and power tools to communicate, people can efficiently affect a lot of people with their emotion, without conveying rationally by words.
Here's a random idea: Build a complex simulation game, but with relatively simple creations with some evolving capability. If we try to manipulate the environment enough to let self-awareness and emotions to be optimal solution.
The wok is very versatile. I use it for most things by default.
The skillet is great for pan frying.
The dutch oven is great for braising without me stirring it too often.
Cast iron is situational because it has large heat opacity: you can think of it as a pizza stone for pan frying.
The advantage is you can compensate by long preheating if your stove is inferior.
The disadvantage is it's slow to respond: When you turn to high it delays a while, when you want to lower the temperature you still need to wait.