📜 [專欄新文章] 類 Python 的合約語言 Vyper 開發入門:與 Solidity 差異、用 Truffle 部署、ERC20 賣幣合約實做
✍️ 田少谷 Shao
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
有鑒於個人近期關注的 Uniswap 及 Curve 皆用 Vyper 實作,索性瀏覽了官方文件並嘗試一些開發工具,希望此文能減少一些讀者初嘗 Vyper 會遇到的麻煩!
Vyper and Solidity
Outline
一. Vyper 極簡介二. 與 Solidity 語法差異三. 開發、開發環境設置 1. 語法高亮 2. 本地 Vyper compiler 安裝 3. 使用 Truffle 操作 ERC20 - 安裝 Truffle - 發幣 - 寫個簡易賣幣合約四. 已知 Remix 問題 五. 結語
一. Vyper 極簡介
Vyper 是除 Solidity 外,以太坊上的另一智能合約 (Smart contract) 語言。其語法和 Python 相近,但畢竟也是寫合約的語言,邏輯差異不大,所以若熟悉 Solidity 應該不難理解用 Vyper 寫出的合約!
Vyper 主要被設計和 Solidity 的區別是安全性及可讀性,這部分會在下一段落及後方的實作中舉例說明。
二. 與 Solidity 語法差異
Vyper 與 Solidity 的差異有許多,在本段只就個人認為感受較深的三點進行說明,其他差異只進行翻譯,有興趣的讀者可以到官方文件詳細了解:https://vyper.readthedocs.io/en/latest/index.html
1. 沒有 modifier
Solidity 常見的 onlyOwner() modifier; 由於 gist 沒有 Solidity 的語法高亮,故截圖
在 Vyper 中單純用 assert 及 assert_modifiable 來進行條件檢查,兩者差別為若要檢查函數執行後的返還值,要用後者,如下圖:
Vyper 寫法
2. 沒有 Class inheritance 繼承
繼承是物件導向程式設計 (OOP) 的核心概念,但各種繼承關係有時候確實很複雜。Vyper 沒有繼承,這無疑大幅地增加了程式可讀性及安全性,以及降低審計程式碼的難度。在此提供一個例子供不熟悉 OOP 複雜之處的讀者有個概念:
source: https://consensys.github.io/smart-contract-best-practices/recommendations/#multiple-inheritance-caution
在上例中,contract A 的 fee 值 (因繼承自 contract B 和 C,故有 fee 一值) 是 5、a 值也是 5 (因繼承自 contract Final,故有 a 一值)。原因是 A 先繼承 B 再繼承 C,因此 contract A 中的 setFee() 是使用了 contract C 的 setFee(),而 a 值是由於 C(5),這代表 contract C 的 constructor (舊版本中即 function C(),函式名稱同 contract 名稱) 被傳入的值為 5。
稍微延伸一下以上概念,將 contract A 改成:contract A is C, B。如此一來,a 值還有 fee 值都會是 3,因為這次 A 先繼承 C 再繼承 B,因此最終吃到的值是 contract B 的。
以上就是 OOP 繼承的複雜之處的簡單範例說明,應該能稍微感受到爲什麼除去繼承後會大幅提高可讀性及安全性,畢竟即使是熟悉 OOP 的人有時頭腦一混亂也會開始懷疑自己寫的程式碼繼承結構是否正確 …
3. 沒有 dynamic array 動態陣列
這應該是目前 Vyper 設計中爭議最大的部分。沒有動態陣列代表在宣告陣列時需要宣告其長度,也就是說 Solidity 中的寫法 uint[], bool[] 等等,這些是不會出現在 Vyper 的。在 Vyper 中只能出現諸如:
# Vyper 的變數宣告方式為 變數名稱: 存取範圍(變數型態(若為陣列給長度))
values: uint256[10]participants: public(address[20])
可以看到上方的 uint256 及 address 兩陣列皆需要宣告長度,不能不宣告而使其動態地配置空間。
沒有動態陣列固然可以確保執行運算的範圍、次數,但一來動態陣列真的很方便、二來在 Solidity 有此功能而 Vyper 卻沒有的情況下可能會造成麻煩,詳見此一討論串:點我。
4. 沒有 inline assembly,程式碼中不會有組合語言
5. 沒有 function overloading,函式不會因傳入的參數數目不同而結果不同
6. 沒有 operator overloading,運算符號不會有不同於預設的自定義功能
7. 沒有無限迴圈,可免於 gas limit attack
8. 十進位定點數 decimal fixed point 而非二進位 (binary) 定點數,詳見:點我
三. 開發、開發環境設置
結論先講
開發 Vyper 的最佳姿勢目前個人認為是在本地裝上 Vyper compiler、用 Truffle 部署,並在撰寫時將檔名後加上 .py 就能有 Python 的語法高亮👌
1. 語法高亮 (syntax highlighting)
有語法高亮絕對是舒服地寫程式的第一步。
Remix 有 Vyper 的語法高亮,但一來個人目前不推薦使用 Remix 來撰寫 Vyper,原因詳見下方 4. 已知 Remix 問題;二來 Remix 的語法高亮其實也沒有很清楚,因此個人推薦:在本地開發,將檔名後加上 .py 就會有 Python 的語法高亮。
2. 本地 Vyper compiler 安裝
照官方說明使用 Python 的虛擬環境 virtualenv:
source: https://vyper.readthedocs.io/en/latest/installing-vyper.html#installing-vyper
簡單兩點提醒:
如果中間那行報錯但確實已經有 Python,則可能是版本問題。依照自己電腦上的版本改成相應的即可,ex: python3.6 改成 python3
進入虛擬環境後(檔案路徑前方應有 vyper-venv 的提示),使用此指令: vyper {檔案名稱}.vy,即可編譯 .vy 檔;使用完畢後輸入 deactivate 即可退出
3. 使用 Truffle 操作 ERC20
安裝 Truffle
Truffle 雖有冗餘的 migration 但也別無他法,畢竟 Remix 目前仍不完善 :(
下載流程可以照官方文件,使用 vyper-example:
source: https://github.com/truffle-box/vyper-example-box
由於我們會接上測試網 Ropsten,因此還要下載 truffle-hdwallet-provider:
source: https://github.com/trufflesuite/truffle-hdwallet-provider
接者就可以開始使用 Vyper 寫合約了!
發幣
由於 Vyper 的官方文件中已經有許多優質範例,因此本文希望來點不一樣但大家卻又很熟悉的…以 ERC20 為例(這千篇一律的主題xD):
用 Curve 的 ERC20 程式碼為範本,發一個幣(又要發…)
寫一個簡易賣幣合約
選擇這個主題一方面畢竟 ERC20 是以太坊的最大宗應用之一,二來有興趣的讀者可以透過讀 ERC20 的程式碼來熟悉 Vyper,並在看過本文的流程後對於用 Vyper+Truffle 來操作 ERC20 有完整的概念!
好的,首先複製一份 Curve 的 ERC20 程式碼(看到就順手拿來用),並複製到 Truffle 所在路徑的 contracts 資料夾中:https://github.com/curvefi/curve-contract/blob/pool_compound/vyper/ERC20.vy
由於第一點希望著重在跑一次流程,因此不改動合約的程式碼。
將 ERC20.vy 複製到 contracts 資料夾中後,到 migrations 資料夾開啟 2_deploy_contracts.js,首先將 require() 中的參數改為 ERC20.vy 的檔名 ERC20,再來依照自己喜好決定幣的名稱、代號、小數點位數及發行總量,輸入於 deployer.deploy() 中。
接著,為了和測試網 Ropsten 互動,需要將以下程式碼寫入 truffle-config.js。
第二行的 privateKeys 是帳號的私鑰。以下實作需要兩個帳號來操作,因此請從錢包匯入兩組私鑰(並非助憶詞)。
在第 13 行中 HDWalletProvider 此函式的第三個參數代表要用第幾個帳號最為預設帳號(部署合約等),第四個函數代表總共匯入幾組帳號。而第二個參數則是需要至 Infura 申請一個 project 來得到串接 Ropsten 的連結。這兩步驟並非本文重點,因此不詳細解說步驟,Google 搜尋關鍵字應該就會找到方法!
接著,就可以輸入以下指令來將代幣發佈到 Ropsten:
truffle deploy --network ropsten
有進入虛擬環境才可以編譯 .vy 檔,若忘記就會收到如下的錯誤訊息:
記得打開虛擬環境才能編譯 .vy 檔
成功後就可以在 contract address 中看到代幣發佈的位置,加入到 Metamask 中就可以看到。本文的例子是維尼代幣 Winnie the Coin, WTC ;)
contract address 便是 ERC20 的所在
Winnie the Coin, WTC
好了,到此測試網上又多了一個測試用的垃圾廢幣。
寫個簡易賣幣合約
賣幣合約中我想要簡單有兩個功能就好:付錢買幣 、結束銷售,以下就是程式碼。買幣的部分就不寫太詳細,固定價格為 0.01 Ether 可以買 500 代幣。
簡單說明幾點:
Solidity 的 constructor() 在 Vyper 中為 Python 風的 __init__():
函式的屬性(public, private, payable 等等)放在函式上方,與 Python 的修飾器位置相同
總之寫法跟 Python 很像,次方也一樣是用兩次乘法代表:**
變數前加上 self 代表是當前合約的變數/全域變數,因此非常容易與函式中的變數/區域變數做區隔
由於已經在第一行匯入了 ERC20 那份合約,因此透過將地址傳入合約當參數,就可以呼叫在該地址的合約:ERC20(self.tokenAddress) 。並且,可以將部署的合約存成一個變數 erc20 較方便
寫完合約後一樣要更改 migrations 資料夾中的 2_deploy_contracts.js 如下,將代幣所在的地址作為參數輸入。
由於先前已經部署過一次了,因此要重置才能再部署第二次,輸入以下指令:
truffle deploy --reset --network ropsten
部署成功之後就要來試著買幣啦!輸入以下來進入 console:
truffle console --network ropsten
成功進入後應該會看到 truffle(ropsten)> 的字樣。接著,首先取得部署的兩合約,並查看是否有返回合約資訊:
# ERC20 及 SellToken 是先前在 2_deploy_contracts.js 中的變數名稱,代表被部署的合約
let instance1 = await ERC20.deployed()instance1 # 印出 instance1 的資訊
let instance2 = await SellToken.deployed()instance2 # 印出 instance2 的資訊
再來,為了讓 SellToken 可以賣幣,要先用 ERC20 的合約匯幣到 SellToken 的合約。因此,輸入以下指令:
instance1.transfer(instance2.address, 10000)
# 這裡數字只要設為 > 500 就可以
接著,我們要利用第二個帳號去買幣(第一個帳號為預設帳號,因此就是代幣擁有者)。將帳號的資訊存入變數 accounts 中,再指定送出交易的帳號是第二個帳號。由於我個人匯入私鑰的順序是將第一個帳號存在 truffle-config.js 的 privateKeys[0]、第二個帳號存在 privateKeys[1],因此第二個帳號的地址就會在 accounts[1] 的位置:
let accounts = await web3.eth.getAccounts()
instance2.buyToken({from: accounts[1], value: 10000000000000000})
# value 為 10^16 是因為在 SellToken 的 buyToken 函式中買一次要 0.01 Ether, 即為 10^16 wei
然後應該就會在自己的第二個帳號中看到匯入的幣了~
最後,由於合約中結束銷售就是一個自殺 selfdestruct 函式,因此可以呼叫看看,第一個帳戶錢包中的錢應該會增加,因為第二個帳戶有付款買幣;並且,可以到 Ropsten 上瀏覽,應該能看到相關提示:
中間 contract 的右上角有 Self Destruct 的樣式
四. 已知 Remix 問題
Remix 目前有兩個版本,只有新版有 Vyper 的編譯器。在此整理目前遇到的問題,如果有人也遇到可以對照一下本處,可以省去很多自我懷疑xD
不會報錯
Remix 的編譯結果有時會是錯的、和本地端編譯出來的結果不同
舉上方的 SellToken 合約為例,將其複製到 Remix 中使用左邊的 Remote Compiler 有錯,但又不報錯 q_q (ERC20 的合約有在同檔案目錄)
左方有紅色三角形,代表編譯失敗,但沒有報錯訊息可以看…
getter function 竟然要花錢
用 Solidity 寫的合約,查詢 public 變數的值應該是不用消耗 gas 的,但不知何故查詢 Vyper 寫的合約的 public 變數卻要消耗 gas,如下圖…
可以看到中下方有 22026 gas 的消耗
Local compiler 無法使用
圖中的 Local Compiler 此選項,個人雖照官方文件執行 vyper-serve 但卻失敗,因此若有讀者成功希望能留個言不吝分享!
五. 結語
Vyper 作為一個比 Solidity 更新的合約語言,在寫程式碼的方面沒什麼問題,但相關的開發工具、學習資源等都遠不及 Solidity。
Vyper 主打的兩個特色:可讀性的部分相信看完上面的讀者應該已經有些感覺;安全性…小白如作者我倒是沒有感受到顯著的不同。況且 Solidity 已經發展許久,很多錯誤的寫法、知名的安全漏洞大家應該也很熟悉了,還有 Openzeppelin 提供安全合約寫法的範本,因此有待以後高人解說安全性是否真的是 Vyper 較好。
有興趣者可以查看 Vyper 的安全報告:點我,大意是目前 Vyper 的編譯器仍有許多問題待改進! (感謝 Chih-Cheng Liang 的提供)
本文對 Vyper 的介紹及其與 Solidity 的差異只講了個大概,欲知更詳細的介紹還是要麻煩讀者前往官方文件了:https://vyper.readthedocs.io/en/latest/index.html
最後,如果本文有任何錯誤,請不吝提出,我會盡快做修正;而如果我的文章有幫助到你,可以看看我的其他文章,歡迎一起交流 :)
田少谷 Shao - Medium
類 Python 的合約語言 Vyper 開發入門:與 Solidity 差異、用 Truffle 部署、ERC20 賣幣合約實做 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
「python compiler推薦」的推薦目錄:
- 關於python compiler推薦 在 Taipei Ethereum Meetup Facebook 的最佳貼文
- 關於python compiler推薦 在 iThome Facebook 的最佳解答
- 關於python compiler推薦 在 コバにゃんチャンネル Youtube 的最讚貼文
- 關於python compiler推薦 在 大象中醫 Youtube 的最讚貼文
- 關於python compiler推薦 在 大象中醫 Youtube 的最佳解答
- 關於python compiler推薦 在 Re: [問題] 新手學習Python的開發環境 的評價
- 關於python compiler推薦 在 #新手Python 的編輯器 - 軟體工程師板 | Dcard 的評價
- 關於python compiler推薦 在 3 種Python / C++ 線上編譯器 的評價
- 關於python compiler推薦 在 Python 程式語言設計課程: 基礎篇工具 - YouTube 的評價
- 關於python compiler推薦 在 程式人 的評價
- 關於python compiler推薦 在 [心得] 大一程設自學心得 - Mo PTT 的評價
- 關於python compiler推薦 在 用iPad寫程式? 的評價
python compiler推薦 在 iThome Facebook 的最佳解答
【好文推薦】腦力科技之四:要複雜還是要簡單
成大資工係蘇文鈺教授從台灣企業看輕底層IT(忽略對OS、編譯器等等底層技術的投入)的價值,只顧搶商機的幾個真實小故事,來談臺灣資訊產業的困境和短視。
好文一篇,經蘇老師同意特轉貼!
"許多傳統的技術因為其他領域的技術的高度發展而導致被淘汰,也有許多早被丟棄在一邊多年的技術卻因此而重生。可是因為許多人無法看到幾個世代以來的技術發展過程,也欠缺終身學習的思維,因此常常固執的固守一項當下看來成功的技術與做法,這些人或公司最終都是會招致失敗的後果。
by 成功大學資訊工程學系蘇文鈺教授"
之前的po文,我修了一下文字。若是之前看過的可以跳過。
[腦力科技之四 要複雜還是要簡單]
前面說到的Dave Wilson要價數十萬美元的喇叭WAMM是個大傢伙,整個喇叭是多個分開的模組所構成,非常複雜,所以一般不熟WAMM人要把它調整好是很困難的,難怪要出動Dave Wilson本尊才行。問題是要聽好聲音一定要弄得這麼複雜嗎?
簡單的喇叭,一顆單體裝在一片木板上就可能可以很好聽了。到底要複雜,還是要簡單,其實這問題說是難回答的也不見得,想通後,也可以很簡單。以下是聖嚴師父說過的一個故事:
在我小的時候,有一天傍晚,我父親跟我正好經過一條河邊的小路,有一群鴨子本來在河岸上休息,見到我們父子倆走過,或許是受驚了,也或許是要讓路給我們,總之一群鴨子全部都下了河,從河的這一邊,游到另一邊去。接著又上岸去玩了。
父親看著在河裡游的鴨子,告訴我說:「孩子,你看到了嗎?這群鴨子裡,有大鴨、有小鴨。大鴨游出來的是大的路,小鴨游出來的是小的路。不管是大路還是小路,都是自己游出來的路,而且都到了河的對岸。」
又說:「孩子啊,人要學這些鴨子。你長大之後,不管游出大路或小路都沒有關係。可是不游是不行的,因為不游的話就沒有路可走了。」
也就是說,簡單有簡單的用處,複雜的有複雜的好,做的好,都有活路。
我們這個年紀的人當年用的是Apple II,學程式是從Basic入手,然後是Fortran,接著是Pascal和C,後兩者最大的障礙是要把當時認為抽象的資料結構(data structure)以及資料存放的位址(address)和指標(pointer)的關係搞懂。相對於Basic不知到複雜多少,可是用C能做的事,其實用 Basic也做的到,只不過後者做起來可能會很麻煩而已,程式可讀性與可再被利用性會大幅降低。後來一點我才知道其實所有的高階語言都會透過編譯器(compiler)轉為更低階的assembly(組合語言),所以實際上電腦是依照組合語言一步一步執行的,一個高階語言的指令通常是以多個低階語言來完成。當年在開發工具不足的情況下,我甚至被迫要直接用6502與Z80的機器碼(machine code)來寫程式,因為當時根本沒有如現在這些方便的滑鼠,鍵盤與螢幕可以用。一份工作是要用高階一點的語言來實做,還是用低階的語言來完成,應該依照需求與當下的技術成熟狀況來決定,而不是高階的就一定比較好,低階的就比較一定差,例如多數驅動程式,不用低階語言來做是不行的。反之亦然。
後來我的工作跟使用TI(德州儀器)的C3X與C4X等數位訊號處理器(Digital Signal Processors)有關,一些數位訊號處理的程式我與我的夥伴們都用組合語言來寫,因為編譯器轉出來的程式執行效率實在太差了。可是幾年以後,編譯器越來越強大,所編出來的程式的效能就慢慢提高了,在非關鍵處,我們已經不再堅持用組合語言來寫了。
後來的程式語言越演變越複雜,功能也越來越強大,從簡單的C,到後來的物件導向(Object Oriented),從為數不多的語言,到因為不同的需求而被開發的新語言如Java,LISP,Pearl,Python,Forth等等甚至有為了設計電路的硬體描述語言(HDL) ,慢慢的學校裡對組合語言的要求變少,學生也不願意學,造成許多需要低階語言的工作找不到人來做,不然就只好把人招進了公司後再來訓練。緊接著,為了不同的目的而開發的新的工具軟體變多了,例如為了特殊的資料流(data flow)程式模型而被開發的StreamIt,以至於目前開發iOS App而廣為使用的Object C(我們之後有機會再來談這個語言),為了平行程式所被開發的如OpenMP或MPI(Message Passing Interface),這世界上有關於寫程式這件事所被開發出了來工具多到滿出來,編譯器與中介軟體(middleware)越來越強大,各式各樣的新語言,新應用等等就越多。可是不要忘了,即使是有這麼多五花八門的產物,這世界上有一些角落裡的工作還是需要使用組合語言來做。
有些事需要用複雜的方式來做,有的事卻需要用簡單的方式來做。原本一隻簡單的程式,因為可以平行化,如今我們因為有多核心的機器與可平行的程式模型可以用,所以程式設計師會用更複雜的方式如多執行緒(multithread),資料流(data flow),Map-Reduce(如Hadoop),CUDA與OpenCL等來實做,程式的複雜度看起來提高很多,可是執行所需的時間實際上卻大幅降低。又如,在數位訊號處理裡常用的旋積(Convolution),本來是可以用沒幾行的程式就可以寫出來,但是因為快速富利葉轉換(FFT)的關係,讓我們可以在頻率域(Frequency Domain)裡運算以減少計算時間,但是程式複雜度卻高出許多。可是,因為多核心架構硬體與平行的程式模型的出現,加上時間域(Time Domain)的旋積具備高度可平行化的特性,現在反而是回到時間域來計算要快得多,同時也少了一些在頻率域(Frequency Domain)運算所造成的缺點,過去為了在頻率域運算所開發出來的演算法反而變得沒有多大用處了。
許多傳統的技術因為其他領域的技術的高度發展而導致被淘汰,也有許多早被丟棄在一邊多年的技術卻因此而重生。可是因為許多人無法看到幾個世代以來的技術發展過程,也欠缺終身學習的思維,因此常常固執的固守一項當下看來成功的技術與做法,這些人或公司最終都是會招致失敗的後果。
以上我們說了許多軟體的發展,接著來說硬體,尤其是電腦的核心,CPU(中央處理單元),也就是大家常聽到的Intel Pentium,IBM PowerPC或是ARM Cortex等等。早年的CPU如Apple II用的6502到今日的主流多核心CPU,其複雜度不知道已經高出多少倍,30年前的大型主機(我大學時用的是CDC Cyber,全校共用)的計算能力可能比不上今天的一部桌上型電腦。有一陣子,簡單架構的CPU不容易被聽到(但是實際上他們的用處很廣呢!),一般人知道的CPU都是INTEL出的(因為廣告打得兇),那時的人類似乎除了INTEL X86架構的CPU之外都不需要其他的了。可是曾幾何時,INTEL感受到ARM的架構簡單的省電CPU的強力威脅,所以INTEL也希望把它的CPU變成簡單又省電,但是與此同時,ARM卻在把它的CPU變得功能更強大,但是卻也更耗電。你們說,這兩家公司在爭的商機是甚麼呢?相信只要在這個產業的人都知道他們在玩什麼把戲。大家都知道的東西,在CPU設計落後先進國家的台灣在高階CPU上也就沒什麼好搶的了,那台灣的機會在哪裡呢?(當然,現在的聯發科跟晶心科技這兩家策略與市場都不一樣的公司看來是很有機會佔有一定的市場,有興趣的人可以去研究一下這兩家公司的CPU策略)
有一天,有朋友打電話給我,聊起他現在的公司也在做CPU,而且是八位元,或甚至位元數更低的CPU。我說,這麼低單價的東西有什麼好做的。他說,其實市場的量真正大的是簡單型的CPU,因為太多應用只需要用到簡單的CPU,這時連8051都還嫌太複雜,而且目前設計界常用的Arduino也可以在稍微複雜一點的八位元CPU跑起來。只要做的夠便宜夠省電,利潤還是有的。但是這其中還有一個大問題,那就是即使是這麼簡單的CPU,在今天的情況,工具鍊(toolchain)還是要完整,才會賣得出去。他問我可不可以幫他做編譯器,我說這非我專長,實在是愛莫能助。我不禁想,這年頭連賣一顆幾毛錢的CPU都要開始建完整工具鍊了,這錢還真難賺啊!
又有一次,有間廠商打電話過來問我有沒有興趣做一個建教合作計畫,是關於多核心的系統軟體的。那時候我一聽到多核心,腎上腺素就上來了,也沒多問細節就說可以見面討論。過兩天,我們一起聚在一起開了個會,才知道這個多核心原來是拿8051來當核心。我心想,連8051都拿來做多核心,會不會太奇怪。不過既然廠商堅持有他們的市場與考量,也可以賣得出去,我這商場門外漢就不好說甚麼了。接下來廠商希望我們可以幫忙做兩件事,第一件是為這顆多核心打造一個多核心作業系統,第二件是做一套中介軟體讓不同核心之間可以快速交換資料。當我心裡還在盤算著,且認為這應該可以做得到的時候,接著聽到的話讓我差點從椅子上掉下來。他說,但是這一切希望在16K bytes之內做到,而且在半年內做完,經費是30萬。接著我只能說我願意考慮看看,其實心裡說的是謝謝再連絡並祝福他們會成功,一刻鐘後我堆滿一臉笑容來隱藏底下的鐵青送他們出門。
這些事讓我想起來台灣過去幾年有關IC設計的問題,甚至是更多產業所面對的問題。那就是太重視硬體了,以為只要把硬體做出來,就可以賣出去的時代早就已經過去了,而目前全世界最大的高科技公司其實都是軟體為主的公司,連聯發科的軟體工程師數目早就超過硬體工程師的數目了。假如連一顆八位元的不到的CPU都需要一大堆軟體工具鍊,那麼我實在不清楚很多公司只注重看來是實際出貨用的硬體在想什麼,會逐漸失去商機不奇怪啊!我自己會想,要是早個十年我知道軟體的工具練會這麼重要,那麼我不就賺翻了嗎?可是上面的第二個故事告訴我,在台灣,不被重視的就是不被重視,早做也沒用。很多廠商把技術看得太廉價了,但是這家公司至少還願意出錢,有的台灣公司即使本身很賺錢卻根本就連錢都不出就想獲得技術。
2010之前的好幾年,韓國的政府讓許多家大學(我沒記錯的話是八家,連漢陽與首爾都在其中),參與企業(就是三星啦!)一起trace Android的核心的時候,台灣在做甚麼呢?大喊自由軟體,然後只要寫寫不知道能不能用的Java App就可以有獎金或補助。等到三星智慧型手機崛起,火燒屁股時,才急急忙忙由政府底下的若干研究單位出面協調,同時希望學界也能出面幫忙。
這整件事的荒謬在於,第一,商場如戰場,都火燒屁股,要馬上上戰場去賣的東西讓學界來幫忙怎麼會來得及呢?第二,學生寫的軟體你敢用嗎?一旦有bug不是退貨退到瘋掉?第三,這種核心技術早就該知道要做了,不然派個探子去美國,甚至是韓國轉一圈,也知道人家在做甚麼。然後,既然都火燒屁股又要找學界專家來幫忙,為什麼不乾脆花大錢挖學界懂這東西的一整個團隊進公司體系,還要找官方與半官方的機構出面協調,這不是浪費時間呢?台灣不是最流行超時工作,讓工程師燒肝(燒乾)工作的嗎?高薪一堆人進來,以台灣工程師的素質之高,其實不會沒救的。不過,我看到的情況只能用失望兩個字來形容。
有時人要挖空心思才可以看到商機,有時只要好好照著道理來做就會有商機,賣系統(不管是複雜到手機還是其他簡單的系統應用IC)卻不重視軟體就是沒照著道理來做。目前台灣所製造的電腦產品,只要是要用到稍微大型的軟體系統如Android,或甚至是小到一個小型的RTOS(即時作業系統),有多少是台灣所原創的呢?不能原創的原因很多,公司不重視軟體人才此其一,會教又提供學生實作機會的學校不多(因為做這類苦工無法出High Impact Factor的論文啊!)也是主因,政府科技與教育政策一樣難辭其咎。以編譯器(compiler)這樣傳統的學問來說,不管時代怎麼變,不變的是它對產業總是非常的重要,學校裡有多少人還在做編譯器的研究呢?再來恐怕都要找不到人來教了,因為有多少教授願意做一個傳統又難以發表High Impact Factor論文的研究呢?過幾年,整個硬體產業要是變成硬體慘業,我是一點也不意外。即使沒完蛋,還不是要乖乖每年繳一大堆權利金給外國提供軟體的廠商嗎?
你若是問我,難道台灣真的沒有那種看到軟體工具鍊與大型軟體的機會,堅持信念,終於媳婦熬成婆的團隊嗎?當然有,我也好希望我也是其中之一。可惜我沒有這麼堅強的毅力,要不然也不用在這裡狗吠火車了。
前面說過的話,這裡再重複一遍,但是用意與前面不同,這裡是希望為上面這幾段故事做小結:
許多傳統的技術因為其他領域的技術的高度發展而導致被淘汰,也有許多早被丟棄在一邊多年的技術卻因此而重生。可是因為許多人無法看到幾個世代以來的技術發展過程,也欠缺終身學習的思維,因此常常固執的固守一項當下看來成功的技術與做法,這些人或公司最終都是會招致失敗的後果。
時代在改變,有些事也會跟著變,但是有些事卻也一直不變,變與不變之間,要視實際狀況決定。就跟聖嚴師父說的一樣,大鴨子與小鴨子,只要願意努力前進,都可以游出自己的路。
python compiler推薦 在 #新手Python 的編輯器 - 軟體工程師板 | Dcard 的推薦與評價
想知道大家都用什麼編輯器去寫的 另外可以的話想了解IDE compiler 的差別 像Eclipse,VS,Dev C++ 應該都是屬於IDE? 請益 · 程式語言 · python. ... <看更多>
python compiler推薦 在 3 種Python / C++ 線上編譯器 的推薦與評價
本篇介紹3 個好用的Python / C++ 線上編譯器, ... 以下以熱門程度與使用者體驗來排序,越後面越好,分別為ideone.com onlineGDB repl.it (推薦使. ... <看更多>
python compiler推薦 在 Re: [問題] 新手學習Python的開發環境 的推薦與評價
回答你的問題:
1. Python 是直譯語言, 有一個直譯器, 官方網址 https://www.python.org/,
目前版本是 Python 3.8.3, 下載後約 26.5MB, 內建一個簡單的IDE(稱為IDLE).
2. 你可以只用 IDLE 編寫, 或使用 VS Studio, VS Code, Spyder, PyCharm,
Sumblime Text 3, ATOM, Notepad, Notepad++, etc.. 來編寫 Python Code,沒差別
3. 文字編輯器編輯完後, 可以在有安裝 Python 直譯器的電腦上執行副檔名為.py 的程式.
所以:
1. 幾乎沒有一本書 (至少我沒看過) 內容是用 Visual Studo 201x 來介紹的.
2. 最常見的是介紹使用 Anaconda 和 PyCharm, IDLE, Spyder, IPython, Jupyter.
3. 我個人比較覺得新手用 IDLE 即可. 或是用 VS Code 搭配 IDLE.
4. 書的部份我之前常有介紹. 新書很多我沒看過, 但我個人推兩本:
a. 輕鬆學 Python3 ISBN 978-986-476-602-4
b. Python入門邁向高手之路 (有新的很多不同版)
5. 我自已也有裝 Visual Studio 2019, Installer 內可以帶 Python 3.7.5. 可以去
官網下載新版 3.7.7 後安裝, 它會更新原來的.
6. Microsoft 網站有介紹如何用 VS2019 搭配 Python 寫程式, 內容佷詳細應該足夠.
7. 大家都推用 VS Code 比較多, 我個人也覺得很棒. 除錯比較方便. 只是我用的時候,
輸入中文時有時畫面顯示會有問題, 不知有沒有人有碰到過.
8. 用 VS Studio 如果你習慣了也行, 只是它很大(大概要 3.5GB), 等它開起來我程式
都寫完了. 我通常用小小的 Sublime Text (10M) + IDLE (27M) 開起來很快.
9. 很多書前面的語法大同小異. 買書時主要看你有沒有什麼套件 (Packages) 或用途 (
Machine Learning/Big Data/etc..), 每本書介紹的都不太一樣. 最好挑新一點的.
因為套件一直在更新. Python也有v2和v3的差別, v2快不支援了, 所以太舊旳不建議.
10. 書還是自已覺得看得慣比較好. 我自己有時候是翻兩下就知道這本書我看不下去.
※ 引述《jayzhuang (Jay)》之銘言:
: 各位大大您好~!
: 在下因為換新工作,新公司未來要我學習python相關的東西
: 但小弟是個新手,所以打算買本書來看看。
: 有看到網友與一些人推薦新手可以買看看這本書:
: https://reurl.cc/MvD0lL
: 或是另一本書:
: https://reurl.cc/yZXr32
: 不過我因為以前寫C#的,所以習慣都用Visual Studio(2015、2019)
: 在前公司也是都用VS,目前新公司也都是用VS開發。
: 我自己有實際在我的電腦用VS寫過一點點python的語法
: (單純的命令提示字元顯示那種,但還沒開始很深......)
: 想詢問看看這兩本書的內容,都可用VS環境學習嗎?
: 或是有人有推薦適合新手的python書,可用VS開發學習?
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.192.186.54 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Python/M.1591029612.A.717.html
... <看更多>