I think it's a syntax problem. ASCII doesn't have enough bracket characters to simply & clearly represent necessary language features. So it's harder for an intelligent human to sort and categorize these aspects.
Pre-generics Java is about the appropriate amount of language complexity for our current lingua franca
> Pre-generics Java is about the appropriate amount of language complexity for our current lingua franca
I am not sure to whom you are referencing as being "our", so I can only say I disagree as there are many developers which are quite adept in languages having more complexity than "pre-generics Java."
Perhaps you meant to reply to a different comment?
Java is tolerably mediocre now but vintage 1996 Java was awful (and slow). I enjoy Scala, but even I can see why it's more than most of the industry is ready for. If there's a sweet spot, Kotlin seems close to it.
This. When a platform refuses to solve a problem, that problem doesn't go away. The users are forced to roll their own solutions, none of which have the same test coverage and optimization opportunities.
People who say "C is the new assembly" don't understand why people moved from assembly to C.
Assembly is bad because it is typeless. Because it is typeless, there is no way to check for program correctness. Rust is okay because it doesn't require garbage collection and types, but the best language would be C with a highly-elaborate strong type system and no closures or other unsuitable concepts for systems programming.
Closure often have really weird lifetimes, so typically they've ended up implemented either with GC of some sort (possibly refcounting), or required such exceedingly careful handling that the cost/benefit analysis gets a big fat lump of "cost" that isn't a problem in most other environments because trying to track the transfer of ownerships across scopes, up and down stacks, and perhaps even between threads is just insane. Typically the entire purpose of the closure is precisely to inject some code's logic into a quite distant other bit of code, so the problem is not amenable to normal techniques around rearranging things to be on the stack and so on. The very nature of a closure-type abstraction in C is go to stomping right over the generally-fragile informal, unsupported organization of what code is responsible for what memory.
I once was working with libpurple in a glib environment that made heavy use of segfaults in C. I mean closures. Closures in C that made it really easy to segfault when calling to a closure that had been freed, or really easy to leak if you didn't free them. I encountered situations where the common paths used by the "standard UI" for libpurple worked, but even when I was quite sure I was handling one of my closures correctly, the system would crash because it still free'd my closure, even though it should have been my responsibility to do so, and so on.
Prior to Rust, I'd agree with the common wisdom that closures and systems programming had gone together poorly. It's a demonstration of the power of Rust's approach to the matter that closures become practical in system programming with it; that had not previously been the case.
Right, there's definitely all sorts of issues with closures (esp async ones) if you don't have lifetime analysis. But Rust is the only systems programming language that I take seriously.
That's not why people moved from assembly to C, C is portable, assembly is CPU specific, the move to C was about abstraction to a higher level language in the name of portability to multiple processors, not about verifying program correctness.
It is not. A company that does not charge for use must get revenue by selling data. A company that charges for its service doesn't have to get revenue by selling data. It is "freed up" and can turn a profit through fee and skinny advertising.
You guys sound like the teenager whose parents (priests and theologians) are "always going on about that" wrt his drug usage. "No mom and pop. I don't have a drug problem. I can self-correct myself any time I want in time for Varsity."
> What if a film came out that satirized, I don't know, science, or abortion, or same-sex marriage, or racial equality?
You are wasting your time. All people of faith believe that everyone else's beliefs are based on insane delusions and that their beliefs is based on evidence and truth and so they cannot do an unbiased comparison of their beliefs with others. Comparing belief in e.g. rights for sexual minorities with e.g. Islam is always going to be seen as a false equivalency. Just like the Muslim is going to see a comparsion of belief in e.g. feminism as a false equivalency with Islam. You see, the Quran is based on truth while feminism is based on an insane delusion.
They can't both be right. At least one of them is wrong.
> Beside that, basics of category theory is far easier to grok than OOP Design patterns.
I know high-school dropouts and graduates from DeVry University who understand design patterns. Category theory--even basic category theory--isn't taught to undergraduate math majors (except maybe at MIT to honors students).
I mean, I appreciate functional programmers who want to do it because it is hardcore... but that's why they do it: because it's hardcore.
> I appreciate functional programmers who want to do it because it is hardcore
That's a misconception. Functional programming makes so many things so much simpler. I know, Haskell can be seen as an impractical exercise for the sake of tickling your prefrontal cortex. But again: there are other functional languages, e.g.: Clojure - it is simple and allows you to get things done in a pragmatic, reasonable and relatively quick fashion.
Recursion is the worst way to do iteration because it requires cleverness (= harder to debug) and it's ridiculously easy to cause a stack overflow. A for-loop is not going to cause an integer overflow on a 64bit architecture.
Closures are basically global variables and inherit all of the problems with global variables.
Continuations are basically goto's or memcpy and inherit all of the problems with goto's and memcpy.
Functional programming is ALL of the bad programming practices of the '80s. But because it's more abstract and mathematical it gets a free pass. Nevermind the fact that computer science is not mathematics. And the benefits of mathematical abstraction DO NOT TRANSFER if they inherently violate the commandments of bad ideas like global variables and goto's.
There are solutions to ALL OF the object oriented problems--including the diamond problem, circle-ellipse problem, and overuse of type hierarchies. There are no solutions to the functional programming problems because they inherently incorporate bad ideas described in paragraphs 1, 2, & 3.
> Recursion is the worst way to do iteration because it requires cleverness
No, it doesn't; in fact, recursion is usually much easier to reason about, particularly in terms of termination.
> and it's ridiculously easy to cause a stack overflow.
It's ridiculously easy not to, just assure your recursive calls are in tail position and you are using a language that supports tail call optimization (which essentially every dedicated FP language and a number of others do.)
> Closures are basically global variables
No, they aren't even similar.
> Continuations are basically goto's
Not really. They are similar in that they are a more powerful (and, therefore, dangerous if used incorrectly) flow control concept than simple function calls, but they aren't equivalent to gotos.
> Functional programming is ALL of the bad programming practices of the '80s.
No, that's unstructured imperative programming (though some structured languages preserved some of them.)
Closures are as hard to reason about as global variables are. Anywhere the function with the closed variable is called, that is the same thing as invoking a global variable, because that function could be called anywhere in the entire program. The difference is that the garbage collector deletes it when no function is calling it any longer.
Continuations are equivalent to memcpy... which should almost never be used. And tail-optimized recursive functions are still difficult to reason about.
And tail-call optimization (making stack calls constant) is... kind of self-defeating... because the only advantage of recursion is that it has a stack built into the function call/return operations. Anything a recursive algorithm can do is equivalent just a for loop and a stack data structure. And if you're tail-call optimizing it so that it has a stack parameter... then you're just using a clever way to write a for-loop :D Except functional doesn't allow for you to mutate a preexisting stack so you're also wasting space recreating a new stack each function call.
Yeah. Abstract math almost rarely transfers directly to the computer world. There's a reason why the pure functional & concurrent language Erlang was only used in telecoms and languished in obscurity: because that was the only domain it worked well in.
Holy shit. You're into something here. Hey, you should immediately send letters to companies like Wallmart, Apple, AT&T, etc. most of them are in Fortune 500 list. They all use functional programming languages. You could save them billions!
Computer science uses a completely different system of logic than mathematics or mathematics-inspired paradigms like functional.
Fortune 500 companies aren't attracted to functional. They're attracted to the TYPE systems of many functional languages. And type systems are good. But you can build e.g. a dialect of C or Pascal using those exact same type systems with no functional programming at all.
Python tries to move away from functional idioms whenever the developers realize that the idiom can be severed from the paradigm. E.g. Python's switch from filter(list, p) to [x for x in list if p]. Guido van Rossum feels that the imperative way is easier to understand and so do I.
Functional programming languages have good ideas, like type systems or lazy evaluation. But many of these ideas are NOT INHERENT to the paradigm. Perl6 incorporates almost every functional programming idea but as an imperative language.
