Why aren't you functionally programming?

I disagree with your statement about understanability of bottom-up languages. I think they are much harder to understand, in general, than something like an apply function.
(apply 'function '(1 2 3)) is a lot easier for me to understand than the equivalent in C, for example.

>I only put Haskell there because it's synonymous to fp
yeah well you made a mistake because FP can be useful if you use it where appropriate, which is the opposite of Haskell

Maybe research could be done on it, it's hard to get an unbiased opinion because you'd need to test people who haven't programmed, the language of math in general has a way of putting people off though

In practical terms there really isn't

Impractical for systems programming, it's comfy as fuck for general application development though

Because I had some tasks that involved processing large (1GB+) datasets and the memory usage in functional languages became intractable.

what were you using?

It doesn't fix the kind of bug I typically make.

I am, with Swift.

Haskell. Tried making things strict and even a bit of unboxing. Eventually gave up and used Ada instead.

Try OCaml. Or just use use Python for data science like everyone else

Python still has issues due to putting absolutely everything on the heap. It gets away with it because all the data science libs are just wrappers for C or Fortran. Anyway, this was stuff I did a few years ago and Ada worked fine. Was comfy coming from Haskell even though it's strictly imperative/OOP. Probably the strong static typing.

cose it retarded

I have to be honest, I have never programmed in a fully functional language. I'm interested in learning it though, and it might be interesting to me because my background is actually in mathematics, not computer science. However I think Object-Oriented programming is way too powerful to completely shift the paradigm away from it. A good solution is possibly C# (my favorite language), which apparently is a hybrid language.

>I think Object-Oriented programming is way too powerful to completely shift the paradigm away from it.
you cant say things like that if you want to be a cool functional programmer

I'll get back to you on this once I've learned functional programming and gotten used to it

Learn F#. F# is actually functional and integrates well with C#.

I'm well aware of F#. However I'm currently reading through this book: manning.com/books/functional-programming-in-c-sharp
because I use C# in my job and it'd be cool if I can directly apply some of the things I learn to my actual work.

but I am, OP. Professional clojure programmer since 2+ years here.

nigger not even C works the way your processor computes. There is so much abstraction between you and your silicon you have no idea. Therefore, for the application programming purposes a top-down approach is the only one that makes sense. Mainly because this aims to save the programmers time for an arguably negligible performance hit AND you can always optimize your shit later on.

> bottom-up design where they take how the computer works
translating shit to machine code is literally a compiler's job, not a programmers'. Furthermore, as stated before python/C#/java OOP is NOT how the computer works;

wtf do you mess up so badly not even Haskell's compiler strictness can straighten up?

Haskell is a huge bitch when it comes to performance analysis. OCaml/Clojure? 1-2GB is not *that* much of data, with proper data structures you should arguably be able to crunch through on an average laptop. What calculations are you doing precisely?

>nigger not even C works the way your processor computes. There is so much abstraction between you and your silicon you have no idea
Even though you're exaggerating to the point of being basically wrong, C is still alot closer than any functional language, and that performance hit is definitely not negliable. Declarative programming doesn't offer you as much room for optimization by nature

>OOP is NOT how the computer works;
Who said it was? Even then, standard OOP abstractions translate a hell of alot better to machine architecture than FP abstractions

>standard OOP abstractions translate a hell of alot better to machine architecture than FP abstractions
the only semantics that can be seen as contrary to the FP paradigm that map readily to machine architecture are strict evaluation and mutability. But most FP languages that aim for practicality rather then theoretical elegance have both of these features anyway.

You don't have to give up on OO and go purely functional, you can mix and match styles.

declarative programming allows for the lowest level of programming (programming the logic gates that make up your cpu, or using fpgas)

single inheritance is a zero-cost abstraction and runtime polymorphism of single inherited things is also very fast. Meanwhile FP code translated to machine language could have unpredictable branches all over the place - or in some cases it could be very efficient. It's hard to tell, which makes it worse when you care about performance

I just read something about this as I got this reply! Very interesting, I think I'll delve deeper into this book

Attached: oopvsfp.png (636x528, 129K)

the lowest level of programming available to you is imperative machine code

>single inheritance is a zero-cost abstraction
data composition in FP is zero-cost too
> runtime polymorphism of single inherited things is also very fast
whatever single dispatch mechanism you use in FP is just as fast, and as a bonus you don't have to pay for that polymorphism in vptrs if you don't actually use it

there are commercially availible fpgas, alternatively you can use logic gates by hand

>that performance hit is definitely not negliable
this is wrong and you know it. You can easily optimize some simple Haskell/OCaML programs to run at least in the same order of magnitude as a C equivalent.

>standard OOP abstractions translate a hell of alot better to machine architecture
this has to be bait. A couple of years ago all you could read around were articles about how the OOP memory access patterns were hurting performance, etc.

what functional languages do you know? I'm not sure you know any of them beyond the trivial one-file programs. Furthermore, you can't do much with single inheritance, as it's frowned upon in every single relevant OOP project, which leans towards the composition over inheritance through the usage of interfaces/partial classes/traits.

FP is only just as fast if the compiler understand it it can be. It CAN be just as fast, or it can be alot slower, because its computation model is not aligned with the computation model of the CPU it's running on. That's the problem. Immutable data can be just as efficient as mutable if the compiler find a way to to turn it into mutable imperative code under the hood.

Everything you said is nothing more than baseless conjecture. Rust is demonstrable evidence that primitive functional abstraction techniques such as typeclasses and parametric polymorphism map onto real machine architectures just as readily if not more so than the OOP techniques (as in C++).

>this is wrong and you know it. You can easily optimize some simple Haskell/OCaML programs to run at least in the same order of magnitude as a C equivalent.
I can optimize a functional program to run as well as an imperative one or I could just write an imperative one with significantly less effort. But it really depends on the domain. Some domains are more suited to the paradigm than others

>this has to be bait. A couple of years ago all you could read around were articles about how the OOP memory access patterns were hurting performance, etc.
OOP has little to do with how you access memory. You can write bad memory access patterns with OOP or you can write good ones

>typeclasses and parametric polymorphism
These are great abstractions and map to machine architectures perfectly, when I complain about bad performance I'm talking about the immutability that comes with pure functions and the way languages like haskell treat functions where you're currying them and creating new ones all the time doesn't neccessarily map to CPU architectures at all

Nothing's stopping you tupling up all your arguments and passing them that way all the time. It wouldn't be any less syntactically weighty than doing the same in a procedural language with C syntax.
Just because FP makes a higher level of abstraction possible doesn't mean you can't write dumb and basic code.

why use a functional language to write imperative code when you could just use an imperative language

There are shades of grey here. Rust is a very imperative language with some functional features and (apart from the BC forcing you into ass-backward designs, mainly concerning mutability) those features map more readily onto the hardware than low level OOP like C++ does.
At the same time pure FP like Haskell is no more removed from real hardware than Smalltalk or whatever bullshit Yegor Bugayenko is working on.
"OOP" and "FP" are very broad descriptors and don't say much about the imperative/declarative nature of the language, but at basically every level of abstraction required FP is more efficient and more expressive than the OOP equivalent.

FP and OOP aren't even equivalent
The core concept of FP is pure functions (immutable data) and first class functions, immutable data is inefficient as hell and heavy use of first class functions has unpredictable performance
I don't consider typeclasses functional programming because you can do that in any type of language, imperative or functional

I am, with R and with Python.

>The core concept of FP is pure functions (immutable data) and first class functions
Purity is essential only to mathematical formulations of FP. It's also present in very high level OOP and formalizations of OOP like the pi calculus. Painting purity as only FP when the most popular FP languages don't require it but equivalently abstract OOP languages encourage it is disingenuous.
>heavy use of first class functions has unpredictable performance
Literally no different to heavy use of virtual functions.
> don't consider typeclasses functional programming because you can do that in any type of language, imperative or functional
Type classes literally only exist to add bounded polymorphism to polymorphic lambda calculi.

>I could just write an imperative one with significantly less effort
"Easy" and "Effort" are both subjective. On the other hand, "Simple" is objective. Scheme is among the simplest actually usable programming languages ever written, yet python might be easier for you.
What I'm arguing about is that programming languages that follow primarily the functional paradigm tend to be simpler to read and easier to interpret by a compiler, which ultimately leads to a smarter compiler. In C/Python - unless you use some special constructs - you have to do a shitload of AST analysis to figure out what exactly are you doing in a loop: whether it's an isolated operation, a search, or maybe you are accumulating something. Meanwhile in OCaML it's trivial.

But I agree on the domain - some things are just better done in a procedural imperative way, such as kernel-level utilities, HW drivers, and such.

Also, OOP and FP are not mutually exclusive - java/C# do not implement OOP properly according to the Alan Kay's definition and therefore should not be treated as representative of the style.

>formalizations of OOP
there's nothing 'formal' about OOP. People can't even agree on a definition of what OOP really is. It's a higher level abstraction built into some imperative languages, which is why I think it's a dumb idea to compare it to FP. You compare functional to imperative. You're trying to argue the supremacy of FP over OOP and I'm arguing that pure FP isn't very practical regardless of the existence of OOP or not

Functional code being easier to compile has little relevance to you as the programmer. Smarter compiler doesn't matter when they're all just spitting out imperative code in the end

Comparing functional to imperative is retarded, because they are orthogonal. FP and OOP are both declarative, procedural is imperative. Pure FP implicitly means pure declarative, but nobody's saying you have to use pure FP when you want imperative. That's just as retarded as pure OOP.

they are all spitting binary (or bytecode), which is something you're not gonna write anyways. And it's not predictable in a reasonable way - even C might surprise you on that front. Meanwhile, a smarter compiler would help you by translating some specific parts of your program (if not all of it) in a faster set of binary instructions, which is the goal of any language whatsoever.

“Programs are meant to be read by humans and only incidentally for computers to execute.”
Donald Knuth.

Imperative code issues commands one after the other to change state. In functional code the order of evaluation is meaningless because it has no state. That's the fundamental difference as I see it. OOP isn't very declarative, it has pretty concrete implementation details

That's because your idea of OOP is Java, not Smalltalk. You're comparing Haskell to something completely unrelated.

Never used Java or Smalltalk, you're the person who turned this into OOP vs FP, I don't see the point in debating a subject where the definition of OOP isn't even agreed upon and the apparently popular usage of the term has nothing to do with what people call OOP now

Name a single program designed using a FP language that is used by a lot of people

WhatsApp, written in Erlang.

Erlang is pretty based

I am, because I'm not a brainlet.

C has functions.

They're procedures, not functions. The nomenclature is inaccurate.

No "functions" in any real language is actually a function. The Fetch-decode-execute cycle does not allow real functions.

Abstract semantics do not care about underlying implementation. A function is a function if it behaves like a function, but C procedures do not.

you should try smalltalk, even if only for meme points. Or erlang - it's probably more Object-Oriented than any of the languages that are today conventionally defined as OOP.

but generally I like your FP definition here. Will reuse.

this.

>wtf do you mess up so badly not even Haskell's compiler strictness can straighten up?
The one thing I tend to do is mixing up function parameters, in particular when they are of the same type, ie. x and y. Also, APIs tend to be retarded and do the same.
Also I'm not keen on lazy evaluation.

what about Elixir?

Attached: elixir_github_1481354.png (400x400, 20K)

>implying I don't

Attached: 1540072050531.png (1024x1024, 95K)

>The one thing I tend to do is mixing up function parameters, in particular when they are of the same type, ie. x and y.

This makes no sense at all

Because i'm employed

Isn't Rust a functional language? I know everyone's talking shit about performance impact with functional languages, but I'm using Firefox 63 and it's faster than Chromium and every other browser I'm using, and it was largely written in Rust.

What's the point of functional programming anyway?

Rust has some functional elements, but it isn't a predominantly functional language and is mostly procedural. Most of the time functional programming is discussed, people think of highly abstract languages like Haskell.
Only the layout engine Servo is written in Rust.

>translating shit to machine code is literally a compiler's job, not a programmers'.
I always find it funny that cniles enjoy the fact that hardware manufactures are ripping them off and making them do their job. I ran into a guy here early who couldn't understand the concept of a lisp machine. He didn't realize that it was implemented in hardware and assumed they had to use assembly or something. I've always ran into a lot of people that think the C pointer model is the only way to manage memory and can't believe powerful languages like Ada don't have raw pointers.

>I've always ran into a lot of people that think the C pointer model is the only way to manage memory
Pointers dont manage memory, they just point to it it

you sound like someone that wikipedia'd fpga and aren't aware of the cost-scaling issues or hasn't intimately used them

FPGAs for prototyping and sometimes if you're willing to drop a ton of $$ they're good for data-center applications, but tool support for what you're describing is always geared towards C/C++, not to mention that performant FPGA designs *HAVE* to be stateful

You use pointers to allocate memory in C otherwise it's handled automatically by the compiler. What are you going on about? Is this cnile autism?

pointers don't allocate memory, the kernel allocates it and returns a pointer with the address of the block it was able to secure for your application

I just use whatever's practical, can't really be bothered learning about a language just for the memes or because it invented OOP

you manage memory using malloc and free or whatever they're called in C

Yeah which you use on pointers. What are you fucking retarded?

the pointers are not doing the managing, they merely point to the place that needs to be managed

Jesus this is actual autism. I'm done talking to you.

If you're going to talk shit you should get your facts straight or else you'll just look like an idiot

not him but I'm filing away this in my personal repository of reasons "cnile"-spouting autist (you) is an absolute retard

>Even though you're exaggerating to the point of being basically wrong
No, he's right.
blog.erratasec.com/2015/03/x86-is-high-level-language.html
Haskell is bottom-up. It builds a language out of a set of primitives. It's the languages that start with the CPU and then try to abstract it that are top-down.

Languages that are top down start with a high-level concept and work that down to reality, languages that are bottom up start with reality and work up to high-level concepts

Why is doing anything IO related so shit

Not really how these terms are normally used.
en.wikipedia.org/wiki/Top-down_and_bottom-up_design

that wiki page literally repeats what I just said
The people behind Haskell said it's a language designed from the top down

(((WhatsShitt)))

What "facts" do I need to get straight. I know exact how a pointer works you fucking retard. I'm not even sure what he's going on about. The point I was making is you don't need raw pointers to manipulate memory or to write complicated performant software like a kernel.
It's like you cniles have absolutely zero reading comprehension. I already know you guys know shockingly little about how computers actual work.

I am, with the java stream api. From java 11 on, it has everything you might except from a full fledged functional language.
Everything beyond that is just intellectual masturbation that has no practical use for productive programming.

>it was largely written in Rust.
Very partially

They're trying to replace all the c++ with rust I think. I imagine the speed is more about clearing out old inefficient code than something inherient to rust over c++. C++17 can be very safe if you use all of it's new features too. The problem is that most people don't. My professors at my University don't even know how to use smart pointers or reference.

>From java 11 on, it has everything you might except from a full fledged functional language.
No HKTs

Neither do ocaml, common lisp, erlang, clojure, or any of the FP languages that people have been accomplishing useful things with besides writing academic papers.
Just look at scala and the cancer that scalaz/cats programmers have brought along with them, to see the effect of introducing HKT into a programming language.

>Neither do [a shitlang with GIL] and [dynamic langs with no type system in the first place]
You sure showed me.

>C++17 can be very safe if you use all of it's new features too. The problem is that most people don't.
The C++ community learned the hard way that static analysis is really really useful for preventing memory safety problems that invalidate your mental model of what the program is doing. Since C++ was designed without static analysis in mind, it's a constant struggle to change the design to make such analysis easier. Writing tools that will work on existing code is also hugely expensive, resulting in costly per-LOC licenses that prohibit use in open source projects.

Mozilla created Rust (and adopted it for Firefox) as a way to circumvent these problems.

>What "facts" do I need to get straight
that pointers don't manage memory

>static analysis is really really useful for preventing memory safety problems
so is a language that doesnt let you access memory wherever you want without throwing an error but yeah lets use a much more complicated solution instead