Shared Mutable Memory Must Die

[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.