Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[unperson]

Thanks for the replys, I'll dive into C# then :-)
Btw why do you (FACM) think no major title would be made with C#?

[Veroule]

For anyone looking to learn thier first language I would have this small advice.  Choose a compiled language
that is relatively new and has a strong design for parallel processing.

When I say "relatively new" I mean something that has been around enough years to be well documented
and has many good libraries.  For example when C++ first came into popularity its standard libraries
were little more then wrappers for the standard C functions and often produced inefficient code.   Obviously
it was too new at that point.  Pascal on the other hand is too old; even though it has excellent libriaries, it
is no longer used widely enough to be a good choice of first language.

The reason for choosing based on parallel processing is because it is the direction computing is headed and
likely will continue to be headed for many years.  The choice of first language will always color how you think
about programming and having your thinking aligned with where computing will be for the next 15 years is a
good idea.  For example my first language was assembly; iterators look like silly constructs to me,
they look like a complex way of saying something like this.

Spoiler (click to show/hide)

XOR ECX,ECX
:L
PUSH ECX
LEA EAX,00407b23
CALL DWORD PTR [EAX]
INC ECX
TEST EAX,EAX
JE :L
RET

I am stuck with such thoughts because that was my first language.  Parallel processing was equally fun, yes
we did it on 8bit machines.

After saying all that I think I would suggest Haskell as a good first language.

[kuro_suna]

So how exactly does functional programming make parallel processing easier, at the end of the day the challenge is how to split up a job while keeping them independent enough you don't have too many threads all paused waiting from one thread to finish. More specifically how is functional programming better than the more common model of strong OOP plus thread pools embraced by C# and java (also c++ but far more painful to make work).

[jfs]

Pure functional languages help because it allows the compiler to mathematically reason about interdependencies in data. That's about it, really. I don't know any real details, though.

[FACM]

Thanks for the replys, I'll dive into C# then :-)
Btw why do you (FACM) think no major title would be made with C#?

Mostly because C# is managed code, which takes a lot of control out of the developer's hands. It's faster to write with managed code, but you can't choose to do/not do something a certain way for speed benefits, you're stuck with the managed function's way of doing things. C# is also fairly unportable, which matters to some developers more than others.

[Baughn]

So how exactly does functional programming make parallel processing easier, at the end of the day the challenge is how to split up a job while keeping them independent enough you don't have too many threads all paused waiting from one thread to finish. More specifically how is functional programming better than the more common model of strong OOP plus thread pools embraced by C# and java (also c++ but far more painful to make work).

In the case of Haskell, it's a combination of quite a lot of factors. In no particular order..

- The type system is powerful enough to encode a function's side-effectfulness, or lack of same. If there are no side-effects, then there are combinators (basically, functions acting on functions) you can use that change the parallel-ness of the program while guaranteeing that the semantics are the same.

- Lazy evaluation can be seen as delaying execution of a function call until its return value is needed. This process is thread-safe, so if you use the same value in two threads it'll still only be evaluated once - the first time it's used, not when it's made.

- Software Transactional Memory allows a sort of in-memory database, which (while more expensive than mutexes) lets you very easily create atomic operations that aren't subject to race conditions, deadlocks or any of the other usual problems. I really can't overstate the importance of this one; Haskell's STM implementation beats the pants off any other I've seen.

- The garbage collector is smart enough to detect deadlocks and print an error, optionally with a backtrace

- Haskell uses lightweight threads. *Very* lightweight. You can have hundreds of thousands without the runtime choking, their creation costs little more than the creation of a mutex (and about a hundred bytes of memory), and it'll automatically distribute them across CPU cores. No need for thread pooling.

- Excellent pattern-matching syntax makes message-passing modes of programming convenient

- It's impossible to write a race condition that actually corrupts memory. Operations may get run out of order, but your program won't crash; they'll still be in some order.

- Haskell libraries can be assumed to be thread-safe, because making them so is easier than not doing so. You have to really *try* to write unsafe code.

- And, yes, there are some experimental compiler optimizations that attempt to automatically create parallel code, with a minimum of programmer assistance. Data parallel haskell, in particular. It's not mature yet, but shows great promise.


If you just read each element on this list by itself, you might think it's not as great as all that, but remember: They all work together. Synergy is not just manager-speak.

[eerr]

So how exactly does functional programming make parallel processing easier, at the end of the day the challenge is how to split up a job while keeping them independent enough you don't have too many threads all paused waiting from one thread to finish. More specifically how is functional programming better than the more common model of strong OOP plus thread pools embraced by C# and java (also c++ but far more painful to make work).

Threading Haskell has no such "this function must trigger first" problems, because it either triggers first, triggers after, or has no bearing on the timing of another function.
(I'm talking the Math/data functions, not Input/Output)
 So for functions X, and Y
1. Either X must happen before Y
2. Or Y must happen before X
3.Or X and Y are not directly related, and will never share anything together, so you can guarrentee they run concurrently.(they might subsequently both hang waiting on a piece of data they both require, but that is a different issue, of X VS Z, and Y VS Z which is already accounted for in 1. or 2.)


OOP makes this more difficult, because X requires Y, and Y requires X are not clearly defined by the entire way you write the program.
So for functions X, and Y
1. X or Y could happen first, or multiple times, in multiple orders.
2. For X, there is not even always guarentee that Y will or will not run, or has run, or whatnot.
For the programmer and the compiler, sorting these complicated functions involve serious work, and any sort of complexity adds more to the overhead.

Thanks for the replys, I'll dive into C# then :-)
Btw why do you (FACM) think no major title would be made with C#?

Mostly because C# is managed code, which takes a lot of control out of the developer's hands. It's faster to write with managed code, but you can't choose to do/not do something a certain way for speed benefits, you're stuck with the managed function's way of doing things. C# is also fairly unportable, which matters to some developers more than others.

Isn't C# portable to any system on which CLR runs?
As well, can't developers write their own managed functions in C++?

[LordZorintrhox]

So how exactly does functional programming make parallel processing easier, at the end of the day the challenge is how to split up a job while keeping them independent enough you don't have too many threads all paused waiting from one thread to finish. More specifically how is functional programming better than the more common model of strong OOP plus thread pools embraced by C# and java (also c++ but far more painful to make work).

Pure functional languages help because it allows the compiler to mathematically reason about interdependencies in data. That's about it, really. I don't know any real details, though.

Yes, because of the way it works, FP would lend itself to parallelism, though I have honestly never thought of it.  I can see how it would work, but I am having a terrible time trying to explain it.  It sorta boils down to how FP and Imperitive languages execute:

Functional

Code: [Select]

foo(bar(gaz()))

Imperative

Code: [Select]

foo()
bar()
gaz()

The first has no notion of a program state; it says explicitly what the result will be, that being the return value of foo().  You cannot, under general circumstances, call multiple things one after another.

The second does have a notion of a program state.  You can use phrases like "after I call foo()", etc., and after you do call foo(), who knows what the state of the program will be.  Anything could have changed.

Because functional programming generally ignores the idea of state, parallelism is far easier because threads can't exactly collide with each other trying to access data, like they can in C/C++.  That is not to say you can't hack the general behavior of one into the other; I've done it, it is just a little painful at times.

Now Haskell...that is in the category of voodoo.  It is cool, and there are plenty of awesome things it lets you do, lazy evaluation alone being pretty cool.  Its literally like telling the compiler "hey, this is exactly how to do this" on a very high level, and then it does it.

If there is a question of what language to learn first...hmm.  The most applicable is probably Python, because:

- most big languages have a C-like syntax, which though different in the details, is effectively like Python's
- since white space is syntactically important, you are forced to get into the habit of well formatted code
- garbage collection
- objects, which is a must for fun things like games
- tuples so you can return multiple things from a function
- a nice insulating layer between you and your hardware/memory
- implicit typing; I think it is good for a beginner because, although it will cause you some heartache, you have to check what kind of stuff you are passing around and those skills are good for higher-powered stuff like C where you can override the type checker

Any other intro-type language has it's own set of issues for newbies: non-standard syntax, surprising behavior, mathematical behavior (which not everyone gets, mind you), and sometimes just general badness.

Also, prototyping in Python is the most productive method of development in my opinion.  It is like programming duct tape: you just sit down and get something working real fast, then can analyze how it works so you can implement it in something else.

[unperson]

I looked into some beginner Haskell tutorial because all the good things people say about it here :-). So far looks realy nice, (well I can only compare it to my minimal c# knowledge).
Thanks for the advices, realy helpfull.

[Leperous]

I have to learn Python for work - and figuring out pygame on the side - anyone have much game-design experience with it, esp. with regards to tile-based games? Obviously it's going to be slow and clunky if you're using it for everything instead of interfacing with C, but it seems excellent for AI, and in any case who needs 100 dwarves stealing your CPU when you really only use ~20 :p

Also I wonder if any of you have tried applying your Haskell to solving some maths? Seems to me like an excellent way to learn a new language (got me very good at Mathematica).

[cephalo]

I've been a hobbyist programmer since Commodore 64 BASIC, and in recent years I've used C++, Python and C#.  C++ does allow you to paint yourself into corners, but if you know how to OOP it's a fine language. I gotta say I friggen LOVE C#. Using it for fun in the last few years has made me a better programmer. If I did go back to C++ I would do it a hundred times better now that I have the C# experience. I now understand that my objects need to do their thing without knowledge of their environment. They give information while demanding as little as possible.

My latest C# project took me a little over a month. I started PerfectWorldDF (in my sig) about a week after DF2010 hit. 'Windows only' is definately a big minus but there's no other way I know to make an application like that in so short a time. If anyone knows a cross platform way throw up an app with such rich GUI, I would definately like to look into it.

[kuro_suna]

The mono project (open source cross platform .net runtime) had some problems with earlier versions but works fairly well now, that and the ability to compile many languages like python and ruby to .net bytecode makes me think its going to be the next standard language framework.