4 ms·

You seem to confuse a few things. Lazy evaluation is an option in the design space of programming languages, and one that is rather exotic due to its complicati

You seem to confuse a few things. Lazy evaluation is an option in the design space of programming languages, and one that is rather exotic due to its complications. Eagerly evaluated functional languages are quite normal. An imperative language could use lazy evaluation as well (and you can easily emulate it in one), but programmers would likely be confused by the ordering of intentional side effects and some typical imperative paradigms might even not work in a lazy setting. Object-oriented programming has long been criticized, but not in the context of JavaScript. As JavaScript is untyped, the downsides of OO programming aren't that visible. The big divide between (typical, statically typed) functional languages (say ML) and (typical, statically typed) object-oriented languages (say Java) lies in the organization of data. In the former you will typically use algebraic datatypes, which normally force you to define a complete data structure in one place and allow you to define many operations on it everywhere in your code (operational extensibility). The latter do the opposite and allow you to add new subclasses (structural extensibility). See "expression problem" for more info. In practice, it turns out that operational extensibility is much more important for safe code and there are functional patterns that give you the best of both worlds ("finally tagless"). It is because of this design-space divide that some people claim that (statically typed) object-oriented programming is a dead end.

petilon 5y ago
> Eagerly evaluated functional languages are quite normal. Probably not very efficient. Are there commercially successful examples of such a language? > An imperative language could use lazy evaluation as well Certainly! I believe Microsoft's Linq is one such example.
- duped 5y ago
  > Probably not very efficient. Are there commercially successful examples of such a language? Global lazy evaluation by default is the exception, not the norm. Standard ML, F#, OCaml, Scala, ... I actually would have more trouble finding a classic "functional" language that is lazy like Haskell but isn't Haskell. Not to mention, almost all the multiparadigm languages that can utilize FP like C++, Rust, etc are eager.
  - petilon 5y ago
    Rust does lazy eval.
    - duped 5y ago
      Expressions in Rust are eagerly evaluated, but you can write lazily evaluated things without issue.
    - bidirectional 5y ago
      Basically every language has some kind of opt-in lazy evaluation, Rust is strict by default as is basically every remotely mainstream language bar Haskell.
munk-a 5y ago
> Lazy evaluation is an option in the design space of programming languages, and one that is rather exotic due to its complications. It definitely requires control of the data - i.e. having a partially evaluated linked list somewhere directly accessible by pointer without signaling any generating function will break a lazy implementation. That said I absolutely love lazy evaluation and have built a lot of tools in less functional languages like PHP and C++ for handling very large data sets. When dealing with large report generation (i.e. all transactions from a quarter compiled for the accounting department) it can be necessary to avoid ever actually realizing full data sets into memory for efficiency and capacity reasons - that's an area where abstractly defining various transformations on the result set and then executing them in an iterative or batched manner can be exceedingly useful. I have killed many OOMs in my days.
kaba0 5y ago
Just want to add some defense for OOP (and that the two is not orthogonal at all, you can do OOP with FP): not everything is data-first. There are cases where object identity is essential for example, as well as types where the internal state has to be truly encapsulated to uphold invariants. Here, most FP languages would use the convention to only use functions designed explicitly for that very finicky use-case, while OOP can enforce it.
- choeger 5y ago
  For the latter case you would use an abstract type hidden in some module in ML. Only difference to OOP is the lack of open recursion and implicit "this" argument.

petilon 5y ago

> Eagerly evaluated functional languages are quite normal. Probably not very efficient. Are there commercially successful examples of such a language? > An imperative language could use lazy evaluation as well Certainly! I believe Microsoft's Linq is one such example.

duped 5y ago
> Probably not very efficient. Are there commercially successful examples of such a language? Global lazy evaluation by default is the exception, not the norm. Standard ML, F#, OCaml, Scala, ... I actually would have more trouble finding a classic "functional" language that is lazy like Haskell but isn't Haskell. Not to mention, almost all the multiparadigm languages that can utilize FP like C++, Rust, etc are eager.
- petilon 5y ago
  Rust does lazy eval.
  - duped 5y ago
    Expressions in Rust are eagerly evaluated, but you can write lazily evaluated things without issue.
  - bidirectional 5y ago
    Basically every language has some kind of opt-in lazy evaluation, Rust is strict by default as is basically every remotely mainstream language bar Haskell.

munk-a 5y ago

> Lazy evaluation is an option in the design space of programming languages, and one that is rather exotic due to its complications. It definitely requires control of the data - i.e. having a partially evaluated linked list somewhere directly accessible by pointer without signaling any generating function will break a lazy implementation. That said I absolutely love lazy evaluation and have built a lot of tools in less functional languages like PHP and C++ for handling very large data sets. When dealing with large report generation (i.e. all transactions from a quarter compiled for the accounting department) it can be necessary to avoid ever actually realizing full data sets into memory for efficiency and capacity reasons - that's an area where abstractly defining various transformations on the result set and then executing them in an iterative or batched manner can be exceedingly useful. I have killed many OOMs in my days.

kaba0 5y ago

Just want to add some defense for OOP (and that the two is not orthogonal at all, you can do OOP with FP): not everything is data-first. There are cases where object identity is essential for example, as well as types where the internal state has to be truly encapsulated to uphold invariants. Here, most FP languages would use the convention to only use functions designed explicitly for that very finicky use-case, while OOP can enforce it.

choeger 5y ago
For the latter case you would use an abstract type hidden in some module in ML. Only difference to OOP is the lack of open recursion and implicit "this" argument.