Ulasan Haxe: Fitur dan Kekuatan Haxe 4

Tinjauan Haxe kami sebelumnya berakhir dengan melihat Haxe 4 yang akan datang. Dengan rilis resmi Haxe 4 (dan tak lama kemudian, dua rilis patch bug—versi 4.0.1 dan 4.0.2), inilah saatnya untuk tinjauan Haxe baru . Apa tambahan terbaru untuk bahasa pemrograman yang sedang berkembang ini? Ke mana arah komunitas bahasa pemrograman Haxe? Apakah mesin game Haxe masih menjadi andalannya?

Ulasan Haxe: Fitur Baru Haxe 4

Dengan lebih dari tiga tahun pengembangan sejak rilis besar terakhir, versi 4 bahasa pemrograman Haxe meningkatkan kinerja makro, pengalaman pengembang, dan sintaksis. Tiga dari peningkatannya masih dianggap eksperimental tetapi patut disoroti: target bytecode JVM baru, dukungan untuk markup inline, dan pemeriksaan keamanan nol.

Target Kompilasi Bytecode JVM Eksperimental di Haxe 4

Target bytecode JVM baru Haxe 4 membuat pengembangan Java melalui Haxe sedikit lebih efisien dengan memotong langkah kompilasi utama: Tidak ada langkah kedua untuk memiliki kompiler Java sendiri ( javac ) mengkompilasi output kode sumber Java dari transpiler Haxe.

Metode kompilasi dengan Haxe 4 ini juga sepenuhnya menghilangkan ketergantungan pada Java developer kit (JDK), dan membuka pintu untuk debugging interaktif untuk diterapkan di masa mendatang.

Sampai versi utama hxjava kompatibel dengan Haxe 4, pengaturan dasar melibatkan pemasangan Haxe dan Haxelib, kemudian menjalankan haxelib install hxjava 4.0.0-alpha . Setelah itu selesai, alur pengembangannya sederhana:

 # transpile directly to JVM bytecode with Haxe (-D jvm would also work): haxe --main HelloWorld --java jar_output --define jvm # run JVM bytecode with Java: java -jar jar_output/HelloWorld.jar

Mengingat bahwa kompilasi JVM langsung masih memiliki status eksperimental di Haxe 4, ia hadir dengan beberapa peringatan:

• Ada beberapa masalah khusus untuk Android.
• Performa runtime tidak begitu bagus, meskipun pada akhirnya akan lebih cepat daripada metode tidak langsung.

Meskipun demikian, ini adalah langkah penting ke arah yang benar bagi siapa pun yang memanfaatkan teknologi berbasis Java.

Dukungan Markup Sebaris Eksperimental di Haxe 4

BEJ, siapa saja? Haxe 4 memungkinkan markup sebaris, memungkinkan pengembang untuk menulis, misalnya, HTML langsung di dalam kode sumber Haxe:

 var dom = jsx( <div> <h1>Hello!</h1> <p>This is a paragraph.</p> </div> );

Karena jsx() di sini bisa menjadi fungsi makro statis, ini memungkinkan proyek untuk memiliki pemeriksaan waktu kompilasi, apakah markup sesuai dengan spesifikasi XML apa pun yang ingin diterapkan oleh pengembang. Karena dukungan XML itu sendiri dibangun ke dalam Haxe API, pemeriksaan dapat memanfaatkan Xml.parse() , tetapi untuk kemampuan parseabilitas “XML-ish” dasar, bahkan itu tidak diperlukan:

 static macro function jsx(expr) { return switch expr.expr { case EMeta({name: ":markup"}, {expr: EConst(CString(s))}): macro $v{"XML MARKUP: " + s}; case _: throw new haxe.macro.Expr.Error("not an xml literal", expr.pos); } }

Maksud dari fitur ini adalah untuk membantu mendorong Haxe keluar dari gelembung pengembangan game (walaupun pasti juga digunakan di sana). Sudah cukup umum bahwa itu diimplementasikan pada tingkat kompiler—karenanya tidak memerlukan Haxe API di makro di atas—tetapi memeriksa DSL tertentu adalah pertanyaan berikutnya yang harus dipecahkan oleh tim kompiler dan komunitas.

Keamanan Null Eksperimental di Haxe 4

Sejak penemuan referensi nol pada tahun 1965, masalah keamanan nol sering menjadi kutukan pengembang di lingkungan yang dapat diketik null seperti bahasa pemrograman Haxe. Aleksandr Kuzmenko memperkirakan bahwa GitHub berkomitmen untuk memperbaiki jumlah kesalahan referensi penunjuk nol lebih dari 10 juta.

Haxe 4 memiliki makro keamanan nol waktu kompilasi bawaan, yang dapat diaktifkan dengan menyertakan baris @:nullSafety tepat sebelum definisi yang diberikan. Muncul dalam @:nullSafety(Loose) (default) dan @:nullSafety(Strict) , dan dapat dinonaktifkan sesuai kebutuhan dengan @:nullSafety(Off) . Mode Strict akan memeriksa panggilan fungsi untuk mutasi bidang yang mungkin menetapkan nol, bahkan dalam konteks keamanan-nonaktif nol.

Pengembang Ruby mungkin bertanya-tanya apakah operator navigasi aman yang berguna ( ?. di Ruby) ada di radar. Belum, tetapi seperti banyak aspek pemrograman di Haxe, ada makro untuk itu (perhatikan bahwa ia menggunakan !. sebagai gantinya.)

Pengalaman Pengembang (DX) dengan Haxe 4: Penambahan Sintaks, Gula Sintaksis, dan Lainnya

Penambahan terkait DX ke bahasa pemrograman Haxe dan dukungan Haxe IDE menghadirkan pengalaman Haxe 4 setidaknya sejajar dengan bahasa pemrograman lain di berbagai bidang. Dalam beberapa hal, Haxe berusaha menjadi segalanya bagi semua orang, tetapi tim penyusun mengambil pendekatan yang bijaksana untuk mengintegrasikan fitur dan konvensi yang paling berguna dari bahasa lain.

Hasilnya adalah bahasa pemrograman Haxe dan API standar berkembang tanpa mengurangi stabilitas, kepekaan, dan keterpaduannya. Tidak semua dalam ulasan Haxe ini akan tampak layak untuk dihebohkan, dan justru itulah intinya: DX meningkat, dan ini mendukung sekadar mengejar "fitur du jour " yang mencolok.

Namun, ada keseimbangan yang bisa didapat: Perubahan Haxe dilakukan dengan kesadaran akan pola yang diikuti bahasa lain, dan Haxe 4 tentu saja berupaya menarik pendatang baru dari bahasa yang lebih populer.

Sintaks "Jenis Fungsi" Baru

Pada catatan itu, Haxe sekarang mendukung dua cara utama untuk merepresentasikan tipe fungsi. Sintaks lama "menyarankan bahwa kari otomatis dan aplikasi parsial didukung, tetapi tidak," menurut proposal fitur asli:

 Int -> String -> Void

Sintaks baru memungkinkan argumen bernama, yang meningkatkan DX:

 (id:Int, name:String) -> Void

Tetapi selain DX, menggunakan sintaks baru Haxe 4 untuk tipe fungsi adalah kebiasaan yang baik untuk dilakukan, karena sintaksis lama yang lebih rendah dapat dihapus di versi utama yang akan datang.

Gula Sintaks… Semacam

Mungkin ini bukan terobosan baru, tetapi peningkatan sintaksis Haxe 4 akan menjadi berita yang disambut baik untuk pengembang Haxe yang sudah ada dengan latar belakang pengembangan tertentu (ES6, misalnya) dan mereka yang mungkin datang dari mereka ke Haxe untuk pertama kalinya.

Sintaks fungsi panah ("lamda pendek") sekarang didukung, yang dalam kasus Haxe kurang lebih hanyalah jalan pintas untuk mengetik function dan return . Sintaks iterasi nilai kunci dan nilai indeks (untuk peta dan larik, masing-masing) sekarang juga didukung. Ketik deklarasi menggunakan ekstensi statis hanya dapat menggunakan satu pernyataan using secara global alih-alih membutuhkannya di mana pun metode ekstensi statis yang sesuai digunakan.

Enum dan abstrak enum memiliki beberapa peningkatan lain, salah satunya adalah bahwa yang terakhir telah pindah dari lingkup makro ke memiliki dukungan kompiler langsung. Fitur lain yang dipindahkan dengan cara yang sama termasuk kelas akhir, antarmuka akhir, dan bidang eksternal.

Beberapa fitur yang mengandalkan makro tetap bergantung pada makro, namun tetap ditingkatkan. Kelebihan operator ditingkatkan untuk menyertakan setter bidang, dan metadata sekarang dapat diberi namespace dengan . pemisah seperti pada @:prefix.subprefix.name .

Menyebut perubahan sintaksis gula di atas memang terlalu menyederhanakan, tetapi pembaca dipersilakan untuk menggali proposal asli yang ditautkan dari catatan rilis Haxe 4 di mana mereka membutuhkan lebih banyak detail.

Lebih Banyak Peningkatan Haxe 4 DX

Sementara debugging interaktif sudah dimungkinkan di Haxe untuk berbagai target yang dikompilasi, target eval baru memungkinkan debugging interaktif untuk kode yang ditafsirkan. Untuk contoh sederhana, Anda dapat mengambil direktori proyek tutorial Haxe “Hello, World”, menambahkan file bernama whatever-you-want.hxml terlihat seperti ini:

 --main HelloWorld --interp

…dan dapatkan debugging interaktif di VSCode IDE hanya dengan:

1. Membuka direktori proyek di VSCode;
2. Menambahkan breakpoint di suatu tempat; dan
3. Menekan F5 dan memilih "Haxe Interpreter" dari dropdown.

Fitur ini juga memungkinkan Anda untuk secara interaktif men-debug kode makro dengan cara yang sama, bahkan jika Anda benar-benar mengkompilasi untuk target tertentu seperti java (daripada menggunakan --interp ). Satu-satunya persyaratan instalasi selain Haxe dan VSCode sendiri adalah ekstensi Haxe VSCode.

Layanan IDE

Berbicara tentang IDE, Haxe 4 memperkenalkan protokol layanan IDE baru, yang sudah dimanfaatkan dalam ekstensi VSCode Haxe terbaru, vshaxe. Selain peningkatan kinerja yang signifikan, ini memungkinkan vshaxe untuk memberikan beberapa peningkatan DX yang sangat berguna, termasuk:

• (Sudah lama ditunggu) impor otomatis
• Petunjuk arahkan pelengkapan otomatis yang menampilkan lebih banyak detail, seperti menjawab pertanyaan, “Dari mana bidang ini berasal?”
• Pelengkapan otomatis yang sangat menyeluruh dalam beberapa cara baru yang apik, seperti penyelesaian tipe yang diharapkan, penyelesaian postfix, dan penyelesaian override
• Optimasi down-to-the-keystroke saat mengetik kode

Jauh lebih mudah untuk melihat nilainya melalui demo visual yang luar biasa dari log perubahan vshaxe yang relevan. vshaxe dengan VSCode bukan satu-satunya Haxe IDE yang ada—HaxeDevelop dan Kode Studio khusus untuk Haxe, dan ada plugin Haxe IDE untuk IntelliJ IDEA, Sublime Text, Atom, dll.—tetapi tampaknya lebih unggul dalam hal memanfaatkan protokol layanan IDE baru Haxe 4, diikuti oleh IntelliJ-Haxe.

Literal Unicode

Pengembang yang ingin menggunakan literal string Unicode nyata akan menemukan dukungan untuk itu di Haxe 4, tetapi ada beberapa nuansa yang harus diperhatikan.

Array hanya-baca

API Haxe standar sekarang memiliki larik hanya-baca. Ini mudah digunakan seperti mendeklarasikan variabel bertipe, misalnya, haxe.ds.ReadOnlyArray<Int> , setelah itu mencoba menyetel, mendorong, atau memunculkan nilai menghasilkan berbagai kesalahan kompiler. Tambahkan kata kunci final ke deklarasi, dan penugasan ulang array itu sendiri juga akan dilarang.

Inlining situs panggilan

Call-site inlining adalah fitur bahasa Haxe baru yang memungkinkan pengembang mengontrol dengan baik di mana fungsi-fungsi disejajarkan, berguna saat mengoptimalkan fungsi yang sering dipanggil di mana tradeoff ukuran-kinerja keseluruhan mungkin merupakan keputusan kalah-kalah.

Ini adalah tambahan yang bermanfaat untuk bahasa pemrograman Haxe yang sudah sangat baik. Apa pengembang di komunitas Haxe yang sekarang setelah Haxe 4 keluar?

Beyond Haxe Game Engine: Pengembangan Web dengan Haxe 4

Basis pengguna Haxe secara historis didominasi oleh pemrogram game. Namun ada banyak contoh Haxe yang digunakan—dalam skala besar—di segmen lain, seperti tumpukan bisnis, aplikasi seluler, dan web, baik untuk pengembangan front-end maupun back-end.

Untuk itu, Haxe 4 memasok eksternal HTML yang diperbarui, yang berarti bahwa API standar js.html telah diperbarui dengan API web yang lebih luas seperti yang didefinisikan oleh MDN, serta memperbaiki bug dan menambahkan API yang hilang. (Misalnya, Haxe 4 sekarang menyertakan Push API.)

Dalam ceramah Juraj Kirchheim, Weaving a Better Web with Haxe, ia menunjukkan contoh solusi web berbasis Haxe yang lebih efisien—namun juga lebih tangguh—dalam pengaturan perusahaan.

Dia juga menentang pendekatan arsitektur Rails (dalam hal hierarki folder), tetapi pengembang yang menyukai kerangka web lengkap ala Rails masih dapat menemukannya. Di lain waktu, mungkin bermanfaat bagi pengembang untuk meninjau sumber proyek web yang lengkap, dalam hal ini perlu melihat repo publik untuk Giffon, platform crowd-gifting yang mendukung Haxe 4. Demikian juga, web-centric, open- sumber perpustakaan Haxe seperti JavaScript-splitting Haxe Modular, thx.core generik dan perpustakaan saudaranya, dan toolkit web Haxe yang terhormat Tinkerbell semuanya sudah mendukung Haxe 4. Begitu juga solusi UI lintas platform HaxeUI, yang mendukung konteks web tetapi menargetkan cakupan yang lebih luas termasuk pengembangan aplikasi bisnis dan desktop; khususnya terus berkembang hingga rilis bahasa Haxe yang baru.

Web, game, perusahaan… terlepas dari platform dan citarasa aplikasi yang ditargetkan oleh tim pengembangan—bahkan satu tim—, pengembang Haxe pada akhirnya harus bergulat dengan pengelolaan dependensi. Untuk ini, sumber daya yang berguna untuk ditinjau oleh pengembang Haxe adalah slide dari pembicaraan Adam Breece, Menskalakan dengan baik dengan orang lain.

Haxe sebagai Bahasa Pemrograman Terbaik untuk Game

Apakah ada satu bahasa "terbaik" untuk pengembangan game? Ini adalah pertanyaan subjektif, dan mudah untuk menemukan perdebatan sengit tentang. Lebih besar dari yang bisa diharapkan dari ukuran komunitasnya saja, keberhasilan Haxe di bidang pengembangan game tentu bukan kebetulan. Joe Williamson memberikan beberapa wawasan tentang mengapa ini mungkin dalam sebuah wawancara tentang memenangkan game jam Ludum Dare 45 pada tahun 2019, dan ini tampaknya akan berlanjut dengan Haxe 4.

Pencipta asli Haxe, Nicolas Cannasse, sudah menggunakan Haxe 4 dalam produksi dengan Northgard dari Shiro Games. Motion Twin juga menggunakan Haxe 4 dalam produksi untuk Dead Cells. Kedua game memiliki puluhan ribu ulasan positif di Steam, dan tersedia untuk PC (Win, Mac, dan Linux) dan konsol—hasil yang benar-benar hebat mengingat kedua game memiliki tim pengembangan yang lebih kecil namun basis pengguna dalam jutaan. Dead Cells bahkan memiliki versi iOS, dengan versi Android di radar mereka juga.

Dari segi perpustakaan, beberapa mesin game Haxe utama pasti mengikuti perubahan Haxe 4. Mesin yang kompatibel dengan Haxe 4 termasuk Kha (dan sebagian dari banyak mesin yang dibangun di atasnya—misalnya, Armory), HaxeFlixel dan ketergantungan utamanya OpenFL, NME, dan Heaps—tentu saja, karena itulah yang digunakan oleh Northgard dan Dead Cells. HaxePunk juga bekerja pada kompatibilitas Haxe 4; dalam satu kasus, perpustakaan, Nape, bercabang untuk bekerja dengan Haxe 4.

Beberapa pengembang juga membuat mesin mereka sendiri daripada menggunakan salah satu dari banyak yang sudah ada di luar sana. Misalnya, Kirill Poletaev, yang merinci bagaimana dan mengapa dia menulis mesin game 3D Haxe miliknya sendiri. Karena mesin tersebut ada di rumah, masuk akal jika ini adalah salah satu contoh proyek yang belum bermigrasi ke Haxe 4.

Haxe 4: Melanjutkan Kemajuan Lancar dari Toolchain Luar Biasa

Dengan Haxe yang memiliki utilitas yang begitu luas, fitur Haxe 4 yang paling penting akan bervariasi menurut pengembang, jadi ulasan Haxe ini sama sekali tidak lengkap. Beberapa perubahan Haxe 4 yang hilang di atas, antara lain:

• Penambahan output ES6 untuk target JavaScript
• Penghapusan fitur (beberapa di antaranya masih tersedia melalui perpustakaan hx3compat ) dan target (PHP5 dan segera AS3)
• Bendera CLI dibuat lebih konsisten dengan alat umum ( -lib -menggunakan file .hxml perlu diubah ke -L atau --library , misalnya).
• Selain final sekarang menjadi kata kunci (yang karenanya tidak dapat digunakan sebagai nama variabel), operator dan overload juga merupakan kata kunci yang baru dipesan.

Ada juga beberapa perubahan yang melanggar, tetapi sangat sedikit sehingga banyak perpustakaan yang dipelihara secara aktif bahkan tidak repot-repot mengumumkan kompatibilitas Haxe 4 secara eksplisit—secara umum, migrasi dari Haxe 3 dikatakan cukup mudah. Lagi pula, salah satu tujuan Haxe adalah stabilitas di tengah dukungan juggling untuk sejumlah besar platform target, dan Haxe 4 tidak mengecewakan di sini.

Bagaimana dengan pengguna baru? Pada akhirnya, terserah pembaca untuk memutuskan apakah Haxe adalah bahasa pengkodean terbaik untuk game, apakah ekosistem Haxe menawarkan perpustakaan paling kuat untuk pengembangan web, atau apakah perkakas khusus Haxe memberikan DX paling masuk akal untuk alur kerja tertentu. Paling tidak, Haxe terus menjadi pesaing yang layak di banyak ruang, menawarkan sesuatu keuntungan rahasia untuk hampir semua pengembang.

Bacaan lebih lanjut: Pengembang yang baru mengenal Haxe mungkin tertarik dengan tutorial Haxe yang cukup baru oleh John Gabriele, dan juga catatan rilis Haxe 4.1.0 dan Haxe 4.1.1.