Bold claim: every widespread language has at least one widespread framework, in the wide sense of the word.
- Python: Flask, PyTorch.
- JavaScript: DOM API, React.
- C: Linux, the POSIX standard.
- R: the R repl.
I say success of a language is impossible unless hard decisions are already made for some practical area of expertise.
This does not imply causality of course. It is hard to establish causality in History. So, I find this observation persuasive — this is as good as it gets. If we are to make any decision, the decision to get a framework going is a good one.
Haskell's "framework", so far, is geared towards language design
1 reply
I stumbled upon dataHaskell recently and thought it looked cool. Then I decided to give it a try, first by using Chart. I spent the entire day trying to set it up in a stack project but failed because there was no LTS version providing all the necessary component libraries of Chart(?). Then I found out that the Chart repository has basically been inactive since 2016 or so...
This community seems largely inactive especially recently but still, I love both Haskell and data science and I think it'd be really cool to have a Haskell environment where you can do advanced data science stuff easily. If I wanna contribute to dataHaskell, where can I start?
Seems so. I guess it would help to start by clarifying the ideas. I mean, what would really help is if some hacker genius just threw together a new tool and language that was heavily influenced by Haskell on the one hand, and successful tools on the other. Maybe it would be an edsl, maybe not
hi tebu1783 (tebu1783), I second your sentiments re. the need for this kind of tooling in haskell, and of a supportive community
but this language is both a blessing and a curse because it favors experimentation and is very large, therefore there are more "standards" than actual users
we also have to reinvent many things from scratch that other languages get for free like subtyping or inheritance
@tebu1783: if there's not suitable LTS, would cabal work?
I'm a Nix advocate, I'll try to keep down the zealotry to a minimum though
Thanks for the response, @ocramz_:matrix.org
That reminded me of the classical essay The Lisp Curse. I thought this wouldn't be the case for Haskell because it's way more restricted than Lisp (in the sense that it has no macros)... But the "Haskell Curse" is still caused by the enormous amount of language extensions and new advanced features built on top of those?
That reminded me of the classical essay The Lisp Curse. I thought this wouldn't be the case for Haskell because it's way more restricted than Lisp (in the sense that it has no macros)... But the "Haskell Curse" is still caused by the enormous amount of language extensions and new advanced features built on top of those?
@man_of_letters:mozilla.org @b:chreekat.net I haven't given cabal a go, but now you mention it, I should try using Nix and cabal as a last resort, too :-)
Fwiw I don't feel like the number of language extensions is a problem, especially with the GHC20xx concept that is now available. But the fragmentation of the "standard" library is a problem
And the other problem as far as data goes is the Num type class
see? that's exactly what I meant above: 2 users, 2 orthogonal opinions.
IMO the haskell type system should simply be bypassed for data/ML workflows. With metaprogramming, generics and so on. Stuff like type families and singletons is simply a pain in the ass at scale.
this is my rationale for 'heidi' and my recent work on tensor compilation
Yeah I'm thinking the same thing, in that the boilerplate of type decorations is just a tremendous pain in the ass sometimes. And I agree that opening the doors to over engineering is probably not the right idea in this situation
My personal experience in this domain was at university studying numerical analysis and computational physics. For some dumb reason I really wanted to use C for everything at first. When I got around to anything using matrices, though, the boilerplate just killed me. I switched to octave. Sure, having a bunch of math stuff built in was useful, but what really saved me was a compact syntax built for the problem domain.
That's why I'm not sure just using raw Haskell would be the right idea.
I never got around to learning python, so I'm curious to know in what ways it was flexible enough to get heavy adoption for mathematical programming
chreekat: python is great for doing science because it runs your code no matter what. No matter what they say about pre-registering experiments, scientists just love to tinker and make up hypotheses after the fact
haskell is the opposite, it forces you to formalize the data domain very early. And the more type stuff you add to the domain, the harder it becomes to refactor
Hey guys, I'm looking for simple models in Haskell to generate random unique names (as in first names), just to identify stuff (as random UUIDs would, but in a pronounceable manner). Grenade seems to be able to train models that could do that, but maybe it's overkill, and also it doesn't seem really maintained. Any idea? I'd like something light that generates serializable models so it can easily be embedded in a Haskell application
@YPares: hi! what kind of neural networks are these (in newbie terms: fully connected, convolutional, recurrent, etc.)? Do you have in mind some classic model described somewhere in detail?
also, is the pronounceability learned by imitation and not verified, or is there a loss function that really enforces that during the training? (pardon me if that's trivial to google)
chreekat: python is great for doing science because it runs your code no matter what. No matter what they say about pre-registering experiments, scientists just love to tinker and make up hypotheses after the fact
I must say, I've had some horrible experiments where I run Python code for hours and then finally it prints out:
Traceback (most recent call last):
File "boop.py", line 1, in <module>
print(x)
NameError: name 'x' is not defined
Though that's completely consistent with what you said :P
@ocramz_:matrix.org
and they say Haskell compilation takes a long time...
anton_5: backprop is very handy. I've used it a few times
1 reply
oh, cool; for ML, as in neural nets, backprop should be great; at least, regarding performance on CPU and if your nets have large tensors in them, as opposed to very many smaller ones (it uses blas/lapack under the hood)
Oh, nice, good to know, thanks! I wonder if it can work with the accelerate as well.
Looks like accelerate has bindings to cublas, so, in theory, it should be possible to substitute regular blas in the backprop for cublas.
Or use the arrayfire bindings.
mentions library https://gitlab.com/sacha-sokoloski/goal used in https://elifesciences.org/articles/64615 , probably of interest to some datahaskellers :)