271–280 of 355 posts
Earlier quoted context omitted.
>even now functional languages are slower OCaml is famously faster than C++.
OCaml is quite fast, and I guess it could produce faster code than C++ on some occasions, but it's definitely SLOWER than C++ for most benchmarks, e.g.: benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ocaml&lang2=gpp
But yes, Ocaml is quite fast. Which was my point.
Earlier quoted context omitted.
>I don't have any idea what you're talking about when you say 'functional came before OO'. Lambda calculus is technically the first functional language, and predates computers. But if we're talking about actual programming languages, SASL, one of the earliest functional languages actually implemented, was released the same year as Smalltalk, and was influenced by the older ISWIM, which was never implemented. >I'm gue…
The lambda calculus was also the first OO language. (William Cook pointed this out in http://web.engr.oregonstate.edu/~walkiner/teaching/cs583-sp1... and I'd noticed the same thing. I just want to bring in a neat observation here, not fight for either side of the OO/FP culture war. I wish we humans wouldn't do that.)
Programming paradigms are a lot like political parties -- they tend to lump a lot of disparate things together with a weakly uniting theme. You don't need inheritance for encapsulation to be useful, for instance. The problem is, sometimes you agree with only a small part of the platform. None of these things individually are terrible ideas if tastefully applied, but it all gets clumped together into one big blob of "…
You can view a programming language like a fighting weapon ( although I don't promote violence ). If the enemy is right in front of you, you may kill it easier with a sword then with a nunchaku. But if he is around the corner, you may have better chances with the nunchaku. Or if he's at a distance you may use shuriken. One weapon can't offer all benefits, because it becomes impractical or dangerous. The reason why an…
Earlier quoted context omitted.
You can count your reduction steps in lambda calculus just fine. Can't you?
If you want a foundation for computing, may I humbly suggest imperative algorithms in the integer RAM model. That gives correct answers to questions like "what's the time and space complexity of quicksort in the average and worst case?" Good luck answering that with lambda calculus, or Turing machines for that matter.
(Lambda calculus is an interesting foundation mostly for work on correctness of algorithms---indeed analysing cost of computations is harder. Chris Okasaki has done a good case study of analysing runtimes of purely functional algorithms / data structures.)
Earlier quoted context omitted.
Cobol is certainly considered bad.
But good enough to be widely used for some of the worlds most important business processes such as payrolling and banking.
Legacy code bases don't make a language good.
Earlier quoted context omitted.
If you ask me what's the opposite of "proving", I'd say it's "testing". You call that "weaker"? It's the weakest form of validation I know of.
It may be weak, but by hell it's practical. Tons of tooling, tons of engineers who understand it, and with a pragmatic approach, eliminates many bugs and regressions.
Earlier quoted context omitted.
OCaml is quite fast, and I guess it could produce faster code than C++ on some occasions, but it's definitely SLOWER than C++ for most benchmarks, e.g.: benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ocaml&lang2=gpp
Ah. Sorry. But yes, Ocaml is quite fast. Which was my point.
Which is my point - there are languages that can compile to similar code as C/C++ if you write similar code - but the idiomatic code is still slower because it doesn't map to hardware cleanly and have inherent overhead, this is why functional languages didn't catch on when we were heavily CPU bound, it was common for people to write ASM because they couldn't get good enough perf out of C compilers.
Now that we transitioned from vertical to horizontal scaling problem domain maps very nicely to functional languages (actor model/message passing style communication is practically transparent with immutable data function calls).
Earlier quoted context omitted.
Actually, from what I've seen, pure FP forces people with less experience into design and structures of their code that they'd only do in imperative settings with considerably more experience. Eg when I asks students to do some simple exercise like "write a function that finds the shortest path through a given graph", in impure languages their solutions tend to return a path if they find one, but just give up with eg…
Funny choice of exmple, the algorithms I am aware of for finding shortest paths require mutable vertices that store the scores and pointers (edges) for the best part found so far . No doubt there ways to do it in a pure functional language -- but that requires a bit of thought. Compared to that difficulty, this business of return values seems trivial. Worse, a language that forces people to Do The Right thing, might…
No problem. Traditional loops with mutable variables translate straight-forward to tail recursive calls, if you want to write your algorithm like that.
Though actually my argument was less about not mutating your functions internal variables---but about interacting with the world outside your function via a well defined interface. (In this case, via arguments and returned values.)
The most 'mainstream' language that encourages such a strong adherence to declared interfaces is Haskell. But the imperative D can do something similar:
"In a slightly less precise way, this means that pure functions always have the same effect and/or return the same result for a given set of arguments. As a consequence, a pure function for example cannot call other impure functions, or perform any kind of I/O (in the classical sense)."
Earlier quoted context omitted.
The majority of software written ever has been written in the world's most popular functional programming language: Excel.
Yes but the majority of excel sheets consist of calculations. The source code of many OO programs will also consist of pure functions if that program is focused on calculation. So calculations are easy to express as pure functions, everybody knows that. On the other hand, if you want to make an interactive application in excel you use VBA which exposes a large and rich set of objects.
Simon Peyton Jones once did some work on giving Excel more programmatic power without having to go to VBA.
http://research.microsoft.com/en-us/um/people/simonpj/Papers...
Earlier quoted context omitted.
The real disadvantage of pure functional programming is that it is notoriously difficult to use and thus only very few programs outside specialized domains are written in them. For example I would guess that in a typical enterprise (say, a manufacturing company), 0.0001% of the software is written in a pure functional language. Things OO languages 'force' us seem to be relatively easy to use: sending a message to a c…
I work in a group of teams that is mostly new college grads and nobody has trouble writing pure FP business logic in Scala. We don't go as far as doing pure FP for all effects though (although we are starting to do that more as well) If we can do it, so can everyone else ;)