And of course the reason that there is a lot VC capital in Europe has absolutely nothing to do with the fact that you'd be crazy to do a startup in e.g. Denmark (because doing so will likely be personally ruinous even in the unlikely case that you get some traction, due to unrealized gains tax) or to directly invest in one in e.g. Germany (where you'd be expected to physically sit through, on location, a few hours of a notary reading stuff out to you)? Do you actually have any idea how much additional legal risks, costs and time wasting bureaucracy are associated with even just forming a company in a typical EU country?
Miami, and Florida in general, have basically zero universities anyone has ever heard off, and still boast a higher number of unicorns per capita than Germany, despite the latter having at least one world-class technical university.
Europeans are aware of this but they do not want to engage in a race to the bottom. Socialism was a conscious political decision in response to the oligarchy.
It is incomprehensible to Americans but not everyone wants to be like them. It would actually be a capitulation.
The policies I mentioned (just as nepo-baby Mamdani's programs to abolish programs for gifted children) have, of course, precisely and deliberately the effect of cementing an existing parasitic elite and screwing over talented and hardworking people from a non-privileged background.
Which part of this do you fail to understand? Who do you think will be more inconvenienced by the removal of gifted programs, some intellectual mediocrity who goes to a $70'000/year private school anyway, or a smart child from a family with a yearly total income that's a fraction of that schooling cost? Who do you think is going to be more likely to find themselves financially ruined by being hit with enormous taxes on illiquid assets (such as equity in a pre-IPO startup they founded or where an early employee in) -- someone entirely self-made or your "oligarch"?
Is there some more concise and ideally written summary of Thiel's lectures? One that doesn't require sitting through 3h of video?
I've only got some superficial acquaintance with Thiel's ideas, but he's been objectively correct on enough contrarian stuff (Thiel fellowships) that I'd like to at least have some rough, non-distorted understanding of what the anti-christ stuff is about even if it sounds a bit crazy.
Nordic countries have essentially exactly the same 1/3 two year recidivism rate as the US, the one exception being Norway at 1/5, and mostly not for rehabilitation policy reasons.
My memory is that ES6's template strings preceded f-strings. If that is correct, do you happen to know why python was saddled with f-strings, which seem like an obviously inferior design, in the first place? We are now at five largely redundant string interpolation systems (%, .format, string.Template, f-string, t-string).
PEP 501 when originally written (not by me) was intended to be the competing standard against f-strings, and to have been more inline with ES6's template strings. There was debate between the more simple f-string PEP (PEP 498) and PEP 501. Ultimately, it was decided to go with f-strings as a less confusing, more approachable version (and also easier to implement) and to "defer" PEP 501 to "see what happens". Since then, the python internal have also changed, allowing t-strings to be even easier to implement (See PEP 701). We have seen what happens, and now its introduced. f-strings and t-strings are not competing systems. They are different. Similar to ES6 templates and namedTaggedTemplates, they are used for different things while API feels similar intentionally.
f-strings are not inferior to t-strings, they are better for most use cases of string templating where what you really want, is just a string.
> they are better for most use cases of string templating where what you really want, is just a string.
I think use cases where you want to unconditionally bash a string together are rare. I'd bet that in > 80% of cases the "just a string" really is just a terrible representation for what really is either some tree (html, sql, python, ...) structure or at least requires lazy processing (logging, where you only want to pay for the expensive string formatting and generation if you run at the log level or higher that the relevant logging line is meant to operate).
If the "just a string" is html, sql, python, etc., the programmer is making a mistake as string interpolation shouldn't be used for those things in the first place, and I really hope < 80% cases of "just a string" are among those.
"just a string" where the string really is just a string is really, really common though. Python is the go-to language for a lot of people (including me) if they just want to bash together a one-time-use script that will never see input from other people, and f-strings are incredibly useful in such cases for generating filenames, debugging messages, etc.
I'm not familiar with ES6 template strings, but why are they better than f-strings? F-strings just work, and work well, in my experience so I'm wondering what I'm missing out on. Especially since the language I use the most is c++... So I guess I don't expect much out of string manipulation lol.
ES2015 template strings from the beginning supported "tagged template literals" where the tag is a function that gets the template itself and the objects passed to the "holes" in the template as separate arguments. From there that function can do things like turn the holes themselves into something like SQL Parameter syntax and wrap the things that go in those holes in properly escaped SQL Parameters.
`some template {someVar}` was f-strings and someFunction`some template {someVar}` was more like what these t-strings provide to Python. t-strings return an object (called Template) with the template and the things that go into the "holes", versus tagged templates are a function calling pattern, but t-strings are still basically the other, richer half of ES2015+ template strings.
The problem with f-strings is that they make an extremely limited use case convenient (bashing unstructured text) and thus people people invariably use them for the less limited use case for which no such covenient mechanism exists. Constructing ASTs (including html and SQL). Or logging (where you want to avoid unconditionally computing some expensive string represenation).
I do this myself. I basically always use the subtl wrong log.warning(f"Unexpected {response=} encountered") and not the correct, and depending on the loglevel cheaper log.warning("Unexpected respone=%s encountered", repsonse). The extra visual noise is typically not worth the extra correctness and performance (I'd obviously not do this in some publically exposed service receiving untrusted inputs).
I'd argue these use cases are in fact more prevalent then the bashing unstructured text use case.
Encouraging people to write injection vulnerabilities or performance and correcness bugs isn't great language design.
Dylan is simply a historical curio, so there are no situations in which anyone should use it apart to study programming language history and to take inspiration from roads not taken. It's basically Common Lisp, with Algol-like syntax, less historical baggage (everything is a class, no weird stuff like prog and so and so forth) and more emphasis on efficient implementation. Unfortunately, it didn't catch on, but it's IMO a nicer language than python (which modelled inheritance rules on Dylan), Java, Javascript or C++.
Here are some interesting things about it:
1. It has an simple but nice trick for avoiding ugly_underscores: a-b is a single symbol, a - b is subtraction.
2. IIRC it was the first non-sexp language with a sophisticated macro system.
3. Like Common Lisp it has multi-methods and resumable exceptions (but unlikely Common Lisp all exceptions are resumable). If you want to play around with either multi methods and resumable exceptions, Common Lisp or Dylan are probably your best bets and Dylan has the advantage of being probably simpler to pick up.
Great point – I should definitely have mentioned Julia as your best bet for playing around with multi-methods. I think it's basically the only language with any eco-system to speak of that has them. Julia also happens to be the only extant language I'm aware of that has a well designed shell interpolation syntax. For resumable exceptions, however, playing around with Dylan or CL remains your best bet, as far as I'm aware of (and Common Lisp at least also integrates them into the interactive development experience).
When you are prepared to die in a plane crash because of your decrepitude, how much risk to others is entailed in a case like this? If the plausible answer is “not that much” I am with you. But nonagenarian self-actualization at the cost of other people’s lives and limbs is a different story.
Personally, I think the butterfly keyboard is great. Assuming, of course, that you got one that does not suffer mechanical reliability issues. This opinion is hardly universal but seems to be shared by quite a few good typists. I'm typing this on a fancy mechanical keyboard, because I care quite a bit about keyboard quality (and consequently hate most laptop keyboards). So it's not that I just don't know better.
Miami, and Florida in general, have basically zero universities anyone has ever heard off, and still boast a higher number of unicorns per capita than Germany, despite the latter having at least one world-class technical university.
reply