|
On August 28 2013 19:39 3FFA wrote:
I'm wondering if anyone could provide a brief comparison of something done in Haskel vs another language like C or Java so I could actually see the difference?
There's a multitude of sources online for haskel code if you want to see how it looks, the Haskell wikipedia page for example: http://en.wikipedia.org/wiki/Haskell_(programming_language)
Unless you have some experience with functional languages though, it will probably look like some black magic spell though, functional code usually looks very different from what you might be used to.
|
On August 28 2013 18:19 artynko wrote:Show nested quote +On August 28 2013 17:32 rabidch wrote:On August 28 2013 16:34 artynko wrote:
For me the problem with functional languages is that you can't do "proper" architecture using it (or we don't know how to do it yet)
For example I did a fairly decent sized production software that was written in Erlang (another functional language) it was awesome for what it did, it had probably 10 times less lines of code that if I have written it in anything conventional, but at the end when I was trying to juggle 30 different actors I was starting to feel that a miss the nice architecture I would had had in OO language.
I still love the concepts that a functional language brings mainly immutability and the way concurrency is handled there. When Java 8 comes I will jam that one down my teams throats faster then light (oh closures & functional collection manipulation) but still if anyone asked me if they should learn something like Haskell I would say hell no, learn Scala
what do you mean by architecture? The standard approach that everyone uses to separate stuff in oo, services, daos, domain object, facades having all the oo patters at yours disposal, when I was doing Erlang I had problems with how do I want to connect all the different parts of the application together, when I coded it in similar fashion as I was used from OO it usually did create either circular references or some horrible unclear dependencies. In the end I ended up with a tree like structure that resembled something you would create using OO and the standard tiered architecture but the "levels" of the tree didn't always contain processes that belonged together and the tree had way more levels . Then when I returned back to this code after couple of months I was completely lost and had no idea where the different processes belong and how deep in the tree they are. If you compare this to OO even when I look at my old code and want to add new stuff there I know where to start, you just look for the service in question and go on from there. It just feels like there is no knowledge how to do stuff in functional languages the "right" way compared to OO where we already know how to create something that is manageable and every developer will understand it when he sees it for the first time
interesting, i've never had that problem, but i dont know anything about erlang, most of my experience is in ocaml and haskell. ocaml/F# has a number of object features while haskell isnt oo but is pretty clear about structure through modules and its type system, but its very expressive type system can be an absolute pain to learn... its compiler error messages are almost never helpful.
personally i feel that if the code feels more natural to be imperative or OOP or functional then it should probably be in such a language...
On August 28 2013 19:39 3FFA wrote:
I'm wondering if anyone could provide a brief comparison of something done in Haskel vs another language like C or Java so I could actually see the difference?
http://en.literateprograms.org/LiteratePrograms:Welcome
what the above poster says too
|
On August 28 2013 19:39 3FFA wrote:
I'm wondering if anyone could provide a brief comparison of something done in Haskel vs another language like C or Java so I could actually see the difference?
From what I remember when I was looking at it yesterday
Java -> "astring".substring(1);
Haskell -> tail "astring" or drop 1 "astring"
Mainly what is cool about functional languages is the way you can do cycles with pattern matching so this java code
private void output(String a) {
while (a.lenght > 0) {
sysout(a);
a = a.substring(1);
}
}
can be rewritten like this, you suddenly don't mess up with the 'a' object and it is very clear when the end of the "cycle" is
output([]) -> ok
output(a) -> prinnt(a), output(tail(a));
then when you type somwthere ouput("keke"), it will look at the various heads for the output function and patter match the value so the first one (outuput([])) is only matched when there is blank array as argument so it skips that one and uses the other one to print the first character, and then recursively calls itself again with the remaining characters
|
Ha, funny that you focused much on object to object messaging, which I just moments ago finished posting some slides for a lecture I gave at my university. http://www.randygaul.net/2013/09/02/powerful-c-messaging/
Really it sounds to me like Haskell is just enforcing some good programming practices, which can be achieved by good programmers in C++ (as seen by my link). To me the solution to a lot of problems is to just have good programmers use C++, instead of forcing bad programmers to write better code. But of course good programmers are rare and hard to come by.
|
I read up on some haskell after reading the OP and it's quite a fascinating language, definitely my favorite functional language so far (tried F# and scheme in the past). It's the first language where writing recursive functions makes perfect sense to me (because the syntax is beautiful), and it blew my mind when I realized haskell compiles to machine code and can, in theory at least, be faster than C++ if you write it really well.
It's a downright shame that side-effect handling takes such a weird form... pure programming is cool, but the syntax for IO and such things in haskell just becomes really confusing and uncomfortable.
|
On September 03 2013 05:53 CecilSunkure wrote:Ha, funny that you focused much on object to object messaging, which I just moments ago finished posting some slides for a lecture I gave at my university. http://www.randygaul.net/2013/09/02/powerful-c-messaging/Really it sounds to me like Haskell is just enforcing some good programming practices, which can be achieved by good programmers in C++ (as seen by my link). To me the solution to a lot of problems is to just have good programmers use C++, instead of forcing bad programmers to write better code. But of course good programmers are rare and hard to come by.
its not fair to either language to talk about it simply like that, i recommend at least dabbling in some haskell to understand the viewpoint where carmack is talking from. hes not saying haskell is all that and everything, but looking at certain problems and code from a different viewpoint can be enlightening
On September 03 2013 15:35 Tobberoth wrote:
I read up on some haskell after reading the OP and it's quite a fascinating language, definitely my favorite functional language so far (tried F# and scheme in the past). It's the first language where writing recursive functions makes perfect sense to me (because the syntax is beautiful), and it blew my mind when I realized haskell compiles to machine code and can, in theory at least, be faster than C++ if you write it really well.
It's a downright shame that side-effect handling takes such a weird form... pure programming is cool, but the syntax for IO and such things in haskell just becomes really confusing and uncomfortable.
it is a really cool and fascinating language, but for the same reasons impractical for the all but a fraction of the industry. sure is interesting to write things in it though. also the IO is weird yes, but if u get used to monads its quite natural, plus there are ways you can cheat around it 
i thought F# can compile to machine code? i've used ocaml quite a bit, haskell isnt optimized that well with respect to overhead (theory can only go so far by itself), so ocaml is still generally faster, and F# is also very fast (maybe even faster?), since currently F# is still very close to ocaml
|
Hmm, I can find no resource on compiling F# to native, Visual F# obviously compiles to CIL. Not that it's such a huge deal, compiling to native isn't the massive speedgain it used to be since everything does just-in-time compilation nowadays.
|
That's correct. There are no F#-to-native code compilers out there. All of them target the .NET framework/CIL.
Haskell can actually be surprisingly speedy in certain situations, e.g.,
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=all
This is especially true if you know how to exploit strict evaluation and various Haskell quirks about optimization. Where Haskell definitely falters is space usage simply because lazy evaluation means that a lot of computation is left "suspended", waiting to be executed at a yet-to-be-determined time.
The way that side-effects are handled in Haskell is necessary insofar as side-effects destroy referential transparency which is where Haskell gains much of its properties. Its purity guarantees are even stronger than OCaml/F# (which allow "un-scoped" mutation via ref cells and/or objects) which allows for even greater allowance to rely on types to guide development.
One example of how you can rely on types more in Haskell than traditional languages is the encoding of domain-specific languages whose own type properties are checked by Haskell at compile-time. For example, here is a definition of a small calculator language with integers, booleans, addition, greater-than-or-equal comparison, and conditionals (*1):
{-# LANGUAGE KindSignatures, GADTs #-}
data Exp :: * -> * where
IConst :: Int -> Exp Int
BConst :: Bool -> Exp Bool
Add :: Exp Int -> Exp Int -> Exp Int
GTE :: Exp Int -> Exp Int -> Exp Bool
If :: Exp Bool -> Exp a -> Exp a -> Exp a
The type Exp a denotes expressions whose underlying Haskell value are a (i.e., it is a polymorphic type). Examples of terms constructed in this little language are:
IConst 0 -- 0
BConst True -- True
Add (IConst 1) (IConst 1) -- 1 + 1
If (GTE (Add (IConst 1) (IConst 1)) (IConst 2)) (IConst 42) (IConst 6)
-- if (1 + 1 >= 2) then 42 else 6
Notably, the definition of Exp above prevents from writing ill-typed terms in this sub-language. For example:
*Main> Add (IConst 0) (BConst False)
<interactive>:8:17:
Couldn't match type `Bool' with `Int'
Expected type: Exp Int
Actual type: Exp Bool
In the return type of a call of `BConst'
In the second argument of `Add', namely `(BConst False)'
In the expression: Add (IConst 0) (BConst False)
That is, the definition of the Add term requires two Exps that evaluate to Haskell Ints. Similarly
If (BConst True) (IConst 0) (BConst False)
is also ill-typed because If requires that the two branches produce the same type of value.
Note that if you tried to implement this in Java naively (*2), e.g.,:
public class Exp { }
public class IConst extends Exp { public int i; }
public class BConst extends Exp { public boolean b; }
public class Add extends Exp { public Exp e1; public Exp e2; }
public class GTE extends Exp { public Exp e1; public Exp e2; public boolean b; }
public class If extends Exp { public Exp b; public Exp e1; public Exp e2; }
There is nothing stopping you from having an instance of an Add term whose two sub-expressions are booleans rather than integers. You would need to check either at construction or when the expression that the expressions are indeed of the correct type.
Finally, to close here's an example of how you'd use this little language in Haskell. The eval function takes a built-up up Exp, evaluates it, and returns the corresponding Haskell value:
eval :: Exp a -> a
eval (IConst i) = i
eval (BConst b) = b
eval (Add e1 e2) = eval e1 + eval e2
eval (GTE e1 e2) = eval e1 + eval e2
eval (If b e1 e2) = if eval b then eval e1 else eval e2
Running this function on each of the (good) examples above produces the proper Haskell value:
*Main> eval $ IConst 0
0
*Main> eval $ Add (IConst 1) (IConst 1)
2
*Main> eval $ If (GTE (Add (IConst 1) (IConst 1)) (IConst 2)) (IConst 42) (IConst 6)
42
(*1): This example uses an advanced feature of Haskell called Generalized Algebraic Datatypes or GADTs. A GADT is a datatype whose constructors' return types can be freely chosen.
(*2): This example can be encoded using Java generics and C++ templates. However, more complicated examples of GADTs are not possible using Java generics and C++ templates as-is. Both languages require additional features, i.e., type parameter constructors, to emulate the full functionality of GADTs.
|
Most programmers are too lazy or stupid to see the benefits in using good programming languages. Until then, Java, C++, PHP, etc. will continue to reign supreme. The non-remedial will look into Standard ML, Haskell, OCaml and Scheme, to some extent. The three former-most in that order. The latter-most is just fun and has a lot of good documentation, but I've fallen out of favor with weakly typed languages.
|
|
|
|
|
|
EPT
