你討厭本身喜歡的語言有五件事情是什麼？ [關閉]

最近Stack Overflow上出現了一羣Perl-hate，因此我想我會把「 你討厭你最喜歡的語言的五件事 」問題帶到Stack Overflow。 拿你最喜歡的語言告訴我你討厭的五件事。 那些多是讓你煩惱，認可設計缺陷，公認的性能問題或任何其餘類別的東西。 你只須要討厭它，它必須是你最喜歡的語言。

不要將它與其餘語言進行比較，也不要談論你已經討厭過的語言。 不要用你最喜歡的語言談論你喜歡的事情。 我只想聽聽你討厭但容忍的事情，這樣你就可使用全部其餘的東西了，我想聽聽你但願別人會用的語言。

每當有人試圖將他們最喜歡的語言推到我身上時，我就會問這個問題，有時也會做爲面試問題。 若是有人找不到討厭他最喜歡的工具的五件事情，他就不會很清楚地提倡它或者使用它來獲取大筆資金。 他沒有在足夠多的狀況下使用它來充分探索它。 他主張將其做爲一種文化或宗教，這意味着若是我不選擇他喜歡的技術，我就錯了。

我不在意你使用哪一種語言。 不想使用特定的語言？ 而後不要。 您是否通過盡職調查以作出明智的選擇但仍然不使用它？ 精細。 有時候正確的答案是「你有一個強大的編程團隊，有很好的實踐和不少Bar經驗。改變Foo會是愚蠢的。」

---

這也是代碼審查的一個很好的問題。 真正瞭解代碼庫的人會對它有各類各樣的建議，那些不太瞭解代碼庫的人會有非特定的投訴。 我問的問題是「若是你能從新開始這個項目，你會作些什麼不一樣的事情？」 在這個幻想的土地上，用戶和程序員會抱怨任何他們不喜歡的東西。 「我想要一個更好的界面」，「我想將模型與視圖分開」，「我會使用這個模塊而不是另外一個」，「我會重命名這套方法」，或者他們真的不喜歡不喜歡目前的狀況。 這就是我如何處理特定開發人員對代碼庫的瞭解程度。 這也是一個線索，關於程序員的自我與他告訴個人內容有多大關係。

仇恨並非弄清楚人們知道多少的惟一方面，但我發現它是一個很是好的維度。 他們討厭的事情也讓我知道他們對這個主題的思考程度。

---

#1樓

我恨「我討厭某些語言的事情」列出的五件事怎麼樣？ ：d

5-繪製橙紅色不會成爲蘋果。

設計語言時，設計師一般會考慮到它的用處。 將它用於徹底不一樣的東西能夠起做用，但抱怨它不是愚蠢的。 以Python爲例。 我確信有人會或某人有一天會建立一個實用程序來從Python代碼建立exe。 爲何上帝的地球，你會想這樣作？ 這將是整潔的 - 不要誤解我 - 但它沒有用。 因此不要抱怨它！

精心設計的項目可能包含來自多種語言的代碼。 這並非說你不能用一種語言完成一個項目。 有些項目可能徹底符合您使用的任何語言的能力。

你站在木腿上嗎？

平臺能夠對語言的做用產生很大影響。 隨着時下的垃圾收集者，或甚至帕斯卡早期嘗試「垃圾收集」，能夠幫助內存淡化（也許malloc更多ram ??）。 計算機速度更快，固然，咱們指望更多的語言。 坦率地說，咱們可能應該這樣作。 可是，爲了方便編譯器建立哈希表或字符串或各類其餘概念，須要付出巨大的代價。 這些東西可能不會繼承到它們所使用的平臺。 要說它們很容易包含在一種語言中，只是告訴我你可能沒有一條腿站立。

3-誰的錯是真的嗎？

錯誤。 你懂。 我喜歡蟲子。 爲何我喜歡蟲子。 由於這意味着我能夠繼續工做。 沒有錯誤，會有不少封閉的披薩店。 可是，用戶討厭錯誤。 但這裏有一點冷水。 每一個bug 都是程序員的錯。 不是語言。 具備如此嚴格語法的語言能夠顯着減小可能生成的錯誤數量，這將是一種徹底無用的語言。 它的能力可能一方面可能被計算在內。 你想要靈活性仍是力量？ 你有錯誤。 爲何？ 由於你並不完美，並且你犯了錯誤。 在C中採用一個真正可識別的例子：

int a[10];
for (int idx = 0; idx < 15; idx++) a[idx] = 10;

咱們都知道會發生什麼。 然而，咱們可能有些人沒有意識到的是......功能可能很是有益。 取決於你在作什麼。 緩衝區溢出是該功能的成本。 上面的代碼。 若是我真的把它發佈給公衆。 那又是..跟我說吧......「個人錯」。 不是C容許我這樣作。

2-咱們不該該把它放在回收站裏嗎？

很容易指出咱們不理解的語言中的某個功能，由於咱們不常用它並稱之爲愚蠢。 抱怨它就在那裏等。後藤老是在招待我。 人們老是抱怨goto是一種語言。 但我打賭你的最後一個節目包括一種goto。 若是你曾經使用過休息或繼續，你已經使用了goto。 就是這樣。 固然，這是一個「安全」的轉到，但它就是它。 Goto有它們的用途。 是否使用「隱式」getos，如continue或break，或使用顯式gotos（對於任何語言使用實際關鍵字「goto」）。 並不是語言開發人員天衣無縫，但一般......若是功能自時間開始就存在（對於那種語言）。 可能這方面是該語言的定義質量。 意思是......因爲向後兼容性，它正在被使用而且可能不會被閒置。 它今天正在使用。 和5分鐘前同樣。 而且使用得當。 嗯..能夠說有人也使用它不正確，但這與我名單上的＃3有關。

1. - 一切都是對象。

好吧..這個真的是＃2的一個子集。 但這是迄今爲止我在仇恨列表中看到的最煩人的抱怨。 並不是一切都是對象。 有不少不屬於或不須要成爲對象的概念。 把東西放在他們不屬於的地方只是醜陋並且會下降程序的效率。 固然。 也許並很少，取決於語言。 這也與＃5有關。 這意味着......是的。 全球還能夠。 與靜態方法相關的函數是能夠的。 將OO編程與全局函數相結合是能夠的。 如今......這並不意味着咱們都應該走出去，並從它的對象模型中「釋放」咱們的代碼。 在設計一段代碼或整個項目時，在將它們組合在一塊兒時應考慮幕後發生的事情。 不只在這個概念存在的地方還有許多其餘因素。 爲何將全局函數包裝在類或名稱空間概念中，若是它沒有用處？ 獲取靜態成員變量。 這很是讓我感到高興，由於......好吧......固然，取決於語言和實施，但總的來講，你剛剛宣佈全球化。 是的，有一些理由將這些非OO概念包裝在OO包裝器中。 其中一個固然是自我記錄代碼。 這是有道理的。 因此......就像我說的那樣。 不要出去「免費」你的代碼。 可是，任何優秀的現代語言都將在其OO建模以外具備全局概念。 是的，我特別指出，沒有全局概念的OO編程語言極可能存在嚴重的設計缺陷。 雖然..再次取決於語言的意圖和設計，因此我不是試圖挑選任何特定的語言，並且這裏有太多的東西要分析。 Anywho，考慮代碼應該存在的位置而且是最有效的。 將一堆閃光添加到不添加功能或支持的東西只會更快地磨損鍵盤。 它沒有任何好處。 嗯..除非你喜歡那些可能錯誤地教你一切都是對象的人的布朗尼點。

簡而言之，編程不只僅是盲目地敲擊鍵盤。 任何項目都有不少設計考慮因素。 我知道這是陳詞濫調，但你必須從各個角度來看待它。 即便是如今的類型安全語言。 你不只要刪除代碼並指望它可以正常工做。 固然..它可能有用，但它可能不是正確的方法。 總的來講，選擇最適合特定工做和環境的語言和格式。 但沒有一種語言可以消除它背後的思想。 若是你不在想......你只是在打字。

---

#2樓

C＃/ .NET：

• 默認狀況下應該密封類
• 應該沒有lock語句 - 相反，你應該有特定的鎖定對象，而且應該有諸如Acquire方法返回一次性鎖定令牌。 推論：每一個對象都不該該有監視器。
• GetHashCode()和Equals()不該該在System.Object - 並不是全部東西都適合散列。 相反，讓IdentityComparer執行相同的操做，並保留IComparer<T> ， IComparable<T> ， IEqualityComparer<T>和IEquatable<T>接口以進行自定義比較。
• 對不變性的支持不足
• 發現擴展方法的方法不好 - 它應該是一個更有意識的決定，而不只僅是我使用命名空間的事實。

這些都是個人頭腦 - 明天問我，我會想出一個不一樣的5 :)

---

#3樓

C ++

1. 模板語法
2. 鑽石繼承問題
3. 現代語言所擁有的過多/缺少標準庫（雖然提高很接近）。
4. 輸入輸出流
5. IOStreams周圍使用的語法

蟒蛇

1. 空間是有意義的（有時）
2. 強調關鍵字
3. 有限的線程支持（至少目前）
4. 「自我」而不是「這個」
5. 空間是有意義的（有時）

---

#4樓

C

• 字符串操做。

必須手動處理字符串緩衝區是一個容易出錯的痛苦。 因爲如此多的計算實際上正在移動和修改字符串（計算機並無像人們認爲的那樣在大數字運算時使用得那麼多），可以使用託管語言或C ++的字符串真的很棒對象來處理這些。 當我必須在直線C中進行時，感受就像在流沙中游泳同樣。

---

#5樓

如下是一些我不喜歡Java的東西（這不是我最喜歡的語言）：

• 泛型類型擦除（即沒有具體化的泛型）
• 沒法在單個catch塊中捕獲多個異常（不一樣類型）
• 缺乏析構函數（finalize（）是一個很是糟糕的替代品）
• 不支持閉包或將函數做爲數據處理（匿名內部類是很是冗長的替代）
• 通常檢查異常，或者更具體地說，檢查不可恢復的異常（例如SQLException）
• 對文字集合沒有語言級支持
• 調用泛型類的構造函數時沒有類型推斷，即類型參數必須在'='的兩側重複