Siapa yang harus saya tanyakan tentang F #, jika bukan orang yang telah mendedikasikan situs web terperinci untuk bahasa ini?
Scott Vlashin menciptakan sumber daya
"F # untuk Kesenangan dan Keuntungan" , yang akrab bagi banyak penduduk Habra: dari Habré mereka menerjemahkan kedua
seri artikel "Pemikiran Fungsional" dan
artikel "Pemrograman Berorientasi Kereta Api" dari sana.
Dan pada bulan November, dia akan berbicara pada konferensi DotNext kami di Moskow dengan
laporan "Kekuatan komposisi". Dan untuk mengantisipasi pidato ini, kami bertanya kepadanya tentang F # dan pemrograman fungsional secara umum.
- Mari kita mulai dari awal: apa yang Anda lakukan sebelum pemrograman fungsional, bagaimana Anda sampai di F # dan bagaimana Anda membuat situs?- Saya seorang pria yang terhormat, dan ketika saya masih di universitas, belum ada program ilmu komputer yang terpisah. Saya menerima pendidikan matematika, tetapi tidak ingin melakukan matematika, jadi setelah universitas saya bekerja selama sekitar 10 tahun di berbagai pekerjaan, termasuk seorang tukang kayu.
Suatu hari di akhir 1980-an, ayah saya membeli komputer, CP / M Kaypro, dengan jumlah memori yang kecil dan floppy disk 5,25 inci untuk pekerjaannya. Ini sebelum Windows muncul, jadi DOS berdiri di atasnya. Di situlah saya mulai pemrograman. Saya terlibat dalam database, pada awalnya untuk ayah saya, dia membutuhkan ini untuk pekerjaannya. Dan kemudian saya mulai melakukannya secara profesional.
Bahasa pertama saya adalah Turbo Pascal, dan pada tahun 1989 atau 1990 saya bertemu Smalltalk, dan saya sangat menyukainya, itu masih salah satu bahasa favorit saya. Satu pekerjaan menggantikan yang lain, dan pada akhirnya, seperti kebanyakan programmer, saya mendapat pekerjaan di sebuah perusahaan besar untuk menulis aplikasi bisnis yang membosankan (saya menyebutnya "Gumpalan": Boring Line-of-Business application). Dan untuk waktu yang sangat lama dia melakukan hal itu.
Untuk sementara saya menulis dengan Python, sekitar 10 tahun - dalam C #. Dan pada tahun 2011, itu, belum lama ini, saya memutuskan bahwa saya bosan dengan pekerjaan saya dan akan menyenangkan untuk mencoba sesuatu yang baru; jadi saya ingin melakukan pemrograman fungsional. Ternyata Visual Studio saya sudah memiliki bahasa fungsional, jadi saya mencoba memahami F #. Dan pada awalnya itu terasa sangat aneh, saya tidak bisa mengerti apa-apa, itu sangat berbeda dari semua yang saya kerjakan sebelumnya.
Ada beberapa blog bagus di F #, tetapi ada sangat sedikit, dan tidak ada dokumentasi yang cukup juga. Sebagai hasilnya, teman-teman saya memberi saya nasihat yang sangat baik: jika Anda ingin mempelajari sesuatu dengan benar, cobalah untuk mulai mengajar orang lain tentang hal itu, karena itu membuat Anda sangat memahami topiknya. Selain itu, saya disarankan untuk memulai blog, ini memungkinkan saya untuk menonjol di antara programmer lainnya.
Secara umum, pada tahun 2012 saya memulai blog "F # untuk kesenangan dan keuntungan" dan mulai menerbitkan artikel di dalamnya setiap kali saya belajar sesuatu yang baru tentang F #. Sekarang ada beberapa ratus halaman, dan itu telah mendapatkan popularitas besar. Pada awalnya itu hanya hobi, saya mengerjakannya di waktu luang saya. Dan sekitar 3 atau 4 tahun yang lalu, saya memutuskan untuk berhenti dari pekerjaan saya dan menjadi konsultan lepas. Tahun sebelumnya, saya menulis sebuah buku, yang ternyata juga cukup populer. Jadi, kenalan saya dengan F # terjadi.
- Bagaimana Anda bekerja sebagai freelancer dengan F #, atau tidak hanya?- Pada dasarnya, F #, meskipun secara umum, apa yang akan mereka bayar - itu sebabnya saya menyarankan
* tertawa * . Jika saya butuh uang, tetapi seseorang telah bekerja pada C #, dan itu terlihat menarik, saya menerimanya. Dan tahun lalu, saya bekerja dengan Python selama tiga bulan. Yang penting bagi saya bukanlah bahasa, tetapi masalah khusus apa yang harus dipecahkan. Saya suka belajar, dan ketika Anda direkrut untuk memecahkan masalah, Anda harus menjadi, jika bukan seorang ahli, maka setidaknya memilah area baru.
Dengan cara ini saya harus mempelajari ekonomi real estat dan risiko asuransi. Saya percaya bahwa kode yang baik hanya dapat ditulis ketika Anda memiliki pemahaman yang baik tentang subjek yang Anda lakukan dan tidak hanya menulis apa yang orang lain katakan kepada Anda. Bagi saya, ini yang paling menarik - bukan bahasa, tapi masalah.
- Di Rusia, meskipun beberapa pengembang memiliki minat pada F #, bisnis dengan bahasa ini sulit: lebih sulit untuk menemukan atau mengganti pengembang daripada dengan C #. Dan perusahaan-perusahaan tempat Anda bekerja, bagaimana mereka dipecahkan dalam F #?- Ada dua situasi paling umum. Opsi pertama adalah ketika perusahaan sudah menggunakan F #, mereka biasanya memiliki semacam proyek percontohan. Mereka memanggil saya dan meminta saya untuk membantu mereka meluncurkan proyek ini dan mengajar mereka bahasa. Biasanya mereka siap untuk menghabiskan sekitar enam bulan pada proyek semacam itu untuk mencari tahu apakah mereka ingin melakukan ini lebih lanjut.
Selain itu, saya terlibat dalam mengajar orang desain berbasis domain, dan di sini F # tidak dalam sorotan, tapi saya menggunakannya sebagai bahasa. Saya menunjukkan kepada para programmer yang terbiasa dengan C # seberapa pendek kode yang sama dalam F # daripada di C #. Artinya, saya diam-diam mempromosikan bahasa. Ini membantu bahwa Anda tidak harus beralih ke F # sepenuhnya, Anda dapat menulis model domain dalam F #, dan segala sesuatu lainnya dalam C #.
- Anda mengatakan bahwa C # dan F # dapat digunakan bersama. Tetapi dalam C #, Kerangka Entitas, NHibernate, atau sesuatu yang serupa paling sering digunakan. Dan di antara pengembang di F # ini jauh lebih populer. Bagaimana cara menggabungkan bahasa-bahasa ini dengan mempertimbangkan perbedaan dalam pendekatan?- Salah satu perusahaan tempat saya bekerja menggunakan Entity Framework. Mereka mencoba untuk beralih ke arsitektur Ports and Adapters, yaitu, untuk menghapus semua operasi input / output dari inti arsitektur. Untuk ini, Kerangka Entitas sangat buruk. Dalam situasi seperti itu, jauh lebih nyaman untuk menggunakan sesuatu seperti Dapper, yang memungkinkan Anda untuk tidak berurusan dengan SQL di tengah-tengah kode Anda. Antara lain, ini membuat pengujian lebih mudah.
Biarkan mereka tidak menggunakan pemrograman fungsional, tetapi situasi masih mendorong mereka untuk memiliki inti bersih dari program, dan menyimpan database di suatu tempat di pinggiran. Jika pemikiran telah beralih ke format ini, maka ini adalah langkah penting menuju meninggalkan Entitas. Dalam perusahaan seperti itu, saya, pada kenyataannya, tidak akan mengubah apa pun. Anda tidak dapat memaksa orang untuk berubah, mereka sendiri harus menginginkan perubahan. Saya tidak mencoba menjual diri sendiri dan memaksakan pada seseorang dengan cara yang menurut saya adalah yang terbaik. Biasanya orang sudah ingin berubah, dan saya hanya membantu mereka mencapainya. Apakah Anda mengerti maksud saya?
- Artinya, pelanggan Anda adalah perusahaan yang sudah bergerak ke pendekatan yang lebih fungsional.- Bahkan jika mereka bekerja dengan C #, mereka beralih ke C # lebih fungsional, mulai menggunakan LINQ, struktur data yang tidak dapat diubah, yaitu, secara umum, pergi ke arah ini. Oleh karena itu, bagi mereka, beralih ke F # tidak lagi merupakan lompatan besar.
Apakah profesi seorang pengembang dan tukang kayu serupa?
- Anda memiliki utas menarik di Twitter yang membandingkan pekerjaan seorang programmer dan seorang tukang kayu. Saya ingin bertanya tentang "fungsionalisme", mulai dari utas ini. Tetapi bisakah Anda memberi tahu intisari dari itu untuk pembaca kami?- Pengembang suka membandingkan diri mereka dengan insinyur, dan pengembangan perangkat lunak - dengan konstruksi bangunan atau jembatan. Dan ada banyak perdebatan tentang apakah pemrograman benar-benar dekat dengan kegiatan ini, atau apakah mereka secara fundamental berbeda. Seperti, kami memiliki persyaratan untuk proyek berubah setiap hari - ketika Anda membangun jembatan, mungkin semuanya benar-benar salah? Atau benarkah demikian?
Tetapi saya percaya bahwa dalam perselisihan ini tidak ada jawaban yang benar. Saya tidak pernah menjadi insinyur, tetapi saya adalah seorang tukang kayu. Dan saya dapat mengatakan bahwa tukang kayu memiliki banyak pekerjaan yang berbeda, sangat berbeda dalam format, dan masing-masing membutuhkan pendekatan sendiri.
Misalnya, di salah satu karya saya membuat lemari dapur. Di Amerika, mereka semua sangat terstandarisasi, semuanya berukuran sama, disesuaikan satu sama lain, dan pekerjaan sedang dilakukan dengan alat-alat listrik. Penting untuk memberikan beberapa kualitas, tetapi di Amerika, dapur lama biasanya dibuang ketika rumah berganti pemilik, yaitu, ia tidak akan berfungsi untuk waktu yang sangat lama. Jadi dalam pekerjaan ini, semuanya terkait dengan kecepatan dan penghematan biaya.
Kemudian saya mendapat tugas lain, di mana saya perlu mengganti balok kayu ek besar 6 inci di tengah ruangan di gedung itu, yang usianya 400-500 tahun. Di sini semuanya berlawanan: semuanya melengkung, tidak ada sudut kanan, dan untuk menggantinya, perlu secara manual memasukkan potongan kayu baru sehingga bentuknya persis sama dengan yang lama. Ini membutuhkan banyak akurasi.
Akhirnya, ada karya ketiga di mana saya melakukan pemandangan untuk panggung. Mereka terbuat dari kayu lapis dan kayu yang sangat tipis untuk alat peraga.
Gagasan saya adalah bahwa setiap pekerjaan membutuhkan pendekatannya sendiri. Dalam hal lemari dapur, presisi, penggunaan alat-alat listrik dan hasil yang dapat direproduksi diperlukan. Di sebuah rumah kayu tua Anda bekerja dengan sistem warisan, penting untuk berhati-hati, tidak terburu-buru, Anda tidak perlu cepat, tetapi hasilnya benar. Akhirnya, dalam hal dekorasi, Anda sengaja membuat struktur rapuh yang tidak harus kuat, Anda sering harus memotongnya dan merakitnya lagi dalam beberapa menit, struktur seperti itu tidak bertahan selamanya.
Ketika mereka mengatakan bahwa pemrograman mirip dengan teknik, ini hanya berlaku untuk jenis pemrograman tertentu. Misalnya, jika Anda menulis perangkat lunak yang mengendalikan pesawat terbang, Anda harus sangat berhati-hati dan mencapai akurasi yang sangat tinggi. Hal yang sama sekali berbeda adalah skrip satu baris untuk mencari file, ini lebih seperti membuat pemandangan. Tidak ada gunanya menghabiskan 20 jam untuk membuktikan bahwa skrip ini berfungsi dan menulis 1000 unit tes untuk itu. Semua pekerjaan harus tidak lebih dari 5 menit. Dan ketika Anda bekerja dengan sistem yang diwarisi, Anda harus menyesuaikan kode Anda dengan yang ada sebanyak mungkin, refactoring besar tidak diinginkan di sini.
Artinya, dalam setiap kasus, konteks itu penting. Terkadang Anda perlu banyak merencanakan, berpikir banyak tentang suatu proyek, menulis banyak tes. Dalam kasus lain, itu sudah cukup untuk menyiapkan sesuatu. Banyak orang kurang fleksibel dalam hal ini, mereka percaya bahwa jika Anda tidak menggunakan tes unit atau tidak menggunakan bahasa pemrograman, maka Anda bukan seorang profesional. Bahkan, gagasan bahwa itu semua tergantung pada konteksnya cukup jelas. Anehnya, betapa keras kepala beberapa programer bersikeras pada ide-ide mereka, dan jika Anda setidaknya entah bagaimana menyimpang dari cita-cita mereka, Anda segera dikirim ke daftar hitam. Menurut saya, ini bodoh.
- Anda mengatakan bahwa untuk pengamat luar kegiatannya terlihat seragam, tetapi ketika Anda melihatnya dari dalam, kasus yang sama sekali berbeda terungkap. Dan saya ingin bertanya: apakah itu sama dengan pemrograman fungsional? Mereka yang melihat dari luar memiliki stereotip yang sama, tetapi sebenarnya ada perbedaan besar?- Benar. Dari luar mungkin tampak bahwa semua "fungsionaris" berpikir sama, tetapi ada banyak kelompok berbeda yang saling berdebat: pendukung Haskell, F #, Clojure, Elm. Bahkan di dalam F #, ada ketidaksepakatan yang kuat mengenai ke arah mana bahasa ini harus berkembang - jika Anda mencoba meniru Haskell atau seharusnya kemudahan penggunaan menjadi prioritas. Jadi Anda benar, di dalam bidang ini jauh lebih beragam daripada yang biasanya dibayangkan oleh pengamat luar.
- Untuk perbedaan dalam pekerjaan tukang kayu, Anda memberikan contoh yang sangat jelas. Bisakah Anda menggambarkan perbedaan dalam pemrograman fungsional dengan contoh spesifik juga?- Ada sekolah pemrograman fungsional, yang percaya bahwa Anda perlu mencoba membuktikan semuanya, dan agar semuanya sempurna secara matematis. Sekolah ini menggunakan banyak jargon matematika, misalnya, "monoids" atau "monads." Ini terutama adalah pengguna Haskell, dan lingkungan akademik sangat berpengaruh.
Dan ada orang yang lebih penting untuk mencapai hasil. Mereka tertarik tidak begitu banyak dalam matematika seperti pada kekebalan dan penghapusan I / O ke pinggiran. Contoh terbaik dari pendekatan ini adalah komunitas Elm. Mereka terutama terlibat dalam pembuatan aplikasi web. Berbeda dengan kelompok pertama, di sini mereka tidak secara sadar menggunakan jargon matematika, dan mereka secara sadar menolak bagian dari fungsi yang ada di Haskell dan yang menurut pengguna Haskell penting.
Selain itu, ada perselisihan antara pendukung pengetikan kuat dan pengetikan dinamis. Dalam pandangan awam, pemrograman fungsional adalah sesuatu seperti Haskell atau F #, tetapi selain itu, ada bahasa seperti Clojure yang memiliki pengetikan dinamis dan pendekatan yang sama sekali berbeda untuk menyelesaikan masalah. Jika Anda mengumpulkan semua perusahaan beraneka ragam ini dalam satu ruangan, mereka bisa bertarung. Saya pikir semua pendekatan memiliki alasan sendiri, dan ketika saya bekerja untuk seseorang, saya tidak memberi tahu mereka bahwa pendekatan mereka salah.
- Banyak yang takut dengan "sifat akademis" yang disebutkan ("F # berakar pada ML, yang untuk bukti ilmiah yang ketat, tapi saya menyelesaikan masalah nyata di sini"). Tapi ternyata orang takut sia-sia?- Secara umum, rasanya aneh bagi saya bahwa begitu banyak orang terbiasa menganggap akademis sebagai sesuatu yang negatif. Yaitu, bagaimana, beberapa menganggapnya negatif, yang lain - positif.
Faktanya adalah bahwa banyak teknologi yang sekarang kita gunakan dalam pemrograman telah muncul di lingkungan akademik, misalnya, pengumpulan atau jenis sampah. Jadi tidak ada yang salah dengan metode akademik itu sendiri. Pertanyaan lain adalah bahwa penekanan yang berlebihan pada mereka bisa berbahaya, karena para ilmuwan dan programmer memiliki tujuan yang berbeda.
Meskipun bahasa fungsional memiliki akar akademis, menurut saya keputusan sadar yang tepat untuk menyembunyikan logika ini dalam bahasa seperti F # dan Elm. Oleh karena itu, F # digunakan bukan untuk membuktikan teorema, tetapi untuk menyelesaikan masalah nyata, itu adalah bahasa yang sangat pragmatis. Dan universitas sekarang telah beralih ke bahasa yang lebih kompleks, seperti Coq, F * dan sejenisnya. Mereka jauh lebih akademis, dan digunakan untuk membuktikan teorema.
Seperti yang saya katakan, ilmuwan dan pemrogram melakukan hal yang berbeda. Pemrogram menghabiskan sebagian besar waktu mereka membaca dan menulis file, bekerja dengan database, menampilkan data di layar, memeriksa data yang dimasukkan, mengonversinya, dll. Tetapi para ilmuwan tidak tertarik pada hal-hal seperti itu. Tetapi kenyataannya adalah bahwa hal-hal yang murni akademis 40 tahun yang lalu mungkin tidak demikian hari ini.
- Seperti yang Anda sendiri katakan sehubungan dengan pekerjaan seorang tukang kayu, pendekatan yang berbeda baik dalam konteks yang berbeda, tidak ada pendekatan universal. Dan secara khusus, F # juga paling cocok untuk tugas-tugas tertentu. Apa tugas-tugas ini?- Ya, ini jelas bukan bahasa universal, saya pasti tidak akan merekomendasikan menggunakannya sama sekali untuk semua orang, itu akan bodoh. Tapi menurut saya F # adalah pengganti yang sangat baik untuk C # - dengan pengecualian tugas yang membutuhkan kinerja sangat tinggi. Pemrograman dalam F # didasarkan pada pendekatan yang sama sekali berbeda: kekebalan, kesetaraan struktural, dependensi eksplisit, F # tidak memiliki nilai nol, dan sebagainya. Dan menurut saya pendekatan ini jauh lebih berguna dalam menyelesaikan masalah pemrograman sehari-hari.
Karena itu, jika seseorang menggunakan C #, ia pasti harus bertanya tentang F #, bahasa ini akan membantu membuat kode lebih baik. Adapun bidang aplikasi lain, menurut saya F # akan cocok untuk banyak tugas yang sekarang digunakan Python. F # dan Python sangat mirip, dan menurut saya F # memiliki potensi besar untuk pemrosesan data. Untuk saat ini, masih ada banyak pekerjaan yang harus dilakukan di bidang ini, tetapi mungkin dalam beberapa tahun orang akan menggunakan F # untuk berbagai hal yang berkaitan dengan data besar dan ilmu data, yang sekarang digunakan Python.
Akhirnya, F # sangat nyaman untuk bekerja dengan JavaScript. Secara umum, tidak ada yang ingin bekerja secara langsung dengan JavaScript, jadi ada banyak bahasa yang dikompilasi di JS: misalnya, ReasonML (yang berjalan di OCaml) dan Fable (yang berjalan di F #). Secara pribadi, saya lebih suka bekerja dengan salah satu opsi ini daripada berurusan dengan JavaScript, jadi ketika bekerja di frontend, saya akan memilih sesuatu seperti Fable. Jadi ini adalah tiga area utama di mana F # menunjukkan sisi terbaiknya.
- Seperti yang Anda catat dalam laporan Anda “F # for C # developers”, hal utama dalam bahasa ini bukanlah sintaks, tetapi filosofi. Tetapi di sini letak kesulitan bagi mereka yang ingin cepat memahami "apakah bahasa ini cocok untuk saya." Anda sudah bisa mengerti jika Anda menyukai sintaks dengan pengantar cepat. Tetapi berapa lama untuk memahami filosofi bahasa?- Seseorang yang menulis dalam bahasa C # dapat dengan cepat mengetahui bahasa seperti Java atau Go, karena sebagian besar bahasa standar ini memiliki sekitar satu model imperatif. Pindah dari mereka ke F # pasti membutuhkan banyak usaha, dan ini menghentikan beberapa orang. Dalam pengalaman saya, F # jauh lebih mudah dipelajari jika untuk sementara Anda melupakan semua yang Anda ketahui tentang OOP. Kalau tidak, Anda mulai mentransfer segala macam hal dari C # ke F #.
Adapun waktu, di suatu tempat dalam dua minggu pelatihan sudah mungkin untuk mulai menulis kode kerja, dan itu akan memakan waktu beberapa bulan untuk lebih atau kurang terbiasa dengan bahasa tersebut. Akhirnya, untuk tingkat kepemilikan yang baik Anda perlu lebih banyak waktu, 6 bulan, mungkin lebih - ini adalah jika kita berbicara tentang memilah semua perpustakaan, idiom dan sejenisnya.
Tapi jujur, beralih ke F # tidak lebih sulit daripada beralih ke Entity atau WPF. Mereka juga membutuhkan banyak waktu. Jangan meremehkan upaya yang diperlukan, tetapi kadang-kadang mereka mengatakan bahwa transisi ini membutuhkan waktu bertahun-tahun. Saya ulangi: untuk mulai menulis kode, perlu beberapa minggu untuk merasa nyaman - beberapa bulan. Saya mengatakan ini baik dari pengalaman saya sendiri maupun dari pengalaman orang lain yang berbicara dengan saya.
Apakah saya perlu tahu C # sebelum F #
- Jelas bahwa sebagian besar dari mereka yang menggunakan F # berasal dari C #. Apakah ada banyak yang datang ke F # tanpa pengalaman 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#: , , , . , .