ASP.NET 5: How to Get Your Cheese Back

This talk didn't do much for me except convince me that Microsoft continues to struggle for relevancy by reinventing the wheel. Rewriting ASP.NET from scratch only serves to frustrate everyone involved with it. Not worth my time.

A Developer’s Journey from Object Oriented to Functional Programming

This talk was basically an intro to F#, which I've played with before. I wish the author had spent more time describing the good parts of functional programming because he spent a lot of time just talking about object oriented design. I guess there's no substitute for reading a good textbook functional programming, but I don't think any minds were changed in the audience.

Having said that, it is definitely possible to go overboard with pure functions or LISP-style macros that later make the code unreadable and unmaintainable. It's hard to find the sweet spot of a functional language that doesn't require extra deployment dependencies, and it is still possible to debug it without going insane (haskell is too pure to debug without going insane), and it has enough popularity with other programmers and businesses to not destroy anyone's career and/or code base.

Or you could just keep writing in a common language (like C# but with more lambdas and linq) and wait for this fad to pass, much like every attempt to popularize functional programming in the past.

Cure What Ails You With This Rx: An Intro To Reactive Extensions

I love the idea of Reactive Extensions. It's async plus events as an enumerable, which should be a winning combination. If there's one subject I should really spend more time doing and less time just thinking about, it is this one. I don't like how some of the transformation functions have opaque internal state (distinct when changed), and it's all really just for loops under the covers (i.e., iterators), and some of the operands cause every result to be loaded into memory simultaneously (sorting, order by), and some of it looks like a bad SQL optimizer, but the final result looks so clean and simple that I'm left convinced that I should do it anyway.

This talk was presented well, and I wish the author the best of luck with his crazy beehives and temperature measuring circuits, whatever they were.

Side note: maybe Stephen Cleary will finally update Nito Sockets to use Rx, and then I'll be set for life. :)

Software Development Lessons Learned from Industrial Failures in the 1980s

This was the worst talk because it was entirely plagiarized from an NPR story about NUMMI. It didn't even have programming. I think that NUMMI and the Toyota Production System are very important subjects in the automotive industry, but the author of this talk spent most of her time giving out prizes and stealing photos from websites and books without attribution. It was at this time that the downsides of CodeMash became apparent to me: there are no published proceedings, so you can't cite work in the conference or hold anyone accountable for the content of their talks. The turnover in technology is so fast that trying to find the signal from the noise in the abstracts is going to be almost impossible anyway.

Oh well, I got plenty of value out of the other talks at CodeMash.

Great Galloping Cuckoos: Algorithms Faster than log(n)

I love to learn new algorithms, and this talk covered a few of them:

• https://en.wikipedia.org/wiki/Exponential_search - used when an upper bound is not known a prioiri on the array


• https://en.wikipedia.org/wiki/Interpolation_search - assumes data is uniformly distributed, O(N) worst case.


• https://en.wikipedia.org/wiki/Cuckoo_hashing - or Peacock hash - uses many hash tables, avoids buckets. I still think using a bigger table and a good hash function is better than using multiple hash functions, but obviously this conclusion is dependent on the distribution of the hash keys

This talk made me realize that the majority of programmers in the room had not gotten a CS degree in college, and they did not know the basics of analyzing algorithms in operations performed or memory usage. It worries me to think about how much code must be written without coming close to the harder topics, theoretical or practical. (Heck, I've seen lots of buggy implicit FSMs and bad network socket code, so I shouldn't be surprised.)

Cross-Platform Desktop Apps with Electron

Somehow I ended the conference back on node.js, but this time for desktop apps, not for servers. It does sound much easier to go cross platform with javascript and Chrome than with Xamarin. Too bad the GUI looks uniformly bland, much like Java desktop apps from 15 years ago. It still might be worth a shot anyway.

Closing Ceremony

Wow, this was not worthwhile at all. I should have gone home early because the odds of getting anything in the lottery were very bad (mostly because I didn't know you had to put your ticket into the lottery bowl on Friday morning, but not sooner than that, or else you couldn't win).

Final thoughts: I was pretty tired at the end, but I was glad that I went. It so rare for me to get to talk with any other programmers, let alone experts, and I easily got the value I'd hoped for out of informal discussions about SQL Broker and linq and async. Here's to next year's abstract submission going better.