This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # babashka (9)
- # bangalore-clj (4)
- # beginners (20)
- # calva (5)
- # cider (1)
- # clara (2)
- # clojure (12)
- # clojure-italy (2)
- # clojure-spec (11)
- # clojure-uk (4)
- # clojurescript (34)
- # clojutre (7)
- # code-reviews (5)
- # cursive (3)
- # datascript (7)
- # fulcro (7)
- # graalvm (8)
- # jackdaw (1)
- # malli (1)
- # nrepl (4)
- # off-topic (225)
- # reagent (23)
- # reitit (14)
- # remote-jobs (1)
- # ring-swagger (1)
- # shadow-cljs (19)
- # tools-deps (10)
2600 is releasing a digital version (!) https://store.2600.com/products/new-issue?variant=30308928487479
Hello! Out of curiosity, is there anyone reading this message who has decent experience in an language with an advanced type system (e.g. Haskell) and yet find themselves preferring the untyped nature of Clojure for most (or for some specific) tasks?
then simple stuff with the typesystem like "declare fields and optionality" starts to become a dev time burden and imo outweighs the "safety" benefits
if you attempt some kind of abstraction with rust and it doesn't work out then you might be stuck doing a refactor to ensure memory safety/etc
which is perfectly fine, at least for rust, and doing refactors in advanced typesystems kind of languages are as painless as is possible
but a dynamic language lets you take on that tech debt of accessing a "private" field or writing something that dispatches on a class and some string together, etc
scala in particular kinda stinks at doing that kind of stuff without brandishing a phd and the sword of artorius
@emccue thanks for writing all that out! the optionality part echoes some personal experiences as well
if im writing in a typed language its alot "easier" to keep my fingers typing before i even know what im supposed to be doing
thats not necessarily a condemnation of boilerplate - you might end up with the same interfaces and system boundaries at the end of a project regardless - but it is what I use as a sign that a project is a good fit for a dynamic language
if i can sketch it out in great detail beforehand in a dynamic system it might be a good fit for doing statically
I am going through a similar experience right now where I am re-writing a project from Clojure to Haskell, and it strongly fits in the category of “can design in great detail beforehand”
im also not the most experienced person out there, so take anything i say with a mountain of salt
if you have a model that you know ahead of time, being able to encode that in the type system is a big win
Haskell's type system's "painless refactorings" assume that a large portion of the types are unchanging
and you may be talking to an API that doesn't have the same level of consistency as Haskell
there could be a ton you know about the JSON, but to describe the type in Haskell's type syntax would be hell
anyway, I think the Haskell type system is really valuable, but it's not the end of the story
Interesting comment by someone I used to work with: https://twitter.com/GHengeveld/status/1180191410676469761
I share Gert's view, but for Haskell. I only used Scala for about 18 months, before switching to Clojure.
I'm working on an episode of my podcast where I talk about why I prefer Clojure over Haskell, even though I think Haskell has some benefits
as far as type systems go, I think they're the future but we have to live in the present
a type system that I would use would have to be way more expressive and cost less
it's nice when you get type checking for free without having to change your coding habits
Back at university, I worked with ML and Miranda and SASL while I was doing my research work and designing/building yet another FP language so I could experiment with syntax and semantics (and implementation issues around GC).
When Haskell appeared, I had really high hopes for it to go global and take FP into the mainstream.
Every few years, I go and try to re-learn Haskell, but I just get frustrated with it each time.
Haskell is a rather well-designed language overall, but there's still so much room for figuring out the type system
I have spent a fair amount of free time in 2018 learning Haskell, just so I could have a better judgement of this. I liked it, but more as an intellectual challenge than something I actually want to work with. Having my SQL queries type safe isn't the most important thing to me.
Where I had most frustrations with Scala was around database interactions. I suspect I would find similar frustrations with Haskell.
It wouldn't surprise me if this was more or less the same problem as spec1 where you have to make up a name for a specific set of key/vals (like is very common with query results).
So in a type system you have to make a new type for every slight variation of a query result is what I mean.
Yeah, or you construct these giant, complex, compound types with lots of optional fields.
yeah, from my experience that’s a pain-point in Haskell to which I haven’t found an answer to
I think row polymorphism could be an answer to that. They have this in PureScript and Elm. I think that could work for Haskell, but they haven't figured it out yet as a language extension. They do have libs but they tend to be complicated and slow.
I asked a question to a couple of Haskell folks at a speaker dinner last week: what's the state of row polymorphism in Haskell nowadays? One of them replied: that's a troll question.
it's going to be a great experimental language that other languages borrow features from
Which reminds me: y'all should try this podcast episode with Hal Abelson: https://corecursive.com/039-hal-abelson-sicp/
you know how that one guy did the experiment where he had some people go into psych wards and pretend to hear a voice that said "thud"
and that revealed that practicing psychologists were basically inept and not doing things in a scientific way even slightly
and then there was a news story about how alot of early psychology experiments aren't reproducible
i want either something absolutely terrible to happen or someone to indisputably shame everyone so that everyone gets scared into actually trying
def. the wrong crowd for this rant, but "industry standards" and "best practices" feel like they are mostly gobbldeygook
I know that screams "hey we've tried to make standards before and design by committee is terrible"
Java won over C++ people back in the before-i-was-born's, but only with the help of a massive marketing effort
When Java appeared, I was the editor of a C++ journal in England and I wrote a very skeptical op-ed about this "new kid on the block". And then several years later, I switched from C++ to Java as my primary work language...
Marketing helped, but so did not having to track every free and malloc... java was card out of that jail...
The other thing I liked about Java was that it's not punctuation-heavy -- after years of C++, it was a breath of fresh air to write (and read) code that looked a lot more like English than line noise 🙂
I loved Java at that time because it would explain why it would crash and where, thanks to the stacktrace.
"oh postgres can let you query over a blob of json" or "mysql can't do transactional data declarations"
and it wasn't just lack of foresight, it was a lack of understanding why we would use something to begin with
how some old dudes in the past concluded that graph databases and object databases weren't flexible enough and now its just momentum (even if they are right)
but really the programming level of stuff is such a small part of the actual engineering needed to make a thing exist
i should go through blogspot, or wordpress, or some minecraft server hoster, or aws, or whatever
but if you want to run it in a way that can support a buisiness you need to pick a way to do logging, a place to host the code, a way to scale to more people, how to deal with storing data
but I heard splunk was good, so i am going to just google how to get splunk running on aws
why does docker have a central thing you need an account with an external company to use?
Analysis paralysis is real. There’s a lot here, but one of the ways I’ve found to deal with this is to recognize that there are no universally right answers, because what makes something the “right tool for the job” depends on your constraints.
More often than not I’ve found that simply beginning to build something immediately clears away a lot of choices that don’t work.
In the worst case scenario, I spend a long time building something only to discover I didn’t understand the problem domain properly, and I have to begin again from the start. But even then, I only understand that about the problem domain precisely because I wrote that code I later had to throw away.
So having to begin again isn’t a good rubric for whether I made the right choice or not. I know more about the problem and can build a better solution now, which strikes me as strong evidence to having made the right decision.
Also, depending on the industry you work/hope to work in, you’re unlikely to hit many of the failure cases for a particular piece of tech until you’re pushing its limits, which isn’t the worst kind of problem to have.
So some questions, like what kind of data store to use, don’t have a lot riding on the answer. Should you use Postgres or MySQL? Pick whichever one strikes your fancy. A document store versus relational? Read a couple blogs and if you still can’t decide, pick at random.
I don’t know if this will help you at all, but it’s what I’ve learned the hard way so I hope it can ease your path.
Yeah, decades ago, it was all a lot simpler. You could actually run an internet service on your computer at home. I wrote my own mailing list server software in C and ran it on my home computer connected via dial-up -- and I managed mailing lists for fans of Peter Hammill (and a few other things).
Everyone using the mailing list knew that the server was only running from 7pm to 7am weekdays and then all weekend. It was too expensive to stay connected during "peak" day time.
I don't know how you'd even do that these days -- but of course why would you? There are so many mailing list services out there.
and one of our assignments for the software development class was to write some text specification for a toy problem
and we picked our language for the class so we are supposed to say "do it in language X"
When I did CS, we did some pretty substantial final year projects. Mine was to write an APL interpreter. A friend wrote a Lisp interpreter (that had full native system call integration -- so you could use Lisp to write system utilities which was cool).
I wanted to write mine in Algol 68, which I loved, but none of the lecturers knew it well enough to review my project, so I ended up writing it in Pascal instead.
which isn't wrong but its telling that those are the only 2 languages other than racket that our college includes in the curriculum
regarding types, is TypeScript winning territory or are there still a lot of JS devs who prefer "vanilla" JS?
@borkdude my impression is that it is growing still, though no clue what the upper limit is
TS is a pure superset of JS tho', right? So why would a JS dev be so against it?
In my experience, most JS devs are fine with TS as long as people don't start writing C# or Java like code with it (heavy class and enheretance use). This especially become a problem when C# or Java shop move to a node with TS backed, or devs with mostly experience in those languages start setting the direction for front end projects.
I have seen a lot of pro-type arguments like this: "48% of bugs in production would have been caught by the type system"
meaning time saved from debugging column minus time spent coding the feature in the first place
I've wondered if it detracts from the focus on the bigger domain problems by focusing too much time pleasing the type checker.