> Overall it is a higher-level language, whereas C is designed for maximum performance.
I agree with most of your points, but on this I think you are comparing apples to oranges. C is not designed for maximum performance, but as a system language and as such only as slim abstraction over assembler. As a side effect it allows for maximum performance. A more fair comparison (pretty much every widely used language is easier to use than C) would be C++ vs. Python, where in C++ most - if not all - of the higher level abstractions were explicitly designed not to worsen performance compared to low level code. And in my opinion Python is so much easier to use than C++ because it values simplicity and consistency more than efficiency.
For example the general loop constructions in Python which are possible because of nice generators and the wonderfully straightforward `yield` construction are unacceptable in C++ as they lack the flexibility to be as efficient as possible in every case.
The advantage of dynamic typing only becomes apparent in a third argumentative step; when you try build a language with consistent and efficient abstraction and you end up with something like Haskell whose type system complexity is huge entry barrier. That's why I think dynamic typing is good for Python.
I'd argue that Haskell actually has a pedagogy problem, because many of its proponents are academics or mathematicians, who are comfortable with that kind of language. Talking about monads, functors, and arrows is a very natural activity for them, and clarifies rather than complicates the subject. However, you don't really have to understand any of that to get started in Haskell, and much of the blogging community has (I think wrongly) focused on explaining advanced concepts rather than making easy introductions.
You don't have to deal with monads any more than you have to deal with Python's OO behavior - which is to say, for quite a while.
I'd also argue that once you take in to account the sometime strange OO implementation of Python, and that Haskell has type inference for most things, Haskell is easier to understand the high level concepts in. Typeclasses and higher order functions (functions which act on functions) provide a very neat way to substitute in different types to your algorithm without having to change the whole thing, and don't even delve in to the complicated world of functors and monads.
I would like to make two notes about this:
- Most of the Haskell tutorial examples are about computing pi, fibs, and other math functions or series. Which is fine, but rather obvious beyond the recursion vs iteration bit. It's not just that newcomers arrive to Haskell with an imperative mindset, it's that they (we?) come with imperative (stateful) algorithms, which of course turn out to be a nightmare to implement.
- I found those explanations about Monads, etc necessary because as soon as I wanted to do anything less obvious than calculating a function or series, it was pretty hard to figure out how to get it done. For example, adding print logs to my code to debug, or building the code to output the formatted result of my program. "Why can't I use map here?" "What is is this mapM thing?" are very real roadblocks.
Those problems are not unique to Haskell, of course, but Haskell's purity makes it much more inflexible - you can't do some part the Haskell way to learn the ropes while you do the rest imperatively to get actual, satisfying results.
main = do
putStrLn "Hello, what's your name?"
name <- getLine
putStrLn ("Hey " ++ name ++ ", you rock!")
Btw. I am a mathematician and the only time I ever had contact with category theory was in a seminar presentation. The great majority of students at our university would be as new to functors as most of you.
But on the other hand the reason I am fascinated by Haskell are all these advanced methodologies that promise to make the act of solving a problem more manageable. To contrast that against the Python/C comparison I find that Python gets less in my way (probably even less than any other programming language I've tried) but hasn't taught me concepts that I didn't already know from C++/Java/…
So the question would be: If you don't want to learn about Monads, why would you come to Haskell in the first place?
OTOH I've never seen any mathematician use (perhaps with the exception of myself, depending on at what point you start counting a person as "mathematician" and at what point you consider someone to be "using haskell") haskell. I doubt the haskell community actually has any mathematicians, it's mostly just people who'd like to be mathematicians but are too lazy to get a degree.
The overlap of mathematicians who care about category theory (some logicians, algebraic geometrists, algebraic topologists, ...) and mathematicians who program (mostly mathematicians from applied disciplines, numerical methods, computational physics, ...) is pretty much zero.
You probably won't find your algebraic topology professor programming in any language anytimes soon, except LaTeX.
Well, unless perhaps s/he has some involvement in a project like this one http://comptop.stanford.edu/ ("The overall goal of this project is to develop flexible topological methods which will allow the analysis of data which is difficult to analyze using classical linear methods"; first named person in left sidebar is an algebraic topologist).
Or this one http://www.esf.org/index.php?id=8764 ("Applied and Computational Algebraic Topology"; first named person on steering committee is an algebraic topologist).
Or this one http://munkres.us.es:8080/groups/catam/ ("Computational Applied Topology and Applied Mathematics"; directory is an algebraic topologist).
Or, turning away from algebraic topology as such to mathematics inspired by algebraic topology and involving both category theory and programming: http://homotopytypetheory.org/ ("... new program for a comprehensive, computational foundation for mathematics based on the homotopical interpretation of type theory. [...] currently being implemented with the help of the automated proof assistant Coq"; note that in practice doing nontrivial things in Coq is a matter of functional programming).
For sure there are plenty of mathematicians (in algebraic topology and elsewhere) who don't program, but I think the intersection between people interested in categories and people interesting in programming is bigger than you suggest.
I don't know how many of them are using Haskell, though.
If you go to your average mathematics department and ask a few professors there that work in logic, algtop or alggeom, I doubt you'll find any that do any programming for their research. You probably won't find that many logicians that use proof-assistants either, although those are probably the least niche category of the things listed (and they are fairly popular with the CS folks)
For sure. Then you get a compiler error.
Programming Haskell without understand the type system and lambda calculus is not possible.
Edit: thanks for downvoting me. If you believe that you can program Haskell without understanding the basics of Functional Programming and without understanding the type system, then you live in an alternate reality or want to evangelize Haskell.
λx. x (λf y.y f (f 1) ) (λx1 f x.f (x1 f x))
λx y f x.(x f) (y f x)
Even the type system - you need to understand some tiny amount - you can only add ints to ints etc. The more complicated stuff, the type inference, the monads etc - can be ignored until later.
Haskell can be used without understanding - almost all programming languages can. That's why we have so many newbie bugs.
Let's look at a few chapter titles of Real World Haskell.
Chapter 2: Types and Functions
Chapter 3: Defining types, streamlining functions
Chapter 4: Functional Programming
Chapter 6: Using Typeclasses
Chapter 14: Monads
Chapter 15: Programming with Monads
Chapter 18: Monad transformers
I think the biggest issue is with those developers that never got a degree or were unfortunate to land in a degree that taught programming languages instead of programming concepts.
Haskell borrows concepts from category theory (a "field" so abstract from most math that most mathematicians don't need but a handful of its concepts) to label typeclasses, and those typeclasses don't always follow from their namesake.
Further, Haskell could exist and keep its property of referential transparency without the the 'mathematical' structures or their names. Here's a version of Haskell without monads: http://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-s...
Monads, functors, arrows, etc. are more aesthetic than fundamental to the core nature of Haskell. They're just a bookish (and sometimes bureaucratic, IMO) design choice. What I mean by that, is that the language designers took a concept (referential transparency) and built an understandable structure, but beside and aside from this, made a bunch of nested, derived typeclasses of dubious value or purpose. Sometimes I look at a Haskell library and have a more academic version of the, "Why the fuck is this a class?" moment.
I'd like to comment tangentially that Haskell is almost the OOP/Java of the 2010's - the programming community claims that it makes your code "safer", and in some sense it very much does, but its features are being perverted and overhyped while its caveats are being forgotten.
I very rarely change the type of a variable, so it would be essentially free speed and free speeds for me.
I actually wonder, do people use dynamic typing so often? I mean, it's nice to do "variable = int(variable)" when I know that I'm getting an integer in a string, but that's probably the only use case can I can think off that doesn't just reuse variables for something else.
Here are a few from Guido himself (not really anti static-typing, but just walking you through pros/cons as he sees them). Great reads:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
Can someone give me a concrete example of when static typing would be beneficial? (The majority of my work revolves around databases, so I guess I rely on that as a kind of type checking to a degree).
On the other hand, the Haskell typing is superior in many ways to dynamic typing. Because you lose very few power of expression but you gain a lot of time in your workflow (and also security).
Concrete example (I'll use js):
function showField(data) {
console.log(data.field1.filed2);
}
Static typing:
showField : ConcreteData -> IO ()
showField data = putStrLn $ filed2 (field1 data)
correct your code. Now you're done.
Here is another example:
Dynamic typing:
function showField(data) {
if (data.field) { console.log("OK"); }
else { console.log("Not OK")}
}
...
showField(myData);
In static typing:
showField data = if (field data)
then putStrLn "OK"
else putStrLn "Not OK"
showField data
| field data == Nothing = putStrLn "Not OK"
| otherwise = putStrLn "OK"
The BIG bonus is that you detect the error before you discover it at runtime. Imagine you didn't detected the error during your test (even with unit tests). This is why it is so easy to push this kind of error in production in a dynamic typed language.
And I only scratched the surface.
I program mostly in JS now, and I love even more when I am doing Haskell.
When you chain a series of functions/actions together, only to supply data for computation last, type signatures almost always ensures the correctness of the entire computation. This is true even the computation occurs at a high abstraction level. It's almost like magic, when dealing with the more difficult concepts (well for beginners) like monads. There has been a number of times when I wrote something but cannot make sure it does what I want, yet it compiles and a few tests reveals it indeed works like a charm.
Whereas in dynamic languages, it'd be a nightmare to dig into the dirty details at runtime. I always have this problem in R, a series of supposedly elegantly linked operations fail for mistakes like forgetting to convert character values into factor type. To debug such errors, I always have to explicitly carry out middle steps and store intermediary results, until finally locating the problem.
Another note, even in javaScript, sometimes there at patterns encourage the use of implicit types or interfaces(typeclass in haskell). The canonical example is jQuery, most of the times you can safely do:
$(something).method1().method2(param).method3()...
myObject[ someFunction() ] = 1;
In a (good) type system oriented language, you have to declare that myObject is a Map, and therefore when you want to access "field" you know this access could be "Nothing". The type system alert you if you don't handle the "Nothing" value.
I can't understand what a function is doing in isolation when the types are unknown. A function takes a variable foo and returns foo[bar], what did it return? Is that even valid code? What does that even mean if foo is a string and bar is a database handle? Ok, this is a lookup of some kind... is it an index or a hash table? I have no way of knowing without reading the comments (which may or may not exist). The only other way to figure out what the function is used for is to trace the data all the way back to its creation... literally find every call site and slog my way up the call stack.
In a dynamic language you can't even tell if all your code will execute until you run it and test all the code paths, let alone attempting to convince yourself that it's correct. I don't understand why people want that cognitive burden when the compiler can tell you straight away that you've typed something nonsensical.
I've just never seen a code sample that made me want to throw away static typing. Not even one.
Sometimes it computes a type and you have no idea what the type is about.
Also dynamic typing does not mean you don't know what a function receives or returns. Many dynamically typed languages are object oriented and use classes.
For example in Lisp I would write:
(defmethod collide ((s1 ship) (s2 submarine))
...
(the collision-event (make-collision-event ...)))
It's not statically typed, but the code is nicely readable and testable.
Many languages allow you to specify types even when they may be inferred to add clarity/preconditions. This is useful for modelling the domain as well as local reasoning. Perhaps the current implementation is valid for all integers, but in the domain context it only makes sense for the range 0-100.
The best compromise between static typing and dynamic typing, IMHO, is what C# (and later generations of C++) do: implicit typing via the VAR keyword.
You can't implicitly type the members of an object or the arguments of a function, but you can implicitly type variables in local scope. This is how C# is able to support anonymous types and functions so easily - implicit typing abstracts away the gangly looking static objects that are produced by LINQ queries and the like.
Implicit typing makes it very easy to refactor large blocks of statically typed code without compromising the benefits of static typing. So you get some of the flexibility of dynamic typing with the predictability of static typing.
Realistically - you don't utterly redefine the type of objects at runtime very often in production code even with dynamic languages, so you don't lose much with implicit typing.
That was due more to architectural issues in the C# compiler than any principled reason. C#'s type inference is extremely weak and incomplete and is a poor example of "getting it right".
Example: Dictionary<string, Func<string, int, Dictionary<string, string>>> somedic = new Dictionary<string, Func<string, int, Dictionary<string, string>>> { ... }
Is almost entirely better served by
let somedic = dict [ ... ]
For the majority of code, having to specify the types is an exercise in verbosity, nothing more. Unless you're only writing public libraries with no internal implementation, I don't see how there's not a scenario.
But this is just syntactic sugar, and the var keyword already takes care of the left-hand operand in this equation. Generic functions also do a reasonably good job of type inference under this set of circumstances, although I've found that generic delegates and lambdas not so much.
More information makes the code somewhat readable and understandable 10 years after when it was written. Dynamic typing often becomes a much more messy affair.
Static typing is beneficial when you want to catch a certain type of errors before your code enters production, it makes you write less error prone code.
I program a lot in Groovy these days, and it now has optional static typing with a limited amount of type inference. What I observe is that I voluntarily prefer to type my variables much of the time because it really does save time and takes only a fraction more effort than leaving them untyped. I find Python quite hard to decipher much of the time because it's nearly impossible to know what type a variable passed into a function is unless you trace back to the caller.
Groovy has enabled types on variables and functions (and fields and methods) since Groovy 1.0 but that makes the code run slower.
The general argument is that if you write enough unit tests, you can guarantee that your code doesn't make those kinds of mistakes. The statically-typed response is "why should you have to write unit tests when the compiler can make that guarantee for you?"
It's possible that the compiler would have had enough information to determine this, if the compiler were to check types. Again, the proposed solution is to simply write enough tests to exercise all code paths.
For what it's worth, I enjoy working in Perl. But I realize when I do that some things are deferred until runtime. I also enjoy working in C and C++, partly because I can push some things to compile time (type checks, sure, but also arithmetic ( http://en.cppreference.com/w/cpp/numeric/ratio/ratio ), unit checking ( http://www.boost.org/doc/libs/1_55_0/doc/html/boost_units.ht... ), a decent amount of reflection ( http://en.cppreference.com/w/cpp/header/type_traits ), some assertions (static_assert), etc.). I don't necessarily push it all to compile time, but C++ allows me to.
x + y
where x and y are values I got from who knows where. Javascript shouldn't pretend to figure out what I mean by this, because in many cases, I'm talking gibberish, and all I have is a bug.
I'd rather not talk about this stuff in terms of "types." It's about assertions, and Python makes them early and throws the exceptions early. It's a defensive practice that you can emulate in any language, and your assertions can be much richer than anything that is typically thought of as a type.
1 + 0 = 1
1 . 0 = 10
There are two problems demonstrated by your example; the other is the overloading of the + operator as a design decision in JavaScript. Easier, but worse.
The interesting thing is that a sufficiently powerful type system with strong type inference eventually converges with dynamic typing in ease of use, but it offers the option to do rather complex reasoning about the code at compile time, again, preventing certain classes of errors.
Beyond the classes of errors being prevented, I feel like a mature, strongly typed architecture offers a certain amount of guidance in implementing new solutions. If you start implementing certain interfaces in our more mature codebases, you get a number of situations you need to handle - since the interface forces you to implement certain methods. You can't forget these situations, again, preventing mistakes or recreating the same bugs.
Note that both situations assume a certain level of maturity in a solution. Initially, a type system can be somewhat annoying while you work out the kinks, I'm perfectly fine to admit this. This requirement also implies what I feel - in small, hacky scripts, static type systems tend to be annoying to some degree. But in large, complex systems, I don't want to miss them.
Result: program crashed when trying to call not present method. Had to clear up a few of these before it would work. If the type system hadn't been so forgiving the library implementers would have realized how their abstractions were leaking, and it would have been a lot easier for me to implement the interface correctly.
A similar thing can be achieved in Haskell, with the Typeable typeclass. The Scrap Your Boilerplate also fixes problems like this.
There has to be some use for dynamic typing when even Haskell (ghc) adds support for it, I guess.
I don't think ML users will agree ;)
ML dates from the 70s and its type system is the inspiration for Haskell's, although Haskell also adds typeclasses (and various Haskell extensions add a bunch of other stuff).
The most widely used versions today are Standard ML and Ocaml, although many languages take inspiration from ML, for example Coq, Haskell, Clean, etc.
I assume by "new PHP implementation", you're referring to Hack[2] which is a different language, although heavily based on PHP. (I believe Hack is a superset?)
https://github.com/psoberoi/stepanov-conversations-course/tr...
I certainly don't see Cython as anything but a quick way to get efficient C code in to Python module though... you typically get the worst of both worlds with compilation + dynamic typing.
That quicksort algorithm is about as efficient as it gets btw.
Regardless, it's damned nice (especially with TypeScript on the front end: static optional typing everywhere!)
http://docs.cython.org/src/tutorial/cython_tutorial.html#pyx...
At the same time I hate it when syntax vacillates wildly from application to application.
At the same time it is 40x faster (in my applications developed in a fortune 500 company, ok the research bit - but still delivered for use if not prod) than python.
Now, if only we got it running in SPARK...
It wouldn't make Python easier to use. Just the opposite.
Dynamic typing is probably preferable to a 40 year old type system. But Python could be easier to use (catch bugs ahead of time!) and execute faster by adding a modern type system. Optional typing (like TypeScript or Facebook's new PHP implemntation) would probably be appropriate.