من يجب أن أسأل عن F # ، إن لم يكن الشخص الذي خصص موقعًا تفصيليًا على هذه اللغة؟
ابتكر سكوت فلاشين المورد
"F # for Fun and Profit" ، المألوف لدى العديد من سكان Habra: من Habré قاموا بترجمة
سلسلة من المقالات "التفكير الوظيفي"
ومقال "البرمجة الموجهة للسكك الحديدية" من هناك.
وفي نوفمبر ، سيتحدث في مؤتمرنا DotNext في موسكو مع
تقرير "قوة التكوين". تحسبا لهذا الكلام ، سألناه عن F # والبرمجة الوظيفية بشكل عام.
- دعنا نذهب من البداية: ماذا فعلت قبل البرمجة الوظيفية ، وكيف أتيت إلى F # وكيف قمت بإنشاء الموقع؟- أنا رجل في سن الجليلة ، وعندما كنت في الجامعة ، لم تكن هناك برامج منفصلة لعلوم الكمبيوتر بعد. تلقيت تعليماً رياضياً ، لكنني لم أرغب في ممارسة الرياضيات ، لذا عملت بعد الجامعة لمدة 10 سنوات في مجموعة متنوعة من الوظائف ، بما في ذلك نجار.
في أحد الأيام الجميلة في أواخر الثمانينيات ، اشترى والدي جهاز كمبيوتر ، CP / M Kaypro ، مع قدر ضئيل من الذاكرة وأقراص مرنة بحجم 5.25 بوصة لعمله. كان هذا قبل ظهور Windows ، لذلك وقفت DOS عليه. كان عليها أن بدأت البرمجة. كنت منخرطاً في قواعد البيانات ، في البداية بالنسبة لوالدي ، لقد كان بحاجة لذلك من أجل عمله. ثم بدأت في القيام بذلك باحتراف.
كانت لغتي الأولى هي Turbo Pascal ، وفي عام 1989 أو 1990 قابلت Smalltalk ، وقد أعجبتني حقًا ، فهي لا تزال واحدة من اللغات المفضلة لدي. حلت وظيفة واحدة محل وظيفة أخرى ، وفي النهاية ، مثل معظم المبرمجين ، حصلت على وظيفة في شركة كبيرة لكتابة تطبيقات الأعمال المملة (أسميها "BLOBs": تطبيقات خط الأعمال الممل). ولفترة طويلة جدا كان يفعل ذلك تماما.
لفترة من الوقت كتبت في بيثون ، حوالي 10 سنوات - في C #. وفي عام 2011 ، أي منذ وقت ليس ببعيد ، قررت أنني سئمت من عملي وسيكون من الجيد تجربة شيء جديد ؛ لذلك أردت أن أفعل البرمجة الوظيفية. اتضح أن Visual Studio لدي بالفعل لغة وظيفية ، لذلك حاولت أن أفهم F #. في البداية بدا الأمر غريبًا جدًا ، لم أكن أفهم شيئًا ، كان مختلفًا تمامًا عن كل شيء عملت معه من قبل.
كان هناك العديد من المدونات الجيدة على F # ، ولكن كان هناك عدد قليل جدًا منها ، ولم يكن هناك وثائق كافية أيضًا. نتيجة لذلك ، قدم لي أصدقائي نصيحة ممتازة: إذا كنت ترغب في دراسة شيء ما بشكل صحيح ، فحاول البدء في تعليم الآخرين عنه ، لأنه يجعلك تفهم الموضوع جيدًا. بالإضافة إلى ذلك ، لقد نصحت ببدء تشغيل مدونة ، وهذا يسمح لي بالتميز بين المبرمجين الآخرين.
بشكل عام ، بدأت في عام 2012 مدونة "F # من أجل المتعة والربح" وبدأت في نشر مقالات فيها في كل مرة تعلمت فيها شيئًا جديدًا عن F #. الآن هناك عدة مئات من الصفحات ، وقد اكتسب شعبية كبيرة. في البداية كانت مجرد هواية ، لقد عملت عليها في وقت فراغي. وقبل حوالي 3 أو 4 سنوات ، قررت ترك وظيفتي وأصبح مستشارًا مستقلًا. في العام السابق ، كتبت كتابًا ، والذي تحول أيضًا إلى شعبية كبيرة. وهكذا فإن معرفتي بـ F # حدثت.
- كيف تعمل كصحفية مستقلة مع F # ، أم لا؟- بشكل أساسي ، F # ، على الرغم من الحديث عمومًا ، ما الذي سيدفعون مقابله - لهذا السبب أنصح
* يضحك * . إذا كنت بحاجة إلى المال ، لكن شخصًا ما يعمل على C # ، ويبدو الأمر مثيراً للاهتمام ، فأنا أعتبره. وفي العام الماضي ، عملت مع بيثون لمدة ثلاثة أشهر. ما يهمني ليس اللغة ، ولكن ما هي المشكلة الخاصة التي يجب حلها. أحب أن أدرس ، وعندما يتم تعيينك لحل مشكلة ما ، عليك أن تصبح ، إن لم تكن خبيراً ، ثم تقوم على الأقل بترتيب مجال جديد.
وبهذه الطريقة اضطررت إلى دراسة اقتصاديات العقارات ومخاطر التأمين. أعتقد أنه لا يمكن كتابة التعليمات البرمجية الجيدة إلا عندما يكون لديك فهم جيد للموضوع الذي تقوم به وليس فقط كتابة ما يقوله الآخرون لك. بالنسبة لي ، هذه هي الأكثر إثارة للاهتمام - ليست لغة ، ولكن مشكلة.
- في روسيا ، على الرغم من أن بعض المطورين مهتمون بـ F # ، إلا أن التعامل مع هذه اللغة أمر صعب: من الصعب العثور على مطور أو استبداله بدلاً من C #. وتلك الشركات التي تعمل معها ، كيف يتم حلها في F #؟- هناك حالتان شائعتان. الخيار الأول هو عندما تستخدم الشركة بالفعل F # ، وعادة ما يكون لديهم نوع من المشروع التجريبي. يتصلون بي ويطلبون مني مساعدتهم في إطلاق هذا المشروع وتعليمهم اللغة. عادة ما يكونون مستعدين لقضاء حوالي ستة أشهر في مثل هذا المشروع لمعرفة ما إذا كانوا يريدون القيام بذلك بشكل أكبر.
بالإضافة إلى ذلك ، أنا منخرط في تعليم الناس التصميم القائم على المجال ، وهنا F # ليس في دائرة الضوء ، لكنني استخدمه كلغة. أعرض للمبرمجين المعتادين على C # مقدار أقصر من نفس الرمز في F # مقارنةً بـ C #. وهذا هو ، أنا بهدوء تعزيز اللغة. يساعدك على عدم التبديل إلى F # بالكامل ، ويمكنك كتابة نموذج مجال في F # ، وكل شيء آخر في C #.
- أنت تقول أن C # و F # يمكن استخدامها معًا. لكن في C # ، غالبًا ما يتم استخدام إطار الكيان أو NHibernate أو شيء مشابه. وبين المطورين على F # هذا أقل شعبية. كيف تمزج هذه اللغات مع الأخذ في الاعتبار الاختلاف في النهج؟- إحدى الشركات التي عملت معها تستخدم Entity Framework. لقد حاولوا التبديل إلى بنية الموانئ والمحولات ، أي لإزالة جميع عمليات الإدخال / الإخراج من جوهر البنية. لهذا ، فإن إطار الكيان سيء للغاية. في مثل هذه الحالات ، من المريح استخدام شيء مثل Dapper ، والذي يسمح لك بعدم التعامل مع SQL في منتصف التعليمات البرمجية الخاصة بك. من بين أمور أخرى ، وهذا يجعل الاختبار أسهل.
دعهم لا يستخدمون البرمجة الوظيفية ، لكن الموقف لا يزال يدفعهم إلى الحصول على مجموعة نظيفة من البرنامج ، والاحتفاظ بقاعدة البيانات في مكان ما على الهامش. إذا تحول التفكير إلى هذا التنسيق ، فهذه خطوة مهمة نحو التخلي عن الكيان. في مثل هذه الشركة ، في الحقيقة ، ما كنت لأغير شيئًا. لا يمكنك إجبار الناس على التغيير ، بل يجب عليهم التغيير. لا أحاول بيع نفسي وفرض على شخص ما بالطريقة التي أعتقد أنها الأفضل. عادة ما يرغب الناس بالفعل في التغيير ، وأنا أساعدهم في تحقيق ذلك. هل تفهم ماذا اقصد؟
- أي أن عملائك هم شركات ينتقلون بالفعل إلى نهج أكثر فاعلية.- حتى إذا كانوا يعملون مع C # ، فإنهم يتحولون إلى C # أكثر وظيفية ، ويبدأون في استخدام LINQ ، هياكل البيانات غير الثابتة ، وهذا بشكل عام ، يسير في هذا الاتجاه. لذلك ، بالنسبة لهم ، لم يعد التحول إلى F # قفزة كبيرة.
هي مهن مطور ونجار مماثلة
- لديك موضوع مثير للاهتمام على تويتر يقارن بين عمل مبرمج ونجار. أود أن أسأل عن "الوظيفية" ، بدءًا من هذا الموضوع. ولكن هل يمكنك أن تقول جوهر ذلك لقرائنا؟- يرغب المطورون في مقارنة أنفسهم بالمهندسين وتطوير البرمجيات - مع تشييد المباني أو الجسور. وهناك الكثير من النقاش حول ما إذا كانت البرمجة قريبة بالفعل من هذه الأنشطة ، أو ما إذا كانت مختلفة اختلافًا جذريًا. مثل ، لدينا متطلبات للمشروع تتغير كل يوم - عند بناء جسر ، ربما كل شيء خاطئ تماما؟ أم أنها حقا كذلك هناك أيضا؟
لكنني أعتقد أنه في هذا النزاع لا توجد إجابة واحدة صحيحة. لم أكن مهندسا قط ، لكنني كنت نجارًا. وأستطيع أن أقول إن النجارين لديهم الكثير من العمل المختلف ، يختلفون كثيرًا في الشكل ، وكل منهم يحتاج إلى مقاربة خاصة به.
على سبيل المثال ، في أحد الأعمال فعلت خزانات المطبخ. في أمريكا ، كلها موحدة تمامًا ، بنفس الحجم ، مصممة خصيصًا لبعضها البعض ، ويتم العمل باستخدام أدوات السلطة. من الضروري توفير بعض الجودة ، ولكن في أمريكا ، يتم عادةً التخلص من المطبخ القديم عندما يغير المنزل مالكه ، أي لن يعمل لفترة طويلة جدًا. لذلك في هذا العمل ، يرتبط كل شيء بالسرعة وتوفير التكاليف.
ثم قمت بمهمة أخرى ، حيث كنت بحاجة إلى استبدال شعاع كبير من خشب البلوط بحجم 6 بوصات في منتصف الغرفة بالمبنى ، الذي كان عمره من 400 إلى 500 عام. كان كل شيء على عكس ذلك: كان كل شيء منحنيًا ، ولا توجد زوايا قائمة ، ولإبداله ، كان من الضروري وضع قطعة خشب جديدة يدويًا بحيث يكون لها نفس الشكل القديم تمامًا. هذا يتطلب الكثير من الدقة.
أخيرًا ، كان هناك العمل الثالث الذي قمت فيه بالمناظر على المسرح. كانت مصنوعة من الخشب الرقائقي والخشب رقيقة جدا للدعائم.
فكرتي هي أن كل عمل يتطلب منهجه الخاص. في حالة خزائن المطبخ ، هناك حاجة إلى الدقة ، واستخدام أدوات الطاقة والنتائج القابلة للتكرار. في المنزل الخشبي القديم الذي تعمل فيه بنظام قديم ، من المهم أن تكون حريصًا ، لا تتعجل ، لا تحتاج إلى السرعة ، ولكن إلى صحة النتيجة. أخيرًا ، في حالة الزخارف ، أنت تخلق عمداً بنية هشة لا يجب أن تكون قوية ، غالبًا ما يتعين عليك قصها وتجميعها مرة أخرى في بضع دقائق ، ولا تستمر هذه الهياكل إلى الأبد.
عندما يقولون أن البرمجة مماثلة للهندسة ، فإن هذا ينطبق فقط على أنواع معينة من البرمجة. على سبيل المثال ، إذا كتبت برنامجًا يتحكم في الطائرة ، فعليك أن تكون حذرًا للغاية وأن تحقق دقة عالية جدًا. شيء مختلف تمامًا هو برنامج نصي مؤلف من سطر واحد للبحث عن الملفات ، وهذا أشبه بإنشاء مشهد. ليس هناك فائدة في قضاء 20 ساعة لإثبات أن هذا البرنامج النصي يعمل وكتابة 1000 وحدة اختبارات لذلك. يجب ألا يستغرق العمل أكثر من 5 دقائق. وعندما تعمل مع نظام موروث ، فأنت تحتاج إلى ملاءمة التعليمات البرمجية الخاصة بك مع النظام الحالي قدر الإمكان ، حيث أن إعادة التوطين الكبيرة غير مرغوب فيها هنا.
وهذا هو ، في كل حالة ، السياق مهم. في بعض الأحيان تحتاج إلى التخطيط كثيرًا ، والتفكير كثيرًا في المشروع ، وكتابة الكثير من الاختبارات. في حالات أخرى ، يكفي عمل شيء ما. كثير من الناس يفتقرون إلى المرونة في هذا الصدد ، فهم يعتقدون أنه إذا لم تستخدم اختبارات الوحدات أو لا تستخدم لغة برمجة ، فأنت لست محترفًا. في الواقع ، فكرة أن كل هذا يتوقف على السياق واضحة للغاية. من المثير للدهشة ، كيف يصر بعض المبرمجين بعناد على أفكارهم ، وإذا انحرفت على الأقل عن أفكارهم ، فأنت على الفور تُرسل إلى القائمة السوداء. في رأيي ، هذا غبي.
- أنت تقول أن النشاط بالنسبة للمراقب الخارجي يبدو موحدًا ، لكن عندما ترى ذلك من الداخل ، يتم الكشف عن حالات مختلفة تمامًا. وأود أن أسأل: هل هو نفسه مع البرمجة الوظيفية؟ أولئك الذين ينظرون من الخارج لديهم صورة نمطية مشتركة ، ولكن في الواقع هناك اختلافات هائلة؟- هذا صحيح. من الخارج قد يبدو أن جميع "الموظفين" يفكرون على حد سواء ، ولكن هناك العديد من المجموعات المختلفة التي تتجادل مع بعضها البعض: أنصار هاسكل ، إف # ، كلوجور ، إلم. حتى داخل F # ، يوجد خلاف قوي بشأن الاتجاه الذي يجب أن تتطور به هذه اللغة - في حالة محاولة تقليد Haskell أو يجب أن تكون سهولة الاستخدام أولوية. إذاً أنت على صواب ، داخل هذا المجال أكثر تنوعًا مما يتخيله المراقبون الخارجيون.
- بالنسبة للاختلافات في عمل النجار ، أعطيت أمثلة واضحة جدًا. هل يمكنك توضيح الاختلافات في البرمجة الوظيفية مع أمثلة محددة أيضًا؟- هناك مدرسة للبرمجة الوظيفية ، والتي تعتقد أنك بحاجة لمحاولة إثبات كل شيء ، وحتى يكون كل شيء مثاليًا من الناحية الرياضية. تستخدم هذه المدرسة الكثير من المصطلحات الرياضية ، على سبيل المثال ، "monoids" أو "monads". هؤلاء هم مستخدمي هاسكل بشكل أساسي ، والبيئة الأكاديمية مؤثرة للغاية.
وهناك أشخاص أكثر أهمية لتحقيق النتائج. إنهم لا يهتمون بالرياضيات بقدر ما يهتمون بالثبات وإزالة الإدخال / الإخراج في الأطراف. أفضل مثال على هذا النهج هو مجتمع الدردار. يشاركون بشكل أساسي في إنشاء تطبيقات الويب. على عكس المجموعة الأولى ، لا يستخدمون هنا المصطلحات الرياضية بوعي ، ويرفضون بوعي جزء من الوظيفة الموجودة في Haskell والتي يعتبرها مستخدمو Haskell أمرًا حيويًا.
بالإضافة إلى ذلك ، هناك خلاف بين مؤيدي الكتابة القوية والكتابة الديناميكية. من وجهة نظر الشخص العادي ، البرمجة الوظيفية هي شيء مثل Haskell أو F # ، ولكن بجانبها ، هناك لغات مثل Clojure التي لديها كتابة ديناميكية ونهج مختلف تمامًا لحل المشكلات. إذا قمت بجمع كل هذه الشركة المتنافرة في غرفة واحدة ، فيمكنهم القتال. أعتقد أن جميع الأساليب لها أسبابها الخاصة ، وعندما أعمل لدى شخص ما ، لا أخبرهم أن أسلوبهم خاطئ.
- كثيرون يشعرون بالخوف من "الطبيعة الأكاديمية" المذكورة ("F # له جذور في ML ، وهذا هو للحصول على أدلة علمية صارمة ، لكنني حل المشاكل الحقيقية هنا"). لكن اتضح أن الناس خائفون دون جدوى؟- بشكل عام ، يبدو غريباً لي أن الكثير من الناس اعتادوا على اعتبار الأكاديمية شيئًا سلبيًا. حسنًا ، هكذا ، كيف يعتبرها البعض سلبية ، والبعض الآخر - إيجابي.
الحقيقة هي أن العديد من التقنيات التي نستخدمها الآن في البرمجة قد نشأت في البيئة الأكاديمية ، على سبيل المثال ، جمع القمامة أو أنواعها. لذلك لا حرج في الأساليب الأكاديمية نفسها. سؤال آخر هو أن التركيز المفرط عليها يمكن أن يكون ضارًا ، لأن العلماء والمبرمجين لديهم أهداف مختلفة.
على الرغم من أن اللغات الوظيفية لها جذور أكاديمية ، يبدو لي القرار الواعي الصحيح بإخفاء هذا المنطق بلغات مثل F # و Elm. لذلك ، يستخدم F # ليس لإثبات النظريات ، ولكن لحل المشاكل الحقيقية ، إنها لغة براغماتية للغاية. وقد تحولت الجامعات الآن إلى لغات أكثر تعقيدًا ، مثل Coq و F * وما شابه. هم أكثر أكاديمية ، وتستخدم لإثبات النظريات.
كما قلت ، يقوم العلماء والمبرمجون بأشياء مختلفة. يقضي المبرمجون معظم وقتهم في قراءة وكتابة الملفات ، والعمل مع قواعد البيانات ، وعرض البيانات على الشاشة ، والتحقق من البيانات المدخلة ، وتحويلها ، وما إلى ذلك. لكن العلماء غير مهتمين بمثل هذه الأشياء. ولكن الحقيقة هي أن الأشياء التي كانت أكاديمية بحتة قبل 40 عامًا قد لا تكون كذلك اليوم.
- كما قلت أنت بنفسك فيما يتعلق بعمل النجار ، فإن الطرق المختلفة جيدة في سياقات مختلفة ، ولا توجد طرق عالمية. وبالتحديد ، F # مناسب أيضًا لمهام معينة. ما هي هذه المهام؟- نعم ، هذه بالتأكيد ليست لغة عالمية ، بالتأكيد لا أوصي باستخدامها على الإطلاق للجميع ، ستكون غبية. ولكن يبدو لي أن F # هو بديل ممتاز لـ C # - باستثناء المهام التي تتطلب أداءً عاليًا للغاية. تعتمد البرمجة في F # على نهج مختلف تمامًا: المناعة ، والمساواة الهيكلية ، والاعتمادية الصريحة ، و F # ليس لها قيم فارغة ، وما إلى ذلك. ويبدو لي أن هذا النهج مفيد أكثر بكثير في حل مشاكل البرمجة اليومية.
لذلك ، إذا كان الشخص يستخدم C # ، فعليه أن يسأل بالتأكيد عن F # ، وسوف تساعد هذه اللغة في تحسين الكود. بالنسبة إلى مجالات التطبيق الأخرى ، يبدو لي أن F # سيكون مناسبًا للعديد من المهام التي تستخدم Python الآن. F # و Python متشابهان للغاية ، ويبدو لي أن F # لديه إمكانات كبيرة لمعالجة البيانات. في الوقت الحالي ، لا يزال هناك المزيد من العمل الذي يتعين القيام به في هذا المجال ، ولكن ربما في غضون سنوات قليلة ، سيستخدم الناس F # في العديد من الأشياء المتعلقة بالبيانات الكبيرة وعلوم البيانات ، والتي تستخدم Python الآن.
أخيرًا ، F # مناسب جدًا للعمل مع JavaScript. بشكل عام ، لا يريد أحد العمل مباشرة مع JavaScript ، لذلك هناك العديد من اللغات التي يتم تجميعها في JS: على سبيل المثال ، ReasonML (التي تعمل على OCaml) و Fable (التي تعمل على F #). أنا شخصياً أفضل العمل مع أي من هذه الخيارات بدلاً من التعامل مع JavaScript ، لذلك عند العمل على الواجهة الأمامية ، سأختار شيء مثل Fable. هذه هي المجالات الثلاثة الرئيسية التي تظهر فيها F # أفضل جانب لها.
- كما لاحظت في تقريرك "F # for C # developers" ، فإن الشيء الرئيسي في اللغة ليس بناء الجملة ، ولكن الفلسفة. ولكن هنا تكمن الصعوبة بالنسبة لأولئك الذين يريدون أن يفهموا بسرعة "ما إذا كانت هذه اللغة تناسبني". يمكنك بالفعل فهم ما إذا كنت تحب بناء الجملة من خلال مقدمة سريعة. ولكن كم من الوقت يستغرق لفهم فلسفة اللغة؟- يمكن للشخص الذي يكتب في لغة C # اكتشاف لغة مثل Java أو Go بسرعة ، لأن معظم هذه اللغات القياسية لديها نموذج واحد إلزامي. يتطلب الانتقال منها إلى F # بالتأكيد الكثير من الجهد ، وهذا يوقف بعض الناس. في تجربتي ، أصبح F # أسهل بكثير في معرفة ما إذا كنت قد نسيت كل شيء تعرفه عن OOP لفترة. خلاف ذلك ، تبدأ في نقل جميع أنواع الأشياء من C # إلى F #.
بالنسبة للوقت ، فمن الممكن بالفعل في مكان ما خلال أسبوعين من التدريب البدء في كتابة رمز العمل ، وسيستغرق التعود على اللغة عدة أشهر أو أكثر. أخيرًا ، للحصول على مستوى جيد من الملكية ، فأنت بحاجة إلى مزيد من الوقت ، 6 أشهر ، وربما أكثر - وهذا إذا كنا نتحدث عن فرز جميع المكتبات ، والتعابير ، وما شابه ذلك.
ولكن بصراحة ، فإن التحول إلى F # ليس أكثر صعوبة من التبديل إلى Entity أو WPF. كما تتطلب الكثير من الوقت. لا تقلل من أهمية الجهود الضرورية ، لكن في بعض الأحيان يقولون إن هذا الانتقال يستغرق سنوات. أكرر: من أجل البدء في كتابة الكود ، يستغرق الأمر عدة أسابيع للراحة - عدة أشهر. أقول هذا من تجربتي الخاصة ومن تجربة الأشخاص الآخرين الذين تحدثت معهم.
هل أحتاج إلى معرفة C # قبل F #
- من الواضح أن معظم الذين يستخدمون F # جاءوا من C #. هل هناك الكثير ممن يأتون إلى تجربة F # دون تجربة C #؟— , , C#, C#. - , , F# .
, F# Python. , F# .NET, .NET C#. Visual Basic, C#. , , .
— C#, F#, , F# . ? LINQ , , , ?— , , , , , : ? ? . , , , . , , , F# , Programming Theory Concepts - .
— C# , F# ?— . , . , , . , - , Python JavaScript, .
, . JavaScript , F# . , . F# — , , C#, . F# .
— F# — «F# for fun and profit»? C#?— F#, . F#, . , , Railway Oriented Programming, Property Based Testing . , TypeScript Ruby, , F#. , , C#.
Fun and profit
— «F# » («F# for fun and profit») - , «». , -, ?— . . , F# , , . , , F#, , . F# .
- , — . , - Java . , , , . , , F# C# .
— «»: , , , .— , . , , , . .
StackOverflow , , F# , . , , , , C#. , - , , 10 . .
, , F#, F#. F#, , . , . , F# .
— , F# . ? , , F# . F# ?— , F# . , . - , . , , , . , . F# null; , ; . F# .
, F#, , , . C# — Visitor, Factory, Singleton, Bridge, F# , , , .
- . , , . , , , , , . Google Amazon — .
— , F# , — , , . ?— , . , , C# , , C#. , C#, null, , - . F# . , , , .
- - , , , . C# F#, , , . , , . , , F#, .
— , Microsoft F# ( C# ). ?— , Microsoft C#. , . — , Microsoft, , , Entity Framework Visual Studio. , Microsoft, Microsoft - — . , , Python Ruby. - , - , .
, F#, , , — F# , . Microsoft, . , Ionide, VS. , F# , Microsoft. , , , , , Microsoft . Microsoft , , .
— Haskell. F# — .NET-, ?— , - , , Smalltalk, - . F# - , .NET. Java, Scala . , , C#, Java, F# , Scala, .
Haskell, . Haskell , , F#. F# , Haskell . , , , API Java, .NET JavaScript. API .NET , , API .
— . F#, , : , , ?— , F# . , , , . , . F# , , C#. , Haskell, - , .
, , , .
F# , , . , -, .
, - , , — , ? , , , . F#, C#, , . . - , F#.
, F# , , .
DotNext «The Power of Composition». , F#: , , , . , .