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.
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.
- 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).
- 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
This is exactly true. Every Haskell function takes either zero arguments, or one.
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.
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: ghci> map (2^) [1..5]
[2,4,8,16,32]
ghci> map (^2) [1..5]
[1,4,9,16,25]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.
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.
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.
Omitting content that is primarily valuable to experienced Haskellers is a feature, not a bug.
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.
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.
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?
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 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.
www.haskell.org: fun, introductory, digestible
lang.haskell.org: the current haskell.org homepage, good bookmark for those who want the haskell portalWould 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'd hope there's some way to keep that perpetually current -- for it to include recent talks, kept up to date.
<p><a>View examples</a></p>