This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (56)
- # boot (4)
- # cider (22)
- # clara (10)
- # cljs-dev (50)
- # cljsrn (27)
- # clojure (27)
- # clojure-conj (4)
- # clojure-dev (3)
- # clojure-italy (17)
- # clojure-nl (12)
- # clojure-norway (3)
- # clojure-spec (10)
- # clojure-uk (137)
- # clojurescript (132)
- # cursive (4)
- # datascript (2)
- # datomic (109)
- # devcards (2)
- # editors (1)
- # emacs (4)
- # euroclojure (2)
- # events (4)
- # figwheel (1)
- # fulcro (15)
- # jobs (1)
- # jobs-discuss (4)
- # juxt (3)
- # leiningen (2)
- # off-topic (21)
- # onyx (13)
- # other-languages (8)
- # pedestal (6)
- # re-frame (22)
- # reagent (5)
- # reitit (1)
- # ring-swagger (3)
- # shadow-cljs (75)
- # sql (6)
- # tools-deps (2)
- # vim (1)
- # yada (8)
its odd my youngest used to sleep into 7:30 and now she doesnt 😞 6 am everyday, really starting to exhaust ,me
I woke up at 5:30 to make sure I caught a 6:30 train. Feeling a little bit sleepy-eyed and foggy-brained
Some useless trivia for the day... >The suffix 'ham' could be derived from one of two words, 'Ham', the Saxon word meaning 'settlement', or 'hamm', meaning 'water meadow'. A 'ham' can also be a geographical feature roughly corresponding to a peninsula surrounded on three sides, usually by marsh. >... the Germanic word 'ham' mean[s] ‘meadow in the bend of a river’, ‘water meadow’, or ‘flood plain’,
i've been told that modern-day islandisk is much closer to old norsk, because iceland was largely isolated for 1000 years after some norsk folk settled it, and it's mostly trade and other cultural mixing which causes lang change
I love that this channel has been lots of "good morning" and OT, but then it is like that every day. 😉
(I am in a good mood, it's Friday, I hit my deadline earlier this week and have since been thanked by co-workers for work done. I am enjoying it while it lasts!)
@lady3janepl - That sounds nice! Hope you have a lovely time! Where are you off to?
Primarily visiting distant relatives and some paperwork, but as it happens said relatives live in the country and it’s 30 degrees summer 😄
It’s worth going! The country improved a lot over the last 10 years 🙂 (although it’s gotten more expensive too, some places have food with UK prices)
If you ever have a chance, I recommend Tatra mountains (proper mountains), Kraków (an Edinburgh/Oxford mix, previous capital, reasonably near Tatra mountains and best ice cream I’ve ever had) and optionally Gdańsk (a port city with beautiful architecture, lots of German influence)
speaking of visiting Poland I was really surprised recently that a person on the internet really liked my home town. Not used to it…. https://twitter.com/argumatronic/status/1006631156194926595
is it just me that thinks that clojure/spec and haskell have very different approaches to how to create long term maintainable and "correct or working" software is a good thing?
I really like the dialogue and the academic work on types (dynamic and static) and tla+ et al seem to be undecided, so I don't know why we have to make a decision as an industry
you have to make a decision now about what you are going to use @otfrom, and that decision will be difficult to change later on (though μservices may help)... so maybe some of the angst around whether you have/will made/make the correct decision bleeds in to the industry mindset ?
lots of shops will continue with python/ruby/java or what have you and not concern themselves with this stuff at all probably
@alex.lynham Ain't to proud Java, the odd Java shim helps out then just call it from Clojure 🙂
I once heard Pascal creator Niklaus wirth ( Martin Odersky and Robert Griesemer did their PhD under him) say that dynamic languages are used because we have bad compilers for statically typed languages. He said compilers should do a lot more than what we have in C/C++/Java.
Interestingly the features Niklaus and Robert Griersemer conceived in Oberon lang ended up in Golang. Martin brought type inference into scala.
After listening Rich, Joe Armstrong, David West, I kind of started think that the debate of static vs dynamic typing will go nowhere without appropriate context
we are better off reframing the question - "Should I use static or dynamic typed lang for problem x"
Aside, I had a feeling that the whole microservices buzz was simply a rehash of erlang actors
@alex.lynham I too had tough time munching Java style OO. But two books really helped in making sense of OO 1) Object Design: Roles, Responsibilities, and Collaborations by Alan McKean, Rebecca Wirfs-Brock and 2) Object thinking by David West. And more importantly listening to Alan Kay, Rob Pike, and Joe Armstrong.
As of today, I think I would go for Go/Rust if the problem is close to the machine. But I would choose Clojure for a problem that is close to business. However, if I am not the one to write code, and I have to pay to someone to write the code, I would go for Java. You find Java Spring developers so easily
Go and Rust are radically different in terms of type systems and the effort required to learn.
I try to learn a new language every year (per "Pragmatic Programmer" book recommendation) and when I learned Go, I was pretty underwhelmed. When I learned Rust, it was what I'd hoped Go would be 🙂
I think that microservices do change a lot. They shouldn’t need to - proper modularity should be possible in monoliths, but developers don’t typically manage to build modular monolithic code unless you force them 😞 Whereas with small services, you can define your types more as contracts - “I expect this shape of data at this external interface, and I will return this shape of data” - and then you can use types, or not, to implement the internal logic.
If my code is split into small modules, and I have types (or specs) at the “edges”, I personally prefer not to add types all through the code - maybe if you had a perfect type inference system, tied to a range of IDEs that made the types simple to use, it’d be OK. But in all my experience, inflicting types on small code modules just makes for big code modules, where the actual work of the code is hidden in a corner somewhere, while 90% of the code is spent creating POJOs and Objects and marshalling data to and from the external formats, and building DI and Factories and a whole lot of bumph you don’t need in a more dynamic language.
@seancorfield I cannot learn so many langs. Hands down to you. I tried F# and Pony. But did not go so far. Go can be good in terms training the teams..Isn't it?
@manas.marthi Yeah, I'd say Go is much easier to learn/teach and folks would become productive much faster (than Rust).
@korny except when people build microservices that are tightly coupled and then we’re back to square one :) can’t fix some things
@lady3janepl yeah. Sigh. “Let’s put our API behind a service library!” “Hey, why can’t we release our services independently any more?”
To be fair, GDS had libraries but also let you semantically version them so you could at least defer changing the shared types. But still.
I rather meant “service X needs different output from Y!” “Wait but Z depends on an undocumented feature of Y.” “LOCKSTEP RELEASE”
But yeah, there are various ways to put yourself in a pickle. This is what people should pay senior devs for. This, and snark.
Regarding microservices, I guess two Spring Boot apps talking via JSON/HTTPS is equivalent of using channels and maps within one app. Isn't it?
Too many people take the senior devs, and say “You need to be leading not coding! Go into a corner and write ADRs and diagrams, and stop showing people how to do stuff better”
Besides, queues, and channels help to make asynch calls easy. A lot of our code is made of blocking REST calls 😞
@manas.marthi apart from the masses of bloat you get with Spring Boot, yeah 🙂 The issue though is that people doing it within one app always seem to end up tightly coupling things. “Hey, I need a class to do X, there’s one in the other module that’s public, I’ll use that”
Stuff that’s fine for a small-ish app, but as things grow, you get masses of coupling and spaghetti. At least with two Spring Boot apps you have enforced decoupling.
On sync vs async, I think it’s a common failing of microservices architectures that they tend to be all synchronous. There’s no need for it, and it scales badly. The best systems I’ve worked on had a mix of Rest-ish synchronous APIs, and queues for anything that could be deferred.
Anyway, I’m probably wildly over-generalising, I’m home after a 5-hour trip home followed by a :poop: incident with a tired toddler, I should be relaxing not pontificating on slack 🙂
$ mvn install >>>> Seriously Jase I'd grab your passport and go on holiday for a week while I download Spring Boot. >>>> Australia is good this time of year I head, shall I book you a ticket?
@korny i am of the opinion that synchrony should be reserved for cpu-bound things. as soon as any i/o is required you should go async
mvn got a lot better since i last used it @jasonbell, or at least a lot more considerate
@mccraigmccraig I saw a talk on Spring Boot components last weekend in Belfast, I just kept asking myself, "who'd put themselves through that much pain? Oh that guy at the front talking...."
i've never had the joy of spring boot... the last java stuff i was doing was springy, but pre-boot
I swear Spring Boot only seems like wonderful magic and unicorns to people that have only previously dealt with giant Enterprise Java stuff...
...I was at Java One around the time Spring Boot first appeared and one of the guys on the booth demo'd it to me and I was like "Still seems like a lot of work compared to all this other non-Java stuff" 👀
I did a Spring Boot project a couple of years. It starts like a simpler Spring. But most of that is just lots and lots of magic configuration and auto-configuration. We ended up having to dig through the source code a few times, and it’s full of bizarre magic to hide the complexity under a rug of code…