solicode

I've heard that too but I think there are at least efforts to support Scala 3.

Having said that I think Quill looks nicer (https://getquill.io/) if you want a DSL like that.

From a political perspective, yes for sure. From a technical perspective, less so. The Cats ecosystem and ZIO are meaningfully different with their designs that the two evolving separately isn't so bad in my opinion.

The Scalaz/Cats schism was worse in the sense that they were largely the same (at least at the time) which led to a lot of duplicated effort.

There's probably a nicer way (or more performant at least), but I created a function that uses the built-in `uuid_generate_v1mc` and then reverse the order of the time component so that high values come first.

I like ordered UUIDs, but if you care about 100% strict and accurate ordering you need to be careful about generating them in app code vs. on the DB side. With the former + using multiple app servers, server clock drift can become an issue. Which is why I still generate my ordered UUIDs on my Postgres server. It means writing some funky PL/pgSQL (or however you decide to do it... I think you can run Python too), but it gets the job done.

I wish ordered UUIDs were built-in to more DBs natively. I remember seeing UUIDv6 being proposed, but I don't know if/when that will be standardised.

Not in the standard library. Kotlin went with specific language features to achieve null safety: https://kotlinlang.org/docs/reference/null-safety.html

Personally, being able to solve problems with the abstractions you can achieve within the language over adding very specific language features to solve them appeals to me more.

Having said that, Arrow has Option: https://arrow-kt.io/docs/apidocs/arrow-core-data/arrow.core/...

F# is quite nice. I used it a long time ago for a couple of libraries when I was working in a team that mostly used C#. Fable looks really cool too.

I remember getting the feeling that C# is holding it back though. F# can't have any feature that it wants because interop in both directions seems to be a priority. If I recall correctly, that's what is holding back higher-kinded types in F#.

That, and the last time I tried F# on .NET Core things were still very rough. This was when .NET Core was still fairly new though. It might be fine now.

There is that, yeah. There was a lot of translating things from Haskell to Scala 1:1, and that didn't always work out so well. Well, actually it does mostly work on a technical level, but with heavy costs when it comes to ergonomics. The implicit imports and poor type inference was enough to cause frustration within our team.

That's why I specifically mentioned ZIO. Things improved greatly after migrating to it. It feels like it plays to Scala's strength. It infers well and we don't have a single implicit import to make it work. Well, with the 1 exception of the optional Duration syntax so that we can write "5 seconds" instead of "Duration(5, TimeUnit.SECONDS)".

I don't know the whole story. Perhaps somebody who knows can chime in. But my impression is that Android being stuck basically on pre-Java 8 at the time while Scala relying heavily on Java 8 features was one complication. Scala generating a bunch of class files for lambdas and so on with no SAM types + invokedynamic to reduce all that plus strange DEX limitations might have caused issues. Plus memory limitations like you said.

I'm not sure there are any real blockers for Scala on Android anymore. I imagine it's mostly a resource problem now. With Kotlin's momentum in that space though, I'm not sure too many people are calling for it anymore. Who knows though, maybe after Scala 3 is finally out the door priorities could shift.

I often see comparisons to Go, Kotlin, Rust, etc, and I agree that it's unlikely for Scala to have a second renaissance and have an steep upward trajectory like those languages, but is that really a death of a language? I'm actually fine with Scala narrowing its scope and focus at being really good at just a couple of things. Such as embracing its FP-side more so than its OO-side. Not to say there is no value in its OO-side (I still see some value there mostly pertaining to modules). But I just mean that not every language needs to aim to be a top 5 language. FP and advanced type systems still seems to alienate a significant percentage of programmers for various reasons. That's fine. It's not like that sentiment is going to change overnight.

Scala missed its opportunity with Android. I think you just have to concede that to Kotlin at this point and just focus on moving in a direction that is not occupied. Which is why I mention FP with a strong focus on types. There's not much competition there besides Haskell. And since Haskell for the JVM will likely never be a thing (a few have tried, but none have gained traction), Scala is still there. And with the direction Scala 3 is going and all the improvements it brings, it's actually looking quite positive. At least in my eyes.

And besides, I don't think Scala has to be a "worse Haskell" in everything that it does. I think ZIO is a good example of a great Scala library that actually resulted in something really special by embracing what Scala can do: https://zio.dev

Not too sure about the case in the article and if relates exactly, but it made me think about spaced-reptition systems. I aim for a 80-90% success rate as I've found that to be the optimal range (arrived at that after doing this for 10+ years now with varying settings).

I found other articles about this: https://eshapard.github.io/anki/target-an-80-90-percent-succ... https://vladsperspective.wordpress.com/2017/03/14/optimize-y...

While I wouldn't say it's THAT significant, there is one other advantage to fixed-width fonts that I've experienced. Due to the fact that they align vertically, sometimes they expose mistakes if you're constructing data in a table-like fashion. Or when you have a bunch of copy/pasted lines that differ only in the parameter values. Like, "Hey wait a minute... this line is 1 char wider than the previous one. Oh, whoops, I fat-fingered something there".

I wish I had more specific examples and could quantify it better, but I know I've caught quite a few errors this way.

Interesting, I assumed it was the carrier, but it might be the model. I have a Galaxy S7 which I got in Hong Kong. With this variant, I can't find the emergency alert settings anywhere. That might explain it.

I don't know either, but I got the alert through Yahoo's 防災速報 app. I'm on an MVNO, so I don't think I would have gotten the alert otherwise.

If they're limiting APM to that of human levels, I don't see it being much of an issue though. APM would just be a limited resource like any other. In fact, I sort of want to see how a strong AI would choose to spend its limited pool of actions. How different would it look compared to a pro? Maybe not much, but I'm not actually certain.

In SC1, just the act of moving a large army is a commitment and takes quite a few resources. Moving your armies under fog of war and not letting your opponent know exactly how you're set up in order to get a good angle on you is incredibly important. I want to see how much of an importance a great AI puts on that vs the other things it could be doing instead. Are the strongest AIs going to be more methodological, safer, and slow moving? Or will the best AIs try to exploit the imperfect information aspect of the game and try to lure the opponent into making a wrong decision? I feel like AIs tend to excel at the former, but the latter has been a huge component for the very best pros in SC1.

I don't follow SC2, so I don't know much of this also applies there. I just feel like SC1 isn't as mechanical as it's made out to be. There's definitely that huge initial barrier, but once passed that, the game actually feels very delicate and is about good use of resources (including mouse/keyboard actions), timing, and transitions in unit composition to catch your opponent off-balance.

Personally, I think focusing on BW would have been more interesting (as long as the APM limit still stands), but I guess SC2 is alright too. The fact that they're even doing this though makes me happy.

The reason I say BW would be especially interesting is simply because the game has remained basically unchanged balance-wise since v1.08 which came out in 2001. Despite that, the pro scene never left, and we're still seeing some shifts in the meta even today. It would be cool to see a strong AI flip the script completely for such an established and "well understood" game. Opportunities like that are kind of rare, at least when it comes to video games.

There might be better sources, but here are two that I know of:

https://facebook.github.io/react/blog/2015/10/19/reactiflux-...

http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-...

The fact that Slack has made it clear they don't intend to support large open source projects is the biggest thing in my opinion. Reactiflux was basically forced off Slack for getting too big. Other large communities like the Clojurians Slack community will likely be forced off soon in the near future too (some members of the community have begun discussing this and evaluating alternatives). The Elixir Slack community is also similar in size, and I see the same thing happening there eventually.

Yeah, I saw that. :) This is impressive. I wish I knew about this project sooner. I didn't see this project on the Clojure subreddit, so I shared it there in case others haven't seen it before either.

I see the issue you created about separating the Clojure API from the AI code. I think I'd have to do that because I'll be creating an AI from scratch.

I noticed in the thread you linked to that you mentioned Java packaging and possibilities for contributions. I might be able to help there. Let me know, or if you want to create some GitHub issues, I can take a look later and see which ones I can take.

Awesome, that would be great. Thanks!

I see you even hosted a micro tournament recently. I didn't know that was a thing. How did it go? So there's at least some interest for that it seems? If so, I think I'd like to give it a shot too in the future (it'll probably be a while before I can get to this though).

This is great, thanks! The fact that it's possible to get started in Clojure, I no longer have any excuses to not try this.

Having an interactive REPL seems like it would be helpful for iterating on micro routines (this is what I want to focus on). I see you already have some situational micro examples too.

I feel like a kid again. Can't wait to try this! Now I'm wishing I still had my StarCraft discs with me.

While I was watching some of these replays, I was thinking to myself of all the things a bot needs to keep track of and all the things it could potentially try, and it just seemed so overwhelming. There are just too many things you can try, and your resources are limited.

StarCraft is a very, very deep game. It seems like it would be very easy to waste time on paths that lead to no real gains. And that rather than using interesting AI techniques, the most important thing might in fact be the StarCraft knowledge of the author. And how good they are at distilling the game down to the parts that is going to yield the biggest returns.

Also, StarCraft has very distinct early, mid, and late stages to the game. Focusing only on the early game, and going with a single strategy eliminates a ton of complexity. If you spend all your time on getting an all-or-nothing rush perfected, you've essentially "skipped" all the sophisticated techniques some of the other authors spent their time creating for the mid and late stages. In fact, it seems like some authors did just this and were quite successful.

But even an all-or-nothing rush has a surprising amount of depth, and perfecting that would be a quite a feat. The biggest thing being micromanagement/unit control and knowing what to target first (this is actually very hard). If you don't perfect that, beating a pro doesn't seem like it would be even remotely possible.

I was a huge StarCraft BW fan, and it's the only game where I got to the point where I could sometimes hold my own against pro players. I'm tempted to try BWAPI. Creating a full bot seems like a huge amount of work that I probably don't have time for, but creating a unit control AI sounds like it would be fun. I remember there used to be micromanagement custom game maps that people used to create (basically a series of situational challenges where you have a bunch of units and you could face other human players 1v1). Doing a competition for that as well would be pretty cool I think.

Yeah, you see this in a lot of sports actually. I feel the biggest differentiator is whether there's a players union or not. The Minors appear to not have their own (I did not know this). Maybe this has to do with how much money the league generates, but I can't say because I don't know the details.

Boxing was already mentioned, but there's also MMA which is in the news right now for this very reason. If you're interested, look up the recent deal between the UFC and Reebok and how nearly all the fighters got screwed by this. Only the top players are getting taken care of, while plenty of others can't even get proper healthcare despite the fact we're talking about a combat sport here. It's unbelievable.

I imagine forming a union must be harder in individual sports rather than team sports. And with e-sports, most players' careers seem to be very short, which can't be helping matters if they ever wanted to form a union. Not much leverage for a variety of reasons.

It's good knowledge to have before going to Japan, but encountering a Japanese person who would actually be offended if you were to offer a tip would be quite rare, I think. They're well aware tipping exists in other cultures. And they don't expect you to know the Japanese way of doing things. It could be interesting to see how they react if a Japanese person were to attempt it though. :)

Also, you could say a form of tipping does exist in Japan (kokorozuke), though it's quite different than what we usually think of tipping. The biggest differences being: 1. It's sort of a way of saying, "Sorry for the trouble" rather than "rating" their service. 2. You give the "tip" beforehand rather than afterwards. And it's likely you'll have to insist that they take it.

You can see this custom in high-end ryokans for example, but even then, it's not required or anything.