Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
In control engineering or instrumentation, I see Simulink or LabVIEW(G) is pretty popular.
In ESL design, I see that Agilent SystemVue is gaining some popularity.
If you see the well established compiler theroy, almost 100% is about the textual language. But how about the graphical language?
Is there any noticable research or discussion about the graphical programming language? In terms of
Theory about Graphical Language - syntactic/semantic analysis and whatever relevant
expressiveness (Actually, I asked a question about it at SO - What do you mean by the expressiveness of a programming language?)
Possibility of the Graphical language
...
Or what do you think about the Graphical Programming Language?
DRAKON is basically a flowchart optimized for readability.
http://drakon-editor.sourceforge.net/DRAKON.pdf
There are editors that can generate source code in C, C++, Python and Tcl.
For example:
http://drakon-editor.sourceforge.net/python/python.html
I heard about one such language called DRAKON. It was developed for the Buran space project and now it seems to rebirth (language, not Buran =)). The only problem is that the most of materials about this language is in Russian. I'll give you some links anyway:
Article in Russian Wikipedia.
OberonCore forum DRAKON subsection in Russian.
DRAKON + Oberon = DRON visual programming language in English.
Wouldn't know anything about theory, but Lego MindStorms has a great graphical programming environment for programming the NXT robot toolkit (based on LabView components) that is extremely fun to use.
For kids it seems to be very easy environment in which to learn how to program by for example tweaking the functionality of existing programs or following instructions. When English (or any other written language for that matter) is not all that well understood the graphical environment makes it much easier to use than any written textual language.
The graphical language is perhaps "simple" in the sense that there is only one loop construct, one switch construct and a set of "high" level functions but i find it fit for the purpose.
From a slightly different angle, this is in issue tackled in the interfaces for graphical programming tools for creative use, such as MaxMSP and Isadora - it might be useful to see how they handle the issues involved.
Prograph is pretty cool - it's a general purpose graphical programming language and it uses a data flow paradigm.
See also Marten.
Quartz Composer presents a graphical interface for constructing image composition workflows. (I think that would be considered a "programming language".)
A little late but I can also recommend the IBM / Rational Rose Realtime (commercial). Be aware that it is something different than "Rational Rose".
http://www-01.ibm.com/software/awdtools/developer/technical/
http://nimotoons.com is a 100% graphical development language based on functional languages.
it is from UPC and still under construction
You should also try YAWL which has a pretty good background in workflow programming in a graphical way, you can see:
http://www.yawlfoundation.org/
See workflow patterns which is a really good theoretical basis, I think, to approach graphical programming.
You could try Cameleon: http://www.shinoe.org/cameleon which seems to be simple to use.
Its written in C++ but can call any type of local or distant programs writen in any programming language.
It has a multi-scale approach and seems to be turing complete (this is a petri net extension).
sheers,
Myosis.sh
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently working on the topic of programming-languages and interpreter-design. I have already created several programming languages but couldn't reach my goal so far:
Create a programming-language which focuses on giving the programmer a good feeling when writing code in it. It should just be fun and/or interesting and in no case annoying to write something in it.
I get this feeling when writing code in Python. I sometimes get the opposite with PHP and in rare cases when having to reinvent some wheel in C++.
So I've tried to figure out some syntactical features to make programming in my new language fun, but I just can't find any.
Which concrete features, maybe mainly in terms of syntax, do/could make programming in a language fun?
Examples:
I find it enjoyable to program in Ruby because of it's use of code blocks.
It would be nice if you could include exactly one example in your answer
Those features do not have to already exist in any language!
I'm doing this because I have experienced extreme rises in (my own) productivity when programming in languages I love (because of particular features).
You mentioned Ruby in your question. AFAIK, Ruby is the only programming language, for which Joy is an actual, stated, explicit design goal. (In fact, it is the only design goal.)
The reason that Yukihiro Matsumoto was able to design Ruby this way, is that he already knew and used tons of programming languages before he started designing Ruby and learned tons more in order to design Ruby. (Interestingly, he didn't know Python, and has said that he probably wouldn't have created Ruby if he did.)
Here's just a tiny fraction of the languages that matz has either used himself, or looked at for inspiration (or in some cases for inspiration what not to do):
CLU
Sather
Lisp
Scheme
Smalltalk
Perl
Python
Haskell
Scala
PHP
C
C++
Java
C#
Objective-C
Erlang
And I believe that this is one way that good programming languages can be designed (what Larry Wall calls postmodernist language design): Throw away everything that didn't work in the past, take everything that worked and combine that tastefully.
Of course, this requires that you actually know all those languages from which you want to "steal" and in particular, it requires that you know lots of very different languages with different paradigms, different concepts and different "feels", otherwise the idea pool from which you steal is rather small and inbred.
Consistency.
Its the feeling that you already know something when you use an API or feature you've never used before. It also makes you more productive as you don't have to learn something new for the sake of it.
I think this is also one of the Ruby 'likes', in that if you follow the naming convention, things start to 'just work' without bindings and glue and suchlike.
For example, using the STL in C++, many of the algorithms are the same for all containers - even strings. That makes it nice to use... except for those parts that do not follow the same API (eg vector of bools) then the difference is more noticable.
Two things to keep in mind are orthogonality and the principle of least surprise.
A programming language should make it easy to write correct programs and difficult (if not impossible) to write incorrect programs. For instance, in Java
long x = 2000000000 + 2000000000;
overflows, while
long x = 2000000000L + 2000000000;
doesn't. Is this obvious? I don't think so. Does anyone ever want something to overflow? I don't think so.
Hilarity.
http://lolcode.com/
Follow common practices (like using + for addition, & for bitwise/logical and)
Group logicaly-similar code in namespaces
Have an extensive string processing library
Incorporate debugging facilities
For a cross-platform language, try to minimize platform differences as much as possible
A language feature that appears simple and easy to learn surprises and delights the programmer with its unexpected power. I nominate Haskell type classes :-)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In every technical publication, and on this site too, people are always comparing OO languages to Smalltalk. My experience is in Java: is Smalltalk so important that I should study it?
Smalltalk was one of the earliest object-oriented (OO) languages (with others like Simula and Eiffel) and can be said to be extremely "pure" in an OO sense:
Everything is an object and objects are only communicated with via the sending of messages
No primitives (no ints, booleans etc)
No control structures (no for, while, if etc). Sounds impossible but it's true!
No statics
It also pioneered some other, now common, stuff:
the virtual machine (and JIT compilation)
Debugging by inspection
"Hotswapping" running code
the modern IDE
Closures
Duck typing
Model-View Controller (MVC) architecture for UIs
Test-driven development (TDD) and agile methodology
And there are other things connected with Smalltalk which didn't really make it into the mainstream:
"Image"-based system rather than file-based.
Object-oriented databases
And it's fair to say that the Java collections API and the apache-commons collections API are heavily influenced by Smalltalk.
I wouldn't say that you should learn Smalltalk per se, but a familiarity with the fundamentals of these features (now present in many other languages) is surely advantageous to you.
Note that there are currently only 123 questions on here about the language, which was originally intended as an educational language (i.e. aimed at children) by its creator, Alan Kay. It is not particularly heavily used anymore. That's not to say it isn't used. JPMorgan, for example, has a large exotic derivatives risk-management system written in it.
Smalltalk has many brilliant innovations - things we're all taking for granted today, including:
being the first ever IDE
providing programmatic support for a GUI with a mouse If you learn Smalltalk GUI programming, you really will have understood MVC properly.
being built out of a small number of powerful ideas that work together extremely well
The Smalltalk way isn't to crash out on unexpected behaviour - it's to adapt. If you send a message to an object that doesn't understand it, the debugger comes up and invites you to write that method... so it provides excellent support for incremental development.
The IDE, the app that you're writing and your data are all part of the same system - so you can write your own tools and debug instrumentation far more easily.
The TDD toolset in Smalltalk is still better than any other language (see below).
Squeak Smalltalk has quite a bit of cutting-edge design research:
the morphic UI - you can get familiar with the concept of "liveness"
the seaside web framework - learn what a continuation server is and how it's radically different
Squeak has a strong connection with the OLPC software (one laptop per child) project - and could yet have a big influence on the world.
Find out what a "trait" is...
Play with the radical 3D immersive environment called Open Croquet.
Because Smalltalk is a smaller, simpler and more consistent language, with it's own built-in environment it's a much less confusing place to start teaching OOP. People who go this route end up being better Java, Ruby and C# programmers because they can learn basic OOP without all the messy inconsistencies of mainstream languages.
Some commercial Smalltalks have amazing, multi-node distributed OO database environments. I'm thinking about Gemstone.
Want to know the difference between Model-View-Controller and Model-View-Presenter - look at Dolphin Smalltalk...
The single most important reason to learn Smalltalk today is that extreme programming and scrum both got invented in the Smalltalk community... and the highly interactive style of programming you experience in Smalltalk is simpler, more powerful and direct than anything you can do with Java or C# or Ruby... and you can't really understand how well agile methods can work until you've tried to do extreme programming in Smalltalk. Few other languages (no mainstream ones anyway) have a comparable feature set.
... to really understand what TDD can be you need to use SUnit. JUnit just shows you where your tests failed. SUnit actually allows you click into the debugger at the point where the test failed and see the actual objects and how they're connected so you can see, live in the debugger how the code failed and fix it right there.
Yes, Smalltalk is so important you should study it. Why? You can understand object-oriented programming in pure, simple form. What people forget is that the Smalltalk-80 "Blue Book" has only about 90 pages devoted to the language—the language is just that simple. The other 300 pages talk about the predefined class hierarchy, which is a masterpiece of design for a class-based, object-oriented language that uses single inheritance. You will get a much deeper understanding of objects (e.g., classes are objects, and they have metaclasses, and so on off to infinity... except the knot is carefully tied to keep the system finite) than you would ever get from studying a hybrid language like Java or C++. Smalltalk matters not just because of its history but because of its simplicity:
Simple enough so you can understand the entire language and the libraries
Shows one idea (objects are all you need) pushed to its logical extreme
Everybody has something to learn from Smalltalk!
Smalltalk is one of the first two original OOP languages, the other being Simula-67. Consequently, there are two large families - the statically typed model centered around method invocation, pioneered by Simula (C++, Java, C# all belong here), and the dynamically typed model centered around message passing, pioneered by Smalltalk (Python, Ruby belong here).
Today, Smalltalk isn't particularly important on its own - there are some people still using it to write stuff, but it's definitely not mainstream. Learning it will give you some insight in how and why OOP evolved, however.
I spent about 5 minutes in a presentation at a conference last month on Smalltalk's history and influence. See Image-based development with Smalltalk. One of the more foreign concepts to today's programmers is the "image-based" development. There are some good analogies, including a DBMS and a spreadsheet.
Yes. Download the seaside one-click image, start using it with the tutorial from James Foster and you will learn at least:
how web applications should be build
how debugging is supposed to work
I agree with the others. I'm not sure if it's important per se, but it is COOL (imho).
I love that there are no loops or conditionals in the language. If-then-else is a message sent to a boolean object. Objects of type True do one thing, objects of type False do another. (Yes, True and False are subtypes of Boolean, with a single value each, true and false respectively).
It starts out being kind of counter-intuitive, but it does give you a very interesting, and deep, view of how OO programming should work...
Not only was it one of the first, Smalltalk remains to this day a paragon of OO language design. The more popular languages that came later — C++, Java, even Objective-C — all have more primitive object-orientation and are more restrictive than good old Smalltalk. Smalltalk had pervasive first-class objects, great support for runtime introspection, very natural use of duck typing and closures that worked better than I've seen in any non-functional language. I mean, we're talking about a language that had no native control structures (if, while, etc.) but was able to create them out of its object system in a way that worked seamlessly. How cool is that?
I wouldn't recommend Smalltalk for any intensive desktop app development these days (there just isn't a viable implementation IMO), but if you want to see how OO was meant to be and maybe pick up some ideas you can use in your apps, Smalltalk is a great place to look.
If you only know one object-oriented language you should consider learning a second and a third and a fourth in order to gain a broader perspective on programming with objects. Learning Smalltalk will stretch your brain because a lot of the familiar concepts we're used to in other languages (e.g. if-then-else, for(;;), while(), etc) are not there in Smalltalk. There are equivalents, obviously, but Smalltalk does things differently, and learning about different ways to do things is always a good idea.
Good luck.
I've just started to revive my interest in Smalltalk, and in my opinion, there are a few compelling things that are special about Smalltalk:
Highly productive development
environment
Built-in support for Agile/Extreme
programming methodologies
"Pure" object model
Easy to use graphics framework
None of these make it especially useful for people who are not in the software development business. My first exposure to it was when I saw a user interface for an embedded device prototyped on a PC using Smalltalk. This allowed the user interface to be modified and tested very quickly, and when completed, provided the embedded developers an "executable specification" that was far more precise than any document. I'm surprised I haven't seen this technique used far more often than I've observed in my travels during the last 20 years.
Using Smalltalk as a prototyping tool is where my interest lies: I think that given a new problem, different approaches to solving it can be tried and validated very quickly and easily in a Smalltalk environment, and once the desired solution is found it should be relatively mechanical to convert it to Java/C++/C# etc. etc. In fact, for repetitive sorts of things, it might well be possible to use Smalltalk to generate code for parts of the solution in some other target language.
The other thing about SmallTalk is that its alumni include Kent Beck and Ward Cunningham. Their work with SmallTalk spawned automated xUnit testing, software design patterns, CRC Cards and other practices which ed into XP/Agile, etc. So it could be argued that SmallTalk has been a major contributor to the modern programming landscape.
Just two comments:
Smalltalk is not object "oriented", is real objects, only objects and messages in the environment.
Smalltalk is not a language, is an environment that has a language (of the same name), but most of the "magic" here is thanks to the environment (the image).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
One of the key properties to designing comprehensible software (and, indeed, designing anything at all) is to develop a good set of abstractions. These days, those abstractions include things like functions, classes, interfaces, recursion, and higher-order functions. But what else is there? How can we further abstract our designs, so that I needn't think about anything but my immediate, direct goal? What novel abstractions have yet to be leveraged by existing technologies?
Also note that most of the items on my list (with the exception, perhaps, of recursion) are also tools used for code reuse. Code reuse is not the subject of this question, and is not what I see as a necessary aspect of a good abstraction. Functions are useful as abstractions because they hide what they are doing behind a descriptive name, not because I can call them from several different places.
A poorly-formed idea: Is a driver function that only calls a sequence of other functions, without maintaining any state of its own, really the same as a function? We write it as a function, and call it as a function, but perhaps it represents a different concept? This is reflected in some languages by making a distinctions between procedures returning values and procedures not returning values. But maybe there's a better way to view that difference, some different way to abstract the sequence of relatively unrelated steps?
So to reiterate, how can future programming languages better facilitate abstraction?
A powerful absraction tool, Lisp macros. Why not look into the past and present? :)
They can use self-exposing semantics to better allow metaprogramming of the environment/language presented as the end-user interface. Mutable language semantics.
Some areas that I think are potentially fruitful:
Intentional Programming, or something similar. Charles Simonyi's company Intentional Software has been keeping pretty quiet for a while but is now starting to show some promising early demonstrations.
Functional Programming: ideas from functional programming are increasingly finding their way into more mainstream languages like Python, C# (Linq, lambdas, etc.) and even C++ (lambdas in C++ 0x). F# is becoming a first class .NET language with full support in Visual Studio. The rise of multi core development is another factor driving the wider adoption of functional concepts.
Domain Specific Languages (DSLs): closely related to the ideas behind Intentional Programming, Microsoft seem to be putting some effort into supporting DSLs as part of the .NET ecosystem.
Much more sophisticated IDEs. There are already some positive developments with refactoring tools in IDEs like Visual Studio and IntelliJ but I think there's a lot of room for progress in this area. Moving away from dumb text source files towards something more like an abstract syntax tree representation could make it much easier to work at a higher level of abstraction. Again, this connects with many of the ideas behind Intentional Programming.
By having built in detection of stupid ideas that, when tripped, lock the developer out of the IDE and refuse to let them code ever again.
OOP facilitates abstraction quite nicely. It's developers that come up with poorly formed ideas.
Let's see, how about if we make abstraction mandatory for every data type, and then provide ways of generalizing our abstractions over type parameters? Wait! I've just reinvented CLU. Do I get a Turing Award?
Anyone interested in the role of abstraction in programming should study CLU.
Eiffel code proofs. (warning: link to PDF!)
Functional programming, aspect oriented programming, design by contract and generally everything that takes us away from the dark age of imperative programming.
Also, I hope non - managed software development will cease to exist. C++ and other low level stuff makes me sad. :-(
I like my LINQ, my lambda operator, my extension methods and my fluent interfaces. Oh, and I love PostSharp.NET. And F#, but I guess it's very hard NOT to love F#. :-)
I will give an indirect answer. Before we can develop better constructions in programming languages, we must first understand the theory of abstraction.
Oh yes, there is an actual theory which predates modern computing, it is called category theory.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I would like to write an interactive song. It would contain state and logic. A listener/user should be able to modify some state vars using a GUI or a MIDI interface. Listener accessible vars don't have to directly represent tempo, pitch or any other music property. They would rather represent values that logic would process in order to make changes to the song.
Do I have to write such platform myself or something fitting my imagination already exists?
Look at cSounds and PureData.
If you are happy to use Java, check out JFugue.
I have tried PureData, CSound and SuperCollider.
CSound is very cumbersome to program in, and has had severe stability issues for my requirements (24bit/96kHz realtime low latency linux) in version 4.
PureData is graphical, which makes it even harder to keep code neat and tidy then with text files. Composing is a pain because you have to build your own composition GUI, which can be powerful, but as long as I'm my only user I find it's just faster to use text.
The winner hands down is SuperCollider, because it is a smalltalk inspired object oriented language which is quite pleasant to work with. It is split into an OSC controlled sound server, and the client language. I can recommend the sound synthesis server and using the language to create instruments without reservation for its excellent stability, great flexibility and incredible power. I've used it live on stage and the performance is incredibly good.
The score creation language suffers from many-hands syndrome; in lack of recent clear leadership there are too many ways to do too many things with too many limitations, but it is still better than CSound because at least you can use reasonable high level structures.
Still looking for a composition language that just gets it right.
Have a look at Strasheela:
It's a composition system based on the programming language Oz. Learning Oz isn't easy, as it it combines the functional and the logic programming paradigm. However if you liked the SICP book, then you will probably like it too.
Strasheela treats music composition as a Constraint Statisfaction Problem (CSP), and seeks "solutions" for it. It means that the music style is defined as mathematical constraints on integer numbers (finite domain), that must be statisfied, and the built-in constraint solving system computes the solutions "automatically".
P.S.: I cannot program in Oz, but I'm on my way of learning it.
See High level languages for Computer Music and Programming Languages used for music for help.
I am not sure if it covers what you are after for, but have a look at Java Sound API. For a FAQ about what it can do see here. The benefits are that is already bundled in the SDK and JRE and that is cross platform. Also, you could build the GUI using any Java toolkit.
If it weren't for the interactive bits, I'd suggest looking at Haskore or Nyquist, both effectively being DSLs for music generation.
Definitely take a look at Alex McLean's livecoding demos, though. It's more flexible and interactive as you can possibly imagine, using SuperCollider through OpenSoundControl.
Answer is for .NET:
I found something, checkout NAudio by Mark Heath, a great .NET music library I would say it should be contained in the BCL.
midi-dot-net is another great C# project by Tom Lokovic.
For music interaction, PureData, Max/MSP and OpenMusic (these two last are from IRCAM) are the best. PureData is freeware. Google them!
I don't really get what you want to do, but here is a list of some CL music software, both for composition and cognition: http://www.cliki.net/Music
You're looking for an Audio Programming Language. Another option you should consider is Processing - used by many artists and musicians for this type of work.
-Adam
Its a shame that none said about Chuck................
Chuck is a programming language that is specifically built for music/audio generation and composition.
You can download Chuck at http://chuck.stanford.edu
its a lot easier to use,and is a lot familiar to c,c++,java etc,however its easier to learn too.You can find at Coursera about chuck for free from California arts university,link here.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
With the rise of multicore CPUs on the desktop, multithreading skills will become a valuable asset for programmers. Can you recommend some good resources (books, tutorials, websites, etc.) for a programmer who is looking to learn about threaded programming?
Take a look at Herb Sutter's "The Free Lunch Is Over" and then his series of articles on Effective Concurrency.
Joseph Albahari wrote a good overview of Threading in C# here:
http://www.albahari.com/threading/
I've honestly never read it myself, but Concurrent Programming in Java is a book I've heard recommended by several people.
http://www.yoda.arachsys.com/csharp/threads/
I write about multithreading and concurrency in C++ on my blog. I'm also writing a book on concurrency in C++: C++ Concurrency in Action.
I've read (most of) Java Concurrency in Practice by Brian Goetz, which is very good.
There is obviously a Java-based theme running through the book (using Java specific implementations of threads, locks etc.), but pretty much all of the principles can be applied to other languages.
The author's home page contains a list of articles he has written, some of which include threading related stuff. Maybe start there and if you like his style, buy the book.
For a great guide and reference for concurrency programming in C# (or .NET in general) I'd recommend the MSDN What Every Dev Must Know About Multithreaded Apps article by Vance Morrison on MSDN. It contains a great deal of best-practice information and caveats about multithread development
I maintain a linkblog for concurrency articles, blogs, and projects at:
http://concurrency.tumblr.com
I usually post a link or two per day on a variety of topics (threads, actors, locking, parallel programming) in a variety of environments (Erlang, Java, Scala, .NET, C++, Ruby, Python, etc).
It's Delphi specific, but no reason why the concept wouldn't apply to any other language!
Multi Threading Tutorial
http://www.cilk.com/multicore-e-book/
That's a nice general overview of the sitution, if you're looking for tuorials and books it might be best to specify a language as a starting point so you can mess around with some code.
The Erlang programming language provides an easy-to-use style of concurrent programming. You may never actually use Erlang, but the concepts are transportable to other languages. You might want to read the book Programming Erlang: Software for a Concurrent World .
Fans of functional programming claim that there is no need to learn anything new. Just use a pure functional language, and the compiler or interpreter will automatically parallelize everything. So you might want to learn Haskell, OCaml, or another functional language.
I don't know what exactly you are looking for, but if you are doing WindowsForms development the following blog post is worth every minute reading:
WinForms UI Thread Invokes: An In-Depth Review of Invoke/BeginInvoke/InvokeRequred
I think Boost.Threads is a great C++ concurrency library to learn, especially if you just want to get started in writing multithreaded applications. The code is very succinct and easy to understand, plus the next C++ standard will likely include a threading library based on Boost.Threads (tutorial: http://www.ddj.com/cpp/184401518)
If you want to have a go at doing a highly parallel version of a simple task, or see real solutions, you could do worse than look at the wide finder project. Basically it's about how to do parallel regex matching of log files efficiently, but trying to add as little code as possible.
Participants have submitted solutions in many different languages and the performance results are posted. The original project has now finished and there is now wide finder 2 taking the work on.
CodingHorror has a good introduction to wide finder.
For a rich, thorough treatment of the subject, with a good balance between computer science and practice, I recommend The Art of Multiprocessor Programming. A lot of examples are in object-oriented code, i.e. Java, with other languages scattered throughout. It just depends on the topic being covered. What I really love about this book is that it discusses how common algorithms should be implemented in a concurrent design. Of course, there's so much more!
For general concepts and a treatment of pthreads, I really like Programming with POSIX Threads. Being the library and API that it is, it's in C.
For Windows and C# developers, check out Joe Duffy's blog. Joe works on parallel libraries, infrastructure, and programming models in Microsoft's Developer Division. He has a book coming in Nov. 2008 titled Concurrent Programming on Windows (Amazon link).
Also, don't miss the Godfather's blog: Herb Sutter's Sutter's Mill. He has links to all his articles in Dr. Dobb's Journal and more. Click his Concurrency category.
CPU manufacturers websites have some interesting content:
http://developer.amd.com/documentation/articles/Pages/default.aspx#parallel
http://software.intel.com/en-us/multi-core
Also Intel's opensource threading library has some good references:
http://www.threadingbuildingblocks.org/
If you work with C#, the book "C# 2008 and 2005 threaded programming", by Gaston C. Hillar - Packt Publishing - http://www.packtpub.com/beginners-guide-for-C-sharp-2008-and-2005-threaded-programming/book , will help you.
Highly recommended for C# programmers, because you can download the code with funny examples that exploit your multicore computer.
The book is a nice guide with a lot of code to practice. It tells stories while it explains the most difficult concepts.