爲何繼續選擇DELPHI?

  已經鑽DELPHI很深了，固然如今DELPHI是過了最輝煌的時代。但爲何要繼續下去，而不轉向其它的?這是否是死腦筋？

我看了一下C#的LINQ的產生，而後又被實體框架所代替。思考了一下：

1）LINQ的確是有好處，可是所用的場景又很少，這樣就會變得很雞肋。因此說學新的東西，有時對本身來講不必定有至關大的好處。

2）軟件編程發展示在，會有不少花巧的小東西，這些小東西可能帶給你好處，但也不必定。只要你用不上，就沒有好處。並且有些東西只是過渡性，嘗試性，上家以爲很差又可能把它放棄，這的確對開發員很忌的事情，不跟M$也是這個緣由。C語言很老，但到如今仍是排第2，能夠說明這些問題。由於C什麼均可以本身作，本身作上家作輪子。它功可以單一，不須要太多東西也能排第2。

3）框架問題，其實深刻一件事，在長時間編程中，會積累對本身工做有利的框架。這樣本身的工做效率也會不斷提升。若是跳到另外一個坑，又得從新積累，因此這樣不必定划得來。而框架積累到必定時，效率不必定比新玩意差多少。

4）客戶要求，大部分都對語言沒有要求。只要方向不變，何苦要折騰本身。也許有些客戶是有要求，但這樣的單子能夠不作。若是對語言有要求，同理又能夠要求使用什麼框架，什麼結構等。可是框架是變幻無窮，編碼風格也是。一份源碼，就算是最熱門的語言，給另外一我的維護也不容易。

5）D繼續發展，不怕小衆。只要仍是本身用，就不怕小衆。一我的只能作好本身的本份事。本身寫得舒服，客戶用得舒服就行。滿足常樂，沒必要什麼事都要爭第1，騰出的時間能夠作好其它東西。其它的事情也很重要。人就是要平衡好，若是人太苛刻，事事求最好，事事反作很差。

6）善用不起眼的小東西，思考問題。升提本身。以前我有點抱怨DELPHI分實現部分和定義部分，改代碼不方便。後來用了MMX,發現這個缺點沒有這麼明顯了。工做起來也舒服得多。最新的DELPHI XE IDE,CNPACK,MMX各類小東西不斷深刻再深刻，發現用得好，也是不錯。雖然整體和最熱門的C#總有些差異，但整體問題不大，能夠接受。
    調試代碼也是，以爲VB一類的語言能夠邊調試邊改代碼，D不能。但後來改進了調試技術和調試習慣，發現問題也不算很是大。
　其實這也是處人處事的哲理，一我的也是，沒必要由於小小的事情，就抱怨本身的所處環境如何很差，要換這個換那個。其實生活和工做，只要用心分析，就算是在有限的資源下，不斷的進行小改進，也會取得好的結果。

以上幾點只是針對本身我的狀況所思所想的交流看法，也許讀者來講，會有另外一番不一樣想法。