This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (10)
- # beginners (59)
- # calva (172)
- # cider (13)
- # clj-kondo (1)
- # cljdoc (10)
- # cljs-dev (4)
- # cljsrn (65)
- # clojure (144)
- # clojure-europe (2)
- # clojure-italy (26)
- # clojure-losangeles (1)
- # clojure-nl (14)
- # clojure-spec (26)
- # clojure-uk (91)
- # clojurescript (75)
- # core-async (53)
- # cursive (11)
- # datomic (16)
- # fulcro (42)
- # graalvm (29)
- # graphql (9)
- # kaocha (3)
- # leiningen (22)
- # off-topic (26)
- # qa (1)
- # re-frame (3)
- # reagent (7)
- # reitit (10)
- # rewrite-clj (56)
- # robots (1)
- # shadow-cljs (107)
- # spacemacs (10)
- # specter (5)
- # sql (15)
- # tools-deps (39)
- # vim (11)
Does TypeScript play nice with Ramda? I’ve tried using Ramda with Flowtype but it quickly became a noisy nuisance.
@lilactown I still don't know that I buy that argument without specifics being mentioned. Clojure has a very very small dev team and community around it, yet it has achieved more then feature parity and polish in many aspects. Also, that answer is kind of side stepping my question. I'm interested in the why so that I can be aware of what specific things are missing from TypedClojure that renders it not as practical or attractive. Maybe it's a case of a thousand small details. So there's a chance you're right, it might be that each little thing just integrated better and was slightly more polished in TypeScript. But before I settle on that, I'm hoping to first eliminate the bigger major difference. But since I only toyed with core.typed and never used Typescript, I'm in no position to do that 😁😩🤤
As a slightly but still related note. I just read this: https://quickbirdstudios.com/blog/keep-87-typeclasses-kotlin/
Reading that article, all I was thinking was, oh cool Kotlin could add support for some form of typeclass. And then slowly I was realizing, man, these type issues and constraints all seem like weird accidental complexity that keeps growing, and making the logic of the code more obscure as more emphasis moves to these abstract types and their supposed safety. That's the kind of exact scenario which I feel might be entering type complexity. And I think core.typed actually suffers from that. Like wanting to achieve too much type safety can result in the overhead of figuring out how to properly design your type just no longer being worth it, as it steals precious time away from design your core logic.
@didibus Isn't TypeScript essentially a superset of JS? i.e., you can take a
.js file, rename it to
.ts and it's still valid?
Kinda like Groovy and Java -- but in the opposite direction? Rename
.groovy and it's still valid, but then you can take away type information.
Typed Clojure isn't like that tho'. You can't take a regular Clojure file and feed it to Typed Clojure and just get a "thumbs up" -- instead you get tons of errors and/or warnings and you have to annotate a lot of code to get it to shut up and accept it.
It's been a while since I last tried to do anything with Typed Clojure, but for a while we tried both Schema and Typed Clojure, going back and forth multiple times before ultimately giving up on both.
Typed Clojure definitely caught real bugs in our code -- but it also threw up a lot of false positives where we had to then wrestle the code into a form that Typed Clojure would accept (or just "give up" and mark code as "don't check this").
Ya, I think you're right on all count. But I'm wondering what's the underlying cause of that, and I think its due to core.typed having soundness as a guarantee and uncompromising tenet. While TypeScript made the trade of to go unsound so that that would not happen.
I don’t know firsthand, but it sounds like Typed Racket is a more useful/enjoyable experience. which would then indicate that Typed Clojure isn’t/wasn’t quite mature enough for real-world use
I never tried Racket or Typed Racket. I think if that's true, it could very well be. I know from typed Clojure's thesis that there was more complications with Clojure, like around typing multi-method. At least the thesis make it sounds like it. Like new type system features had to be figured out which typed Racket doesn't need. But ya, I do think usability improvement are the next step for typed Clojure. I actually think Ambroise might be working on that as part of a PhD. Not 100% sure though.
There was this blog post a while back: https://frenchy64.github.io/2018/09/20/towards-typed-clj.html
he defended his dissertation a month or so ago. the future of Typed Clojure seems pretty uncertain
Looks like there is a talk at StrangeLoop that is highly relevant to this! https://thestrangeloop.com/2019/typing-the-untyped-soundness-in-gradual-type-systems.html
the clojurians log has a really nice error screen https://clojurians-log.clojureverse.org/cljsjs/2017-01-24
I’ve seen this before - is this http-kit? Looks like Django’s exception handler. Very useful for beginners. Would be great to extract that into some reusable ring handler.
That is cool. View-source reveals it’s a Ring middleware called prone. https://github.com/magnars/prone
I saw a thing awhile back where a popular Python http module, in dev, will open up a web REPL inside the context where an error occurred
Nice post about parsing a lisp with rust, https://dev.to/deciduously/rust-your-own-lisp-50an