Mike Flasko and Anthony Jones: Winsock and .NET Protocol Agnostic Development

jsampsonPC wrote:Charles, why didn't you take advantage of Roundtable for this interview?I just started watching...and this lineup looks like it's potentially one of the coolest interviews in a long time
footballism wrote:
Dummy wrote:How much did Anders get for plugging the TalkingRain Beverage Company?
How many of you have experiene with functional programming? What do you think about the trend towards a comingling of imperative and functional?
C
I'm so thrilled you that enjoyed this! I know I did. You can bet that we will be talking with these innovators again. Consider this an introduction (teaser). When they are able to discuss specifics (of course they are not ready to disclose publicly at this time the amazing work they are doing today to make programming tomorrow a real treat for us all) you will be the first to know; right here on Channel 9!
Keep on coding,
C
sylvan wrote:This really fills me with hope for the future. I've been quite concerned that MS was completely missing the boat with what we need for the future, and I still think they're a bit late on the ball here, but at least it seems like all the head honchos understand that functional programming is the only direction we can move in if we are to have any hope of effectively programming for tomorrow's machines.
I think we're kind of late to the party on the sofware side though. The hardware is already here, and we don't know how to use it yet. We should've been better at predicting this "crisis" and moved to FP much sooner.
Very interesting video Charles! It really fills me with hope for the future.
staceyw wrote:Great video guys!
I say yes we need better concurrency abstractions for sure. But until then, we will still need tooling, static analysis, and runtime analysis to help me answer the following:
1) Do I really need a lock here? Might an interlocked or something else be better. Maybe no lock is even needed in some cases - why or why not?
2) How many times am I taking this lock? How hot is it? Am I needlessly taking it multiple times? Should I refactor with finer grain locking or would that just add more overhead? Tool should help me discover this easily and help me refactor.
3) Where am I at risk of dead-lock or live-lock?
4) We need a way to gaureentee a method (or property) is always called in a locked context. Likewise I may want a gaureentee a lock is not held when a certain method is called. A set of invariants could also have such compile and runtime debug checks. Attributes would seem reasonable here. This would seem easy for the computer to do for me, but hard to do manually as programs get complex.
5) Runtime collection performance analysis. Should I be using a linked list here or a List<T>. What would be the projected pros or cons using this or that?
6) Should I be using a closure here or a plain delegate and method. I should be able to know the cost easily.
7) Need easy dynamic code for user level changes to behavior:
RunThis(true,
delegate(string s)
{
x = x + 1; // may what dynamic change
}
);
Why is it so hard just to replace 1 line with something else at runtime? All I really want to do is allow user to plug-in "x = x +5". But today, they need to write and compile a dll, I need to figure out how to load the assembly and find right namespace and call a delegate and somehow get versioning correct, etc, etc. I may also want this in a sandbox, with certain things the user code and do and not do.
Charles wrote:How many of you have experiene with functional programming? What do you think about the trend towards a comingling of imperative and functional?
Charles wrote:How many of you have experiene with functional programming? What do you think about the trend towards a comingling of imperative and functional?
foo xref yref = do
x <- readSTRef xref -- extract the value from reference
y <- readSTRef yref
return (x+y)
-- here we "run" the imperative function above with "runST"
-- ensuring statically that no side effects "leak"
fooPurified x y = runST ( do
xref <- newSTRef 5
yref <- newSTRef 8
foo xref yref
)
-- two versins without imperative features
fooPure1 x y = x+y
fooPure2 = (+)
(btw, note the "but it looks like a dynamically typed language"-effect above, though it is all 100% strongly typed)
Now, clearly the first version is not as elegant as the following two versions. But there is no reason for why the language couldn't have a more convenient
built in syntax for doing all this with a C-ish look and feel. The "assembly" like programming style that you must use to do mutable state in purely functional languages is syntactical. There is no reason for why a C-like version of the function above
couldn't insert the "readSTRef" style commands automatically with some translation rules (I'm handwaving the details here).
SEP2007 wrote:Declarative languages learn and use 18 - 28 year old.
Funcutional Languages learn and use 35 - 55 years old.
The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the world-wide availability of skilled engineers, courses and third party vendors. The popular search engines Google, MSN, and Yahoo! are used to calculate the ratings. Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system. The definition of the TIOBE index can be found here.
Position Jan 2007 |
Position Jan 2006 |
Delta in Position | Programming Language | Ratings Jan 2007 |
Delta Jan 2006 |
Status |
---|---|---|---|---|---|---|
1 | 1 | ![]() |
Java | 19.160% | -3.10% | A |
2 | 2 | ![]() |
C | 15.807% | -3.20% | A |
3 | 3 | ![]() |
C++ | 10.425% | -1.04% | A |
4 | 5 | ![]() |
(Visual) Basic | 9.123% | +0.03% | A |
5 | 4 | ![]() |
PHP | 7.943% | -1.46% | A |
6 | 6 | ![]() |
Perl | 6.237% | -0.81% | A |
7 | 7 | ![]() |
C# | 3.521% | -0.03% | A |
8 | 8 | ![]() |
Python | 3.502% | +0.90% | A |
9 | 10 | ![]() |
JavaScript | 2.845% | +1.31% | A |
10 | 21 | 11 * ![]() |
Ruby | 2.519% | +2.15% | A |
11 | 11 | ![]() |
SAS | 2.343% | +1.18% | A |
12 | 9 | ![]() ![]() ![]() |
Delphi | 2.336% | +0.75% | A |
13 | 12 | ![]() |
PL/SQL | 1.570% | +0.54% | A |
14 | 22 | 8 * ![]() |
D | 1.335% | +0.97% | A- |
15 | 20 | ![]() ![]() ![]() ![]() ![]() |
ABAP | 1.229% | +0.82% | A- |
16 | 14 | ![]() ![]() |
Lisp/Scheme | 0.674% | +0.07% | B |
17 | 18 | ![]() |
Ada | 0.638% | +0.17% | B |
18 | 13 | ![]() ![]() ![]() ![]() ![]() |
COBOL | 0.637% | -0.13% | B |
19 | 15 | ![]() ![]() ![]() ![]() |
Pascal | 0.570% | +0.04% | B |
20 | 34 | 14 * ![]() |
Transact-SQL | 0.510% | +0.34% | B |
The long term trends for the first 10 programming languages can be found in the line diagram below.
The long term trends for the first 10 programming languages can be found in the line diagram below.
[/quote]
What was it that happened in 2004?
Charles wrote:How many of you have experiene with functional programming? What do you think about the trend towards a comingling of imperative and functional?
C