I'm just trying to have a conversation around developing new (revolutionary versus evolutionary) methodologies versus modifying old ones to exploit the advancements in hardware in the most effective manner as possible. Auto-parallelization at the machine
level is pretty much science fiction without explicit support at the expressive level way up the abstraction stack.... Or is it?
Of course, throwing everything out that's been invested in for so long is unrealistic, but this is why theory is fun
It is indeed an interesting topic.
Let me express what annoys me more than anything, which is this
There is not a single platform for software development; .Net did not kill off native code dispite its all-inclusive mantra, Microsoft itself still creates a lot of native software for maximum performance; maybe this picture will change a little as the
per-machine processor count increases
This in term means that
C# and F# are awesome but
Is the "object-functional integration" good enough and does IL have the right abstractions?
Also, given a superbly expressive language like Scala
Wouldn't it be nice to be able to express a whole operating system using extremely modular, fine-grained and clean semantics (assuming better than C/C++) And is the Singularity/Sing# experiment the future for Microsoft?
This also ties into the parallelism and concurrency problem in that
It is preferable to be able to express as much code using a high level of abstraction, thereby pushing abstractions closer to the metal, to have as much code as possible yield the benefits of those abstractions and to maximize integration (IL + P/Invoke
vs C# + F#?)
Some quick thoughts from a random developer...
1) I'd like to state exactly WHY functional programming is far easier parallelized, it's not because of immutability per-se, and immutability helps, but something slightly more subtle. C++ and other compilable languages get assembled into assembly instructions,
that linear form is actually the problem. The instructions depend on instructions above other than the branch/jumps to find the final momentary code execution path. Functional languages on the other hand use LAMBDAS, which are self-contained packages of instructions
which are independent of other lambdas. The ability for one lambda/anonymous function to not rely on the others in the program other than possible data dependency's is why you can run a lambda function independent of the processor. Thus a lambda function's
instructions are at a coarse enough grain that they aren't tied together by a built-in per-CPU hardware program counter.
2) The other thing I've not understood is WHY today we are limited to a single main function!!! To me, if code entry execution point and exit points could be refrenced or indexed like a fucntion table at the beginning of the file, the binary could/should
be able to run different functions at the same time, instead of the one large main which must start at one point in code/binary and end at specified exit/exception points. This is an alternate way in my head I've been wondering could be a different approach
to the "thread".
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.