verttii

9 ms·

31.
by verttii 7y ago
Typescript's inherent problem may well be that it's rules are too lax, it allows you to circumvent them conveniently. This keeps poisoning the code base piece by piece, leaving you with a false sense of trust. Maybe it's beca
32.
by verttii 7y ago
Thanks, excellent summary!
33.
by verttii 7y ago
There seems to be very little promotional stuff about the runtime for server-side. What's the story with that for Swift? I don't think many people are going to start learning Swift just to build servers with it unless the platform
34.
by verttii 7y ago
But Swift has had a more specific target platform, where it wouldn't make sense to produce excessively high level generic abstractions. Whereas a language like Haskell is happy to try some absurdly abstract concepts in the interest of
35.
by verttii 7y ago
Public sharing of REPLs for anyone even without an account is just awesome. Gitpod or anyone else that I know of doesn't offer this.
36.
by verttii 7y ago
To be fair they're not always that easily accessible on React Native either. A lot of the times they seem to break stuff in weird ways, if they work at all.
37.
by verttii 7y ago
They're inherently similar. Both highly verbose and quite object oriented. Dart is less flexible and arguably less advanced, but unlike Typescript, it's sound (as in type soundness). For a very specific target (mobile) being a bit
38.
by verttii 7y ago
For the record, here is the press release about it from the Ministry of Economic Affairs and Employment of Finland: https://tem.fi/en/article/-/asset_publisher/suomi-investoi-e... Quote from the press re
39.
by verttii 7y ago
The course was developed quite some time ago by the University of Helsinki with their funds. It's a public university like all Finnish universities, meaning it is funded by taxes. What's news here is the translation job to transla
40.
by verttii 7y ago
A lot of Finnish taxpayers' money was spent developing it. I think it's fair to criticize its shortcomings openly.
41.
by verttii 7y ago
Static types do help eliminate errors and unwanted behavior without requiring to write explicit tests to verify the same outcomes. A good static type system helps reason about the code and therefore increases productivity. On that note, why
42.
by verttii 7y ago
Interestingly, I started off with Elixir & Elm and then moved on to Haskell. Elixir & Elm both feel like DSLs with abstraction level purposefully constrained relatively low. A lot of the concepts in those languages didn't make
43.
by verttii 7y ago
Why would Haskell need to be readable by people who don't know Haskell?
44.
by verttii 7y ago
Stack uses cabal underneath though. What kind of issues are you running into? Personally I love the language but struggle with all the (necessary) stuff around it. Configs, deployment, dependency management, editor setup, lint, auto-formatt
45.
by verttii 7y ago
Servant. It takes a while to pick it up but it's well worth the effort. You end up with an automatically documented type safe API and you can even generate client functions for other languages using Swagger based on the spec. It has ex
46.
by verttii 7y ago
This is a great tutorial for getting up and running fast. I started off with Spock too but grew out of it pretty quickly. It's painful in Haskell you're learning it but feel you're not able to generate anything real for the f
47.
by verttii 7y ago
Great advice, I'll try these features out while prototyping on Haskell.
48.
by verttii 7y ago
Agreed, I switched to Flutter from React Native. Although I don't particularly like Dart lang, everything just works way better on Flutter.
49.
by verttii 7y ago
Really good stuff, is that talk uploaded anywhere?
50.
by verttii 7y ago
You could and probably should promote this to the Elixir community too. Especially the OTP parts are very relevant fundamental knowledge for any Elixir dev.
51.
by verttii 7y ago
This is so spot on. Asynchronous ports are troublesome in a lot of cases. That's why I don't usually do my apps in Elm.
52.
by verttii 7y ago
Beyond the funding, what were the most important factors there that made you feel this way?
53.
by verttii 7y ago
For example now I'm building a Servant API on Haskell. It's basically a strongly typed API that you don't need to validate with tests. You only need to test the handlers that handle business logic. In other languages with a l
54.
by verttii 7y ago
> SO MUCH worse cost/benefit than unit testing My experience is exactly the opposite. Using the type system is less effort, guides your development more and, in a way, provides more consistent guarantees than spending time on a wide
55.
by verttii 7y ago
Operators are just functions. Learning the type system is the key. You can easily check any function's type signature in the docs once you understand how the type system works.
56.
by verttii 7y ago
> it lacks a lot of features to make it useable at scale. Can you elaborate on this?
57.
by verttii 7y ago
This is an incredibly good series. Just what I've been looking for. I'm writing a Servant API myself and this really explains a lot of the fundamental concepts in plain English.
58.
by verttii 7y ago
Got it thanks, good info for me!
59.
by verttii 7y ago
CPU-heavy tasks may not be constrained as much on mutation as on the host VM architecture. The threading system purposefully prevents a thread from hogging all resources. And since you have to run every computation in a thread (process), th
60.
by verttii 7y ago
The point of lazy evaluation is to evaluate something only when you really need it. Not to auto-adjust the system performance wise. You can force eager evaluation in places where you want it evaluated sooner. Personally, I think consistency

More ›