|
does chaining iterators count as fp? cuz i do that all the time in rust and it owns.
|
# ? Dec 11, 2017 09:47 |
|
|
# ? May 10, 2024 01:44 |
|
=sum(a:a)/count(a:a)
|
# ? Dec 11, 2017 17:02 |
|
point free = very maintainab le and easy to read
|
# ? Dec 12, 2017 03:57 |
|
i was taking a programming languages class in college, where they reviewed different paradigms including oop, functional, and logic programming. the functional part was done in ML and took up most of the class. about 90% of the students hated it, or at least didn't get it, and couldn't wait to go back to java. i was in the 10% that loved it! ended up doing an fp undergrad research project with the prof of that class, which helped me get into grad school
|
# ? Dec 12, 2017 04:04 |
|
Ludwig van Halen posted:my dude functional programming has been around as long as C has had function pointers this doesn't really count because, while you can pass around pointers to existing functions (defined statically at the top level of a source file), you can't create functions at runtime with closure over their environment, which is pretty essential to fp techniques. the lack of parametric polymorphism is also very painful
|
# ? Dec 12, 2017 04:08 |
|
DELETE CASCADE posted:i was taking a programming languages class in college, where they reviewed different paradigms including oop, functional, and logic programming. the functional part was done in ML and took up most of the class. about 90% of the students hated it, or at least didn't get it, and couldn't wait to go back to java. i was in the 10% that loved it! ended up doing an fp undergrad research project with the prof of that class, which helped me get into grad school I did a coursera programming languages course that starts with ML and I hated it for a while but I assumed it was mostly because of the static typing. I was definitely not used to it back then. But now that I think about it, I guess it was more than just that, it was the whole "humbling" experience of learning functional programming that got to me.
|
# ? Dec 12, 2017 05:21 |
|
Symbolic Butt posted:I did a coursera programming languages course that starts with ML and I hated it for a while but I assumed it was mostly because of the static typing. I was definitely not used to it back then. But now that I think about it, I guess it was more than just that, it was the whole "humbling" experience of learning functional programming that got to me. for me the static typing was the best part, as i got used to the ML type system it was just like yes Yes YES why isn't everything like this, it's so simple i can see how today's student of a "more mainstream" fp language like haskell or scala might feel very differently, though...
|
# ? Dec 12, 2017 05:25 |
|
0x1991BABE posted:point free = very maintainab le and easy to read point free / paren free sucks
|
# ? Dec 12, 2017 11:57 |
|
typed this up for some reason: For the last week or so I've been working on an elastic search client (really just a wrapper for the java library) in Scala. The main motivation is that the most popular Scala Elastic Search library returns a scala.concurrent.Future, but our code uses twitter.util.Future, and we have to convert between the two. Which isn't the end of the world, but it's annoying and requires adding work to a thread pool when it's really not necessary. Also I really dislike the fancy dsl exposed by the popular library (elastic4s); the official ES library is much easier to use and I'd rather just use that, even though it relies on mutable builders which are not functional. The only problem with using the java library directly is that it returns an ActionListener (or ResponseListener if you're using the low level client) object for all of its asynchronous calls -- they're basically just promise wrappers around nio's async http client. So we wanted a wrapper that accepts the standard Elastic Search query builders but returns a Twitter Future, rather than an action listener/response listener. Here's the (simplified) signature of the ES Java async Http API: code:
Wrapping this in a Twitter Future is not difficult: code:
within the promise. However, we're type-safe functional programmers and we'd like to provide a type-safe interface that prevents us from making mistakes such as passing a `GET` with a body. Let's define a few classes to encapsulate the standard requests. code:
code:
code:
code:
Ok, but the typeclass definitions above are pretty verbose. How can we make that easier? You might be thinking "add some simple helper methods" or "extend from request" and those answers would be fine but instead let's do it this dumb functional way: You may have noticed that all of our request types can be defined in terms of `Request`, which is the most general of our request types. Essentially, if we have a way to map from any of our request types to a `Request`, we know how to perform that request, and don't need to add any more logic. How do we map from one type to another? How about with map! Here, we've defined a method `map` on the `AsyncRequest[Req]` typeclasses that takes an existing `AsyncRequest` typeclass and constructs a new one. We simply pass a function `A => Req` that takes an A and returns a Req. code:
an instance of `AsyncRequest[Get]` in terms of `AsyncRequest[Request]`. Now we can do: code:
in the repl: code:
So, if the plan is to build higher level APIs, we probably want a way to manipulate the response as well as the request. That's a simple extension of what we've already done, parameterizing over the Response: code:
Now we have an amazing wrapper for elastic search, and we want people to use it. But we have the same problem elastic4s has: We've constrained ourselves to a concrete implementation of Future, and all of our users are stuck using our Future type. If only there were some way to abstract over the concept of a Future, so that our interface can return an arbitrary Future implementation. Let's do it. First, let's rewrite our code so that it accepts an AsyncExecutor typeclass, which is responsible for converting our response listener into a future: code:
and returns a unit (`ResponseListener => Unit`). We pass this partially applied function into the `fromResponse` method defined on the `AsyncExecutor` typeclass instance, which returns a `Future[Response]`. However, we haven't achieved our goal: We want to be able to define this for any Future (or really, anything that can do something meaningful with a ResponseListener). While our rewrite allows us to provide custom implementations of our `AsyncExecutor` typeclass, the signature of `fromResponse` is still constrained to a concrete implementation of Future. Let's take another look at our `AsyncExecutor` trait: code:
code:
the return value of `fromResponse` is simply Future! However, if we try to change it so that it returns a `Future[Response]` we cannot, because the trait says that we need to return an `A`, not an `A[Response]`. Is there a way to change the return value of our trait to `A[Response]`? In fact there is! code:
For our purposes, a higher kinded type is a type that takes a type parameter, such as an Option[A], a List[A], or, indeed, a Future[A]. However, I'm going to do a bad job explaining this, so read up here: https://typelevel.github.io/blog/2016/08/21/hkts-moving-forward.html In order to make this useful, we need to constrain it a bit by saying "any type which can do something meaningful with a ResponseListener." Let's see what a concrete implementation looks like: code:
typeclass available. For fun, let's provide an implementation of our AsyncRequest typeclass for the cats IO monad: code:
return either an `IO[Rep]` or a `Future[Rep]`. Wow! However, there's a problem: code:
our `F[_]` to things that can be mapped over. Things...that can be mapped over. That sounds familiar.. What do we call things that we can map over? I'm pretty sure I've read that Functors are things that can be mapped over. Let's try that. code:
code:
DONT THREAD ON ME fucked around with this message at 15:25 on Dec 12, 2017 |
# ? Dec 12, 2017 14:25 |
|
tl;dr
|
# ? Dec 12, 2017 14:45 |
|
jesus crhist just use c# or java. scala is a nightmare.
|
# ? Dec 12, 2017 15:08 |
|
Shaggar posted:jesus crhist just use c# or java. scala is a nightmare. i got the figgies for the C# job so i'm starting there in a month or so
|
# ? Dec 12, 2017 15:10 |
|
no lie i'm going to miss scala though, i feel like FP is just starting to click for me
|
# ? Dec 12, 2017 15:17 |
|
MALE SHOEGAZE posted:no lie i'm going to miss scala though, i feel like FP is just starting to click for me get a haskell job, op
|
# ? Dec 12, 2017 15:34 |
|
MALE SHOEGAZE posted:i got the figgies for the C# job so i'm starting there in a month or so noice
|
# ? Dec 12, 2017 15:57 |
|
MALE SHOEGAZE posted:no lie i'm going to miss scala though, i feel like FP is just starting to click for me looks like scala is just starting to right click empty trash imo
|
# ? Dec 12, 2017 17:32 |
|
i'm going to learn F# i think. does it still require that you declare your functions before using them within the same lexical scope? or was it something weird about file names? i cant remember.Cocoa Crispies posted:looks like scala is just starting to right click empty trash imo rude!!
|
# ? Dec 12, 2017 21:46 |
|
don't bother with f#. just use c#
|
# ? Dec 12, 2017 21:50 |
|
Shaggar posted:don't bother with f#. just use c# nah gonna do both.
|
# ? Dec 12, 2017 21:57 |
|
Shaggar posted:don't bother with f#. just use c# You've got it the wrong way around, friend.
|
# ? Dec 12, 2017 22:00 |
|
those sharps are just too sharp for me. give me a big ol' b♭ any day.
|
# ? Dec 12, 2017 22:29 |
|
maybe even an e♭ if i'm feelin' a lil' perky on the morning
|
# ? Dec 12, 2017 22:30 |
|
MALE SHOEGAZE posted:i'm going to learn F# i think. does it still require that you declare your functions before using them within the same lexical scope? or was it something weird about file names? i cant remember. I think people were confused by F# because it uses in-order evaluation, like Lisp or ML or Haskell, rather than a C-like independent/static compilation model so code within files needs to be ordered and the files themselves need to be ordered as well
|
# ? Dec 12, 2017 22:34 |
|
MALE SHOEGAZE posted:
the russians used curl wrapped in a bash script
|
# ? Dec 12, 2017 22:35 |
|
eschaton posted:so code within files needs to be ordered and the files themselves need to be ordered as well Is this true of all fp? Like I've mainly done programming in the small type stuff for course work in scheme, sml, and some racket so I haven't had to deal with this, but it sounds hosed up. e: Possibly less hosed up than having to worry about link order with large C projects though, now that I think about it. Colonel Taint fucked around with this message at 01:37 on Dec 13, 2017 |
# ? Dec 13, 2017 01:35 |
|
Colonel Taint posted:Is this true of all fp? Like I've mainly done programming in the small type stuff for course work in scheme, sml, and some racket so I haven't had to deal with this, but it sounds hosed up. the thing to understand about f# is that it's just ocaml copy-pasted on top of the .net platform. they've added new features but didn't really change how the core language works at all, to the point of source code compatibility in many cases. in ocaml you have to define stuff before you can use it. so if your module has a "main function" it's usually at the bottom, kinda like C. and there is no "forward declaration" where you can say "ehhh some other module is gonna tell you what this type is later on", the modules of your program need to be arranged into a DAG with no cyclic references (if you need cyclic dependency you have to make the modules mutually recursive and put them in the same compilation unit). in my personal aesthetic opinion this is kinda nice because you have to actually think about how to structure your code, and when i start to read your codebase for the first time i have sane places to proceed from; whether i prefer top-down or bottom-up study, at least i can see where the top and bottom are. contrast with a typical java codebase. however i suspect that the true reasoning behind this restriction in f# is "ocaml did it that way because ocaml came out of a research project and it was easier to write the compiler that way". there are some language details in ocaml that make lifting the restriction non-trivial (you can put side-effecting top-level statements in modules, so you need some way to establish a consistent ordering). f# probably does not need these details; i don't know c#, but presumably it works like java, where the restriction doesn't exist. they were probably just lazy.
|
# ? Dec 13, 2017 02:18 |
|
Colonel Taint posted:Is this true of all fp? Like I've mainly done programming in the small type stuff for course work in scheme, sml, and some racket so I haven't had to deal with this, but it sounds hosed up. a lot of languages and environments are like this, not just functional ones the main difference is if what you’re writing is a static description of a system (C, C++, ObjC, Java, C#, Swift) or whether the system is effectively “live” while it’s being compiled (Lisp, Scheme/Racket, Smalltalk, ML, etc.—and JavaScript) having the system be “live” during compilation can be an advantage, for example you can use its full power at compile time via macros or other forms of metaprogramming
|
# ? Dec 13, 2017 04:59 |
|
Colonel Taint posted:Is this true of all fp? Like I've mainly done programming in the small type stuff for course work in scheme, sml, and some racket so I haven't had to deal with this, but it sounds hosed up. nah erlang & elixir are 100% fine with functions in a module being out of order (otherwise you can't have functions that call each other) ruby's fine with cross-file dependencies as long as the names can be resolved at runtime rust is good
|
# ? Dec 13, 2017 05:20 |
|
i think you can be out of order in haskell, too. and also in elm and purescript
|
# ? Dec 13, 2017 09:24 |
|
much as i like f# it takes some doing to view a linear order being required as a positive.
|
# ? Dec 13, 2017 09:27 |
|
fart simpson posted:i think you can be out of order in haskell, too. and also in elm and purescript most haskellers are out of order in some way
|
# ? Dec 13, 2017 13:46 |
|
MALE SHOEGAZE posted:i'm going to learn F# i think. does it still require that you declare your functions before using them within the same lexical scope? or was it something weird about file names? i cant remember. F# is only similar to scala in intent, they're extremely different languages. If you take haskell, strip out any language features developed in the last 20 years and make the syntax slightly worse (ie no where, only let-in clauses) then you have F#. Honestly if it weren't for the dotnet interop nobody would ever use it even a little. That said, it's better than c#. http://www.trelford.com/blog/post/LighterCSharp.aspx
|
# ? Dec 13, 2017 14:58 |
|
computation expressions seem cool but are they adding typeclasses to f# sometime this decade or is it gonna get get beaten to the punch by c#? at this point javascript is a better platform for type safe functional programming than .net and that's kind of pathetic
|
# ? Dec 13, 2017 15:23 |
|
gonadic io posted:F# is only similar to scala in intent, they're extremely different languages. bleh, that's disappointing.
|
# ? Dec 14, 2017 01:34 |
|
e: hrm, had not kept up with present-day ocaml, retracting this
Cybernetic Vermin fucked around with this message at 09:30 on Dec 14, 2017 |
# ? Dec 14, 2017 09:10 |
|
Cybernetic Vermin posted:e: hrm, had not kept up with present-day ocaml, retracting this
|
# ? Dec 14, 2017 11:05 |
|
MALE SHOEGAZE posted:bleh, that's disappointing. Computational expressions are cool though, f#'s only novel feature as far as I know. They effectively do the same thing as haskell's monads, but can replace the semantics of let, while, andThen etc in the same way that haskell's do notation does. The neat thing is that they can be generated from specification files at compile time, so you can do all sorts of system interop poo poo with them. And OCaml with better libraries (but a less mature compiler) is still a better language than scala... Janestreet have optimised the poo poo of ocamls compiler infrastructure gonadic io fucked around with this message at 11:20 on Dec 14, 2017 |
# ? Dec 14, 2017 11:16 |
|
do closures break referential transparency?
|
# ? Dec 15, 2017 06:07 |
|
MALE SHOEGAZE posted:do closures break referential transparency? not if everything in them is immutable (parameters don't count)
|
# ? Dec 15, 2017 06:10 |
|
|
# ? May 10, 2024 01:44 |
|
yeah i guess so. not a very interesting question now that i've thought about it more.
|
# ? Dec 15, 2017 06:13 |