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.
> You want to sell Javascript based solutions, go for it. But don’t push this nonsense like “No language like Javascript”. The only reason Javascript has a wider adoption than others is that it’s forced upon us.
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.
Thank you, GitHub, this is one of the best things!
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 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.
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.
It says that "Nintendo" or "任天堂" the brand name refers to an old Chinese saying "謀事在人，成事在天" which means "Man proposes, God disposes", or "do your best and leave it to the fate".
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.
This. I find open source projects written in Go or Rust are usually more pleasant to work with than Java, Django or Rails, etc. They have less clunky dependencies, are less resource-hungry, and can ship with single executables which make people's life much easier.
Anecdote: I live in Asia, and when I was in middle school, AFAIR there were only 3 people (out of 40-ish) don't wear glasses including me.
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.
> It strips type info and runs it as Javascript, though. There's no native typescript runtime, AFAIK (it doesn't enforce types at runtime, only at build time)
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).
There are some discussions in this thread [0] that believe that cows and pigs are sentient.
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.
I'm still struggling with the question "what is sentience".
Are insects sentient?
If so, could we build less intelligent but sentient AI, on par with insects?
If so, is it unethical to torture such intelligence for fun in simulations?
If we can define or create something as "minimal sentient", the following discussion on ethics would be more clear - since now people are talking past each other with completely different understandings.
- The dev experience is closer to the early days of PHP.
- TypeScript, Preact out of the box. No need to configure build tools / deploys much faster. It's a pain in the ass to make these working at the same time and targeting both browser and server nowadays.
- You can have interactivity without bolt-on client-side scripts that are different from other parts.
- The code could be running on the edges.
- I'm not sure what does the island based client hydration means, but sounds like Remix
Many other frameworks could do some of them but not all (Ruby needs JavaScript/Turbolink, Next.js need to build then refresh, etc)
This is not how you use Tailwind. Back then there was no such concept as component, so people need to write CSS classes to encapsulate and reuse styles.
Now Components are everywhere, and when you write components and CSS classes at the same time, you're non-obviously duplicating structures (Write components, then write classes corresponding that component).
In essence, Tailwind (or styled components and such) makes component mechanic as your single source of abstraction.
It's hard to distribute content from your own platform. Most successful content creators are relying on many platforms, it's virtually impossible to fight them.
But it's always to have a small resort of yours on the internet. It doesn't have to be big and great, and it can be as simple as a business card that points to your footprints on every other platform.
For example, many Russian content creators are losing their audience immediately after they're sanctioned. It's always a good thing when people search your name, your own site appears on the first page.
You're right. But I also said in the following paragraphs which means the same thing:
> Most companies will stick to "if it ain't broke don't fix it" unless we offer them 10x solutions
It should also work if people undermine 1x solution to 0.1x solution. If there are a lot of bad hires at the company level, which they can't finish ordinary tasks other than LeetCode problems and keep screwing things - the team leads and managers will start to complain and eventually propagate to the top level.
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.