Lars Kemmann

Biography

Comments

Fellow Niners, if you are at all interested in the business side of software, I highly recommend that you check out the resources on the York Group website, especially the page on "CloudControl®" - http://www.theyorkgroup.com/services/cloud_control.html. The whitepaper Why Resellers Don't Sell is eye-opening, to say the least, and very well written.

There's also a 30-minute video there on how to build a sales channel - though I expect that will likely get covered in next week's webinar.

Harald, it looks like you've partnered with the Microsoft Go-To-Market Services that are being advertised on this site - I see the York Group is mentioned as conducting channel development workshops: http://www.microsoftgotomarket.com/ I heard about this site through online word-of-mouth and I'm curious about what they are offering. Any comments? (Maybe you could address it in a future webinar... ;))

Thanks very much for showing WCAT - that's the main reason I'm downloading this. (The other, like @thiago, is to try to glean some information about the release timeframe across Azure for .NET 4.5 support, such as on Azure Services. Would it be reasonable to say that we're looking at the winter wave for that release? That would be great for my startup! Especially the fully-integrated Windows Identity Foundation.)

It would seem that Anders hates languages that aren't statically typed. ... I'm just very, very sad that Microsoft is still paying him to ruin languages for the sake of tools, when the rest of the world is embracing the ideas of dynamic languages and providing tooling for them - including Microsoft!

I see why you're concerned (even though I personally like Anders's work).

In the spirit of innovation, I like the idea of seeing where we can go by adding static typing. Bear in mind that the most rugged code in the world (silicon-layer logic) is extremely statically typed. There's a place for that, and in a world increasingly reliant on HTML for cross-platform client applications, we're going to see more and more apps requiring the level of ruggedness and static guarantees (as opposed to the Web 2.0 mantra of fail-fast iteration) that only these techniques can provide.

So I'm going to wait and see. But Microsoft definitely needs to acknowledge - up-front - the pioneers in this field (especially those outside of Redmond).

The last enterprise I worked at was rapidly adopting CoffeeScript, for example; if MS starts to preach TypeScript as the One True Way then they're going to get some unexpected backlash. If, instead, Anders acknowledges that this is an experiment and that there are going to be changes in the process of developing open standards (possibly even including the abandoning of TypeScript once it's served its purpose) then people are going to have a much warmer response. It's harder to convince us that our investment won't be a wasted one, but ultimately it's the more honest path and would lead to a better outcome for everyone.

Put another way, you (Anders) need to explain why this doesn't belong in DevLabs.

The question that Microsoft (looking at you, Anders ) needs to be addressing is why we need yet another JS+x language that compiles down to JS. I'm all for innovation, and I hope that we end up with multiple usable flavors of programming languages for HTMLvNext clients. But languages need to show clear advantages if they're going to be adopted by the mainstream - so what sets this apart from CoffeeScript, Dart, etc.?

Another way to phrase the question: is it your intention to make TypeScript into a mainstream language, or to help merge the best traits of TS, CS, etc. into a new standard language down the road? In the former case, you'll need to explain why you're not effectively fighting against the CoffeeScript community (to impose the One Microsoft Way). In the latter case, you'll need to explain why early adopters of TypeScript can take the risk that they'll need to do some significant rewriting down the road once "ECMATypedScript" is approved (or once these typing features make it into ECMAScript).

@RockfordLhotka: Thanks for responding! I wasn't aware of the impersonation/culture flow - it's nice to have that, especially since the average developer (me) wouldn't have thought of that (getting to your point about the value of frameworks). Although, again, I could make an argument for using an interface with an optional abstract base class to help out those who are providing CSLA "adapters" to various persistence locations/schemes... Anyways, I think the most recent version of CSLA that I used was around 3.6-ish, so I'm definitely behind the times somewhat.

I've been a Rocky & CSLA fan ever since I read his book on VB6 Business Objects. While my current projects don't lend themselves to that framework (different architectural paradigms), I've learned a lot from CSLA and my use of it in the past. (Though I never did like its DataPortal implementation of a facade over the data access layer, it always seemed like a hack to not just map CRUD operations directly to an interface... And CSLA's properties could be much, much nicer with metaprogramming facilities available like in C++...)

Where can I get the cool Magenic wallpaper with the Technical Relevance chart? Looks like a great orientation tool.

From my point of view, there are now two main reasons left that keep me from "going native" with my software (Herb Sutter is right on with this):

1. Components. .NET is, as Juval Lowy likes to say, the "component-oriented framework" that superseded COM. In C++, today, there would be a huge barrier to cross (at least that's the impression I get) if I wanted to support third-party extensions (and I *have* to).

2. Libraries. The asynchrony/concurrency work from MS is fantastic, but more often I need to do "basic" - and standardized! - things like XML, JSON, HTTP, TCP/IP, etc. (Oh, and C++ XAML would be nice to have on Win7 as well. )

For those of us who are in a situation like this, what would you recommend? Keep working in .NET (or Ruby, or whatever) for another year or two and start (re-)learning C++ on the side? Or try to make the switch now? If the latter, then could you provide some guidance for how to deal with these issues? Maybe create a "living" document that provides C++ equivalents/recommendations for each of the classes available in the .NET Framework? That would be a great MVP-esque contribution