This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # asami (3)
- # babashka (51)
- # beginners (86)
- # chlorine-clover (1)
- # cider (18)
- # clara (5)
- # clj-kondo (6)
- # cljsrn (6)
- # clojure (2)
- # clojure-europe (18)
- # clojure-uk (1)
- # clojurescript (57)
- # clojureverse-ops (2)
- # code-reviews (9)
- # cryogen (11)
- # depstar (5)
- # jackdaw (2)
- # malli (8)
- # nrepl (2)
- # off-topic (66)
- # practicalli (3)
- # reitit (6)
- # shadow-cljs (83)
- # sql (4)
- # vim (24)
- # xtdb (4)
Hypothesis: If all we all collectively agreed to rename “unit tests” to “code example”, that would significantly increase the chance of them being written in the first place.
Nice Hypothesis. I hardly write any test with Clojure. Also because I don't use it for work or for a library. I really like with Rust you can add code examples in the documentation, right above the code. I guess with macros with Clojure something similar could be done. Like
defne define a function, with an example of using the function.
Not really, I do have a library other people use in production. Recently I made a poc, but mostly because of politics I don't see that going to production soon.
Same. I’ve written generative tests for things that really needed to be correct and the cost of messing up is high. Those can help, like a lot. But unit tests… I barely can see the value.
I like the idea of specifying them next to the original function. There’s an overhead of switching to a separate namespace to write the “examples”.
Python does this: https://docs.python.org/3/library/doctest.html However, for tests that require non-trivial setup it can easily become awkward. EUnit (from Erlang) has a feature where you can write unit tests at the bottom of a module. It’s pretty nice for co-locating the tests and the code, and helps emphasise the “unit” part of unit testing. This also lets you test “private” functions which can be both a blessing and a curse. The risk, of course, is that a module’s “internal” API is much more volatile
I think you can use the :test metadata for this, e.g. with https://clojuredocs.org/clojure.test/with-test
I think a problem with the name "unit tests" is the concept of an "unit". Is it just a function? Will it use internal data? And so on... I do write LOTS of tests, but very few would be considered "unit tests".
Yes, good point. I guess the definition of a “classic” unit test is a test that indeed only tests one function/method.
A “unit” in a language that has immutable constructs and for the most part relies on pure functions is not the same as a “unit” in a language that does PLOP.
Having said that, there are times when you would possibly write tests that focus on smaller parts, not just the whole thing since it might be a little easier to focus and setup
Same here. I write lots and lots of test, for clj-kondo and babashka, but most of them test the entire chain, including the parsing of command line args, all the way to printing the output.
Hi, how does Git versioning work? In specific: What is saved with each commit? Just a high quality diff compared with the previous instance? Or is it a canonical copy is saved with meta data describing previous instances as diffs from the canonical-current-instance?
To me it would appear that the latter, a current-canonical-version that applies a series of commits in reverse order (id est: undoes them) for getting to a previous commit is the most efficient solution for space and furthering work. Basically have the present moment as the main copy and everything else is a diff or series of diffs against that.
Each commit has the full project at that point in time. Space is saved using structural sharing.
So it appears seamless to the user as a full-project-at-each-moment but in reality the under-the-hood stores the stuff efficiently?
Yeah I recently interviewed for a job where one of the future projects for the thing was version control for user-generated documents... So I'm curious how one would implement it nicely.
There's a lot similarities with clojure's persistent data structures, where adding an element to a vector doesn't use twice the memory due to structural sharing
Right. I see what you mean. Yes I was admiring that about Clojure just yesterday.
I rather enjoy that those efficiency dilemmas are abstracted away from the general program
This might be a dumb question but what are peoples' workflow for using two computers to work on code? I have a desktop and just got a laptop and I want to be switching back and forth throughout the day. Just use dropbox or something?
Wonder how pricey to run up a vm in the cloud and use as your dev environment... then wherever you are you can work...
I work like this, switching between desktop on Linux and Windows laptop, git works fine for me. But I tend to check in frequently.
I once used this setup. I used the faster computer as my primary coding machine, and the slower as browser, document viewer, and slack. To change between then I used a software keyboard/mouse multiplexer (I believe it was synergy)
So you reckon some form of structural sharing is key to efficiently storing git commits / git versions? Rebuilding from previous commits might be costly.
You may find the git internals chapter interesting, https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
Finding good, real world projects that cover design isn't always easy, but the git book is a great example
@jjttjj two physically distinct OS instances? (not just dual monitor?) I use github for code and you can fetch latest on the next machine each time. But uh, it depends on what you're working on. Code or image editing? Video editing would recommend getting an external HDD or SDD and putting huge files on it to swap quickly, or even swap-and-share a project directory on an external drive.
Just code editing. Yeah I've taken a stab at just using github too but I've been burned by forgetting to commit or not yet having a coherent commit ready before switching computers
@U3ES97LAC it's not exactly meant for this use-case, but maybe you can take a look at https://mob.sh/ It's some bash tooling to enable making temporary git branches and WIP commits and push/pulling them between different computers. Primarily meant for quick handoffs between several people that are coding together, but I don't see why you couldn't use it to push/pull when switching computers :)
I'd be worried about using dropbox as my source-of-truth for git repos after seeing John Hughe's talk about quickchecking Dropbox (and also thinking back to all the Jepsen post-mortem posts). Distributed systems are hard when they want to auto-merge conflicts :)
^ to be fair, someone has pointed out to me in the past (can't recall who), that Dropbox had fixed those bugs found by Hughes when they released a new sync engine sometime ago.
I’ve been using Dropbox for years and years, all my oss repos are in there so I can work on them from anywhere although Github generally has all my code as well at the end of the day
Storing full snapshots at each point in time is also important for integrity. From a design perspective it makes it harder for a bug to lose or munge data that's committed.
Hmm, that's a good point. Maybe storing a commit id and also storing some error correcting codes would help ensure things are A-OK.
random thought about programming languages. I found this article comparing Energy efficiency between programming languages (https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf?utm_source=thenewstack&utm_medium=website&utm_campaign=platform) and this got me thinking.. do we have any studies about expenses with cloud providers as your system grows by programming language? Something like to provide X workload using Python / Java / Go ... etc you will need an ECS cluster of size X1, X2, X3, and so on. (or EC2.. whatever) that will cost Y per month.
because of this GRPC benchmark https://github.com/LesnyRumcajs/grpc_bench/wiki/2021-04-13-bench-results I was thinking about that. It is easier to find python developers where I live and arguably easier for them to prototype something... but would be interesting to see how this choice also impact the budget of the company with servers to deploy these systems
I am still in a CFML community (for historical reasons), and one guy there was talking about their 40 server cluster the other day and I was thinking “sheesh, what kind of scale do you have to be to have 40 app servers?” — but I strongly suspect if he was using a more efficient language, he’d have a smaller cluster.
Yeah, exactly. I worked in a place where we switch a whole python service to golang and it made an astonish difference in allocated resources. Maybe if this was well understood we could use as a selling point to languages more efficient.
I would expect that even if you fixed the language variable, how you actually code in that language is going to introduce variability into scaling.
Possibly, but at least you could make more informed decisions. I might be in a bubble that thinks python is the way to go. 1) easy to learn and to build. So it is difficult to discuss against it with business people too but the compromise of choosing it is not well understood at all
And the language of money has more attention. Often the cost of "rewrite" after the prototype is done is taken into account. But these rewrites are very difficult to actually happen
Yeah, I’ve been very lucky to have worked at companies where “rewrite” is fine but most folks are not.
About the selling point against clojure.. let's take the grpc benchmark as a proxy. Do I prefer a very expressive and easy to learn language like python that will cost 20x more over time or a very expressive but not so easy to learn language like clojure with 2x more cost over time when compared to pure java or rust. (Or even higher discrepancy)
Studies like this would be very valuable to discussions like this with management sector
A study trying to identify what languages you are more prone to poor implementations. For example, I had an experience with PHP and it is incredible how much content is out there in the web... And how much bad advices are out there too. Looking at my teams working with python and clojure I would say that you are more prone to silly errors in python because of the amount of bad advices around the web when you search for basic stuff
@UBSREKQ5Q “hard” and “easy” are very relative. I’ve had a much easier time learning Clojure (coming from PHP) than Python. And I had “tried” learning Python before Clojure, but I had zero motivation because I never saw any benefit. It’s 95% the same language as PHP, just slower. So I never “learned” it. I have a basic understanding of it, 3/10. But I can’t write a correct line in it without Google. The syntax makes zero sense (to me). If you’re saying “easy” as in “a bigger pool of people to hire from”, there’s no contest there, I agree.