5 ms·

I have to admit, the more I look into Haskell the less enamored I am of its syntax. Sure, it's wonderful in the common case, but when it comes to things like ve

by jeorgun 12y ago

I have to admit, the more I look into Haskell the less enamored I am of its syntax. Sure, it's wonderful in the common case, but when it comes to things like vectors or (apparently) unsafe pointer manipulation, it's practically unreadable. Something like Lisp or Python— or even C++— syntax is rarely optimal, but at least it never degenerates this totally into symbol soup.

cgag 12y ago
They don't degenerate when tryin to achieve type safety?
IsTom 12y ago
You won't see (#a,b#) in client code, that's hidden behind the facade of a library, unless you are very desperate. Nor will you use pointers.
- Nursie 12y ago
  So... this is somebody else's problem and smarter people will take care of it for me? I've never found that answer very satisfying...
  - freyrs3 12y ago
    Do you assemble your own machine code as well or do you trust that someone else has taken care of the gritty details of the assembler so that you can work at a level of abstraction higher than that?
    - bronson 12y ago
      Assembling a program into machine language is simple enough that it's easy to trust someone else to get it right. I imagine it depends on the difficulty of the problem being outsourced.
      - SoftwareMaven 12y ago
        Have you seen what optimizing compilers do? I'd hardly call that simple!
        bronson 12y ago
        Thought it was clear the OP was talking about assembly? Which, thanks to pipeline stalls and out-of-order execution is no walk in the park these days, but it's not TOO bad.
  - Dewie 12y ago
    > So... this is somebody else's problem and smarter people will take care of it for me? Smarter is your opinion. Is a library writer smarter than an app developer? Is a compiler writer smarter than a library writer? Perhaps, though I don't see how that is a given. I look at it more like; compilers will be used by more people than a single library, so it pays off to spend more time on developing, testing, debugging, etc. it than a library. A library might be used by more clients than a single app, so it pays off to use more time on it and optimize it, which might include unsafe features. If people that work "further down the stack" are necessarily smarter than those in the upper layers, we programmers must be pretty stupid... :)
    - alextgordon 12y ago
      Bjarne says in his book that he wanted to make C++ implementable with just nothing more complicated than a linear search. Things didn't quite work out that way, but it's a good principle for language designers to live by. If you don't know how to implement the languages you use, then either you or the language is at fault, IMO.
      - Dewie 12y ago
        That's a pretty absolute rule to live by. I think there is merit in the idea - it's nice to be able to easily know what is going on. If I was making a language - and I could do as I wanted - I would make try to make the compilation step fully "debuggable", ie being able to step through the whole compilation, even stop and modify things, mess around, etc. Compilers seem awfully black-boxy, in general. (Forth might be one of the ultimate expressions of the principle of a fully understandable compiler - Chuck Moore even hesitates to call it a compiler.) On the other hand, you can get very far without really losing anything if you just know the semantics of the language, and leave the nitty-gritty to the compiler. C is supposed to be simple, but given how big of a deal optimizing compilers for C seems to be, it's not straightforward to make a proper, industrial standard compiler for the language (perhaps both with regards to competition and effort). And yet C is supposedly just a thinly-veiled abstraction over assembly ("supposedly" since I'm not a C programmer). I for one welcome giant, too-big-to-understand-for-one-person compilers, as long as they are awesome at what they do. Simple programming language? Then you seem to get complicated design patterns. Simple semantics ala "everything is X" (immutable, object, ...)? Then you get complicated work-around in the places where you can't/don't want immutability/objects... . Simple compiler? Lot's of responsibility and mental overhead for each individual programmer, in a sense duplicating a lot of the effort that could be handled by a team of compiler writers, once.
  - IsTom 12y ago
    Works for libc.
freyrs3 12y ago
This code here isn't representative of any Haskell end-users would write, it has a whole other syntax (LiquidHaksell) layered on top of it that augments the type system and it imports the internals of GHC.* libraries to work with the base machine types. The strength of GHC's implementation is that a lot of the compiler internals are directly accessible in the frontend source language with certain language extensions enabled (GHC.Exts, GHC.Prim, ``-XMagicHash``). That said the code here is more about the implementation of the vector library internals at a very low level that deals with machine types. If you're a Python user this is effectively equivalent to reading the NumPy internals which I can tell you first hand are an ungodly mess of preprocessor macros and code generation gone horribly wrong and far worse than this.
maaku 12y ago
You should expect code that breaks out of the safe environment the language tries to build for you to be ugly. To be unworkable even. If it is not, then that means that the language has been optimized for unsafe usage, and whatever clean syntax was chosen could have been used better somewhere else.
rdtsc 12y ago
Just curious what would you think has good syntax that you would enjoy? I always thought Python to be one of the most approachable for example. Then maybe C. I also like Erlang. More in depth: Python is closest to pseudocode. As in, if I sat down and wrote an algorithm, in some pseudocode language, it would probably look a lot like Python. I like C and Erlang because they are relatively small and self-consistent. Think of it as chess, there are not too many rules of the game, but the game can still be very interesting. Erlang is a good example of a practical functional language. I really like pattern matching in it. I don't like C++ for example because the syntax is too complex. Too many exceptions, rules and corner cases. I don't have an opinion on Lisp/Scheme/Clojure/Haskell just because I haven't tried using them in depth.

by jeorgun 12y ago

cgag 12y ago

They don't degenerate when tryin to achieve type safety?

IsTom 12y ago

You won't see (#a,b#) in client code, that's hidden behind the facade of a library, unless you are very desperate. Nor will you use pointers.

Nursie 12y ago
So... this is somebody else's problem and smarter people will take care of it for me? I've never found that answer very satisfying...
- freyrs3 12y ago
  Do you assemble your own machine code as well or do you trust that someone else has taken care of the gritty details of the assembler so that you can work at a level of abstraction higher than that?
  - bronson 12y ago
    Assembling a program into machine language is simple enough that it's easy to trust someone else to get it right. I imagine it depends on the difficulty of the problem being outsourced.
    - SoftwareMaven 12y ago
      Have you seen what optimizing compilers do? I'd hardly call that simple!
      - bronson 12y ago
        Thought it was clear the OP was talking about assembly? Which, thanks to pipeline stalls and out-of-order execution is no walk in the park these days, but it's not TOO bad.
- Dewie 12y ago
  > So... this is somebody else's problem and smarter people will take care of it for me? Smarter is your opinion. Is a library writer smarter than an app developer? Is a compiler writer smarter than a library writer? Perhaps, though I don't see how that is a given. I look at it more like; compilers will be used by more people than a single library, so it pays off to spend more time on developing, testing, debugging, etc. it than a library. A library might be used by more clients than a single app, so it pays off to use more time on it and optimize it, which might include unsafe features. If people that work "further down the stack" are necessarily smarter than those in the upper layers, we programmers must be pretty stupid... :)
  - alextgordon 12y ago
    Bjarne says in his book that he wanted to make C++ implementable with just nothing more complicated than a linear search. Things didn't quite work out that way, but it's a good principle for language designers to live by. If you don't know how to implement the languages you use, then either you or the language is at fault, IMO.
    - Dewie 12y ago
      That's a pretty absolute rule to live by. I think there is merit in the idea - it's nice to be able to easily know what is going on. If I was making a language - and I could do as I wanted - I would make try to make the compilation step fully "debuggable", ie being able to step through the whole compilation, even stop and modify things, mess around, etc. Compilers seem awfully black-boxy, in general. (Forth might be one of the ultimate expressions of the principle of a fully understandable compiler - Chuck Moore even hesitates to call it a compiler.) On the other hand, you can get very far without really losing anything if you just know the semantics of the language, and leave the nitty-gritty to the compiler. C is supposed to be simple, but given how big of a deal optimizing compilers for C seems to be, it's not straightforward to make a proper, industrial standard compiler for the language (perhaps both with regards to competition and effort). And yet C is supposedly just a thinly-veiled abstraction over assembly ("supposedly" since I'm not a C programmer). I for one welcome giant, too-big-to-understand-for-one-person compilers, as long as they are awesome at what they do. Simple programming language? Then you seem to get complicated design patterns. Simple semantics ala "everything is X" (immutable, object, ...)? Then you get complicated work-around in the places where you can't/don't want immutability/objects... . Simple compiler? Lot's of responsibility and mental overhead for each individual programmer, in a sense duplicating a lot of the effort that could be handled by a team of compiler writers, once.
- IsTom 12y ago
  Works for libc.

freyrs3 12y ago

This code here isn't representative of any Haskell end-users would write, it has a whole other syntax (LiquidHaksell) layered on top of it that augments the type system and it imports the internals of GHC.* libraries to work with the base machine types. The strength of GHC's implementation is that a lot of the compiler internals are directly accessible in the frontend source language with certain language extensions enabled (GHC.Exts, GHC.Prim, ``-XMagicHash``). That said the code here is more about the implementation of the vector library internals at a very low level that deals with machine types. If you're a Python user this is effectively equivalent to reading the NumPy internals which I can tell you first hand are an ungodly mess of preprocessor macros and code generation gone horribly wrong and far worse than this.

maaku 12y ago

You should expect code that breaks out of the safe environment the language tries to build for you to be ugly. To be unworkable even. If it is not, then that means that the language has been optimized for unsafe usage, and whatever clean syntax was chosen could have been used better somewhere else.

rdtsc 12y ago

Just curious what would you think has good syntax that you would enjoy? I always thought Python to be one of the most approachable for example. Then maybe C. I also like Erlang. More in depth: Python is closest to pseudocode. As in, if I sat down and wrote an algorithm, in some pseudocode language, it would probably look a lot like Python. I like C and Erlang because they are relatively small and self-consistent. Think of it as chess, there are not too many rules of the game, but the game can still be very interesting. Erlang is a good example of a practical functional language. I really like pattern matching in it. I don't like C++ for example because the syntax is too complex. Too many exceptions, rules and corner cases. I don't have an opinion on Lisp/Scheme/Clojure/Haskell just because I haven't tried using them in depth.