在一個項目中使用不同的語言

Question

我最近聽說在一個（大）項目中使用了幾種不同的語言，我還閱讀了一些着名的服務，例如使用Rails作爲前端的Twitter，與其他一些語言混合使用，以及Scala我認爲它是後端。

• 這是常見的做法嗎？誰做的？

• 我敢肯定，這有缺點。我認爲你會對不同的解釋器/編譯器產生問題，並且無縫地連接不同的語言。這是真的？

• 這實際上是爲什麼？爲了表現？

Answer 1

我相信，在Twitter的情況下，它是性能相關; Scala比Ruby更快，他們使用它來爲隊列系統提供動力。

除了維護問題，一起使用多種語言可以幫助彌補每種語言的缺點。通過Twitter，Ruby（on Rails）非常適合運行他們網站的前端，但使用更快的語言處理惡劣的後臺任務更有意義。在排隊系統時，語言之間的集成並不困難，因爲它們可以完全獨立於應用程序本身，並仍能正確執行其任務。

Answer 2

這個問題基本上歸結爲域特定語言（DSL）。有時候一種語言更適合於程序的一部分，另一種語言適合於另一種程序。好處（執行速度或易於開發）常常超過混合多種語言的缺點。

• 這是常見的做法嗎？誰做的？

很常見;我會說幾乎每個大型應用程序都是用多種語言編寫的。

考慮一個遊戲的例子。核心引擎通常使用C或C++語言編寫，以實現速度和低級別硬件訪問，但對象和字符的行爲以Lua等更高級語言編寫。

• 我相信這樣做有缺點。我認爲你會對不同的解釋器/編譯器產生問題，並且無縫地連接不同的語言。這是真的？

是的，有一定量的開銷使腳本能夠訪問遊戲對象等。

• 爲什麼實際上這樣做？爲了表現？

是的，沒有。如果性能不是問題，整個遊戲可以用腳本語言編寫。其他一些原因是：

• 發展速度;想象一下，如果像魔獸世界這樣的遊戲中的所有小物件和角色都是用C++編寫的話，那麼就可以開銷了。該程序必須進行編譯並重新啓動，以便進行每次小改動。

• 模塊性;新的對象可以在運行時輕鬆下載和添加/刪除，精明的用戶甚至可以對它們進行修改。

• 便攜性;相同的腳本將在不同的平臺上運行。

Answer 3

我有混合語言

在一種情況下，我已經用C＃，因爲F＃允許我代碼中的問題容易多了（是一個挑戰），一些F＃混合

其他情況下，一些項目會混合silverlight和.net在同一個項目 - 他們使用不同的CLR

在其他情況下，我有vb.net和c＃當公司有程序員使用多種語言 - 我工作的大多數人不能閱讀c ..任何代碼都可能不是我ñ僱主的最大利益。

主要的缺點是每個工作在代碼上的人都需要知道所有的語言。

這不是我經常做的事情，而是真正的關於工作的工具。

我不願意這樣做是爲了表現通常......雖然我已經鏈接到C++ dll的時候，我需要做的事情非常快速（圖形算法，我可以做任何cuda之前）......決定周圍的表現大於計算時間。他平時的開銷像sdcalability，易於閱讀仍然進入它。 即我想你可以說，它的有關性能，只要你不限制性能意味着速度O fthe程序的執行

Answer 4

在一個典型的嵌入式應用程序，我寫的8051，我已經涉及多國語言：

• C - 應用程序的大部分是C語言，因爲它的寫入速度要快得多，但它很容易生成適合64k（或更少）代碼空間的緊密代碼。
• 彙編語言 - 有時你不能通過編譯器生成的代碼。每個字節計數時，彙編語言規則。
• Perl - 我的幾個構建工具都是用Perl編寫的。像Perl這樣強大靈活的動態語言可以輕鬆處理ROM映像，並處理構建過程的許多方面。
• GNU make - 嗯？是的，make是一種語言。它是一種聲明性語言（這是與「面向對象」，「功能性」和「勢在必行」相同的另一類語言）。 Make是我構建系統的基礎。

我這樣做是因爲我喜歡爲每項工作使用正確的工具。我必須使用C和彙編器來處理微小的8位微。我儘可能多地使用C，因爲我完成了更多的工作。我使用Perl來處理複雜的與構建相關的任務，因爲它比C更高效，比bash更強大，更便攜。我使用GNU make作爲構建的基礎，因爲它非常適合處理依賴關係，並且可以很容易地創建和維護這個元數據並將其應用到我的項目構建過程 - 換句話說就是生產力。

這種方法最大的缺點是顯而易見的：理解我的應用需要工程師理解C，彙編語言，Perl和make。

Answer 5

很多的項目是混合語言。最常見的混合語言之一是SQL，它顯示了混合語言項目的一個關鍵特徵：每種語言都側重於它擅長的部分問題，並彌補其他問題的弱點（ S）。在SQL的情況下，它處理關係數據庫訪問，將其他事物（無論是GUI還是Web服務或......）留給其他更擅長的語言。我甚至會說使用單一語言就像用錘子做房子一樣;是的，你需要一把錘子，但你也需要一堆其他工具。

我知道在一個項目中混合使用jQuery，Tcl，C，Fortran和SQL的項目。 （這是一個Web應用程序，通過Tcl編寫的web服務器驅動，在C和Fortran，並通過SQL訪問的數據庫的計算組件）。

Answer 6

考慮平均web項目，它多少種語言包括：

HTML，CSS，JavaScript/JQuery，Java，SQL/HSQL。

當每一種語言是遠遠更適合比你已經在使用語言的域名，拋在另一種語言。

我也有與web前端數據重程序結束用Java編寫的，而是用C編寫的託管在不同服務器上的後端（用於實際處理數字）等等。我不得不說，不要模仿Twitter的模式。你不可能有這樣的想法，即大量人需要這麼多，沒有建立在盈利能力之上，投資者爲了錢而洗錢。他們在場地的合身和完成方面也非常糟糕;如果你曾經使用過Gmail密碼，那麼它很可能是以明文形式傳輸的，並且至少兩年後，你可以通過短信界面在沒有他們許可的情況下與朋友通話。 （Gah。）

Answer 7

這是常見的做法嗎？爲什麼這個實際上完成了？爲了表現？

是。做這件事的人通常試圖重複使用現有的軟件（你會注意到它是用多種語言編寫的），或者試圖使用幾種不同的語言，每種語言都有其優點。

表現有時可能是相關的;例如，我可能希望使用Lua其快速原型的能力，但它連接到用C編寫的

一套高性能的電子郵件分析器我認爲你將有不同的解釋/編譯器和連接無縫的問題不同的語言。這是真的？

有時。多語言實踐的狀態大致上是，如果一種語言與其他任何事物都不會談話，它就會與C通話。所以通常可以通過某種類似C的界面來協同工作。

否則，第一個問題通常在內存管理或VM層中出現，我們可能會考慮「託管代碼」的示例。例如，讓一個Haskell程序很難與JVM交換堆分配的對象。一個典型的解決方法是像遠程過程調用一樣處理這些類型的調用，就好像程序運行在不同的進程或甚至不同的機器上一樣。這樣的調用可能涉及大量開銷，例如，通常使得兩種不同語言共享可變對象的開銷過於昂貴。但是，如果你不需要改變事物，管理費用就不會那麼糟糕。

摘要：有使用不同的語言來解決不同的問題有充分的理由，如果一個大型軟件系統沒有不使用多國語言（可能除了在單一語言孤島狀佳樂的Smalltalk這將是令人驚訝的，這根本不會與世界其他地方交談）。互操作性確實存在困難，但問題在於舊的問題，並且已知解決方法。