4 ms·

Can someone explain to me, why would a programmer want to develop a web application using an ML-derivative (e.g. F#) instead of Ruby/JavaScript/PHP or Python?

• mercurial 12y ago
  > Why does a statically typed langauge need "type inference" let suffix str = str ^ "mysuffix";; val suffix : bytes -> bytes = <fun> Type inference in action: the OCaml toplevel displays the type of the 'suffix' function as something that takes a value of type bytes and returns a value of type bytes, without any type declaration (though obviously, the type inference system works in much more complex cases as well). You can write entire programs without a single type declaration. Dynamic languages do not do type inference. They do duck-typing. The big difference is that OCaml will not let you write a program like: let suffixed_five = suffix 5 You will get: Error: This expression has type int but an expression was expected of type bytes Python will not let you concatenate integers and strings, either, but will blow up at runtime.
  • brudgers 12y ago
    Some dynamic languages, notably Ruby, use duck typing. Many tag all values with types, Lisps are an example. Tagged types allows a dynamic language to be strongly typed [dynamic/static is orthogonal to strong/weak typing, C being an example of weak static typing]. Type inference is syntactic sugar in most languages that allow it, and explicit type declaration is [almost?] invariably permitted. Of course, the price of omitting type declarations in code is the potential loss of clarity that comes anytime implicit communication is used in lieu of explicit statements of intent.
  • Jtsummers 12y ago
    A nit: Dynamically typed languages do not all use duck-typing. Duck-typing is primarily concerned with the question: Does this object respond to this message/method or have this field? If the answer is yes, then we'll act as though it's whatever type we needed it to be. So duck has a quack() method and decoy_duck has a quack() method. decoy_duck is not, in fact, a duck, but it has enough of the duck behavior for what we need.
• ufo 12y ago
  Static typing helps catch bugs and code refactoring. For example, if you add a parameter to a function in ML the compiler will point out for you all the call sites that need to be updated to the new API. The compiler will also be smart enough to notice the times when your function is called via aliases, which is something you can't do via textual find-and-replace. The need for type inference is because in languages with more advanced type systems like ML it would be very annoying if you had to write down the types for everything by hand with no assistance from the compiler. > As I understand this - I'm probably wrong but - dynamically type == type inference. No, this is only a common misconception. The better analogy is "dynamically typed" == "everything belongs to a single type". In Python every value has a type of "object" and can be passed to anywhere you want. The interpreter adds tags to the memory representation of the objects so it knows what to do with them and it raises a runtime error if you try to use a value in the wrong place (for example, when you try to call a method on None). On the other hand, in a language with a sound type system you have a guarantee that there will never be type errors at runtime ("well typed programs do not go wrong"). The type checker enforces that different types never get mixed together, which also removes the need for runtime tags in the memory representation.
  • atmosx 12y ago
    Thanks for the comprehensive answer!
• brudgers 12y ago
  There are of course the ordinary people do what they do reasons: familiarity with the language, consistency within a project, opinion and deep insight into the problem and dumb mistakes. Static typing offers some advantages in regard to tooling. Entire classes of errors can be caught by the editor/IDE as the programmer types code without waiting for compile time...or in the case of dynamic languages perhaps runtime. ML languages are particularly suited for the classes of problems for which they were developed, e.g. fault tolerant high reliability systems, because they can efficiently express state machines via pattern matching semantics and the SOME|NONE construct. So a person might choose to write a web application in F# because they are thinking about the problem in terms of a state machine. With code generation, a stack similar to Microsoft's can provide a lot of the Presentation and Storage layers in Javascript and SQL respectively.
  • atmosx 12y ago
    Nice, thanks! :-)
  • jallmann 12y ago
    > ML languages are particularly suited for the classes of problems for which they were developed, e.g. fault tolerant high reliability systems Are you thinking of Erlang? Erlang is definitely not a ML, although they share some similarities (immutability, pattern matching). Not sure what ML originally was designed for, other than maybe building compilers. > So a person might choose to write a web application in F# because they are thinking about the problem in terms of a state machine Algebraic data types in ML allow you to encode program state within the type system, so the compiler can help ensure the program is in a consistent state at any point during run-time. That is the real benefit to having a strongly static type system in the vein of ML. Regarding the original question: the difference between static and dynamic types is, IMO, one of checking at compile-time vs run-time. (But the static/dynamic definition is fuzzy enough that there's often leeway for interpretation here.) Type inference is icing on the cake -- type annotations could be explicit (C, Java) or implicit (ML), but a language is not statically typed unless the types are known prior to execution.
    • 12y ago
• dragonwriter 12y ago
  > Except from a totally different programming paradigm what do ML-derivateves have to offer? The programming paradigm is itself a reason. > Also the author states that ML is "statically typed", "type inference"... Why does a statically typed langauge need "type inference"? Static typing provides aspects that are statically known to be correct without testing, type inference allows the benefits of static typing without the type-related boilerplate/overhead of, e.g., Java. > As I understand this - I'm probably wrong but - dynamically type == type inference. Dynamic typing is not the same thing as type inference. Dynamic typing provides the low boilerplate that static typing with type inference provides but without the safety that static typing (with or without inference) provides.