5 ms·

> But then you hit a wall. Laziness makes for brutal debugging. Singly linked lists actually suck. Performance optimization is a black art To be fair, these is

• amelius 10y ago
  You mean non-purely functional languages.
  • bjz_ 10y ago
    Purity is orthogonal to laziness. Languages like Idris, Purescript, and Elm are pure but also eagerly evaluated.
    • hikarudo 10y ago
      Except that laziness requires purity.
      • deleted 10y ago
        [deleted]
      • fdej 10y ago
        Only if you insist on determinism :-)
  • vog 10y ago
    I assume you mean strict (the opposite of lazy) instead of non-pure (which means imperative). Well, even then, Rust does not only give you control over execution order, but also tight control over memory management, while keeping it safe. Haskell allows for good reasoning about correctness. In OCaml, you can additionally reason about execution order, but memory management and garbage collector are still somewhat "unpredictable" (i.e. hard to reason about). On top of that, in Rust, you can reason clearly about memory usage and aliasing. These new, modern languages follow a clear path about keeping quality and correctness (hence safety) while having more and more control over performance, without going back to low-level where you would loose clarity about correctness and safety. (Note, however, that the distinction between correctness and performance is over-simplified here, because performance can also be part of correctness, e.g. for real-time systems, or in systems where scalability is an important requirement.)
    • pron 10y ago
      > pure (the opposite of imperative). Pure is not quite the opposite of imperative; declarative is the opposite of imperative, although in practice it is true that pure functional languages tend to be more declarative that imperative functional ones. You can have pure (AKA referentially transparent) imperative languages if they are synchronous[1]. The synchronous style is especially well suited to reactive/interactive applications, and quite popular in hard realtime applications. Also, we don't really have exact definitions to any of these terms (imperative, pure, functional, declarative). Here is my attempt for approximate, problematic definitions: * Functional -- a language that models most/all computations as (possibly partial) mathematical functions, and constructs a program by assembling those functions. * Imperative -- a language that models computation as state transitions, specifying what state should the computation have at each step. * Declarative -- a language that describes what result should the program give (as a function, a relation or a behavior) rather than at each step. * Pure -- a language where the semantic value of the composition of syntactic terms can be determined by the semantic value of each of the component terms and no others. [1]: https://en.wikipedia.org/wiki/Synchronous_programming_language https://en.wikipedia.org/wiki/Synchronous_programming_langua...
      • catnaroek 10y ago
        You've just defined “pure” as “can be given a denotational semantics”. I have news for you: even ALGOL can be given a denotational semantics. --- @pron Nowadays I prefer the terms “effect-free” and “effectful”, rather than “pure” and “impure”, since I don't want to suggest that effects are somehow “wrong” or “evil”. By definition, values are effect-free. An effect is anything that invalidates some equational law that holds for values. For example, integer equality is decidable, and `x == x` evaluates to `true` when `x` is any integer value. However, if we substitute `x` with the expression `foo()`, where: int counter = 0; // or any other initial value int foo() { return counter++; } Then `foo() == foo()` doesn't evaluate to `true` anymore. Hence `foo` is an effectful procedure. Of course, nontermination is an effect too. If we had defined `foo` as: int foo() { while(true); return 0; } Then `foo() == foo()` would similarly fail to evaluate to `true`.
• srean 10y ago
  Technically you are correct (the best kind of correct) but from where we sit today in time, Haskell and OCaml appear as are peers. They probably have some 4~5 years between them, and probably less if you consider ML.
• nilkn 10y ago
  Practically speaking, OCaml is not exactly just a drop-in replacement for Haskell. For instance, Haskell has world-class support for STM which makes it arguably one of the best languages out there for single-machine multicore concurrency. Also, OCaml is still two decades old. I find it very bizarre that you attempted to group it in with Rust as a "new" language.