Apakah ada metodologi rekayasa perangkat lunak untuk pemrograman fungsional? [Tutup]


203

Rekayasa Perangkat Lunak seperti yang diajarkan hari ini sepenuhnya berfokus pada pemrograman berorientasi objek dan pandangan berorientasi objek 'alami' dunia. Ada metodologi terperinci yang menjelaskan cara mengubah model domain menjadi model kelas dengan beberapa langkah dan banyak (UML) artefak seperti use-case-diagram atau class-diagram. Banyak programmer telah menginternalisasi pendekatan ini dan memiliki ide bagus tentang bagaimana merancang aplikasi berorientasi objek dari awal.

Hype baru adalah pemrograman fungsional, yang diajarkan di banyak buku dan tutorial. Tapi bagaimana dengan rekayasa perangkat lunak fungsional? Saat membaca tentang Lisp dan Clojure, saya menemukan dua pernyataan menarik:

  1. Program fungsional sering dikembangkan dari bawah ke atas bukan dari atas ke bawah ('On Lisp', Paul Graham)

  2. Pemrogram Fungsional menggunakan Peta di mana Pemrogram OO menggunakan objek / kelas ('Clojure for Java Programmers', berbicara oleh Rich Hickley).

Jadi apa metodologi untuk desain sistematis (berbasis model?) Dari aplikasi fungsional, yaitu dalam Lisp atau Clojure? Apa langkah-langkah umum, artefak apa yang saya gunakan, bagaimana cara memetakannya dari ruang masalah ke ruang solusi?


3
Saya punya komentar di sini: banyak program ditulis dengan cara top-down, penjelasan praktis untuk proses pengembangan perangkat lunak dalam bahasa fungsional diberikan dalam buku "Pemrograman Fungsional dalam Bersamaan Bersihkan" (bahasa itu sendiri sangat akademis, meskipun).
Artyom Shalkhakov

4
1. Parnas berpendapat bahwa sebagian besar program harus dari bawah ke atas dan kemudian dipalsukan agar terlihat seperti dari atas ke bawah, sehingga pendekatan itu harus dicampur, tidak ada jawaban yang tepat.
Gabriel Ščerbák

2
2. Objek memberikan perilaku tergantung pada status terstruktur yang dienkapsulasi, dalam FP Anda memiliki semua status dan struktur yang eksplisit dan perilaku (fungsi) dipisahkan dari struktur. Jadi untuk pemodelan data, Anda menggunakan peta untuk objek, tetapi ketika mendesain aplikasi, objek tidak dapat diganti dengan fungsi - FP adalah ekspresi besar yang dihasilkan dan dievaluasi melalui jalur pipa, OOP adalah tentang membuat model dan mengirim pesan antar objek.
Gabriel Ščerbák

1
Saya mengajukan pertanyaan terkait beberapa waktu lalu: "bagaimana satu model data dari database relasional di clojure?" stackoverflow.com/questions/3067261/…
Sandeep

4
Hehe, dalam salah satu kuliah SICP Hal Abelson mengatakan, setengah bercanda, sesuatu di sepanjang baris "Ada metodologi terkenal, atau haruskah saya katakan mitologi, yang disebut rekayasa perangkat lunak [...] membuat diagram dan persyaratan yang rumit dan kemudian membangun sistem dengan mereka; orang-orang itu belum banyak memprogram ". Saya berasal dari "Java School", di mana selama berabad-abad kami mengajarkan UML dan artefak dan barang-barang, dan sementara itu sedikit bagus, terlalu banyak perencanaan dan perencanaan (permainan kata-kata) lebih berbahaya daripada berguna: Anda tidak pernah tahu bagaimana Anda perangkat lunak akan sampai Anda benar-benar kode.
lfborjas

Jawaban:


165

Terima kasih Tuhan bahwa orang-orang rekayasa perangkat lunak belum menemukan pemrograman fungsional. Berikut ini beberapa persamaannya:

  • Banyak "pola desain" OO ditangkap sebagai fungsi tingkat tinggi. Misalnya, pola Pengunjung dikenal di dunia fungsional sebagai "lipatan" (atau jika Anda adalah ahli teori berkepala runcing, "katamorfisme"). Dalam bahasa fungsional, tipe data sebagian besar pohon atau tupel, dan setiap tipe pohon memiliki katamorfisme alami yang terkait dengannya.

    Fungsi-fungsi tingkat tinggi ini sering datang dengan hukum pemrograman tertentu, alias "teorema bebas".

  • Pemrogram fungsional menggunakan diagram jauh lebih sedikit daripada pemrogram OO. Banyak dari apa yang diungkapkan dalam diagram OO sebaliknya dinyatakan dalam tipe , atau dalam "tanda tangan", yang harus Anda anggap sebagai "tipe modul". Haskell juga memiliki "kelas tipe", yang sedikit mirip dengan tipe antarmuka.

    Pemrogram fungsional yang menggunakan tipe umumnya berpikir bahwa "setelah Anda mendapatkan tipe yang benar; kode praktis menulis sendiri."

    Tidak semua bahasa fungsional menggunakan tipe eksplisit, tetapi buku How To Design Program , sebuah buku yang bagus untuk mempelajari Skema / Lisp / Clojure, sangat bergantung pada "deskripsi data", yang terkait erat dengan tipe.

Jadi apa metodologi untuk desain sistematis (berbasis model?) Dari aplikasi fungsional, yaitu dalam Lisp atau Clojure?

Setiap metode desain berdasarkan abstraksi data berfungsi dengan baik. Saya kebetulan berpikir bahwa ini lebih mudah ketika bahasa tersebut memiliki tipe eksplisit, tetapi itu berfungsi bahkan tanpa. Buku bagus tentang metode desain untuk tipe data abstrak, yang mudah diadaptasi untuk pemrograman fungsional, adalah Abstraksi dan Spesifikasi dalam Pengembangan Program oleh Barbara Liskov dan John Guttag, edisi pertama . Liskov memenangkan penghargaan Turing sebagian untuk pekerjaan itu.

Metodologi desain lain yang unik untuk Lisp adalah memutuskan ekstensi bahasa apa yang akan berguna dalam domain masalah tempat Anda bekerja, dan kemudian menggunakan makro higienis untuk menambahkan konstruksi ini ke bahasa Anda. Tempat yang bagus untuk membaca tentang desain semacam ini adalah artikel Matthew Flatt, Making Languages ​​in Racket . Artikel tersebut mungkin berada di belakang paywall. Anda juga dapat menemukan materi yang lebih umum tentang desain semacam ini dengan mencari istilah "bahasa tertanam khusus domain"; untuk saran dan contoh khusus di luar apa yang dibahas Matthew Flatt, saya mungkin akan mulai dengan Graham's On Lisp atau mungkin ANSI Common Lisp .

Apa langkah-langkah umum, artefak apa yang saya gunakan?

Langkah umum:

  1. Identifikasi data dalam program Anda dan operasi di dalamnya, dan tentukan tipe data abstrak yang mewakili data ini.

  2. Identifikasi tindakan umum atau pola perhitungan, dan ungkapkan sebagai fungsi atau makro tingkat tinggi. Berharap untuk mengambil langkah ini sebagai bagian dari refactoring.

  3. Jika Anda menggunakan bahasa fungsional yang diketik, gunakan pemeriksa tipe lebih awal dan sering. Jika Anda menggunakan Lisp atau Clojure, praktik terbaik adalah menulis kontrak fungsi terlebih dahulu termasuk pengujian unit — pengembangan yang didorong oleh tes hingga maksimal. Dan Anda akan ingin menggunakan versi QuickCheck apa pun yang telah porting ke platform Anda, yang dalam kasus Anda sepertinya disebut ClojureCheck . Ini adalah pustaka yang sangat kuat untuk membuat tes kode acak yang menggunakan fungsi tingkat tinggi.


2
Pengunjung IMO bukan lipatan - lipatan adalah bagian dari pengunjung. Pengiriman ganda tidak (langsung) ditangkap oleh lipatan.
Michael Ekstrand

6
@Michael - sebenarnya Anda dapat menangkap banyak pengiriman dengan berbagai jenis katamorfosis tingkat tinggi dengan sangat rapi. Pekerjaan Jeremy Gibbons adalah satu tempat untuk mencari ini, tetapi saya akan merekomendasikan pekerjaan pada pemrograman tipe-generik secara umum - Saya sangat menyukai kertas kompos.
sclv

6
Saya setuju bahwa saya melihat diagram yang digunakan jauh lebih jarang untuk menggambarkan desain fungsional dan saya pikir itu memalukan. Harus diakui sulit untuk merepresentasikan ekuivalen diagram urutan ketika menggunakan banyak HOF. Tapi saya berharap ruang bagaimana mendeskripsikan desain fungsional dengan gambar sedang dieksplorasi lebih baik. Sebanyak saya membenci UML (sebagai spec), saya menemukan UML (sebagai sketsa) cukup berguna di Jawa dan berharap ada praktik terbaik tentang cara melakukan yang setara. Saya telah sedikit bereksperimen melakukan hal ini dengan protokol dan catatan Clojure, tetapi tidak ada yang saya sukai.
Alex Miller

22
+1 untuk "Terima kasih Tuhan bahwa orang-orang rekayasa perangkat lunak belum menemukan pemrograman fungsional." ;)
Aky

1
OO sendiri merupakan cara untuk mencoba program dengan tipe, sehingga pendekatannya tidak begitu berbeda. Masalah dengan desain OO biasanya tampaknya berasal dari orang yang tidak tahu apa yang mereka lakukan.
Marcin

46

Untuk Clojure, saya sarankan kembali ke pemodelan relasional lama yang baik. Out of the Tarpit adalah bacaan inspirasional.


Itulah artikel yang bagus, masa lalu yang baik dalam Ilmu Komputer pasti sangat mengesankan, ketika semua konsep ini bertahan hingga kebangkitan hari ini. Mungkin karena dasar yang kuat dalam matematika.
Thorsten

1
Ini. INI. INI! Saya membaca makalah ini, dan sungguh menarik bagaimana tampaknya mencakup semua dasar dari apa yang diperlukan untuk membangun sistem nyata, sambil mempertahankan keadaan seminimal mungkin yang dapat berubah dalam cara yang sangat terkontrol. Saya bermain-main dengan membangun Pong dan Tetris dalam gaya FRelP (maafkan inisialisasi yang aneh, tetapi sudah ada FRP lain yang lebih populer: Pemrograman Fungsional Reaktif).
John Cromartie

Setelah membaca koran saya berpikir bahwa clojure akan menjadi bahasa yang sempurna untuk FR (el) P, setidaknya untuk logika penting , yang negara disengaja dan kontrol dan lainnya komponen. Saya bertanya-tanya bagaimana cara membuat definisi relasional dari kondisi penting dalam clojure tanpa menciptakan kembali sql (tanpa cacatnya)? Atau apakah ide untuk menggunakan DB relasional (sql) yang bagus dan membangun program fungsional di atasnya tanpa ketidaksesuaian konseptual yang diperkenalkan oleh OOP?
Thorsten

1
@Thorsten ide dasarnya adalah set = table, map = index. Bagian yang sulit adalah menjaga indeks dan tabel disinkronkan tetapi masalah ini dapat diselesaikan dengan tipe set yang lebih baik. Satu set sederhana yang saya terapkan adalah seted-set yang merupakan set yang menggunakan fungsi kunci untuk menguji unisitas. Ini berarti bahwa melakukan penyisipan nilai atau pembaruan, dapatkan panggilan dengan bidang kunci utama mengembalikan seluruh baris.
cgrand


38

Secara pribadi saya menemukan bahwa semua praktik baik yang biasa dari pengembangan OO berlaku dalam pemrograman fungsional juga - hanya dengan beberapa penyesuaian kecil untuk memperhitungkan pandangan dunia fungsional. Dari perspektif metodologi, Anda tidak perlu melakukan sesuatu yang secara fundamental berbeda.

Pengalaman saya berasal dari pindah dari Jawa ke Clojure dalam beberapa tahun terakhir.

Beberapa contoh:

  • Memahami domain / model data bisnis Anda - sama pentingnya dengan apakah Anda akan merancang model objek atau membuat struktur data fungsional dengan peta bersarang. Dalam beberapa hal, FP bisa lebih mudah karena mendorong Anda untuk berpikir tentang model data secara terpisah dari fungsi / proses tetapi Anda masih harus melakukan keduanya.

  • Orientasi layanan dalam desain - sebenarnya berfungsi sangat baik dari sudut pandang FP, karena layanan tipikal sebenarnya hanya fungsi dengan beberapa efek samping. Saya pikir bahwa pandangan "bottom up" tentang pengembangan perangkat lunak yang kadang-kadang didukung di dunia Lisp sebenarnya hanya prinsip-prinsip desain API berorientasi layanan yang baik dalam kedok lain.

  • Pengembangan yang Didorong Tes - berfungsi dengan baik dalam bahasa FP, bahkan kadang-kadang lebih baik karena fungsi murni sangat cocok untuk menulis tes yang jelas dan dapat diulang tanpa perlu menyiapkan lingkungan yang stateful. Anda mungkin juga ingin membuat tes terpisah untuk memeriksa integritas data (mis. Apakah peta ini memiliki semua kunci di dalamnya yang saya harapkan, untuk menyeimbangkan fakta bahwa dalam bahasa OO definisi kelas akan memberlakukan ini untuk Anda pada waktu kompilasi).

  • Prototying / iterasi - berfungsi sama baiknya dengan FP. Anda bahkan dapat membuat prototipe langsung dengan pengguna jika Anda menjadi sangat pandai membuat alat / DSL dan menggunakannya di REPL.


3
Praktik-praktik ini terdengar cukup akrab bagi saya. Saya masih berpikir seseorang harus menulis fungsional yang setara dengan "Rekayasa Perangkat Lunak Berorientasi Objek menggunakan UML, Patterns and Java" oleh Bruegge / Dutoit alih-alih buku keenam "Programing in Clojure". Ini bisa disebut "Rekayasa Perangkat Lunak Fungsional menggunakan Clojure dan ?? apa ??". Apakah mereka menggunakan UML dan pola di FP? Saya ingat Paul Graham menulis bahwa pola adalah tanda kurangnya abstraksi dalam Lisp, yang harus diperbaiki dengan pengenalan makro baru.
Thorsten

3
Tetapi jika Anda menerjemahkan pola sebagai praktik terbaik, mungkin ada pola di dunia FP juga, layak untuk dibagikan dengan yang tidak diinisialisasi.
Thorsten

2
Ada beberapa desain prinsip yang menarik dalam buku PAIP. norvig.com/paip.html
mathk

1
ada juga pola pemrograman fungsional (skema rekursi, dll.)
Gabriel Ščerbák

13

Pemrograman OO secara ketat memasangkan data dengan perilaku. Pemrograman fungsional memisahkan keduanya. Jadi Anda tidak memiliki diagram kelas, tetapi Anda memiliki struktur data, dan Anda khususnya memiliki tipe data aljabar. Jenis-jenis itu dapat ditulis agar sangat sesuai dengan domain Anda, termasuk menghilangkan nilai yang tidak mungkin dengan konstruksi.

Jadi tidak ada buku dan buku di dalamnya, tetapi ada pendekatan mapan untuk, seperti kata pepatah, membuat nilai-nilai yang tidak mungkin tidak terwakili.

Dengan demikian, Anda dapat membuat berbagai pilihan tentang merepresentasikan tipe data tertentu sebagai fungsi saja, dan sebaliknya, merepresentasikan fungsi tertentu sebagai gabungan tipe data sehingga Anda bisa mendapatkan, misalnya serialisasi, spesifikasi yang lebih ketat, optimisasi, dll. .

Kemudian, mengingat itu, Anda menulis fungsi di atas iklan Anda sehingga Anda membuat semacam aljabar - yaitu ada hukum tetap yang berlaku untuk fungsi-fungsi ini. Beberapa mungkin idempoten - sama setelah beberapa aplikasi. Beberapa asosiatif. Beberapa transitif, dll.

Sekarang Anda memiliki domain tempat Anda memiliki fungsi yang menyusun menurut hukum yang berlaku. DSL tertanam sederhana!

Oh, dan diberi properti, Anda tentu saja dapat menulis tes acak secara otomatis (ala QuickCheck) .. dan itu baru permulaan.


1
Pendekatan membuat nilai-nilai tidak mungkin tidak terwakili kurang berlaku untuk bahasa dengan pengetikan dinamis seperti Clojure dan Skema dibandingkan dengan bahasa dengan pengetikan statis seperti Haskell dan ML.
Zak

@ Zak - yah, Anda tidak dapat secara statis mengecek apakah mereka tidak dapat ditampilkan, tetapi Anda dapat membangun struktur data dengan cara yang sama.
sclv

7

Desain Berorientasi Objek tidak sama dengan rekayasa perangkat lunak. Rekayasa perangkat lunak harus dilakukan dengan seluruh proses bagaimana kita beralih dari persyaratan ke sistem kerja, tepat waktu dan dengan tingkat cacat rendah. Pemrograman fungsional mungkin berbeda dari OO, tetapi tidak menghilangkan persyaratan, desain tingkat tinggi dan terperinci, verifikasi dan pengujian, metrik perangkat lunak, estimasi, dan semua yang lainnya "hal-hal rekayasa perangkat lunak".

Selain itu, program fungsional menunjukkan modularitas dan struktur lainnya. Desain rinci Anda harus dinyatakan dalam konsep konsep dalam struktur itu.


5

Salah satu pendekatan adalah membuat DSL internal dalam bahasa pemrograman fungsional pilihan. "Model" kemudian adalah seperangkat aturan bisnis yang dinyatakan dalam DSL.


1
Saya memahami pendekatan untuk pertama membangun bahasa menuju domain masalah sampai tingkat abstraksi tercapai bahwa tidak ada pola berulang yang muncul lagi dalam kode, daripada menyelesaikan masalah dengan abstraksi itu.
Thorsten

1
Tapi bagaimana kelihatannya ketika "model adalah seperangkat aturan bisnis yang dinyatakan dalam DSL"? Dalam aplikasi Java EE, model ini ditulis sebagai POJO-Entities, yang dipanggil dari controller-EJBs yang pada gilirannya memperbarui tampilan-JSP - misalnya. Apakah ada pola arsitektur yang serupa (seperti pola MVC) di FP? Bagaimana itu terlihat?
Thorsten

2
Tidak ada alasan Anda tidak dapat memiliki pola MVC di FP, persis seperti itu. FP masih memungkinkan Anda membangun struktur data yang kaya, dan bisa dibilang dengan ADT dan pencocokan pola, memungkinkan Anda membuat yang lebih kaya . Jika ada, karena FP memisahkan data dan perilaku, sistem tipe MVC muncul jauh lebih alami.
sclv

5

Lihat jawaban saya ke posting lain:

Bagaimana Clojure mendekati Separation of Concerns?

Saya setuju lebih banyak yang perlu ditulis pada subjek tentang bagaimana menyusun aplikasi besar yang menggunakan pendekatan FP (Ditambah lagi yang perlu dilakukan untuk mendokumentasikan UI berbasis-FP)


3
Saya suka pipa 90% dan pendekatan makro 10%. Tampaknya wajar untuk menganggap program fungsional sebagai pipa transformasi pada data yang tidak dapat diubah. Saya tidak yakin apakah saya mengerti apa yang Anda maksud dengan "memasukkan semua intelijen ke dalam data, bukan kode", karena pendekatan memiliki 100 fungsi yang bekerja pada 1 struktur data (daripada 10 fungsi pada 10 struktur data) tampaknya menyiratkan sebaliknya. Bukankah struktur data dalam OOP lebih pintar daripada di FP, karena mereka memiliki perilaku sendiri dibangun di
Thorsten

3

Walaupun ini mungkin dianggap naif dan sederhana, saya pikir "resep desain" (pendekatan sistematis untuk pemecahan masalah yang diterapkan untuk pemrograman seperti yang dianjurkan oleh Felleisen et al. Dalam buku mereka HtDP ) akan dekat dengan apa yang Anda cari.

Di sini, beberapa tautan:

http://www.northeastern.edu/magazine/0301/programming.html

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.8371


Tautan ke halaman Northeastern tampaknya sudah mati.
James Kingsbery

1
James, kau benar, dan aku tidak ingat apa yang ada di sana untuk memperbaikinya, sayangnya. Saya hanya tahu bahwa penulis HtDP melanjutkan untuk membuat bahasa Pyret (dan mungkin, merevisi HtDP edisi ke-2 untuk menggunakannya alih-alih Racket, sebelumnya Skema PLT).
Artyom Shalkhakov

3

Saya baru-baru ini menemukan buku ini: Pemodelan Domain Fungsional dan Reaktif

Saya pikir ini sangat sesuai dengan pertanyaan Anda.

Dari deskripsi buku:

Pemodelan Domain Fungsional dan Reaktif mengajarkan Anda bagaimana memikirkan model domain dalam hal fungsi murni dan bagaimana menyusunnya untuk membangun abstraksi yang lebih besar. Anda akan mulai dengan dasar-dasar pemrograman fungsional dan secara bertahap berkembang ke konsep dan pola lanjutan yang perlu Anda ketahui untuk menerapkan model domain yang kompleks. Buku ini menunjukkan bagaimana pola FP tingkat lanjut seperti tipe data aljabar, desain berbasis kelas, dan isolasi efek samping dapat membuat model Anda tersusun agar mudah dibaca dan diverifikasi.


2

Ada gaya "penghitungan program" / "desain dengan perhitungan" yang dikaitkan dengan Prof. Richard Bird dan kelompok Aljabar Pemrograman di Universitas Oxford (Inggris), saya tidak berpikir terlalu jauh untuk menganggap ini sebagai metodologi.

Secara pribadi sementara saya menyukai pekerjaan yang dihasilkan oleh kelompok AoP, saya sendiri tidak memiliki disiplin untuk mempraktikkan desain dengan cara ini. Namun itu kekurangan saya, dan bukan salah satu perhitungan program.


2

Saya telah menemukan Behavior Driven Development menjadi cocok alami untuk kode yang berkembang pesat di Clojure dan SBCL. Kelebihan nyata dari meningkatkan BDD dengan bahasa fungsional adalah bahwa saya cenderung menulis tes unit gandum yang jauh lebih baik daripada yang biasanya saya lakukan ketika menggunakan bahasa prosedural karena saya melakukan pekerjaan yang jauh lebih baik menguraikan masalah menjadi potongan-potongan fungsionalitas yang lebih kecil.


apa alat yang Anda gunakan untuk melakukan BDD di clojure?
murtaza52

Saya suka Midje. Ini terbaru dan sangat ekspresif. Lihat ini: github.com/marick/Midje
Marc

1

Jujur jika Anda ingin resep desain untuk program fungsional, lihat perpustakaan fungsi standar seperti Haskell's Prelude. Dalam FP, pola biasanya ditangkap oleh prosedur tingkat tinggi (fungsi yang beroperasi pada fungsi) sendiri. Jadi jika suatu pola terlihat, seringkali fungsi orde tinggi dibuat untuk menangkap pola itu.

Contoh yang baik adalah fmap. Fungsi ini mengambil fungsi sebagai argumen dan menerapkannya ke semua "elemen" dari argumen kedua. Karena ini adalah bagian dari kelas tipe Functor, setiap instance dari Functor (seperti daftar, grafik, dll ...) dapat diberikan sebagai argumen kedua untuk fungsi ini. Ini menangkap perilaku umum menerapkan fungsi ke setiap elemen argumen kedua.


-7

Baik,

Umumnya banyak Bahasa Pemrograman Fungsional digunakan di universitas untuk waktu yang lama untuk "masalah mainan kecil".

Mereka semakin populer sekarang karena OOP mengalami kesulitan dengan "pemrograman paralel" karena "keadaan". Dan kadang-kadang gaya fungsional lebih baik untuk masalah yang dihadapi seperti Google MapReduce.

Saya yakin, ketika functioanl guys menabrak dinding [mencoba menerapkan sistem lebih dari 1.000.000 baris kode], beberapa dari mereka akan datang dengan metodologi rekayasa perangkat lunak baru dengan kata-kata buzz :-). Mereka harus menjawab pertanyaan lama: Bagaimana cara membagi sistem menjadi beberapa bagian sehingga kita dapat "menggigit" setiap bagian satu per satu? [bekerja berulang-ulang, tambahan dengan cara evolusioner] menggunakan Gaya Fungsional.

Sudah pasti bahwa Gaya Fungsional akan mempengaruhi Gaya Berorientasi Objek kami. Kami "masih" banyak konsep dari Sistem Fungsional dan disesuaikan dengan bahasa OOP kami.

Tetapi apakah program-program fungsional akan digunakan untuk sistem sebesar itu? Apakah akan menjadi arus utama? Itu pertanyaannya .

Dan tidak ada yang bisa datang dengan metodologi realistis tanpa menerapkan sistem besar seperti itu, membuat tangannya kotor. Pertama, Anda harus membuat tangan Anda kotor kemudian menyarankan solusi. Solusi-Saran tanpa "rasa sakit dan kotoran" akan menjadi "fantasi".


Sudah cukup banyak sistem skala besar dibangun dengan bahasa fungsional sekarang. Kalaupun tidak ada, ini sama sekali bukan argumen.
Svante

Nah, sebutkan beberapa dari mereka? Saya hanya tahu sedikit sistem "Erlang". [ukuran sedang] Tapi Haskel? Clojure? Pelat?
Hippias Minor

Dan itu [menulis sistem besar] adalah argumen yang sebenarnya. Karena itu adalah ujian. Test case ini menunjukkan bahwa jika gaya fungsional ini berguna dan dapat kita lakukan hal-hal praktis dengannya di dunia nyata.
Hippias Minor

2
Hal lucu tentang bahasa yang tidak secara "OOP" analitik adalah bahwa mereka sering memberi Anda kebebasan dari "desain metodologi metodologi", untuk berpikir untuk diri sendiri, dan untuk memotong program Anda dengan cara yang paling tepat, alih-alih secara membabi buta mengikuti pola yang ditetapkan dan hidup dengan boilerplate birokrasi. Maaf, tidak ada 10 poin 3 minggu saja di sini.
Svante

1
Saya telah melihat hal-hal yang tidak akan Anda percayai.
Svante
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.