It is exhausting, but it can be fun. My motivation was to network during conferences. I ended up meeting interesting people, having good conversations, and enjoying myself more.
If you're genuinely an introvert, the alternative is you "hide at home" and have fun doing so. And socialize infrequently with few very close friends (basically, quality over quantity).
I'm pretty good at socializing when I need to. I'll still most likely be wishing throughout that I was out eating dinner or having a beer at a brewery by myself with a good book or HN on my eInk tablet. Being by myself is extremely restorative and makes me happy.
I think this is what having an introverted personality is like.
The difference is between gaining a skill vs loving what you do. Introverted person practice socializing is more of a skill development than actually loving every moment of it. True introverts are happy being alone (they are not lonely as in a negative sense).
I think it is easier for introvertes to gain extrovertion skill (clear benefits) than extroverts to gain introversion skills (benefits of being alone is not that obvious)
Pigs were domesticated (specifically for their meat) for several thousand years already by the time the earliest Jewish dietary restrictions took shape.
There are many theories that try to tie it specifically to the conditions in the Middle East, but none that I'm aware of are particularly convincing.
People do realize that, which is why such frameworks have first appeared decades ago. It's just that you can't fully paper over the network gap and pretend that it doesn't exist; eventually, the abstraction leaks.
Have they? I assume you are talking about PHP, which is not that kind of framework, because you would still have to write JavaScript. It lacks type safety too.
Wow, I had no idea that existed. It looks like it is a Java library that abstracts over the web, and generates JavaScript under the hood? I never touched GWT, but it does sound like there would be issues if you wanted to do something that's not supported by the framework. But still, I don't think this is the same as modern full stack frameworks.
If I remember correctly, it was the first whatever-to-JS transpiler. But it opened the floodgates and "do everything in one language, bridge the gap transparently" has been tried several times since then.
And even before that, actually! Before web apps were even a thing, we had DCOM and CORBA and some other similar but less-known frameworks that tried to make OOP in general network-transparent. It worked in principle - you could have distributed object graphs in pretty much arbitrary configurations, going back and forth as needed to capture the semantics. It failed in practice because every time you have a network gap you get a slew of potential issues that just don't exist without it (simply put, your connection and/or the other party may suddenly go away).
FWIW I'm not saying that single-language specifically is a bad idea. It's specifically the notion that you can treat a distributed app as a monolithic thing without clearly marked internal boundaries where the network gap is, that fails in real world. But if you expose the gap then you still need to deal with impedance mismatch - e.g. nice your object oriented API no longer works because the object graph can't span the gap, so you need a more procedural (read: REST-style) API with serialization etc.
So, this is the point where you basically want a language designed from grounds up with message passing in mind. Blazor, but for something like Erlang or Elixir, perhaps?
And it's not an either-or. For example, I found that a quick way to get a web frontend for a console app is to prompt it to turn that into a CGI app. But said CGI app can still serve HTML with fancy JS and what not, and use modern frameworks for that if desired.
> That sounds reasonable to me. AI is best at generating super basic and common code
I'm currently using AI (Claude Code) to write a new Lojban parser in Haskell from scratch, which is hardly something "super basic and common". It works pretty well in practice, so I don't think that assertion is valid anymore. There are certainly differences between different tasks in terms of what works better with coding agents, but it's not as simple as "super basic".
I'm sure there is plenty of language parsers written in Haskell in the training data. Regardless, the question isn't if LLMs can generate code (they clearly can), it's if agentic workflows are superior to writing code by hand.
There's no shortage of parsers in Haskell, but parsing a human language is very different from parsing a programming language. The grammar is much, much more complex, and this means that e.g. simple approaches that adequate error messages don't really work here because failures are non-actionable.
> At that point, the argument over whether they're crap or not is done.
Not really, it just transforms into a question of how many of those jobs are meaningful anyway, or more precisely, how much output from them is meaningful.
I don't agree. I've recently started using claude more than dabbling and I'm getting good use out of it.
Not every task will be suitable at the moment, but many are. Give claude lots of direction (I've been creating instructions.txt files) and iterate on those. Ask claude to generate a plan and write it out to a file. Read the file, correct what needs correcting, then get it to implement. It works pretty well, you'll probably be surprised. I'm still doing a lot of thought work, but claude is writing a lot of the actual code.
They all let you do that now, including Claude Code itself. You can choose between pay per token and subscription.
Which means that a sensible way to go about those things is to start with a $20 subscription to get access to the best models, and then look at your extra per-token expenses and whether they justify that $200 monthly.
reply