Is anyone from the Mac world able to tell me where the CoreGraphics dylib is so I can use JNA with it?

On my High Sierra iMac, /System/Library/Frameworks/CoreGraphics.framework/Versions/Current

There seems to be a symlink from .../CoreGraphics.framework/CoreGraphics to Versions/Current/CoreGraphics FWIW.

@dorab Thanks! Yes, what confused me was that the dylib is just called CoreGraphics and doesn’t have the dylib extension.

In the end I mashed up some code using JNI rather than JNA anyway.

Nice thread on Maybe Not: https://twitter.com/Hillelogram/status/1069292357219217408

In my experience people get carried away with types and overuse them to solve problems (and create new problems along the way) and hence they eventually get mentally attached to them.

@kulminaator I’ve been guilty of that. The idea that if you just lock down your types enough then nothing can go wrong is appealing but hasn’t ever quite worked for me.

TBH, I’d love a type checker in Clojure that would statically catch things like “you’re about to call a function with no such arity”, or “silly rabbit, int doesn’t support java.lang.String. The crux of the deal is that it has to be faster than I can eval the same code in the REPL.

@orestis isn't this what an IDE can do? (at least the arity: I have Cursive that tells me such things)

What is an IDE? 😛 I should try out Cursive one of these days. CIDER is unaware of such things, IME so far.

afaik, IDE can't do something like: function foo expects first arg to have a int for the :bar key" -- but something like a type system can catch it at compile time, instead of a runtime "trying to add nil" error

https://github.com/arohner/spectrum aims to do that

it's a work in progress but the intent is good

spectrum aims to statically check specs, .... which requires solving the halting problem

there's also 'typed-clojure'

yeah

none of them worked well in practice, and I went with Kotlin

well spectrum doesn't aim at full coverage so the goal is achievable

well, "empty set" is a valid subset of specs, so it doesn't really say much about what it does; whereas with type systems, however limited, it's very explicit about what it will and will not check

@orestis i was never able to get clj-refactor work in a decent way, and that's what made me switch to cursive for clojure. Their refactoring tools (find usages, etc.) has been amazing. I use emacs keybinding and the only thing i miss is that the repl isn't another "pane" 😞

I think there is a distinction between “mechanical” things such as working with files, bytes, numbers, etc etc where a type checker can be of great value and minimal overhead. However if you work with data as maps a lot, I think a type checker will be more trouble than it’s worth. But that’s just my domain, I work with Mongo these days (unfortunately) so you need to aggressively validate at runtime anyway.

I think alot of it is domain driven. If you're doing ETL work, types are a hindrance. If you're writing a compiler, OS, or game engine, types are godsend.

I really wish someone would design a pair of languages at once, like a (Rust, Clojure) combo -- where the two languages co-evolve, with one focused on static guarantees + performance, and the other on "scripting"; and the central authority ensures that interop between the two is smooth.

@todo that is actually a nice idea

and here I am trying to implement something like Pedestal interceptors in Kotlin, spending most of my time wrestling with the type system…

>I think alot of it is domain driven. If you’re doing ETL work, types are a hindrance. If you’re writing a compiler, OS, or game engine, types are godsend. that’s one reason why core.typed is so exciting

@schmee: I never understood Pedestal. Do interceptors correspond to tcp packets, or things that transform tcp packets, or what ?

Interceptors are basically just functions that take a map and return a map. You can just think of them like middleware. This page does a fairly good job describing them. http://pedestal.io/reference/interceptors

they are like ring middleware, split in half (request interceptor stack / response interceptor stack)

This is a thing I say a lot about types and situated languages: I think my second-favorite language to work in after Clojure is Swift. Swift is very dissimilar from Clojure: it is functional and strongly opinionated about working with immutable data first, but it also has static typing and much ink has been spilled on designing and refining a first-class type and operations on that type just for optionals

The key difference, to me, is where each language “lives” - in Swift, you are (mostly) working in iOS, and “in iOS” is a very different place to be situated than a JVM sitting in a server OS/container. Every time you interact with Foundation or UIKit, you’re dealing with an API-bounded conversation with, essentially, an Objective-C runtime that is entirely comfortable with handing you either the thing you asked for, or a nil - and expecting you to just send it messages and that’s fine because you can send nil messages in Obj-C.

so Swift is running in an environment where nearly everything it has to do to actually perform effective work is the boundary with a system that requires validation and a degree of defensive programming, et voila we see a wildly different shape of language arise

I like the idea of a pair of languages that can operate together, but I wonder if a pair is enough? Are there even more environments for our programs to inhabit that require a third, fourth, nth type of extremophile DNA to build themselves from?

given how hard it is to define and evolve one language, asking for 2 or more seems … harder

“Job security”

@alexmiller: If something like Racket had either a JVM backendc of all of Rust';s backends, it might work -- the set of supported DSLs should keep static-typers and dynamic-typers happyl.

@chris_johnson language shape is an interesting point. but lisps are good at supporting different shapes

There's also clojure interop with jvm

In theory with GraalVM you could stitch multiple languages together, not sure about the developer experience, and maintainability though. But maybe in time the ide's get smart enough to understand such code, and with debugging you can go easily from one to the next.

anyone know of a good git tutorial for a less than trivial rebase merge? Something interactive that would take you through the 80% use case of rebase?

preferrably interactive tutorial to have something for my team as rebase is going to be mandatory and I don't think it's clear to everyone how to do it

@theeternalpulse How are you going to handle multiple people working on the same branch, working in forked branches? I would really like my team to rebase more, but most still find it scary..

well the need for rebase has already caused friction, but the idea is that you simply rebase on master whenever you merge, then ??? then everything's great?

but I know from my experience when magit defaulted to rebase I had no idea what was going on

but we have that scenario now, and it's kind of a requirement now to rebase so our deployment process can squash them and we have one of those theoretical clean histories i've never seen in a multi-team project

This doesn't answer your question, but we've actually moved away from mandating squashing and rebasing commits, instead using --first-parent to the various commit DAG commands to get a clean view of the history.

no, never rebase on master, I meant for feature brenches

squashing is the worst

so git log --oneline --decorate --graph --topo-order --first-parent

linear history is a lie, (almost)never rebase, always merge

this is a, "I know it, you know it, but the people that tell us how the project should run told us to do it" situation sadly

Not to mention having to force push due to incompatible changes on the upstream branch

I don't like rebase at all

mjd posts on git (and his workflow) are very good https://blog.plover.com/prog/git-habits.html

do you have rerere enabled? it can help a lot if you end up with a rebase heavy workflow

never heard of that, let me look into it

it saves resolutions to conflicts so if you ever encounter a particular conflict again it can automatically resolve it

at one point a company I worked at had a workflow based on squash merges and cherry-picking, rerere made in slightly less terrible

cool, I've shared it and will look into it

"up" looks like "dn" upside-down

I've also found squashing commits before rebasing can help if you hit conflicts, since it'll be a single set of conflicts to fix, and against the latest state of the code base.

On the downside you have to give up your git history before the official merge point, so that's a tradeoff

I like the storytelling for a PR that individual commits can give, when correctly staged (as mjd noted), so I'm reluctant to squash at the PR level, though squash-and-merge seems like it's reasonable at that point

Then you have a verbose, comprehensible review followed by clean history

Anyone at the NYC clojure\lisp meetup tonight?

About to head there myself. I’ll be the socially awkward dude in a stupid hat 😆