Apa perbedaan terbesar antara F # dan Scala?


59

F # dan Scala adalah bahasa pemrograman fungsional yang tidak memaksa pengembang untuk hanya menggunakan tipe data yang tidak dapat diubah. Mereka berdua memiliki dukungan untuk objek, dapat menggunakan perpustakaan yang ditulis dalam bahasa lain dan dijalankan pada mesin virtual. Kedua bahasa tampaknya didasarkan pada ML.

Apa perbedaan terbesar antara F # dan Scala meskipun fakta bahwa F # dirancang untuk .NET dan Scala untuk platform Java?


2
Jika Anda dapat memilih dan berpikir ini adalah pertanyaan yang berguna atau memiliki jawaban yang berguna di bawah ini, silakan pilih. Situs StackExchange membutuhkan suara untuk membangun komunitas yang baik. Anda dapat memberikan 30 suara per hari, jangan sia-siakan. Khusus pengguna dengan reputasi tinggi dan penghitungan suara rendah diberikan, harap baca ini: meta.programmers.stackexchange.com/questions/393/…
Maniero

functional programming langugages that don't force the developer to only use immutable datatypes- apakah ada, kecuali mungkin bahasa mainan?
Ingo

1
@Ingo, jika Anda berpikir bahwa ML dan Ocaml tidak memenuhi syarat sebagai bahasa pemrograman fungsional karena mereka memungkinkan mutabilitas, mungkin Anda harus menyesuaikan definisi Anda!
Frank Shearar

3
+ Frank, Anda pasti salah paham: Maksud saya, bahkan Haskell memiliki tipe data yang bisa berubah. Karenanya, saya masih ingin tahu bahasa apa yang mungkin dimiliki oleh @Jonas yang akan memaksa seseorang untuk menggunakan hanya tipe data yang tidak dapat diubah?
Ingo

Jawaban:


61

Perbedaan Utama:

  • Baik Scala dan F # menggabungkan pemrograman OO-imperatif dan pemrograman fungsional ke dalam satu bahasa. Pendekatan mereka terhadap penyatuan paradigma sangat berbeda. Scala mencoba untuk menggabungkan dua paradigma menjadi satu (kita menyebutnya paradigma objek-fungsional), sedangkan F # menyediakan dua paradigma tersebut secara berdampingan. Sebagai contoh, tipe data aljabar dalam F # adalah konstruksi fungsional murni tanpa OO'ness di dalamnya sedangkan ADT di Scala masih kelas dan objek reguler. (Catatan: Dalam proses kompilasi ke bytecode CLR, bahkan F # ADTs menjadi kelas dan objek tetapi mereka tidak terlihat oleh programmer F # di tingkat sumber.)

  • F # memiliki inferensi tipe gaya Hindley-Milner penuh. Scala memiliki inferensi tipe parsial. Dukungan untuk subtyping dan murni-OO-ness membuat inferensi tipe gaya Hindley-Milner tidak mungkin untuk Scala.

  • Scala adalah bahasa yang jauh lebih minimalis daripada F #. Scala memiliki serangkaian konstruksi ortogonal yang sangat kecil yang digunakan kembali di seluruh bahasa. F # tampaknya memperkenalkan sintaks baru untuk setiap hal kecil, sehingga menjadi sangat sintaks dibandingkan dengan Scala. (Scala memiliki 40 kata kunci, sedangkan F # memiliki 97. Itu akan memberi tahu Anda sesuatu. :-)

  • F # menjadi bahasa Microsoft memiliki dukungan IDE yang sangat baik dalam bentuk Visual Studio. Hal-hal yang tidak begitu baik di sisi Scala. Plugin Eclipse masih belum sesuai standar. Sama berlaku untuk plugin NetBeans. IDEA tampaknya menjadi taruhan terbaik Anda saat ini, meskipun itu bahkan tidak mendekati apa yang Anda dapatkan dengan Java IDE. (Untuk penggemar Emacs, ada ENSIME. Saya telah mendengar banyak hal baik tentang paket ini, tetapi saya belum mencobanya.)

  • Scala memiliki sistem tipe yang jauh lebih kuat (dan kompleks) daripada F #.


Perbedaan lain:

  • Fungsi-fungsi F # diatur secara default. Dalam Scala, kari tersedia tetapi tidak sering digunakan.

  • Sintaksis Scala adalah campuran dari bahasa Jawa, ML Standar, Haskell, Erlang, dan banyak bahasa lainnya. Sintaks F # terinspirasi oleh orang-orang dari OCaml, C #, dan Haskell.

  • Scala mendukung jenis dan jenis kacamata yang lebih tinggi. F # tidak.

  • Scala jauh lebih bisa menerima DSL daripada F #.


PS: Saya suka Scala dan F #, dan berharap mereka menjadi bahasa utama di platform masing-masing di masa depan. :-)


6
Jawaban ini melanggengkan beberapa kesalahpahaman. Saya akan menghitung satu per satu. Anda mengatakan "tipe data aljabar dalam F # adalah konstruksi fungsional murni tanpa OO'ness di dalamnya" tetapi tipe data aljabar dalam F # hanya kelas dan, khususnya, mereka mendukung augmentasi dengan instance OO / anggota dan sifat statis.
Jon Harrop

7
Anda mengatakan "Scala mencoba untuk menggabungkan dua paradigma menjadi satu (kami menyebutnya paradigma objek-fungsional)" tetapi Scala tidak memiliki eliminasi panggilan ekor secara umum dan, akibatnya, kode fungsional non-sepele (termasuk hampir semua idiom fungsional konvensional seperti penerusan kelanjutan) gaya dan melepaskan ikatan rekursif) cenderung menumpuk overflow di Scala dan, oleh karena itu, praktis tidak berguna.
Jon Harrop

4
@ JonHarrop: Scala tidak memperlakukan ADT secara khusus. Mereka diperlakukan seperti kelas reguler. Karenanya Some(2)dalam Scala memiliki tipe Some[Int]dan bukan Option[Int]IMO yang tidak diinginkan. F # di sisi lain lain memiliki sintaks khusus dan pengobatan untuk ADT, dan dengan demikian benar menyimpulkan jenis Some 2sebagai int option. Jadi F # encoding ADT lebih baik daripada Scala (IMO, tentu saja). Saya tidak mencoba untuk menyiratkan bahwa itu lebih rendah, dan saya minta maaf jika itu terjadi seperti itu.
missingfaktor

9
@ JonHarrop: Kurangnya TCO di JVM tidak mengganggu banyak pengembang Scala. Percayalah, ini bukan masalah besar seperti yang Anda pikirkan. Sebagian besar waktu, kami menggunakan fungsi urutan yang lebih tinggi, bukan rekursi eksplisit. Dan sebagian besar fungsi urutan yang lebih tinggi di Scala diimplementasikan dalam hal loop, dan bukan rekursi. Jadi, kekurangan TCO menjadi dekat dengan immaterial.
missingfaktor

8
Saya merasa seluruh jawaban ini sedikit bias terhadap Scala. Sebagai contoh Scala adalah bahasa yang jauh lebih minimalis daripada F # yang tampaknya bertentangan dengan argumennya / titik belakangan dari sistem tipe yang lebih kompleks.
Adam Gent

9
  • F # ditetapkan pada aspek fungsional sedangkan scala didasarkan pada aspek berorientasi objek.
  • F # memiliki dukungan IDE yang lebih baik dengan Visual studio sementara plug-in gerhana Scala untuk IDE open source dan relatif lebih lambat.
  • F #, karena lebih mirip-ML daripada Scala, memiliki lebih dari kalkulus lambda-y minimum yang terasa seperti OCaml, Standar ML, dan Skema miliki. F # tampaknya menjadi bahasa yang jauh lebih sederhana.

4
"F # tampaknya menjadi bahasa yang jauh lebih sederhana." << Tidak, tidak. Ini jauh lebih besar dari Scala. Saya harus menulis artikel tentang hal ini beberapa saat.
missingfaktor

4
"Scala didasarkan pada aspek berorientasi objek." << Salah. Scala mencoba untuk memadukan OOP DAN pemrograman fungsional. Saya pribadi sangat jarang menggunakan fitur berorientasi objeknya. Sebagian besar yang kami lakukan adalah murni fungsional.
missingfaktor

@missingfaktor: "Ini jauh lebih besar dari Scala". Seberapa besar tata bahasanya?
Jon Harrop

1
Saya tidak tahu apakah semuanya telah berubah. Scala di IntelliJ rocks, dengan plugin masih open source.
Colliot

0

Salah satu poin kecil namun penting adalah lisensi: Scala adalah BSD (cukup banyak lisensi perangkat lunak bebas yang paling permisif), F # dulunya adalah "perjanjian lisensi Sumber Penelitian Bersama Microsoft" tetapi merupakan produk komersial saat ini (menurut @Lorenzo di bawah, walaupun saya tidak dapat menemukan perjanjian lisensi yang lebih spesifik di manapun).


3
Sebenarnya, F # sekarang open source dan Scala sekarang merupakan produk komersial dari perusahaan Scala Solutions milik Martin Odersky.
Jon Harrop

4
@ Jon Harrop: Saya pikir Scala Solutions hanya menjual alat, layanan, pelatihan terkait Scala, dll. Bahasa itu sendiri tampaknya masih di bawah lisensi BSD.
Joonas Pulakka

2
@Joonas: Persis, hal yang sama berlaku untuk F #.
Jon Harrop

5
@JonHarrop: Scala tetap open source. Tolong jangan sebarkan informasi yang salah.
missingfaktor

2
@missingfaktor: Saya tidak mengatakan Scala sumber tertutup.
Jon Harrop
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.