บริษัทวิจัย RedMonk รายงานว่าแนวโน้มการพัฒนาโปรแกรมบนลินุกซ์ มีโปรแกรมที่เขียนด้วย Mono มากขึ้น ตัวอย่างโปรแกรมดังๆ เช่น Banshee โปรแกรมฟังเพลง, Tomboy โปรแกรมจดโน้ต และ GNOME Do โปรแกรมค้นหาและสั่งงานเดสก์ท็อป ในขณะที่มีโปรแกรมที่พัฒนาด้วย Java และได้รับความนิยมใกล้เคียงกันน้อยมาก
Ian Murdock ผู้ก่อตั้งโครงการ Debian และขณะนี้ทำงานอยู่กับซัน ไม่เห็นด้วยกับ RedMonk และบอกว่าคนใช้ Mono นอกวงลินุกซ์มีน้อยมาก และโปรแกรม Mono ที่ดังๆ ถูกพัฒนาขึ้นโดย Novell (ซึ่งเป็นเจ้าของ Mono) ดังนั้นไม่สามารถสรุปว่า Mono ได้รับความนิยมมากกว่า Java ได้
แต่ทางเว็บไซต์ SD Times ที่มาของข่าวนี้ได้สำรวจความเห็นจากนักพัฒนา และได้ผลเกือบเอกฉันท์ว่า Mono ดึงดูดนักพัฒนาได้มากกว่า Java
เหตุผลที่ทำให้ Java บนลินุกซ์ได้รับความนิยมน้อย ได้แก่ JRE แบบ 64 บิตบนลินุกซ์ไม่สมบูรณ์ มีบั๊กมากมาย, ปัญหาสัญญาอนุญาตของ JDK ที่ก่อนหน้านี้ไม่เป็นโอเพนซอร์สเต็มที่ และทำเป็นแพกเกจรวมไปกับดิสโทรได้ยาก, ดิสโทรบางรายอย่าง Debian รวมเอา Eclipse เวอร์ชันเก่า (3.1) ซึ่งมีฟีเจอร์น้อยมาก เมื่อเทียบกับ MonoDevelop ซึ่งเป็น IDE ของฝั่ง Mono
ที่มา - SD Times
Comments
ข่าวดีในรอบปีเลยครับ
แต่เซ็ง Win.Forms ยังไม่อาจจะได้ 100%
ข่าวดี
โดยส่วนตัวแต่ก่อนชอบ Java มาก แต่ตอนนี้หลังจากลูบๆ คลำๆ .Net มาซักพัก ก็รู้สึกชอบและเทใจไปทาง .Net มากกว่า คงเพราะหลังๆ รู้สึกว่าทางฝั่ง Java ไม่ได้เพิ่มอะไรเจ๋งๆ ออกมาเท่าไหร่เลย (อันนี้พูดในมุม Windows นะ ผมไม่เคยพัฒนาแอพฯ บน Linux เลย ..Mono ยังไม่เคยลูบคลำ)
จะบอกว่า Java ลดลงเรื่อยๆ!?!
Java กำลังจะตาย!?!
ลักษณะงานในไทยล่ะ Java เพิ่มขึ้นหรือลดลง!?!
ปล. เอาระเบิดมาลงแล้วก็หนี อิอิ
ไม่มีอะไรหรอก แค่ใส่ๆให้มันมี sig เหมือนชาวบ้านเค้ามั่ง
บอกว่าบนลินุกซ์ Mono ฮิตกว่า Java ครับ ส่วนหนึ่งคงเป็นเพราะ Novell สนับสนุนโปรแกรมสาย GNOME ทำให้มีโปรแกรมที่เขียนด้วย Mono สายนี้หลายตัว และเมื่อ GNOME ถูกเลือกโดย Ubuntu ยิ่งทำให้โปรแกรมเหล่านี้กระจายตัวออกไปมากขึ้น
Java เคย "ถูกพิจารณา" ใช้งานก่อน Mono หลายปี แต่ซันเปิดซอร์สช้าเองเลยพลาดโอกาสตรงนี้ไป
ผมกลับมองว่า ตลาดของ Java ไม่ใช่ Desktop application นะครับ น่าจะเป็นด้าน Web-Application ขนาด Enterprise มากกว่า
End your suck life, end microSuck.
ในทางกลับกันก็มองได้ว่า .Net/Mono เหมาะกับ Desktop Application เพราะงั้นจากนี้ไป User ทั้ง Windows Linux และ MacOS ควรจะหันมาลง .Net/Mono มากกว่า Java และัผู้พัฒนา Desktop App ก็ควรศึกษา C# เป็นหลัก สินะครับ
ในทางต่อไป ก็มองได้ว่า ฐานโปรแกรมเมอร์ที่เป็น .Net/Mono จะเยอะขึ้น ต่อไปโปรแกรมแนว Widget เลกๆ ทำเล่นใช้เอง หรือโปรเจคที่ทำตอนเรียน พวกนี้จะเปน Desktop Application ทั้งนั้น มองต่อไปถึงพวก RIA อีก
พอ cloud และ mash-up เกิดเตมตัว แค่ทำ UI เรียก service คนอื่น ก็ apply ได้อีกแยะ ยิ่งพอ input มีมากกว่า key-point-click-drag และ output ก็มีหลาย media และ dynamic.. แค่ทำ UI ก็คิดหนักแล้ว
เรียกว่าส่วน UI ของ Java จะเหลือแค่กลุ่ม HTML/AJAX/CSS-based คำถามต่อไป แล้ว UI กลุ่มนี้ .. .Net/Mono หรือ Java ใช้ง่ายกว่ากัน ถ้าตอบ .Net/Mono ก็สรุปว่าอีกหน่อย Jnr Dev ที่มีพื้น Java ไม่เหลือ
คำถามต่อไปคือ แล้วส่วน Middle-tier ที่ปกติให้ทำโดย Snr Dev ล่ะ จะใช้อะไร.. จะยังใช้ Java เพราะอะไรบ้าง(ไม่รู้?) ที่แน่ๆ ต้องเริ่มหัดใหม่ จะบอกว่าต้องใช้ Java เพราะของเก่าเปน Java.. ก็ท่าจะชะรอย COBOL? ซึ่งหากค่าแรงต่างกันมากขึ้นเรื่อยๆ .Net/Mono ก็จะน่าสนมากขึ้นๆ เช่นกัน
ยิ่งปีหน้า Dublin มา ความสามารถส่วน Middle-tier ก็จะลดลงเรื่อยๆ และถ้าโปรเจคแนว IKVM.NET เกิดฮิต ปัญหา interop ก็จะลดลงไปอีก จิงๆ เหน commercial .net/java-bridge ออกมาหลายตัวแล้วด้วย แน่นอนว่า Dublin อาจยังไม่เจ๋งเท่าไร แต่ MS ก็คงไม่หยุดแค่นั้นเช่นกัน
ยังไม่รวมว่า ตอนนี้ .Net/Mono ลุย functional/script เตมสูบแล้ว ขนาด PHP ก็ยังเจอชิมลางด้วย phalanger กะ expression แล้วเลย พื้นที่ของ Java หดลงทุกทีๆ .. Java จะรักษาที่มั่นและรุกกลับยังไงหนอ หรือจะไปอยู่แบบ c/c++ ก็คงยาก สุดท้ายอาจชะรอย COBOL ไปจริงๆ :(
การโต้กลับเหรอ
นับรวมกับฐาน developer ที่มีจำนวนไม่น้อยทีเดียว... งานนี้ึคงยังไม่ชะรอย COBOL ไปง่ายๆ หรอกครับ หึหึ
ใช้ grails อยู่เช่นกัน...
...ตอนนี้เปลี่ยนจากใช้ .net มาใช้ grails แทนแล้วครับ.
Grails และ Groovy นี่ แนวคิดเยี่ยมมากเลยนะครับ เรียกว่าแฟนพันธุ์แท้ Java ยังมีหวังนะครับ
อย่าลืม scala อีกตัวครับ
ใช้ Coolite หรือยังครับ แล้วจะหวนกลับมาแตะ .NET อีกครั้ง งานนี้ Web base แต่ต้องยุ่งกับ delegate เยอะเหมือนเขียน desktop application
Java FX <= ช่วยแนะนำ Designer & Media Tool ที ถ้าไม่มีเจ๋งๆ มีหวังดับ ส่วน Flash เรื่องนี้สบาย Tool ด้านนี้จุดแข็งของ Adobe อยู่แล้ว แต่ Silverlight ก็ยังพอมี Expession มาช่วยชีวิตเอาไว้ได้
Groovy กะ Seam .. .NET ห่างจิงๆ frameworks ตามลิสต์นี้มี .NET นิดเดียวเอง http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
แต่ .NET พึ่งจะลง Dynamic Language เตมตัวกับ .NET 4 (ยังไม่ออกตัวจริงเลย) พวก frameworks ทั้งหลาย ไว้มาเทียบดูอีกที หลังจากที่ .NET 4 ออกซักพักแล้วดีกว่า
[Edited : มันซ้ำ]
ผมกลับมองอีกด้านนึงคือ
Desktop Application กำลังจะตาย เพราะ Desktop Application มีข้อจำกัดคือ ข้อมูลฝังอยู่ที่เครื่องๆเดียว ไม่ได้ส่งผ่าน network ได้แต่อนาคต แบนวิดบนอากาศจะมหาศาล และสิ่งที่จะมาคือ Cloud Computing และ Cloud OS ซึ่ง Google เป็นโต้โผใหญ่ และค่อยๆกัดเซาะฐานของ Microsoft ไปเรื่อยๆ (เช่นการออก Chrome OS)
การมาถึงของ Cloud Computing นั้นได้รับการเกื้อหนุนอย่างดีจาก SOA จะทำให้ Application แบบ Server-side ที่มีการทำ Clustering เติบโตมากมายนักเพราะความเสถียรส่วนใหญ่อยู่ที่ Server ส่วน .NET ที่มีต้นทุนในการทำ Clustering สูงจะเดินเข้าสู่จุดอัป
ส่วน Client นั้นจะถูกย้ายไปอยู่บนมือถือหรือ device ที่เล็กลงเช่น netbook ซึ่ง Java เองก็เหมือนไปเกิดใหม่ในการ coding android
สุดท้ายแล้วการยอมให้เกิด mono ขึ้นอาจจะเป็นการยอมลดศักดิ์ศรีของ microsoft เพื่อหาทางออกให้กับตนเองในอนาคต ที่ผู้คนเลิกต้องการ proprietary application แต่ก็ไม่แน่ว่าจะอยู่รอดเสมอไป เพราะ microsoft นั้นไม่เก่งเรื่อง error และ exception handler จึงทำให้ programming language ของตนนั้นขาดความเสถียรอย่างร้ายแรง
Zealot ปร่ะนี่ ฮ่าๆ
End your suck life, end microSuck.
Desktop Application != Stand-alone Application
ไมโครซอฟท์เองก็ออกของจำพวก RIA มาให้อยู่แล้วนี่ครับ นับว่าเป็นเจ้าต้นๆเลยด้วยซ้ำ
onedd.net
onedd.net
ส่วน .NET ที่มีต้นทุนในการทำ Clustering สูง <<< มีเหตุผลอะไรเหรอครับ???
.Net สามารถทำได้ทั้ง Client Side และ Server Side ครับ การที่ Mono ลง Linux ทำให้เราเขียนโปรแกรม Server บน .Net ได้ ซึ่งผมพูดตรงๆว่าง่ายกว่าเขียนด้วย C++ เป็นพันเท่า
Desktop App นี่แหละครับ ตัวทำ Network ที่แจ่มกว่า Web App ดูอย่างเกมออนไลน์ก็ได้
และ Microsoft มีแผนจะทำ Windows Server Cloud ด้วยครับ แน่นอนว่าสนับสนุน .Net และผมเชื่อว่า Linux สาย Debian กับ Fedora ที่ติด Mono ก็ต้องมีแผนจะทำ Server Cloud ติด Mono แหงๆ
.Net เกิดทีหลัง Java เพราะงั้นมันก็มีฟีเจอร์เยอะแยะที่ Java ไม่มีและไม่ยอมทำ ซึ่งตอบโจทย์ความง่ายและประสิทธิภาพในการพัฒนา Application ได้มาก (ขนาดที่ใช้เขียนเกมลงเครื่อง Console Next-Gen ได้)
พูดต่อไปจะกลายเป็น Zealot ซะเปล่าๆ... เอาเป็นว่า ผมว่ามันไม่มีสาเหตุอะไรเลยที่ Desktop App กำัลังจะตาย
และที่สำคัญคือ ผมว่า .Net/Mono สู้จาว่าได้ทุกที่นั่นแหละ ไม่ว่ามันจะไปไหนก็เหอะ ที่ๆสู้ไม่ได้อาจจะเป็นที่มือถือ ซึ่งก็คงโดน Android เซาะกันไป
ดีไม่ดีที่จะโดน Google กินเรียบ อาจจะไม่ใช่ Microsoft Windows และ .Net/Mono
แต่เป็น Apple MacOS และ Java แทน ก็ได้ :P
ถ้าจะทำ cluster ก็ต้องมีเครื่องจำนวนมาก
ถ้าเครื่องจำนวนมากก็มีปัญหาเรื่องค่า license ของเครื่องอีก ตรงนี้ open source ได้เปรียบสุดๆครับ
onedd.net
onedd.net
มันต้องมี license สำหรับ Cluster โดยเฉพาะอยู่แล้วครับ
อย่างกะใช้ Red Hat ไม่ต้องมี license สำหรับเมนเทแนนซ์งั้นแหละ - -a
อีกอย่าง ตอนนี้เรากำลังพูดถึง Mono ที่กำลังเป็นตัวแทน .Net ใน Linux ตัว Mono ก็ OpenSource ขอให้นับรวมด้วยนะครับว่ามันก็ฟรีเหมือน Java
เราใช้ Fedora ทำ cluster ได้นี่ครับ
อันนี้คิดว่าถ้าเราจะเอาไป deploy ลง windows แต่ถ้าลง Mono เลยก็ไม่น่ามีปัญหาเรื่องค่า license ครับ
onedd.net
onedd.net
ใช่ครับ NPACI Rocks ครับ รัน CentOS เป็นฐาน (ก็ RedHat ดีๆนี่เอง) แทบจะเป็น de facto ของ opensource ของ Linux cluster ไปแล้ว ฟรีแล้วก็ติดตั้งง่ายมากๆ
หากกล่าวถึง license ของ Windows Clusters มันมีแบบราคาถูกนะครับ แต่มีมาเป็นหลินฮุ่ย เอ่ย! ... มีเป็นช่วงๆน่ะครับ ประมาณ 8 เหรียญต่อโหนด
My Blog / hi5 / Facebook / Follow me
My Blog
น่านดิ เข้าใกล้ Zealot เละ หุๆ
หยุด หยุด ... ดีกว่า :P
แต่ก็ขอบคุณนะครับที่ช่วยแสดงความคิดเห็นกับคอมเม้นท์ผม แต่ถึงภาษาอะไรจะมาหรือไปก็แล้วแต่ บนโลกอนาคตที่ SOA เป็นหลัก ภาษาก็จะกลายเป็นแค่ Tools ที่ซึ่งทุกๆ platform แลกเปลี่ยนข้อมูลกันได้ด้วย XML เพราะฉนั้นเราคงไม่ถูกจำกัดด้วยภาษา เรื่องไหนภาษาไหนเก่งก็เขียนด้วยภาษานั้น แล้วถ้าจะทำอีกเรื่องที่ใช้อีกภาษาก็ใช้ XML เข้าหากัน นั้นคือ solution ของอนาคต
End your suck life, end microSuck.
แต่แอบรุสึกว่า exception handler ใน .NET ใช้ง่ายกว่าแหะ .. หรือคิดไปเอง??
ปล. "Java เองก็เหมือนไปเกิดใหม่ในการ coding android" <== เหมือนจะผ่าเหล่า? เหน Java แบบ android แล้วนึกถึง J++/J# .. ดูคล้าย Java แต่จิงๆ ไม่ใช่เลย
จริงรึุ??
เอาละสิ SUN จะดีดดื้นอะไรอีกรึเปล่านะ :P
ที่ว่ามันผ่าเหล่า ก้อเพราะ code java ทั่วไป กะ code android อาจเอามาใช้ด้วยกันปุ้บปั้บไม่ได้ ซึ่งไม่ใช่ sense ของ java .. code ส่วนใหญ่อาจจะใช้ได้เลย แต่ก้อมีหลายจุดที่ต้องแก้ก่อน
Java สำหรับ Android มัน copy หลักการมาจาก SWT ครับ เขียนเหมือนกันเด๊ะเลย จริง ๆ แล้ว SWT ผมชอบมากกว่า .NET อีก แต่ไม่ค่อยมีบริษัทไทยรับ เลยไม่ได้หัดใช้ต่อละ
ทั้งชีวิตเคยรัน Java Applet ผ่านแค่สองสามตัวเองครับ (อาจจะเพราะผมรันบนเครื่อง 450MHz ด้วย เครื่อง 1.5GHz ยังไม่เคยลอง)
[ JIRAYU.INFO ]
เหรอ
ผมใช้ C ธรรมดาๆ เลยอ่ะ ??
I'm a DS Lover ^^
:: DigiKin8 ::
เห็นทีต้องเปลี่ยนชื่อเป็น monoboom แล้วสิ
My Blog / hi5 / Facebook / Follow me
My Blog
lol
<mOkin>ไม่รู้โลกกว้างไป หรือใจฉันแคบลง<mOkin/>
ฮ่าๆ
Priesdelly Blog
จาวายังมีโอกาส แต่โอกาสเหลือน้อยลงทุกที
Mono ดังมากจริงๆ การที่สามารถเขียน .Net ไปรันบน linux ได้นี่ ประโยชน์มันมหาศาลจริงๆ ครับ เหมือนสโลแกนของ Java ที่ว่า Write once, run anywhere น่ะแหละ
my android-blog
.Net ออกมาตั้งหลายปีแล้ว ถ้าจะ Write once, run anywhere ด้วย Mono ทำไมเพิ่งทำเอ่ย? ติ๊กต่อกๆ
\(@^_^@)/
M R T O M Y U M
ผมว่า .NET นี่ไม่ได้ชู WORM สักเท่าใหร่เลยนะครับ (แม้จะทำได้ในทางทฤษฎี) เพราะตัว API หลายอย่างก็ผูกกับวินโดวส์ Mono นี่ทำแยกเพิ่งเสร็จมาไม่นาน และก็ไม่ได้ชู WORM เท่าใหร่อีกเหมือนกัน มันอาจจะข้ามดิสโทรง่ายกว่าเดิมบ้าง แต่ก็ไม่ได้มีอะไรวิจิตรไปมากกว่านั้น
จุดที่แย่ที่สุดสำหรับจาวาในความคิดผมคือการไปโชว์เรื่อง WORM แล้วทำไม่ได้จริงนี่ล่ะครับ โดยเฉพาะ Applet กับ J2ME (เรื่องกินแรมนี่ให้อภัยกันได้ แรมมันถูก...)
LewCPE
lewcpe.com, @wasonliw
.Net กับ Mono ไม่ได้คิดจะทำ Write once,run anywhere แต่แรกแล้วครับ ที่ไมโครซอฟท์ตั้งใจทำก็แค่ Write once, run somewhere (อย่าง XBox และ Zune กับ Windows Mobile)
หลักๆแล้ว Mono ก็แค่ทำให้ Write once,Compile anywhere,then run there เท่านั้นเอง
ซึ่งสำหรับผมว่าก็พอแล้วนะ
ของ java ที่ว่า Write once, run anywhere มันมาเป็นจริงกับ Android ครับ ส่วนที่ Sun ทำมัน Write once, fix bug anywhere
ยอมติด java เพราะต้องใช้ eclipse, OpenOffice.org นี่แหละ ทำเว็บเดี๋ยวนี้หันมาใช้ .NET แทนแล้ว เครื่องมือที่เขาปล่อยให้ใช้ฟรี ก็พอใช้ได้
ผมใช้ Visual Foxpro ทำงานและตอบสนองความต้องการได้ดีเยี่ยม ลองใช้ VB, Delphi แล้วไม่เวิร์ค เมื่อก่อนนำ AS400 เข้ามาปรากฏว่าไปไม่ถึงฝั่งต้องกลับมาใช้ฟอกซ์เหมือนเดิม
ที่ทำงานเก่าใช้เหมือนกันครับ ทำงานเร็วดีครับ.
+1 ผมเชียร์ขาดใจเหมือนกัน อะไรๆ ก็ง่ายขึ้นบนฟอกซ์
ชอบเหมือนกัน ...แก่แล้วนี่อิอิ แต่ไม่ได้พัฒนาด้วย FoxPro นานแล้วครับ จะยังมี Version ถัดไปไหมเนี่ย?
\(@^_^@)/
M R T O M Y U M
เอ แล้วใครอธิบายได้ไหมครับว่า mono ดีกว่า java ยังไง ฟังคอมเมนต์แล้วเหมือนห่างชั้นกันมากเหลือเกิน
ที่ผมคิดว่าชัดๆ น่าจะเป็นเรื่องการทำงานบนลินุกซ์นะครับ (ซึ่งก็เป็นที่มาของข่าวนี้) Mono ออกแบบมาบนลินุกซ์เป็นหลัก ในขณะที่จาวาไม่ใช่ ความเนียนในการ integrate เข้ากับส่วนอื่นๆ ของลินุกซ์เลยมากกว่ามาก เช่น พวก UI toolkit ที่ใช้ GTK+ โดยตรง (ผ่าน GTK#)
อย่างที่สองเป็นเพราะทีมทำ Mono เป็นทีมเดียวกับทีม GNOME เก่า เลยเข้าใจจุดตายว่าต้องสร้างโปรแกรมต้นแบบที่มีคุณค่า และยัดมันเข้าไปรวมกับ standard GNOME ให้ได้ (นั่นคือ Tomboy) เมื่อสร้างโปรแกรมที่ GNOME ปฎิเสธไม่ลง (ในแง่ฟีเจอร์แล้ว) ที่เหลือก็เจรจาเรื่อง license ให้ GNOME ยอมรับและผนวกเข้าไปกับ standard GNOME
ผมคิดว่าส่วนที่สองนี้สำคัญมาก เป็นการบอกนักพัฒนาอื่นๆ ที่ดีที่สุดว่า Mono พร้อมสำหรับใช้งานจริงแล้ว (พร้อมขนาดถูกรวมไปกับ GNOME/Ubuntu) และ Mono package ก็ถูกแจกจ่ายไปอย่างแพร่หลายพอสมควร
ซึ่งเรื่องพวกนี้ ฝั่งจาวาก็มี แต่ดันไปเลือกการรวมตัวเข้ากับ OOo (Wizard และ Base) ผลก็คือ โปรแกรมที่เป็น stand alone ไม่เห็นภาพตามเท่าไร เนื่องจากว่ามันอยู่ในจักรวาลของ OOo
จุดตายอีกอันที่ Mono ยังแก้ไม่ได้คือ โปรแกรมที่เขียนด้วย .NET ยังย้ายข้ามมารันบน Mono ได้ไม่สมบูรณ์นัก ในขณะที่จาวานั้น portable เต็มที่
ติดบางอย่างนี้พอเข้าใจครับ แต่รอดูต่อไปครับ ดูจาก Roadmap แล้วคงแก้ปัญหานี้ได้ไม่นานมากครับ
ใครบอก นานมาก ๆ เลยต่างหากล่ะ
ตอบแบบสาวก
1 .Net เร็วกว่าครับ
อันนี้เป็นกึ่งๆความเชื่อนะ คือตอนแรก .Net ออกมา ทำงานเร็วกว่า Java เยอะ จาว่าได้รับสมญาโคตรอืดมหากาฬอยู่แล้ว(ด้วยหลายๆสาเหตุ ทั้งระบบ การทำงาน บลาๆ) พอ .Net ออกมา ความเร็วแทบจะเท่ากับภาษา Native ก็เลยเป็นความเชื่อสืบต่อกันมา
ได้ข่าวว่า Java แก้เรื่องนี้แล้ว แต่ผมไม่แน่ใจว่าจริงมั้ย(และดูจากประวัติการทำงานของ SUN แล้ว ผมไม่เชื่อน้ำมนต์เรื่องนี้เลย)
2 C# ใหม่กว่า Java และ Microsoft กล้าทำโน่นทำนี่มากกว่า SUN
เลยทำให้มีฟีเจอร์ที่สนองความต้องการของยุคสมัยได้มากกว่า อย่างเช่น delegate และ enum กับ valuetype แล้วก็ generic และอื่นๆอีกมากมาย รวมถึงฟีเจอร์ที่ผมยังไม่เคยใช้ ซึ่งเพิ่มขึ้นทุกเวอร์ชั่น ในขณะที่ผมไม่ค่อยเห็น Java ลงมือเพิ่มอะไรเลย
3 IDE ดีกว่า เขียนง่ายกว่า
อันนี้เป็นจุดเด่นของ Microsoft เลยว่า ทำโปรแกรม IDE ออกมาได้แจ่มจริงๆ ผิดกับ Java ที่มี IDE เยอะแยะ แต่สู้ Microsoft Visual C# Express ไม่ได้ซักตัว
4 ภาษา C# เขียนง่ายกว่า
อันนี้เป็นความเห็นส่วนตัวครับ
5 และอื่นๆอีกมากมาย
Mono จะดังกว่านี้เมื่อถึงเดือนกันยายนปีนี้แหละครับ เพราะ Mono 2.6 จะออกมาให้ยลโฉมกัน มันสำคัญยังไงน่ะหรอ ก็คือ รองรับ ASP.NET 3.5 & Linq ที่เป็นการรวม DbLinq จากนักพัฒนา Google summer codes เข้าไว้ใน Mono SDK นั่นหมายความว่า Mono จะมี ORM แบบเดียวกับ Java ซะที ไม่ต้องใช้ NHibernate อีกต่อไป
ASP.NET 3.5 & Linq ไม่ได้รวมอยู่ใน ECMA 335 จึงไม่ครอบคลุมโดย Community Promise ของ Microsoft
ที่ว่าจะดังเนี่ย เพราะคนใน FOSS Community จะออกมาตีกันอีกหรือปล่าวครับ??
ผมมองว่า อยากให้เขาฟ้องตอนนี้เลยด้วยซ้ำ เอาขึ้นศาลเลย ความชัดเจนจะได้เกิด ว่าควรใช้หรือไม่ควรใช้ ไมโครซอฟต์ถนัดนักในการสร้างความคลุมเคลือ ความไม่แน่นอน แม้แต่ vb6 ยังเจอกันมาแล้ว เราก็ใช้ ๆ ไปแล้วรอเขาฟ้องมาไงล่ะ ไมโครซอฟต์จะกล้าไหมกับการสูญเสียนักพัฒนา .NET อย่างมหาศาลไป แล้วเปิดโอกาสให้ Android java รุกคืบคลานมาแทนที่
ถึงแม้กระแสเรื่อง Mono ตอนนี้ จะเย็นลงได้ด้วยการที่ Microsoft ออกมาประกาศ Community Promise ให้ C# กับตัว CLI แต่ผมเดาเอาเองว่าสุดท้ายแล้ว GNOME จะต้องพยายามพัฒนาทางเลือกทดแทนแล้วค่อยๆ หาทางผลัก App ที่พัฒนาด้วย C# ออก เพราะถ้าไม่อย่างงั้นบทสรุปของ GNOME มีความเป็นไปได้ว่าจะค่อยๆ ถูกทอดทิ้งจาก FOSS Community หรือไม่อีกทาง ก็ถูกครอบงำโดยอ้อมจาก Microsoft เหตุผลรองรับที่ทำให้คิดอย่างนั้นก็คือ ถ้าตามอ่านรายละเอียดหน่อยจะเห็นว่าสเป็ค ECMA 334/335 ที่ Microsoft ประกาศ Community Promise ไป แม้จะเป็นส่วนแกนใหญ่และ Library มาตรฐานส่วนหนึ่งแต่ไม่ใช่ทั้งหมด เพราะอย่างงั้นปัญหาก็ยังไม่หมดไป(ถ้าจำไม่ผิดรู้สึกว่า Banshee กับ F-Spot จะใช้ ADO.NET ที่ไม่ถูกรวมในข้อกำหนดด้วย) นอกจากนั้นรายละเอียดที่ Microsoft ระบุไว้ใน Community Promise คือจะไม่ดำเนินการทางกฏหมายกับ Implementation ที่พัฒนาตรงตามสเป็คของ ECMA 334/335 เป๊ะๆ เท่านั้น นั่นหมายความว่าถ้ามีการพัฒนาต่อยอดไปทางอื่น หรือเพิ่มเติมอะไรเข้าไปบ้าง ก็ไม่มีอะไรเป็นข้อยืนยันว่าจะไม่มีปัญหาในอนาคต และนั่นย่อมหมายถึงการถูกควบคุมทิศทางโดย Microsoft ไปโดยปริยาย
รวมความได้ว่า นิยายเรื่องนี้ ยังอีกยาว...
เริ่มมีแล้วด้วยครับ Vala กับ Genie
แต่ผมมีความเห็นอย่างนึงว่า
ต่อให้ถอด .Net ออกแล้วมีตัวอื่นเข้ามาแทนที่ ก็เป็นไปได้ว่าจะยังใช้ภาษา C# ทั้งหมด แค่พัฒนาตัว Library ออกไปคนละทาง
ซึ่งจริงๆก็มีทำแล้ว นอกเหนือไปจาก WinForm แล้ว ผมเห็น Mono ก็มีตัวอื่นให้ใช้(สองสามตัว ตัวนึงรู้สึกจะ GNome ผมไม่ชัวร์) และมีไลบรารี่เฉพาะบนลินุกซ์อีกสองสามตัว
ผมไม่คิดว่าไมโครซอฟท์จะบังคับว่า "ถ้าใช้ภาษา C# ต้องใช้กับ Library .Net ที่เป็นมาตรฐานเท่านั้น ต้องไม่มีส่วนเพิ่มเติมหรือส่วนต่างใดๆทั้งสิ้น!"(เหมือนบางเจ้า(ขอแอบกัดนิดนึง)) อย่างน้อยมันก็ไม่มีอยู่ในข้อกำหนดของภาษา C#
"เป็นไปได้ว่าจะยังใช้ภาษา C# ทั้งหมด แค่พัฒนาตัว Library ออกไปคนละทาง" ภาษา C# ที่ว่านี่ในความหมายไหนครับ? Syntax ของภาษา? ถ้าคำตอบคือใช่ คงต้องอธิบายว่า ถึงแม้อันที่จริงในสเป็คของ Microsoft จะมีการระบุถึงโครงสร้างและหลักการของตัวภาษา C# ไว้ด้วย(เป็นเหมือน Abstract ที่ระบุไว้ใน ECMA 334) แต่ในความเป็นจริงแล้วเรื่องโครงสร้างหรือ Syntax ของภาษาไม่น่าจะเป็นปัญหาสักเท่าไหร่ อย่าง Vala ที่ @mk ยกมานี่ Syntax ก็แทบจะเรียกได้ว่าถอดแบบ C# มาเลย(ขณะที่ C# เองก็ยกแนวคิดเรื่อง Syntax มาจาก Java ไม่น้อยเหมือนกัน) เพราะฉะนั้นประเด็นปัญหาก็วกกลับมาที่ตัว VM คือ Mono แต่หากจะบอกว่าถ้าเป็นปัญหานักก็ตัด Mono(.NET) ออกไปคงไว้แต่ตัวภาษา C# อย่างนั้นมันพูดแล้วดู Paradox อยู่บ้าง เพราะเคสของ Vala เองเราก็ไม่เรียกมันว่า C# ถูกมั้ย การพิจารณาตัวภาษาคงต้องมององค์รวมของมัน Syntax แบบนี้รันบน CLI เราก็เรียกมันว่า C# ส่วน Syntax คล้ายๆ กันแต่รันบน JVM เราก็เรียกมัน Java
ในกรณีที่ยกตัวอย่างว่ามี Solution อื่นแทน Win.Form มาอธิบายเรื่องการพัฒนา Library อื่นๆ ขึ้นมาทดแทน Library มาตรฐานของ .NET จริงๆ ต้องบอกว่าใน Context ของ GUI นี่มันอาจจะเทียบเคียงได้ไม่ชัดและอันที่จริงมันไม่ใช่จุดหนักใจของ Developer บนฝั่ง Linux เท่าไหร่ตั้งแต่แรก เพราะส่วนใหญ่ก็ใช้ GTK#(GTK+), Qyoto(Qt) กันอยู่แล้วมันให้อารมณ์ Native กว่า สาเหตุที่บอกว่าการยกเรื่อง GUI มาอธิบายเรื่อง Library นั้นมันยังไม่ชัดเจนเท่าไหร่ก็เพราะสิ่งที่ทั้ง GTK# และ Qyoto เป็นจริงๆ คือ Binding/Wrapper เท่านั้น ไม่สามารถเรียกได้ว่าเป็น Library ใหม่ที่พัฒนาบน Mono/.NET เต็มรูปแบบ ส่วนในประเด็นที่ว่าพัฒนา Library เพิ่มเติมจากส่วนมาตรฐานของ Microsoft ในอนาคตตามที่คุณ Thaina ว่า นั่นล่ะที่เป็นปัญหาที่แท้จริง เพราะคนที่พัฒนา Library ดังกล่าว อาจจะโดนดำเนินการตามกฏหมายได้ เมื่อเป็นอย่างนั้นจึงเป็นที่มาที่ไปของความเห็นที่เขียนไว้ก่อนหน้าคือ เลี่ยงไม่พ้นที่จะโดน ควบคุม/จำกัด แบบอ้อมๆ โดย Microsoft ซึ่งเป็นสิ่งที่ GNOME ไม่น่าจะยอมและคงจะพยายามสร้างทางเลือกอื่นๆ ให้กับนักพัฒนามากกว่า
ผมเองก็ไม่รู้ครับว่า Syntax Vala เป็นภาษา C# (หรือผมควรจะพูดว่า ใกล้เคียงภาษา C#?) ถ้าเป็นแบบนั้นจริงมันก็เป็นอย่างที่ผมคิดแหละครับ ว่าภาษา และรูปแบบการทำงานของภาษา(ที่ใช้ CLR แปลง IL เป็นโปรแกรมกึ่ง Native) มันคือภาษา C#
อย่างนึงคือผมเห็นว่า สำหรับ โปรแกรมเมอร์ Desktop App มักจะเลือกภาษาเดียว และมักจะไม่ยอมเปลี่ยนภาษาของตัวเอง เพราะฉะนั้น ถ้ามีการตั้งเป้าแล้วว่า ภาษาไหนจะเป็นมาตรฐานได้ ก็จะมีแรงจูงใจให้เริ่มศึกษาภาษานั้นๆ อย่างเมื่อก่อนนี้ C++ ก็เป็นภาษา "มาตรฐาน" สำหรับการเขียนโปรแกรม และมันบูมสุดๆ ทุกวันนี้คอมพิวเตอร์ทุกรูปแบบ ใช้ภาษา C++ เป็นหลัก
ผมกำลังคิดว่า ต่อไป ก็จะเป็น C# ที่จะได้เป็นภาษามาตรฐาน เวลาใครที่อยากจะเริ่มเขียนโปรแกรม ก็จะแนะนำไปเลยว่า C#
แล้วก็ เป็นไปได้จริงๆหรือที่ Microsoft จะสามารถฟ้อง Mono ได้ว่า มีการเพิ่มเติมไลบรารี่ สำหรับการสร้างสิ่งต่างๆแทนโมดูลมาตรฐาน
ถ้าอย่างนั้นจริง ถ้าสมมุติว่าผมเขียนโปรแกรมสร้าง Form ขึ้นมาใหม่ แทน Win.Form โดยมีรากฐานจาก namespace System ผมก็มีโอกาสถูกไมโครซอฟท์ฟ้องเมื่อไหร่ก็ได้? ไม่น่าจะเป็นอย่างนั้นนะครับ อย่างน้อย Microsoft ให้การรับรอง Mono กองใหญ่ และหลังจากนั้น หาก Mono จะเขียน Binding หรือ Wrapper ของตัวเองขึ้นมา โดยใช้ระบบของภาษา C# และโมดูลมาตรฐานรวมกัน
อธิบายลำบาก(ผมโง่) เอาง่ายๆคือ ผมเห็นว่าการที่ Mono จะเขียนอะไรเพิ่มเป็นโมดูลของตัวเอง มันไม่ต่างอะไรกับการเขียนโมดูลเพิ่มโดยโปรแกรมเมอร์อื่นๆที่ใช้ .Net ในโลกนี้ อาจจะมีซักคนนั่งเขียน MySelf.Forms แล้วเกิดดังขึ้นมา โดยไม่ได้ใช้ System.Windows.Forms แต่ใช้ System.Int32 System.Int64 หรืออื่นๆ ไมโครซอฟท์จะฟ้องโปรแกรมเมอร์คนนั้นได้หรือไม่? ผมคิดว่าไม่ครับ
ป.ล. ผมจำชื่อผิดจริงๆ ตั้งใจจะพูดว่า GTK ไม่ใช่ GNome
คำตอบคือ ต่อให้ Mono ไม่ได้พัฒนาอะไรเพิ่มจาก Standard ของ .NET เลยเหมือนปัจจุบัน อันที่จริงแล้ว Microsoft ก็สามารถที่จะดำเนินการทางกฏหมายกับ Mono ได้ และปัญหาในช่วงที่ผ่านมาก็คือ Microsoft ปล่อยให้เกิดสูญญากาศ ไม่แสดงท่าทีที่ชัดเจนว่าจะจัดการยังไงกับเรื่องนี้
ตอบแบบรวมๆ ก็จะได้แบบที่ตอบไปแล้วด้านบนนะครับ แต่แตกประเด็นย่อยหน่อยในส่วนของการทำ Binding/Wrapper คืออย่างที่ทราบกันทั่วไปว่าเมื่อเราพูดถึงสองสิ่งนี้(Binding/Wrapper) มันคือการทำ Interface ระหว่าง Platform ที่เราใช้ให้สื่อสารและใช้ API ของ Library ที่พัฒนาโดยเครื่องมืออื่นๆ(C,C++,etc.) ได้ โดยหลักใหญ่ของกระบวนการแล้วไม่ได้เป็นอะไรมากไปกว่าการแปลง Data Type ไปมา เพราะฉะนั้นมันอาจจะไม่เป็นประเด็นเท่าไหร่นักที่ Microsoft จะดำเนินการกับงานประเภทนี้ แต่กับงานอะไรก็ตามที่ยืนอยู่บนพื้นฐานหรือ Implement บนมาตรฐานของ Microsoft ว่ากันตามหลักเหตุผลแล้ว Microsoft มีสิทธิ์ที่จะฟ้องร้องได้ สิ่งที่ Microsoft ออกมาประกาศ Community Promise กับโปรเจ็ค Mono บางส่วน มันไม่ใช่การรับรอง Mono ตามที่คุณ Thaina เข้าใจ เป็นแต่เพียงการ "สัญญา" ว่าจะไม่ดำเนินการทางกฏหมายกับ Mono ในขอบข่ายเงื่อนไขที่จำกัดอย่างเป็นลายลักษณ์อักษรเท่านั้น ส่วนถ้ามีอะไรหลุดไปจากสิ่งที่ Microsoft กำหนด ก็ยังเหมือนเดิม คือยังไม่มีการระบุหรือกำหนดท่าทีที่ชัดเจนแต่อย่างใด และนั่นคือสิ่งที่คนส่วนใหญ่เค้ากังวลครับ
Update:
มาเห็นอีกทีว่ายังไม่ได้ตอบประเด็นสุดท้ายที่มองว่า การพัฒนาอะไรบน Mono ไม่น่าจะต่างจากพัฒนาอะไรๆ เพิ่มบน .NET ไม่งั้นคนที่พัฒนา component ให้ .NET ก็โดนฟ้องหมด อันที่จริงแล้วต้องเข้าใจก่อนว่ามันเป็นคนละเรื่องกัน ใน Context ของการพัฒนาเพิ่มเติมบน .NET นั่นย่อมหมายความว่าคนพัฒนาคือลูกค้าของ Microsoft ซึ่ง Microsoft มอบสิทธิ์ในการดำเนินการให้ผ่าน License อยู่แล้ว ส่วนตัวที่ Distribute กันทั่วไปเป็นเพียงตัว Runtime เท่านั้น ในขณะเดียวกัน Mono คือ Re-implementation ของทรัพย์สินทางปัญญาของ Microsoft และ Mono รวมถึงนักพัฒนาที่ยืนอยู่ในฝั่งนี้ไม่ใช่ลูกค้าของ Microsoft ทั้งไม่เคยมีการมอบสิทธิ์ให้แต่อย่างใด เคสมันย่อมต่างกันชัดเจนครับ
ส่วนตัว ถ้าสรุป..
MS จะฟ้องก็ฟ้องได้ แต่คิดว่ายังไงก็ไม่ฟ้อง แค่กั๊กให้กลัวเล่นๆ ฟ้องไปก้อเสียฐาน dev
กั้กให้กลัว เพื่อไม่ให้ Mono โตไวเกิน แล้วเปนอาวุธให้ linux ใช้ฆ่า windows
เมื่อถึงจุดที่ MS เหนว่า linux จะไม่สามารถสะเทือนตลาด Windows ได้แล้ว หรือถึงจุดที่ MS ไม่แคร์ตลาด Windows แล้ว .. ตอนนั้นก้อคงปล่อยเตมที่ เพราะฐาน dev ที่จะได้ จะไปต่อ value ด้านอื่นให้ MS ได้อีกเยอะ
เผลอๆ ไม่แน่ .. เมื่อถึงวันที่ MS ไม่แคร์ตลาด Windows หรือเหนว่า Linux ทำไรไม่ได้แล้ว MS อาจจะทำ Office สำหรับ Linux เองด้วยซ้ำ (ตอนนั้นคงทำใหม่ด้วย .net หมดแล้วด้วย ซึ่งถ้าเปนแบบนี้ การ support Mono เตมตัว จะทำให้ย้ายมาได้ง่ายๆ เลย กลับทำให้ได้ตลาดใหม่ด้วยซ้ำ .. จุดหมายเดียวกับจาวา แต่เดินคนละเส้นทาง)
ก้ออย่างแมค ที่ MS ทำ Office ให้ เพราะเหนว่าลูกค้าคนละฐานกับ Windows จริงๆ ยังสงสัยอยู่ว่า .. Office บนแมค เอาไปใช้บน Linux อื่นไม่ได้หรอ
ส่วนประเดนด้านภาษา ก้อเปนไปได้ที่อีกทาง Mono จะตาย แต่ยังไง C# คงรอด เพราะฐาน dev ติดภาษามากกว่า VM ถ้า MonoVM อาจเปนภัย ก้อเกบไว้แค่ C# ถ้าภาษามันฮิตซะอย่าง จะเอาไปใช้กับ VM อะไร เดวก้อมีคนทำ compiler ให้ ด้วยวิธีนี้ ก้อยังรักษาฐาน dev ได้ แต่อดขยายตลาดให้ product อื่นๆ บน windows
สรุปแล้ว ด้วยรากฐานจาก Mono ซึ่งไม่ว่าสุดท้ายจะเปนเช่นไร ยังไง MS ก้อ Win จะมากน้อยก็อีกเรื่อง แต่แผน Mono นี่ น่าจะตั้งใจสร้าง ไม่ใช่เพราะดิ้นรนหาทางรอดแน่ๆ
ฝันสลายแล้วครับ Office รุ่นใหม่ ใช้ WPF สร้าง อีกนานเลยกว่า Mono จะมีเหมือน
IBM เลยยังใช้ SWT ของตัวเองต่อไป
็อย่างที่บอกล่ะครับ สิ่งที่ขาดไปตอนนี้ หลักใหญ่ใจความก็มีแค่ Win.Form ซึ่งมี GTK# ที่แทนที่ได้ ส่วนฟีเจอร์อื่นๆ อย่าง ADO รือ ASP ผมว่ายังไม่จำเป็นต้องคำนึงถึงสำหรับคนที่ต้องการแค่ Desktop App และสำหรับ ADO ผม "เชื่อว่า" สามารถทำ Binding แทน ADO.NET ตัวจริงได้
ขอบข่ายเงื่อนไขที่เป็นลายลักษณ์อักษรที่ว่า ก็คือ Mono กองใหญ่ ที่ผมพูดถึงนั่นแหละครับ ประเด็นคือ ตอนนี้การพัฒนา Desktop App ด้วยภาษา C# และ "Mono ในขอบข่ายที่ Microsoft กำหนด" สามารถเป็นมาตรฐานบน Linux แทน Java ได้หรือไม่?
ผมเชื่อว่าได้ แม้จะมีแค่ namespace พื้นฐาน และใช้ GTK# แทน Winform
ป.ล.1 ไม่รู้ว่าผมเข้าใจถูกหรือไม่ แต่ผมเชื่อว่าการเขียน API ไม่ว่าจะด้วยภาษาหรือเฟรมเวิร์คอะไร ก็เป็นการ Binding คำสั่งบนแพลทฟอร์มนั้นๆ อย่าง lib System ใน .Net และ Java ก็คือการเขียนคำสั่งไป Binding โมดูลบน OS
ป.ล.2 ถ้าสมมุติว่า Microsoft มีปัญหากับ Mono แล้ว มีคนที่เขียน Someone.Form ขึ้นมา Wrap GTK# กับ Win.Forms ให้สลับใช้กันในแต่ละ OS แล้วยกเลิก Win.Form ใน Linux แล้ว Microsoft จะทำอะไรได้หรือไม่?
สิ่งที่ขาดไปหลักใหญ่ไม่น่าจะใช่ Win.Form ครับ เพราะในแง่ของการใช้งานใน Linux ทั้ง GTK# และ Qyoto น่าจะเรียกได้ว่าแทนที่ Win.Form ได้อยู่แล้ว รวมไปถึงว่าจะต้อง ADO.NET หรือปล่าว จริงๆ ก็ไม่ใช่ประเด็น แต่สิ่งที่เค้าถกกันและดูเหมือนจะเป็นประเด็นจริงๆ ก็คือ
ในส่วนที่เป็นความกังวลของอนาคตก็คือ มีความพยายามโต้แย้งใน Community เหมือนอย่างที่คุณ Thaina ว่านี่แหล่ะ ว่าก็แค่ใช้ CLI กับ Library มาตรฐานพัฒนาเอาก็ได้นี่นา ส่วนเสริมอื่นๆ ก็ทำ Binding เอา ในประเด็นนี้ก็แยกย่อยออกเป็นสองมุมมองคือ ในเมื่องานที่มันซับซ้อนกว่านี้ก็ต้องไปใช้เครื่องมืออื่นและหากมันมีส่วนที่ต้องทำ Binding จำนวนมากคำถามคือ แล้วทำไมไม่ไปใช้เครื่องมือที่มันเหมาะสมซะเลย? กับอีกประเด็นก็คือการที่จะรักษาเงื่อนไขที่ Microsoft ประกาศออกมาได้ก็คือ Mono และ Develop Chain ใดๆ ก็ตามที่ยืนอยู่บน Mono จะต้องคอยตามหลัง .NET ของ Microsoft อยู่เสมอ ความเป็นอิสระไม่มี ซึ่งส่วนนี้มันจะโยงไปเรื่องปรัชญา FOSS จะเห็นว่าทั้ง Debian และ GNOME เป็นโครงการที่ยืดนโยบาย FOSS เคร่งครัดอยู่พอสมควรจนอาจจะเรียกว่าเป็นโครงการต้นแบบ เป็น Case Study อยู่บ่อยครั้ง ครั้นแล้วโครงการต้นแบบดันจะรวมเอา Proprietary มาไว้ในชุดมาตรฐานหรือแม้กระทั่งให้การยอมรับอย่างเป็นทางการ มันก็ย่อมหลีกหนีไม่พ้นการตกเป็น Controversial
ส่วนเรื่องการ Binding นั้น คร่าวๆ มันก็คล้ายๆ นะครับ แต่ในรายละเอียดก็คลาดเคลื่อนและมีความต่างไปบ้าง การ Binding ก็คือตัวกลางทำหน้าที่แปลง Data Type ไปมาให้ แต่ในการเขียน Library หรือ API มันคือการเขียนชุดคำสั่งแล้วแปลงให้เป็นภาษาที่ทำงานหรือรวมเข้าเป็นส่วนหนึ่งของชุดคำสั่งของ OS เพื่อเรียกใช้ System Call อื่นๆ ต่อไป พูดง่ายๆ ก็คือแปลงให้เป็นชุดคำสั่งชนิดเดียวกันสื่อสารกันได้ถาวรเลย โดยที่ไม่ต้องคอยแปลงอะไรอีก ซึ่งเราเรียกกระบวนนี้โดยทั่วไปว่า Compiling เพราะฉะนั้นจะว่าเหมือนหรือเป็นสิ่งเดียวกัน คงไม่ใช่มังครับ
Mono จงใจออกแบบให้เป็น dual stack มาตั้งแต่แรกเพื่อเป็นทางออกกรณีมีปัญหากฎหมายครับ
รูปแบบมันจะเป็น (Compiler+Runtime กลาง) + ((.NET Compatible Library ที่ Mono เขียนเอง) หรือ (Mono Library))
เรื่องทิศทางผมว่าดีนะครับ ถ้าไปทางเดียวกับ .net แต่ไม่ชอบเรื่องกั๊กเท่านั้นเอง
MS คุมทิศทางไม่มีใครว่าถ้าไม่กั๊ก