Scala knowledge - Existential types

前言

Scala 的Type parameter 是一個強大的特性, 實現許多抽象化資料結構, 但Scala run 在jvm上, 仍是受到type erase限制, 因此在Type parameter中需要再處理抽象化type時候, Existential types 是一個很好詮釋Abstract data type的方式

JAVA knowledge wild-card VS generic methods

Java 泛型提供了polymorphism更多應用, 不過實作上有wild-card ? 跟 type parameter <T> 可應用, 這兩者看起來很類似但實際上又有些應用上的不同

Scala knowledge - Nest class and # operator

不算前言
Nest class 在JAVA中是很常見的語法, 比如要嵌入實作某些Listener interface, 在JVM上的Scala 也是有Inner class應用方式, 只是當你在外部Call inner class的時候, 會很不一樣...

Scala Duck typing - Structural type

不算前言
Duck typing在Dynamic Language很常見到, 儘管Scala是在JVM上運行的靜態語言, 但透過強大的Compiler 實現Duck typing, 也拜靜態語言之福, 還能保有Type safe的特色, 只是自然也有些限制...

Scala package object

不算前言

一般來說再package層級只能放class, object, trait 這些標準的定義, 可是當你有一些更小層級ex method, type, val 等等, 要放到package層級讓大家都可以使用時候, 是無法獨立一個檔案出來放, 這時候就需要scala 2.8 feature － package object

Scala knowledge - Lifting

不算前言
Lifting 追根朔源我是找到Haskell lifting, 應該是functional 概念衍伸出來的意義, 因為 Scala 集合了OOP + Functional 概念, 所以Scala Lifting又有其自己的意義 

Scala knowledge - Eta-expansion

不算前言
Scala 相較於Java多了hight-order function的能力, 就好比把function 當作參數傳到其他method, 但Scala終究還是run在jvm, 那麼就是eta-expansion 黑魔法

OOP in Scala 2, Packaging & Import

前言
物件導向的世界中, 需要有個方法來幫物件做分類管理, 區分功能性並建立架構, package 的概念很熟悉, 它也正是一個物件, 是用來定義複數物件的集合, JAVA的package很基本, 但缺乏彈性, 已知道的比如C#就有scope的package架構, 在Scala中更是講這兩者結合, 端看軟體需求, 讓使用者更方便建立物件

OOP in Scala 1, Classes and constructors

前言

Class 在OOP裡面是Encapsulation最基本的原件, 也就是物件, 在Scala世界中既保有JAVA物件模型, 又更進階的加上了Mutable & Immutable 概念, 更甚者還有Function 物件來當朋友, 在與Functional演化與變異過程中, 要如何保有原先物件的優點, 這種DNA的 Design是你該好好觀察的

Scala basic5, Pattern matching

前言

程式邏輯的控制流程, 大部分都是從if else 起手, 可是當遇到複雜的資料結構要分析, 用底層的簡單判斷式就有點捉襟見肘, 複雜的流程設計可以透過switch來建置, 而Pattern match又更上一層樓的可以處理各種使用者自定義的資料結構, 實際上這也是來自於Functional programming的設計

來看看有哪些新創公司在用Scala

儘管在台灣Scala很少聽到, 也沒有太多資源, 但事實上, 在美國已經有不少知名的新創公司, 是以Scala為base, 開發出許多人在應用的服務,

最著名的就是Twitter(可以參考這一篇), Twitter 一開始是以Ruby on Rails 為起家, 但隨著他的服務規模不斷長大, 為了提升整個System的擴充性, 還要良好的Performance, 融合OOP & FP的Scala自然是首選, Scala又完善的整合Akka 來實現高階平行處理, 最後JVM上的實作能良好的善用JAVA 的所有Library , 功能性之外, 對於在Twitter中的Ruby on Rails 工程師來說, Is it fun? 是他們所care的, 而Scala 的Sugar syntax也能讓你的code很精簡, 很酷炫, 因此Twitter用Scala rebuild 許多後端的核心服務

前言再前言, 關於看這一系列Scala文章前你可以知道的事

學習Scala也不過是幾個月的事情, 實際上還沒用Scala做過的複雜系統, 只有自己簡單的做一些範例練習
我的Scala觀念主要是來自這本書 Scala in Action
以及部分網路上的教學來補足其他部分
所有的Scala觀念都是以Scala in Action一書為主, 
分享的內文邏輯和部分例子, 都有參考該書,
是經過我腦袋自己重整, 加上自己的想法後才分享出來
想要更仔細了解Scala, 建議親自去看該書
會開始寫這Scala分享文, 主因是讓腦袋整理一遍, 使我所學得更扎實, 邏輯更明確
另一方面也是因為有鑑於網路上, Scala中文方面的資源較少, 多一點分享也好

Scala basic4, For-comprehensions

前言
在Programming language裡面, 迴圈的設計能夠重複的執行某些工作, 藉此機器的運作才得以日復一日規律的執行, 如同世界運轉一般, 在Scala中迴圈 while 如JAVA一般沒甚麼不同, 可是For發展出更有彈性的應用, 尤其遇上了Immutable 變數的時候, 不能用過去 int i 當作迴圈次數索引, 需要有更方便的架構來幫助軟體運行

Scala basic3, Array & List

前言
資料結構是一個很棒的發明, 豐富了原本看起來只是0和1的電腦世界, 很多現實世界中的事物才可以藉此數位化的保存與傳遞, 複雜的資料結構都是由簡單的元件組合而成的, 在Scala之前最常見的簡單結構是Array, Array讓資料得以方便複數處理, 在Scala後更開始依賴List的活性, 在Scala中不是創造了新的架構, 而是在原本熟悉的架構中, 提供更有j完善的操作函式, 讓軟體更加容易更快去面對複雜的世界

Scala Basic2, 函式

前言
Method跟Function是有差別的, 在OOP的世界中, Method只是物件中的一個功能函式, 一個不完整的個體, 跟所屬物件相依性很高, 它會存取修改到物件的變數, 造成Side effect, 可是當你到了Functional Programming的概念時候, Function就強大的多了, 它是自己獨立個體, 有自己的生命環境, 可當作物件參數傳入其他函式, 更可以透過Composition由小元件建構出複雜的運算架構

Scala Basic1, 變數

前言
       如果你本身是一個OOP Programmer, 透過OOP的概念來進入Scala是一個很好的開始, 尤其當你又是JAVA Programmer, 那麼該是時候來藉由Scala來進化到下一個階段：有生產力且有效率的Program. Scala並非一個全新的語言, 當你遇到學習瓶頸的時候, 可以思考看看這個語法特性在JAVA or其他語言是長怎麼樣, Scala又如何做新的詮釋? 很多東西在Scala表面上看似新的, 但Scala只是基於過去的功能做更進化且更好的應用.

Scala 前言2 - is Scalable by OOP & Functional Programming

前言
Functional programming是一個比OOP還要舊的語言, 重點不是What is Functional Programming, 而是當Scala 同時有Functional programming & OOP特性的時候, 這兩者該如何完美的互相結合, 並且幫助你建置出有用且可擴展性的Software

Scala名稱來自於Scalable, 它的使命亦即就是讓你可建置出可擴展性的Software, OOP本身也是一個可擴充性語言, 當你需要新的東西時候, 創造新的物件 or 透過繼承來實做是一個常見的方式, 可是OOP的Encapsulation(封裝) 把Program架構模組化成物件, 卻又產生了一些矛盾, 因為在一個以物件為基本元素的語言, 當你只需要該物件的一個method的特性時,你卻得繼承整個物件, 是非常不方便的, 如果硬幹, 你要幫既有的系統增加新的功能時, 你會遇到得重新Compile整個系統, 是會有問題的.

Functional Programming是一個比OOP還要舊的語言, 在FP中是把Instruction封裝成一個Function, 而OOP可以視為這種模組的進化, 當Software更加複雜的時候, 把Method + Field 封裝成一個物件. 但也限制住了Functional的很多特性, 為了建置出可擴展性的Software, Scala結合了OOP與Functional的特點, 這兩者看似相近又有矛盾的架構, 該怎麼結合?

Scala 前言1, 是Java的下一步也是物件導向的下一步

前言
重點不是What is Scala, 而是Why, 重點不是多了酷炫的語法 or Framework, 而是OOP的下一步是甚麼 ?當cpu發展已經走到多核心而你的program只能在一個processor裡面龜速的時候, 該意識到時代正在改變, 學Scala對我來說不是最佳解, 只是邁向下一個進化必然的階段而已

OOP's Next step

OOP是一個劃時代的發明, 電腦語言最原始的0與1的組合被抽象化成現實世界中的物件組合,大大的促進了programming language的推廣與應用. OOP更被CS列為必修課程之一, 然後一路從大學到研究所, 到業界到建置各種Software & Service等等. 當然OOP不是完美語言, 去建置各種不同的Service(ex Web, APP)會很困難, 因此一些彌補OOP不足的Framework(ex MVC)一一浮現出來, 可是根基不改, 最後還是會被一道牆壁而堵住

這道牆若要說是莫爾定律的極限, 但並非IC design人員且跟硬體很疏遠的programmer, 不如換個角度來觀察；現在市面上的CPU Core基本上都是 4核心起跳, 平行化處理是最有效率的去提升Software Performance, 儘管現在大家泛用的語言都有提供 Thread相關的 Library, 先別說到底有多少人真的有去實用過

看OOP最精隨的Call by reference, Shared data很容易在多個Thread 間同時存取&修改,但是造成的Data inconsistency, 導致每一次的Output都像開樂透一般難以預料, 當你的Application不能正確符合邏輯與User的期待時候, 就已經不是一個Program.