为充分利用不断增长的处理器核数量，需要程序员在编写并行算法时发挥更大的作用，以便各个核能相互协作。目前的编程语言可采用类似消息传递接口(MPI)这样的框架，但使用该方法需要占用大量设计时间。该方法可以升级，虽然有时并不是必需的，但当系统设计做得不好的时候，程序员大多希望升级该方法。这也是人们对并行编程语言的兴趣日益增长的原因之一。
带MPI的***单线程语言(例如C语言)和并行编程理论之间的主要区别是，并行编程理论通常假设存在隐式并行执行。在工具包諱OD黾诱饫嘤镅杂行┪惫纾俨⒐刈⑺呛问闭嬲鹱饔檬侵档玫摹?br /> 
诸如美国***仪器(NI)的LabVIEW、MatLab的Simulink以及对象管理***(Object Management Group)的UML(统一建模语言)等图形编程语言和环境往往会针对新手和***开发不同的设计。新手可从降低了复杂MOD的封装中受益，而***则获得一种以任何人都能明白的方式表述复杂算法的途径。任何使用过IAR Systems的visualState的人都了解，与内嵌的C代码相比，采用图形化状态图做开发是多么容易。
这些面向基于文本的程序员的图形编程环境已取得稳步进展。程序开发者也许仍然会更偏爱文本编程方法或图形编程方法，但将两者严格划分(all-or-nothing)的方法似乎已过时了。
UML和C语言不再泾渭分明
许多UML 2.0产品已经能够针对Ada、C、C  和J***a等语言从UML(统一建模语言)模型中生成代码。尽管这样，通常还是希望C语言开发者能学会UML。虽然以前的代码可以继续使用，但开发者应该将学习UML作为新的目标。
在Telelogic的***新版(V7)Rhapsody中，对C语言的***新支持通过允许C语言开发者在建模的同时保留文件和目录层次(开发者已将文件和目录层次与Eclipse IDE(集成开发环境)等工具一道使用)而实现了突破。
这不仅是对现有资源文件的利用，而且可利用这些文件的关联关系来展示并构建图形模型。Rhapsody的反向工程特MOD可扫描源文件并生成这些C语言类型的模型，从而使得启动模型几乎不费什么力气。
更重要的是，Rhapsody具有可在Eclipse CDT(C/C  开发工具)和UML模型之间来回变换的能力。变换朝两个方向进行，这使得设计师可以完成高层次的UML设计并在代码中反映该变换。同样，随着UML中的功能逐渐可用，添加到C源代码中的新功能也将显示出来。只需点几下鼠标就可在C源代码和与之匹配的UML定义之间反复变换。
当然，如果并没有采用合适的代码管理工具，变换可能会让程序员和管理者晕头转向。这就是新的图形差异化特MOD十分重要的原因。它以图形化方式凸显了UML模型中的变化。
V7版Rhapsody中的另一项新功能是对Mathworks的Simulink R***的支持。它在UML和Simulink的代码之间提供了相似的链接，从而允许将等式和Simulink建模代码整合到Rhapsody中。该整合可提供协同执行的能力。
并行编程语言的挑战
并行编程语言仍处于研究开发阶段。Sun的Fortress解决了大量应用和编程问题，但它基于有大量内核且内核间通讯良好或内核间共享存储器的系统。线程与基本代码模块同步。
并行编程语言面临许多挑战，包括技术问题以及针对社会问题的优化。对于大多数编程人员来说，转换编程语言是件很不寻常的事情，而学习一种新的编程语言一般需要投入大量的时间和精力。
并行编程语言没有沿用传统串行编程语义，因此默认值是执行并行操作，而不是串行操作。编译器和运行时间环境必须对并行操作进行优化，使编程人员免于处理这些零碎工作。还必须明确定义串行操作，因为这时串行操作属于例外而不是常规操作。