scalapython開發效率

① ...選擇scala還是python作為主要編程語言比較好

我個人認為scala是比較優秀的函數語言,但是學這個你還是要懂javapython是老牌腳本語言D語言不值得學scheme不如學common lisp

② 誰能說說 scala 和 python 的區別，有木有必要學習 scala

學 Scala 可以發現更大的世界，之後會感覺其他語言的特性都不會太陌生，感覺尤其是函數式編程和類型系統。
不過身邊會 Scala 的都是搞 spark 的，或者曾經搞過 spark 的。
如果 Scala 都精通了，學 Python 也就是看下語法熟練下的事。
Scala 與函數式編程是信仰，如果面試遇到信仰相同的面試官可能有加分。

③ Scala 是一門怎樣的語言，具有哪些優缺點

以前在這個版塊也答過關於Scala的問題，但那更多的是知識普及，而沒有談Scala是什麼，做什麼，以及有怎樣的特點。

Scala可怕的地方在於人人都能對它說上一二，但是不一定每個人都能明白。查看這個版塊的帖子，有人把它當做Java的延伸版（一個UPenn賓大的學生Justin Kim ——此人目前在沃頓混得風生水起，當著我的面說Scala是在JVM上的腳本語言），有人把它當做JVM上的C++，有人覺得這是面對對象語言和函數語言的簡單混合，有人覺得這就是Haskell，而且也還不如Haskell強。對Scala的偏見（或者是錯誤的見地）達到了很高的地步，Martin Odersky馬丁·奧德斯基（Scala的發明者，EPFL教授）在今年夏天的Scala Day舊金山大會上發出了這張著名的玩笑照片：
gt;

這個圖片上的翻譯是：「Scala唯一的作用是將人引向Haskell」（原諒我沒法完全直譯）。馬丁·奧德斯基以此作為一個笑話，說他該把Scala改一下名字，叫做Hascalator，還請人設計了一個Logo。

不同的語言有不同的特點，同時也帶來不同的優勢。如果不能理解Scala的特點，就不可能知道如何運用Scala，以及發揮其最大的優勢。一些語言有很顯而易見的優勢，也很容易理解，比如Python，Python的哲學（Zen of Python PEP 20 -- The Zen of Python），我很早的時候曾經覺得有道理，尤其是One way to do it（一種方法做一件事情），理由是對任何任務，雖然可以採用很多方法，但總有最好的一種方法，通過在語言或者哲學層面這樣定義後，能簡化程序員的任務，從而達到提高效率的方法。但經過一段時間的思考後，我突然發現Python其實並不是「一種方法做一件事」的哲學，而是「一種方法做一百萬件事情」的哲學：極其有限的數據結構（只有四個: List, Tuple, Dictionary, Sets），以及不能查看時間復雜度的訪問方法，比如鼓勵人們使用for x in list。

這種處理方式能達到Python最初的打算：發明一種每個人都能使用的簡易語言，但是對於追求速度和效率的程序員而言，這幾乎是略帶噩夢性質的。當然，這不是說Python很慢，通過各種優化（比如NumPy/SciPy中的），以及Cython這樣的將Python直接翻譯為C/C++語言又重新通過C_Mole方式讀回Python環境的編譯器，性能可以得到不少提升，但是仍舊，Python並不追求快。

再舉一個語言的例子：Java。Java的特性或者優勢何在？Java的第一個優勢在於它是第一個系統提供模塊化（mole）設計的語言（在此之前有Smalltalk存在，該貨是OOP的鼻祖）。在Java之前，炒程序員魷魚是很困難的事情，那些C/C++程序員，以及而且尤其是那些Lisp程序員，一旦炒掉他們，新來的人沒有十天半個月，甚至半年，是不可能搞懂前任人士的代碼的。每個人的代碼有自己的邏輯，自己的思路，寫上個數萬行任誰來看都頭疼。這也是為什麼Paul Graham保羅·格雷厄姆（寫了《黑客與畫家》）講他給雅虎做了一個用Lisp寫成的在線商店的案例，在他離開後，雅虎根本沒法維護他寫的代碼，因為數萬行Lisp沒人能弄得很清楚。

Java的模塊化，給企業、大公司帶來了第一道曙光，模塊化之後，這些公司不再給程序員一整個任務，而是一大塊任務的一小塊。介面一定義，虛擬類一定義，換誰上都可以，管你是保羅·格雷厄姆這樣的明星程序員，還是一個新來的大學生，程序員不聽話就直接開除，反正模塊化之後，開除程序員的成本大大降低，這也是為什麼谷歌、甲骨文（這貨最後收購了Java）一類的公司大規模的推崇Java，還一度提出了模塊化人事管理的理念（把人當模塊化的積木一樣隨時移進移出）。

過度企業化後，這延展出了Java的第二個特性，束縛手腳。保羅·格雷厄姆在《黑客與畫家》中寫道，Java屬於B&D（捆綁與束縛）類型的語言。為何束縛手腳？因為要讓新手和明星程序員寫出類似質量的代碼，盡可能的抹消人的才華對程序的影響。不同於C/C++，老手和新手寫出的Java代碼不會有上百倍的耗時差距。但同樣也導致了Java的一個弱點——不容易優化。很多優化Java代碼的程序員必須要對JVM（虛擬機）進行優化，實際上增大了很多任務難度。

通過Python和Java這兩個語言的優缺點，返回來看Scala，就能瞬間明白Scala的定位了。

首先，Scala不把程序員當傻子。當馬丁·奧德斯基宣布Scala 2.12將要簡化語法，推出Scala "Don Giovanni"項目的時候，在視頻中說的很清楚：「Scala現在是為聰明人創造的，以後也是為聰明人服務的。」所以不同於Python讓程序員用一種方法做所有事情，Scala提供一整套工具，讓程序員自由選擇，無論是mutable數據結構，immutable數據結構，並行（parallel）數據結構。然後在這些選擇中，Scala再針對他們進行演算法層面的特殊優化。Scala相信程序員的聰明才智，讓程序員自行選擇合適的結構，以針對變化萬千的任務需求，這點是Scala做得極好的地方。

再者，有人會說immutable數據結構佔用內存，或者速度很慢。這是真的，但這不是Scala的錯，而是這些結構就是這樣定義的。這里講的是Scala集合的運行速度，是一個來自Goldman Sachs的程序員講他們為Java寫的集合庫（GSCollection）速度和內存消耗，但同時比較了gs-collection（goldmansachs/gs-collections · GitHub），Java，和Scala庫的速度。最後Scala的可變集合mutable原生庫完爆Java，和gs-collection基本持平。

Scala的第二個優勢，相較於Java而言，則是相信程序員的優化能力。在Scala with Style講話中（），馬丁·奧德斯基說：「很多程序員會告訴我，他們一般會重構他們的Scala代碼兩三次，甚至三四次。」這聽起來似乎非常的沒有效率，但Scala就是這樣的語言，每一次重構，代碼的性能或者是可讀性都會有極高的提升。

之前就有人提到過，Scala新手和老手寫出來的代碼完全會呈現兩種不同的風格，甚至新人根本不能讀懂有經驗的Scala程序員所寫的代碼，有人於是戲稱：「太好了，這樣的話我們部門的實習生就不能亂碰我寫的代碼啦！」但其實不僅風格不同，執行效率差距也一定是巨大的。Scala提供一整套工具，但是要明白什麼時候用拿一種工具，哪些演算法能夠隨意調用，哪些演算法不能，這一定要依靠經驗、研究和學習以及對源代碼的理解才能得知。最簡單的例子，Scala的foreach()方法是高度優化過了的（尤其針對Range結構和Vector結構），但是fold()就不一定了。或者當受到誘惑想用zipWithIndex()的時候，一定要明白這是兩次循環，最好改用Vector(...).indices.foreach()的方法，或者用.view來推遲執行。

像這樣的地方還有很多。所以在這個層面上來講，簡直和C++非常的相似。從另外一個層面來講，不僅僅是要理解語言層面的優化，Scala作為一個社區而言，是非常追求運行速度的。Ruby社區就完全不同了，Ruby曾經是推特的主要語言。推特的團隊找到了Ruby團隊，說，你們能不能讓Ruby運行的快一點，我們有這個這個和這個建議。Ruby直接把這些建議拒絕了，因為它們會增加語言復雜度，讓Ruby不能繼續做一個「fun」（好玩）的語言。而Python直接就立志做一個「Simple」（簡單）的語言了。於是推特只好將後台換做Scala和Java的結合。有一位在推特工作的知乎友人在我的一個回答下留言說推特換用Scala後，TypeSafe（Scala的母公司）還送去了一個蛋糕。

為了追求速度，Scala社區是絕對不會管所謂的「簡單」或者是「好玩」，怎樣有效率就怎樣弄。與其專注於JVM的改進，Scala社區大部分在編譯器上下功夫，比如很著名的Miniboxing（Miniboxing），這是一個編譯器增進器。Miniboxing做的是什麼呢？只做一件事：防止auto-boxing和auto-unboxing。所有的泛型，尤其是原生類泛型（Primitive Types），諸如Int、Double等等，在進行各種操作的時候會自動取出和裝回它們所屬的類中去——這個我解釋的不太好，但是可以看這里（Java 自動裝箱與拆箱(Autoboxing and unboxing)）。

Miniboxing這樣的插件可以讓所有的原生類泛型再也不用自動裝拆箱，從而將Scala的運行速度提升1.5倍到22倍（）。當然這樣的東西可不是白來的，這是馬丁·奧德斯基的PhD博士學生做的一個研究項目，然後為OOPSLA寫了一篇論文（），所以怪不得這玩意Scala可以有，但其他語言想要有都沒有。

另一個Scala的很大優勢就是所謂的Macro——宏。宏本身作為元編程而言，其實和運行速度是沒有什麼太大關系的，反而，因為對反射（Reflect）的利用，可能會影響到速度。但Scala社區對宏的理解顯然和最初的設計理念有偏差。因為Scala本身是沒有傳統意義的循環的（for-loop），所以很多時候循環必須利用while或者foreach。但是部分追求效率的Scala程序員們利用宏為Scala寫了一個傳統循環，叫做cfor，被收錄在Spire（non/spire · GitHub）數學計算庫中。cfor的寫法如下：

import spire.syntax.cfor._// print numbers 1 through 10cfor(0)(_ < 10, _ + 1) { i =>
println(i)}

而這玩意運行效率如何呢？文章中做了一次測評，將cfor和zip寫的一個演算法作比較——在公布結果之前，我想說的是，zip並不是一個高度優化的方法，所以本身就慢很多，cfor用了26.1毫秒運行，zip方法用了7.4 秒運行，這幾乎是284倍的速度差距。

通過這兩點，Scala的一個優勢就很明顯了——多樣化。當需要寫簡單的代碼，像Python一樣當腳本語言使用時，Scala提供大量的原生方法和數據結構，可以很輕松的寫出比較復雜的操作。但當需要速度的時候，又可以通過重構來獲取數十倍或者上百倍的速度提升。通過Miniboxing一類的編譯器增強器，Scala在某些操作的速度是必定超過Java的。

Scala的第二個優勢就是——一幫勤勞勇敢的PhD博士生。二十一世紀的程序語言和二十世紀的程序語言已經不能比擬了。那個年代的普通人（甚至是學生）還能任意發明一下語言，稍微把編譯器優化幾次就能上得了廳堂（比如那一大堆Lisp方言），到了這個年代，編譯技術已經達到了很復雜的程度（虛擬機技術也是如此），優化和語義理解，程序語言的定義與延展，再也不是隨便任何人都能搞定的工作了。作為編程語言方面的教授，馬丁·奧德斯基不斷的將最前沿的學術界成果轉移到Scala這個語言中，還讓他的博士學生發展出新的，讓語言運行得更快的方法，這些都是其他語言，尤其是Python、Ruby、甚至是Go都沒有的優勢。

當然，說了這么多，總會有人說了，Scala如果像C++一樣難，又追求速度的話，為什麼不直接去學C++，原因很簡單——現在有很多在JVM上面寫成的軟體啊！大家又不是Haskell程序員，壓根不打算一切自己寫吶。

④ scala相對於python有何優缺點

學 Scala 可以發現更大的世界，之後會感覺其他語言的特性都不會太陌生，感覺尤其是函數式編程和類型系統。
不過身邊會 Scala 的都是搞 spark 的，或者曾經搞過 spark 的。
如果 Scala 都精通了，學 Python 也就是看下語法熟練下的事。
Scala 與函數式編程是信仰，如果面試遇到信仰相同的面試官可能有加分。

⑤ Spark 中用 Scala 和 java 開發有什麼區別

Scala相對於Java的優勢是巨大的。熟悉Scala之後再看Java代碼，有種讀匯編的感覺…… 如果僅僅是寫Spark應用，並非一定要學Scala，可以直接用Spark的Java API或Python API。但因為語言上的差異，用Java開發Spark應用要羅嗦許多。好在帶lambda的Java 8出來之後有所改善。 在Spark應用開發上，學Scala主要好處有二： 開發效率更高，代碼更精簡； 使用Spark過程中出現異常情況，在排查時如果對Spark源碼比較熟悉，可以事半功倍

⑥ 我是數學專業想要做數據這塊，是學大數據好還是python好

本人只能從個人經驗給你一點建議，希望你少走一點彎路。
首先，你說到你剛接觸大數據，你要明白大數據范圍超級廣，你具體想要學習哪個方向呢？數據挖掘？還是機器學習深度學習？亦或nlp（自然語言處理）？
我給所有問我大數據該怎麼入門的人都會有如下建議：學好數學！學好數學！學好數學！重要的事說三遍，不然你怎麼理解各種模型的構建？所以從理解演算法開始，什麼svn啦，knn啦，k means啦，總之各種聚類分類的演算法，把它搞懂，絕對有用。
言歸正傳，回到語言的選擇問題。java和python這兩個語言，我給你從這幾個方面解釋一下：
1. python是腳本語言，無需編譯，java則是需要編譯的語言
2. 我在letitcode（大概是這么拼）上測試過好多次，同一個功能的程序竟然是java性能好很多
3. 平時我們做項目，都是用python寫個demo去測試，真正發行的版本，是用java寫的
4. 許多大數據平台（如spark），都提供多種語言的介面，所以你不用擔心學一種語言沒處用的問題
看到了吧？python和java的地位差別在企業中就是一個低一個高，氮素！以我個人的觀點來看，我還是建議你先學python。
為啥膩？我可不是要坑你，而是因為：
1. 很多java中幾行的代碼，python中一行就搞定，學會了python，還怕學不會java？
2. python上手快，簡潔事兒少
3. （個人經驗）我學數據挖掘入門是用的scikit-learn（一個python庫），當時用的超爽的好吧！幾分鍾搞個模型出來。當然現在看來那不算什麼啦，可當時真的體驗很好，特有成就感。相反拿java寫程序我就各種別扭，總覺得啰嗦得很
4. 其實，我覺得scala更適合大數據…linkedin後台好像就是它寫的，但是我覺得scala難，再加上種種原因，一直沒來得及學
以上就是我的看法。
最後給你推薦個小工具：jupyter notebook，一個在線互動式編譯器，不但支持python在線編譯，還支持matplotlib及各種繪圖庫哦！在你前期做數據清洗和特徵提取的時候很有用。

⑦ R，Python，Scala 和 Java，到底該使用哪一種大數據編程語言

如果你對晦澀的統計運算進行繁重的數據分析工作，那麼你不青睞R才怪。如果你跨GPU進行NLP或密集的神經網路處理，那麼Python是很好的選擇。如果想要一種加固的、面向生產環境的數據流解決方案，又擁有所有重要的操作工具，Java或Scala絕對是出色的選擇。
有一個大數據項目，你知道問題領域(problem domain)，也知道使用什麼基礎設施，甚至可能已決定使用哪種框架來處理所有這些數據，但是有一個決定遲遲未能做出：我該選擇哪種語言?(或者可能更有針對性的問題是，我該迫使我的所有開發人員和數據科學家非要用哪種語言?)這個問題不會推遲太久，遲早要定奪。
當然，沒有什麼阻止得了你使用其他機制(比如XSLT轉換)來處理大數據工作。但通常來說，如今大數據方面有三種語言可以選擇：R、Python和Scala，外加一直以來屹立於企業界的Java。那麼，你該選擇哪種語言?為何要選擇它，或者說何時選擇它?
下面簡要介紹了每種語言，幫助你做出合理的決定。
R
R經常被稱為是「統計人員為統計人員開發的一種語言」。如果你需要深奧的統計模型用於計算，可能會在CRAN上找到它――你知道，CRAN叫綜合R檔案網路(Comprehensive R Archive Network)並非無緣無故。說到用於分析和標繪，沒有什麼比得過ggplot2。而如果你想利用比你機器提供的功能還強大的功能，那可以使用SparkR綁定，在R上運行Spark。
然而，如果你不是數據科學家，之前也沒有用過Matlab、SAS或OCTAVE，可能需要一番調整，才能使用R來高效地處理。雖然R很適合分析數據，但是就一般用途而言不太擅長。你可以用R構建模型，但是你需要考慮將模型轉換成Scala或Python，才能用於生產環境，你不太可能使用這種語言編寫一種集群控制系統(運氣好的話，你可以對它進行調試)。
Python
如果你的數據科學家不使用R，他們可能就會徹底了解Python。十多年來，Python在學術界當中一直很流行，尤其是在自然語言處理(NLP)等領域。因而，如果你有一個需要NLP處理的項目，就會面臨數量多得讓人眼花繚亂的選擇，包括經典的NTLK、使用GenSim的主題建模，或者超快、准確的spaCy。同樣，說到神經網路，Python同樣游刃有餘，有Theano和Tensorflow;隨後還有面向機器學習的scikit-learn，以及面向數據分析的NumPy和Pandas。
還有Juypter/iPython――這種基於Web的筆記本伺服器框架讓你可以使用一種可共享的日誌格式，將代碼、圖形以及幾乎任何對象混合起來。這一直是Python的殺手級功能之一，不過這年頭，這個概念證明大有用途，以至於出現在了奉行讀取-讀取-輸出-循環(REPL)概念的幾乎所有語言上，包括Scala和R。
Python往往在大數據處理框架中得到支持，但與此同時，它往往又不是「一等公民」。比如說，Spark中的新功能幾乎總是出現在Scala/Java綁定的首位，可能需要用PySpark編寫面向那些更新版的幾個次要版本(對Spark Streaming/MLLib方面的開發工具而言尤為如此)。
與R相反，Python是一種傳統的面向對象語言，所以大多數開發人員用起來會相當得心應手，而初次接觸R或Scala會讓人心生畏懼。一個小問題就是你的代碼中需要留出正確的空白處。這將人員分成兩大陣營，一派覺得「這非常有助於確保可讀性」，另一派則認為，2016年，我們應該不需要就因為一行代碼有個字元不在適當的位置，就要迫使解釋器讓程序運行起來。
Scala
現在說說Scala：在本文介紹的四種語言中，Scala是最輕松的語言，因為大家都欣賞其類型系統。Scala在JVM上運行，基本上成功地結合了函數範式和面向對象範式，目前它在金融界和需要處理海量數據的公司企業中取得了巨大進展，常常採用一種大規模分布式方式來處理(比如Twitter和LinkedIn)。它還是驅動Spark和Kafka的一種語言。
由於Scala在JVM裡面運行，它可以立即隨意訪問Java生態系統，不過它也有一系列廣泛的「原生」庫，用於處理大規模數據(尤其是Twitter的Algebird和Summingbird)。它還包括一個使用非常方便的REPL，用於互動式開發和分析，就像使用Python和R那樣。
我個人非常喜歡Scala，因為它包括許多實用的編程功能，比如模式匹配，而且被認為比標準的Java簡潔得多。然而，用Scala來開發不止一種方法，這種語言將此作為一項特色來宣傳。這是好事!不過考慮到它擁有圖靈完備(Turing-complete)的類型系統和各種彎彎曲曲的運算符(「/:」代表foldLeft，「:\」代表foldRight)，很容易打開Scala文件，以為你看到的是某段討厭的Perl代碼。這就需要在編寫Scala時遵循一套好的實踐和准則(Databricks的就很合理)。
另一個缺點是，Scala編譯器運行起來有點慢，以至於讓人想起以前「編譯!」的日子。不過，它有REPL、支持大數據，還有採用Jupyter和Zeppelin這一形式的基於Web的筆記本框架，所以我覺得它的許多小問題還是情有可原。
Java
最終，總是少不了Java――這種語言沒人愛，被遺棄，歸一家只有通過起訴谷歌才有錢可賺時才似乎關心它的公司(註：Oracle)所有，完全不時髦。只有企業界的無人機才使用Java!不過，Java可能很適合你的大數據項目。想一想Hadoop MapRece，它用Java編寫。HDFS呢?也用Java來編寫。連Storm、Kafka和Spark都可以在JVM上運行(使用Clojure和Scala)，這意味著Java是這些項目中的「一等公民」。另外還有像Google Cloud Dataflow(現在是Apache Beam)這些新技術，直到最近它們還只支持Java。
Java也許不是搖滾明星般備受喜愛的首選語言。但是由於研發人員在竭力理清Node.js應用程序中的一套回調，使用Java讓你可以訪問一個龐大的生態系統(包括分析器、調試器、監控工具以及確保企業安全和互操作性的庫)，以及除此之外的更多內容，大多數內容在過去二十年已久經考驗(很遺憾，Java今年迎來21歲，我們都老矣)。
炮轟Java的一個主要理由是，非常繁瑣冗長，而且缺少互動式開發所需的REPL(R、Python和Scala都有)。我見過10行基於Scala的Spark代碼迅速變成用Java編寫的變態的200行代碼，還有龐大的類型語句，它們占據了屏幕的大部分空間。然而，Java 8中新的Lambda支持功能對於改善這種情況大有幫助。Java從來不會像Scala那麼緊湊，但是Java 8確確實實使得用Java進行開發不那麼痛苦。
至於REPL?好吧，目前還沒有。明年推出的Java 9會包括JShell，有望滿足你的所有REPL要求。

⑧ R，Python，Scala和Java，到底該使用哪一種大數據編程語言

哪一種都行，Python適用於腳本，網路和爬蟲，Java適用網路，商業和游戲，r適用於腳本和網路

⑨ scala python哪個用來開發spark更好

你好。

bg4.png spark的開發語言來scalar，因此會scalar是最好的，

至於 java，python則是為了兼容性，有相關介面，但是資料相對較少一些

如果還有問題，可以繼續追問，感謝。

⑩ scala , python哪個用來開發spark更好

bg4.png spark的開發語言來scalar，因此會scalar是最好的，至於 java，python則是為了兼容性，有相關介面，但是資料相對較少一些。 查看更多答案>>

麻煩採納，謝謝!