Re: [問題] 有沒有人可以分享一下幾個技術沒落的原 …
※ 引述《manlike ( )》之銘言：
: ※ 引述《GGGGGforever (五雞大俠)》之銘言：
: RMI 第一次看到覺得還蠻酷的
: 現在來看確實是還蠻落伍的 缺點蠻多的
: 1. 太複雜
: 2. 非標準
: 3. 安全性
: 4. 很少用
: 5. 難維護
: 6. 太封閉
: 7. ......
: 隨便想都一大堆缺點
: 最重要的是現今有許多更好的替代技術
: 如果把 RMI 用來做 IPC 的用途，
: Linux 上有 D-Bus 是系統通用的介面，
: 可以支援用多種語言實做，互相透過介面呼叫，
: 而且應該比較簡單，雖然也有點複雜，
: 也算是 Linux 上一個系統層級的標準。
: Windows 的話不熟，不過應該也有才是。
上面的沒研究沒什麼意見。
: 如果是當作 RPC 的用途
: 以 web service 或 web 2.0 的角度來看
這兩個都可以說是已經過氣的舊名詞了，
扣掉 web 2.0 這個純口號的名詞，web service 當初的願景現在看看剩多少，
還有許多有趣的老東西像是 soap等，也是有一堆人在砲轟太難搞，
再經過幾年的洗禮後不知道還剩什麼評價。
: 就是要能讓開發者輕易的使用任一語言開發
: 有共同的標準，使用者也能輕易存取，
web service 的目的比較接近是把資料層跟資料操作抽象化，
與其說是要輕易使用任一語言開發，倒不如說是他想跳脫語言的層次。
: AJAX 和 REST 技術就符合這些特性
: AJAX: HTML, Javascript 和 CSS 都是標準，而且大家很熟，使用者也很常用。
這裡有一個華麗的名詞陷阱， ajax 本身並不符合你說的這些，
基本上他只是一個行為，就算你要把廣義的 javascript 都列進來，
那也不算是所謂的有共同的標準跟能輕易存取。
事實上，你看看瀏覽器戰爭現在打得這麼激烈，
許多該 support 的東西都還在拼命奮戰，
要說輕易存取實在是太看得起web了。
至於標準，如果你不算入那些各家實做的奇奇怪怪的鬼東西跟鬼規格，
那的確是蠻標準的，不過現在好像已經很少看到這麼「標準」的網站了。
至於大家都熟這更是一個有趣的.......呵呵
為了一個好的使用者體驗，有一些部份寫 web 的人，
可是費盡千辛萬苦在搞一些鬼東西。
: REST: XML 和 HTTP 也都是標準，而且大家很熟，使用者也很常用。
: 對開發者而言，這些都是再熟悉不過的技術，開發容易，而且是真正跨平台且開放。
: RMI 就只能用 Java，也很複雜，使用者還要裝JRE，也非標準而且封閉，
: 如果你是要做封閉的系統才會考慮用 RMI 吧？？？
: 只是封閉的系統擔然最後就是落伍然後被淘汰...
這裡也是名詞陷阱， REST 本質上是一種伺服器服務的「風格」。
他主要的實做方式捨棄大多數原本透過 XML like 的格式的描述資料，
而規範一致性的 url ，透過特定的 Http method ，來達到他的目的。
其實真的熟 Http method 的人我想並不多，
POST 跟 GET 知道的人應該很多， PUT/DELETE 我想會用到的人應該很少；
REST 多是綁在特定的需求或者特定的技術上，
像是我之前在玩的 RoR 就是 RESTful 的
事實上，拿這個跟 RMI 比是蠻奇怪的。
而且 REST 跟 RPC 並沒有完全的交集，他們是不是能劃上還有爭議。
: : 當然, 現在應該是沒有人在開發系統時會使用它們了, 算是書中失落的80頁
: : Joel on Software 一書裡也說到他從2000年初就不看好 RMI 技術.....
: : 除了這兩個技術外,
: : mmdays也曾在部落格的文章中說到 EJB 的架構被認為是失敗的
: : 使用POJO更好....
: : 當然這些都是聽別人說的
: : 所以有沒有人能更明確得稍微分析一下這幾個技術衰敗的原因呢？
: : 如果有參考資料更好, 謝謝囉^^
不過其實我覺得沒有什麼技術是真的好或不好啦，
你深入去玩過一些東西，瞭解過一些東西。
你就會發現軟體的世界呈現著一種演變的趨勢。
有些老東西雖然用現在的眼光看起來是爛的，
但是在當年那個時代可是個創舉。
就像是 java 早期以物件導向為口號，現在到處都物件導向的語言，
更有標榜「純」物件導向（ex Ruby）的語言，
有些東西其實在過時或者被取代的背後，都是一個大膽創新的嘗試。
就像是我幾年前有一度為了 web 投身 applet 的世界，
玩了幾個月的 applet ，雖然後來發現 applet 是個沒落的老東西；
但是你會發現 applet 相對於他的時空背景，仍然是個好東西；
有過 applet 經驗，對於日後我操作 swing ，
甚至是我去玩 javascript 時，有蠻多東西都還是可以對照著看。
有許多各式各樣的技術曾經被視為是失敗的，就像 javascript，
其實在 2005迄今有許多人都認為這是一個失敗的語言，
因為語言方面他的確有一部分的缺陷，但是基於環境的條件跟歷史因素，
他仍然是存活而且有趣的，並隨著規格的演變跟各式的實做在強大著。
有些事情實在是很難講。
java 體系當然也有許多老東西是個好嘗試，但是並不好用的東西。
比方說 swing 系列有許多在設計架構上非常有理想，
但是實際上用起來非常難用的東西。（我個人對JTable有揮之不去的夢魘 XD）
EJB 的歷史直接看 wiki 比較快
http://zh.wikipedia.org/zh-tw/EJB
基本上還是老話一句，
這些是在過去還沒有選擇時，人們所踏出大膽的那一步，
每個東西被創立出來都一定有他想要解決得問題，
而絕大多數的時候是當做完之後，問題演化變成新的面貌，
所以我們用新的工具去處理。
就像是以前我們很多功能直覺就是寫 application 來得安全簡單可靠，
現在卻會努力搬到 web 為了 portable 特性，
因為我們意識到使用者不會想要隨時帶著一個安裝檔，
他想到簡單的有個瀏覽器舊能用，這就是需求的演化。
如果要因此覺得 EJB 這個東西就是個笨東西，那也只是個結果論；
事實上 EJB 也曾經在他的世代中紅極一時，
或許有些日後被軟體工程師唾棄的東西，在我們現在卻是視之為真理呢。
還有蠻多東西其實也都還是在進化中，像是這 JSF ，
一些有趣的第三方 Framework 更能看出這些差異。
以前在玩的 webwork ，後來也跟 Struts2 併一起，
樣貌也跟以前有很大的差異了。
還有一些比較屬於是環境的演化，
像是以前有一陣子我們很愛用 xml 當config，
但是 annotation 出來跟用過之後，回去用 hibernate 時叫我寫 hbm ？
拿把刀殺了我比較快吧～～
所以其實很多時候這些演化是因為
1.發現問題應該再被分解成更小單位
2.因為用了之後發現有更好的方法
3.發現這個需求不存在，或者是這個問題根本是無解。
其實這都是無數前人踩在前面創下的路呀。:p
--
我：一半的日子讓你說，我聽你說你的所有______________________________________
______________________________________一半的日子我想說，對你說過去的所有：我
_______________________________________________________
在討論中妥善扮演兼具聆聽與分享的角色，是我們一生的課題。
_______________________________________________________
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 111.82.21.118
推
10/04 22:58, , 1F
10/04 22:58, 1F
→
10/04 22:59, , 2F
10/04 22:59, 2F
推
10/05 00:02, , 3F
10/05 00:02, 3F
→
10/05 02:54, , 4F
10/05 02:54, 4F
推
10/05 12:07, , 5F
10/05 12:07, 5F
推
10/09 11:15, , 6F
10/09 11:15, 6F
→
10/09 11:17, , 7F
10/09 11:17, 7F
→
10/18 22:00, , 8F
10/18 22:00, 8F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 2 篇)：