Slashdot Mirror

I'm tired about hobbyists trying to brag with their half knowledge: https://archive.eiffel.com/doc...
That is just an introduction. It is pretty difficult to write manual memory management code that is as fast as "the optimal" gc.
Perhaps you like to read the "arguments for" and "arguments against" GC in this article: http://www.berenddeboer.net/ei... (note: the arguments "against" get debunked or put in bettter light at least ;D)
Or perhaps you like to read something from an expert: http://www.cs.kent.ac.uk/peopl...
Or simply google/search for the old Eiffel versus C benchmarks of Bertram Meyer. He compared about 30 Eiffel programs with their corresponding C programs. The "specialized" Eiffel GCs where nearly always faster than the manual crafted C code, and half of the C programs had bugs regarding memory management.

Interesting article you linked, but many mistakes. And not really related to the core question or core statements :D

Nah, that's before my time as a "professional" programmer. Back when I was studying we had a teacher, Brian Vinter, whom used to love bashing Java - one of his favorite presentations was "Wot, no chicken?" (or starving philosophers if you will).

See this: http://www.cs.kent.ac.uk/projects/ofa/java-threads/0.html

See also: http://projects.cs.kent.ac.uk/projects/tock/trac/ - tock occam compiler, written in Haskell. It produces really fast code that supports large SMP systems, written by members of the KrOC group.

So, what has Go brought to the table?

Go is designed with internal messaging capabilities, intended to simplify the creation of applications running on different nodes, and improve their performance.

"It's a way to try to address how to write concurrent software that's more robust, as opposed to using the old threading model of Java and others," Voss said.

...

In this regard, Go offers "a new programming paradigm" that makes it easier to solve a wide variety of programming problems by simplifying many types of parallel processing.

No, Go doesn't bring anything new to the concurrency table. The two things I've seen about Go concurrency that are regarded as special are M:N/"green" threads and CSP-style channels.

M:N threading is an implementation detail of a language runtime. Whereas the standard library of a language might specify how threads are available to client applications (programs written in the language), it's best left to the implementation (runtime or compiler) to decide how to translate those threads onto the machine. Some implementations might want to focus on scalable, high-performance threading, and so they'd choose M:N. Some others might emphasize simplicity, and map language threads directly to OS threads. What Go has done is standardized this implementation detail into the language specification. (I don't think that's a good idea, but that's a matter of taste.) Other language implementations offer M:N threading, including GHC and (I think) Erlang.

On channels: they're cool. I love them. But there's a lot of prior art here, and many languages have great CSP-style channel libraries written for them that offer the same great flavor of relatively safe message passing and alternation between sets of channels:

• Communicating Sequential Processes for Java (JCSP)
• C++CSP2
• CHP: Communicating Haskell Processes
• python-csp
• Plan 9 libthread for C (and not just Plan 9, thanks to plan9port)
• and my own: Calispel for Common Lisp

In summary, I just don't get what the buzz with Go is about, besides that it's Google's very own language.

So, what has Go brought to the table?

Go is designed with internal messaging capabilities, intended to simplify the creation of applications running on different nodes, and improve their performance.

"It's a way to try to address how to write concurrent software that's more robust, as opposed to using the old threading model of Java and others," Voss said.

...

In this regard, Go offers "a new programming paradigm" that makes it easier to solve a wide variety of programming problems by simplifying many types of parallel processing.

No, Go doesn't bring anything new to the concurrency table. The two things I've seen about Go concurrency that are regarded as special are M:N/"green" threads and CSP-style channels.

M:N threading is an implementation detail of a language runtime. Whereas the standard library of a language might specify how threads are available to client applications (programs written in the language), it's best left to the implementation (runtime or compiler) to decide how to translate those threads onto the machine. Some implementations might want to focus on scalable, high-performance threading, and so they'd choose M:N. Some others might emphasize simplicity, and map language threads directly to OS threads. What Go has done is standardized this implementation detail into the language specification. (I don't think that's a good idea, but that's a matter of taste.) Other language implementations offer M:N threading, including GHC and (I think) Erlang.

On channels: they're cool. I love them. But there's a lot of prior art here, and many languages have great CSP-style channel libraries written for them that offer the same great flavor of relatively safe message passing and alternation between sets of channels:

• Communicating Sequential Processes for Java (JCSP)
• C++CSP2
• CHP: Communicating Haskell Processes
• python-csp
• Plan 9 libthread for C (and not just Plan 9, thanks to plan9port)
• and my own: Calispel for Common Lisp

In summary, I just don't get what the buzz with Go is about, besides that it's Google's very own language.

+1 offtopic incoming. Regarding your signature, it's somewhat more difficult to find a feature of this nature in Linux as it would be in Windows. Which strikes me as a bit odd. Anyway, what you want to do can be simulated with this apparantly:

http://www.cs.kent.ac.uk/~sm244/Jail.tar.gz

Though if you wanted that functionality for the same reason I wanted it (specifically playing games on a dual-headed Linux using TwinView, your best bet is to start researching adding a extra MetaMode into your X config. It's what I ended up doing instead, since it just turns the other monitor off and allows me to play on my main monitor. Works fine.

Jonaskoelker's Irony Meter

Jonaskoelker's irony meter has encountered a problem and needs to close. We are sorry for the inconvenience.

If you were in the middle of something, the irony you were working on may be lost.

Please tell Beelsebob about this problem.
We have created an irony report that you can send to help us laugh at Internet Explorer. We treat this report as hilarious and highly entertaining.

To see which nuggets of irony the report contains, click here.

Actually, no, Opera is not one of the fastest browsers out there as This, on Mac OS, and this on windows show -- note, what is showing as opera 9.8 is 10.0 beta, I've yet to test the final release of 10.0, but you're of course welcome to try to duplicate my results.

Actually, no, Opera is not one of the fastest browsers out there as This, on Mac OS, and this on windows show -- note, what is showing as opera 9.8 is 10.0 beta, I've yet to test the final release of 10.0, but you're of course welcome to try to duplicate my results.

Communication channels are the right way to tackle this. Bell Labs had the right idea. See http://swtch.com/~rsc/thread/ and the slides at http://www.cs.kent.ac.uk/teaching/07/modules/CO/6/31/slides/ if you have an inquisative mind. For the slides, read them in this order: motivation.pdf -- just pages 1-39, basics.pdf, applying.pdf, choice.pdf, replicators.pdf, protocol.pdf, shared-etc.pdf.

is a Best Buy or a Barnes 'n Noble. you're going to need to know the tools and procedures of open source development before you can get anything done or changes submitted.

0. Install an Open Source operating system with development tools, such as [Net,Free,Open]BSD or Linux
1. Learn CVS [http://cvsbook.red-bean.com/, http://www.cs.kent.ac.uk/systems/cvs-howto.html%5D .
2. Learn the basics of the GNU C Compiler [http://www.faqs.org/docs/learnc/].
3. Learn Automake, Autoconf and Libtool [http://sources.redhat.com/autobook/autobook/autob ook.html, http://autotoolset.sourceforge.net/tutorial.html, http://www.amazon.com/Autoconf-Automake-Libtool-Ga ry-Vaughan/dp/1578701902, http://www.st-andrews.ac.uk/~iam/docs/tutorial.htm l%5D.
4. Download a tarball of some source code and compile it, learn how to edit Makefiles, etc.
5. Check out the source code of the same application from CVS, mess around with it.

Hey, release early, release often.

(Which seems as good a time as any to link to the UPS Debugger Song, better known as "Just one more hack and then I'll put it on the 'net".)

Debugging multithreaded code can be relatively easy, you just have to start off on the right foot. The best way to do that is to leave behind older concurrency models like monitors with mutexes, which the inventor of that model rejected back in the 80s and go with more recent concurrency models like CSP (the newer way to do concurrency from the man who brought you monitors). From a more modern perspective like CSP reasoning about concurrency is a lot easier, and hence debugging becomes much simpler. In fact tere are model checking tools that can verify lack of deadlocks etc. The downside is that its much easier if you have a language that supports the model, or get an addon library to do it for you. You can get a CSP add-ons for Java: JCSP, and for C++: C++CSP. Alternatively languages like Eiffel, Erlang, Occam, and Oz, offer more of hat you need out of the box - concurrent programming with those languages is easy to get right. Changing languages is, of course, not an option for most people.

Right now, something worth getting good at is understanding how to write highly parallel programs that are reliable. Write something that has lots of intercommunicating threads and be confident the locking is correct. There aren't that many people who consistently get that right.

"Pattern matching" in the OP's terminology probably refers to a a feature in functional languages like ML. It doesn't necessarily have to do with regular expression pattern matching. For example, pseudocode like:

def findLinkedListMax(node):
        """Returns the max value in a linked list."""
        if node == None: raise ValueError
        else if node.next == None: return node.value
        else: return max(node.value,
                                          findLinkedListMax(node.next))

can be written in a pattern matching way like this (again, pseudocode):

exception ValueError;;
let rec find_linked_list_max l = match l with
        [] -> raise ValueError
    | hd :: [] -> hd
    | hd :: tl -> max hd (find_linked_list_max tl)

where the language itself is aware of data structure internals and is able to de-structure things without having to use selectors. The example above doesn't seem like much, but for more complex data, pattern matching can lead to very clear code.

For a larger example of pattern matching, see Wadler's paper on "A critique of Abelson and Sussman or why calculating is better for Scheming":

http://www.cs.kent.ac.uk/people/staff/dat/miranda/ wadler87.pdf

This seems to be a topic that it easier to think about than talk about. As you suggest in the title of your original post, a lot of the problem can be mere semantics. Or to paraphrase the old adventure game, we seem to be facing a maze of twisty little metaphors all alike.

Another possible source of disagreement is the perspective of where we are coming from and where we want to go. I am trying to reconcile my "Physics" view of the world with my spiritual view. In particular I am interested in exploring the connections (if any) between the mathematical ideas exposed by Godel's Theorems and my experiences of self-awareness and consciousness. I see some very interesting parallels between the mathematical techniques used to "tame" Godel's Theorems and some of the common threads that run through many of the great spiritual paths.

Another source of difference is our personal experiences. I was extremely struck by my first instant of self-awareness. My realization of the hall of mirrors occurred many years later and was beautiful and dizzying but was not nearly so profound. What was almost as profound was my appreciation of the existence of the consciousness of others. The metaphor I find most useful for this experience is Indra's Net where each jewel in the net is a consciousness that reflects all of reality.

Perhaps your experience was vastly different from my own. Maybe you were given the hall of mirrors as mediation topic or a koan and it led you to a profound experience.

In your original post you had asked if there was any AI or evolutionary psychology definitions of self-awareness. The best (in fact, only) scientific definition I know of is the mathematical one discovered by Godel and explained in Smullyan's book.

I admit that it might seem foolhardy to try to make any link between the mathematics of Godel and human consciousness. This path is certainly filled with traps that have already caught many. For a while I despaired that anything more than weird coincidences and wild speculation would be impossible. But then I found E. T. Jaynes' book Probability Theory : The Logic of Science and my hopes increased. Jaynes mathematically defines an optimal "plausible reasoner" and makes several compelling arguments why our own personal models of reality should follow the same rules as the plausible reasoner.

It may never be possible to prove that results similar to Godel's apply to human consciousness. But it might be possible to apply Godel's ideas to Jaynes' plausible reasoner. Any non-trivial results would be extremely interesting and would help give us insights into human consciousness even though we can't prove mathematically that they apply to consciousness. AFAIK, very little (if any) of the non-trivial things that have been said about human consciousness can be proven mathematically.

I am not looking for proofs, for now I am content to examine the analogy and see how the concepts discovered by Godel relate to similar ideas in some of the major spiritual paths. I don't think I can change anyone's beliefs, but I hope to develop a very well defined vocabulary so that practitioners of various paths could say "yes this is what I am talking about" or "no that is not what I mean".

At best it would be a precise language with which to discuss consciousness and spiritual matters, at worst it would be all:

That is not what I meant at all.
That is not it, at all.

Why would you want to use a CSP-style concurrency model instead of threads? To quote from the occam compiler homepage:

CSP has a compositional and denotational semantics, which means that it allows modular and incremental development (refinement) even for concurrent components. In turn, this means that we get no surprises when we run processes in parallel (since their points of interaction have to be explicitly handled by all parties to these interactions). This is simply not the case for standard threads-and-locks concurrency, which have no formal denotational semantics and by which we get surprised all the time.

In layman's terms, you get concurrency that can be built up from easily understood pieces (instead of a monolithically concurrent system with locks scattered throughout the code), and an underlying theory of concurrency that lets you understand and analyze your design and ensure that it is, for example, free of deadlocks (I've personally created complex networks of 1000+ interacting processes in a dynamically evolving topology, with nary a hitch). And did I mentioned that the context-switching performance of most of these systems is amazingly good?

Pros and cons of garbage collection?

If you don't CONS, you never need to collect garbage. *rimshot*

More seriously, GC isn't so much about pros and cons, as it is about tradeoffs between the various GC algorithms: time vs. space, low-latency vs. high-throughput, parallelism, etc.

If you're designing a new language, it should include garbage collection, or nobody will use it (i.e., your target audience can already program in C). You may wish to have multiple GC implementations available for different purposes, perhaps to be selected at compile-time.

For a good overview of what's available, see http://www.memorymanagement.org/

My personal favorite is the good old Cheney semi-space collector (and Ephemeral/Generational Garbage Collectors, which are more advanced versions designed to generally have low latency), as it is very straightforward (both to understand and to implement), compacting (it defragments memory, and can perhaps improve cache locality by grouping related objects), and it has high throughput (work is proportional to the amount of live data, not total data).

If memory usage is of more concern than fragmentation and throughput, a mark-sweep collector may be more your style.

There are also "real-time" (and "soft-real-time", i.e. bounded latency [see Henry Baker's Treadmill]) collectors, parallel collectors [including an interesting case for reference counting, usually considered a dog performance-wise, as a viable parallel/remote GC method], "conservative" collectors for C/C++ (see Hans-J Boehm's libgc), collectors for real and hypothetical computers with special hardware and/or OS support for GC features, and some collectors that are just plain weird.

Note also that garbage collection algorithms are considered hard to measure for performance, especially with regard to wall-time latency, so just because a paper(*) claims that a certain GC has certain performance characteristics, be sure to benchmark if it really matters.

(*) Did I mention papers? If you're serious about implementing GC, getting comfortable reading CS research papers is a must. The book "Garbage Collection" is your best friend here, as it provides a very good overview/survey of said papers and algorithms, and it discusses a lot of pros and cons between various algorithms, and useful variants or adaptations that have been applied to previously-published work.

Also check out Henry Baker's papers, because he is a memory management demigod: http://home.pipeline.com/~hbaker1/home.html.

Just to add, there are languages designed specifically to exploit parallel architectures, effective in both shared-memory and non-shared-memory environments. Bit of a plug, but see KRoC (the Kent Retargetable occam-pi Compiler). And google for CSP (Tony Hoare, Bill Roscoe) for the formal semantics that make such parallel systems "safe" (and understandable/composable).

The key advantage that CSP has is that it is a real, live, honest-to-god mathematical theory of concurrency, which means that the primitives and composite operators have extremely well-defined semantics, and have been analyzed to ensure that they compose correctly. Plus, you can express a design intended for a language that supports CSP-style concurrency directly in CSP notation, and then analyze it using various tools (or even pencil and paper) to ensure that it is deadlock-free, and maintains whatever properties you want maintained.

If you are a Java programmer, you may want to check out the JCSP library of CSP primitives for Java. IMHO much easier to use than Java's native concurrency model.

Erlang is much nicer to use than Java's built-in thread model. If you want decent concurrency for Java you should get the JCSP library.

I've personally created complex programs with several thousand threads, without having to worry about any of the defensive techniques you preach, simply by using a better concurrency model. Not only do they work, I can prove that there are no thread-related bugs (which testing - no matter how much you do - simply isn't guaranteed to catch) because the CSP concurrency model can be mathematically analyzed and mechanically model-checked.

See also occam, the original CSP-based language, and JCSP, a CSP library for Java. The WoTUG website has lots of great references on CSP, occam, and the communicating process model in general.

See also occam, the original CSP-based language, and JCSP, a CSP library for Java. The WoTUG website has lots of great references on CSP, occam, and the communicating process model in general.

CSP provides a way to think about concurrency. Theoretical work in CSP is done in mathematical notation. Mechanical verification of CSP models can be carried out by translating those models into CSPm, a machine readable version of CSP that does indeed embed a Haskell-style functional language. However, CSPm is not intended for creating final implementations, merely for modelling and understanding a design at a higher level of abstraction.

Occam provides one implementation of CSP-style concurrency in an actual programming language (literally built into the language). The advantage of doing this is that abstract system models of even very complex systems, that can be verified to be free of deadlock, and to meet their specifications, can easily be translated into equivalent software that will also maintain those properties. It's nice to have those features built into the language, but by no means absolutely necessary - see for example Peter Welch's work on building CSP-style primitives for Java (the JCSP project).

Yes, Haskell provides a Concurrent library with various threading primitives. But the point is that the threads model is decades old, and not the best way to do concurrent programming - it predates monitors (which everyone seems to agree are a good idea), and Hoare discarded his monitor concept to develop CSP due to weaknesses in the monitor idea. But the threads model, while easy to understand, can be very difficult to apply safely in any system above a modest level of complexity. One problem is that threads can often be tightly interdependent, so that their semantics compose in non-trivial ways - the whole skill in multi-threaded programming lies in setting up and staying in control of these complex interactions. On the other hand, parallel composition of CSP processes is mathematically clean, yields no engineering surprises and scales well with system complexity. The result is cleaner concurrent systems, in a much more understandable and maintainable form.

Haskell is a great language. Just not necessarily the best one to use for concurrent applications. Presumably you could build a library of CSP-style primitives for Haskell on top of the existing threads library (similar to JCSP for Java). But it would be nicer if it was built directly into the language (cf occam, Erlang, Newsqueak, or Concurrent ML). If type-systems are your particular fetish then yeah, occam may not be for you - it was originally designed for embedded systems. In that case, you might want to check out Concurrent ML or Erlang instead.

You can avoid whole classes of bugs by having proper language support, and programmer time can be reduced considerably.

Very true. So the question is why are you choosing a language that doesn't support nice features like Design by Contract (which helps avoid whole classes of bugs, makes debugging far simpler, and thus reduces programmer time considerably), or (a new one to me) CSP style programming (which makes writing multithreaded programs a breeze, meaning you can just do things multithreaded from the outset, obviously reducing programmer time considerably)?

Yes C# and OO languages have nice language features that aid in development. That's not the be all and end all however. Both ideas I just mentioned are very old (DbC is decades old, CSP about 20 years old), yet we haven't gotten around to using them, mostly because people simply don't know what they are, what they can do, and how much simpler they can make things.

Jedidiah.

Now you either need:
a) A really intelligent compiler
or
b) A really intelligent programmer

or
(c) A language and corresponding underlying concurrency theory that allows you to design and analyze complex interacting multithreaded systems with ease.

The breakthroughs that you want were invented years ago. You might want to look into a language called occam - see occam-pi for a recent implementation. Occam is based on Hoare's CSP concurrency model, which makes dealing with concurrency easy. Similar ideas were implemented in Plan 9's Alef language, and also in Limbo on the Inferno OS.

The breakthroughs that you want were invented years ago. You might want to look into a language called occam - see occam-pi for a recent implementation. Occam is based on Hoare's CSP concurrency model, which makes dealing with concurrency easy. Similar ideas were implemented in Plan 9's Alef language, and also in Limbo on the Inferno OS.

Better yet, use occam !
http://wotug.kent.ac.uk/parallel/www/occam/occam.h tml

Well, there is a CSP/Occam-derived add-on for Java that supports a robust concurrency model. It just isn't widely used (yet). Note that there are similar concurrency toolkits for C and C++ (in fact I believe that the x86 port of Occam is built on top of the CCSP toolkit).

Here, the guy put up mirrors of the videos. (the link on the main page article is 404 now.)

• http://library.kent.ac.uk/mirrors/jibble.org/CIMG0 057.AVI
• http://library.kent.ac.uk/mirrors/jibble.org/CIMG0 053.AVI
• http://library.kent.ac.uk/mirrors/jibble.org/CIMG0 051.AVI

Here, the guy put up mirrors of the videos. (the link on the main page article is 404 now.)

• http://library.kent.ac.uk/mirrors/jibble.org/CIMG0 057.AVI
• http://library.kent.ac.uk/mirrors/jibble.org/CIMG0 053.AVI
• http://library.kent.ac.uk/mirrors/jibble.org/CIMG0 051.AVI

Here, the guy put up mirrors of the videos. (the link on the main page article is 404 now.)

• http://library.kent.ac.uk/mirrors/jibble.org/CIMG0 057.AVI
• http://library.kent.ac.uk/mirrors/jibble.org/CIMG0 053.AVI
• http://library.kent.ac.uk/mirrors/jibble.org/CIMG0 051.AVI

Nice to see someone else thinking that occam got missed. Incidentally it is still alive and well, one implementation is KRoC.

Almost every university calendar states the rather severe penalties that are usually enforced if people plaigarise, up to and including expulsion. Many, albeit not necessarily all, university instructors also mention the issue of plaigarism in their own course description, and/or they refer specifically to the university calendar where the rules and the repercussions for breaking them are described further. And, finally, most universities have some kind of general statement on the concept of ethical conduct as it applies to students.

It is a little hard to believe he did not encounter any of this previously.

Well look at that:
Annex 10: Academic Discipline
===========
Information for Students, Teachers and Examiners
Annex 10: Academic Discipline: Procedures

1.
General Regulation V.3 Academic Discipline

Regulation V.3 of the General Regulations for Students states:

Students are required to act with honesty and integrity in fulfilling requirements in relation to assessment of their academic progress.

Note: The following are some examples of conduct which will be regarded as a breach of this regulation:

o Cheating in examinations
o Attempting to influence an examiner or teacher improperly
o Repeatedly reproducing the work of others without proper acknowledgement
o Conspiring with others to reproduce the work of others without proper acknowledgement, including knowingly permitting work to be copied by another student
o Falsification of data
==========

It goes on to explain what the actual consequences and procedure would be upon breach of any of these regulations.

What a dingbat.

Apparently, it's a 10,000 student university, with multiple campuses (in multiple countries) and a bureaucracy to match.

another mirror

My own personal recommendation would be the original book on CSP (it is an expanded paper essentially), an idea that is well worth-while, and also look at some of the useful applications

My own personal recommendation would be the original book on CSP (it is an expanded paper essentially), an idea that is well worth-while, and also look at some of the useful applications