
Kronos Haskell - Red_Tarsius
http://www.kronosnotebook.com/haskell
======
PieSquared
Hey all! Author of IHaskell and Kronos here. Feel free to ask any questions :)

Sadly Kronos is outdated now, because it is based on IPython 2. IHaskell now
supports IPython 3 / Jupyter only, as of the release that I'm going to try to
put on Hackage today. I strongly recommend installing from Github master now -
we have two easy to read installation scripts for Linux and Mac (so no need to
trust them blindly, you can just read their source to see what they do).

Someday when I have the time Kronos will get an overhaul. The Python version
will become free - it makes no money, unsurprisingly - and you will be able to
download kernels from the app, perhaps including Julia and others, instead of
installing separate apps.

~~~
wz1000
Thanks for your work!

I was trying to get IHaskell to build on Arch Linux(using the Hackage
package). I couldn't get it to work with either the arch packages for ipython2
or for ipython3. The version that IHaskell tries to install also didn't work.
Should I just wait for your latest release?

~~~
PieSquared
I recommend installing IPython 3 with pip, cloning the repository, and then
running ./build.sh ihaskell. If that doesn't work, file an issue and I'll be
happy to help figure out the installation woes. (Note that ihaskell install
must be run for IPython to know about the kernel! Updating the documentation
is the last bit before release... :) )

~~~
baldfat
This is the whole reason why Juypter is being made. Everything in Juypter will
be kernel agnostic. The only part of Juypter that will be first class Python
is the IPython kernel.

------
Red_Tarsius
Disclaimer: I am NOT the author of Kronos. I'm learning the language and I'm
into all things Haskell. I thought it could be interesting to HN as well. You
can read more here: [http://goo.gl/SNLxjo](http://goo.gl/SNLxjo)

If you want get into functional programming, _Learn You a Haskell for Great
Good!_ , _Real World Haskell_ and _Parallel and Concurrent Programming in
Haskell_ are available online for free:
[http://goo.gl/4RoYrJ](http://goo.gl/4RoYrJ)

EDIT – Here's a handy cheat sheet of features:
[http://cheatsheet.codeslower.com/CheatSheet.pdf](http://cheatsheet.codeslower.com/CheatSheet.pdf)

~~~
coolsunglasses
If you'd like to learn Haskell, I'd suggest doing cis194 and then the NICTA
Course rather than LYAH and RWH, based on my experiences learning and teaching
Haskell.

I have a guide here that lists my recommendations:
[https://github.com/bitemyapp/learnhaskell#yorgeys-
cis194-cou...](https://github.com/bitemyapp/learnhaskell#yorgeys-
cis194-course)

I've explained my stances towards what not to use to learn Haskell here:
[http://bitemyapp.com/posts/2014-12-31-functional-
education.h...](http://bitemyapp.com/posts/2014-12-31-functional-
education.html)

~~~
dvdt
Wanted to second the NICTA course as a top-notch resource for learning
Haskell. It was only by working through the NICTA exercises that I finally
understood functors, applicatives, monads, etc. and _more importantly_
strengthened my intuition for when I could apply these functional tools to
practical problems.

------
kbd
Great to see the IPython notebook being used by languages other than Python!

I've been wanting to read The Haskell School of Music[1]. I'm hopeful this
would be a useful environment for working through it.

[1] [http://haskell.cs.yale.edu/euterpea/haskell-school-of-
music/](http://haskell.cs.yale.edu/euterpea/haskell-school-of-music/)

------
wz1000
Is there any way to build this for Linux, or am I better off just using
IHaskell?

~~~
ics
Just build IHaskell or use the docker container. Kronos is by the author of
IHaskell and if I recall also had a repo for a node-webkit wrapper around
IHaskell or IPython which this appears to be the continuation of.

To add: Building and installing IHaskell (on Mac at least) is a bit of a
hassle if you just want to get up and running. You need XQuartz, cairo for the
Diagrams module, gcc, a non-distribution ipython (recommended), and of course
a sane cabal environment. If you know what you're doing, that's a few minutes
in shell commands, making sure you're in a sandbox, etc. If you're new to all
of this, have fun figuring out why your build keeps exiting because of some
weird ABI breakage in an upstream Haskell package, or setting the right
library paths so that GCC can do its job, or finally getting everything to
build after GHC takes a week off in the Bahamas only to find that the kernel
dies immediately...
([https://github.com/gibiansky/IHaskell/issues/287](https://github.com/gibiansky/IHaskell/issues/287)
now fixed, don't worry!)

Despite that, it's a great tool and without it I don't think I would have been
as motivated to work through the stack of Haskell learning materials I've got
piling up.

Edit: Based on the author's comment above (PieSquared) Kronos is deprecated
with IPython 2, so it must be what I was thinking of regarding the older repo.

------
wodenokoto
Can any of you get it to work? I spend forever trying to get the open source
version working on Linux and gave up at tried this version on OS X.

I hope it will become part of the juPyter package in the long run.

~~~
wz1000
I used cabal install ihaskell --reorder-goals, and it built without any
errors. However when I try to run it, IPython does not detect the IHaskell
kernel. I get this error:

    
    
        /usr/lib/python3.4/site-packages/IPython/kernel/manager.py:95: UserWarning: Setting kernel_cmd is deprecated, use kernel_spec to start different kernels. warnings.warn("Setting kernel_cmd is deprecated, use kernel_spec to "

------
ElectricFeel
applying this to my list of 'interesting techie things'

------
hunnypot
The GitHub Pages site is dead.

------
tempodox
Wow, every language should have such a nice working environment, with graph &
math rendering built in. Too bad Haskell is such an impractical language.

~~~
sfvisser
> Too bad Haskell is such an impractical language.

When does this nonsense ever stop?

~~~
tormeh
It's not nonsense, though. But IMO it's not the language itself, but the
libraries that are impractical. The naming is the worst. If Haskell's authors
really wished to create a practical language, they would never have allowed
things like ">>=", "\", "." or "!!" into the standard libraries. It's not the
first programming language to use lots of arbitrary signs, but it's certainly
the worst I've ever seen. The only conclusion I can draw from all this is that
Haskell's written by people who love memorization and don't care much about
explaining to others.

~~~
nbouscal
Have you ever tried doing any non-trivial work in Haskell? I've used it
professionally, and spoken with a lot of other people who have, and exactly
zero people have expressed an experience that the naming of operators has
caused the language to be less practical for them. Some think it's less
aesthetically pleasing than it could be, but that's not a practical concern.

Furthermore, the specific operators you cite are confusing examples, given
that ">>=" can be elided using do notation, "\" looks enough like a lambda
that it took me a while to remember what you were referring to, and "!!" is
_rarely_ used. A slightly more reasonable argument for your case would be to
cite the operators used in the lens library, but those are all aliases for
regularly-named functions.

There are some arguments against Haskell in terms of practicality, but this is
not one of them.

~~~
jdminhbg
> I've used it professionally, and spoken with a lot of other people who have,
> and exactly zero people have expressed an experience that the naming of
> operators has caused the language to be less practical for them.

This is a pretty self-selecting set. One of the reasons I don't use Haskell
professionally is that I hate its operator-naming culture, and Haskell isn't
big enough in industry yet that it has lots of involuntary users (like C++ or
PHP or Java does).

~~~
nbouscal
As I said, you can definitely raise aesthetic objections. You're free to hate
operators all you want, though it does strike me as a peculiar basis on which
to decide what tool to use. My point was whether there are actual _practical_
implications, though, and I don't think the self-selected nature of Haskell
professionals has any bearing on that. I frequently hear many other objections
from people working in the language, so it's not a case of rose-colored
glasses in which we think everything about the language is fine. It's simply a
case of operator naming not being very important, from a practical
perspective. To the extent that it is important, most people who _actually
use_ the language think it's a benefit, not a detriment.

~~~
jdminhbg
Well right, but what I'm saying is that the people who actually use the
language are the kind of people who like the operators. I know Latin, and a
language whose functions were named in Latin would not be a practical
impediment to me, but I wouldn't say that such a language would be practical
in general. Haskell's operators aren't on that level, but I do think if you
introduced it in a company where people were hired to write
Python/Ruby/C/whatever, there'd be people who found them a practical problem.

~~~
nbouscal
Again, whether or not people _like_ the operators is irrelevant. Aesthetic
opinions about syntax don't have a material effect on productivity. As I said,
there are people using the language professionally who have an aesthetic
distaste for the use of operators in, e.g., the lens library (i.e. your
purported selection effect is empirically false). Those people will still
admit that this has little practical effect, and certainly not enough to make
a _language choice_ based on it.

If there were a language written in Latin, and it was useful for some reason,
people would quickly write aliases for all the Latin functions, named in
English. This is very easy to do in Haskell: if your argument held, you would
expect to see aliases for all of the operators. With a few exceptions (again,
lens), this isn't the case.

You're choosing where to live based on the color of the neighbor's bikeshed,
against evidence from previous tenants that the current color is quite
pleasant.

~~~
tormeh
It's not about liking, it's about looking at a piece of code and going and
going "I understand all that" vs "What does all these signs and single-letter
variables mean?". Naming matters.

~~~
nbouscal
Yes, it's very important that people who work in the language be able to read
and understand it easily. It is not, however, important that people who do not
work in the language be able to do so. The most persistent critique of Haskell
is that it is hard to understand for people who haven't learned it. This is as
reasonable as critiquing Java because it is hard to understand for people who
do not know how to program. You're welcome to claim that Haskell has a larger
barrier to entry, but that is a fundamentally different claim from the claim
that operators make the language harder to read for practitioners. I have been
attempting to refute the latter claim, using my experience discussing the
issue with said practitioners. If you want to discuss the former claim, I'm
happy to do that as well, but you have to acknowledge that it is a separate
claim and be clear about what it is you actually mean.

~~~
tormeh
>Yes, it's very important that people who work in the language be able to read
and understand it easily. It is not, however, important that people who do not
work in the language be able to do so.

Well, I guess we disagree there. And remember that some people may only work a
little bit in a language, and it matters, to them, how much time they need to
get into the groove with a language. Once you work enough in a language you
get used to all the weirdness anyway, which is how you end up with people
claiming C++ and PHP are actually kinda neat languages. The only good judges
of language syntax are people who have never seen that syntax before.

~~~
nbouscal
I think the exact opposite: the only good judges of syntax are people who
understand the semantics deeply enough to understand whether the syntax
accurately reflects them.

It's all well and good to say that people should be able to bounce around
between languages within a paradigm. A Rubyist should be able to read Python,
Perl, and PHP, sure. A Java programmer should be able to read C++ and C#.
Claiming that people should be able to read _any_ programming language,
though, means that languages aren't allowed to explore significantly different
semantics. A JavaScript programmer isn't going to be able to pick up something
written in Prolog or Forth and quickly understand exactly what's going on, and
_that 's as it should be_. The whole point of having multiple paradigms is
that they can express different ideas and ways of approaching problems.

So, I agree that an SML or OCaml programmer should be able to "get into the
groove" with Haskell quickly. In my experience, this is usually the case.

