Jika kita dapat melakukan pemrograman fungsional dengan Python, apakah kita memerlukan bahasa pemrograman fungsional tertentu? [Tutup]

22

Menggunakan generator dan lambda, kita bisa melakukan pemrograman fungsional dengan Python. Anda juga dapat mencapai hal yang sama dengan Ruby.

Jadi pertanyaannya adalah: mengapa kita perlu bahasa pemrograman fungsional spesifik seperti Erlang, Haskell, dan Skema? Adakah yang berbeda dari bahasa pemrograman fungsional spesifik ini? Mengapa kita tidak bisa menggunakan Python saja untuk pemrograman fungsional?

Joshua Partogi
sumber
30
semua itu ada bahkan sebelum python dibuat
Mahmoud Hossam
51
Pinto ford adalah mobil. Mengapa kita membutuhkan mobil cepat khusus seperti Ferraris?
Martin York
11
Menggunakan kelas dan templat, kita dapat melakukan apa saja OO di C ++. Mengapa Java dan Python pernah dibuat? Apa yang mereka tambahkan?
9000
19
Semua bahasa pemrograman (tanpa beberapa bahasa penelitian akademis murni) setara Turing, jadi apa yang dapat Anda lakukan dalam bahasa A dapat Anda lakukan dalam bahasa lain. Jadi, mengikuti rangkaian
Maglob
17
Jika Anda tahu bahasa-bahasa ini, Anda tidak akan mengklaim bahwa Python melakukan pemrograman fungsional dengan baik. Tidak. Itu cukup baik untuk menggabungkan bagian dari hal-hal FP-ish, tetapi tidak lebih baik.

Jawaban:

20

Saya menghargai pertanyaan itu, karena saya pribadi penggemar berat Python dan gaya pemrograman fungsional. Saya memiliki latar belakang yang panjang dalam Python dan saya mulai mempelajari Haskell baru-baru ini, jadi inilah beberapa poin berdasarkan pengalaman pribadi saya tentang perbedaan antara bahasa-bahasa ini juga, dari perspektif fungsional.

Kemurnian

Bahkan jika Anda tidak peduli tentang kemurnian fungsi (yaitu tidak memiliki efek samping) sebagai prinsip, itu memang memiliki efek praktis pada betapa mudahnya membaca kode dan alasan tentang hal itu. Bahkan jika Anda mempertahankan kemurnian dalam fungsi Python Anda sendiri, ada perbedaan besar dalam membuat kompiler menegakkan kemurnian dan, yang paling penting, memiliki perpustakaan standar yang dibangun berdasarkan persyaratan kemurnian dan struktur data yang tidak dapat diubah.

Performa

Anda mungkin atau mungkin tidak peduli dengan kinerja tergantung pada apa domain aplikasi Anda, tetapi pengetikan statis dan kemurnian yang dijamin memberikan kompiler lebih banyak untuk dikerjakan, dibandingkan dengan Python dan bahasa dinamis lainnya (walaupun saya harus mengakui bahwa PyPy menjadi hebat terobosan, dan misalnya LuaJIT berbatasan dengan ajaib).

Optimasi Tail-call

Terkait dengan kinerja, tetapi sedikit berbeda. Bahkan jika Anda tidak terlalu peduli dengan kinerja runtime, tidak memiliki optimasi panggilan ekor (terutama untuk rekursi ekor) membatasi cara-cara Anda dapat mengimplementasikan algoritma dengan Python tanpa mencapai batas tumpukan.

Sintaksis

Ini adalah alasan terbesar mengapa saya mulai melihat bahasa fungsional "nyata" daripada hanya menggunakan Python dengan gaya fungsional. Walaupun saya berpikir bahwa Python memiliki sintaks yang sangat ekspresif secara umum, Python memiliki beberapa titik lemah khusus untuk pengkodean fungsional. Sebagai contoh:

  • Sintaks untuk fungsi lambda agak bertele-tele dan terbatas dalam apa yang bisa dikandungnya
  • Tidak ada gula sintaksis untuk komposisi fungsi yaitu f = g . hvs.f = lambda *arg: g(h(*arg))
  • Tidak ada gula sintaksis untuk aplikasi parsial yaitu f = map gvs.f = functools.partial(map, g)
  • Tidak ada gula sintaksis untuk menggunakan operator infiks dalam fungsi tingkat tinggi yaitu sum = reduce (+) lstvs.sum = reduce(operator.add, lst)
  • Tidak ada pencocokan pola atau pelindung untuk argumen fungsi, yang membuatnya mudah untuk mengekspresikan kondisi akhir rekursi dan beberapa kasus perbatasan dengan sintaksis yang sangat mudah dibaca.
  • Kurung tidak pernah opsional untuk panggilan fungsi, dan tidak ada gula sintaksis untuk panggilan bersarang. Saya kira ini adalah masalah selera, tetapi terutama dalam kode fungsional, saya menemukan itu umum untuk panggilan fungsi berantai dan saya menemukan y = func1 $ func2 $ func3 xlebih mudah dibaca daripada y = func1(func2(func3(x))), setelah Anda terbiasa dengan notasi itu.
shang
sumber
28

Inilah perbedaan terpenting:

Haskell

  • Evaluasi malas
  • Mengkompilasi ke kode mesin
  • Pengetikan statis memastikan fungsinya murni
  • Ketikkan inferensi

Haskell dan Erlang

  • Pencocokan pola

Erlang

  • Aktor model konkurensi, proses ringan

Skema

  • Makro

Semua bahasa

  • penutupan nyata (ruby memiliki penutupan, apakah python dapat diperdebatkan, lihat komentar)
  • perpustakaan standar yang cocok untuk gaya pemrograman fungsional (koleksi yang tidak berubah, peta, filter, lipat dll)
  • rekursi ekor (ini dapat ditemukan dalam beberapa bahasa non-fungsional juga)

Juga, Anda harus melihat bahasa dari keluarga ML seperti SML, Ocaml dan F # dan Scala, yang menggabungkan OO dan pemrograman fungsional dengan cara baru. Semua bahasa ini memiliki fitur menarik yang unik.

Kim
sumber
3
+1 pos bagus. Anda bisa menambahkan inferensi tipe pada proses Haskell dan Light-weight pada Erlang.
Jonas
1
Python memang memiliki peta, filter dan lipat (kurangi). Mengenai "penutupan nyata": Jika Anda mendefinisikan penutupan nyata sebagai penutupan yang dapat mengandung sesuatu selain satu ekspresi, Haskell juga tidak memiliki penutupan nyata (tetapi tentu saja Haskell memiliki beberapa hal yang bukan ekspresi ...) . Namun poin tentang struktur data yang tidak dapat diubah adalah bagus, jadi +1 untuk itu. Juga: rekursi ekor (dan rekursi umumnya lebih murah).
sepp2k
2
+1 untuk "pengetikan statis memastikan fungsi murni". Sangat keren memiliki sistem tipe yang membedakan fungsi murni dan tidak murni. (C ++ 's doe snot count. :)
Macke
1
@ btilly: Saya tidak akan menganggapnya sebagai penutupan jika Anda tidak dapat menetapkan ke variabel yang ada dalam ruang lingkup. Kalau tidak, kita harus mengatakan bahwa Java juga memiliki penutupan, karena Anda dapat menggunakan trik yang sama di sana.
Kim
3
Sebagai penutup, saya dapat mengakses variabel dengan cara yang sama seperti biasanya. Ini berlaku untuk penutupan Haskell dan Ruby, tetapi bukan pengganti Python atau Java yang buruk. Mungkin orang lain bisa memberi tahu kita tentang erlang, saya tidak tahu itu.
Kim
19

Sulit untuk mendefinisikan dengan tepat apa itu "bahasa fungsional" - dari bahasa yang Anda cantumkan, hanya Haskell yang murni fungsional (semua yang lain mengadopsi semacam pendekatan hybrid). Ada fitur bahasa tertentu yang sangat membantu untuk pemrograman fungsional, dan Ruby dan Python tidak memiliki cukup dari mereka untuk menjadi lingkungan yang sangat baik untuk FP. Berikut adalah daftar periksa pribadi saya, sesuai urutan kepentingannya:

  1. Fungsi dan penutupan kelas satu (Ruby, Python, dan semua yang Anda daftarkan memiliki ini).
  2. Optimalisasi panggilan ekor yang dijamin (Erlang, Haskell, Scala, dan Skema memilikinya, tetapi belum Python, Ruby, atau Clojure (belum)).
  3. Mendukung kekekalan dalam bahasa dan pustaka standar (ini adalah yang besar yang dimiliki semua "bahasa fungsional" yang Anda daftarkan (kecuali Skema) tetapi Ruby dan Python tidak).
  4. Dukungan tingkat bahasa untuk fungsi yang transparan (atau murni) secara referensial (sejauh yang saya tahu, hanya Haskell yang memiliki ini saat ini).

Kebutuhan untuk (1) harus jelas - fungsi tingkat tinggi sangat sulit tanpa fungsi kelas satu. Ketika orang berbicara tentang Ruby dan Python sebagai bahasa yang baik untuk FP, mereka biasanya membicarakan hal ini. Namun, fitur khusus ini diperlukan tetapi tidak cukup untuk membuat bahasa yang baik untuk FP.

(2) telah menjadi kebutuhan tradisional untuk KB sejak Skema ditemukan. Tanpa TCO, tidak mungkin untuk memprogram dengan rekursi yang dalam, yang merupakan salah satu pilar FP, karena Anda mendapatkan stack overflow. Satu-satunya bahasa "fungsional" (menurut definisi populer) yang tidak memiliki ini adalah Clojure (karena keterbatasan JVM), tetapi Clojure memiliki beragam peretasan untuk mensimulasikan TCO. (FYI, Ruby TCO adalah implementasi khusus , tetapi Python khusus tidak mendukungnya .) Alasan TCO harus dijamin adalah bahwa jika itu spesifik implementasi, fungsi rekursif yang dalam akan pecah dengan beberapa implementasi, sehingga Anda tidak bisa benar-benar gunakan semuanya.

(3) adalah hal besar lain yang dimiliki bahasa fungsional modern (terutama Haskell, Erlang, Clojure, dan Scala) yang tidak dimiliki oleh Ruby dan Python. Tanpa membahas terlalu banyak detail, immutability yang dijamin menghilangkan seluruh kelas bug, terutama dalam situasi bersamaan, dan memungkinkan hal-hal yang rapi seperti struktur data yang persisten . Sangat sulit untuk mengambil manfaat dari manfaat ini tanpa dukungan tingkat bahasa.

(4) bagi saya adalah hal yang paling menarik tentang bahasa murni fungsional (bukan bahasa hibrida). Pertimbangkan fungsi Ruby yang sangat sederhana berikut:

def add(a, b)
  a + b
end

Ini terlihat seperti fungsi murni, tetapi karena operator kelebihan beban, ini dapat mengubah parameter atau menyebabkan efek samping seperti mencetak ke konsol. Tidak mungkin seseorang akan membebani +operator untuk memiliki efek samping, tetapi bahasa tidak memberikan jaminan. (Hal yang sama berlaku untuk Python, walaupun mungkin tidak dengan contoh khusus ini.)

Di dalam bahasa yang murni fungsional, di sisi lain, ada jaminan tingkat bahasa yang fungsinya transparan secara referensial. Ini memiliki banyak keuntungan: fungsi murni dapat dengan mudah ditulis; mereka dapat dengan mudah diuji tanpa bergantung pada negara global apa pun; dan nilai-nilai dalam fungsi dapat dievaluasi dengan malas atau paralel tanpa khawatir tentang masalah konkurensi. Haskell mengambil keuntungan penuh dari ini, tetapi saya tidak cukup tahu tentang bahasa fungsional lain untuk mengetahui apakah mereka melakukannya.

Semua yang dikatakan, dimungkinkan untuk menggunakan teknik FP di hampir semua bahasa (bahkan Jawa). Misalnya, Google MapReduce terinspirasi oleh ide-ide fungsional, tetapi sejauh yang saya tahu mereka tidak menggunakan bahasa "fungsional" untuk proyek-proyek besar mereka (saya pikir mereka kebanyakan menggunakan C ++, Java, dan Python).

shosti
sumber
2
+1 untuk penjelasan menyeluruh - bahkan saya sebagai orang luar FP memahaminya. Terima kasih! :-)
Péter Török
jawaban paling berharga untuk pertanyaan ini sejauh ini. Ditemukan pada fakta dan banyak informasi. Kerja bagus.
wirrbel
Scala memiliki rekursi ekor dan, seperti Skema, itu dilakukan secara otomatis jika panggilan rekursif berada di posisi ekor (tidak seperti Clojure di mana ia harus secara eksplisit diminta). Bahkan ada anotasi sehingga Anda dapat memeriksa bahwa kompiler akan menghasilkan kode rekursif ekor. Apa yang tidak dimilikinya adalah Skema TCO yang lebih umum. Saya berasumsi Anda tahu itu, tetapi karena Anda terlalu banyak detail tentang hal-hal lain, yang tampaknya pemecatan / kelalaian aneh.
bruce
@itsbruce Posting ini cukup lama, IIRC Scala tidak memilikinya pada saat itu (atau saya mungkin saja salah;). Diperbarui.
shosti
Saya belum pernah menggunakan Scala sejak awal tetapi memang memiliki rekursi ekor pada tahun 2008, ketika saya mulai tertarik ;-) Saya merujuk orang-orang yang bertanya tentang topik ini ke pertanyaan SO khusus ini karena memiliki beberapa jawaban yang bagus dan saya hanya baru saja memperhatikan keanehan itu, jadi berkomentar untuk kelengkapannya.
akarnya
11

Bahasa yang Anda sebutkan sangat berbeda.

Sementara Python dan Ruby adalah bahasa yang diketik secara dinamis, Haskell diketik secara statis. Erlang adalah bahasa bersamaan dan menggunakan model Aktor dan sangat berbeda dari semua bahasa lain yang Anda sebutkan.

Python dan Ruby memiliki banyak konstruksi imperatif sementara dalam bahasa fungsional yang lebih murni seperti Haskell, semuanya mengembalikan sesuatu atau dengan kata lain semuanya adalah fungsi.

Jonas
sumber
@ KRON: Ya, sistem tipe adalah properti penting dari suatu bahasa, dan dia bertanya "Apakah ada sesuatu yang berbeda yang disediakan oleh bahasa pemrograman fungsional spesifik ini?". Tentu, Anda dapat menggunakan model Aktor dengan bahasa lain tetapi Erlang memilikinya dalam bahasa tersebut. Erlang menggunakan proses yang ringan dan memiliki konstruksi bahasa bawaan untuk pemrograman terdistribusi - karenanya bahasa "bersamaan".
Jonas
8

Terlambat ke pesta seperti biasa, tetapi akan mengatakan banyak hal.

Bahasa pemrograman fungsional bukan bahasa yang memungkinkan pemrograman fungsional. Jika kita menggunakan definisi itu, maka hampir semua bahasa di mana saja adalah bahasa pemrograman fungsional. (Hal yang sama berlaku untuk OOP, kebetulan. Anda dapat menulis dalam gaya OOP dalam C jika Anda suka. Jadi, menurut logika Anda, C adalah bahasa OOP.)

Apa yang membuat bahasa pemrograman fungsional bukanlah seperti yang Anda izinkan untuk diprogram, melainkan apa yang memungkinkan Anda memprogram dengan mudah . Itulah kuncinya.

Jadi, Python memiliki lambdas (yang sangat mirip dengan masalah penutupan mirip anemia) dan memberi Anda beberapa fungsi perpustakaan yang akan Anda lihat di perpustakaan fungsional juga seperti "map" dan "fold". Ini tidak cukup untuk membuatnya menjadi bahasa pemrograman fungsional, karena sulit untuk mustahil untuk secara konsisten memprogram dalam gaya fungsional yang tepat di dalamnya (dan bahasa jelas tidak memaksakan gaya ini!). Pada intinya Python adalah bahasa imperatif yang berkaitan dengan operasi manipulasi negara dan negara dan ini hanya bertentangan dengan ekspresi dan ekspresi semantik evaluasi bahasa fungsional.

Jadi mengapa kita memiliki bahasa pemrograman fungsional ketika Python (atau Ruby (atau memasukkan bahasa pilihan Anda)) dapat "melakukan pemrograman fungsional"? Karena Python, dkk tidak dapat melakukan pemrograman fungsional yang tepat. Itu sebabnya.

HANYA PENDAPAT SAYA yang benar
sumber
6

Anda dapat melakukan pemrograman fungsional di Jawa (lihat misalnya http://functionaljava.org/ ). Anda juga dapat melakukan pemrograman berorientasi objek di C . Hanya saja tidak sebodoh itu.

Jadi memang kita tidak benar - benar membutuhkan Erlang, Haskell, Skema, atau bahasa pemrograman spesifik apa pun, tetapi semuanya mewakili pendekatan dan pertukaran yang berbeda, membuat beberapa tugas lebih mudah dan beberapa lebih sulit. Apa yang harus Anda gunakan tergantung pada apa yang ingin Anda capai.

Joonas Pulakka
sumber
4

Pertanyaan ini dapat diterapkan pada jumlah bahasa dan paradigma yang tak terbatas.

  • Karena semua orang menggunakan C ++, mengapa kita membutuhkan bahasa tujuan umum lainnya?
  • Karena java adalah bahasa OO yang hebat, mengapa bahasa OO lain ada?
  • Karena perl adalah bahasa scripting yang menakjubkan, mengapa kita perlu python?
  • Yatta, yatta, yatta

Sebagian besar, jika tidak semua bahasa ada karena alasan tertentu. Mereka ada karena seseorang memiliki kebutuhan yang tidak ada bahasa saat ini diisi, atau diisi dengan buruk. (Ini tentu saja tidak berlaku untuk setiap bahasa, tapi saya rasa itu berlaku untuk sebagian besar bahasa yang terkenal.) Misalnya, python awalnya dikembangkan untuk berinteraksi dengan OS Amoeba [ 1 , 2 ] dan Erlang diciptakan untuk membantu dalam pengembangan aplikasi teleponi [ 3 ]. Jadi satu jawaban untuk pertanyaan "Mengapa kita membutuhkan bahasa fungsional lain?" bisa saja, karena [masukkan-nama-dari-seseorang-yang-tahu-bagaimana-desain-bahasa] tidak suka cara python melakukannya.

Itu cukup menyimpulkan apa yang saya pikir jawabannya. Meskipun Anda dapat melakukan apa saja dengan python yang dapat Anda lakukan dengan bahasa fungsional, apakah Anda benar-benar ingin melakukannya? Segala sesuatu yang dapat Anda lakukan di C, Anda bisa lakukan dalam perakitan, tetapi apakah Anda ingin? Bahasa yang berbeda akan selalu menjadi yang terbaik dalam melakukan hal yang berbeda, dan begitulah seharusnya.

cledoux
sumber
2

Pemrograman fungsional adalah tentang paradigma desain seperti halnya tentang fitur bahasa tertentu. Atau, dengan kata lain, lambdas dan fungsi peta tidak membuat bahasa pemrograman fungsional. Python dan Ruby memiliki beberapa fitur yang terinspirasi oleh bahasa pemrograman fungsional, tetapi Anda umumnya masih menulis kode dengan cara yang sangat penting. (Ini seperti C: Anda dapat menulis kode seperti OO dalam C, tetapi tidak ada yang menganggap serius C sebagai bahasa OO.)

Lihat: pemrograman fungsional bukan hanya tentang lambdas, atau map, atau fungsi tingkat tinggi. Ini tentang desain . Suatu program yang ditulis dalam bahasa pemrograman fungsional "benar" memecahkan masalah melalui komposisi fungsi. Sementara program yang ditulis dalam Ruby atau Python dapat menggunakan fitur seperti FP, mereka umumnya tidak membaca seperti sekumpulan fungsi yang dikomposisikan.

mipadi
sumber
0

Setiap bahasa fungsional yang Anda sebutkan cocok dengan niche tertentu dengan cukup baik dan pola-pola idiomatik yang mendorong masing-masing membuatnya sangat cocok untuk tugas-tugas tertentu yang tidak mungkin untuk dicapai dengan Python kecuali Anda membangun perpustakaan besar modul pembantu. Salah satu keunggulan niche yang paling jelas adalah model konkurensi Erlang. Yang lain juga memiliki kekuatan yang sama.

davidk01
sumber
0

Setiap konsep yang tersedia dalam lambda-calculus, LISP, dan Scheme tersedia dalam Python, jadi, ya, Anda dapat melakukan pemrograman fungsional di dalamnya. Apakah nyaman atau tidak adalah masalah konteks dan selera.

Anda dapat dengan mudah menulis penerjemah LISP (atau bahasa fungsional lainnya) dengan Python (Ruby, Scala) (apa artinya itu?). Anda dapat menulis penerjemah untuk Python menggunakan fungsional murni, tetapi itu akan membutuhkan banyak pekerjaan. Bahkan bahasa "fungsional" adalah multi-paradigma saat ini.

Buku tua dan indah ini memiliki sebagian besar (walaupun tidak semua) jawaban tentang apa esensi pemrograman fungsional.

Apalala
sumber
@Arkaaito Tapi apakah Anda setuju bahwa setiap konsep yang tersedia dalam lambda calculus, LISP, dan Scheme tersedia dalam Python?
Mark C
Apakah Anda yakin bahwa setiap konsep cadel tersedia dalam Python? Macro, kode-adalah-data?
SK-logic
@ SK-logic Macro tidak ada dalam lambda-calculus, tapi ya, mereka tersedia dalam Python, meskipun tidak dengan nama itu. Python menyediakan suatu eval()fungsi, yang diperlukan untuk kode adalah data , tetapi ia melangkah lebih jauh: ia memungkinkan Anda memodifikasi sebagian besar lingkungan runtime, seperti di LISP.
Apalala
@Apalala, bahasa dinamis eval()adalah metaprogramming runtime. Terkadang bermanfaat, tetapi sangat mahal. Lisp macro berbeda, ini adalah waktu penyusunan metaprogramming. Ini tidak tersedia dalam Python dalam bentuk apa pun yang dapat digunakan.
SK-logic
@ SK-logic Makro semacam itu mematahkan premis kode-is-data , karena program tidak dapat mengubah makro (atau bahkan mengetahui keberadaannya). Dalam Python, program memiliki akses ke pohon parsing mereka sendiri pada saat runtime, jika mereka membutuhkannya. Makro (pra-pemrosesan statis) tidak berfungsi sama sekali.
Apalala
-5

Karena Python juga dapat memprogram dalam gaya non-fungsional, dan itu tidak cukup baik untuk purist FP. Namun, lebih banyak pembuat kode pragmatis dapat menikmati manfaat gaya fungsional tanpa menjadi dogmatis tentang hal itu:

“Programmer fungsional terdengar seperti seorang biarawan abad pertengahan, menyangkal kesenangan hidup dengan harapan bahwa itu akan membuatnya berbudi luhur. Bagi mereka yang lebih tertarik pada manfaat material, "keuntungan" ini tidak terlalu meyakinkan. Pemrogram fungsional berpendapat bahwa ada manfaat materi yang besar ... [tetapi] ini jelas konyol. Jika mengabaikan pernyataan tugas membawa manfaat yang sangat besar maka programmer FORTRAN akan melakukannya selama dua puluh tahun. Adalah mustahil secara logis untuk membuat bahasa lebih kuat dengan menghilangkan fitur, tidak peduli seburuk apa mereka. ”

- John Hughes, Mengapa pemrograman fungsional penting

Mason Wheeler
sumber
6
Saya setuju. Bahasa apa pun yang gotoada di luar itu mengerikan.
Anon.
2
@ Anon: Atau saudara kandungnya call-with-current-continuation,.
Chris Jester-Young
4
Mason, makalah yang Anda kutip mengatakan sebaliknya. Kutipan Anda hanyalah sebuah fragmen dari beberapa paragraf makalah yang menceritakan kisah yang berbeda. Bahkan, jika Anda mengutip kedua paragraf secara keseluruhan, mereka akan dengan jelas menunjukkan makna lain.
Marco Mustapic
2
@ Alasan: ya, penulis mengklaim modularisasi dan evaluasi malas adalah manfaat sebenarnya. Tetapi perhatikan bagaimana kutipan asli Anda di luar konteks - Anda tampaknya menyarankan penulis mengklaim sesuatu terhadap FP, padahal sebenarnya Anda mengutip paragraf dari sebuah makalah dengan kesimpulan bahwa FP itu hebat, hanya saja bukan karena alasan menyesatkan dari " kurang itu lebih". Judul makalah ini menunjukkan maksud penulis dengan cukup jelas: "mengapa pemrograman fungsional penting" ;-) Ini tentu saja tidak mendukung klaim Anda bahwa bahasa FP yang lebih murni "adalah gangguan".
Andres F.
6
@Mason Wheeler: Bahasa hibrid mendahului Python dengan peregangan loooooong. Lisp, misalnya, berasal dari tahun 1959 dan, pada kenyataannya, adalah bahasa multi-paradigma. Ini sepenuhnya mendukung pendekatan fungsional, pendekatan prosedural dan pendekatan berorientasi objek untuk pemrograman. Dengan paket makro yang tepat di atas Anda juga dapat melakukan pemrograman logika dengan cukup mudah. Skema juga mendahului Python (dan tulisan ini). Ini kembali ke tahun 1975. Mungkin Anda harus melirik timeline bahasa pemrograman ini kapan-kapan.
HANYA SAYA PENDAPAT yang benar