สกาล่าพร้อมหรือยังสำหรับช่วงเวลาไพร์ม? [ปิด]

ตอนนี้ฉันได้ทำสิ่งเล็ก ๆ น้อย ๆ กับ Scala (ซึ่งฉันชอบ "Hello world" และแอปพลิเคชันที่ประดิษฐ์!) ฉันสงสัยว่า .. ส่วนหนึ่งเกี่ยวกับวุฒิภาวะของเครื่องมือเพื่อสนับสนุนการพัฒนาและส่วนหนึ่งเกี่ยวกับการบังคับใช้ทั่วไป ชุดเครื่องมือพร้อมหรือยัง? Scala เหมาะสมสำหรับการใช้กับแอปพลิเคชันระดับองค์กร / ธุรกิจหรือไม่ "คุณ" จะใช้มันในโครงการที่ไม่สำคัญหรือไม่?

ข้อกังวลของฉัน (ไม่มีมูล) อาจเป็น:

• IDE และชุดเครื่องมือมีความสมบูรณ์เท่ากับสิ่งที่เราต้องพัฒนาแอปพลิเคชัน. net และ java (eclipse สำหรับ Scala ดูเหมือน จำกัด เมื่อเทียบกับ eclipse สำหรับ java)
• ชุดเครื่องมือ build / CI / การทดสอบสามารถจัดการกับ Scala ได้อย่างมีประสิทธิภาพหรือไม่
• รหัสรัดกุมที่สามารถบำรุงรักษาได้ (สนับสนุน?) เขียนด้วยภาษาได้อย่างไร?
• เป็นไปได้หรือไม่ที่จะพบนักพัฒนาซอฟต์แวร์ที่มีประสบการณ์ Scala
• มีความสำคัญพอที่จะรับความช่วยเหลือผ่านการอ้างอิงออนไลน์และหนังสือที่มากกว่า "อินโทร" สำหรับภาษาหรือไม่

บรรทัดล่างดังนั้น - ระบบนิเวศเติบโตเพียงพอที่จะใช้ตอนนี้หรือดีกว่ารอดูว่ามันวิวัฒนาการหรือไม่

แก้ไข: สมมติว่า "ไม่ใช่เรื่องไม่สำคัญ" เป็นโครงการสำหรับนักพัฒนา 10-20 ปีแบบหลายปี

ในขณะที่มันเป็นความจริงที่ Scala ถูกนำมาใช้ในป่าที่ผู้พิทักษ์และที่ Twitter มีข้อกังวลพื้นฐานอย่างหนึ่งคือ

ความนิยมของ Java ส่วนใหญ่มาจากความจริงที่ว่าอ่านและดูแลรักษาค่อนข้างง่าย สกาล่ามีปัญหาที่นี่เพราะมันสามารถเขียนได้หลายสไตล์ สไตล์ OO เทียบกับรูปแบบการทำงานเป็นแยกที่เห็นได้ชัดที่นี่ แต่จะได้รับความซับซ้อนมากขึ้นเมื่อคุณพูดคุยเกี่ยวกับ 3 ระดับของสกาล่า

คุณต้องตรวจสอบให้แน่ใจว่าทีมของคุณและการจ้างงานใหม่ที่อาจเกิดขึ้นสามารถทำตามสไตล์เดียวกันและสไตล์นั้นง่ายพอสำหรับคุณจริง ๆ ที่จะสามารถจ้างนักพัฒนาที่มีประสิทธิภาพ (ไม่ใช่ทุกคนสามารถจ้าง 2% ด้านบน) .

การสนับสนุนการใช้เครื่องมือยังไม่มากนักถึงแม้ว่าฉันคาดว่าช่องว่างนี้จะปิดอย่างรวดเร็วพอสมควร นอกจากนี้คุณยังสามารถรับการสนับสนุนสำหรับ Scala แบบเต็มจากฝูงชนTypeSafe ฉันคิดว่าสกาล่าจะแกะสลักโพรงของมันออกมา แต่จนกว่าระดับจะถูกสร้างขึ้นเป็นภาษา / คอมไพเลอร์ / อะไรก็ตามฉันก็เห็นว่าการปวดหัวการบำรุงรักษาจะลดลงในทีมหลังจากช่วง 1-2 ปีแรกของการทำงานที่ตื่นเต้น

ดูคำตอบที่เกี่ยวข้องสำหรับรายละเอียดเพิ่มเติม

Scala ปัจจุบันใช้งานโดย Twitter และโดย Gaurdian ดังนั้นจึงพร้อมใช้งานสำหรับแอปพลิเคชั่นที่ไม่สำคัญ

โปรแกรมเมอร์สกาล่าจะมีแรงจูงใจมากและน่าจะดีมาก การเลือกภาษาใหม่เป็นวิธีที่ยอดเยี่ยมในการดึงดูดความสามารถ

แน่นอนว่าโปรแกรมเมอร์ของสกาล่ามักจะไม่ได้รับประสบการณ์สกาล่าอย่างมืออาชีพและอาจมีสำนวนหลากหลายที่พวกเขาใช้ บางคนอาจพยายามเพื่อความบริสุทธิ์เหมือน Haskell ในขณะที่บางคนอาจมองว่าเป็น Java ด้วยการปิด ดังนั้นอาจใช้เวลาสักครู่ในการพัฒนามาตรฐานการเข้ารหัสและการประชุมที่สอดคล้องกัน

เครื่องมือ Java จำนวนมากจะทำงานได้ดีแม้ว่า IntelliJ Idea อาจคุ้มค่ากับการลงทุนกับ Eclipse

โดยรวมแล้วอาจเป็นทางเลือกที่ดีถ้าคุณมีอำนาจควบคุมโครงการ หากนี่เป็นส่วนหนึ่งของ บริษัท ประกันภัยขนาดใหญ่คุณอาจพบปัญหาหากมีแนวทางสถาปัตยกรรมเช่น: 'โครงการทั้งหมดจะถูกสร้างโดย Maven และปรับใช้ใน WebSphere' (ฉันไม่มีเหตุผลที่จะคิดว่ากฎนี้โดยเฉพาะจะเป็นปัญหา แต่การแพร่กระจายของกฎดังกล่าวอาจเดินทางคุณในบางจุด)

ความประทับใจของฉันคือระบบนิเวศส่วนใหญ่ที่มาพร้อมกับภาษา "ธรรมดา" (เช่น Java) มีจุดประสงค์เพื่อชดเชยความซุ่มซ่ามของพวกเขา

คำถามไม่ใช่เครื่องมือที่มีสำหรับภาษาที่กำหนด (Scala) แต่เครื่องมือที่มีอยู่สำหรับภาษานั้นดีกว่าเครื่องมือที่มีอยู่สำหรับภาษาอ้างอิง (Java) หรือไม่ เนื่องจากเครื่องมือปานกลาง 100 อันจะไม่ให้คุณเครื่องมือที่ดีอย่างหนึ่งที่สามารถมอบให้คุณได้ และสิ่งที่คุณไม่ควรลืมคือภาษานั้นเป็นส่วนหนึ่งของเครื่องมือเหล่านั้น

ความเสื่อมของภาษา

• มีสัดส่วนผกผันกับปริมาณและความรุนแรงของข้อบกพร่องที่คุณสร้างขึ้นด้วยเหตุนี้ Java จึงยอดเยี่ยมในการสร้างข้อบกพร่องและคุณต้องการเครื่องมือจำนวนมากเพื่อหลีกเลี่ยงและติดตามพวกเขา
• เป็นสัดส่วนกับประสิทธิภาพการทำงานของคุณซึ่งเป็นสาเหตุที่ Java มีความละเอียดมากและคุณต้องการตัวสร้างโค้ดและเครื่องมือที่คล้ายกันจำนวนมาก

ตัวอย่างเช่นฉันเคยอ่านโพสต์บล็อกที่น่ากลัวโดยคนทับทิมผู้โต้เถียงแบบคงที่ไม่มีจุดหมายเพราะการทดสอบของคุณจะครอบคลุมความปลอดภัยของประเภท สิ่งนี้มาจากใครบางคนที่ยังไม่ได้ทำงานกับระบบสแตติกชนิดที่แสดงออกอย่างชัดเจน สมมติว่าฉันสามารถเป็นตัวแทนของความสัมพันธ์ทุกประเภทในความหมายของภาษาและมันไม่ได้เป็นงานที่ต้องทำ (และมันก็ไม่ใช่เพราะภาษาสมัยใหม่ส่วนใหญ่สนับสนุนการอนุมานประเภท) ฉันได้รับทั้งหมดนี้ฟรี

ในการผลักดันให้คิดไปข้างหน้าอีกเล็กน้อย: การทดสอบหน่วยให้แน่ใจว่าหน่วยทำตามที่ระบุไว้หรือเพื่อใช้ถ้อยคำใหม่การทดสอบหน่วยเป็นข้อกำหนดเฉพาะที่สามารถเรียกใช้ อย่างไรก็ตามผ่านการเขียนโปรแกรมที่ประกาศหน่วยตัวเองเป็นข้อมูลจำเพาะ runnable อีกครั้งคุณจะได้รับของฟรี

สิ่งที่ฉันพยายามจะพูดคือคุณไม่ควรประมาทว่าคุณลักษณะภาษาใดที่สามารถทำให้คุณได้ และถ้าคุณไม่ลองพวกเขาในสนามจริงๆคุณจะไม่เข้าใจ

ดังนั้นเพื่อกลับมาที่คำถามเดิม: เครื่องมือที่มีอยู่สำหรับ Scala ดีกว่าสำหรับ Java หรือไม่ ยากที่จะพูด. ขึ้นอยู่กับสิ่งที่คุณต้องการจะทำ ฉันคิดว่าเราทุกคนเห็นด้วยกับภาษาดีกว่าอย่างมากตอนนี้คำถามก็คือระบบนิเวศที่คุณจะพบได้ในพื้นที่ธุรกิจของคุณดีแค่ไหน
สำหรับเว็บLiftจริงๆเป็นตัวเลือกที่ดีที่จะไปด้วย ไม่ทราบเกี่ยวกับเดสก์ท็อปหรือมือถือ

สมมติว่า "ไม่สำคัญ" เป็นโครงการสำหรับนักพัฒนา 10-20 ปีที่หลากหลาย

นั่นเป็นความเสี่ยง รางวัลจะต้องมีค่า ในโลกของแอพธุรกิจองค์กรและโครงการขนาดกลางถึงขนาดใหญ่การรับความเสี่ยงมักมี จำกัด หรือค่อนข้างมีความเสี่ยงที่จะจัดการกับ ... การคาดการณ์มีความสำคัญมากกว่า

ฉันสงสัยว่าการนำไปใช้จะทำงานอย่างนั้น

มีแนวโน้มมากขึ้นที่จะเริ่มเป็นคนจำนวนหนึ่งที่ทำงานในส่วนที่มีความเสี่ยงเช่น POC, องค์ประกอบที่ไม่สำคัญ, การทดสอบหรือชิ้นส่วนที่ดูเหมือนว่าปัญหาจะได้รับการแก้ไขที่ดีกว่าโดย Scala มากกว่าทางเลือกอื่น ๆ ตัวอย่างเช่นนักแสดง) ... จากนั้นเมื่อเครื่องมือเติบโตขึ้นชุมชนจะเติบโตความรู้เติบโตใน บริษัท จากนั้นก็สามารถขยายตัวได้

ด้วยการใช้ประโยชน์จากรันไทม์ของ Java Scala ก็พร้อมสำหรับช่วงเวลาสำคัญ หากคุณสามารถปรับใช้แอปพลิเคชัน Scala ได้เมื่อมีการสร้าง bytecode มันควรทำงานกับ Java runtime เวอร์ชันนั้น ๆ ไลบรารีแบบสกาล่าจะทำงานเหมือนกับห้องสมุดบุคคลที่สามของ Java อื่น ๆ ที่คุณคุ้นเคย

ในแง่ของ IDEs สร้างเครื่องมือและทุกอย่าง Scala ไม่มีระดับของการแพร่กระจายในระดับเดียวกันกับที่ Java มี ดังนั้นคุณจึงไม่มีเฟรมเวิร์คที่ใช้สกาล่าหรือเครื่องมือที่ใช้สกาลามากมาย ที่มีมากขึ้นที่จะพูดด้วยความนิยมของ Java มากกว่าที่จะเป็นกับความนิยมที่เพิ่มขึ้นของสกาล่า Scala มีเครื่องมือที่ใช้งานได้รวมถึง Scala IDE และ sbt สร้างเครื่องมือ แต่มันก็ไม่ได้มีความซับซ้อนเท่าเครื่องมือตัวช่วย Java ล้วนๆ

จุดเก็บเชอร์รี่จาก @huynhjl และ @FarmBoy:

• การค้นหาโปรแกรมเมอร์ Scala ที่มีประสบการณ์จำนวนมากอาจเป็นเรื่องยาก

• แนวปฏิบัติที่ดีที่สุดสำหรับ Scala ยังคงพัฒนาอยู่ (*)

• ไกด์สไตล์การประชุม ฯลฯ ยังคงมีการพัฒนา (*)

• การสนับสนุนเครื่องมือยังคงพัฒนาอยู่ (*)

การดึงสิ่งเหล่านี้เข้าด้วยกันอาจเป็นคำถามที่ดีกว่าสำหรับคุณที่จะถาม (ตัวคุณเอง / ตัวเอง) ว่าองค์กรของคุณพร้อมที่จะใช้ Scala ในโครงการ "ที่ไม่สำคัญ" หรือไม่? คุณมีคนที่สามารถรับมือกับการทำโครงการขนาดใหญ่ที่มีหลายสิ่งหลายอย่าง "ยังคงพัฒนา" หรือไม่? ตรงกันข้ามมันจะดีกว่าหรือไม่ที่จะทำโครงการเล็ก ๆ ก่อน?

(* อันที่จริงภาษาส่วนใหญ่ยังคงมีการพัฒนาในประเด็นเหล่านี้อย่างน้อยหนึ่งประเด็นปัญหาที่นี่คืออัตราการเปลี่ยนแปลง / ฟลักซ์ ... และทีมของคุณสามารถรับมือกับมันได้หรือไม่)

David Pollak ที่ Good Stuff มีบล็อกโพสต์ที่ยอดเยี่ยมชื่อFunctional Language จะเป็นกฎ (แต่ไม่ใช่ปีนี้)ที่พูดถึงภาษาหน้าที่การใช้งานโดยทั่วไปและ Scala ในรายละเอียดที่ฉันขอแนะนำให้อ่านเพื่อทำความเข้าใจให้ดีขึ้นถ้า Scala พร้อม สำหรับช่วงเวลาสำคัญ

ฉันไม่เคยเข้าใจความแตกต่างระหว่างenterpriseและnon enterpriseโปรแกรม

ฉันใช้โปรแกรมเดียวกันกับที่ทำงานเหมือนอยู่ที่บ้าน ฉันจะไม่ใช้โปรแกรมปานกลางในเวลาว่าง - ทำไมต้อง

โปรแกรมที่ไม่ใช่วิชาชีพคืออะไร ฉันเคยเห็นแอปพลิเคชั่นที่ไม่ดีถูกใช้เพราะผู้ใช้ไม่รู้จักดีขึ้นเนื่องจากปัญหาความเข้ากันได้หรือผู้ใช้ปฏิเสธที่จะทำสิ่งใหม่

แต่มันเป็นปัญหาของซอฟต์แวร์ที่ล้าสมัยและเป้าหมายที่ผู้พัฒนานึกไว้ - ไม่ใช่ภาษาโปรแกรมถูกเขียนขึ้นหากคุณเริ่มคิดว่าภาษาใดที่โปรแกรมถูกเขียน

Enterprise- แอปพลิเคชันเป็นคำที่ไม่เหมาะสมซึ่งไม่มีประโยชน์สำหรับการสนทนาที่จริงจัง

และลูกค้าคนไหนที่รู้ว่าคุณทำงานอะไร บางครั้งพวกเขาสนใจบางครั้งพวกเขาไม่

คุณอาจมีคำถามที่เกี่ยวข้องกับวุฒิภาวะของภาษา แต่คุณไม่สามารถตอบคำถามสำหรับองค์กรทุกประเภทและแอปพลิเคชันทั้งหมด