|
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
|
|
|
|
| # ¿ May 10, 2024 04:21 |
|
|
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
|
|
|
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
|
|
|
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
|
|
|
MALE SHOEGAZE posted:do closures break referential transparency? not if everything in them is immutable (parameters don't count)
|
|
#
¿
Dec 15, 2017 06:10
|
|