لماذا وظيفية اللغات ؟ [مغلقة]
https://stackoverflow.com/questions/36504
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أرى الكثير من الحديث هنا عن اللغات الوظيفية و الاشياء.لماذا استخدام واحد على "التقليدية" اللغة ؟ ماذا تفعل أفضل ؟ ما هي أسوأ ؟ ما هو المثل الأعلى البرمجة الوظيفية التطبيق ؟
المحلول
اللغات الوظيفية استخدام النموذج من الضروري وجوه المنحى لغة.أنها تستخدم آثار جانبية خالية وظائف باعتباره لبنة أساسية في اللغة.وهذا يتيح الكثير من الأمور يجعل الكثير من الأمور أكثر صعوبة (أو في معظم الحالات المختلفة من الناس ما تستخدم).
واحدة من أكبر مزايا مع البرمجة الوظيفية هو أن أمر التنفيذ من جانب-تأثير خالية وظائف ليست مهمة.على سبيل المثال ، في إرلانج هذا يستخدم لتمكين التزامن في غاية الشفافية.ولأن المهام الوظيفية اللغات تتصرف مشابهة جدا الدوال الرياضية فإنه من السهل أن تترجم تلك إلى اللغات الوظيفية.في بعض الحالات, هذا يمكن أن يجعل رمز أكثر قابلية للقراءة.
تقليديا ، واحدة من أكبر عيوب البرمجة الوظيفية أيضا عدم وجود آثار جانبية.من الصعب جدا كتابة البرامج المفيدة دون IO, ولكن IO من الصعب أن تنفذ دون آثار جانبية في الوظائف.لذلك معظم الناس لم يحصل أكثر من البرمجة الوظيفية من حساب واحد خرج من إدخال واحد.في الحديث مختلطة-نموذج لغات مثل F# أو سكالا هذا هو أسهل.
الكثير من اللغات الحديثة عناصر من لغات البرمجة الوظيفية.C# 3.0 لديه الكثير البرمجة الوظيفية الميزات ويمكنك أن تفعل البرمجة الوظيفية في بيثون أيضا.أعتقد أن أسباب شعبية البرمجة الوظيفية في الغالب لسببين:التزامن هو الحصول على أن يكون مشكلة حقيقية في البرمجة العادية لأننا الحصول على المزيد والمزيد من أجهزة الكمبيوتر متعددة المعالجات;و اللغات الحصول على المزيد من الوصول إليها.
نصائح أخرى
لا أعتقد أن هناك أي سؤال حول النهج الوظيفي إلى البرمجة "اصطياد" لأنه تم في الاستخدام (مثل أسلوب البرمجة) لمدة 40 عاما.كلما OO مبرمج يكتب كود النظيفة التي تفضل ثابتة الكائنات ، الذي هو رمز الاقتراض وظيفية المفاهيم.
ومع ذلك, لغات فرض على نمط وظيفي على الكثير من الظاهرية الحبر في هذه الأيام ، سواء تلك اللغات سوف تصبح المهيمنة في المستقبل هو سؤال مفتوح.بلدي الشك هو هجين متعدد نموذج اللغات مثل سكالا أو OCaml من المرجح أن تهيمن على "خالصة" اللغات الوظيفية في بنفس الطريقة التي نقية OO (لغة Smalltalk ، بيتا،.... الخ) أثرت التيار البرمجة ولكن لم انتهى الأكثر استخداما الرموز.
أخيرا, أنا لا يمكن أن تقاوم مشيرا إلى أن تعليقاتكم إعادة FP عالية بالتوازي مع تصريحات سمعت من الإجرائية المبرمجين ليس قبل سنوات عديدة:
- فإن (الأسطورية ، IMHO) "متوسط" مبرمج لا يفهم ذلك.
- انها لا تدرس على نطاق واسع.
- أي برنامج يمكنك كتابة مع أنها يمكن أن تكون مكتوبة بطريقة أخرى مع التقنيات الحالية.
كما واجهات المستخدم الرسومية و "رمز نموذج الأعمال" كانت المفاهيم التي ساعدت OO تصبح أكثر تقدير على نطاق واسع ، وأعتقد أن زيادة استخدام ثبات و أبسط (ضخمة) التوازي سوف تساعد أكثر المبرمجين نرى فوائد هذا النهج الوظيفي العروض.ولكن كما تعلمنا في الماضي 50 أو حتى سنوات التي تشكل كل تاريخ الرقمية برمجة الكمبيوتر, أعتقد أنه لا يزال لدينا الكثير لنتعلمه.عشرين سنة من الآن ، المبرمجين سوف ننظر إلى الوراء في ذهول في الطبيعة البدائية من الأدوات التى تستخدمها حاليا ، بما في ذلك الآن شعبية OO و FP اللغات.
بالإضافة الرئيسي بالنسبة لي هو الأصيل التوازي ، خاصة ونحن الآن الابتعاد عن أكثر ميغاهرتز و نحو المزيد والمزيد من النوى.
أنا لا أعتقد أنها سوف تصبح التالي نموذج البرمجة و تحل تماما محل OO نوع الأساليب, ولكن أنا لا أعتقد أننا سوف نصل الى النقطة التي نحن بحاجة إلى إما كتابة بعض التعليمات البرمجية في لغة وظيفية أو الأغراض العامة اللغات سوف تنمو لتشمل المزيد من بنيات وظيفية.
حتى لو كنت لا تعمل في لغة وظيفية مهنيا ، فهم البرمجة الوظيفية سوف تجعلك أفضل المطور.وسوف تعطيك منظورا جديدا على الكود الخاص بك و البرمجة بشكل عام.
أنا أقول ليس هناك سبب لا تعلم ذلك.
أعتقد اللغات القيام بعمل جيد من خلط وظيفية بد النمط الأكثر إثارة للاهتمام هي الأكثر احتمالا للنجاح.
أنا دائما متشككا حول الشيء الكبير المقبل.الكثير من الأوقات الشيء الكبير المقبل هو محض الصدفة من تاريخ التواجد في المكان المناسب في الوقت المناسب بغض النظر عن ما إذا كانت التكنولوجيا هي جيدة أم لا.أمثلة:C++, Tcl/Tk, Perl.كل معيبة التكنولوجيات جميع ناجحة بعنف لأنهم كانوا المتصورة إما أن حل مشاكل اليوم أو أن تكون متطابقة تقريبا إلى ترسخ معايير أو كليهما.البرمجة الوظيفية قد يكون في الواقع كبيرة ، ولكن هذا لا يعني أنه سوف يتم اعتمادها.
ولكن أنا يمكن أقول لك لماذا الناس متحمس عن البرمجة الوظيفية:العديد والعديد من المبرمجين لديهم نوع من "تجربة التحويل" التي اكتشف أن استخدام لغة وظيفية يجعل منها ضعف الإنتاجية (أو ربما عشر مرات الإنتاجية) في حين أن إنتاج التعليمات البرمجية التي هي أكثر قدرة على التكيف مع التغيير ولها عدد أقل من الأخطاء.هؤلاء الناس يعتقدون في البرمجة الوظيفية كسلاح سري;وخير مثال على هذا التوجه هو بول غراهام بفوزه على المتوسطات.أوه, و طلبه ؟ التجارة الإلكترونية تطبيقات الويب.
منذ أوائل عام 2006 كان هناك أيضا بعض الطنانة حول البرمجة الوظيفية و التوازي.لأن الناس مثل سيمون بيتون جونز وقد القلق حول التوازي وتشغيله على الأقل منذ عام 1984 ، أنا لا أحبس أنفاسي حتى اللغات الوظيفية حل والمتعددة المشكلة.لكنه يفسر بعض إضافية باز الآن.
في عام ، الجامعات الأمريكية بعمل الفقراء تعليم البرمجة الوظيفية.هناك نواة قوية من الدعم تدريس مقدمة البرمجة باستخدام نظام, و هاسكل يتمتع أيضا بعض الدعم هناك ، ولكن هناك القليل جدا في طريق تدريس تقنية متقدمة الوظيفي مبرمج.لقد درست هذه دورة في جامعة هارفارد وسوف نفعل ذلك مرة أخرى في ربيع هذا العام في تافتس.بنيامين بيرس وقد علمتنا هذه الحال في بنسلفانيا.أنا لا أعرف إذا كان بول هوداك فعل أي شيء في جامعة ييل.الجامعات الأوروبية هي القيام بعمل أفضل بكثير;على سبيل المثال, البرمجة الوظيفية أكد في أماكن مهمة في الدنمارك ، هولندا ، السويد ، والمملكة المتحدة.لدي أقل من الشعور ما يحدث في أستراليا.
أنا لا أرى أي شخص ذكر الفيل في الغرفة هنا ، لذلك أعتقد أن الأمر متروك لي :)
جافا سكريبت هي لغة وظيفية.كما المزيد والمزيد من الناس أكثر الأشياء المتقدمة مع شبيبة خصوصا الاستفادة من النقاط الدقيقة مسج, مدرسة, وغيرها من الأطر FP سيتم عرض ويب المطور الباب الخلفي.
بالتزامن مع الإغلاق, FP يجعل رمز شبيبة ضوء حقا, حتى الآن لا تزال قابلة للقراءة.
الهتافات ، PS
معظم التطبيقات هي بسيطة بما فيه الكفاية ليتم حلها في العادي OO الطرق
OO الطرق لم تكن "طبيعية". هذا العقد هو معيار العقد الماضي المهمشة المفهوم.
البرمجة الوظيفية هو الرياضيات. غراهام بول على Lisp (بديل وظيفية البرمجة Lisp):
لذا قصيرة تفسير لماذا هذا 1950s اللغة ليست هي التي عفا عليها الزمن لم يكن التكنولوجيا ولكن الرياضيات ، الرياضيات لا معنى لها.الحق الشيء مقارنة اللثغة أن لا 1950s الأجهزة, ولكن أقول فرز سريع الخوارزمية التي تم اكتشافها في عام 1960 و هو لا يزال أسرع للأغراض العامة نوعا ما.
أراهن أنك لا تعرف أنك البرمجة الوظيفية عند استخدامها:
- صيغ Excel
- الكوارتز الملحن
- جافا سكريبت
- شعار (السلاحف الرسومات)
- LINQ
- SQL
- Underscore.js (أو Lodash), D3
متوسط الشركات مبرمج مثلامعظم الناس الذين أعمل معهم ، لا أفهم معظم العمل بيئات لن تسمح لك البرنامج في ذلك
هذا هو واحد فقط مسألة وقت على الرغم من.متوسط الشركات مبرمج يتعلم مهما الحالي هو.قبل 15 عاما لم أفهم OOP.إذا FP المصيد ، "متوسط الشركات المبرمجين" سوف تتبع.
انها ليست حقا تدرس في الجامعات (أو هو في الوقت الحاضر؟)
يختلف الكثير.في جامعة SML هي اللغة الأولى يتم إدخال الطلاب.أعتقد MIT يعلم اللثغة الأولى-سنة الطبع.هذين المثالين قد لا تكون ممثلة ، بالطبع ، ولكن أعتقد أن معظم الجامعات على الأقل تقديم بعض الدورات الاختيارية على FP, حتى لو أنها لا تجعل جزءا إلزاميا من المناهج الدراسية.
معظم التطبيقات هي بسيطة بما فيه الكفاية تحل في العادي OO الطرق
انها ليست مسألة "بسيطة بما فيه الكفاية" على الرغم من.أن الحل يكون أبسط (أو أكثر للقراءة, قوي, أنيق, performant) في FP?العديد من الأمور "بسيطة بما فيه الكفاية ليتم حلها في جافا" ، لكنه لا يزال يتطلب يدي كمية من التعليمات البرمجية.
في أي حال, نضع في اعتبارنا أن FP أنصار ادعى أنه كان الشيء الكبير المقبل لعدة عقود الآن.ربما هم على حق ، ولكن نضع في اعتبارنا أن أنها لم تكن عندما جعلوا نفس المطالبة 5, 10 أو 15 عاما.
شيء واحد بالتأكيد تحسب في صالحهم ، على الرغم من أن في الآونة الأخيرة, C# اتخذت منعطفا حادا نحو FP, إلى حد أنه عمليا تحول جيل من المبرمجين في FP المبرمجين ، دون حتى أن يلاحظ.التي قد تمهد الطريق FP "الثورة".ربما.;)
الرجل لا يستطيع فهم الكمال و عيوب المختار الفن إذا كان لا يرى قيمة في الفنون الأخرى.القواعد التالية فقط تصاريح التنمية يصل إلى نقطة في تقنية ثم طالب الفنان لمعرفة المزيد و لطلب المزيد.فمن المنطقي أن دراسة الفنون الأخرى فضلا عن تلك الاستراتيجية.
الذي لم يتعلم شيئا أكثر عن أنفسهم من خلال مشاهدة أنشطة الآخرين ؟ لمعرفة السيف الدراسة على الغيتار.لتعلم قبضة دراسة التجارة.إلى مجرد دراسة السيف سوف تجعلك ضيق الأفق و لن تسمح لك أن تنمو إلى الخارج.
-- مياموتو موساشي "، وهو كتاب من خمسة خواتم"
واحد الميزة الرئيسية في لغة وظيفية هو مفهوم وظائف من الدرجة الأولى.والفكرة هي أنه يمكنك تمرير وظائف معلمات وظائف أخرى وإعادتها كما القيم.
البرمجة الوظيفية يتضمن كتابة التعليمات البرمجية التي لا تتغير الدولة.السبب الرئيسي لذلك هو أن المتعاقبة يدعو إلى وظيفة سوف تحقق نفس النتيجة.يمكنك كتابة رمز وظيفي في أي لغة تدعم وظائف من الدرجة الأولى ، ولكن هناك بعض اللغات مثل هاسكل التي لا تسمح لك بتغيير الدولة.في الواقع, أنت ليس من المفترض أن تجعل أي آثار جانبية (مثل طباعة النص) على الإطلاق - والتي يبدو أنها يمكن أن تكون عديمة الفائدة تماما.
هاسكل بدلا توظف نهج مختلف IO:monads.هذه هي الأشياء التي تحتوي على المطلوب IO العملية المنفذة من قبل المترجم toplevel.في أي مستوى آخر فهي ببساطة الكائنات في النظام.
ما هي مزايا البرمجة الوظيفية ؟ البرمجة الوظيفية يسمح الترميز مع أقل الإمكانات عن الخلل لأن كل عنصر معزول تماما.أيضا, استخدام العودية و وظائف من الدرجة الأولى يسمح بسيطة البراهين على صحتها والتي عادة ما تعكس بنية التعليمات البرمجية.
لا أعتقد أن الأكثر واقعية الناس يعتقدون أن البرمجة الوظيفية سوف قبض على (يصبح الرئيسية النموذج مثل OO).بعد كل شيء, معظم المشاكل التجارية ليست جميلة مشاكل الرياضيات ولكن شعر قواعد أساسية لنقل البيانات حول وعرضها بطرق مختلفة ، مما يعني أنه ليس مناسبا نقية وظيفية نموذج البرمجة (منحنى التعلم من الكائن الدقيق الاحادي الخلية يفوق بكثير OO.)
OTOH, البرمجة الوظيفية هو ما يجعل البرمجة متعة.يجعلك أقدر الكامنة, الجمال الخالدة من مقتضبة تعبيرات الرياضيات الأساسية للكون.يقول الناس أن تعلم البرمجة الوظيفية سوف تجعلك أفضل مبرمج.وهذا بالطبع موضوعي إلى حد كبير.أنا شخصيا لا أعتقد أن هذا صحيح تماما سواء.
يجعلك أفضل كائن واع.
يجب أن تكون كثيفة ، ولكن ما زلت لا تحصل عليه.هل هناك أي أمثلة فعلية من التطبيق صغير مكتوب في لغة وظيفية مثل F# حيث يمكنك إلقاء نظرة على التعليمات البرمجية المصدر و انظر كيف و لماذا كان من الأفضل استخدام هذا النهج من C# ؟
أود أن أشير إلى أن كل ما ذكرته عن اللغات الوظيفية معظم الناس كانوا يقولون عن وجوه المنحى لغات منذ حوالي 20 عاما.في ذلك الوقت كان من الشائع جدا أن نسمع عن OO:
* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways
التغيير يجب أن يأتي من مكان ما.مغزى و أهمية التغيير سوف تجعل من نفسها يحدث بغض النظر عما إذا كان الأشخاص الذين تم تدريبهم في وقت سابق من التقنيات ترى أن التغيير ليس من الضروري.هل تعتقد أن تغيير OO كانت جيدة على الرغم من كل الناس الذي كانوا ضدها في ذلك الوقت ؟
F# قد قبض على لأن مايكروسوفت في دفع ذلك.
برو:
- F# سوف يكون جزء من الإصدار القادم من برنامج Visual Studio
- مايكروسوفت بناء المجتمع لبعض الوقت الآن - الانجيليين, الكتب, الاستشاريين التي تعمل مع العملاء البارزة, تعرض كبير في MS المؤتمرات.
- F# هو من الدرجة الأولى .صافي اللغة و هو أول وظيفية اللغة التي تأتي مع كبيرة حقا مؤسسة (وليس أن أقول أن Lisp, هاسكل, إرلانج ، سكالا ، OCaml يكن لديك الكثير من المكتبات ، فهي ليست كاملة .نت)
- دعم قوي على التوازي
كونترا:
- F# من الصعب جدا أن تبدأ حتى إذا كنت جيدة مع C#.صافي - على الأقل بالنسبة لي :(
- فإنه من المحتمل أن يكون من الصعب العثور على جيد و# المطورين
لذا أعطي 50:50 فرصة F# لتصبح مهمة.الفنية الأخرى اللغات لن يجعل ذلك في المستقبل القريب.
أعتقد أن أحد الأسباب هو أن بعض الناس يشعرون بأن أهم جزء من ما إذا كانت اللغة سوف تكون مقبولة هو كيف جيدة اللغة.للأسف الأمور نادرا ما تكون بسيطة جدا.على سبيل المثال, أنا أزعم أن العامل الأكبر وراء بايثون القبول ليس اللغة نفسها (على الرغم من أن هو مهم جدا).أكبر سبب لماذا الثعبان هو شعبية جدا هو ضخم المكتبة القياسية و حتى المجتمع أكبر من 3rd الطرف المكتبات.
لغات مثل Clojure أو F# قد يكون استثناء من القاعدة على اعتبار أنهم بنيت على JVM/CLR.ونتيجة لذلك, أنا لا أملك جوابا لهم.
معظم التطبيق يمكن حلها في [أدخل اللغة المفضلة لديك, نموذج, الخ.هنا].
على الرغم من أن هذا صحيح ، أدوات مختلفة يمكن استخدامها لحل المشاكل المختلفة.وظيفية فقط يسمح أخرى عالية (أعلى من ذلك؟) مستوى التجريد الذي يسمح القيام بعملنا على نحو أكثر فعالية عند استخدامها بشكل صحيح.
يبدو لي أن هؤلاء الناس الذين لم يتعلموا اللثغة أو مخطط الجامعي الآن اكتشاف ذلك.كما هو الحال مع الكثير من الأشياء في هذا المجال هناك ميل إلى الضجيج وخلق توقعات عالية...
وسوف تمر.
البرمجة الوظيفية كبيرة.ومع ذلك, انها لن تأخذ أنحاء العالم.C, C++, Java, C#, وما إلى ذلك سوف يكون لا يزال حولها.
ما سوف يأتي من هذا أعتقد هو أكثر عبر قدرة اللغة - على سبيل المثال تنفيذ الأشياء في لغة وظيفية ثم إعطاء الوصول إلى الأشياء التي في اللغات الأخرى.
عند قراءة "التيار المقبل لغة البرمجة:مطور لعبة منظور" تيم سويني ، Epic Games, كانت فكرتي الأولى - يجب أن تعلم هاسكل.
الأشياء تتحرك في التوجيه الوظيفي لفترة من الوقت.اثنين باردة جديدة للأطفال في السنوات القليلة الماضية ، روبي وبايثون, كلاهما جذريا أقرب إلى اللغات الوظيفية مما جاء من قبلهم — لدرجة أن بعض Lispers بدأت دعم واحد أو الآخر بأنها "قريبة بما فيه الكفاية."
و مع المتوازية الأجهزة وضع الضغط التطوري على الجميع — و اللغات الوظيفية في أفضل مكان للتعامل مع التغييرات — انها ليست بعيدة قفزة كما كانت تعتقد أن هاسكل أو F# سوف يكون الشيء الكبير المقبل.
هل تم بعد تطور لغات البرمجة في الآونة الأخيرة ؟ كل إصدار جديد من جميع لغات البرمجة التيار يبدو أن تقترض المزيد والمزيد من الميزات من البرمجة الوظيفية.
الإغلاق, وظائف مجهولة ، ويمر وإعادة وظائف القيم المستخدمة لتكون غريبة ميزات لا يعرفها إلا Lisp و مل المتسللين.ولكن تدريجيا, C#, Delphi, Python, Perl, Javascript, إضافة دعم الإغلاق.ليس من الممكن لأي القادمة اللغة أن تؤخذ على محمل الجد من دون إغلاق.
عدة لغات أبرزها Python, C#, و روبي لديك الوطنية لدعم قائمة comprehensions و قائمة المولدات.
مل رائدة في البرمجة العامة في عام 1973 ، ولكن دعم الأدوية ("حدودي تعدد الأشكال") أصبح معيار الصناعة في آخر 5 سنوات أو نحو ذلك.إذا كنت أتذكر بشكل صحيح ، Fortran دعم الأدوية في عام 2003 ، تليها جافا 2004, C# في عام 2005 ، دلفي في عام 2008.(أنا أعرف C++ دعمت قوالب منذ عام 1979 ، ولكن 90% من المناقشات حول C++'s الخاصة بلبنان تبدأ مع "هنا يكون هناك الشياطين".)
ما يجعل هذه الميزات جذابة للمبرمجين ؟ وينبغي بصراحة واضحة: فإنه يساعد المبرمجين كتابة كود أقصر.جميع اللغات في المستقبل سوف تدعم -- على الأقل -- الإغلاق إذا كانوا يريدون البقاء تنافسية.في هذا الصدد, البرمجة الوظيفية بالفعل في التيار الرئيسي.
معظم التطبيقات هي بسيطة بما فيه الكفاية تحل في العادي OO الطرق
الذي يقول لا يمكن استخدام البرمجة الوظيفية لأشياء بسيطة جدا ؟ ليس كل برنامج وظيفي يحتاج إلى مترجم ، نظرية المعايرة القياسية ، أو المتوازية الاتصالات التبديل.أنا بانتظام استخدام F# المخصصة بخس البرامج النصية بالإضافة إلى أكثر المشاريع تعقيدا.
إنه على اصطياد لأنها أفضل أداة في جميع أنحاء للتحكم في التعقيد.انظر:
- الشرائح 109-116 سيمون بيتون جونز الحديث "طعم هاسكل"
- "التيار المقبل لغة البرمجة:مطور لعبة منظور" تيم سويني
أنا أتفق مع النقطة الأولى, ولكن تغير الزمن.الشركات سوف تستجيب ، حتى لو تأخرت تبنته ، إذا رأوا أن هناك ميزة قد يكون.الحياة الديناميكية.
كانوا التدريس هاسكل و مل في جامعة ستانفورد في أواخر 90s.أنا متأكد من أن أماكن مثل كارنيجي ميلون, MIT, Stanford, وغيرها من المدارس الجيدة يتم عرضها على الطلاب.
أوافق على أن معظم "فضح قواعد البيانات العلائقية على شبكة الإنترنت" تطبيقات سوف تستمر في هذا المنوال لفترة طويلة.Java EE, .صافي, RoR, و PHP وقد تطورت بعض جيدة حلول لتلك المشكلة.
كنت قد ضربت على شيء مهم:قد تكون المشكلة التي لا يمكن حلها بسهولة عن طريق الوسائل الأخرى التي من شأنها تعزيز البرمجة الوظيفية.ماذا سيكون ؟
سوف ضخمة متعددة النوى والأجهزة والحوسبة السحابية دفعهم على طول ؟
لأن FP له فوائد كبيرة من حيث الإنتاجية والاعتمادية والصيانة.العديد من النواة قد يكون القاتل التطبيق أن يحصل أخيرا الشركات الكبرى للتبديل على الرغم من كميات كبيرة من التعليمات البرمجية القديمة.وعلاوة على ذلك, حتى التجارية الكبيرة لغات مثل C# هي أخذ على وظيفية متميزة نكهة نتيجة العديد من الشواغل الأساسية - الآثار الجانبية ببساطة لا تناسب بشكل جيد مع التزامن والتوازي.
أنا لا أوافق على أن "طبيعية" المبرمجين لن تفهم ذلك.هم كما هم في نهاية المطاف فهم OOP (الذي هو مجرد غامضة و غريبة ، إن لم يكن أكثر من ذلك).
كما أن معظم الجامعات لا يعلمون FP, كثير حتى تعلم أنها أول دورة البرمجة.
نجاح باهر هذا هو مناقشة مثيرة للاهتمام.أفكاري على هذا:
FP يجعل بعض المهام البسيطة نسبيا (مقارنة مع أي-FP اللغات).لا شيء-FP اللغات بدأت تأخذ الأفكار من FP, لذلك أظن أن هذا الاتجاه سوف يستمر وسوف نرى المزيد من الدمج التي يجب أن تساعد الناس على تحقيق قفزة إلى FP أسهل.
أنا لا أعرف ما إذا كان سيتم القبض على أم لا, ولكن من التحقيقات وظيفية اللغة هو بالتأكيد يستحق التعلم ، سوف تجعلك أفضل مبرمج.مجرد فهم المرجعي الشفافية يجعل الكثير من قرارات التصميم أسهل بكثير - مما أدى برامج أسهل بكثير عن سبب.في الأساس, إذا واجهت مشكلة ، ثم فإنه يميل إلى أن يكون مشكلة مع الإخراج من وظيفة واحدة, بدلا من مشكلة مع inconsistant الدولة ، والتي يمكن أن يكون ناجما عن أي من مئات من الطبقات/طرق/وظائف في imparative اللغة مع آثار جانبية.
الجنسية طبيعة FP خرائط أكثر بطبيعة الحال إلى عديمي الجنسية طبيعة شبكة الإنترنت ، وبالتالي اللغات الوظيفية تصلح أكثر سهولة أكثر أناقة ، راحة webapps.على النقيض مع جافا .صافي الأطر التي تحتاج إلى اللجوء إلى فظيعة القبيح الخارقة مثل VIEWSTATE و مفاتيح جلسة للحفاظ على طلب الدولة ، والحفاظ على (أحيانا تماما راشح) التجريد من جليل بد اللغة على أساسا عديمي الجنسية الوظيفية منصة مثل شبكة الإنترنت.
و أيضا المزيد من عديمي الجنسية التطبيق الخاص بك أكثر سهولة ويمكن أن تصلح المعالجة المتوازية.مهمة جدا على شبكة الإنترنت, إذا كان موقع الويب الخاص بك يحدث الحصول على شعبية.انها ليست دائما واضحة إلى مجرد إضافة المزيد من الأجهزة إلى موقع للحصول على أداء أفضل.
وجهة نظري هو أنه قبض على الآن أن مايكروسوفت دفعت الأمر أبعد من ذلك بكثير في التيار الرئيسي.بالنسبة لي انها جذابة بسبب ما يمكن القيام به بالنسبة لنا لأنه تحديا جديدا بسبب فرص العمل أنها تستاء من أجل المستقبل.
يتقن مرة واحدة سيكون أداة أخرى إلى مزيد من المساعدة تجعلنا أكثر إنتاجية المبرمجين.
نقطة ضائعة في هذا النقاش هو أن أفضل نوع الأنظمة التي وجدت في المعاصرة FP اللغات.ما هو أكثر من ذلك ، المجمعين يمكن أن نستنتج كلها (أو معظمها على الأقل) أنواع تلقائيا.
ومن المثير للاهتمام أن أحد ينفق نصف الوقت في كتابة أسماء نوع عند البرمجة جافا, جافا بعد حتى الآن لا اكتب آمنة.في حين قد لا يكتب أنواع في هاسكل programm (باستثناء كنوع من مترجم فحص وثائق) و الكود هو 100 ٪ نوع آمنة.
بالإضافة إلى إجابات أخرى, صب الحل في الوظيفية البحتة حيث القوات واحد لفهم المشكلة بشكل أفضل.على العكس من ذلك ، التفكير في نمط وظيفي تطوير أفضل* مهارات حل المشاكل.
*إما لأن الفنية النموذج هو أفضل أو لأنها سوف تحمل إضافية زاوية الهجوم.
