Show HN: Lucidity – an interactive program-state visualizer
symbolflux.com
symbolflux.com
So I also decided to take a stab at this, and hopefully will share if I get anything useful. I'm using Haskell + Diagrams to construct a JS parser (to begin with) that will do static analysis and render a graph of whatever you need. The simple use case I've always wanted was just a slice of the graph of the function calls, perhaps with some information on context variables. Seeing this visually would help me get up to speed with any codebase and would allow extremely fast contributions.
I actually think a big part of it is something like a fixed perspective on what the process of computer programming has to be like that comes from an era before it was possible to do such a thing well.
One of the skills a programmer always implicitly learns is to imagine the data their code is operating on—and only to occasionally peek into it with e.g. printlns and debuggers. There's something about the seeming necessity of that that keeps people away from tackling the problem directly. It may be a fish not being able to see the water kinda thing. (At least that's my read on it :)
Technology selects folks that like 'playing computer in your head' as Victor said [1]. This grows a culture where tools that help you avoid mentally simulating the computer are devalued. This selects more people even better at playing computer in their heads, etc.
[1] https://www.theatlantic.com/technology/archive/2017/09/savin...
It seems like there is more interest in this 'direction' these days though: I saw something new from the Firefox dev tools the other day whose time-navigation felt very similar (I'll see if I can find it), and the Clojure REBL project feels philosophically aligned. And I've seen a few others.
Using it in VR would be awesome :D
Edit: I think this was the Firefox devtools thing I was thinking of: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
edit: ok, sorry I missed the whole section of your website that answers this. let me rephrase as, "can you say more about why you chose not to open source?"
I don't have any real experience with open sourcing projects outside releasing a few small things with MIT licenses (none of which had any real activity from others)—so while there's a good chance I will open source this, I just don't know at this point if there are things I need to take into consideration that I'm unaware of. Hoping to get some feedback on that by posting now.
Edit: haha, okay, answering the revised question:
It's roughly the same thing: lack of knowledge of how open source projects 'work'. I guess I have a number of probably unfounded paranoid concerns about what would happen if I were to open source—which I'm actually less concerned about now, but early on I had some ideas about turning the software into a business, and I've had the perception that you need to know what you're doing to run a business around an open source software product.
I'm willing to volun-tribute my time to play MITM between you and GOOG queries to do the grunt work in researching options in how best to open this thing up.
I've got some big plans that I am hoping to get my employer on board with so I can finally make my first attempt at spinning up my current variation of the always just out of reach, Tantalus's unicorn.
Not sure if my contact is retrievable thru my public HN acct bits. If not, I'll check back here and provide if there's interest in at least shooting the shinola with another like mind for a minute.
CHeeers
Some thoughts, in no particular order.
* Would it bother you if someone used your code in a proprietary product without paying you? Without even crediting you?
* Would it bother you if someone ran a proprietary web service using your code?
* Would it bother you if someone openly forked your project? What if they ended up receiving donations to work on their fork, while you weren't making anything off of the original project?
* Do you care if a fork (or patched distribution) uses your project name? Some projects trademark in order to prevent this (ex Firefox, Rust, ...).
Related to the above, carefully consider the different implications between licensing under AGPL, GPL, MPL, and MIT style licenses. Bear in mind that AGPL and GPL will significantly reduce the set of circumstances under which someone in industry would be able to use your code - that might or might not be desirable to you.
(Aside: My preference is generally towards MPL, but MIT has its use cases.)
> I've had the perception that you need to know what you're doing to run a business around an open source software product
That's complicated, and likely depends a lot on what _sort_ of business you want to run. You reveal some or all of your trade secrets, but might gain any of visibility, good will, and community contributions.
If you aim to sell a proprietary product (as opposed to consulting or something else), be careful under what terms you accept contributions from the community to (a portion of?) your code base. Appropriate modularization of the project is likely to be important in this case.
Could you elaborate on:
> be careful under what terms you accept contributions from the community
In particular, for the GPL example that means you could still release a proprietary product based on a modified (closed source) version of it. Other people can't, but you can.
It gets complicated as soon as you accept community contributions into your version though. By default, each contributor holds the copyright to their work - you merely have their permission to use that portion of the project under the terms of the project's license. If the project itself is MIT licensed, I struggle to imagine how this could pose a problem. But for GPL, MPL, and similar, you lose the ability to release closed source variants if they would make use of those community contributions.
Some projects require all contributors to sign a CLA granting them copyright (or similar) to avoid such issues. I suspect this would be unpopular, and would likely result in a fork if you aren't a large corporation throwing a huge amount of resources at the project.
Other thoughts:
* Properly modularizing things mostly sidesteps this. Cleanly separate the proprietary portion and release the shared part under a license that allows linking to it (LGPL, MPL, or equivalent).
* If you don't have a clear business plan or the time available to work on this, you might consider just throwing it into the wild in the hopes that your past effort is useful to someone else. That's arguably better than having sunk time into something that never sees the light of day. To that end, something like CC0 or zlib would maximize the chance it gets used.
* Some licenses might not be compatible with certain distribution channels. For example, it isn't entirely clear to me if GPL and LGPL code can be legally used on Apple's app store since the end user can't realistically make use of a recompiled or relinked program on their device.
* Not actually owning all of the code in your product might (or might not) impact your ability to convince someone to buy your company if that's what you're aiming for.
There is clearly some interest in this area e.g. DS-PITON project (See https://bit.ly/35Eq35R) or the Jive project for java (https://cse.buffalo.edu/jive/). Another would be Glamours Toolkit for Pharo Smalltalk (https://gtoolkit.com/) - though it has a larger scope.
If you do not have time or funds to continue it in its current form and you do not have any 3rd party at this point interested in sponsoring development in some form, and you cannot see how to leverage it in the future - what do you have to lose by open sourcing it?
At worst - it languishes, and no one uses it but it will give you a referenceable open source project for your CV that may help attract work in this or a related area.
At best, the project sees adoption and opens new opportunities for you.
Given the quality on display in the articles and videos I would expect the project to get some interest especially amongst IDE and program visualization communities.
If you do decide to open source the project be careful on licensing choice (to encourage adoption in a manner you want) and copyright notices to ensure you are associated with it. Do expect to have to invest a little time in documentation and code clean up before making it available - but think of that as future advertising for your own capabilities.
Good luck
> ... - what do you have to lose by open sourcing it?
That's pretty much my line of thinking as well. It seems like not much.
Thinking about it more, part of what I've wanted to figure out by posting:
1) How much interest is there (so will it be worth my time to do the documentation, etc.)
2) What's the minimum set of tasks I'd need to do in order for it to have some likelihood of getting picked up by others.
3) Is there some clearcut business usecase that I've never considered that someone on HN might bring up.
0. Decide how you want to license codebase and how much you care about post-release adoption.
1. Write enough documentation to understand what the project is and can be used for (i.e. an edited version of what you have already posted)
2. Minimal demo project / app that the can be build so a prospective user can understand the application / library (probably updated example you already have)
3. Clear repeatable build instructions for demo app/ lib etc
4. License and Copyrights clearly stated and in codebase.
5. One or two paragraph guidance on contributing to the project or using the project.
6. Plan on where to announce, announcement msg and follow up so you can monitor interest.
7. If you decide you do care about adoption, plan on some regular but minimal effort after release to write updates/project blogs so folks can see what is happening and encourage interest. *i.e. dont just throw it public, do no marketing or launch effort and expect people to magically find it and adopt it - some sustenance effort will be necessary. If you don’t care, but just want to release it so its out there – then this step is obviously not necessary.
Finally, perhaps, an alternate way to get people interested in Lucidity and demonstrate Lucidity's benefits would be to package up Lucidity and look to contribute new features / functionality that leverage a subset of Lucidity to an existing project that would benefit from those Lucidity's features.
Whatever you decide, Good luck.
It's built on top of a simple application framework I wrote largely in order to build Lucidity on top of: https://github.com/westoncb/Domain-slash-Converter
I should have written it in a more prototype-y way, but I naively built it on something like a custom engine from scratch in opengl :/ (I figured my rendering requirements were specialized enough I should roll my own: after all its just boxes + quads + text)
There's also source available for doing the 'monitoring' side of things in javascript: https://github.com/westoncb/JS-Watcher (though I've been informed since that I might be better off using an existing lib—Immer, I think—rather than writing the stuff to monitor property changes myself.)
I've came another repo that reminded me of some of the goals of your projects, If I get it right. Lava [1], according to the author, it is an architecture to solve "classic software problems" that includes visualization tools.
1: https://github.com/LiveAsynchronousVisualizedArchitecture/la...
Good luck!
https://marketplace.visualstudio.com/items?itemName=hediet.d...
We have different approaches though.
I wish all tree widgets looked like that. For instance, the VS Code file tree is awful: I always need to look thrice in order to double check which folder a file belongs to, specially when there are a ton of folders.
> Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread [https://news.ycombinator.com/showhn.html]
If you upload binaries for the various platforms somewhere and link on the page, maybe mods be nice enough to let the post stay here?
Because the project looks awesome and I would to try it out in order to give feedback and use it myself.
Unfortunately at the moment there isn't really a reasonable way for me to make binaries available that would be useful for much. I'm going to go make a sandwich and then think a bit more about whether there's something I can do, though.
I assume the mods are fine wit it since they've already revised the title once.
You're technically correct.[0]
That said, I was extremely pleased to just have a glimpse at this project and would rather have it be a Show HN than not.
Upon further reflection I usually just look at most Show HNs without interacting, and I suspect many people are the same way.