Lang.NET Presentation

I presented at both the Lang.NET Symposium and Seattle Code Camp, but it didn't proceed as I originally planned.

For several months, I have been changing the back end of my software to scale better and retain sufficient control of the performance of my product under all circumstances. I do have some hard-coded limits, but these limits and time constraints don't really work well the way my software is written. They are better for catching events that should never happen. The changes were extensive as I used functions pervasively to compress the size of my expressions and maintain the invariant that expression size stay proportional to program size. Manipulating arbitrary functions, particularly recursive functions, in a general and efficient way is really difficult.

I was using these two events as a forcing function for releasing my software. Unfortunately, I didn't make my deadline. I lost about several days of productivity due to a random apartment incident. I skipped a day and half of the conference to prepare in a valiant attempt to demo the most recent build of my software. Instead, I used an old release of my software from six months back, and messed up my demo since I forgot that I could only execute expression in the immediate window from within the context of an error.

My presentation relied heavily on slides rather than a live demo, which was not my plan. People want live code. Presentation slides also leave the audience confuse about the nature of the product as Ted Neward wrote in his Lang.NET review.

For people reading my blog, there wasn't too much extra information above and beyond what I have talked about in the past, since I could not assume that people were aware of my product. Some new points include the liveness of the environment, closed forms and some manipulations with functions.

I am wary about giving too much information, since I have leaked so much already for a considerable period of time without actually releasing the product.

I prepared the slide a month in advance, hoping that I would make changes over the course of the month, but ended up spending a full day polishing the presentation before my Code Camp talk.

Some reactions:

• Four Microsoft researchers quizzed me.
• A number of people that I have met read my blog... Most of the Microsoftees appeared to be familiar with me.
• A few people asked how they could apply for the beta. Others were hoping for a Java version. Miguel comment to me that it was a great presentation. I was surprise of my healthy applause, because I hadn't been paying attention and have never given any applause. The applause level was similar to Miguel's presentation later on, so I couldn't actually tell if the applause was enthusiastic or ordinary.
• Some questions on technical aspects:
  • did I utilize an available prover software like Z3? I wrote the software myself.
  • has my prover been benchmarked? No, and it's doesn't deal with the types of formulas use in the benchmarks.
  • how do I handle complicated cases like overflow. My overflow checking is very limited, since, in the past, I wasn't interested in cluttering my assumptions, but adding such support is trivial and now also less problematic.
  • how do I deal with invoking function variables (ie, delegates). I represent them exactly, but, for the sake of analysis, I ignore the potential effect on state if the function is unknown.

Postmortem:

• Create setup files regularly. Though I update component libraries frequently, I relied too much on .NET's XCopy support. Despite having copy DLLs to output folder, I was not able to get the build that I want working.
• Save interesting snapshot pictures of the product while in development. I reused a lot of images from my blog.
• Always try to have a working build. Include notes about the status of the software. I took a random setup build without remembering what state it was in.
• Conversations and event draw energy away from me. I usually enjoy my energy juices and bars before development, but I should actually remember to do even more so before presentations.
• Get well-rested before a presentation. This is unusually difficult for me, because I work during nights and sleep during the day.

There is still a geek dinner coming up in the next week that I may take advantage of to give a live demonstration.

Comments

[Jeremy Gray]

It has been a while since you posted on NStatic itself, so thanks for the update.

I do have one comment I would like to make, however, about your statement regarding "Create setup files regularly": For what it is worth, you should be striving to reduce your application's dependency on installer technology, not increase it. If you are finding yourself forced to head towards an installer because of libraries that you are using, for example, that isn't a reason to create an installer, it is a reason to harass the libraries' creators to reduce their installation dependencies.

As far as I'm concerned, the closer NStatic is to pure xcopy deployment, the better. The trickle-down effects from not needing an installer are hugely beneficial to your end users and, in the end, to you as a vendor.

[Jeremy Gray]

To be clear: not needing an installer is quite distinct from not having one. ;) It can certainly be a good thing to have an installer that makes it convenient for a user to set up shortcuts and to remove the software when desired, you just should be very wary of your application _needing_ an installer from a technical perspective.

[Sergey Lipnevich]

Hi! Is there any way to get on the list of beta testers?