MarquesMa

I mainly use three different pans: 1) A carbon steel wok 2) A cast iron skillet 3) A dutch oven.

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.

This is my favorite book!

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.

A simulation of a brain cannot produce consciousness any more than a simulation of the weather can produce rain.

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.

Me: dynamic -> static

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.

[0] https://shimweasel.com/2018/08/25/novelty-budgets

The problem is there are no sane in-between options.

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.

Static Typing reduces bugs.

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.

[0] https://www.youtube.com/watch?v=z9quxZsLcfo

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.

Just think about Gitea vs GitLab.

You can't. You trade a crypto coin on the market and you have a price.

The price is hugely affected by how many people in the whole world believe it's a decent currency.

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.

I agree what you're saying, but they were talking about Python and TypeScript - it doesn't make sense to bring up type erasure in this context.

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).

What's the problem?

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.

https://news.ycombinator.com/item?id=31721961

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.

Why this can be great:

- 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)

and then scatter that all over your markup

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.

I don't think it will stop unless 1) It's illegal. 2) It's ineffective 3) It's not economical for the company. To stop the trend you have to achieve one of the three.

Similar to algorithms itself, interviewing is essentially searching for people that the company wants.

How a company interviews candidates define its effectiveness (hire the right person, less false positives, less false negatives) and cost (how much does the company spend on the interview process per hire).

Interviewing with LeetCode is acceptable effective: candidates.filter(leetCode) gives you a much smaller set of people good at algorithm brain teasers, and this set of people have acceptable approximation with the set of ideal candidates.

In other word, it's a lazy but effective enough. The majority of companies will only switch to alternatives when the cost is lower, or substantially more effective. It's broken from the candidates perspective, but not the companies'. Most companies will stick to "if it ain't broke don't fix it" unless we offer them 10x solutions - which is yet to be seen.

But I can also see it the other way around, we can undermine the effectiveness or cost for all companies: if we can develop better courses and bootcamps, letting more people hack LeetCode problems quickly. And then companies will naturally go for harder problems. In the end, the problems will be ridiculously hard that the companies can only filter people who memorizes LeetCode, and those set of people have virtually no correlation of good hires (good problem solving skills). And of course, it's also a profitable business to teach people this.

I would say it would be great to merge with TypeScript.

It would greatly reduce the need of those crazy building tools nowadays. Now we have HTTP2, if only we can write and serve a bunch of TypeScript files directly. Be it browser, Node.js or Deno, you could use the same script file without setting up M*N different webpack.whatever.config.js files.

And it will also open up the possibility of optional runtime type checking which JavaScript as a glue language really needs.

TypeScript has been very cautious about adding non-JavaScript features, and kept its promise on JavaScript compatible, so I don't see big problems merging them. It's just people will need to figure out a spec to formalize the type system for TypeScript.

The only risk is there might be clash of the communities. But it also might get us great results where the whole community working on a great project together.

I'm very intrigued for the CRDT approach. I always want to try CRDT but always end up giving up local-first for simpler approaches, because I can't convince myself fully since there's a risk of accumulating CRDTs data structures too large.

Really looking forward to see your success, it might move the industry forward and bring better apps for the users.

BTW the app is fantastic!

Crusader Kings + Mount and Blade

One is focused on strategic and the narration, and the other has better in-person tactic battle.

Both of them are serious time-consumer, and I experience most flow states with these two games. Combining them organically would result a huge time-consumer that can be played all year without getting bored.

(There are mods that bolt them together but feels not seamless and coherent)

I'm a fan of "The Little X" series so I bought this one when it just came out.

I believe the author did tried their best and a great job they did - which made me work through half of the book (which is a lot for me, and for this topic). However, I did gave up eventually and decide to revisit it in the long future.

My guess is people should discuss more about dependent types - I remember functional programming concepts were also hard for me as well. But after being exposed to those conversations for a while (functional programming was one of the hot topic a dacade ago), I find those concepts were not that hard to understand, they're just different from C-like's perspective.

leetcode is fairly rare

Most of the interviewers don't even know to solve those leetcode problems in an optimal way with Clojure.

It might vary if the programming language is not functional.