JohnnyAwesome wrote:They wrote J Script in the time-span of several weekends? And he wrote that in Lisp and then rolled a C translator from scratch?
There is a reason why I could not work at Redmond and that just about summarizes it.
It's not that difficult, especially if you've done it before, like most people would have in any decent computer science graduate program.
Bearing in mind that Computer Science graduate programs didn't exist fifteen years ago, and were a one-year extention of a maths or engineering course.
Sorry for not responding to this long ago, but I just happened to want to see this video again and noticed your comment.
Computer science graduate programs existed 15 years ago. As a matter of fact, I was in one 15 years ago. While I was there, I wrote an Ada compiler and a Scheme interpreter in the span of a few weeks after taking courses in programming languages and compilers.
Why does C++ even exist? Why does MS keeps maintaining such a language that caused so many buffer overflows, and generally was not as secure as C# or Vb.NET.
The only + point for C++ is that it compiles into machine code directly, and if we can get C# to do that, then there is no need for a language like C++.
I was wondering why C++ still exists when C# is that good of a language.
MS, why not retire C++, and just focus on C# and Vb.NET and F#?
Expand C# capabilities, and get rid of P/invoke and replace it with a new kind of mechanism to call dlls outside the .NET framework.
Finally, make the .NET framework really .NET, in the sense that it is distributed in terms of processing power, by enabling sharing. So that my application could use the processor that is Idle in a second room in the the house, automatically through the use
of Remoting in LAN.
Kill C++, and lets all be on one page, with C#.
Its confusing many people, and things needs to be simpler, with few languages. C# for experts, VB.NET for beginners and intermediates.
That is all.
PS: some might say, there are programmers outthere who enjoy dealing with buffer overflows, and the pains of C++, and to them I say stick with Visual Studio 6 C++ IDE. and that is that.
This post is wrong on so many levels that it has to be a joke.
Concurrency programming enthusiasts would do well to remember
I'm really enjoying the notion of Java, C++, and C# programs being viewed as "legacy code" in the same manner that COBOL programs are viewed today. This video was worth the sheer delight from realizing how true this will become!
I have been through the VB variant type years ago and I don't want to go back to that.
They are not advocating going back to that; I recall their comments about C being a weakly typed language and how that was not a good thing. The dynamic languages that they evangelize are strongly typed.
Evemtually numbers will be repeated or skipped because of race conditions involving the ++i expression.
[For the nitpickers out there: I know that numbering n items is inherently sequential and that trying to do it in parallel is foolish. I am trying to write a simple example of code that looks like it should work because its "functional," but doesn't.]
Even though I am using ParallelFX, lambdas, LINQ, and all the other functional goo, its not a magic wand that lets me ignore the problem of shared mutable state. If I were using lisp, haskel, or another functional language it wouldn't let me do the ++i,
because they don't have mutable state at all. The success of functional languages (in which no beginning student really believes) is that you can actually write meaningful programs without it.
Then it gets worse because if the ++i were actually a function call. In functional languages, the language guarentees no mutable state. In C# I may not know if it mutates state, or it may not do so now and change in the next version. It might mutate state
only in an edge case I didn't test for. All of the sudden, my correctness depends on a sometimes very subtle implementation detail of (potentially) someone else's code.
I pointed out the flaw in the logic of somebody who innocently asked for a parallel version of a for loop in another video thread (the Parallel Fx video thread, I believe).
There are however many problems that can be solved efficiently by leveraging data parallelism, e.g., map-reduce, for which we have no really clean or concise semantics built into our current set of CLR programming languages.
It isn't so much the "functional programming" aspects of functional programming languages that solve this so much as the semantics and syntax for expressing those semantics in such a way that lends itself well to parallelism.
We'll need documented guidance to use these things wisely. You can write grossly inefficient and-or bug-ridden code in any language like SQL or C#. That doesn't make these any of these languages less than useful.
Hopefully universities are doing a better job these days of teaching the concepts of functional programming. When I was in school, I had to go to graduate school for that sort of thing. I hope computer science curriciula has improved since those days.
Is it really necessary for ES to have this functionality when you already have the likes of Premier etc out there? I would have thought that the workflow would be to edit video in an external application and then import into Expression
to be encoded?
Yes, it makes sense if Microsoft wants to compete with Adobe. Microsoft should add a non-linear video editing application to the Expression Studio suite and integrate it with the rest of the applications in the product.
As things currently are, Microsoft has a long way to go to catch up with Adobe, and there isn't a compelling enough story for designers to pick up Expression Studio. Adobe is the incumbent. Microsoft is just getting started.