X
Xah Lee
might be interesting.
〈Guy Steele on Parallel Programing〉
http://xahlee.org/comp/Guy_Steele_parallel_computing.html
--------------------------------------------------
Guy Steele on Parallel Programing
Xah Lee, 2011-02-05
A fascinating talk by the well respected computer scientist Guy
Steele. (famously known as one of the author of Scheme Lisp)
How to Think about Parallel Programming: Not! (2011-01-14) By Guy
Steele. @ http://www.infoq.com/presentations/Thinking-Parallel-Programming
The talk is a bit long, at 70 minutes. The first 26 minutes he goes
thru 2 computer programs written for 1970's machines. It's quite
interesting to see how software on punch card works. For most of us,
we never seen a punch card. He actually goes thru it “line by lineâ€,
actually “hole by holeâ€. Watching it, it gives you a sense of how
computers are like in the 1970s.
At 00:27, he starts talking about “automating resource managementâ€,
and quickly to the main point of his talk, as in the title, about what
sort of programing paradigms that are good for parallel programing.
Here, parallel programing means solving a problem by utilizing
multiple CPU or nodes (as in clusters or grid). This is important
today, because CPU don't get much faster anymore; instead, each our
computer are getting more CPU (multi-core).
In the rest 40 min of the talk, he steps thru 2 programs that solves a
simple problem of splitting a sentence into words. First program is
typical sequential style, using do-loop (accumulator). The second
program is written in his language Fortress, using functional style.
He then summarizes a few key problems with traditional programing
patterns, and introduces a few critical programing patterns that he
thinks is critical for programing languages to automate parallel
computing.
In summary, as a premise, he believes that programers should not worry
about parallelism at all, but the programing language should
automatically do it. Then, he illustrates that there are few
programing patterns that we must stop using, because if you do write
your code in such paradigm, then it would be very hard to parallelize
the code, either manually or by machine AI.
If you are a functional programer and read FP news in the last couple
of years, his talk doesn't cover much new. However, i find it very
interesting, because:
* â‘ This is the first time i see Guy Steele talk. He talks
slightly fast. Very bright guy.
* â‘¡ The detailed discussion of punch card code on 1970's machine
is quite a eye-opener for those of us who's not in that era.
* â‘¢ You get to see Fortress code, and its use of fancy unicode
chars.
* â‘£ Thru the latter half of talk, you get a concrete sense of some
critical “do's ＆ don'ts†in coding paradigms about what makes
automated parallel programing possible or impossible.
In much of 2000s, i did not understand why compilers couldn't just
automatically do parallelism. I thought about it in 2009, and realized
why. See: Why Must Software Be Rewritten For Multi-Core Processors?.
--------------------
Parallel Computing vs Concurrency Problems
Note that parallel programing and concurrency problem are not the same
thing.
Parallel programing is about writing code that can use multiple CPU.
Concurrency problems is about problems of concurrent computations
using the same resource or time (e.g. race condition, file locking).
See: Parallel computing â—‡ Concurrency (computer science)
--------------------
Fortress ＆ Unicode
It's interesting that Fortress language freely uses unicode chars. For
example, list delimiters are not the typical {} or [], but the unicode
angle bracket 〈〉. (See: Matching Brackets in Unicode.) It also uses
the circle plus ⊕ as operator. (See: Math Symbols in Unicode.)
I really appreciate such use of unicode. The tradition of sticking to
the 95 chars in ASCII of 1960s is extremely limiting. It creates
complex problems manifested in:
* String Escape mechanism (C's “\nâ€, widely adopted.)
* Complex delimiters (Python's triple quotes and perl's variable
delimiters q() q[] q{} m//, and heredoc. (See: Strings in Perl and
Python â—‡ Heredoc mechanism in PHP and Perl.)
* Crazy leaning toothpick syndrome, especially bad in emacs regex.
* Complexities in character representation (See: Emacs's Key
Notations Explained (/r, ^M, C-m, RET, <return>, M-, meta) â—‡ HTML
entities problems. See: HTML Entities, Ampersand, Unicode, Semantics.)
* URL Percent Encoding problems and complexities: Javascript
Encode URL, Escape String
All these problems occur because we are jamming so many meanings into
about 20 symbols in ASCII.
See also:
* Computer Language Design: Strings Syntax
* HTML6: Your JSON and SXML Simplified
Was this page useful to you?
Also, almost all of today's languages do not support unicode in
function or variable names, so you can forget about using unicode in
variable names (e.g. α=3) or function names (e.g. “lambda†as “λ†or
“function†as “ƒâ€), or defining your own operators (e.g. “⊕â€).
(Exceptions i know works well in practice are: Mathematica,
Javascript, Java, Emacs Lisp. See: Unicode Support in Ruby, Perl,
Python, Emacs Lisp.)
Xah ∑ http://xahlee.org/
〈Guy Steele on Parallel Programing〉
http://xahlee.org/comp/Guy_Steele_parallel_computing.html
--------------------------------------------------
Guy Steele on Parallel Programing
Xah Lee, 2011-02-05
A fascinating talk by the well respected computer scientist Guy
Steele. (famously known as one of the author of Scheme Lisp)
How to Think about Parallel Programming: Not! (2011-01-14) By Guy
Steele. @ http://www.infoq.com/presentations/Thinking-Parallel-Programming
The talk is a bit long, at 70 minutes. The first 26 minutes he goes
thru 2 computer programs written for 1970's machines. It's quite
interesting to see how software on punch card works. For most of us,
we never seen a punch card. He actually goes thru it “line by lineâ€,
actually “hole by holeâ€. Watching it, it gives you a sense of how
computers are like in the 1970s.
At 00:27, he starts talking about “automating resource managementâ€,
and quickly to the main point of his talk, as in the title, about what
sort of programing paradigms that are good for parallel programing.
Here, parallel programing means solving a problem by utilizing
multiple CPU or nodes (as in clusters or grid). This is important
today, because CPU don't get much faster anymore; instead, each our
computer are getting more CPU (multi-core).
In the rest 40 min of the talk, he steps thru 2 programs that solves a
simple problem of splitting a sentence into words. First program is
typical sequential style, using do-loop (accumulator). The second
program is written in his language Fortress, using functional style.
He then summarizes a few key problems with traditional programing
patterns, and introduces a few critical programing patterns that he
thinks is critical for programing languages to automate parallel
computing.
In summary, as a premise, he believes that programers should not worry
about parallelism at all, but the programing language should
automatically do it. Then, he illustrates that there are few
programing patterns that we must stop using, because if you do write
your code in such paradigm, then it would be very hard to parallelize
the code, either manually or by machine AI.
If you are a functional programer and read FP news in the last couple
of years, his talk doesn't cover much new. However, i find it very
interesting, because:
* â‘ This is the first time i see Guy Steele talk. He talks
slightly fast. Very bright guy.
* â‘¡ The detailed discussion of punch card code on 1970's machine
is quite a eye-opener for those of us who's not in that era.
* â‘¢ You get to see Fortress code, and its use of fancy unicode
chars.
* â‘£ Thru the latter half of talk, you get a concrete sense of some
critical “do's ＆ don'ts†in coding paradigms about what makes
automated parallel programing possible or impossible.
In much of 2000s, i did not understand why compilers couldn't just
automatically do parallelism. I thought about it in 2009, and realized
why. See: Why Must Software Be Rewritten For Multi-Core Processors?.
--------------------
Parallel Computing vs Concurrency Problems
Note that parallel programing and concurrency problem are not the same
thing.
Parallel programing is about writing code that can use multiple CPU.
Concurrency problems is about problems of concurrent computations
using the same resource or time (e.g. race condition, file locking).
See: Parallel computing â—‡ Concurrency (computer science)
--------------------
Fortress ＆ Unicode
It's interesting that Fortress language freely uses unicode chars. For
example, list delimiters are not the typical {} or [], but the unicode
angle bracket 〈〉. (See: Matching Brackets in Unicode.) It also uses
the circle plus ⊕ as operator. (See: Math Symbols in Unicode.)
I really appreciate such use of unicode. The tradition of sticking to
the 95 chars in ASCII of 1960s is extremely limiting. It creates
complex problems manifested in:
* String Escape mechanism (C's “\nâ€, widely adopted.)
* Complex delimiters (Python's triple quotes and perl's variable
delimiters q() q[] q{} m//, and heredoc. (See: Strings in Perl and
Python â—‡ Heredoc mechanism in PHP and Perl.)
* Crazy leaning toothpick syndrome, especially bad in emacs regex.
* Complexities in character representation (See: Emacs's Key
Notations Explained (/r, ^M, C-m, RET, <return>, M-, meta) â—‡ HTML
entities problems. See: HTML Entities, Ampersand, Unicode, Semantics.)
* URL Percent Encoding problems and complexities: Javascript
Encode URL, Escape String
All these problems occur because we are jamming so many meanings into
about 20 symbols in ASCII.
See also:
* Computer Language Design: Strings Syntax
* HTML6: Your JSON and SXML Simplified
Was this page useful to you?
Also, almost all of today's languages do not support unicode in
function or variable names, so you can forget about using unicode in
variable names (e.g. α=3) or function names (e.g. “lambda†as “λ†or
“function†as “ƒâ€), or defining your own operators (e.g. “⊕â€).
(Exceptions i know works well in practice are: Mathematica,
Javascript, Java, Emacs Lisp. See: Unicode Support in Ruby, Perl,
Python, Emacs Lisp.)
Xah ∑ http://xahlee.org/