Threads for smokeonline
-
I can see more funding in Open Source projects related to Clojure with this merge and more companies considering using it in their stack.
-
I really like the idea of Looset code.
The ability of showing code blocks from multiple files in the same screen is something I wish my editor would be able to do. Have you ever thought about writing a plugin for existing editors such as VS code?
-
I like the idea of using different tools together, for example: I used to use Visual Studio and Vim at the same time to edit C# code. I don’t see Looset as an editor, but it could have functionalities to help finding a specific Code Block in any editor. Like an easy way to copy the file path and line number.
-
A protocol to tell editors to open/focus on a specific file+line sounds like a simple enough idea. Maybe piggybacking on LSP as a “service bus” for code tooling or something.
-
I thought that wouldn’t be that simple, but as pyj mentioned, source trail does that and seems pretty useful.
-
-
-
-
Looks neat and I’m excited to see how it progresses. The tagging system looks similar to that of code crumbs, and overall in a similar vein as source trail.
-
They are the closest projects I’ve seen so far from what I have thought. Have you used them? Do you have some pros and cons?
-
-
ClashTheBunny
2 years ago
|
link
| on:
Looset - A promise to improve documentation and code knowledge
I think the big question is languages supported. It would be nice, with all the compile to JavaScript/CSS programs, to support code maps. If you invented a generic code map for all languages, that would be way better than anything else I can imagine.
Maybe have the three main backends at least? LLVM, JVM bytecode, and JavaScript?
I do wish programming languages were more about user interface and less about the underlying implementation. What if every Ruby performance improvement were also felt by LLVM and JavaScript? What if eliminating the GIL in Python helped JavaScript?
-
I am going to support any language, what I need to implement what you saw in the video is just to identify a Code Block with its name (what would be a function or method in most cases). To do that I’ll rely a lot on the fact we give one or more blank lines between function definitions and we ident its content.
I’ll create the different modules of Looset as independent scripts, so it would have a general simple analyzer written in Clojure, but someone else could implement some more advanced analyzer in another language.
-
I don’t understand your last paragraph there. How would eliminating the GIL (Global Interpreter Lock) in Python help JavaScript? They’re not only different languages, but different implementations, with different goals.
Lua does not have a GIL. Python does. Lua runs faster than Python, but because Lua lacks a GIL, you can’t share a Lua state between OS-level threads, whereas you can share a Python instance among threads. It’s a trade-off in the language design.
And how would focusing on user interfaces instead of implementation help a programming language?
-
I was just cherry-picking a few things that people had complaints about in languages. I do agree that they are trade-offs. I don’t think making a Lua syntax frontend for Python would be mistaken as Lua. I just think there is much more in common with languages than is different. Could there be a flag for a GIL in Lua to make it easier to write thread safe code? I’m trying to think about what is an actual feature of a language and what is an implementation detail. Can we work less on implementation details (like with languages that are front ends to other VMs, like JVM, LLVM, and BEAM)?
-
The bottom level of langauges, assembly [1], there is effectively, no runtime (or the runtime is the operating system if you are lucky). As you go up in languages, you start to have more and more of a runtime. Even C (generally speaking, one step up from assembly) has a runtime, if a minimal one. Lua has more of a runtime than C, because it supports garbage collection, closures and coroutines. Can Lua be compiled? Yes (LuaJIT). Does compiled Lua still require a runtime? Yes, because of the garbage collection, closures and coroutines. Can you do those in C? Yes, but … (and it’s a big but) it won’t be recognizable as C, or be so painful to use that no one will use it, or so full of caveats that it’s difficult to use correctly.
Can you use the LLVM backend for Lua? Yes, only because Lua is written in C, and C is one of the frontends to LLVM. Can you use the JVM backend? I guess if there’s a C frontend for the JVM, but then you end up with two garbage collectors—the one in Lua and the one in the JVM. It probably won’t hurt, but it’s a waste of space to have two. I suppose you could remove the Lua specific GC if the backend is the JVM, but the Lua GC is generational (5.4, previous were more mark-n-sweep I think), I don’t know what type the JVM implements but different GCs have different performance and issues (reference has problems with circular references; mark-n-sweep don’t but impose some latency).
There are also implementation details that leak through. Lua supports tail-call-optimizations [2] and Python does not. This “implementation detail” can make or break certain approaches to problems. For one thing, it can make a recursive function (or mutually recursive functions) consume no stack space if supported. Python, or rather Guido van Rossum, absolutely refused to implement tail-call optimizations because it “will break stack traces”. But using tail-call optimizations with mutually recursive functions make implementing state machines trivial and very easy to follow.
From your comments here, I get the feeling you are a tool maven (whereas I am a language maven).
Oh, and Lua kind of has a flag for a GIL—the main implementation has two C macos,
lua_lock()andlua_unlock()that you can provide an implementation for and get a GIL (you’ll need to recompile Lua). On the downside, it makes Lua run as slow as Python.[1] The only platform I know of where you can go one lower, is the PERQ, where you have access to the underlying microcode, and can even modify it.
[2] If the last thing a function does is return the result of a function call:
return call_this_function(foo)that is a tail-call, and it can be optimized into a goto, not a call.
-
(It applies to this post because it would, to me, allow more tools like this to exist and be easier to implement.)
-
-
-
-
Whoever is following this post, I posted a follow up with the prototype https://lobste.rs/s/o42vrm/looset_promise_improve_documentation or you could go straight to it https://forms.gle/5vbfc54MRXcBodKc7
-
All over the place, as I am most weeks:
- Try and get the word out about an idea around a Git-client for non-developers that I had
- Release a “bugfix” version of our standard for a manifest for open source hardware
- Optimize and improve the build system for our 3D-printed microscope and finish the JS “configurator” web app I am developing for it (pre-release version)
- Do freelance work
-
dropgit sounds like a really interesting project. I’ve been thinking a lot lately about how documentation is done at companies and I’m beginning to believe that effective company-wide (or project-wide) documentation would be helped by making it easy for technical and non-technical people to collaborate in the same version control system. Would dropgit allow a developer to continue to use the CLI flows they’re familiar with while a customer support person uses a friendlier interface?
-
I started to talk with some developers about the problems in documentation and prototype a solution. I thought about relying a lot in git, mainly because I like the idea of having documentation near the code as comments as javadocs or jsdocs, but it also enables other features: most developers I talked said the code is the ultimate true and they can’t trust the documentation because it gets out of sync, so imagine a tool that shows you the last commit date for a code block and the last commit date for that code block documentation. You would be able to easily see if the documentation is outdated and check what were the changes since the last time they were synced.
-
-
Thanks! The idea is definitely to allow CLI and non-CLI people to work together. How that’s going to look exactly isn’t settled. I have some ideas but we will need to experiment and see what works. At this stage I am trying to see if I can gather enough interest in it to be able to put a serious amount of work towards it.
-
-
-
There is a strong chance for self-hosting and it being completely open source. It’s very early stages for this idea but it’s grown out of working on kitspace.org and gitbuilding.io and part of the motivation is to be able to write software that can be re-used for these open source projects. I wrote a few more details on the GOSH forum if you are interested.
-
Oh and about the commit messages: the idea is that you can change them if you wish. It will give you some time before they become “permanent”. So you can do it later or you can do it as you go. Dropgit is still very early though, mostly ideas at this point, I think I need to tweak the landing page to make that clearer.
-
-
How is it that you support adding commit messages later? Do you re-write history on the remote?
-
I definitely need to make this more obvious on the page, but this is a UI concept which is at the idea stage. I have some software written for kitspace.org that I can re-use for this but Dropgit as presented doesn’t exist yet.
My current thinking around the commit messages involves three different scenarios:
- This is a shared repository, you are committing directly to master.
- Dropgit acts as your staging area that “settles” an hour after you make your last commit, then it syncs to the remote. You can only edit your commit messages before it’s “settled”.
- This is a shared repository, you are committing to your own branch.
- Synced right away to the branch, Dropgit will
push --force-with-leaseamendments you make to the history of this branch.
- Synced right away to the branch, Dropgit will
- This is not a shared repository, this is your repo and you are working on master.
- Synced right away and
push --force-with-leaseto master
- Synced right away and
Whether we really want to support all three scenarios and how to keep the interaction and interface simple enough bears some further design and experimentation.
- This is a shared repository, you are committing directly to master.
-
-
I updated the github with a solution sketch and some maybe useful ideas. The main ideas are:
- Using labels to define multiple level of documentation.
- Run a basic static analysis to identify the function and where are they called to generate a diagram where you can filter elements you want to show/hide.
- Run this analysis in any language.
- Show usage examples of the code (tests) close to the code it tests.
- Warn dev about missing code, maybe it was deleted or it changed the name.
-
I want multiple levels of documentation for functions and data structures - at the very least (1) a one-line summary so I can scroll through a page with one item per line (with little spacing) (2) a single paragraph and (3) the full docs.
I also want something fast. There’s absolutely no reason for me to have to wait any perceptible amount of time (>200 ms) to go from one documentation page to another - the docs for almost every single project on existence (minus those with huge amounts of media) can fit into 1 GB of RAM, and modern computers are so fast that it’s trivial to pre-render all of the pages linked to the one currently being viewed.
-
Nice requirements, thanks.
-
-
-
The most precise and concise and up to date documentation of a program is the code itself. If you aren’t adding value substantially better than improving the code itself, stop now.
-
Modern systems are so large, understanding them end to end is not humanly feasible, so don’t even try. Solution: The main criteria for judging a program design is how little you need to read and understand before you can make a beneficial change. Nothing else comes close. If adding documentation means you have more to read…. don’t. Rather change your design so you have less to read.
-
Documentation is all about audience and use cases. Be very clear about who you are writing it for, and what they will be using it for. If your audience is a programmer with good code navigation tools…. be very clear about what value you are adding.
If you are not high on the Rusty Russel API design manifesto, for pity sake stop writing documentation and start cleaning up your apis.
http://sweng.the-davies.net/Home/rustys-api-design-manifesto
- Examples are useful. Unit Tests are examples that are proven to work and be up to date. They are your executable documentation. Make sure they are readable documentation. No ramble on tests, Use Given When Then and test one behaviour per test case.
Here’s advice from the 1960’s. It’s still Good.
Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. Fred Brooks
You asked…
Would be a good strategy to write code documentation near the code it’s related to so it would be versioned by git?
Definitely, use markdown (see what the linux kernel guys are doing). Being able to see the diffs is good. Wasting time on fiddling formatting is Bad.
I hate fluffy cloud diagrams. They may mean something to you now, but they don’t accurately transfer knowledge between people.
Architectural Decision Records are A Good Idea -> https://adr.github.io/
-
The most precise and concise and up to date documentation of a program is the code itself.
Up to a point. The code itself is the most precise and up to date documentation of what a program actually does. It is far from the most concise description of this, though: it’s actually the most pedantic and prolix (you could maybe argue that the compiled form is more precise and more pedantic, but I’m ignoring it here). Ultimately though, you need something else to tell you:
- what the programmer thinks the software is doing
- what anybody else thinks the software is doing
- how the programmer expects you to use the software
- whether the software solves the intended problem
- whether the software solves your problem
- why the software works the way it does
- why the software was written the way it was
- why the software wasn’t written in other ways it could have been (you pick up on this by mentioning ADRs)
And this is one of two reasons why automatically-generated diagrams are only sometimes useful. By definition they show a subset of the information presented in the code, which is itself useful when the code is overwhelmingly pedantic (code editors have code folding for the same reason). But they don’t judiciously leave out information, in the same way that a knowledgeable person trying to construct a diagram in conversation with someone who’s learning about the system would: which is the other reason they are sometimes not useful.
If adding documentation means you have more to read…. don’t. Rather change your design so you have less to read.
I find the common failure mode for this “my code is self-documenting” approach is that the code author has typically spent a lot longer grappling with the problem and understanding its features than many readers would have, so has a unique impression of what can be expressed without documentation.
-
what the programmer thinks the software is doing It doesn’t matter what he thinks it is doing, only what it does.
how the programmer expects you to use the software Fact. Users don’t read documentation. They hate you and your program and the horse it rode in on if they have to read documentation to use it. Sad, not what I grew up on, but a fact of current existence.
“my code is self-documenting” What I’m saying is not about self-documenting, it’s about designing code so your need neither to read documentation nor reams of code.
The harsh vicious fact of life most code bases (if you include dependencies) are growing so fast, that even if you read all day everyday every second non stop…
THEY STILL GET AWAY FROM YOU!
You fundamentally cannot understand it end to end.
That route is dead, no longer open to us.
The only route left to us is to design things so we only need to read a small amount before we can make a beneficial change.
-
(if you include dependencies)
…which you only do if you think that “the code is the documentation”, because you can’t trust silly things like API docs. The point of packages, modules, APIs, whatever you want to call them, is that they allow you to avoid needing to transitively read and understand the code of all of your dependencies by just having to understand the interface.
-
I’m currently forced to code to a black box proprietary interface for a certain device stack.
99% of what I’m relying on is that it is reasonably well designed (by the Rusty Russel API Design manifesto).
1% of what I rely on is the design / architectural conventions documentation.
Alas, it’s ambiguous.
I could answer my questions with 100% certainty if I had 20 minutes with the source code.
I don’t.
My productivity is throttled.
-
You seem to be making the point that you need source code in case the documentation is bad - in which case, yes, you need the source code - but that’s not my point.
My point is that with all current languages, good documentation beats out looking at the source code every single time - and it does, because no existing/widely used programming language is sufficiently expressive to show all of the things you put into documentation, such as design intent, and additionally, the documentation can be far more concise than the code by eliminating implementation details.
-
No, my point is Good API design beats Documentation of all and any flavours every time.
Unless your API design is excellent, wasting a single brain cycle on documentation takes you away from the more important task…. Improving your API.
Sure, if your API design is excellent and you’re twiddling your thumbs wondering what to do next… Work on your documentation.
I’m deadly absolute serious about http://sweng.the-davies.net/Home/rustys-api-design-manifesto
Everything in my experience has hammered home the lessons in that manifesto time after time after time for 40 years now.
Out of a rank of 1 to 10, where 10 is most important, “Read the documentation and you’ll get it right” is at a low number 3.
-
-
There are two flavours of documentation. User docs and dev docs.
Users don’t read docs unless they are desperate, and then hate you for making them do so.
I don’t write programs in English. I write them in a programming language.
If you have chosen your language well, it is the most concise, precise and expressive way of expressing the concepts involved.
English is neither precise nor concise. It’s expressiveness comes partly from overloading words and terms with meanings and values, and piling on adjectives at dire cost to precision and concision.
The joy and pain of computing (and mathematics) is it really doesn’t matter what you mean, only what your code does.
-
There are two flavours of documentation. User docs and dev docs.
Yes, and English is superior to APIs/reading the code for both of them.
Users don’t read docs unless they are desperate, and then hate you for making them do so.
Doesn’t matter. Docs will still be superior to making them read an API or the code.
I don’t write programs in English. I write them in a programming language.
Doesn’t matter. There’s no connection between what language you write in and what language you document in. English is more expressive, and in specifically in important ways that make it better for documentation than APIs/code. Show me how to express the reason behind a design decision (e.g. you have to do x because of y, or because of historical event z), as opposed to implementing the design itself, in C, or whatever other language you use. You aren’t allowed to use comments, because those are English documentation, or convoluted code that is significantly different than what you would usually write.
English is neither precise nor concise. It’s expressiveness comes partly from overloading words and terms with meanings and values, and piling on adjectives at dire cost to precision and concision.
It can be very precise and very concise, and more importantly, it has the ability to express an entire class of necessary kinds of documentation, such as reasoning behind design decisions, that modern languages cannot.
Let me be more clear: modern programming languages do not allow you to express historical context or design rationale, both of which are very important for understanding nontrivial systems, and so lacking them is unacceptable - hence, English documentation is necessary.
The joy and pain of computing (and mathematics) is it really doesn’t matter what you mean, only what your code does.
This is only true in the most literal sense of that the computer doesn’t care what you mean. You know who cares about what you mean? Humans, which are who read and write code, and for whom code is executed. “Programs must be written for people to read, and only incidentally for machines to execute.” Therefore, API-only documentation is (1) objectively inferior and (2) unacceptable for development.
-
Let me be more clear: modern programming languages do not allow you to express historical context or design rationale,
I honestly don’t care about such. That’s what commit logs are for.
If I was writing a history book, or trying to justify myself at a trial… Maybe.
All I care about are the constraints now, the behaviour now.
I don’t even care about intent, only behaviour.
I hate code that has the domain stamped all over every variable name and class…. and after wading through the whole thing up and down… I find it is something trivial and generic like a stack.
For pete’s sake, call a stack a stack. An preferably use a language that comes with one out of the box.
I want the humans, who are programmers, when they read my code, to read it using the rich and specialised vocabulary that comes with programming language and standard libraries I’m using.
Code is like group theory. It may be applicable in some domain. But if it is self consistent, and complete (in the mathematical sense)… it has uses that the author cannot imagine or intend.
-
I honestly don’t care about such. That’s what commit logs are for.
That puts you in the tiny majority. The vast majority of programmers, including me, and probably every other one you know, want to know design rationale - because knowing that stuff is actually important, because design rationale encodes information that cannot be encoded in source code with any modern language - as a trivial example, the fact that a data structure is an array of records instead of a record of arrays for caching reasons. You cannot put this knowledge in source code - and as someone who eschews English documentation, you’re either going to be re-making a lot of mistakes, and missing out on a lot of performance gains, and opening security holes, because you’re limited to only the information in source code, or you’re working under conditions that aren’t applicable to, well, the vast majority of programmers - which is the target audience of the original poster: people who want documentation. Not you.
-
Design rationale encodes information that cannot be encoded in source code with any modern language - as a trivial example, the fact that a data structure is an array of records instead of a record of arrays for caching reasons.
That may be the rationale you believe, I’d rather one of the tests include a benchmark that proves it. Beliefs about speed and caching are one of the areas programmers get wrong surprisingly often.
But you’re still missing the point.
The point is simple, it’s not “don’t document.”
It’s documentation is down at number 3 out of 10 in the list of priorities.
If you’ve hit priorities 10 to 4 as best you can…. go for your life. Document in away in Hebrew or Dutch or German and Greek
It’s A Good Thing. It makes life better.
Just take care to keep it up to date.
It’s amazingly easy to slip to level “-3. Read the documentation and you’ll get it wrong.”
In fact my experience is every project I have seen has some documentation at level -3.
-
-
-
-
-
-
-
-
-
-
-
Definitely, use markdown (see what the linux kernel guys are doing). Being able to see the diffs is good. Wasting time on fiddling formatting is Bad.
I hate the new Linux kernel documentation. The old plain text stuff is so much easier to consume than the new HTML-based documentation, it’s just insane how awful the UI of their documentation viewing website is compared to just opening
CodingStylein vim. As a programmer, I’m already very comfortable opening, reading, editing and navigating plain text files. It seems absurd to put documentation in any other format, to me.-
I understand your feeling, I really prefer vim to more fancy and visual IDEs, I think any developer prefer to write text to using some kind of visually alternative (like Scatch), but it might be good to identify what a rich visualization as html has to offer, like text different sizes, alignments, colors, images, interactivity, etc.
-
-
-
I’m working in a tool to improve the documentation process, check it out https://github.com/JpOnline/Blog/blob/master/documentation_sprint.md
-
I wouldn’t bet in desktop installable apps. I see very litle use cases that are a good fit for a desktop app instead of a Web App or a Mobile App.
-
I don’t see a lot of reasons nowadays to write native mobile apps instead of Progressive Web Apps.
-
You pass in a map with your own shape to represent a human, dog, or cat, and the function treats them all the same.
This implicitly means that human, dog, cat, etc. all provide the same static data needed by the function, or have to have appropriate conversions available to make an appropriate map. I’m pretty sure spec covers this, but it’s an absolute pain when functions conflict on the format or names of data they expect. Just passing around maps can hurt function discoverability when you’re unsure if a particular function has been implemented.
Would you rather have 1 sleep function for 100 different animal types, or 100 different animal classes with their own sleep method?
I’d rather just let the class accept appropriate parameters and:
- Add it to a Mixin or make a utility class method (Ruby)
- Just make it a static method on a utility class (Java)
- Make it a free function (C++)
- Define it somewhere in a class at or near the base of the hierarchy.
- Use the template method pattern to adjust behavior as needed if it’s part of a larger flow.
There is an eternal debate around Object Oriented software vs Functional software, and there likely will never be a conclusion, however, this is why I choose Functional when possible.
Eventually I will write up the several pages of lessons I’ve learned after being thrown in OOP and also into FP code. For now, this will have to suffice.
I don’t feel like I have to choose. I get to use languages which support both ideas and try to simplify the thing I’m working on the best I can using both.
OOP excels at creating small types with known transitions between their various states and associating easily discoverable behavior with that data (quaternion, stack, etc.). Using interfaces to define behavior (or traits) also allows type checkers to assist in discovering incorrect usage and allow multiple data types to be used similarly (yes, there are FP constructs for this like typeclasses). You can model systems directly as classes too, but doing so is a delicate balance.
In the problems I deal with, OOP suffers when (1) people poorly define the boundaries of a system, and use these to create a suite of classes, (2) make tall inheritance hierarchies, or (3) needlessly create additional interfaces. In the poorly defined system, you end up with a constellation of classes and objects, all shuffling data back and forth and following control flow becomes incredibly difficult. With a tall inheritance hierarchy, you’re implicitly carrying around a lot of state like a backpack, while that method called near the base of the hierarchy is actually a virtual function re-implemented 3 or 4 different times within the hierarchy, but you have to know about these to understand the control flow and it’s jumping all over the place and you have to track it down. There’s just an incredible amount of implicit behavior and state going on. With a whole bunch of needless ISomething interfaces, it’s like sitting in a lecture where some high level theory is being discussed and you’re praying your professor will actually give a concrete example. You’re trying to track down a specific bug, but that ISomething it’s using here is a Baz, class Bar here, but, wait, there’s Foos sitting too, multiplied a half dozen times with multiple interfaces with convoluted runtime state held by each group. Every attempt to get to real behavior involves at least 4 or 5 layers of interfaces and the code feels like a house of mirrors.
FP suffers when you have
(a (b (c (d (e (f (g ... )))))and you’re trying to understand what the state of the computation looks like at when e is called.fis returning some bizarre map, but noone wrote a /spec for it, so you’re not really sure what you’re getting because that same person wroteg,h, andiwhich feed it and also don’t have a /spec, and it’s using some convoluted piece of data you can’t readily replicate for some reason to try it out in a REPL. There’s a lot of implicit state in terms of the control flow as it emerges out of all of these chained function calls. The other trouble I have in FP is that I often find docs which are unapproachable. It seems like they were written by someone with the stated goal of showing off their higher education and you can’t understand half the verbiage (this is how I’ve learned fun things, like what “nota bene” means) or it includes a bunch of math which “is obvious”. I know this isn’t their intent, but I literally keep a notebook of definitions like I’m in school to be able to figure out what’s going on.-
TLDR
But I like that you gave specific examples of what you would do in each language. I think we devs suffer of a disease that makes us to want to abstract everything. OOP or FP are not single well defined things, We could discuss languages and how easy is to write good software on it. It’s possible to wire bad code in every language. We should focus on principles not rules.
-
smokeonline
edited
3 years ago
|
link
| on:
Clip - inversion of control API - an alternative to integrant, mount or component
It’s very easy to find people saying good things about the Components strategy. I see a lot of tutorials with the conclusion that is much better to use the REPL and write tests with Components than without it. But it may come with unnecessary complexity. I think that components, as any design pattern, should be used when it make sense. Not blindly adding boilerplate code in every namespace.
Is interesting to see that the criticism comes in form of new libs as Clip. What interests me in this one is the attempt to minimize boilerplate.
I would like to discuss the problem that this libs are solving.
I have as primary reference Component’s README and Stuart Sierra’s Reloaded workflow. I see that the main problem that’s being solved is the difficulty of working with entities that require initialization in the REPL. With databases being the main example.
-
I already dreamed about a keyboard more or less like this. I almost bought an old solution for mobile (it was supposed to be used with only one hand), after that I considered customizing a game controller to be used with only one hand. But it was too much trouble as I had to interact a lot with hardware not only with software.
-
-
If I remember correctly, it wasn’t that easy to recognize multiple keys pressing. I remember to try a lot of controller softwares for Windows without success. After a while I focused more on getting different keyboard shortcuts to automate some tasks so I used AutoHotKey for it. This I could create a work around to press multiple keys as “modifiers” besides keys like ctrl, alt, etc. Check it out https://github.com/JpOnline/AutoHotKey-script/blob/812fcb4c6d21130f2810a4b1d88d90472b080147/ahkScript.ahk#L11
-
-
-
#/media/File:Scratch_2.0_Default_screen.png){kind=link}
-
It seems to leverage the power of specs. I can see it working alongside Re-frame.
-
I’m currently having issues using fireplace with clojurescript. How well Paravim works in Linux, with Leningen and clojurescript?
-
It’s an interesting idea. I tried to use REBL to walk through a datomic dB, but I couldn’t make it to work.
-
I also created my own colorscheme, check it out. https://github.com/JpOnline/vim/blob/master/vimfiles/colors/custom_(based_on_jellybeans).vim
I don’t see myself using a light background, but I also enjoy not that many colors.
Now you can find more information about the project in https://jponline.github.io/looset-landing/