Fork me on GitHub

why did image based development (Common Lisp/Smalltalk/Erlang(? - in-situ updates) not gain more prominence? I've seen multiple posts about statically typed langs like Rust, Elm and Ocaml where it's been stated that "if it compiles, it runs without error", someone even going as far as saying the OCaml type system letting them express their problem as a self-consistent crystalline structure. I can't properly enunciate my point yet but this strikes me as being the computation equivalent of pinning a butterfly to study it


I imagine what those people meant was that if your type system is complete enough it's literally impossible to have certain classes of bugs, in that your program won't compile if the function doesn't satisfy the type


@michael.e.loughlin I probably will try SmallTalk in the near future, and find out for myself. But how is image based different from Java, witch is kind of 'jar-based'. I know source code and jar's are different, but that works both ways. Using Java with docker, where the deployables are docker images is maybe even more image based.


What are stored in a Smalltalk images are objects, not classes. The entire state of your environment is saved in the image.


So the big difference is that any state change also becomes part of the code? In that respect it seems a lot like, with a cms, adding some bootstrap content?.


My understanding of images (from Common Lisp) is that - the compiler, runtime environment and your program exist together in the process, affording the ability to incrementally develop at the REPL


I think you have to give up the idea of code. In Smalltalk, everything is an object (including classes) and those objects are stored in memory. The state of your environment is completely represented by the graph of objects in memory. When you save it, this memory is stored on a permanent medium. That's the image.


@conor.p.farrell that makes total sense, and on further reflection a compiler/static type system is orthogonal to image-based development.


For example, in Idris this won't actually compile as the output isn't a vector of length n:

myReverse: Vect n t -> Vect n t
myReverse xs = []
It's quite interesting, though it does tend to lead to some satisfying the compiler that you know what you're doing šŸ™‚


with my original statement, I was largely thinking about the things a type system can't express (as per Rich Hickey's Maybe Not talk) - there is a whole world of runtime behaviors we can express with code but can't test with a compiler

šŸ‘ 1

so the "self-consistent crystalline structure" comment about advanced type systems strikes me (as someone who has at least dabbled) as being a false assumption about the nature of code [in my experience] -- you think you've written a bug proof program, but actually there's this whole other load of behaviours it can exhibit that are easily overlooked because you can't describe them at compile time


then you get an email from JIRA about it from an angry tester šŸ˜‚


Iā€™m looking for a type system that requires a full mathematical proof of the program (including axioms) plus a written statement from AWS promising that networking will never be down.

šŸ˜‚ 9
ā¤ļø 1
šŸš€ 2

oh my GOD javascript why. can anyone help me fix this snippet?

function why ([key, val]) {
    return Object.assign({}, {key: val})

console.log(why(["god", "why"]));
desired: > {"god": "why"} actual: > {key: "why"}


@idiomancy {[key]: val} will "resolve" the key var


@U2J4FRT2T do you happen to know if theres a.. like, a function to do that? Like Symbol.resolve('key')

ā“ 1
šŸ’„ 1



thank you so much


i couldn't for the life of me figure out how to google that problem


any Windows users want clj-kondo in VSCode? please give this a go and report back.