การพิจารณาว่าภาษา / กรอบ / เทคโนโลยีเป็น 'การพิสูจน์ในอนาคต'

ฉันเป็นนักพัฒนา PHP และฉันเพิ่งเริ่มทำงานกับ CodeIgniter ดูเหมือนว่าเมื่อใดก็ตามที่ฉันค้นหาสิ่งที่เกี่ยวข้องกับ CodeIgniter การโพสต์บล็อกและสิ่งที่ไม่ปกติจาก '09 หรือ '10 ดังนั้นฉันจึงคิดว่า CodeIgniter ยังคงมีความเกี่ยวข้องและจะเป็นในอนาคตหรือไม่ มีกรอบอื่นที่เกิดขึ้นหรือไม่

เช่นเดียวกันสำหรับภาษาและกรอบอื่น ๆ เช่นกัน คุณละทิ้งการเรียนรู้ภาษาหรือกรอบบางประเด็น มีวิธีง่ายๆในการค้นหาผู้ที่เกิดขึ้นใหม่และคุ้มค่าหรือไม่

มันไม่ใช่วิทยาศาสตร์ที่แน่นอนดังนั้นอย่าคาดหวังว่าจะสามารถทำนายแนวโน้มในอนาคตในแนวเทคโนโลยีมากกว่า 5 ปีด้วยความมั่นใจ

แต่ฉันจะมองหาทั้งหมดต่อไปนี้:

• ฐานที่ติดตั้ง - ฐานที่ใหญ่กว่าหมายถึง บริษัท จำนวนมากจะ จำกัด การลงทุนในเทคโนโลยีและการบำรุงรักษาซึ่งหมายความว่านักพัฒนาจะต้องทำงานกับเทคโนโลยี วงจรบวกเกิดขึ้น ยกตัวอย่างเช่น Java เช่นภาษาโคบอลก่อนที่มันจะไม่ออกไปหามากนาน
• การสนับสนุนอุตสาหกรรมในวงกว้าง - มีผู้เล่นอุตสาหกรรมชื่อใหญ่หลายคนที่สนับสนุนเทคโนโลยีหรือไม่ ผู้สนับสนุนที่มุ่งมั่นเพียงรายเดียวเท่านั้นเป็นสัญญาณเตือน - มันอาจถูกทิ้งหรือกีดกันได้ตลอดเวลาด้วยการเปลี่ยนกลยุทธ์เพียงครั้งเดียว
• โอเพ่นซอร์ส - ผลิตภัณฑ์โอเพ่นซอร์สที่สำคัญได้พิสูจน์แล้วว่าเป็นเดิมพันระยะยาวที่ดีมาก (ดูที่ Linux, Apache, Red Hat, JBoss, Eclipse เป็นต้น) ผลิตภัณฑ์ที่เป็นกรรมสิทธิ์ในทางกลับกันจะขึ้นอยู่กับความตั้งใจของผู้ขายรายเดียวที่คุณมีความเสี่ยงที่จะหยุด / เพิ่มราคา / ความพยายามที่จะบังคับให้ต้องโยกย้ายไปยัง "สิ่งที่ยิ่งใหญ่ต่อไป"
• คุณภาพ - ผลิตภัณฑ์คุณภาพสูงจะมีอายุยืนยาวขึ้นเพราะผู้คนต้องการใช้มันแทนที่จะเปลี่ยนเป็นอย่างอื่น ในทางกลับกันผลิตภัณฑ์ที่มีคุณภาพต่ำจะถูกทอดทิ้งทันทีที่มีอะไรดีเข้ามา
• นวัตกรรม - เป็นเทคโนโลยีที่ล้ำสมัยของนวัตกรรมหรือไม่ ถ้าเป็นเช่นนั้นมีแนวโน้มที่จะได้รับการยอมรับและการสนับสนุนจาก บริษัท และผู้ใช้ที่มีนวัตกรรมมากขึ้น ในที่สุดนี้จะเริ่มเป็นกระแสหลัก (ฉันจะพูดภาษาใหม่เช่น Scala และ Clojure อยู่ในหมวดนี้)
• ชุมชน - มีชุมชนที่เป็นบวกเปิดใจกว้างมีความมุ่งมั่นมุ่งมั่นและเป็นประโยชน์รอบด้านเทคโนโลยีหรือไม่ เหล่านี้คือคนที่จะรับประกันได้ในอนาคต

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

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

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

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

"Futureproof-iness" เป็นเรื่องเกี่ยวกับพละกำลังและความดื้อรั้นมากพอ ๆ กับความกังวลในทางปฏิบัติมากขึ้น

ตัวอย่างที่ชัดเจนคือนี้ ตัวกรอง Sparkle กำลังทำงานอยู่คอมพิวเตอร์ IBM 402 จากปลายยุค 40 เป็นระบบบัญชีของพวกเขา นี่คือเครื่องที่ตั้งโปรแกรมโดยใช้ปลั๊กไฟฟ้าแทนที่จะเป็น "ไฟล์"

โดยส่วนตัวฉันมีประสบการณ์กับ บริษัท ที่ยังคงรักษาเครื่อง MS-DOS ไว้ในเครื่องมือพิเศษที่ออกแบบมาเพื่อใช้งานมานานหลายทศวรรษ ฉันเลิกใช้งาน PDP มาแล้วตั้งแต่ปลายปี 1997

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

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

เพื่อให้คำถามนี้ตอบได้คุณจะต้องเพิ่มรายละเอียดเพิ่มเติมในข้อกำหนด ตัวอย่างเช่น:

• เรากำลังพูดถึงช่วงเวลาใด - 1 ปี 3 ปี 5 ปีขึ้นไป
• ค่าใช้จ่ายในการเลือกสิ่งที่ไม่ได้อยู่ในรอบ 5 ปีคืออะไร?
• คุณจะได้รับประโยชน์อะไรบ้างจากการเลือกตัวเลือกที่ "ปลอดภัย" น้อยกว่าและผลประโยชน์นั้นมีมากกว่าความเสี่ยง

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

เช่นเดียวกับสิ่งส่วนใหญ่ในชีวิตกิจกรรมที่เกี่ยวข้องกับความเสี่ยงต่ำที่สุดอาจไม่ใช่ทางเลือกที่ดีที่สุด

กล่าวโดยย่อคือคุณมีความไม่แน่นอนมากน้อยเพียงใดเมื่อเทียบกับผลประโยชน์ที่คุณจะได้รับจากการใช้งานในช่วงเวลาที่คาดหวังของโครงการ

ยิ่งคุณต้องการมองหาอนาคตอีกต่อไปยิ่งมีความแน่นอนน้อยลงเท่านั้น หากคุณมีความสุขกับการกังวลเพียงแค่ในอีก 2 ปีข้างหน้าตัวเลือกของคุณจะง่ายกว่าที่จะทำ (และปล่อยให้ตัวเลือกที่เปิดกว้างสำหรับคุณ) ง่ายกว่าการเลือกสิ่งที่ต้องอยู่ในอีก 10 ปีข้างหน้า

มีปัจจัยมากมายที่ทำให้ฉันพูดได้ว่ามันเป็นไปไม่ได้ ในบรรดาสิ่งที่อาจผิดพลาดได้คือ: -

• แฟชั่น. ผู้คนหมดความสนใจและหันไปสนใจแพลตฟอร์มที่สวยกว่าใหม่ Perl มีการผูกขาดของเว็บแอปพลิเคชั่นประมาณปี 2000 ซึ่งแทบจะไม่ได้กล่าวถึงเลย
• ส่วนแบ่งการตลาดของผู้ขาย ประมาณ 2,000 คุณจะได้ว่า C ++ / Sun Solaris ดีจนถึงปี 3000
• บริษัท Shenanigans สองสามปีที่ผ่านมาฉันจะเลือก Java เป็นแพลตฟอร์มพิสูจน์ในอนาคต ด้วย ORACLE ที่มีลิขสิทธิ์ API ฯลฯ ฉันคิดว่าจะเห็นการเปลี่ยนแปลงไปสู่กรอบภาษาอื่น ๆ ฉันแค่หวังว่าฉันจะรู้ว่าอันไหน
• สุดถนน ฉันกำลังคิดถึงสิ่งต่าง ๆ เช่น Visual Basic ซึ่งหลังจากประวัติอันยาวนานและมีเกียรติก็ไม่สามารถยืดออกไปอีกเพื่อรองรับความคิดล่าสุดในการพัฒนาซอฟต์แวร์
• ผู้แพ้ชนะ PHP (ที่ฉันชอบ) จะไม่และไม่เคยชนะการประกวดความงามใด ๆ ในหมู่นักพัฒนา แต่มันกลายเป็นราชาแห่งเว็บที่ไม่มีข้อโต้แย้ง เมื่อฉันแรกเขียน php บางอย่างในปี 2004 ฉันจะไม่ได้รับการสนับสนุนเป็นภาษากลางของการพัฒนาเว็บ
• ลูกเป็ดขี้เหร่ Javascript โดยไม่เปลี่ยนไวยากรณ์ชิ้นเดียวหรือเพิ่ม API เดียวทันใดนั้นก็มาจากภาษาสคริปต์ hokey ซึ่งแบนเนอร์แบบเคลื่อนไหวที่น่ารำคาญเพิ่มเข้าไปในส่วนกลางของ WEB 2.0

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

กรอบ PHP, Symfony อธิบายนี้ได้อย่างสมบูรณ์แบบของพวกเขาที่เว็บไซต์

10 เกณฑ์สำหรับการเลือกกรอบงานที่ถูกต้อง

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

1. ความนิยมและขนาดชุมชน

ยิ่งเฟรมเวิร์กรู้จักและยอมรับมากเท่าไหร่ก็ยิ่งมี“ การมีชีวิต” ที่พัฒนาและสมบูรณ์มากขึ้นเท่านั้น: ความคิดใหม่ ๆ จำนวนและคุณภาพของปลั๊กอินเป็นต้น

2.Philosophy

นี่เป็นสาระสำคัญของกรอบการทำงาน: มันเป็นเกณฑ์พื้นฐานสำหรับการทำให้มั่นใจว่ามันจะตอบสนองความต้องการของคุณ เครื่องมือที่พัฒนาโดยผู้เชี่ยวชาญสำหรับความต้องการของตัวเองจะตอบสนองความต้องการของมืออาชีพอื่น ๆ

3.Sustainability

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

4.Support

เกณฑ์อื่นที่ไม่ควรมองข้ามก็คือความสะดวกในการค้นหาคำตอบสำหรับคำถามของคุณและรับความช่วยเหลือ ระบุการสนับสนุนที่มีอยู่: จากผู้เผยแพร่ จากชุมชน (รายการส่งเมล IRC ฯลฯ ) จาก บริษัท ผู้ให้บริการ (การพัฒนาการสนับสนุนการฝึกอบรม)

5.Technique

เพื่อหลีกเลี่ยงการติดกับดักในเขาวงกตมันจะดีกว่าเสมอในการเลือกโซลูชันที่ใช้งานร่วมกันได้ หนึ่งที่เคารพแนวทางปฏิบัติที่ดีที่สุดในแง่ของการพัฒนา (รูปแบบการออกแบบ)

6.Security

แอปพลิเคชันใด ๆ ที่มีความเสี่ยง เพื่อลดความเสี่ยงจะเป็นการดีกว่าเสมอในการเลือกเฟรมเวิร์กที่สามารถมั่นใจได้กับฟังก์ชั่นความปลอดภัย (ตัวอย่างเช่นการจัดการ XSS)

7.Documentation

มันเป็นความจำเป็นอย่างยิ่งในการประเมินลักษณะปริมาณและคุณภาพของวรรณกรรมที่มีอยู่เกี่ยวกับกรอบงาน: เครื่องมือที่ได้รับการบันทึกไว้อย่างดีทั้งใช้งานง่ายและอัปเกรดได้มากขึ้น

8.License

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

9. ความพร้อมของทรัพยากรในตลาด

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

10. ลองเลย!

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

กุญแจสำคัญคือความอดทน ความอดทนความอดทนความอดทน ไม่มีทางที่จะคาดเดาอนาคตได้อย่างแน่นอน (ฉันต้องเขียนด้วยซ้ำ)? แต่ถ้าคุณให้เทคโนโลยีใหม่สองสามปีและดูว่ามันใช้อย่างไรคุณจะมีความคิดที่ดีว่าจะหยั่งรากหรือไม่และเหมาะสำหรับการลงทุนระยะยาว / โครงการในระยะยาว .

ดังนั้นเมื่อ NextNewThing (tm) เข้ามาอย่าลังเลที่จะกระโดดบน bandwagon ... ไม่ใช่สิ่งสำคัญในช่วงสองสามปีแรก

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

1. ข้อมูลควรถูกจัดเก็บในรูปแบบเปิดที่ง่ายต่อการแยกหรือแปลงในภายหลัง รูปแบบไฟล์แปลก ๆ เป็นเทคนิคการล็อค & พื้นที่ดักขนาดใหญ่โดยทั่วไป และต้องการวิธีที่ง่ายกว่าเช่น CSV, ASN.1 หรือ JSON บนอึที่ซับซ้อนเช่น XML หรือ, พูด, รูปแบบ Word 97;) แนวคิดก็คือมันง่ายพอที่จะโยน parser เข้าด้วยกันด้วยตัวคุณเองและ parser รูปแบบระดับต่ำสามารถนำมาใช้ซ้ำได้ในแอพของคุณ

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

3. สแต็กควรเป็นโอเพนซอร์สทั้งหมดและสามารถแก้ไขได้ฟรี สิทธิ์การใช้งาน GPL, LGPL, BSD, MIT และอื่น ๆ ใช้ได้ในมุมนี้ แนวคิดคือถ้าชุมชนเริ่มตายแล้วสแต็กอาจต้องย้ายไปที่ [ฮาร์ดแวร์ / OS / โปรโตคอล / ฯลฯ ] ใหม่ และคุณต้องใช้รหัสในการทำเช่นนั้น

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

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

6. การพิมพ์แบบไดนามิกการอนุมานประเภทหรือวิธีการพิมพ์แบบยืดหยุ่นอื่น ๆ ช่วยได้ พอร์ตไปยังแพลตฟอร์มใหม่อาจเปลี่ยนนิยามของประเภทฐาน ภาษาที่มีการพิมพ์ภายในที่แข็งแกร่งหมายความว่าคุณไม่ต้องกังวลกับเรื่องนี้อีก

7. ทำให้รูปแบบการทำงานพร้อมกันเป็นเรื่องง่าย ข้อความที่ส่งผ่านอินเทอร์เฟซที่ชัดเจนเป็นเหตุการณ์ที่ขับเคลื่อนได้ ... พกพาไปได้ทุกอย่าง นอกจากนี้ยังมี coroutines คุณเพียงแค่ต้องการหลีกเลี่ยงเส้นทางที่เสี่ยงต่อการเกิดข้อผิดพลาดและปัญหาการพกพา

8. ดูที่ runtimes แบบพกพาของ Mozilla และ Apache พวกเขาแยกแยะปัญหาเฉพาะของแพลตฟอร์มหลายอย่างด้วยอินเตอร์เฟสและตัวเลือกการนำไปใช้งาน พวกเขาสามารถชี้แนะคุณเกี่ยวกับสิ่งที่ต้องกังวลพร้อมกับการเสนอวิธีแก้ไขปัญหาที่ดี

ตัวอย่างที่สมบูรณ์แบบ: Tcl ฉันรู้ว่าผู้คนมากมายเกลียดชังมันและฉันไม่ค่อยได้ใช้มัน แต่ Tcl เป็นอย่างยิ่งภาษาที่เข้าใจง่ายใช้ (12 กฎหลัก) และรหัส. มันมีขนาดเล็กเร็วพอที่จะทำงานร่วมกับเว็บเซิร์ฟเวอร์ฝังในแอปที่ได้รับแจ้งความกับตันของสิ่งที่มีคุณสมบัติด้านความปลอดภัยบางอย่าง และได้รับการปรับปรุงอย่างสม่ำเสมอตั้งแต่ยุค 80 เมื่อมันถูกสร้างขึ้น คุณหรือฉันสามารถใช้งาน runtime TCL ทั้งหมดได้ในเวลาไม่นานสำหรับภาษาหลัก ถ้าเราต้องย้ายไลบรารีมาตรฐานมันจะง่ายกว่าการย้าย. NET หรือ Java และมีโค้ดที่เป็นประโยชน์ค่อนข้างมากที่เขียนขึ้นสำหรับมัน และมันถูกนำมาใช้ในเว็บเทคเมื่อเทียบกับความนิยมใน "ตัวแทนมือถือ" ที่ Java แอปเพล็ตเล็ง ตัวอย่างเช่นเว็บเฟรมเวิร์ก OpenACS ย้อนกลับไปในปี 1998 ด้วยเซิร์ฟเวอร์ที่เก่ากว่า

ตัวอย่างอื่น ๆ : BASIC, COBOL และ LISP (Scheme หรือ CL) ภาษาเหล่านี้กลับไปสู่ยุค 50 หรือ 60 มันง่ายพอที่จะทำให้การทำความเข้าใจการใช้งานและการแปลเชิงกลง่ายขึ้น แต่คุณสามารถสร้างสิ่งที่มีประโยชน์กับพวกเขา COBOL ยังคงให้พลังในการประมวลผลธุรกรรมส่วนใหญ่ของโลกได้รับการปรับปรุงสองสามครั้งและทำงานบน. NET แม้กระทั่ง แอพ QBasic / QuickBASIC แบบเก่ายังคงทำงานอยู่ในปัจจุบันด้วยเครื่องมือแบบเปิด / ไม่เสียค่าใช้จ่ายบนแพลตฟอร์มที่ทันสมัย ตัวแปลงสัญญาณ LISP ทำให้ระบบเป็นโมดูลและใช้งานได้ มีการใช้งานอย่างต่อเนื่องมานานหลายทศวรรษเปิดกว้างและเชิงพาณิชย์

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