去年最受欢迎的语言和往年一样，没有变化，仍然是：Java、C、C、PHP、Basic。前几名的语言要在短短的一两年有变动，是不太可能的。这五个语言哪个不是占据Top5的位置五或十年以上？估计2009年仍然是这样的局面，由这几个语言独占鳌头。
但C#已经在快步进逼BASIC，可能再过两年就可以进入前五名。C#上升，BASIC下降，某种程度上反映出微软的VB程序员正转换到C#语言。C#正在逐渐累积和Java抗衡的能量。
在2009年，最值得重视的编程语言好消息，应该就是C了。C0x的x最终被设定为9，将于2009年推出这个标准。经过十年的经验累积，许多C既有的缺点都将在这个标准中获得改善，值得我们期待。
得益于Google的强力背书下，Python这几年小有斩获，现在已经变成通用型脚本语言的第一选择，Python兴起，导致Perl风华难再，两者消长的态势相当明显。而且在2008年末，大家期待已久的Python30也终于推出了。
现今，我们生活在Web的时代，Web后端或许百家争鸣（Java、PHP、NET、），但Web前端还是JavaScript一枝独秀。尽管JavaScript语言存在许多为人所诟病的地方，但JavaScript的重要性仍会持续上升。
对Delphi来说，我承认我过去看走了眼，认为它会持续触底，但2008年显然是Delphi重新被群众拥抱的一年。Delphi曾经拥有许多高手级的使用者，甚至对VisualBasic造成威胁，但是过去这几年在Java和NET的出现之后，以及Web应用席卷全球后，Delphi明显地被边缘化了。外患加上内忧（Borland公司内部的变动），使得Delphi的形势相当不佳，连原文书都找不到几本。在Borland将开发工具部门切割出CodeGear，接着CodeGear又被Embarcadero买下之后，Delphi好像又渐渐有起色了，但说它拨云见日还太早。
如果说Delphi触底反d，那么遭遇完全相反的就是Ruby了，近期Ruby的招聘大幅降低。对于一个窜升太快的语言，需求稍微有跌落，是正常现象。Ruby长期应该仍会是缓慢上升的格局。
今年是Lua丰收的一年，能见度大增，除了用在游戏软件开发之外，也陆续被一些重要的商业软件商所采用（例如Adobe公司）。我看好Lua，因为在嵌入式语言领域，还没有其他语言可以与之匹敌。
说到Adobe，今年推出AIR之后，好像市场的热度还没起来，所以Adobe的官方语言依然载浮载沉。我希望它能在2009年有更好的表现。
Erlang在2008年的表现不错，持续缓慢上升。Java平台上的两个语言Groovy与Scala也开始受到关注。这些新语言某些程度也相对地呼应了函数式编程（functionalprogramming）与动态语言崛起的现实状况。
根据Net在2009年1月的数据显示，Apple计算机的市场占有率已经达到963%，而且iPhone在过去这一年半的销售数字更是相当抢眼。受其影响，开发MacOS应用软件的官方语言Objective-C也大有斩获，越来越受到重视。要不是Apple的笔记本太贵我买不起，否则我早就开始学Objective-C了。
我注意到过去一年有一个奇怪的语言忽然冒出头，叫做Alice。Alice是一个3D动画的制作环境，适合用来辅助说故事。这个语言之所以叫做Alice，该不会是和“Alice'sAdventuresinWonderland（爱丽斯梦游仙境）”的故事有关？
容我在此有一点私心介绍一下REBOL语言。根据目前的开发进度来看，2009年将会是REBOL30发布的一年。我希望大家多多关注这个语言。你可以到我的REBOLOGY博客（blogspot）上看看它的动态。
分析完重点语言之后，就整体来看，我们会发现动态语言和函数式语言越来越受欢迎。我自己就是从C、C到Java、C#，再到Erlang、REBOL，我使用的语言越来越动态、越来越偏函数式编程。
动态语言受欢迎
由于动态语言越来越受欢迎，NET和Java都注意到这样的现象，试图让动态语言可以更容易地整合到自己的平台上。Java阵营的DaVinciMachine，微软的DLR（DynamicLanguageRunti-me）都是这种趋势下的产物。我们可以预期在不久的未来，动态语言会更加蓬勃发展。
动态语言势力之广，可能远远超出你的想象，下面列出常见的动态语言：D、JavaScript、、Erlang、Groovy、Lisp、Lua、Objective-C、Perl、PHP、Python、Ruby、Scala、Smalltalk、Tcl、VBScript。
究竟动态语言有什么样的魅力？因为动态语言可以用更简单的方式，做到静态语言很难做到的事。我很难用三言两语介绍动态语言的特点，而且动态语言的定义也似乎见仁见智，值得写一篇专文好好地介绍。
函数式语言崭露头角
除了动态语言，函数式语言也是一种趋势，连微软都推出了F#。去年年中我在台湾微软讲过两场F#的讲座，听众不少，显示大家对这类编程技术相当好奇。
函数编程（FP）长期以来没有出现在主流的商业软件世界，真正让FP无法被接受的原因可能是“执行效率”。传统上，函数式编程语言的效率确实比命令式（imperative）编程语言来得差，这在商业系统上是不能忍受的。但是这个原因却有了变化。今天，我们有了新的衡量标准：“简单”、“快速开发”比其他因素都更重要，因为现在软件的复杂度已经到了我们无法忍受的地步，而IT产业的竞争也比以往激烈许多。
想要“简单”、“快速开发”，就要用比较高阶的抽象，因此函数式编程比命令式编程更适合现在的开发环境。这些年来硬件的进步，使得函数式编程的效率不再是大问题；甚至由于编译技术的进步，函数式编程语言的执行速度，现在也已经不再是吴下阿蒙。
近年来硬件的发展，使得局势似乎180度反转成为对FP有利的局面：多CPU、多核心、超线程（HyperThreading）的硬件架构普及，以及分布式运算的流行，这根本就是专为滋养FP繁殖而打造的环境。
但是，大多数的程序员想从OO或者procere式的编程方式，转到FP，难度是不小的。
语言联合国
当一个系统比较大的时候，使用混合语言编程是很常见的，因为：
每个语言都有适合使用的时机，一个大系统可以分成多个次系统或模块，每个次系统都有不同的特质，适合采用不同的语言。
大系统开发时，开发者的人数变多。每个人倾向于使用自己熟悉的语言和工具。
以我自己的例子来说，基于上面的考虑，我规划的系统，同时使用C、C#、REBOL、Lua，未来可能还会加入Erlang。我们用C进行系统编程（处理低阶的，和 *** 作系统相关的部分），使用C#写跨平台的服务器（未来考虑用Erlang取代），使用REBOL写解析器和编译器，使用Lua作内部脚本语言。每个语言各适其所。
使用混合语言的开发方式，另一个好处是程序员擅长什么就用什么。学习一个语言到精通的地步，需要很长的时间。我们无法要求自己团队的程序员都能使用某个我所熟悉的语言，可以退而求其次，让他们用自己最熟悉的语言，只要开发出来的东西符合我们规定即可。
使用混合式语言开发，只要模块切割得当，接口定义清楚，架构设计正确，那么绝对是可行的。这是我的经验之谈。
但是也请注意，混合多语言可能会导致维护难度的提高。当开发某模块的人离职，且当初他所使用的语言没有其它人会，这个时候麻烦就来了。
混合多种语言开发系统，有可能要面对语言之间的阻抗（impedance）问题，就好像不同国家之间会有不同的文化隔阂一样。好的系统设计应该要考虑到这一点，减少模块之间的接触点，设法让语言之间的阻抗降到最低。
我的建议
如果你想培养一个全能的联合国梦幻开发团队，我的建议是要集合下面的语言人才：
C：进行系统开发
C：进行COM与传统的微软技术开发
C#：进行现代的微软技术开发
PHP：进行Web后端开发
JavaScript：进行Web前端开发
Objective-C：进行Mac或iPh-one开发
Java：毕竟许多地方还是会用到Java
Python：进行脚本开发
在线更新，更新过程中可以正常进行游戏，不用停机。不停机更新一般都都是进行比较小规模的更新·，大规模的（比如版本的更迭）都是要停机更新。
停机维护的根本意义在于让服务器休息一下处理一下数据或者更新系统新文件和内容。
服务器就像一起玩局域网游戏一样，也是一台电脑，但能力很大，配置很高，开久了会影响运行程序速度。
在停机维护之前，服务商一般会发布公告、提示停机维护的时间段，以提醒用户做好相应准备。
停机维护期间用户无法使用服务商所提供的服务，停机维护经常会在公告的时间段之前进行完毕。
不仅仅是网游需要进行停机维护，一些大型的系统有时也要进行停机维护，以维持系统的正常运行。
扩展资料
不停机更新技术：
事实上，大多游戏服务器分为逻辑程序服务器和数据库服务器，如果是线上运营的服务器，基本上是在至少两台主机上。
在发现几个逻辑服务器中的bug，或者加了某些功能，比如少加了三个金币，多算了一点经验等，只需要在测试服测试完毕，上传覆盖执行文件(jar或php)，但是依然要重启逻辑服务器进程。
而Erlang的热升级技术，就带了更好的体验。Erlang原本脱胎于电信行业，Jow Armstrong 在描述Erlang的设计要求时期中就提到了“软件维护应该能在不停止系统的情况下进行”。
在实践中，因为这种不停服务的热更新获益良多，终于不用再等到半夜没人的时候再做更新了，对于一些紧急的bug修复，热更新实在是一把利器。
Erlang热更新的秘密其实都集中在code模块、code模块是Erlang Code Server暴露出来的对外接口，其职责就是把已经编译好的模块加载到Erlang的运行时环境。
代码版本有两个概念，当前版本代码“current”和老版本代码“old”,一旦模块被加载就变成“current”,再有一个版本过来被加载,之前的版本就变成“old”,新加载的变成“current”。
这时候,两个版本还是同时存在,新的请求执行的时候会使用新的版本,而老版本的代码还会被使用因为还有其他模块的调用“old”版本中。
再进行一次热更新,这时就有第三个实例被加载,code server就会终止掉还在驻留在“old”版本代码依赖的进程。然后第三个实例成为“current”,之前版本的“current”被标记成“old”。
这种方法有效降低了因版本升级而导致的用户流失。
参考资料来源：百度百科-停机维护
参考资料来源：英雄联盟-12月4日不停机版本更新公告
完整支持MQTT V31/V311协议规范，扩展支持WebSocket、Stomp、CoAP、MQTT-SN或私有TCP协议
完全开放源码
基于Apache Version 20开源协议
百万级并发连接
单节点100万并发MQTT连接峰值负载
完整MQTT协议支持
MQTT V311协议规范QoS0/1/2消息支持
简便安装部署
跨平台部署在Linux、FreeBSD、Mac OS X或Windows服务器
分布式集群或桥接
双节点负载均衡或多节点分布式集群
扩展模块与插件
LDAP, MySQL, PostgreSQL, Redis, MongoDB扩展插件集成
EMQ! 给分给分给分！
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）