|
Redux heavily borrows from Elm's Architecture, and Elm has an equivalent to React in elm-html. If you're comfortable in one, you'll very likely be comfortable in the other.
|
#
?
Apr 30, 2016 16:32
|
|
|
|
| # ? May 14, 2024 00:13 |
|
|
tekz posted:How does elm compare to say, using react+redux, which I really like. The architecture and thought process is similar between the two. The main difference is that Elm has a strong static type system, and encodes IO in the type system, kinda like Haskell - although it does so in a very different (and in my opinion, easier to understand) way.
|
|
#
?
Apr 30, 2016 17:12
|
|
|
Working in React & Redux is similar but clunky because JavaScript doesn't have first class support for its base principles (immutability and FRP) like Elm does. The plus side is it's easier to write 'escape hatch' imperative code for pragmatism reasons, although of course if there was less friction to doing things right like in Elm, you'd need the escape hatches less.
|
|
#
?
Apr 30, 2016 23:50
|
|
|
I guess I'll start with Elixir; http://elixir-lang.org/learning.html has a few options. I'm thinking of picking up the O'Reilly book, but if anyone has another recommendation please let me know.
|
|
#
?
May 4, 2016 21:06
|
|
|
tekz posted:I guess I'll start with Elixir; http://elixir-lang.org/learning.html has a few options. I'm thinking of picking up the O'Reilly book, but if anyone has another recommendation please let me know. Programming Elixir has been pretty great so far. Most Pragprog books are good, in fact.
|
|
#
?
May 4, 2016 23:16
|
|
|
I found Etudes for Elixir to be kinda neat too, but I also enjoyed etudes for erlang as well. MononcQc's Learn You Some Erlang can be helpful too; its erlang, but any of the chapters about OTP/general erlang ecosystem stuff can be really helpful for Elixir stuff still; also you may find yourself using some erlang libraries here and there and this can be helpful as well. There's also Elixir Rader (and apparently another, Elixir digest, that im sure is comparable) that collects library news/cool articles/ etc if you want a newsletter to pepper your inbox; i kinda enjoy the "weekly news" things for languages but it might not be for everyone.
|
|
#
?
May 5, 2016 08:07
|
|
|
Elm just switched their model from using signals, addresses, and ports to a unifying model of "subscriptions". At first glance it seems pretty promising: http://elm-lang.org/blog/farewell-to-frp
|
|
#
?
May 10, 2016 18:35
|
|
|
The 0.17 installer was flagged as Win32/Fathale.B!plock by Windows Defender, but only after I ran it. Hope it's a false positive 
|
|
#
?
May 11, 2016 15:52
|
|
|
So I hear a lot about Lisp's extensibility and metaprogramming capabilities, and how it's good for defining a problem in a language that maps directly to said problem domain. People talk about domain-specific languages and macros and bottom-up programming and "changing the language to suit the problem" which makes it seem a lot more like dark-arts wizardry than a programming language. I don't really understand what this all means, and how it makes Lisp so powerful/versatile. I get the concept of domain specific languages, even if I have no idea how to make one or what makes a good DSL good, and I understand that homoiconicity means that everything is just data, including code. But I can't seem to connect those concepts to understanding and writing code that maps directly from problem domain to implementation. It feels like there's supposed to be an aha-moment with Lisp that I haven't had yet, and I don't know what I'm missing. What am I looking for, and how do Lisp's killer features matter in programming it well?
|
|
#
?
May 18, 2016 23:39
|
|
|
Pollyanna posted:So I hear a lot about Lisp's extensibility and metaprogramming capabilities, and how it's good for defining a problem in a language that maps directly to said problem domain. People talk about domain-specific languages and macros and bottom-up programming and "changing the language to suit the problem" which makes it seem a lot more like dark-arts wizardry than a programming language. For me the lisp aha-moment happened when I started using structural editing for it (paredit in emacs), that's when I realised how the syntax and everything is just superficial and that data is code and how the universe really works. I went to find more information and was finally enlightened by this article about the nature of lisp.
|
|
#
?
May 19, 2016 01:01
|
|
|
The great thing about Lisps to me isn't anything philosophical, or even anything to do with its semantics. It's that you can copy an s-expression from a place, and put it in another place, and be assured that it means the same thing. You can press a key to slurp the sexp and plop it somewhere else, and it just works. When a lot of one's time is spent cutting bits out and moving them around in a large codebase, that's honestly a huge deal and saves a lot of typing and making sure you mouse over exactly the right code fragment. It's an ugly reason for liking Lisp, but as you've seen it's quite difficult to digest the pretty reasons 
|
|
#
?
May 19, 2016 05:31
|
|
|
Pollyanna posted:So I hear a lot about Lisp's extensibility and metaprogramming capabilities, and how it's good for defining a problem in a language that maps directly to said problem domain. People talk about domain-specific languages and macros and bottom-up programming and "changing the language to suit the problem" which makes it seem a lot more like dark-arts wizardry than a programming language. Not to knock Lisp (I've dabbled, but I'm certainly not one of the enlightened), but before you get too depressed about your failure to ascend, remember that for every beautiful Lisp monument to metaprogramming there are a hundred boring-rear end, non-Lisp programs out there doing work that people rely on as well. For all its glories, it hasn't made itself widely indispensable, and after however many years, "well they all just haven't heard the Good Word!" becomes an excuse and not an explanation. And when I read "Imagine the possibilities if the programmer could modify the abstract syntax tree himself!" the first "possibility" I think of is new heights of unmaintainability.
|
|
#
?
May 19, 2016 06:34
|
|
|
Redmark posted:The great thing about Lisps to me isn't anything philosophical, or even anything to do with its semantics. It's that you can copy an s-expression from a place, and put it in another place, and be assured that it means the same thing. You can press a key to slurp the sexp and plop it somewhere else, and it just works. When a lot of one's time is spent cutting bits out and moving them around in a large codebase, that's honestly a huge deal and saves a lot of typing and making sure you mouse over exactly the right code fragment. It's an ugly reason for liking Lisp, but as you've seen it's quite difficult to digest the pretty reasons it's also not particularly accurate
|
|
#
?
May 19, 2016 06:39
|
|
|
There have been a few different times over the years when I read long articles explaining clever macros and got briefly excited about the idea of diving into Common Lisp, but each time I found the language too barbaric to deal with. The function names in Common Lisp seem to have no logic or uniformity at all and the ecosystem feels ancient. I'd be curious to try a more modern Lisp like Clojure but I've never had a personal project that fit.
|
|
#
?
May 19, 2016 07:11
|
|
|
I think the "personal project that fits" part is what trips people up. It's hard to map the usefulness of code-as-data-as-code and macros if your typical use case is setting up a web application or making an app with a GUI.tazjin posted:For me the lisp aha-moment happened when I started using structural editing for it (paredit in emacs), that's when I realised how the syntax and everything is just superficial and that data is code and how the universe really works. I got that first part, where everything's the same under the hood, but apart from that I'm a little lost. I read the article, and I think I'm starting to get it. The XML and to-do list example is a good starting point, but it feels like that's just one particular application of it, and I'm not sure how to apply it to anything else. I can see flashes of brilliance there when you realize that the entire point is about transforming data in a functional manner, but that kind of loses its luster when you work in FP-ready languages already. The one problem I have with macros vs. functions is that everything you can do with macros, you can do with functions. At least, as far as I can tell. As someone who mostly uses FP, I reach for a data-transforming function over a macro since that's what I'm used to. I don't feel the need to use macros, almost ever, so I don't really have a reason to understand them. What could help is to have some sort of exercise where you give people some plain s-expressions meant to represent some kind of data structure, and have people write something that makes that chunk of data into a program. I think that's the crux of the matter - the fact that programs are data in Lisp confuses people, because everyone considers programs and data to be wholly separate things in their minds. Programs do things, whereas data are things. One becoming the other never happens, perceptually, and maybe that's the problem. "Code is data" is readily understood, but "data is code" might just be the missing piece. Here, this is something awful: Lisp code:1. Using only functions, and 2. Using only macros. Forums, boards, threads, posts, and users all have different pretty-print formats. For example, I want all forums to be displayed in UPPERCASE LETTERS, all users to be printed like Pollyanna says:\n, all posts to be printed like this: code:Pollyanna fucked around with this message at 16:24 on May 19, 2016 |
|
#
?
May 19, 2016 16:21
|
|
|
Pollyanna posted:I gotta run, but I feel like implementing this functionality in the two different ways (and maybe even a third way, a combination of both) will help illuminate Lisp's strengths. It won't, because macros and functions serve different purposes (and you should never use a macro when a function will suffice). The reason for macros is to implement new syntactic forms, with their own flow control. For instance, cond: Lisp code:edit: Another (possibly better) example: unlike Haskell or ML, Lisp functions are not automatically curried. If foo is a function of 3 arguments, Haskell treats (foo a b) as a function of the one remaining argument, while in Lisp (foo a b) is an error. But since this syntax is so convenient, Clojure provides the threading macro: Lisp code:Banned King Urgoon fucked around with this message at 00:06 on May 20, 2016 |
|
#
?
May 19, 2016 19:07
|
|
|
Siguy posted:The function names in Common Lisp seem to have no logic or uniformity at all and the ecosystem feels ancient. can you elaborate on both of those, i don't know what you're talking about
|
|
#
?
May 19, 2016 19:31
|
|
|
Banned King Urgoon posted:It won't, because macros and functions serve different purposes (and you should never use a macro when a function will suffice). The reason for macros is to implement new syntactic forms, with their own flow control.
|
|
#
?
May 19, 2016 21:03
|
|
|
weird posted:can you elaborate on both of those, i don't know what you're talking about I was talking a little out of my rear end since I didn't put much effort into learning Common Lisp, but all the built-in functions felt very old-school and weird to me, with lots of abbreviations and terminology I wasn't familiar with. That doesn't mean they're bad necessarily and I probably overstated saying they have no logic, but as someone new to the language I didn't understand why sometimes a common function would be a clear written out word like "concatenate" and other times a function would just be "elt" or "rplaca".
|
|
#
?
May 19, 2016 21:53
|
|
|
Siguy posted:I was talking a little out of my rear end since I didn't put much effort into learning Common Lisp, but all the built-in functions felt very old-school and weird to me, with lots of abbreviations and terminology I wasn't familiar with. That doesn't mean they're bad necessarily and I probably overstated saying they have no logic, but as someone new to the language I didn't understand why sometimes a common function would be a clear written out word like "concatenate" and other times a function would just be "elt" or "rplaca". i understand with elt. most of the odd abbreviated names like rplaca are low level / legacy functions that you don't really need to know about anyway, like you should never be writing (rplaca cons x), but always (setf (car cons) x), and even CAR should be FIRST if it's a list and not just a general cons. setf is really awesome by the way
|
|
#
?
May 19, 2016 22:38
|
|
|
also on ecosystem, the book you linked is a very good introduction to lisp but it was written before quicklisp came out, which is a biggy
|
|
#
?
May 20, 2016 00:27
|
|
|
 I dunno, then. This is just kind of my impression of what that article was trying to teach me, and what the whole magic/zen enlightenment of Lisp is. I just wanna know how to make things really bullshit easy and dead simple, and macros seem like a good way to do that. How, I don't know, but it's what people seem to be saying about them.Siguy posted:I was talking a little out of my rear end since I didn't put much effort into learning Common Lisp, but all the built-in functions felt very old-school and weird to me, with lots of abbreviations and terminology I wasn't familiar with. That doesn't mean they're bad necessarily and I probably overstated saying they have no logic, but as someone new to the language I didn't understand why sometimes a common function would be a clear written out word like "concatenate" and other times a function would just be "elt" or "rplaca". This is basically not a thing in Clojure, which is the newest dialect running on the JVM. Check it out: https://www.conj.io/
|
|
#
?
May 20, 2016 04:15
|
|
|
Siguy posted:I was talking a little out of my rear end since I didn't put much effort into learning Common Lisp, but all the built-in functions felt very old-school and weird to me, with lots of abbreviations and terminology I wasn't familiar with. That doesn't mean they're bad necessarily and I probably overstated saying they have no logic, but as someone new to the language I didn't understand why sometimes a common function would be a clear written out word like "concatenate" and other times a function would just be "elt" or "rplaca".
|
|
#
?
May 20, 2016 07:15
|
|
|
common lisp doesn't really compare to clojure or racket. if you're into lisp for the syntax, which is a good reason to be into it, they're all the same, but cl has a very different style, and there isn't really anything competing with it
|
|
#
?
May 20, 2016 07:20
|
|
|
Zemyla posted:If you were compiling the code, you'd see a much more dramatic decrease in the memory used with foldl', because of something called list fusion. Basically, in GHC, a lot of functions in the Prelude, and a good number of functions in other modules, use rewrite rules to pretend a list is actually a function that produces elements of the list on demand. This is all nice and good but does anybody else want to crosspost it to the coding horrors thread? Every pragma in GHC is just awful.
|
|
#
?
May 24, 2016 20:49
|
|
|
Every optimising compiler belongs in the horror thread. It's always a mess of heuristics, hacks and "good-enough"s.
|
|
#
?
May 24, 2016 21:47
|
|
|
nm
xtal fucked around with this message at 02:08 on May 25, 2016 |
|
#
?
May 24, 2016 21:55
|
|
|
Athas posted:Every optimising compiler belongs in the horror thread. It's always a mess of heuristics, hacks and "good-enough"s. I disagree. Well, sort of. Which is to say, Kent Dybvig did it with one heuristic that properly-quantified "good enough". The rest of Chez Scheme (which was recently open-sourced) is actually a pretty direct process of efficient and direct syntactic rewriting. For example, here is the pass handling letrec. Outside of Chez Scheme (and other, similar compilers written with Dybvig's philosophy, like Ikarus), however, yeah, most compilers, regardless of optimizations, are a horrorshow. Rust's compiler doesn't even do massive optimizations and it's a horrorshow, at this point GCC's a black box, LLVM can't even decide which cross-compilation is available, and ICC is full of magic tricks. QuantumNinja fucked around with this message at 04:47 on Jun 4, 2016 |
|
#
?
Jun 4, 2016 04:43
|
|
|
So I'm trying to Learn Me A Haskell (tm) and am doing so by doing Euler problems. I'm currently trying to do problem 5, which is to find the smallest number evenly divisible by 1 through 20. At first I tried to brute-force it, which turned out to be monstrously slow. Instead my methodology is now to find the prime factors of 2 through 20 (since we get 1 for free), merge them, and then multiply those. The merging method bit is what's killing me: ideally, I want the merged list to have as many 2s as the number with the most 2s in its prime factorization (which is 16, so four 2s), as many 3s as the number with the most 3s (9 or 18, both with two 3s), and so on. Unfortunately, the built-in union method doesn't quite work like this because the order of arguments is important: union [1, 1] [1] is [1, 1], but union [1] [1, 1] is [1]. How would I write a union function that works the way I need it to? I've gotten as far as being able to find the prime factorization of the numbers from 2 to 20 but I can't for the life of me figure out this intermediate step. e: aaaand naturally I figured out at least one way to do this. Tips and improvements are more than welcome, though  code:quiggy fucked around with this message at 19:10 on Jul 1, 2016 |
|
#
?
Jul 1, 2016 18:39
|
|
|
quiggy posted:So I'm trying to Learn Me A Haskell (tm) and am doing so by doing Euler problems. I'm currently trying to do problem 5 I did the same thing a few years ago and ended up with this: code:
|
|
#
?
Jul 1, 2016 20:12
|
|
|
Nippashish posted:I did the same thing a few years ago and ended up with this: The lst ++ (factors \\ lst) bit is pretty brilliant. Clearly I still have a lot of learning to do
|
|
#
?
Jul 1, 2016 20:33
|
|
|
quiggy posted:So I'm trying to Learn Me A Haskell (tm) and am doing so by doing Euler problems. I'm currently trying to do problem 5, which is to find the smallest number evenly divisible by 1 through 20. Uhh... code:
code:Banned King Urgoon fucked around with this message at 21:47 on Jul 1, 2016 |
|
#
?
Jul 1, 2016 20:45
|
|
|
Banned King Urgoon posted:Uhh... I didn't realize lcm was a thing until after I had already solved the problem. In truth breaking it down into smaller pieces is probably better for me to try to learn the language regardless.
|
|
#
?
Jul 1, 2016 20:46
|
|
|
A new Haskell MOOC starts in about 2,5 weeks time: https://www.futurelearn.com/courses/functional-programming-haskell. It seems quite basic but hey, at least its teaching Haskell instead of yet another Python one.
|
|
#
?
Aug 31, 2016 13:13
|
|
|
Lately I've been learning Idris because Haskell has a bunch of warts that make me cry. The library support is, expectedly, lacking, so I'm considering writing Haskell with an alternate prelude instead. Has anybody worked with ClassyPrelude, Protolude or Foundation who can help me decide what to use? (Or tell me if this is even a good idea, because I expect I am going to need to add a whole lot of string conversions for compatibility with libraries.)
|
|
#
?
Sep 2, 2016 20:21
|
|
|
xtal posted:Lately I've been learning Idris because Haskell has a bunch of warts that make me cry. The library support is, expectedly, lacking, so I'm considering writing Haskell with an alternate prelude instead. Has anybody worked with ClassyPrelude, Protolude or Foundation who can help me decide what to use? (Or tell me if this is even a good idea, because I expect I am going to need to add a whole lot of string conversions for compatibility with libraries.) I can't answer any of your questions but I'm curious as to what warts you consider to be intolerable in Haskell? Are any of these resolved in version 8 or with compiler extensions? And what is satisfactorily solved by Idris? I've been writing (functional) Scala for the last few years, and I'm sick of suffering its warts. Haskell is closer to what I want, but it'll take a good bit of personal investment before I am useful with it. Lack of libraries aside, is Idris much better?
|
|
#
?
Sep 3, 2016 01:45
|
|
|
xtal posted:Lately I've been learning Idris because Haskell has a bunch of warts that make me cry. The library support is, expectedly, lacking, so I'm considering writing Haskell with an alternate prelude instead. Has anybody worked with ClassyPrelude, Protolude or Foundation who can help me decide what to use? (Or tell me if this is even a good idea, because I expect I am going to need to add a whole lot of string conversions for compatibility with libraries.) Idris is fun to play with, but it doesn't supplant Haskell, no matter how excited I might be about what dependent types will do for software development long-term.
|
|
#
?
Sep 3, 2016 01:51
|
|
|
I like Idris over Haskell because of some of the historical weirdness it got rid of (switching : and ::, returning Maybe instead of erroring in, i.e., List access functions, the whole Monad/Applicative thing, Int vs. Integer.) I haven't looked too much into GHC 8, though.
|
|
#
?
Sep 3, 2016 02:04
|
|
|
I have a bunch of small complaints (Idris improves a lot more than the type system) but the lack of performance (String) and safety (totality) in the Prelude are what gets me. Having an opaque list type already pokes holes in type safety, so at the very least I want a Prelude that is total. Alternatives also tend to be implemented via type classes rather than concrete types which I prefer.
xtal fucked around with this message at 02:16 on Sep 3, 2016 |
|
#
?
Sep 3, 2016 02:13
|
|
|
|
| # ? May 14, 2024 00:13 |
|
|
Asymmetrikon posted:I like Idris over Haskell because of some of the historical weirdness it got rid of (switching : and ::, returning Maybe instead of erroring in, i.e., List access functions, the whole Monad/Applicative thing, Int vs. Integer.) I haven't looked too much into GHC 8, though. Applicative has been a superclass of Monad since GHC 7.10. The duplicate functions like return/pure and (>>)/(*>) are still there though, and I guess they'll probably never go away.
|
|
#
?
Sep 3, 2016 13:05
|
|
