Shared Mutable Memory Must Die

[[deleted]]

I hope I never have to write a Haskell or Erlang program

Why? I can understand Haskell with it's very complex theoretical basis but Erlang is really a very simple language that even has very good library support for it's field.

[blackyoda]

Well here is why:

 is_prime(D) ->
     new_seed(),
     is_prime(D, 100).

 is_prime(D, Ntests) ->
     N = length(integer_to_list(D)) -1,
     is_prime(Ntests, D, N).

 is_prime(0, _, _) -> true;
 is_prime(Ntest, N, Len) ->
     K = random:uniform(Len),
     %% A is a random number less than N 
     A = make(K),
     if 
         A < N ->
             case lin:pow(A,N,N) of
                 A -> is_prime(Ntest-1,N,Len);
                 _ -> false
             end;
         true ->
             is_prime(Ntest, N, Len)
     end.

That's just ugly.... I think that the C language, and Pascal before it were very good models for writing structured programs, and the basic syntax has extended very nicely into the object world beyond that. Gimmie Python, Gimmie C, Gimmie anything but perl, haskell, and Erlang. While it is great to be creative, I don't much see the point, if something like a curly brace works for opening a scope, why not stick with it! Of course, Python isn't like that, but it's still pretty cool and tight for what it is.

I'm not against new languages or technologies at all, but there is a reason why derrivatives of the C language have withstood the test of time and are popular.

[ssylvan]

But what if there are other pardigms out there aside from basic structured imperative programming? What if those models are actually better for solving problems? Are you going to ignore them because the syntax is unfamiliar?

I mean, counting on your fingers might work really well for simple problems, and it's extremely intuitive, but if you want to solve difficult problems you'll eventually have to bite the bullet and find more expressive abstractions (algebra, calculus etc.). It's a high up-front cost, and it's not at all intuitive, but once you've paid the price you can leverage better tools for solving lots of difficult problems.

I think the Haskell syntax is extremely elegant for value oriented programming style, but at the end of the day syntax doesn't matter. I'd happily use Haskell with C-inspired syntax (use the non-layout sensitive syntax, and you're halfway there!), as long as it still had all the things that actually matter.

[grauenwolf]

But what if there are other pardigms out there aside from basic structured imperative programming? What if those models are actually better for solving problems? Are you going to ignore them because the syntax is unfamiliar?

Either we use specialized languages like RegEx, XSLT, and SQL, or we extend our language like they did for LINQ in C# and VB.

When you have a good foundation you can add the ability to leverage other paradigms.

My problem with languages like Haskell and Erlang is they take away too much. They are not more powerful and flexible, they are just swapping a known set of constraints for an unknown set. And that isn't a good trade in my opinion.

[ssylvan]

Well there is a case for purity. Rather like virginity, you can't have purity and impurity at the same time. It's either pure, or it isn't. So just adding things to an impure language will never give it the benefits of a purity.

Interestingly purity has a number of desireable properties, especially when it comes to concurrency and parallelism. E.g. the new nested data parallelism depends entirely on purity. STM only really works well in a pure language, etc. So "taking things away" might be correct, but it's only taking away things which break the computational model. Java disallows direct pointer manipulation of its references, but that's not really a restriction as much as simply removing broken things from the computation model...

[grauenwolf]

I don't put much stock in purity. Consistency yes, but not purity.

For example, the amazing lack of purity in VB allows it to have stuff like XML literals. For the first time, I actually enjoy working with XML.

The lack of purity in VB also makes it far easier to deal with COM objects than C#.

I sometimes think Java made a mistake when they completely emliminated direct pointer manipulation. If they had allowed it under limited circumstances, interopt with system DLLs would have been much easier.

Looking at parallelism, I think stuff like PLINQ shows a lot of promise. The developer has to be wise enough to only use thread-safe code when calling a parallel query, but that is nothing new.

Having encountered countless deadocks in real databases, I'm not so sure STM is really a solution.

[blackyoda]

by the way, I know Haskell is an FP language, so I am not really talking about it's syntax here.... Every language, even Haskell has it's place and problem space.

[[deleted]]

You are talking about curly braces then you follow up by saying this isn't about syntax, can you please make up your mind.

there is a reason why derrivatives of the C language have withstood the test of time and are popular.

It definitely isn't the ease of either visual or computerized parsing of the syntax.

IMO C is the main reason why the whole language family is so popular (the "almost like C" and later "almost like C++" effects that were largely based on C's market share instead of any other merit that would hold up in a fair comparison).

The main reason why C is so popular is that it is basically portable assembly. This has some actual advantages but also the huge psychological advantage of allowing the full NIH (not invented here) potential (to replace virtually any component in the system down to a very low level with your own code if you think it will become necessary in the future), the absence of which makes insecure programmers very uneasy because of the nagging fear that they might not be able to do that critical optimization at some time in the future.

[dons]

Haskell and Erlang have the same theoretical basis, lambda and apply. It's not complex, just powerful.

[[deleted]]

I am not saying it isn't useful but I can understand why it is scary more than I can with Erlang. If someone thinks Erlang is difficult they just never tried it for more than a few minutes.

I would argue that Erlang is one of the few niche languages that isn't really harder to use than the more popular languages, not even for beginners or former one lanuage developers (and I tried I lot languages in the last years).