3 ms·

If you agree with the author's conclusion that we need better languages that allow us to give the compiler more information about the optimization needs of our

If you agree with the author's conclusion that we need better languages that allow us to give the compiler more information about the optimization needs of our program, then I think you have to look in the direction of languages like Haskell, Idris, etc. Fortran can be faster than C because C has aliasing that limits the optimizations that the compiler can perform. Similarly, strongly typed and pure languages like Haskell give you even more. You can do a lot with types, but on top of that Haskell allows you to define rewrite rules that tell the compiler how things can be optimized. This allows the compiler to automatically convert things like this: map f (map g items) ...into this: map (f . g) items

e12e 11y ago
Assuming f and g are not evaluated for their side-effects... While I get that Haskell allows/demands you to write what you mean, consider an app that adjust reverb and volume up, from 1..10 (here items is the range 1..10). You could argue (rightfully) that the code should be structured differently (in this imaginary case, f and g would be identity functions on integers -- or perhaps Maybe integers (return int if volume/reverb set to the requested number, error/nil otherwise). I realize this is a strange and contrived example -- the main point is that while functional programming is great -- iff what is wanted is a single multidomain language, it needs to function (heh!) in many different paradigms. Btw, what would be the appropriate way to define functions for their side effects in Haskell - eg a function like this that takes an integer, performs some kind of i/o, interrupt, writes to a hw address -- to set some external state -- and returns the new value on success? Anyone have some pointers to that at the top of their head? Maybe there's a chapter in "Real World Haskell" that deals with it? [ed: I just realized that the behaviour of (f . g) and map-map might be similar with the "Maybe identity"-behaviour I sketched above - modulus error handling/recovery (eg: do we want to try f on a given int i, even if g failed?). Oh well :-) ]
- mightybyte 11y ago
  > Assuming f and g are not evaluated for their side-effects... And that is the whole point. In Haskell we can know that f and g have no side effects. If they had side effects you would not be able to compose them with the dot operator. I don't quite understand your example but I assure you that there are elegant ways to accomplish that in Haskell. There was recently a presentation [1] at the NY Haskell meetup that talked about a new Haskell sound synthesis library called vivid. Making functions that perform side effects is also easy. Here's a simple example: intToFile :: Int -> IO () intToFile anInt = do writeFile "myfile.txt" (show anInt) The idea that you have to be multiparadigm to function in real world settings is a fallacy. Haskell is simply more expressive, which equips it to solve just about any problem with more clean and concise code than you're likely to get in other languages. Even if the code size stayed the same the extra safety you get from purity and strong types would be worth it alone. [1] https://www.youtube.com/watch?v=xo3zUvPsizo https://www.youtube.com/watch?v=xo3zUvPsizo
  - guipsp 11y ago
    >The idea that you have to be multiparadigm to function in real world settings is a fallacy. Haskell is simply more expressive, which equips it to solve just about any problem with more clean and concise code than you're likely to get in other languages. Even if the code size stayed the same the extra safety you get from purity and strong types would be worth it alone. Haskell is also not used any major project. It's an academia language.
    - tormeh 11y ago
      I think that has more to do with syntax and the overdependence on rote memorization that it requires, and less to do with the actual concepts themselves. Lots of things are silly in Haskell-land, but that's mostly because it's made to be elegant or math-like, if I've understood it correctly. That said, multiparadigmatic programming is awesome, we just have to find some way to give as much information to the compiler in imperative instructions as we do in functional. This means that imperative programming has to be tightened up quite a bit, but I don't think it would be very drastic, really.
    - e12e 11y ago
      I don't think it's quite right to say it's (still) just an academia language -- but it's absolutely marginal. I use two (three) programs implemented in haskell on a (semi)regular basis: xmonad (and xmobar) and pandoc. Other than that, I know of git-annex that is both actual programs and is in actual use. That's still more than the number of programs I use that are implemented in Arc... Haskell is academic in the sense that it is very opinionated about a few things (as this sub-thread illustrates). Lets see how Shen, Open Dylan and clojure end up doing ... (and of those, probably only clojure have meaningful contemporary systems implemented in it - so far). Maybe there's even more life left in Common Lisp (sbcl etc) or Scheme (Racket, guile w/guix nix (haskell! yay!) ...). Then there's OCaml of course...
  - e12e 11y ago
    > The idea that you have to be multiparadigm to function in real world settings is a fallacy. I'm not so sure. The best solution for a subset of programmers is unlikely to be the best solution for every programmer. Somewhat like the quote about literate programming: "Jon Bentley probably hit the nail on the head when he once was asked why literate programming hasn’t taken the whole world by storm. He observed that a small percentage of the world’s population is good at programming, and a small percentage is good at writing; apparently I am asking everybody to be in both subsets." -- According to Donald Knuth http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856 While I think there is much more overlap between good programmers that write good Forth, those that write good Ada (or other procedural code), those that write good functional programs, those that bask in the glory of Smalltalk/Self (classic oo) and those that get by in java ("modern"/class-oriented oo) -- than between good technical writers and good programmers -- I think the problem is partly the same. There's no guarantee that haskell is the best tool for a 10 year old write interactive fiction, or automate his or her schedule -- and for a finance manager to manage numbers and for an engineer to write code for a robot -- or for high frequency trading... or etc. Machines don't understand Haskell anyway, only humans do. If many of us find Visual Basic or Excel or SQL easier... we probably have a need for such languages (even if I don't want to touch Visual Basic with a stick...). Multiple programming paradigms has nothing to do with computers and systems, and everything to do with human-machine interface and augmenting the capabilities of humans through computers.
- GeneralMayhem 11y ago
  If you wanted their side effects, they would have to be in a context that tabulates their side effects - i.e., a monad. Operations in a monadic context (I/O, mutating state, etc.) are generally not commutable - or if they are, the circumstances under which they are can be expressed in the definition of the monad. On the other hand, part of the point of Haskell is that any side effects must be made explicit, so if all you've got is a function, you can be guaranteed that there are no side effects.
- wz1000 11y ago
  In Haskell, there are no side effects. Any effects you care about will explicitly be part of the type. Haskell provides many combinators to combine various combinations of effectful and effect-free functions. Look into the documentation for Control.Monad to see some.
caf 11y ago
Your example of aliasing in C is a good one, because this is a case where modern C allows the programmer to give the compiler the necessary information to do a better job. The "restrict" keyword indicates that an object accessed through a given pointer argument cannot alias any other object accessed by the function.
- TheLoneWolfling 11y ago
  Which doesn't help when you're trying to express anything more complex. Such as "a won't alias c, but there are no other restrictions".

e12e 11y ago

Assuming f and g are not evaluated for their side-effects... While I get that Haskell allows/demands you to write what you mean, consider an app that adjust reverb and volume up, from 1..10 (here items is the range 1..10). You could argue (rightfully) that the code should be structured differently (in this imaginary case, f and g would be identity functions on integers -- or perhaps Maybe integers (return int if volume/reverb set to the requested number, error/nil otherwise). I realize this is a strange and contrived example -- the main point is that while functional programming is great -- iff what is wanted is a single multidomain language, it needs to function (heh!) in many different paradigms. Btw, what would be the appropriate way to define functions for their side effects in Haskell - eg a function like this that takes an integer, performs some kind of i/o, interrupt, writes to a hw address -- to set some external state -- and returns the new value on success? Anyone have some pointers to that at the top of their head? Maybe there's a chapter in "Real World Haskell" that deals with it? [ed: I just realized that the behaviour of (f . g) and map-map might be similar with the "Maybe identity"-behaviour I sketched above - modulus error handling/recovery (eg: do we want to try f on a given int i, even if g failed?). Oh well :-) ]

mightybyte 11y ago
> Assuming f and g are not evaluated for their side-effects... And that is the whole point. In Haskell we can know that f and g have no side effects. If they had side effects you would not be able to compose them with the dot operator. I don't quite understand your example but I assure you that there are elegant ways to accomplish that in Haskell. There was recently a presentation [1] at the NY Haskell meetup that talked about a new Haskell sound synthesis library called vivid. Making functions that perform side effects is also easy. Here's a simple example: intToFile :: Int -> IO () intToFile anInt = do writeFile "myfile.txt" (show anInt) The idea that you have to be multiparadigm to function in real world settings is a fallacy. Haskell is simply more expressive, which equips it to solve just about any problem with more clean and concise code than you're likely to get in other languages. Even if the code size stayed the same the extra safety you get from purity and strong types would be worth it alone. [1] https://www.youtube.com/watch?v=xo3zUvPsizo https://www.youtube.com/watch?v=xo3zUvPsizo
- guipsp 11y ago
  >The idea that you have to be multiparadigm to function in real world settings is a fallacy. Haskell is simply more expressive, which equips it to solve just about any problem with more clean and concise code than you're likely to get in other languages. Even if the code size stayed the same the extra safety you get from purity and strong types would be worth it alone. Haskell is also not used any major project. It's an academia language.
  - tormeh 11y ago
    I think that has more to do with syntax and the overdependence on rote memorization that it requires, and less to do with the actual concepts themselves. Lots of things are silly in Haskell-land, but that's mostly because it's made to be elegant or math-like, if I've understood it correctly. That said, multiparadigmatic programming is awesome, we just have to find some way to give as much information to the compiler in imperative instructions as we do in functional. This means that imperative programming has to be tightened up quite a bit, but I don't think it would be very drastic, really.
  - e12e 11y ago
    I don't think it's quite right to say it's (still) just an academia language -- but it's absolutely marginal. I use two (three) programs implemented in haskell on a (semi)regular basis: xmonad (and xmobar) and pandoc. Other than that, I know of git-annex that is both actual programs and is in actual use. That's still more than the number of programs I use that are implemented in Arc... Haskell is academic in the sense that it is very opinionated about a few things (as this sub-thread illustrates). Lets see how Shen, Open Dylan and clojure end up doing ... (and of those, probably only clojure have meaningful contemporary systems implemented in it - so far). Maybe there's even more life left in Common Lisp (sbcl etc) or Scheme (Racket, guile w/guix nix (haskell! yay!) ...). Then there's OCaml of course...
- e12e 11y ago
  > The idea that you have to be multiparadigm to function in real world settings is a fallacy. I'm not so sure. The best solution for a subset of programmers is unlikely to be the best solution for every programmer. Somewhat like the quote about literate programming: "Jon Bentley probably hit the nail on the head when he once was asked why literate programming hasn’t taken the whole world by storm. He observed that a small percentage of the world’s population is good at programming, and a small percentage is good at writing; apparently I am asking everybody to be in both subsets." -- According to Donald Knuth http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856 While I think there is much more overlap between good programmers that write good Forth, those that write good Ada (or other procedural code), those that write good functional programs, those that bask in the glory of Smalltalk/Self (classic oo) and those that get by in java ("modern"/class-oriented oo) -- than between good technical writers and good programmers -- I think the problem is partly the same. There's no guarantee that haskell is the best tool for a 10 year old write interactive fiction, or automate his or her schedule -- and for a finance manager to manage numbers and for an engineer to write code for a robot -- or for high frequency trading... or etc. Machines don't understand Haskell anyway, only humans do. If many of us find Visual Basic or Excel or SQL easier... we probably have a need for such languages (even if I don't want to touch Visual Basic with a stick...). Multiple programming paradigms has nothing to do with computers and systems, and everything to do with human-machine interface and augmenting the capabilities of humans through computers.
GeneralMayhem 11y ago
If you wanted their side effects, they would have to be in a context that tabulates their side effects - i.e., a monad. Operations in a monadic context (I/O, mutating state, etc.) are generally not commutable - or if they are, the circumstances under which they are can be expressed in the definition of the monad. On the other hand, part of the point of Haskell is that any side effects must be made explicit, so if all you've got is a function, you can be guaranteed that there are no side effects.
wz1000 11y ago
In Haskell, there are no side effects. Any effects you care about will explicitly be part of the type. Haskell provides many combinators to combine various combinations of effectful and effect-free functions. Look into the documentation for Control.Monad to see some.

caf 11y ago

Your example of aliasing in C is a good one, because this is a case where modern C allows the programmer to give the compiler the necessary information to do a better job. The "restrict" keyword indicates that an object accessed through a given pointer argument cannot alias any other object accessed by the function.

TheLoneWolfling 11y ago
Which doesn't help when you're trying to express anything more complex. Such as "a won't alias c, but there are no other restrictions".