Coffeehouse Thread

69 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

is managed code faster than native?

Back to Forum: Coffeehouse
  • User profile image
    Bass

    Also the thing about obscure languages, it shows how you can do dynamic languages right. Erlang's primary weakness is that it decided to copy the syntax of Prolog. That makes it very unapproachable for beginners.

    You have language like Ruby which isn't that obscure at all and have beautiful syntax. I mean, it's all over the place these days, especially for new development. It has a much better syntax than Erlang and it's also very strongly typed. Ditto for Python. Very well designed languages, with unfortunately, very slow runtimes. That makes them useless for some things, which is incredibly unfortunate.

    Then you have JS which is less pretty, but people have made it pretty via CoffeeScript. But JS is very fast, much faster than any dynamic language ever was because some people had the smart idea of trying to speed up a dynamic language for what seems to be the first real attempt.

    At some point you will have the niceness of Ruby and Python, the robustness of Erlang, and the speed of JavaScript merge. That will be the language of the future.

  • User profile image
    Bass

    @evildictaitor:

    I see no major difference between loading a library and eval, other than working with different languages. You are in fact, adding code to your process both ways, it just happens to that one is machine code. It's still code.

  • User profile image
    evildictait​or

    , Bass wrote

    Also the thing about obscure languages, it shows how you can do dynamic languages right. Erlang's primary weakness is that it decided to copy the syntax of Prolog. That makes it very unapproachable for beginners.

    You have language like Ruby which isn't that obscure at all and have syntax that read almost like poetry. I mean, it's all over the place these days, especially for new development. It has a much better syntax than Erlang and it's also very strongly typed. Ditto for Python. Very well designed languages, with unfortunately, very slow runtimes. That makes them useless for some things, which is incredibly unfortunate.

    Then you have JS which is less pretty, but people have made it pretty via CoffeeScript. But JS is very fast, much faster than any dynamic language ever was.

    At some point you will have the niceness of Ruby and Python, the robustness of Erlang, and the speed of JavaScript merge. That will be the language of the future.

    You say that, but then you accuse statically typed languages of being equivilent to the dreadful languages of C++ and Java, missing out the elegance and simplicity of Haskell.

    I'm not arguing against dynamic languages because I think that PHP is dreadful (it really, really is, by the way) or because I think that C++ and Java are the language that God himself would use (he really, really wouldn't). I'm arguing it because I feel that building unit-tests into the language via formalized contracts is the only way to get people to write them at all, and unit tests are the difference between good and bad code.

    Forcing crappy developers to write unit tests, and getting the compiler to immediately abort and tell them when they do stuff wrong is critical to maintaining a healthy codebase. And making it easy for developers to see where semantics have changed slightly when refactoring their code to make refactoring easy rather than painful is cruicial to building systems that are effective.

    Static types are a way of saying that writing unit tests is part of writing code. Too many people think that unit tests are optional or are something that we need a full time "tester" to write. Contracts and types let you find typos immediately, make code more immediately obvious when reading and easier to algebraically prove correctness for.

    That's why I like static languages, and that's why I feel that going from C# to Spec# is a positive thing, and going to PHP from C#/ASP.NET is a backwards thing.

  • User profile image
    evildictait​or

    , Bass wrote

    @evildictaitor:

    I see no major difference between loading a library and eval, other than working with different languages. You are in fact, adding code to your process both ways, it just happens to that one is machine code. It's still code.

    It is not code that is highly coupled to runtime data. That's the difference.

  • User profile image
    Bass

    @evildictaitor:

    I can go ahead and put the PHP runtime in there and execute PHP and eval PHP code right in. Ha ha. How's about that for inception.

  • User profile image
    Bass

    @evildictaitor:

    In a strongly typed dynamic language. Again I don't see how changing a type1 to a type2 is going to cause anything other than a type mismatch exception or even a compile-time error unless type1 and type2 are both ducks. The whole "unit test" argument is totally bogus. Static types are not helping you at all! Strong types are. You aren't get type safety from static languages. You are just getting more complicated code.

    Duck typing is basically doing the work of adding interfaces to your code so you don't have to think about it. That's all. You can implement it in static languages with a *-ton of interfaces, something like n! interfaces where n is the number of methods/properties. That would be ugly (esp for big classes), but it's doable. Some "pretty OO" designs seem to approach that, with their interface soup. See Android SDK. In what planet is that preferable to duck typing?

  • User profile image
    evildictait​or

    , Bass wrote

    @evildictaitor:

    I can go ahead and put the PHP runtime in there and execute PHP and eval PHP code right in. Ha ha. How's about that for inception.

    I can get your PHP runtime to run an x86 emulator to bootstrap my static language. Ha ha. How's that for making PHP usable and safe?

  • User profile image
    Bass

    So it's like the same thing. Duh. That's what I've been saying.

  • User profile image
    evildictait​or

    , Bass wrote

    @evildictaitor:

    In a strongly typed dynamic language. Again I don't see how changing a type1 to a type2 is going to cause anything other than a type mismatch exception or even a compile-time error unless type1 and type2 are both ducks.

    Because all primitive types duck-type to each other by default. An int is a double is a string is an array is an object.

    Duck typing is basically doing the work of adding interfaces to your code so you don't have to think about it. That's all. You can implement it in static languages with a *-ton of interfaces,

    Duck-typing can be done automatically by an IDE and can be built into a language. Duck-typing is not a feature of or the sole preserve of dynamic languages. Stop quoting it as such.

  • User profile image
    evildictait​or

    , Bass wrote

    So it's like the same thing. Duh. That's what I've been saying.

    I said it several pages ago (http://channel9.msdn.com/Forums/Coffeehouse/is-managed-code-faster-than-native/b464676c754e491eb779a13e0156ce84). The fact that both are turning complete doesn't mean that they are equally good languages. It just means they are equally powerful languages.

    Do keep up.

  • User profile image
    Bass

    evildictait​or wrote

    *snip*

    Because all primitive types duck-type to each other by default. An int is a double is a string is an array is an object.

    Nope. If you are only using weakly typed languages you will have a very distorted view.

    irb(main):001:0> x = 5

    => 5

    irb(main):002:0> x.length

    NoMethodError: undefined method `length' for 5:Fixnum from (irb):2 from /usr/bin/irb:12:in `'

    irb(main):003:0> x = "Foo"

    => "Foo"

    irb(main):004:0> x.length

    => 3

     

  • User profile image
    evildictait​or

    It's kind of Ruby to helpfully report the typo of 5 instead of "5" only when you manage to generate a test case that exactly goes through that chain, rather than just telling you that you did a typo up front. Your customer also gets to appreciate the benefits of dynamic languages when he can't get his work done because of your "500 server error" caused by the error being detected only when he tries it.

    In C# my compiler didn't let me deploy your broken code. Therefore there was never a NoMethodError thrown when my customer visited my webpage.

    Result: I sleep easier and my customers are more happy.

    Yay for statically typed languages.

  • User profile image
    Bass

    , evildictait​or wrote

    It's kind of Ruby to helpfully report the typo of 5 instead of "5" only when you manage to generate a test case that exactly goes through that chain, rather than just telling you that you did a typo up front. Your customer also gets to appreciate the benefits of dynamic languages when he can't get his work done because of your "500 server error" caused by the error being detected only when he tries it.

    In C# my compiler didn't let me deploy your broken code. Therefore there was never a NoMethodError thrown when my customer visited my webpage.

    Result: I sleep easier and my customers are more happy.

    Yay for statically typed languages.

    My point is that your statement was wrong. Not 20% wrong, not 90% wrong. 100% wrong. So maybe try to be a little more accurate in your criticisms next time.

    Yeah sure, the magic of C#'s compiler catches bugs before you deploy. So you're saying with C#, I'd never have need a static verification tool like Ruby/JSLint, because the compiler is just that awesome. Okay.

    System Error

    Wow, that shouldn't have happened

    We're sorry. Something has gone terribly wrong.

    If you would like to let us know about this, please Contact Us and let us know what happened.

    Reference:

    Well you should tell Channel9 team that because I keep getting this like 20 times in this thread so far via their superior C# codebase. To be fair this is the only website I regularly visit written in C# (they are hard to come by, with bigger ones like MySpace failing and all despite using happy customer C# code), so the sample size is small. But it doesn't sell the compiler anti-bug technology to me very well.

    Ruby OR C#, hopefully you have integration/unit tests that do more than load your page or something. Hopefully you are using a static verification tool (!= compiler), code coverage tool and a tool to run your unit tests BEFORE you deploy (realistically, BEFORE you check in). None of this is ever optional in the real world(tm)!

    But really, if you want code contracts, use code contracts (in Ruby even!). Don't try to pass type decorations like they are code contracts.

    Anyway the point of this conversation for me was to try and see if I can learn anything new or interesting about static languages. Something to objectively show that static languages are superior. That WOULD be interesting. But it's not really working. All I am getting in a genuine confusion about the difference between weakly typed and dynamic typed. So uh, good luck.

  • User profile image
    Ion Todirel

    @Bass:Can you point to a dynamically typed native language out there? Note, dynamically typed, not dynamic.

  • User profile image
    evildictait​or

    The bit that annoys me about this type of discussion is that most dynamic languages give you less flexibility and choice than statically typed languages to do what you want.

    In C#, for instance, if you want values rather than variable-sites to have types, use the "object" keyword, or just use an interface:

    object Add(object a, object b)
    {
      return a.GetType().Invoke("op_add", a, b);
    }

    If you do that Add(1, 2) and Add("cat", "dog") will now work without complaining at you. If you write Add(new object(), "string") you'll end up with a runtime error, not a compile time one.

    So the thing is that you can program dynamically in most static languages. What you can't do is program statically in dynamic languages. Yes, you can add code to test for types like this in PHP:

    function add($var1, $var2) { assert(isint($var1)); assert(isint($var2)); }

    but if you do that you still don't get a compile time or immediate IDE feedback when you write add("2", "3") - meaning that it makes the time between when you make a silly mistake and when you have an opportunity to fix it longer. It also ups the barrier to refactoring your code, since when you change internal stuff it's now much harder to quickly see where the error was caused because errors can now happen further from your typo.

    The static versus dynamic debate is a debate about choice, and a debate about whether some forms of basic error checking (which is itself a rudimentary form of unit testing) is a first-class citizen in the language. In Spec# they take this further and build proper unit tests with algebraic solvers into the language - to the improvement rather than to the detriment of programmer productivity, because in Spec# the cost of writing unit tests shrinks yet further to just those tests that are too complex to write as requires/ensures contracts.

    Dynamically typed languages pull the other way. They say that variable sites shouldn't be able to "ensure" or "require" features of the thing that sits inside them. This means that a greater burden is put on the compiler to infer the type and ensure type-safety internally (assuming the langauge is even compiled - most are interpreted, taking a double hit on speed).

    Increasingly C# is giving you the most flexibility of all of the languages to program how you like. Use imperative programming if you want, or functional programming if you prefer. Use compiler-based assertions to pick up common typos and logic errors, and have a dynamic keyword for when it's useful.

    Indeed, with Spec#, you can bring more of your testing into your code - making it possible for your compilation to "know" that you've tested for and proved that certain code paths can't take place - and since in real life hardly anyone unit tests their code, this is a way of bringing testing to normal developers, and stopping testing from being "the thing you do get someone else to do just before you launch the product"..

    The future of languages is having static types where possible and dynamic types for the few times when it's actually needed.

    http://research.microsoft.com/en-us/um/people/emeijer/Papers/RDL04Meijer.pdf

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.