Please note this homepage is NOT final and it's going to see revisions before we push it out to the actual website, including many tweaks to the content and probably some styling tweaks too.
There are a lot of other things we still need to do as well, like ensure all redirects and subpages work properly.
Source: I'm one of the Haskell.org administrators, and we pushed this out only today.
I love the tutorial! I couldn't help writing down some notes while going through it, here they are if you're interested in reading:
- Really would love to return to previous steps to review things (for example, reviewing what the difference is between a list and a tuple)
- "You just passed the (+1) function to the map function." But didn't I also pass [1..5] to it too? It's unclear to me whether map is a function which takes two arguments ... or if the first part "map (+1)" evaluates to a function which acts on [1..5]
- Is a (+1) a tuple with one item (the function "+1") or is it just similar syntax?
- Really like the exercises and would love to have more challenges interspersing the intake of new content. It honestly feels like the best way to learn.
I'm going to sleep for the night, otherwise I'd keep going. I'll return to it later. Looks promising!
P.S. Mini-bug report: Somehow this happened and it really confused me https://i.cloudup.com/0wRJS7FZls.png - looks like my 'try it again anyways' strategy saved me here. (there were no js console errors).
Not sure if you would like to know some answers to your questions, here are they anyway:
- It's unclear to me whether map is a function which takes two arguments ... or if the first part "map (+1)" evaluates to a function which acts on [1..5]
The latter is true. In Haskell you can pass arguments to functions one at a time each time the result could be a function that takes another argument. You might even say that Haskell functions always take one argument, and that Haskell's function syntax is just a bit of sugaring. The process of returning a function that takes the second argument is called a 'curry' after the man Haskell Curry.
- Is a (+1) a tuple with one item (the function "+1") or is it just similar syntax?
A tuple of 1 is just an expression. The ('s are just to determine expression scope, it's the commas that would make it a tuple. A tuple of 2 would just be 2 expressions bundled together, so I don't think there's a meaningful difference :P
Nah, Haskell has no functions with zero arguments.
You could say that a value is a function that takes no arguments, but then you lose the distinction between functions and other values, and more importantly, the distinction between function types and other types! For example, types like Bool have decidable equality, but function types in general have undecidable equality, so you really don't want to be caught saying that Bool is a function type. It's much more sensible to say a type is a function type iff it was constructed by the type constructor ->, which takes two types, the argument type and the return type. In other words, all functions take one argument and return one result.
You could also say that a value is an unevaluated thunk that takes no arguments, but that's not always true. The thunk may be already evaluated and replaced with a value, without affecting the visible type. It's better to keep the idea of "thunk" separate from the idea of "function", because a value could be both, either, or none.
You could also say that every value x can be converted to and from a function () -> x. But that's not a function with no arguments, that's a function with one argument of type "unit" (the type with a single member, a.k.a. the empty tuple).
The above might sound pedantic, but for some reason it's fascinating to me to think about such things. Language design is a kind of addiction and Haskell is like a drug, because its original purpose was to be a laboratory for programming language research, which you can see in the million GHC extensions.
In Haskell, all functions take one argument. Also, operators are functions.
First, the one argument thing is known as currying. With higher-order functions, returning a function is admissible, so
map :: (a -> b) -> [a] -> [b]
can also be thought of as:
map :: (a -> b) -> ([a] -> [b])
like so:
ghci> :t map length
map length :: [[a]] -> [Int]
As for operators being functions, function names that are alphanumeric default to prefix (e.g. f 10) while those that are symbolic default to infix (e.g. 10 + 18). To use an alphanumeric name in infix, use backticks, e.g.:
ghci> 5 `max` 6
6
Use parentheses to prefix an "operator"-style name, like so:
ghci> (+) 5 6
11
The (+1) that you're meeting is an additional bit of syntactic sugar. It's identical to (\x -> x + 1). It allows you to do things like this:
Is there a practical reason why there's so much empty space with this new design, and why so little valuable content and functionality is visible by default?
Viewing the existing site in a desktop browser, I get to see the description of Haskell, and a bunch of useful links about learning it, downloading an implementation, using it, and participating in the community. Recent news items and upcoming events are also visible, as is the search field.
This new design lacks pretty much all of that. Instead of useful content, links and functionality, all I'm seeing are large areas of purple and white, and an extremely blurry photo, along with content of very limited value.
I just can't see this new design being beneficial in any way. It makes it much harder to get useful information about Haskell, which seems very contradictory to what a website like this should be doing.
Yes - the practical reason is to focus on the newcomer's experience. Information overload is actively harmful to someone coming to haskell.org to learn about the language from scratch.
Omitting content that is primarily valuable to experienced Haskellers is a feature, not a bug.
This sounds like a dangerous trade off to be making. It's reminiscent of what we saw with GNOME 3, or even Windows 8. The experience is made much worse for existing users, in a vain attempt to "simplify" the design to allegedly appeal to new users who may not even really exist in practice. It's obvious now that it didn't work well in those cases, and I don't see why this case would be any different.
As an occasional Haskell user, I'm served much, much better by the existing site than by this new design. The existing one lets me get to the information I'm looking for with minimal effort. This new site denies me that accessibility, I'm afraid to say.
I don't see the point in trying to attract new users if doing so also means harming the experiences of established users. Drawing in new users becomes pointless if retention starts to suffer.
This case is different because it's an introductory page rather than a tool intended for heavy daily use, like GNOME or Windows.
Newbies are going to head to haskell.org when they want to learn about the language, and it's sensible for them to be greeted by a pleasant introduction to the language.
As "an occasional Haskell user," you aren't the target audience for the haskell.org landing page. :) If you're visiting on a regular basis, there's no reason your needs couldn't be met by some page other than the landing page.
"This sounds like a dangerous trade off to be making. It's reminiscent of what we saw with GNOME 3, or even Windows 8."
It's also reminiscent of what we saw with the iPhone, and nobody would say that the experience was much worse for users of previous smartphones. There are times when simplifying and giving structure to existing content just makes sense.
I'm curious, what content do you miss from the old page that can't be found in the Community or Documentation sections in the new design?
I'd like to see the Documentation, Community and News content on the front page, rather than hidden away on those separate pages. The new design adds an extra, unnecessary level of indirection in order to get to this useful information.
Fair enough, but as other posters have noted there's no reason why those contents need to be placed directly at the home page; they could be located at an inner page that you'd bookmark for reference.
The purpose of a good landing page is not to serve as an index for all the content (that's what site maps are for), but to explain the concept and structure of the site to someone that haven't seen it before. The new page is much better in that respect.
I miss a link to the current Haskell wiki in the new design, but I definitely wouldn't expect to find a list of all the wiki pages on the land page, but available under the Documents section.
I don't want to deal with numerous bookmarks to internal pages, or site maps, or any crap like that.
I want to be able to type "haskell.org" into any browser, and from there be able to quickly get to the standard library documentation, to the language spec, to Planet Haskell, to the downloads, and so on, without having to dig through subpages of subpages of subpages, and without having to scroll.
The Rust website at http://www.rust-lang.org/ is a good example of how a programming language home page should be laid out. There are many relevant links at the top. I can almost always find what I want within the first inch or two of the page. Yet it still shows all of the marketing junk for those who want that stuff, but it's placed well below the useful content.
The new Haskell design is the complete opposite of that. It puts a lot of useless junk front and center, and almost totally discards everything that actually is useful.
i don't think you can speak for all gnome 3 users. I'm the happiest i've ever been with gnome 3. I don't have a bunch of options and other knobs to twiddle. It just works and stays out of the way.
The real reason is that one of the standard bootstrap layout examples was used. The 'bootstrapped' web today is extraordinarily boring. It is the same big banner followed by striped two column grid again and again and again.
The existing design seems to do a good job of using the space available to convey a large amount of important and relevant information, with very little effort required from the viewer.
For example, a viewer of the existing site can quickly get to various types of documentation right away, without having to click on a link to visit a dedicated "Documentation" page, like with the new design. The same goes for news and community details, as well. An inefficient, unnecessary extra link click or press is now needed to get to very core information.
It isn't worth making an informational website look "pretty" if that means ruining its ability to effectively convey information.
Upvoted you. Even I find the new design to be terrible. One more point - the old webpage seems to be "simple" HTML - which loads properly even in very bad internet connections and old browsers like Hacker News. The new design seems to include video links in the homepage, which is always a bad idea, however "modern" you want it to be.
Also, the old homepage immediately gives a sense that Haskell is mature - with separate links about the language, books, libraries, IDEs, etc. The new webpage does not convey anything at all.
Would you need some help in curating a better set of videos?
I think that having some topics this advanced on the home page might scare of users, especially given their visual priority on the page.
Also, what's the plan on the view examples links on the page? Currently these don't link anywhere. Are you looking for existing articles that exist online to link to, or are you looking to have some content written that can be hosted on haskell.org.
I liked that the videos showed a glimpse into the active community around Haskell -- they are not just a fixed set of tutorials for newcomers, but show the variety of talks that Haskell programmers around the world give (including some deeper topics).
I'd hope there's some way to keep that perpetually current -- for it to include recent talks, kept up to date.
I'm a bit late, but perhaps you'll see this. Can you catch Ctrl+W in the REPL and use it to delete the prior word, instead of closing the tab? Kind of jarring to get into the groove of using a REPL and then accidentally close the tab.
There are a lot of other things we still need to do as well, like ensure all redirects and subpages work properly.
Source: I'm one of the Haskell.org administrators, and we pushed this out only today.