Peter was more sober thinker (probably literally and figuratively). Christopher was a better speaker, probably a better author but as I get older I realise how much more correct Peter was and still is.
This could be mitigated by making the currency interface / abstract class open to extension by the user. The common currencies would be provided by the library and any additional ones could be defined by the user.
Making currencies a concrete implementation is a terrible idea. There is no benefit to it at all, except throwing OOP into something that doesn't need it. A single Money class covers all needed cases, the difference between USD and BTC is... everything. Different smallest denominations, different formats, different everything. You don't even need concrete implementations
private data class Money<T>(val name: String, val amount: Int) {
operator fun <U : T> plus(other: Money<U>): Money<T> {
return Money(name, amount + other.amount)
}
fun <U> plus(other: Money<U>, converter: (Money<U>) -> Money<T>): Money<T> {
return converter(other) + this
}
}
private object EUR
private object USD
val eur = Money<EUR>("EUR", 10)
val usd = Money<USD>("USD", 20)
usd + eur // error
This gives you entirely user defined currencies, does not pollute the global scope with unneeded currencies, allows you to plug in any conversion technique (pop off, make a network call), and fails if you try to add USD and EUR without converting one into the other.
Currencies should always be the user's responsibility to provide.
You could argue the same for timezones in a date library, yet they have them. I would think a library dedicated to money will in fact be the most up to date.
Do they ? I've never once had a library that stores Europe_Paris, or Offset_Plus_7_45, they've always been stringly typed. Do you have an example of who'd be crazy enough to maintain a wrapper around tzdb?
JetBrains’ Lincheck[0] is a good library in the Kotlin/Java world for this stuff. I especially like that it’s declarative, and also the way it outputs the linearizability results.
I‘d say its the other way around, Java is closing the gap, and I say that as a Kotlin fan. Nullability in the type system is the big remaining advantage.
Scope functions are still huge. Yes, deep let chains can certainly be considered an antipattern (sometimes I like the approach of writing them, then transforming to more imperative for readability, I think readability peaks at a mix of imperative with some shallow .let), but I miss them in any language that is not kotlin.
Variables should be the exception, not the norm. I have no patience for names that designate some fluid work in progress instead of a value.
They can be useful, but I can never remember which one of let, run, with, apply, and also I currently need. Also, I've noticed that they motivate overly "clever" code, especially but not exclusively in junior programmers.
They absolutely do come with a goldilocks problem attached, best used in moderation, and require a bit of an aesthetic to develop. But what doesn't. What appears "clever" to the reader is actually dead simple train of thought coding at write time, with many types of bugs waiting to bite in an imperative implementation simply not possible.
That's why I like writing scope-heavy and then transforming to an aesthetic middle ground between scope expression and imperative. Name stuff when you have something meaningful to say, when there's something helpful to express in a name, not when the syntax mandates a locally unique ID.
I’d put any one of extension methods, value and data classes, immutable variables, structured concurrency, and top-level functions ahead of scope functions for reasons to switch to Kotlin. But hey, if you’re switching, we’re already friends :) .
Really, top level functions? I fail to see their impact, outside of getting rid of ceremony around trivial code examples.
You missed optional and named arguments in the list, those really change cost/benefit decisions in API design. (and, unfortunately, make argument names part of the public interface, this must be the most controversial part in all of kotlin)
I singled out scope functions because all those other things feel very much like the usual set of language differences, whereas scope functions feel completely orthogonal. They could be added to every single language that has excursions and imperative elements, and they would be about the same improvement everywhere.
> 2) choose paths now that keep options open later.
Not sure about this one. I’ve seen teams that are too noncommittal in their architecture decisions because “what if [insert unlikely thing that’d not actually be the end of the world] changes?” Then the project ends up only using surface level features of their chosen tooling because people want to keep too many options open and are afraid to commit to something where it matters.
There's no good idea or pattern that some team, somewhere, can't warp to create a bad outcome.
Generally speaking there are lots of well-established best-practices, that are best in most contexts, but which fall over in other contexts. Knowing what to do where is part of the intangibleness that separates the great from the good from the competent.
So some things are good to defer. -if- this product works, we -may- need to scale, so let's choose a database, and design, that allows for multiple servers. Picking say Postgres over SQLite. Other times saying "this is just a proof of concept, do it quick in SQLite".
Is our API gonna be XML or JSON? Not sure, could go either way. Let's design so that part can be trivially replaced.
With data design especially, IMO, it's worth -planning- for success. Starting with uuid will end up fine for 99% of the tables which will have "not many records". When we identify that 1%, which are growing by millions of records a minute, we can adjust for that table as desired.
[On a side note, regarding clustering, it seems some people aren't aware that the primary key and clustered key don't have to be the same.]
I think the Jetbrains team are dropping the ball when it comes to Kotlin on the JVM. They seem to be focusing their energy on KMP, and I’m not sure they have the capacity to deal with all the platforms they want to target (Kotlin/JS, Kotlin/Native, Kotlin/JVM, KMP, Jetpack Compose (?) etc). That being said, I’d strongly encourage others to try Kotlin as a Java alternative for server-side applications (Spring Boot integration is really nice, for instance). It’s such a delight to use! And it’s still my favorite language. Some features I especially like:
- context receivers (think of them as implicit parameters that are checked at compile-time)
- null safety. This is a BIG one, especially if you’re coming from Java.
- structured concurrency. Java still doesn’t have this. Note that SC is different from what was introduced in Project Loom.
- immutable variables, data classes, value classes etc.
> Hogging instances might pay, if this stops competitors getting good hosts. This would eat into PnL and is also wasteful on energy.
Aren’t reserved instances cheaper than spot?
> Bad players could do a ping test to many thousands of EC2 instances, find those which are also at very low latency to their good boxes (assuming these are competitors), and DDoS them during trading hours to hammer the hypervisor’s NIC. This would result in critical overhead occurring for competitors sending orders out.
Leaving out the logistics of how someone could do this (why are your instances reachable from the internet?), wouldn’t you have a good case with your exchange to get them kicked out?
> wouldn’t you have a good case with your exchange to get them kicked out?
Would you know who is doing the pinging? The cloud provider would know what account was pinging, but somebody doing this as a trading tactic would have the resources to churn through aws accounts as quickly as they are banned.
I had a professor who hated Jared Diamond for being reductionist, and I’ve been skeptical of him ever since. However, I see the immense appeal of his theories (and the one linked here) because they’re so simple to understand. They make for good History Channel documentaries, and tidbits you can repeat at a cocktail party to make yourself sound smart.
Former anthropologist (through to PhD, anyhow) here. I think there is benefit in having simpler theories, because they are easier to test. There are so many limitations in getting adequate data to test historical theories anyway... I am always skeptical that what we have is a "just so" story that of course fits the data, since people knew the general shape of the data before proposing the theory.
Indeed, it's interesting to think about how rice production might have influenced the culture.
But to do so without mentioning Buddhism or Confucian thought at least in passing is weird. I assume his take would be that these philosophies were emergent from the culture of rice farming.
I don't see this kind of single factors deterministic, just that things are not perfectly random anymore, a bias is introduced, on similar circumstances the dice may have more probabilities to fall in a particular direction. At least that is how I see complex systems in general and it may apply for this.
> However, I see the immense appeal of his theories (and the one linked here) because they’re so simple to understand.
Theories like that also make excellent propaganda. Take a messy subject (like the economy), drain that away with some oversimple theory that supports your political goals, then push that onto the citizenry in books and articles, and watch the converted start to vote your way. Personally, I think that's the mechanism for how so many laborers have come to believe in rather extreme forms of free market capitalism.
I think to some people it seems fairly simple to pass Jared Diamond off as a reductionist, and I guess it appeals to people to do that in order to seem intelligent at some social affair, but I think the reality is a little more difficult to understand than him just being a reductionist.
Wow, the cocktail parties in this thread must be fantastic. A bunch of people accusing each other of intellectual groupthink, only to get accusations in return.
I don't think Diamond was a reductionist, he often considers multiple factors, as many as most academics IMO.
Did the professor have a single factor who they tried to reduce anything to (and was mad that Diamond didn't share the same favourite hobby horse), or consider multiple factors (like Diamond, but maybe with a different set of factors), was the only way to solve a problem "study it lots and trust the expert", or is the solution "not everything can be solved, sometimes Donald Trump's guess is as good as mine" (but with more fancy words I'm assuming).
To be perfectly honest, after uploading well over 1000 videos, I got a little tired of it. I still post monthly update videos, but it's been months since the last hacking video.
I'm still working on Ladybird every day, and I also manage two full time engineers now, thanks to the generous sponsorships we got from Shopify & others last year. :)
Glad to hear you're doing the right thing by yourself. I regularly go back and watch some of the mini series, or porting videos. I refer many graduate engineers to learn from your high display of clarity and pragmatism that you constantly display.
If the hacking comes back some day, I'll be delighted, but just wanted to say thanks for the fact that we have such a wonderful backlog thanks to your long term efforts.
That said, I think those videos are a significant contributor to the project success. I hope they do not go away completely.
In fact, I think the videos are as important a contribution as the project itself. I remember seeing a quote once from a musician that said he was inspired by both the Beatles and The Rolling Stones. The Beatles showed him what a band could be. The Rolling Stones made him feel like he could do it too. I see that in Linux and Serenity. Your videos make me feel like I could solve any problem by just starting it and breaking it down into smaller, more solvable chunks. They are inspiration and I am not surprised SerenityOS has attracted people to contribute other ambitious aspects. The PDF browser, the GPU stack, and the RISC ports are examples of amazing projects in their own right. I think one of the reasons we see such ambitious contributions in such a young project is the inspiration provided by your leadership and the example set in those videos.
Regardless, thank you for the contribution so far. With the recent improvements to HTMLInputElement, I was able to use Ladybird to leave a comment on the OSnews site recently and it gave me a huge thrill.
Thank you for all the videos! I particularly enjoyed the porting and profiling/optimization videos and I still occasionally rewatch them to this day. :)
Your overall pragmatism and no nonsense C++ style is something more developers should aim to replicate imho.
Add me as another vote that misses them. I totally understand you need a break and other obligations take more time, but I hope you can still find the time to do them occasionally. :)
