I've always wanted a runtime visualizer, and/or a static analysis visualizer. With a couple of exceptions I was unable to find a suitable library and it seems for some reason this hasn't been built yet.
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 do wonder why more work hasn't been done in this area—especially on the run time side.
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 :)
Perhaps a combination of cultural and technical feedback loops?
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.
Very cool! Looks very promising and something I'd use often if it were connected to IntelliJ. I'd been toying around with a similar idea of doing a similar "visual debugger" but within VR (not that it needs to be, but 3D is fun. I've never found time to execute on it however.
Thanks, and glad to hear! Yeah... having it connected to IntelliJ was something that seemed always 'around the corner' for years. I think I will forever be annoyed working on projects without having something like this around—so hopefully someone will get to it eventually.
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.
Firstly, congrats on an interesting project with clearly a lot of thought and time investment. At end of article you request feedback on should you open source - in that respect:
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.
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.
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.)
Very interesting. From a quick read, I feel like the domain/converter pattern has elements in common with flow based programming, is this close?
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.
do you have a github repo? if not, why did you choose to self host?
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?"
There is a github repo for the project, it's just private still.
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.
* 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.
You hold the copyright to code you write by default (at least in the US). So you could choose to license it to the public under (for example) GPLv3 and you would still hold the copyright - others just have permission to use it in accordance with your terms.
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.
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.
this product looks interesting. just my unsolicited opinion, but if your goals are wide adoption and/or monetization you're probably better off open sourcing this. I can't say how useful it is or isn't without playing with it on my projects. but if it's as good as it looks and easy to use, you'll see stars on github and that will open up a lot of options
This is absolutely spectacular, I love it. Have you thought about approaching a programming tools company like Jetbrains to licence/sell it to them? They would have the resources to turn it in to a viable commercial product.
That's a good idea. I should at least try, but tbh I've always just kinda figured they wouldn't take me seriously. Jetbrains seems pretty broadminded though....
Tangent; a small detail of your extension: I really like that tree widget you used, it traces the path from the root of the tree to the selected leaf.
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.
Thanks ;) It took me a great amount of effort to implement that tree widget as I had to combine absolute positioned svg elements with relative positioned divs to get that effect.
This should not be a Show HN as there is nothing you can actually try.
> 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.
Hmm, I guess it depends on how letter vs. spirit you'd like to interpret that in. It is still a project I spent years working on that I'd like to share with the community and get feedback on, so that I can potentially make it available.
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.
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.