Alive v1.0 – Live Programming for C#
blog.comealive.io
blog.comealive.io
I think that live coding tools for the big 2 languages (C# and Java) could be a great boon to students learning programming in college, where at least in my area statically typed languages seem to be the norm.
Which was a statically typed systems programming language with RC and local GC.
http://www.computerhistory.org/revolution/input-output/14/34...
https://archive.org/details/bitsavers_xeroxparcteCedarProgra...
The progress we have lost with mainstream ignoring Xerox PARC research in programming environments.
Those workstations already had something like IPython and Swift Playgrounds available.
Local GC as in, as soon as you go out of scope you free? Or is it doing something more complicated than that. I love all these old/research languages/environments, so many cool ideas. Thanks for the archive.org PDF.
PS: If you're interested in PARC, you might be interested in Brian Beckman, et al's (of MSR) "TimeWarp" http://www.cs.nyu.edu/srg/talks/timewarp.pdf. It ran into resource scarcity issues at the time but that's no longer an issue. Old PoC's are really interesting to revisit now that our main issue isn't space but latency.
(Fun fact: A CPU -> Northbridge RAM fetch is only ~5x (~60 ms[1]) as fast as a prosumer eMLC SATA3 fetch (~200ns) . Data segmentation matters guys, if you are going to have a cache miss. Sequential data matters and predictable prefetching matters, and isn't "pre-optimization" if you're dealing with low-latency stuff!")
(1): https://software.intel.com/sites/products/collateral/hpc/vtu...
So traditional RC with GC for the cycles, if any.
Thanks for the link.
http://stackoverflow.com/questions/33338225/uiview-animation...
However, they are a small step in Bret Victor's vision.
You usually are using DI, so you'll have an interface that you need to resolve and do stuff.
How is alive going to deal with that?
Alive isn't performing static analysis and guessing what your code is doing, it's compiling and running it while showing you the results. So as long as you have unit tests covering a piece of code, we can run those tests and show you what that piece of code does.
And here's another on using tests with Alive: https://www.youtube.com/watch?v=qJgMqTTKPBg&feature=youtu.be
I thought that was all a bit of a fad like factories. Lots of extra code for little benefit. Especially in a statically typed language like C# where it gets rid of so many of the benefits of using it as a language.
I look at DI, or really the dependency inversion pattern, as a guard that encourages better/more maintainable code. Can you write good code without it, sure, and you can write bad code with it, but it's much more likely that code written with it is easier to trace and maintain. Not to mention much easier to test.
The configuration based, hot-swapping of dependencies...that I've never seen much need for even in larger projects.
I use it mostly for unit testing.
I've found it immensely useful to not go through the rigamarole of newing up a ton of objects manually in my web controllers and queue/batch processing frameworks. Just choose your composition roots properly and you can easily add new endpoints/jobs/event processors without all the worry of resolving all the dependencies manually.
It also allows you to reduce footprints (setting non-stateful code/configuration objects as singletons), transparently cache and instrument(dynamic proxies, or application specific caching/logging wrappers), and other similar application-level concerns without it infecting consuming code or otherwise independent modules.
I myself and my team use AutoFac right now, but who knows what it could be in 1-2 years...
With that being said, if it's not yet "stable" then I agree, a hundred bucks is quite pricey for an unfinished dev tool.
IntelliJ is good but I prefer the free Netbeans even when I have access to the full IntelliJ paid by the company.
I just wish they'd simply added subscription options in the first place vs going through all the hullabaloo. Perhaps it was a smokescreen, but that just feels very conspiratorial.
Mental.
Depending on size of your project and complexity of the code, we can update within <100ms to a few seconds after your keystroke.
No, all the processing is asynchronous.
That's not an answer to the question. If every keystroke kicks off a compile-execute-report cycle, then the processor (and drive) are definitely going to be taking on a lot of additional load. It doesn't matter that it's asynchronous; all that does is prevent latency between keystrokes so long as your machine can keep up with the additional load.
I use ReSharper, with pretty much default options because it's too much of a pain to figure out the magic combination of hundreds of options that will improve performance without disabling the features I like to use. ReSharper does its work on a background thread, but that doesn't stop it from making VS crawl when I open up a large solution after doing a scripted (external) rebuild. Async != Free Work.
There's a ton of stuff you can do in this space: lint-type tips, RT TDD, code "explaining", path identification, etc.
Keep up the good work! Would love to see more of this as it comes along.
If anything isn't working you can report it on our public issue tracker: http://github.com/CodeConnect/AliveFeedback/
Edit: Well that looks creepy :) I don't know ragebol and apart from being a happy user I don't have a relationship with the nCrunch dude!
Performance wise, assuming the Alive developers use Roslyn efficiently (which admittedly is difficult), they could offer a lot more semantic/syntax analysis at a way faster rate (i.e., think about solutions with 10s of projects and hundreds/thousands of classes, while having a dynamic dependency graph available-- unit tests, invariants, and even property-based QuickCheck-esque testing could easily at type-time [as in after the keydown event] or a few hundred ms after).
These are all capabilities inherent of being Roslyn based though, nothing too special about Alive, just a benefit it has over NCrunch should they choose to go down that road.