|
Puella Magissima posted:Whoa, that's way better than what I had. I don't think it even occurred to me to recurse to the correct list instead of manually indexing, but when you put it like that it makes total sense. I guess I'm still not used to thinking functionally. I probably should have come here before spending an hour banging my head against the wall coming up with my lovely solution. Thanks a lot for your help. I'll look into Data.Map as well. gonatic io is 100% spot-on about your learning process! Maybe try some of SICP in it, or Project Euler. Another thing that can help with Haskell is HLint, which will give you suggestions for your code. Vim's Syntastic supports it and certainly made me a better Haskell programmer. Also, pedantry: one recurs to the correct list, just as one incurs debt. Recursing is an unfortunate thing that happens after you've un-cursed an object and then sat, unlucky, on a throne in Nethack 
|
#
?
Mar 14, 2016 01:27
|
|
|
|
| # ? May 14, 2024 01:09 |
|
|
If we're being pedantic, then getGraphFromFile is a bad name and it should be called getGraphFromString. No files are involved at this stage. 
gonadic io fucked around with this message at 08:42 on Mar 14, 2016 |
|
#
?
Mar 14, 2016 08:38
|
|
|
QuantumNinja posted:Another thing that can help with Haskell is HLint, which will give you suggestions for your code. Vim's Syntastic supports it and certainly made me a better Haskell programmer. I've never used Vim or Emacs before, is "Vim's Syntastic" the next closest I'd be able to get to that functionality? Looking at YouTube it seems like it's kinda close but would be a pain since I don't already use Vim and its keyboard shortcuts.
|
|
#
?
Mar 14, 2016 13:20
|
|
|
If you don't want to learn a whole new set of keyboard bindings, both atom and sublime text 3 have hlint packages.
|
|
#
?
Mar 14, 2016 13:40
|
|
|
gonadic io posted:If we're being pedantic, then getGraphFromFile is a bad name and it should be called getGraphFromString. No files are involved at this stage. It was indeed originally FilePath -> IO [[Int]] but I didn't change the name when I moved the file access to main  Also I tried out HLint and it seems pretty helpful, thanks for the recommendation.
|
|
#
?
Mar 14, 2016 16:31
|
|
|
Holy poo poo, why is installing haskell stuff so difficult? Is it because I'm using windows? Installing haskell platform iself was no problem. My code compiles and I can test it just fine. However, when I decided to look for a good haskell IDE (with hlint support etc) the troubles began. First try was eclipseFP. No luck, I can install eclipse and eclipseFP just fine, but cabal install buildwrapper fails. Googled a bit, found other people with the same issue but no fix. Seems weird there's a bug in such a library, but hey, poo poo happens. So I decided to look for another IDE, this time I tried Leksah. I download leksah from the website and install it, but when I try to run my script things get messy and I see error messages in the leksah cmd. Turns out cabal install cairo fails, meaning cabal also can't install gtk3h meaning it can't run leksah properly. What the heck. I've again been looking for a solution, gtk3 seems pretty import anyway, Plenty of other users with the same problem This time there were some very vague and complicated solutions as well, so I've just wasted a hour manually installing mingw (again), msys, gtk (multiple ways, including via msys), cairo (again via msys) and looking at path variables and no luck. I also completely uninstalled haskell and did a clean new install. No improvement. Really, installing things should not be this difficult nor give so many errors. Especially the install guidelines for gtk are ridiculously complicated. Apparantly there used to be a simple installer you could use, but for some reason they thought that was too convenient. Buildwrapper error: src\Language\Haskell\BuildWrapper\Cabal.hs:768:47: Couldn't match type `ModuleName' with `ExposedModule' Expected type: [ExposedModule] Actual type: [ModuleName] In the second argument of `(++)', namely `hms' In the second argument of `map', namely `(ems ++ hms)' cabal.exe: Error: some packages failed to install: buildwrapper-0.9.1 failed during the building phase. The exception was: ExitFailure 1 Cairo error: Configuring cairo-0.13.1.1... setup.exe: Missing dependencies on foreign libraries: * Missing C libraries: z, cairo This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. cabal.exe: Error: some packages failed to install: cairo-0.13.1.1 failed during the configure step. The exception was: ExitFailure 1 Walh Hara fucked around with this message at 23:00 on Mar 14, 2016 |
|
#
?
Mar 14, 2016 22:57
|
|
|
That buildwrapper error seems like a bug in the module or its version bounds. Building stuff with C libraries is a gigantic pain on Windows. Leksah starts and editing works fine, but I can't get it to (didn't bother too much) actually build packages, so I just keep a MSYS shell open and build with stack. http://darcs.net/Windows has steps on how to build libcurl bindings and you adapt those for zlib/cairo, but honestly it's not worth the trouble. Boot up a Linux VM and call it a day. Alternatively, you can try getting Emacs or something to work. Probably better chance since you can build ghc-mod etc. easily on Windows.
|
|
#
?
Mar 14, 2016 23:29
|
|
|
The Haskell Platform is pretty much deprecated in favor of Stack, FYI. It keeps things isolated and is generally a huge boon to reliability. The GTK bindings are kind of broken on Windows, and I don't think Leksah (or EclipseFP for that matter) is really very well supported in general; most people just use one of the major editors like Emacs or Sublime or Atom.
|
|
#
?
Mar 15, 2016 01:08
|
|
|
You could always install a linux virtual machine and develop haskell on that.
|
|
#
?
Mar 15, 2016 14:33
|
|
|
My coworker uses Emacs with the Haskell thingy and it seems to work pretty well. I wouldn't call it an IDE per se, but it has syntax highlighting, indentation, and some options for quickly executing your code. Then again, you'd have to use Emacs.
|
|
#
?
Mar 15, 2016 15:20
|
|
|
Ralith posted:The Haskell Platform is pretty much deprecated in favor of Stack, FYI. It keeps things isolated and is generally a huge boon to reliability. The GTK bindings are kind of broken on Windows, and I don't think Leksah (or EclipseFP for that matter) is really very well supported in general; most people just use one of the major editors like Emacs or Sublime or Atom. EclipseFP is dead, the main guy stopped working on it. If Emacs is too much I'd go with Sublime, Atom or VSCode. Also I thought the platform was using stack internally now? There was a big debate about it a few months back.
|
|
#
?
Mar 15, 2016 15:40
|
|
|
hannibal posted:EclipseFP is dead, the main guy stopped working on it. If Emacs is too much I'd go with Sublime, Atom or VSCode.
|
|
#
?
Mar 15, 2016 18:32
|
|
|
Ralith posted:Maybe, I admit I don't follow community news very closely. I think it's pretty difficult to go wrong just installing stack directly, though. The important thing is to not be using raw cabal install. Yeah, cabal-install is hideously broken. Stack actually works, instead of breaking everything constantly.
|
|
#
?
Mar 15, 2016 19:21
|
|
|
QuantumNinja posted:You could always install a linux virtual machine and develop haskell on that. Do this + Stack + Atom with a few Haskell plugins (ide-haskell, haskell-ghc-mod, hlint).
|
|
#
?
Mar 15, 2016 20:12
|
|
|
I honestly have no idea if these posts about using a Linux VM are sarcastic or not. I've certainly never done such a thing and don't think it's a valid reply to the criticism of "installing a good IDE should not be so difficult". I installed via stack now (again, horrible documentation and the installer did somehow not automatically install gci, leaving me to gusss which stack command I needed). I'm currently using Geany, it's ok. Only complaint is that it doesn't do debugging (does any haskell IDE?). I might try atom or sublime.
|
|
#
?
Mar 16, 2016 00:50
|
|
|
Walh Hara posted:I honestly have no idea if these posts about using a Linux VM are sarcastic or not. I've certainly never done such a thing and don't think it's a valid reply to the criticism of "installing a good IDE should not be so difficult". Most non-mainstream languages target Linux primarily, with Windows being very much a second class citizen. I use a Linux VM for development more often than not. I agree it's not a good response, but it's just the state of things. Debugging Haskell is, last I checked, in a pretty sad state. It's a pretty hard problem to solve due to the lazy evaluation.
|
|
#
?
Mar 16, 2016 02:29
|
|
|
Anything that isn't CLR or game development targets Linux and OSX over Windows.
|
|
#
?
Mar 16, 2016 12:05
|
|
|
Walh Hara posted:I honestly have no idea if these posts about using a Linux VM are sarcastic or not. I've certainly never done such a thing and don't think it's a valid reply to the criticism of "installing a good IDE should not be so difficult". I think setting stuff up dev enviroments in windows, especially outside of visual studio, takes more of a learning curve because it doesn't really have a good package management system for the os itself. Setting up on mac/linux is usually a matter of just typing a couple of lines in a command prompt, whereas windows is "run this batch file oh wait it didn't work because you don't have python 2.7 or something's not on your path or you need to download some random file from microsoft off the internet or you have the wrong version of a dll" or some other horseshit.
|
|
#
?
Mar 16, 2016 13:00
|
|
|
Larger and more active development is occurring on Linux platforms for tech focused on it, which means that not only is the ecosystem more mature, it's also more likely to be up-to-date and easy to use. Popular use trumps platform.
|
|
#
?
Mar 16, 2016 13:27
|
|
|
Walh Hara posted:I honestly have no idea if these posts about using a Linux VM are sarcastic or not. Neither do I, but I use a linux VM to write Rust so 
|
|
#
?
Mar 16, 2016 14:41
|
|
|
I work in a polyglot web development team of 100+ and we write 99% of our code in VMs (though we switched to remote ones a year and a half ago). It's not a joke, it's very good. Check out vagrant, it has some kind of folder sharing so you can edit with any ide you want on the physical host while still having a sane environment.
|
|
#
?
Mar 16, 2016 17:20
|
|
|
Bognar posted:Neither do I, but I use a linux VM to write Rust so I wasn't joking; that's how I do most of my development.
|
|
#
?
Mar 17, 2016 01:18
|
|
|
+1 for VMs. Not having to worry about dealing with differing environments and being free to use whatever editor/IDE you want is really beneficial.
|
|
#
?
Mar 17, 2016 11:42
|
|
|
I've been doing a lot of programming over RDP in lieu of using a VM. It's great because I can type make -j and then play video games. Also if there's not a Visual Studio extension for whatever I'm trying to use, that's a pretty good cue to just do it on Linux instead of doing Windows rituals an unbound period of time.
|
|
#
?
Mar 17, 2016 17:10
|
|
|
Poking around Haskell and Functional programming by reading the "Learn You A Haskell" book. In one of the earlier sections, its talking about syntax in functions. It has this example:code:
|
|
#
?
Mar 21, 2016 02:31
|
|
|
Hughmoris posted:Poking around Haskell and Functional programming by reading the "Learn You A Haskell" book. In one of the earlier sections, its talking about syntax in functions. It has this example: informally: "lucky is a function from Integral things to Strings." I think this is better: "For each integral type a, there is a corresponding object called lucky which has the type of a function from things of type a to things of type String" Someone who knows a lot about Haskell/theory can probably phrase it better/correct me.
|
|
#
?
Mar 21, 2016 02:37
|
|
|
Hughmoris posted:Poking around Haskell and Functional programming by reading the "Learn You A Haskell" book. In one of the earlier sections, its talking about syntax in functions. It has this example: I would say that as something like "From any Integral type to String." The first part in parentheses indicates that a must implement the type class Integral, then the rest reads like a normal type signature, with that restriction.
|
|
#
?
Mar 21, 2016 02:39
|
|
|
"lucky is a function from any Integral type to String" sounds good to me. Maybe "from any type that's an instance of Integral to String" but while a bit more accurate it's also a mouthful
|
|
#
?
Mar 21, 2016 02:58
|
|
|
dirby posted:informally: "lucky is a function from Integral things to Strings." Arcsech posted:I would say that as something like "From any Integral type to String." The first part in parentheses indicates that a must implement the type class Integral, then the rest reads like a normal type signature, with that restriction. KaneTW posted:"lucky is a function from any Integral type to String" sounds good to me. Maybe "from any type that's an instance of Integral to String" but while a bit more accurate it's also a mouthful Got it, thanks.
|
|
#
?
Mar 21, 2016 03:17
|
|
|
I dabble with programming as a hobby, mainly in Perl and Python. Trying my hand at functional programming with Haskell. I've read in multiple places that functional programming makes concurrency/parallel programming much easier, and that functional programming scales really well. Could someone explain at a simpleton level why these things are easier with functional programming compared to OO/imperative languages?
|
|
#
?
Mar 24, 2016 23:37
|
|
|
There are a variety of reasons, but the simplest one to understand is that functional programming makes immutability explicit and traditionally either enforces or requires it. Entire classes of errors associated with parallel computation are impossible when acting on immutable data. For instances, consider the humble data race: when the data is immutable, it's meaningless to speak of ensuring that one thread can only read from a variable when another is done writing to it, and all the strategies to ensure this won't happen are unnecessary when the semantics of the language eliminate the entire concept of writing to a variable. This is an oversimplification, of course.
|
|
#
?
Mar 25, 2016 00:07
|
|
|
Hughmoris posted:I dabble with programming as a hobby, mainly in Perl and Python. Trying my hand at functional programming with Haskell. I've read in multiple places that functional programming makes concurrency/parallel programming much easier, and that functional programming scales really well. Most fundamentally, lack of mutable state means that you don't have to worry about data races (except in things like file access), and it allows for *very* lightweight threads. Also, the more expressive syntax lets you experiment with parallelization more simply (e.g. replacing calls to `map` with calls to `parmap`).
|
|
#
?
Mar 25, 2016 00:09
|
|
|
Is there a good tutorial on how to update Tree/Graph like datastructure in a convenient way in haskell? I.e. I have a date structure with theses types: type Edge = (String, Tree) data Tree = Leaf | Node [Edges] I have several functions to find a certain edge according to some criteria: findASpecificEdgeInTheTree :: ... -> Tree -> Edge And a function to update that edge in some way: updateEdgeInASpecificFashion :: ... -> Edge -> Edge How do I combine these two functions, so that I get the original tree but with a specific edge updated? If possible in a generic way so I can take any "findMeAnEdge" function and any "updateAnEdge" function and combine them. Is this even possible without me having to start compairing big subtrees? Context is that I'm trying to implement Ukkonen's algorithm for building suffix trees in Haskell (http://stackoverflow.com/questions/9452701/ukkonens-suffix-tree-algorithm-in-plain-english/9513423#9513423). It's just for fun, I've been implementing these kinds of algorithms in both python and haskell in order to challenge myself a bit and to see how the 2 programming languages compare. In some previous algorithms it was much easier to use haskell, but here I'm kinda stuck. And I haven't figured out how I'll implement suffix links either (a node can have both an edge pointing to it and a suffix link pointing to it, how do I make sure these always point to the same thing?).
|
|
#
?
Mar 25, 2016 21:34
|
|
|
Hughmoris posted:I dabble with programming as a hobby, mainly in Perl and Python. Trying my hand at functional programming with Haskell. I've read in multiple places that functional programming makes concurrency/parallel programming much easier, and that functional programming scales really well. It is mostly bullshit, and the envisioned trivial parallelism that functional programming supposedly grants has not actually manifested itself. In principle, functional programs (which need not be written in a functional language) are easier to parallelise, because the absence of mutable state implies the absence of shared mutable state, which is the bane of parallel programming. In a functional language such as Haskell, which has fairly mature parallel programming techniques and libraries, you can spawn concurrent threads that communicate only through message passing. Of course, you can do this in any modern language, although I suppose that in Haskell, the temptation to create just a little bit of shared mutable state ("for performance/convenience, you see") is easier to resist. The myth of easy parallelism is a little less of a myth when it comes to implicit parallelism (or better: data parallelism), where you do not use explicit threads. A previous poster described 'parmap', which could be a 'map' operation that evaluates each element of the list in parallel. This is true and good, and if the function you are mapping with is a pure function (which it certainly is in Haskell), you are guaranteed that the entire operation is free of race conditions and similar problems. So: parallelism is indeed easy. But: the only reason you want parallelism is to get good performance, and that is still hard. Consider that 'parmap' again - sure, the runtime could launch a thread for every elements, but what if the list has ten million elements? That's a lot of threads and it will kill your performance, especially if each element is very cheap to process. So you need some sort of chunking, and not start more threads than the hardware can readily utilise. And what if there are other 'parmap's in other concurrent threads in the program? You need to control the parallelism exhibited by the entire program, not just each little component, so as not to overwhelm the machine. And of course, whilst the purity of Haskell is very convenient for parallelism, the lazy semantics are most definitely not. In fact, most parallel libraries for Haskell perform eager evaluation, because laziness is totally antithetical to efficient parallelisation. And when you get to more exotic parallel hardware, such as GPUs, the idea of efficient parallelism being "trivial" or even "easy" falls even more apart. Now, I do believe functional languages are easier to parallelise, especially for data-parallelism, but you still need really clever compilers and cut-down languages. I base this on being a PhD student in functional parallel programming and actually having written a compiler for a data-parallel functional language that targets parallel hardware. It's fun.  But it's not as easy as it's often made out to be.
Athas fucked around with this message at 10:40 on Mar 26, 2016 |
|
#
?
Mar 25, 2016 21:47
|
|
|
You've got a lot of really good points here, but it isn't any kind of coincidence that Haskell is the place where transactional memory is becoming/has become conventional.
|
|
#
?
Mar 26, 2016 01:57
|
|
|
Ralith posted:You've got a lot of really good points here, but it isn't any kind of coincidence that Haskell is the place where transactional memory is becoming/has become conventional. No, but transactional memory is not automatically very performant (again: parallelism is easy, efficient parallelism is not). Furthermore, another reason is probably that GHC is the most dynamic and active research compiler I know of, and run quite well by people both technically and socially competent.
|
|
#
?
Mar 26, 2016 10:39
|
|
|
What about Erlang? I don't have any direct experience of it, but people who talk about it go on and on about millions of processes on your laptop or whatever.
|
|
#
?
Mar 26, 2016 18:16
|
|
|
Doc Hawkins posted:What about Erlang? I don't have any direct experience of it, but people who talk about it go on and on about millions of processes on your laptop or whatever. That's concurrency, not parallelism. Erlang is very very good, but it's not particularly fast for computation.
|
|
#
?
Mar 26, 2016 18:52
|
|
|
Athas posted:No, but transactional memory is not automatically very performant (again: parallelism is easy, efficient parallelism is not). Furthermore, another reason is probably that GHC is the most dynamic and active research compiler I know of, and run quite well by people both technically and socially competent.
|
|
#
?
Mar 26, 2016 19:17
|
|
|
|
| # ? May 14, 2024 01:09 |
|
|
Athas posted:That's concurrency, not parallelism. I'm not that ignorant, I just thought share-nothing concurrency would lend itself to parallelism too. But thank you for the answer.
|
|
#
?
Mar 26, 2016 19:22
|
|