Skip to main content
12 events
when toggle format whatbylicensecomment
Jun 17, 2016 at 7:40commentadded sara "Monad" isn't even a "type" that you create and then use in different ways. A type can have monadic structure. In haskell you can "prove" this to the compiler by implementing a type class instance, but the structure is still there even if you won't write out the word. Saying that a language "doesn't have monads" just because it doesn't have special syntax/compiler support is like saying C# doesn't have numbers because there's no INumber interface that all numeric types inherit from. C# has numbers because there are types that behave like numbers, not becuase they are named after integers.
Jul 1, 2014 at 7:17commentadded DarkWanderer I would not agree that a check which prevents your banking application from crashing because of attempt to assign string to int is an "artificial complexity"
Jun 28, 2014 at 16:48commentadded Jedai Only someone that really doesn't know what he's talking about would use monads as an example of complexity forced on static typing languages... The fact that they were only there in Haskell but have since been introduced (under miscellaneous names) in other languages should clearly show you that monads are a powerful tool that helps to tame complexity in programs. Monads are perfectly appropriate to be used in dynamic languages by the way, though those won't be able to enforce their use for certain tasks thus losing a part of their power.
Jan 28, 2014 at 15:49commentadded Thiago Silva @TikhonJelvis (and KarlDamgaardAsmussen), I regret putting monads as an example, as I'm not experienced enough to evaluate it in depth. Now, while norvig's has little to say to the "better languages", it shows an extreme practice of what I think is still present in statically checked languages of today: a tension that forces one to add artificialities to the design and/or face maintenance nightmares. ADT, for instance, has a strong foundation and present us with some open questions (and while they're open, we have to work around them). So does statically checking exceptions, etc.
Jan 27, 2014 at 21:51commentadded Tikhon Jelvis @ThiagoSilva: Monads are not an example of complexity per se. Many people find them hard to learn, but as abstractions go they are quite simple--the difficulty is that they are also quite abstract. In fact, monads often simplify a design by making it more explicit: they just highlight things which are magical and unacknowledged in other languages. And Norvig's design-pattern article is not relevant to statically typed functional languages at all; it's not a comment about static typing in general but rather about Java-style type systems (which we can all agree are a mess).
Dec 20, 2013 at 17:53commentadded Kile Kasmir Asmussen @ThiagoSilva Granted, monads in haskell are a tough concept to grok; but for a softer language like Ocaml, the comment still holds. And you do not have to make your own monads in Haskell, you can use them without much knowledge of their inner workings (same with signatures/structures/functors in Ocaml). Also, every single design patter is meaningless in functional languages in general.
Dec 17, 2013 at 16:24commentadded Thiago Silva "Others think that this restricts their creative expressivity, slows down development ..." -- I would add "introduces artificial complexity into the design" to the list. Two strong examples of different kinds of complexity that a "static typed" language can force you to cope with is (a) monads as present in Haskell; and (b) Peter Norvig showing that 16 of 23 patterns of the design patterns of that popular book are "invisible" or simpler in "dynamic typed" languages whereas in other languages they are mostly bloat working around static checking limitations: norvig.com/design-patterns
Dec 17, 2013 at 16:10commentadded Kile Kasmir Asmussen I'd like to add that there is a hell of a difference between the types in Java (which allow easy and dangerous cast-to-Object violations of the type system) and Haskell (which requires on average one explicit type signature per five or six functions, the rest is inferred, but will spank you if you try anything funny).
Dec 17, 2013 at 15:49commentadded Eric Lippert The word you're looking for is static typing. Statically typed languages can be strict or lax, they can be strong or weak, they can be mandatory or optional, and they can be explicit or implicit, but what they all have in common is that types are facts that can be deduced from the text of the program without actually running it. "Dynamic" languages are so called because facts about the program can sometimes not be known until the program is actually running.
Dec 17, 2013 at 15:15commentadded Brian S "This is why... arguing which language is better are silly" -- amen!
Dec 17, 2013 at 11:24commentadded Neil Both restrictive languages and non-restrictive languages have their high and low points, I suppose. However in my experience, having more degrees of freedom is like programming in assembly in that you can do everything, but it is difficult to do any complex programs. Nice answer.
Dec 17, 2013 at 10:22history answered Kilian FothCC BY-SA 3.0
close