[討論] 有人用過 函數式 elm-lang 前端開發嗎？

看板Soft_Job作者 (ccggqqll_)時間4年前 (2020/01/18 12:31), 4年前編輯推噓11(11推 0噓 49→)
留言60則, 7人參與, 4年前最新討論串1/1
最近剛好接觸到 elm-lang https://elm-lang.org/ 意外的感覺這個跟react 跟angular 相較起來很有效率 還沒仔細嘗試 func lang 的功能 不知道有沒有先進用過 elm 來開發前端？ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.227.101.105 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1579321918.A.A6A.html ※ 編輯: qitisland (61.227.101.105 臺灣), 01/18/2020 12:32:56
推
01/18 13:51, 4年前 , 1F
和人互動的東西 (UI/UX/IO...) 用函數式做是想不開還是..
01/18 13:51, 1F
→
01/18 13:51, 4年前 , 2F
.
01/18 13:51, 2F
推
01/18 14:55, 4年前 , 3F
Sovmedcare有玩過，可以去Github看看
01/18 14:55, 3F
→
01/18 18:47, 4年前 , 4F
為什麼跟人互動就不能函數式？
01/18 18:47, 4F
推
01/18 23:06, 4年前 , 5F
要比喻的話，操作型語言（例物件導向）之於點陣圖
01/18 23:06, 5F
→
01/18 23:06, 4年前 , 6F
就像定義型語言（例函數式）之於向量圖
01/18 23:06, 6F
→
01/18 23:06, 4年前 , 7F
點陣圖你哪邊須要什麼就加上去就好，適合隨時修改、新增
01/18 23:06, 7F
→
01/18 23:06, 4年前 , 8F
、刪除，也適合複雜、難以規約的圖
01/18 23:06, 8F
→
01/18 23:06, 4年前 , 9F
向量圖希望把圖規約成幾何圖形，畫成沒有誤差之後就不去
01/18 23:06, 9F
→
01/18 23:06, 4年前 , 10F
動它，適合商標、圖示之類不會變、簡約、有組織的圖
01/18 23:06, 10F
→
01/18 23:06, 4年前 , 11F
如果你想要用函數式做 UI/UX 的話，你可能須要把人的習慣
01/18 23:06, 11F
→
01/18 23:06, 4年前 , 12F
、覺得方不方便、喜好，背後的原因都找出來用程式建模，
01/18 23:06, 12F
→
01/18 23:06, 4年前 , 13F
否則程式會變超亂超難懂，就像硬要把照片轉成 svg 一樣，
01/18 23:06, 13F
→
01/18 23:06, 4年前 , 14F
裡面的向量根本看不懂，也失去了函數式萬物皆有道理的初
01/18 23:06, 14F
→
01/18 23:06, 4年前 , 15F
衷
01/18 23:06, 15F
→
01/18 23:06, 4年前 , 16F
可能你常常會覺得程式裡某個片段或某部分用函數式很適合
01/18 23:06, 16F
→
01/18 23:06, 4年前 , 17F
，但這不代表整個程式都適合規約成函數式
01/18 23:06, 17F
推
01/19 00:52, 4年前 , 18F
現在 UI 走 functional 是顯學吧 約束簡化狀態改變的
01/19 00:52, 18F
→
01/19 00:54, 4年前 , 19F
度 是在 UI 這種容易有複雜狀態共享中很需要的一件事
01/19 00:54, 19F
推
01/19 00:56, 4年前 , 20F
^複雜
01/19 00:56, 20F
推
01/19 01:53, 4年前 , 21F
先分成用函數式建立 framework，和用函數式使用 framewor
01/19 01:53, 21F
→
01/19 01:53, 4年前 , 22F
k，我想原 Po 問的是後者
01/19 01:53, 22F
→
01/19 01:53, 4年前 , 23F
函數式建立框架就像圖片邊界用向量表示，或許很適合，但
01/19 01:53, 23F
→
01/19 01:53, 4年前 , 24F
不代表邊界以外的部分也適合用向量
01/19 01:53, 24F
→
01/19 01:53, 4年前 , 25F
而且，目前只是發現函數式的某些特性有利於設計 UI 框架
01/19 01:53, 25F
→
01/19 01:53, 4年前 , 26F
而已，不是整個 functional 都適合 UI
01/19 01:53, 26F
→
01/19 01:53, 4年前 , 27F
舉個例子，目前的函數式語言普遍不承認 subtyping 就是一
01/19 01:53, 27F
→
01/19 01:53, 4年前 , 28F
個造成難以真正使用純函數式設計 UI 框架的原因
01/19 01:53, 28F
→
01/19 01:53, 4年前 , 29F
像 Rust 就是因為不承認 subtyping，所以雖然它也很函數
01/19 01:53, 29F
→
01/19 01:53, 4年前 , 30F
式，但是到現在也還沒有堪用的 UI framework（這個問題已
01/19 01:53, 30F
→
01/19 01:53, 4年前 , 31F
經被討論過很久了）
01/19 01:53, 31F
→
01/19 01:53, 4年前 , 32F
更何況是 elm 這種純函數式的語言，而且還是使用框架而
01/19 01:53, 32F
→
01/19 01:53, 4年前 , 33F
不是建立框架
01/19 01:53, 33F
推
01/19 14:03, 4年前 , 34F
https://www.noredink.com/ 語言作者工作的公司，都是用
01/19 14:03, 34F
→
01/19 14:04, 4年前 , 35F
elm 開發完成前端，看不出來不適合在哪裡
01/19 14:04, 35F
推
01/19 14:08, 4年前 , 36F
http://builtwithelm.co/ 有更多使用的網站
01/19 14:08, 36F
推
01/19 14:14, 4年前 , 37F
作者講端框架的趨同演化
01/19 14:14, 37F
→
01/19 14:14, 4年前 , 38F
*前端框架
01/19 14:14, 38F
推
01/19 23:09, 4年前 , 39F
我已經把問題跟你講了，也告訴你有 subtyping 的語言比
01/19 23:09, 39F
→
01/19 23:09, 4年前 , 40F
較適合，要不要用就你的問題啦
01/19 23:09, 40F
→
01/19 23:09, 4年前 , 41F
（補充一下，如果不要 subtyping，那就要有 dependent ty
01/19 23:09, 41F
→
01/19 23:09, 4年前 , 42F
pes 以及一個很好的模組系統，但這樣也不會比較簡單就是
01/19 23:09, 42F
→
01/19 23:09, 4年前 , 43F
了
01/19 23:09, 43F
→
01/19 23:09, 4年前 , 44F
再隨便舉個例子，關於作者的 talk，你有沒有發現 div、bu
01/19 23:09, 44F
→
01/19 23:09, 4年前 , 45F
tton 等等都是函數，不是建構子？
01/19 23:09, 45F
→
01/19 23:09, 4年前 , 46F
這意味著什麼？他把函數當作降階的 GADT 來用，為什麼不
01/19 23:09, 46F
→
01/19 23:09, 4年前 , 47F
用真正 type safe、immutable、it compiles it runs 的 G
01/19 23:09, 47F
→
01/19 23:09, 4年前 , 48F
ADT 呢？因為沒有 subtyping
01/19 23:09, 48F
→
01/19 23:09, 4年前 , 49F
要是你不認為這些問題是問題，那就當作是沒問題吧...
01/19 23:09, 49F
→
01/21 00:33, 4年前 , 50F
functional GUI 的一種做法是將 input 看成 steam ，然後
01/21 00:33, 50F
→
01/21 00:34, 4年前 , 51F
把 UI 和使用者行為設計成方便組合的樣子，好把 input
01/21 00:34, 51F
→
01/21 00:35, 4年前 , 52F
轉換成每個 frame 該畫的畫面，好奇這種做法也必須要倚靠
01/21 00:35, 52F
→
01/21 00:35, 4年前 , 53F
subtyping 嗎？
01/21 00:35, 53F
→
01/21 12:06, 4年前 , 54F
生態差太多了，要做認真的產品再考慮考慮吧。玩玩就沒差囉
01/21 12:06, 54F
→
01/21 12:07, 4年前 , 55F
用 elm, purescript 等語言去開發就是種浪漫而已～
01/21 12:07, 55F
推
01/25 08:36, 4年前 , 56F
一樣啊，除非你的 UI 元件種類是固定寫死的
01/25 08:36, 56F
→
01/25 08:36, 4年前 , 57F
問題是出在 modeling input，要兼顧 ad-hoc、type safty
01/25 08:36, 57F
→
01/25 08:36, 4年前 , 58F
和 decidability
01/25 08:36, 58F
→
01/25 08:36, 4年前 , 59F
如果須要的 types 都用某些未知方法生出來了，那你講的東
01/25 08:36, 59F
→
01/25 08:36, 4年前 , 60F
西就是 obvious 沒錯
01/25 08:36, 60F
‣ 更多 qitisland 的文章
文章代碼(AID): #1U8ee-fg (Soft_Job)