Computer Science Education
Nick Brown
I was listening to the listener feedback episode on my drive home from
the holidays the other day, and the discussion on computer science
education interested me. I'd like to share a conversation I had with
several CS professors a few years back.
As a Virginia Tech alum, I was asked by my employer (IBM) to represent
the company at an ACM programming conference we were co-sponsoring, at
which VT and a number of smaller schools in the region were
competing. I was talking with a few professors from some of those
smaller schools about how they went about teaching the discipline and
the topic of what programming language should be taught was brought
up. One professor mentioned that he would really like to teach his
intro classes using Lisp (I think it was Stallman who said even if you
never use Lisp, it's still useful to learn it because it will teach
you a lot about computer science in general), but couldn't because it
would be impossible to get students to take it then. I (in the
position as a programmer in a corporate setting) mentioned that
wouldn't be such a bad thing, as it would help filter out students who
probably should major in something else. Well, the professors were
all horrified at that notion. Enrollment was already dangerously low,
they told me, so doing something like that would ensure they would be
out of a job in no time. Maybe a large, well known CS program could
take a risk like that, but these were all professors at small private
schools. The lesson I got from that was that in order for a CS
program to be successful, unless you are MIT, it has to be very
accessible. It can't just target those who will eventually be the
über-programmers we want to be our co-workers.
At first I thought this was the wrong way to go about it as this
targets quantity over quality of our future software engineers, but I
suppose they do have a point. Not everyone taking intro to comp sci
is going to be a software engineer, just as not everyone taking intro
to biology is going to be a biologist. In fact, it is becoming more
and more important for members of other disciplines (especially,
though not limited to, engineering and the sciences) to learn at least
some CS. They won't have to write huge, multi-layer applications, but
they may well need to write a short script to accomplish something on
a computer.
So as Bio 101 doesn't usually start out with teaching the complicated
organic chemistry that is the heart of all biology, CS 101 also needs
to start out at a much higher level of abstraction. And what is the
most natural abstraction of CS? Well, depending on who you talk to,
either objects or functions. I would personally side with functions,
but much of that is tainted by how many problems arise with the common
modern implementations of OOP. Functions are familiar, not just to
mathematicians, but to anyone who as taken an algebra class. And the
use of functional programming is not just useful to those who are
working on massively distributed programming, but also to a scientist
who needs to write a script to perform some computation of their data,
or an engineer who needs to run calculations to test their design. In
fact, anyone who has used grep should have no problem defending the
utility of functional programming.
Of course those students who (most likely well after taking CS 101)
decide to specialize in it and become software engineers will need to
learn a lot more, such as the internals of how all this "magic" stuff
they used in their beginning classes really work. But I don't think
that would be any more difficult than learning cellular biology or
organic chem after having a high level overview of biology.
So I suppose this is just a long-winded message about how whoever it
was (I think Tor) who was arguing that you need to start at the bottom
and learn up was wrong
Oh, and regarding the original listener feedback about using JUnit to
launch programs for beginning students, I guess I have mixed feelings
about it. One one hand, I worry that if students first see JUnit as
just a way to launch "Hello World", they may have difficulty switching
over to using it for real unit tests (I suppose I don't have an
argument for that, its just more of a gut feeling more than anything
else). On the other hand, I think using JUnit as it is intended would
be very useful. If they write a program to compute the nth Fibonacci
number, instead of exercising it in int main(...), write a JUnit for
it.
ScottHK
and creating an overview course. after all most of the students will
move into other fields and it can't hurt for them to have an overview
of practical programming concepts. Same as us CS people learning a
bit about physics & chemistry.
At intro level it would be best for young people is to learn that they
can make a computer do something. 'if then else' Get user input
and produce a result, that sort of thing. Procedural programming. OOP
and/or functional programming is just higher level theory that they
can't really grasp at this point.
A few weeks ago I interviewed a brilliant physics masters degree grad,
but had only learned a bit of Fortran in 5 years of schooling, I
really wanted to hire him but he was just unemployable. make them
learn Java!
Vince O'Sullivan
all discussions of Computer Science (CS) courses:
1) Advocating which language to teach is pointless without first
listing the core skills you are intending the students to graduate
with. In turn, advocating the core skills is pointless unless you
first articulate who your course is aimed at. Identify the customer
and their requirements then the solution, not the other way around.
2) All the best programmers will already be computer hobbyists and
enthusiasts before they start a CS course. The problem is what to do
with CS students who are not enthusiasts and only do the work mandated
by the course.
3) There is limited common ground between the skills of a compiler
designer and a those of a business application developer. Beyond the
introductory stuff they should be on separate courses.
Nick Brown
core skills are end up being a discussion itself) are the most
important for a beginning programming student. But the language
choice heavily influences what core skills you can teach and how
effectively you can teach them. Try teaching functional programming
in straight Java 6, or object oriented programming in Basic. Or
anything in Brainf*ck.
With your second point, I don't think I could disagree any stronger.
There are many computer students out there who are genuinely
interested in the subject matter but who do not come from a background
as a computer hobbyist. I was one of them. In fact, in my
experience, many of those who did come in as computer hobbyists were
some of the first to drop out when they realized computer science was
much more rigorous than writing the Basic games they wrote in grade
school. Plus they have a tendency to be very elitist, which beyond
making them think they are better than their classmates who have not
assembled a computer from scratch with their bare hands also can cause
them to refuse to learn anything from their professors.
On your third point, are you suggesting that after taking just a few
introductory courses a computer science student must be able and
willing to choose what direction and what specialty they will be going
into for the rest of their career? Hell with a field changing this
fast, I have trouble seeing where I will be a few years from now, even
over a decade after I started college.
On Dec 31 2010, 4:13 am, "Vince O'Sullivan" <vjosulli...@gmail.com>
wrote:
Ricky Clarkson
> in straight Java 6, or object oriented programming in Basic.
Oddly enough, I 'discovered' functional programming in straight Java
(5 at the time), and object-oriented programming in Basic (Blitz Basic
2).
Derek Munneke
When Odersky taught me Java in '98 he commented on the functional aspects ... and that was 1.2
But that was after several years of Fortran, Modula-2, Lisp, and Miranda... alot of good that turned out to be ;)
ScottHK
Java:
http://codemonkeyism.com/generation-java-programming-style/
On Jan 1, 4:13 pm, Derek Munneke <derek.munn...@gmail.com> wrote:
Nick Brown
programming with Java. Its just going to be a real bitch to do. I
have co-workers who supposedly already have degrees in computer
science who can't always be bothered to add private modifiers to their
variables, and you're expecting brand new CS students to always
remember them? And when they ask why they need to add that identifier
and you tell them its so they can't change the value later, you expect
them to voluntarily refrain from using that newfound "feature" of
variables they can change later? And don't get me started about
anonymous inner classes being a replacement for closures or function
literals.
My point remains valid, the programming language is an important
choice because a clumsy language is going to make certain core skills
very difficult to teach.
Carl Jokl
syntax is potentially harmful to teach because the for loop with an
index is inherently only processable with a single thread vs the
foreach loop which can potentially use parallel processing.
I use mostly foreach loops but there is one situation in Java where I
seem stuck with using the indexed version. This may be a shortcoming
in Java because the order in which iteration is done does not matter.
The situation is when doing operations which involve copying or
deriving values from one array to another array. The foreach loop in
Java is fine for taking values out of an array but I don't think as
far as I have been able to find out
that these loops can be used for receiving values. In this case the
for loop with the index is used to get an element out of an array at a
given index and the derived value is stored in the destination array
at the same index.
For example:
Type[] types = Type.values();
char[] mnemonics = char[types.length];
for (int index = 0; index < mnemonics.length; index++) {
mnemonics[index] = types[index].getMnemonic();
}
I come across this situation a fair amount but don't think it can be
done in foreach style in Java though I think some kind of closure in
other languages would allow the source to be mapped to the destination
as I understand it.
Kevin Wright
One item which I have heard mention recently is that the for loop
syntax is potentially harmful to teach because the for loop with an
index is inherently only processable with a single thread vs the
foreach loop which can potentially use parallel processing.
I use mostly foreach loops but there is one situation in Java where I
seem stuck with using the indexed version. This may be a shortcoming
in Java because the order in which iteration is done does not matter.
The situation is when doing operations which involve copying or
deriving values from one array to another array. The foreach loop in
Java is fine for taking values out of an array but I don't think as
far as I have been able to find out
that these loops can be used for receiving values. In this case the
for loop with the index is used to get an element out of an array at a
given index and the derived value is stored in the destination array
at the same index.
For example:
Type[] types = Type.values();
char[] mnemonics = char[types.length];
for (int index = 0; index < mnemonics.length; index++) {
mnemonics[index] = types[index].getMnemonic();
}
//mnemonics will be an Array[Char]val mnemonics = Type.values map { _.getMnemonic }
//no support for Arrays, so it'll have to be a list, which means primitives can't be stored eitherfinal List<Type> typeList = Arrays.asList(Type.values())final List<Character> mnemonicList = convert(typeList, new PropertyExtractor("mnemonic"));//this needs to work, or we're back to a loop for Character unboxingfinal char[] mnemonics = mnemonicList.toArray(new char[0])
//no support for Arrays, etc, etc.final Function<Type, Character> lookupMnemonic = new Function<Type, Character> {Character apply(Type tpe) { return tpe.getMemonic }}final List<Type> typeList = Arrays.asList(Type.values())final List<Character> mnemonicList = Collections2.transform(typeList, lookupMnemonic)final char[] mnemonics = mnemonicList.toArray(new char[0])
I come across this situation a fair amount but don't think it can be
done in foreach style in Java though I think some kind of closure in
other languages would allow the source to be mapped to the destination
as I understand it.
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
--
Kevin Wright
gtalk / msn : kev.lee...@gmail.com
Ricky Clarkson
import fj.F;
import fj.data.Array;
Integer[] legs = Array(animals).map(new F<Animal, Integer>() {
public Integer f(Animal animal) {
return animal.legs;
}
}).array(Integer.class);
fj = Functional Java.
Carl Jokl
using google collections or another external library. I suppose the
desire to be able to do this kind of things would be a driver for
wanting to add closure to Java.
I get the principle that what I am really doing is mapping one value
to another value (Remembering Haskell from University) and that order
does not really matter.
If it were an array of 8 values and a machine had 8 cores then
potentially the entire operation could be done together. The theory is
fair enough but I wonder about the overhead of breaking up something
like this over multiple threads and whether for more trivial
operations, the overhead of splitting up the computation and doing it
in parallel might outweigh the time savings of being able to do
parallel batches. I imagine there is some kind of threshold where the
parallel processing benefit is greater than the overhead. It may be a
lower threshold than I realise.
Joseph Ottinger
but even pure java has Runnables and Executors. They'd be horribly
verbose for such a simple operation, but it can easily be done.
--
Joseph B. Ottinger
http://enigmastation.com
Ricky Clarkson
would be that the map call could be one that magically knows whether
it's worth parallelising.
Joseph Ottinger
--
Kevin Wright
It still looks like it may not be possible yet in core Java without
using google collections or another external library. I suppose the
desire to be able to do this kind of things would be a driver for
wanting to add closure to Java.
I get the principle that what I am really doing is mapping one value
to another value (Remembering Haskell from University) and that order
does not really matter.
If it were an array of 8 values and a machine had 8 cores then
potentially the entire operation could be done together. The theory is
fair enough but I wonder about the overhead of breaking up something
like this over multiple threads and whether for more trivial
operations, the overhead of splitting up the computation and doing it
in parallel might outweigh the time savings of being able to do
parallel batches. I imagine there is some kind of threshold where the
parallel processing benefit is greater than the overhead. It may be a
lower threshold than I realise.
//the .par makes it parallel...val mnemonics = Type.values.par map { _.getMnemonic }
Cédric Beust ♔
One item which I have heard mention recently is that the for loop
syntax is potentially harmful to teach because the for loop with an
index is inherently only processable with a single thread vs the
foreach loop which can potentially use parallel processing.
Cédric
Cédric Beust ♔
I use mostly foreach loops but there is one situation in Java where I
seem stuck with using the indexed version. This may be a shortcoming
in Java because the order in which iteration is done does not matter.
--
Cédric
Kevin Wright
If you have referential integrity (the same function, with the same input always returns the same value, immutability is important here) and the functions have no side-effects (e.g println) then it's mathematically guaranteed that ordering won't matter. You can still have indices, they just don't need to be processed in-order.
For that matter, they needn't be on the same thread, processor or even computer!
This is the very essence of why so many are now advocating functional programming as such a good fit for concurrency.
>
> --
> Cédric
Cédric Beust ♔
>
> This seems wrong. Just because the loop seems to be parallelizable doesn't mean it is. The compiler needs to know whether your iteration is ordering sensitive or not ("Is it okay if index 3 is treated before index 1?"). This hint is much more meaningful than whether the developer is using an index of foreach. The same applies to closures, LINQ or whatever comprehension walking mechanism you favor.If you have referential integrity (the same function, with the same input always returns the same value, immutability is important here) and the functions have no side-effects (e.g println) then it's mathematically guaranteed that ordering won't matter. You can still have indices, they just don't need to be processed in-order.
Cédric
Ricky Clarkson
different inputs. E.g.:
for (int a = 0; a < 100; a++)
array[a] = a * 2;
If I extracted a * 2 into a separate method:
for (int a = 0; a < 100; a++)
array[a] = doubleIt(a);
there's only one input, and it would be the same if I parallelised that loop.
Something like your example:
int soFar = 0;
for (int a = 0; a < 100; a++)
array[a] = soFar += a;
Here if I extract a method I get:
int soFar = 0;
for (int a = 0; a < 100; a++) {
soFar = addSome(soFar, a);
array[a] = soFar;
}
(eliding soFar is quite easy, but the problem remains)
This time you aren't calling the same function with the same inputs,
so even though addSome is referentially transparent (i.e., it
describes a function), parallelising it won't work.
2011/1/6 Cédric Beust ♔ <ced...@beust.com>:
Cédric Beust ♔
Cédric
Ricky Clarkson
be safely parallelised. That's the connection. Oh, and I'm not Kevin
Wright, the guy who mentioned referential integrity. I was merely
pointing out an error in your reasoning from a reply to Kevin.
2011/1/6 Cédric Beust ♔ <ced...@beust.com>:
Cédric Beust ♔
Loops where each iteration does not depend on any other iteration can
be safely parallelised. That's the connection
--
Cédric
Ricky Clarkson
side-effect-ful and it can do all the necessary analysis. So, for
instance, it's perfectly doable without any hints for Haskell. For
Java a combination of annotations and inference could do it.
2011/1/6 Cédric Beust ♔ <ced...@beust.com>:
Joseph Ottinger
side-effects, if any, and optimize the loop to be parallel if no
side-effects are detected. of course, if side effects are rare
conditions, that makes things much dicier.
--
Ricky Clarkson
they were based on something that was incorrect, so sure, that's an
option. Though when one side effect happens on another
thread/process/CPU, if you allow it to run there rather than
transferring it to the original thread you're probably going to break
stuff.
Cédric Beust ♔
All it takes is for the compiler to know what operations are
side-effect-ful and it can do all the necessary analysis.
So, for instance, it's perfectly doable without any hints for Haskell
Cédric
Ricky Clarkson
containing just the index, that's safely parallelisable and a case it
would be difficult to automatically analyse.
These things often err on the conservative side, so as to not
introduce problems.
2011/1/6 Cédric Beust ♔ <ced...@beust.com>:
Kevin Wright
On 6 Jan 2011 20:45, "Cédric Beust ♔" <ced...@beust.com> wrote:
>
>
>
> On Thu, Jan 6, 2011 at 12:37 PM, Ricky Clarkson <ricky.c...@gmail.com> wrote:
>>
>> All it takes is for the compiler to know what operations are
>> side-effect-ful and it can do all the necessary analysis.
>
>
> It's still not enough: the loop might still be parallelizable even though it's performing side effect operations.
>
>>
>> So, for instance, it's perfectly doable without any hints for Haskell
>
>
> Are you sure? Remember: the only important factor here is whether the operations can be safely performed out of order.
>
Got it exactly! You can be certain that any loop is safely parallelizable so long as no iteration depends on a previous one.
This coupling can be direct, such as the addition of values in calculating the fibbonacci sequence (where integer addition exhibits referential integrity), or through side effects, such as printing and list to the console.
Haskell helps here by ensuring a lack of side effects, so it *is* relevant.
If iterations only depend on their index, then you can generate a list of indices first, and transform said list to output values in parallel. Take the example of printing to the console, the output lines could all be generated simultaneously and only printed afterwards, this shows how avoiding side effects helps concurrency.
It's even possible to go further than this. By using a fork-join approach, lines could also be concatenated in parallel, then printed in a single operation.
This is the sort of thing that functional languages can optimise automatically, using monad composition laws to prove when it's safe to parallelize in such a fashion, and doing so by manipulating the AST as an algebraic construct. But that's, admittedly, getting into very advanced territory.
Amihay Zer-Kavod
recommended) workaround:
object Main extends Application {
println("Hello World!")
}
By extending Application the code inside the class curly brackets is
activated automatically.
It hides all the details and boiler-plating of the main method.
I find it kind of nit and keeps the students focused at the main point
of activating the code they write.
On Dec 31 2010, 1:05 am, Nick Brown <nwbr...@gmail.com> wrote:
> First, a disclaimer, this may end up as a bit of a rant.
> I was listening to the listener feedback episode on my drive home from
> the holidays the other day, and the discussion on computer science
> education interested me. I'd like to share a conversation I had with
> several CS professors a few years back.
> As a Virginia Tech alum, I was asked by my employer (IBM) to represent
> the company at an ACM programming conference we were co-sponsoring, at
> which VT and a number of smaller schools in the region were
> competing. I was talking with a few professors from some of those
> smaller schools about how they went about teaching the discipline and
> the topic of what programming language should be taught was brought
> up. One professor mentioned that he would really like to teach his
> intro classes using Lisp (I think it was Stallman who said even if you
> never use Lisp, it's still useful to learn it because it will teach
> you a lot about computer science in general), but couldn't because it
> would be impossible to get students to take it then. I (in the
> position as a programmer in a corporate setting) mentioned that
> wouldn't be such a bad thing, as it would help filter out students who
> probably should major in something else. Well, the professors were
> all horrified at that notion. Enrollment was already dangerously low,
> they told me, so doing something like that would ensure they would be
> out of a job in no time. Maybe a large, well known CS program could
> take a risk like that, but these were all professors at small private
> schools. The lesson I got from that was that in order for a CS
> program to be successful, unless you are MIT, it has to be very
> accessible. It can't just target those who will eventually be the
> über-programmers we want to be our co-workers.
> At first I thought this was the wrong way to go about it as this
> targets quantity over quality of our future software engineers, but I
> suppose they do have a point. Not everyone taking intro to comp sci
> is going to be a software engineer, just as not everyone taking intro
> to biology is going to be a biologist. In fact, it is becoming more
> and more important for members of other disciplines (especially,
> though not limited to, engineering and the sciences) to learn at least
> some CS. They won't have to write huge, multi-layer applications, but
> they may well need to write a short script to accomplish something on
> a computer.
> So as Bio 101 doesn't usually start out with teaching the complicated
> organic chemistry that is the heart of all biology, CS 101 also needs
> to start out at a much higher level of abstraction. And what is the
> most natural abstraction of CS? Well, depending on who you talk to,
> either objects or functions. I would personally side with functions,
> but much of that is tainted by how many problems arise with the common
> modern implementations of OOP. Functions are familiar, not just to
> mathematicians, but to anyone who as taken an algebra class. And the
> use of functional programming is not just useful to those who are
> working on massively distributed programming, but also to a scientist
> who needs to write a script to perform some computation of their data,
> or an engineer who needs to run calculations to test their design. In
> fact, anyone who has used grep should have no problem defending the
> utility of functional programming.
> Of course those students who (most likely well after taking CS 101)
> decide to specialize in it and become software engineers will need to
> learn a lot more, such as the internals of how all this "magic" stuff
> they used in their beginning classes really work. But I don't think
> that would be any more difficult than learning cellular biology or
> organic chem after having a high level overview of biology.
> So I suppose this is just a long-winded message about how whoever it
> was (I think Tor) who was arguing that you need to start at the bottom
> and learn up was wrong
>
> Oh, and regarding the original listener feedback about using JUnit to
> launch programs for beginning students, I guess I have mixed feelings
> about it. One one hand, I worry that if students first see JUnit as
> just a way to launch "Hello World", they may have difficulty switching
> over to using it for real unit tests (I suppose I don't have an
> argument for that, its just more of a gut feeling more than anything
> else). On the other hand, I think using JUnit as it is intended would
> be very useful. If they write a program to compute the nth Fibonacci
> number, instead of exercising it in int main(...), write a JUnit for
> it.
Kevin Wright
On 11 Jan 2011 18:56, "Amihay Zer-Kavod" <ami...@gmail.com> wrote:
>
> By the way, about the main problem. Scala has a nice (but not very
> recommended) workaround:
>
That's due to change in the very near future.
Enhancements scheduled for the imminent 2.9 release mean that this will soon be the officially recommended way to create an application...
Reinier Zwitserloot
Reinier Zwitserloot
Kevin Wright
I'm a bit confused as to why Scala programmers have the gall to claim the moral high ground in regards to multi-core programming.
Certainly a language that is very good at letting you write code that runs well on multiple cores will have a function-esque taste, but scala isn't it.For example, scala has enshrined foldLeft and foldRight forever more as core language, by importing both of those by default as operators (i.e. "/:", as a token, is a fold operator in scala unless you go out of your way to unimport it). foldLeft is fundamentally *NOT* parallellizable! Its accumulator based, and accumulator is a magic word. It means: "This code has no hope whatsoever of ever running parallel".
I'd envision a language that truly takes this 'parallelize everywhere' principle seriously to be extensively conc-list based.conc-lists are like lisp's cons-lists (1 head element and a tail list), but instead have lists for both head and tail. A list is thus really a tree. If this tree is reasonably well balanced, operations on it that are not accumulation based can be aggressively parallelized.
By the way, conslists, mainstay of for example lisp, and very much associated with functional languages, are another one of those things that absolutely, positively, cannot be parallelized AT ALL. Looping through such a list takes O(n), and no amount of parallelization can fix that. You can kludge it by storing forward pointers in the list as an implementation detail (i.e. hotspot would be doing that), so another core can jump right in the middle of a list and start from there, but this is frightfully complicated; far more complicated that for example updating the JVM hotspot to recognize foreach loops, check if the code relies on sequential execution, and if not, paralellizing it. (That's not a good idea, see my earlier post, but it can be done).
--You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Ricky Clarkson
<rein...@gmail.com> wrote:
> I'm a bit confused as to why Scala programmers have the gall to claim the
> moral high ground in regards to multi-core programming.
The confusion is in your head. Scala programmers don't claim that high ground.
> For example, scala has enshrined foldLeft and foldRight forever more as core
> language, by importing both of those by default as operators (i.e. "/:", as
> a token, is a fold operator in scala unless you go out of your way to
> unimport it).
Let's rewrite that without the emotional crap: "Scala has foldLeft and
foldRight (and symbolic versions of those) in the standard library."
Yes, it does, but so what?
Kevin Wright
Ricky Clarkson
about Java based on those two classes?
Kevin Wright
Why, are there some inaccurate judgements you might otherwise make
about Java based on those two classes?
Ricky Clarkson
Kevin Wright
java.util.Date is immutable, by the way.
Ricky Clarkson
steve
> java.util.Date is immutable, by the way.
val date = new java.util.Date
// date: java.util.Date = Thu Jan 13 17:17:43 CET 2011
date.setYear(2000)
// date: java.util.Date = Sat Jan 13 17:17:43 CET 3900
Not really, isn't it?
Bye,
Steve
Cédric Beust ♔
I'm a bit confused as to why Scala programmers have the gall to claim the moral high ground in regards to multi-core programming.
Cédric
Kevin Wright
+1
You'd also want to add reliability as a metric (this being one of the core selling points for actors), and compare against data flow concurrency as well.
> --
> Cédric
Reinier Zwitserloot
Russel Winder
[ . . . ]
> I am seeing a lot of claims going unchallenged, such as the fact that
> the actor model is superior to the traditional java.util.concurrent
> API's.
Sadly almost the whole of computing since 1936 has been based on
marketing and advocacy research, with (fortunately) some seriously good
quality engineering from time to time. Basically there is essentially
no science in computer science. So not only is there nothing other than
claims that Actor Model is a good thing, there is nothing other than
claims that CSP is a good thing, likewise dataflow. In fact there is no
experimental evidence that object-oriented is good, that functional is
good, or even structured programming. It's all been opinion. And
marketing.
> I'm keeping my mind open but so far, I haven't seen any blinding proof
> of this claim. What I would really like to see is a non-trivial (i.e.
> requiring a few hundreds of lines of code to solve) concurrent problem
> written with both java.util.concurrent and Actors (might want to throw
> in fork-join in there while we're at it) and a tentatively objective
> analysis of the pros and cons of each approach, on several axes:
> maintainability, testability, readability (more subjective),
> debuggability, etc...
I'll turn it the other way around: advocates of java.util.concurrent
being all that is needed, need to provide proof that, in fact, it is
even capable (*).
Clearly there needs to be a grid of frameworks and problems with a set
of metrics. java.util.concurrent has no special position in this
experiment, it's only special position is that it is in the standard
distribution.
If we can decide on a few problems, and on which version control system
to use, it cannot be beyond the wit of Java Posse folk to create a
repository with all the necessary code. I have made a start (**) at
investigating scaling in a very large number of languages using the
problem of calculating PI via quadrature. This is a trivial,
embarrassingly parallel problem that is amazingly useful in
presentations and training courses, even though it is a microbenchmark
with all the problem that brings (***).
> My gut feeling is telling me that while the Actor/Immutable/lock free
> model appears simpler, it also introduces a radical shift in the way
> you implement your solution that might be detrimental to its
> maintenance on the long run. At the end, you might end up with a
> simple locking model (since there are no locks) but at the expense of
> a more spaghetti-ish structure, since all these actors are now sending
> asynchronous messages to each other and retracing and debugging such a
> flow can be challenging.
Personally I challenge that shared memory multi-threading should have
the position of orthodoxy that it has managed to acrete to itself.
Actor Model is 1973. CSP is 1976-1983. There is the Newsqueak thread
of work leading to Go. Threads came later than this: all of these
merging models were simply thrust aside by the obsession that 1970s
operating systems processes and their inter-process communications
systems were too heavyweight and slow -- even though it may have been
true, it was no reason to invent shared-memory multi-threading as an
application programming necessity.
Basically techniques that are necessary in operating systems programming
have been forced into applications programming technology where they
actually ought to be considered anathema.
Hummm . . . I think I am getting close to a rant. Time to stop.
> Another gut feeling that I haven't been able to shake off is the fact
> that the actor model introduces a single locking choke point (the
> inbox queue) while Java's traditional locking approach allows you to
> position your lock wherever you want, and over an arbitrarily large
> (or small) portion of code. Determining such a locking can be
> challenging, but once you've solved that particular problem, it's hard
> for me to imagine that there are more optimal ways of solving this
> problem.
So use Dataflow instead. Just because Actor <odel is getting a lot of
airplay just now doesn't mean its the only alternative. And of course
there is CSP which actually has a mathematical underpinning, unlike
every other of the alternatives.
For me Actor Model is getting to much mind set, others viable models
need a go to avoid all the advocacy and marketing.
(*) In fact I am a huge advocate of java.util.concurrent for any and
all concurrent and parallel Java programming as anyone who has been in
any of my sessions on this sort of thing can attest to. But . . . that
doesn't make it right. It just makes it less worse.
(**) Bazaar branch rendered by Loggerhead at
http://www.russel.org.uk:8080/Pi_Quadrature, Bazaar branches for
branching at http://www.russel.org.uk/Bazaar/Pi_Quadrature.
(***) And, oh boy, isn't Java and the JVM a right pain when it comes to
microbenchmarking. Bizarrely Scala does not have the same problems Java
has when it comes to priming the JVM JIT, yet no Scala advocate has yet
been able to provide me with a good rationale as to why.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Kevin Wright
On 14 Jan 2011 13:59, "Reinier Zwitserloot" <rein...@gmail.com> wrote:
>
> Scala's language spec contains almost nothing. If you don't consider the standard import list part and parcel of scala (removing stuff from that list certainly isn't backwards compatible), I just don't know what to say to you (other than perhaps a wry comment on how I should have expected javaposse's resident scala fanboy to be so blind).... but of course, according to you the new library addition of parallel collections ARE enshrined. Pavlov would be pleased. Of course, we've been able to download and work with ParallelArray on JVM languages for a while now, so this isn't exactly new.
>
Parallel collections are enshrined in the fact that there's an entire release of Scala dedicated to adding them.
Folds? Just a couple of methods, and small ones at that.
It would require a very advanced level of doublethink to *not* objectively see a significant difference between the two.
> How does scala encourage side-effect-free methods? You can't even add an assertion of some sort to say: I intended this method to be side-effect-free. Let alone that such this assertion is checked by the compiler. Java doesn't either, but my claim is that the scala programmers claim to be better at this highly parallelizable thing than java. I'm certainly not claiming that java is any better, I'm just trying to say that language doesn't exist yet - scala most assuredly isn't it. Haskell at least has the side-effect-free thing down pat.
>
No, you're right, Scala doesn't have effect tracking yet. But I can assure you that the community is aware of the absence, and it's one of the more interesting features scheduled to be added under the funding of the recently awarded grant.
Currently, the language just goes a long way towards encouraging immutability and freedom from side effects, without actually enforcing them.
Still, this is a definite step up from ignoring the concepts completely (hey, anyone for setter injection?)
> NB: In regards to your spat against java.util.Date, two points: (1) Date has no operators associated with it, and cannot be used without an import statement or an FQN. This makes java.util.Date orders of magnitude less tied in to java (the language) compared to scala (the language). (2) I never claimed java was any better at this multi-core game that scala is. I'm trying to say that your claim that scala is, isn't backed up by much. Attacking java doesn't help you prove your case.
>
I'm not attacking Java. It's a rare Scala programmer who didn't migrate from java, and we all very much recognize Java's strengths.
I am, however, attacking the attitude that it's somehow heretical to even dare comparing java's "perfection" to alternative ideas.
Cédric Beust ♔
Currently, the language just goes a long way towards encouraging immutability and freedom from side effects
--
Cédric
Kevin Wright
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Kevin Wright
2011/1/14 Cédric Beust ♔ <ced...@beust.com>How? I really don't see it this way.On Fri, Jan 14, 2011 at 12:56 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
Currently, the language just goes a long way towards encouraging immutability and freedom from side effectsYou can use var or val. You can modify fields inside methods. Only case classes are final.I don't see much in the overall philosophy behind the language that's very different from Java's in terms of immutability, and most defaults are toward mutability.If Scala programs tend to have more immutable structures than Java programs, it's much more because of the discipline of its developers than because the language encourages it.I see this as a good thing, by the way, but I think your claim is just plain incorrect.
--
CédricYou can even make case classes mutable if you mark params as vars. :)mutability is certainly accepted, and can't really be avoided for the kind of *deep* Java interop that's a design goal of java.I'll also agree that `var` isn't inherently harder to write than `val`, though anyone learning from current blogs, books, etc. will find themselves rapidly coming to see var as the lesser used of the two.More specifically though, I was thinking about the collections.If you create a new Map, or List, or Seq, etc, etc. then you'll get an immutable collection by default, mutable versions exist, but have to be explicitly imported.Given how much an "average" program will use a collection of some sort or another, that's a *lot* of encouragement.
49:10 - 49:50
Although Fortress is originally designed as an object-oriented framework
in which to build an array-style scientific programming language, [...]
as we've experimented with it and tried to get the parallelism going we
found ourselves pushed more and more in the direction of using immutable
data structures and a functional style of programming. [...] If I'd
known seven years ago what I know now, I would have started with Haskell
and pushed it a tenth of the way toward Fortran instead of starting with