Bagaimana agar berhasil dalam pemrograman sistem, apa yang perlu Anda ketahui dan pahami, terutama jika Anda telah bekerja selama dekade ketiga? C # dan kinerja - apakah layak menulis ulang semua yang Anda lihat di C #? Apa masa depan untuk teknologi kompiler tingkat rendah yang menunggu kita?
Hari ini di studio virtual kami,
Alexandre Mutel menjawab pertanyaan.
Alexandre Mutel adalah Arsitek Perangkat Lunak Utama di Unity Technologies. Selain itu, ia adalah pengembang open source terkenal yang berkontribusi terhadap SharpDX, Markdig, Zio dan proyek lainnya, dan sejak 2014 - MVP dalam kategori Visual Studio dan Teknologi Pengembangan.
Alexandre sedang mengerjakan berbagai masalah tingkat rendah dan tingkat tinggi dalam rendering grafik waktu nyata, GPGPU, sintesis suara, penggunaan yang efisien dan arsitektur bahasa yang dikelola, pembuatan kode dan dokumentasi.
Seperti biasa, wawancara dilakukan oleh Evgeny Trifonov (
phillenium ) dan Oleg Chirukhin (
olegchir ) dari Grup JUG.ru.
Di akhir posting ada kejutan dari Dylan Beatty (donor terkenal lainnya) - kami sendiri tidak mengharapkannya.
E: Anda memiliki karir yang panjang, tiga dekade - sebagai permulaan, dapatkah Anda membicarakannya secara singkat?Semuanya berawal di masa kanak-kanak - Saya mendapat Amstrad PC 464. Ketika saya mulai pemrograman di komputer ini, saya berusia 11, atau 12, saya tidak ingat persis. Saya dengan cepat menguasai pemrograman BASIC dan membeli buku tentang pengembangan game: maka itu tampak sangat menarik. Saya bermain sangat sedikit permainan, di mana lebih menarik untuk mengembangkan dan menulis kode. Kemudian saya terus menulis kode assembler untuk Amstrad.
Pada usia 16, saya mendapat Amiga 500. Saya bertemu dengan orang-orang yang menulis demo - itu sama sekali tidak seperti sekarang. Sekarang ini adalah WebGL, dan ini adalah demoscene yang sama sekali berbeda. Saya mulai menulis banyak demo, yang tidak selalu saya tunjukkan, tetapi saya hanya suka menulis di assembler. Dan sesederhana itu.
Kemudian dia pergi ke sebuah perguruan tinggi teknologi, di mana dia belajar teknik komputer. Ini sudah menjadi sesuatu yang sangat berbeda dibandingkan dengan game dan assembler. Saya senang belajar hal-hal yang saya bahkan tidak tahu ada sebelumnya: sistem operasi, UNIX, bekerja dengan bahasa C (sebelumnya saya hanya menggunakan BASIC atau assembler karena saya tidak punya uang untuk membeli kompiler C / C ++).
Ketika dia lulus dari perguruan tinggi, dia mulai bekerja di industri pasar mata uang. Ini adalah pekerjaan untuk perusahaan Prancis di New York. Dua tahun kemudian, saya kembali dan pergi ke bank. Sebenarnya, saya tidak ingin bekerja di bank, saya ingin bekerja di game dev. Namun akibatnya, terjebak ada area baru, banyak hal yang bisa dipelajari. Jadi saya menghabiskan 8-9 tahun di sana, terutama berurusan dengan Jawa dan sedikit dengan C ++. Banyak server terdistribusi dan database SQL, menyalin database ... Tidak sama sekali apa yang saya lakukan sekarang.
Kemudian saya mengambil cuti kreatif dan melakukan perjalanan wisata ke seluruh dunia: Saya berada di Afrika, di Amerika Selatan, setahun penuh di Asia. Perjalanan mengubah saya dan mengguncang saya. Ketika saya kembali, saya tidak bisa lagi bekerja dengan komputer, di bidang TI, saya tidak bisa bekerja untuk bank. Saya berhenti dari pekerjaan saya dan menghabiskan 4 tahun di kursus pekerja sosial untuk bekerja dengan anak-anak, para tunawisma, orang cacat, orang tua. Saya belajar ini selama tiga tahun, dan itu sangat menarik, karena sebagian besar hidup saya, saya bekerja di bidang ilmu pasti: matematika, proyek, abstraksi. Dan kemudian dia tiba-tiba mengambil dan pindah ke daerah yang sangat kemanusiaan. Saya bahkan mencoba untuk bekerja di daerah ini setelah pelatihan, tetapi hanya selama periode ini seorang teman dengan siapa saya melakukan demo sebagai seorang anak mengisyaratkan bahwa kita dapat melakukan ini lagi.
Saya mulai berlatih demo sepanjang waktu senggang saya, dan sangat cepat mulai mengambil lebih banyak daripada bekerja dengan anak-anak di jalan. Itu buruk. Orang-orang berkata: “Kita perlu mencoba mencari pekerjaan di game dev, mengapa tidak? Kamu bisa melakukannya. " Tetapi saya pikir ini tidak mungkin, karena saya sudah lama tidak bekerja dengan komputer, dan sulit untuk menemukan pekerjaan di IT dengan resume saya.
Saya mulai bekerja pada aplikasi open source dan merilis beberapa proyek yang mulai digunakan perusahaan. Suatu ketika, salah satu perusahaan ini menghubungi saya, mereka menggunakan salah satu proyek terbaru yang disebut SharpDX. Saya pergi ke Jepang bersama keluarga saya - karena saya sudah memiliki dua anak. Kami tinggal 5 tahun di Jepang. Saat ini, saya sedang bekerja membuat mesin game dari awal di C #.
Sekitar dua tahun yang lalu, saya kembali ke Prancis dan mulai bekerja di Unity. Ini mengganggu apa yang saya lakukan sebelumnya, tetapi mereka menawarkan untuk bekerja pada tugas yang sangat kompleks dan menarik, tes nyata: untuk membuat kompiler asli yang menghasilkan kode asli dari kode IL .NET. Inilah yang selalu ingin saya lakukan, tetapi tidak bisa, karena saya tidak akan dibayar untuk ini. Dan kemudian ada peluang, peluang besar. Saya bekerja di proyek ini selama 2 tahun.
Ya, sepertinya ceritanya tidak terlalu pendek.
E.: Tidak ada, karier seperti itu layak untuk cerita panjang. Karena pengalaman Anda, saya ingin menanyakan ini kepada Anda. Sekarang beberapa orang berkata, "Hukum Moore tidak lagi berfungsi, komputer tidak menjadi lebih cepat, kita semua hancur." Yang lain menjawab: "Ayo, meskipun mereka tidak mempercepat pada kecepatan yang sama, masih ada pertumbuhan, jadi tidak ada alasan untuk panik." Karena topik produktivitas dekat dengan Anda, dan pada saat yang sama Anda telah mengikuti industri untuk waktu yang lama, apa posisi Anda?Saya mematuhi maksud emas ini.
(tertawa) Saya percaya bahwa banyak, jika tidak sebagian besar aplikasi yang kami kembangkan beradaptasi dengan persyaratan kinerja sejak awal, menghasilkan kualitas terbaik.
Lihat apa yang terjadi di industri TI di depan mata kita. Misalnya, ketika Windows menjadi sedikit lebih lambat selama bertahun-tahun - Windows Vista, dll. Bahkan, pekerjaan alami dilakukan untuk meningkatkan kinerja, karena selama bertahun-tahun tidak terlalu mengkhawatirkan. Ketika Windows 8 keluar, itu sudah sedikit lebih baik. Kemudian Windows 10 keluar dan menjadi sedikit lebih baik. Sebagai hasilnya, kami memiliki sistem yang bekerja dengan sangat baik dibandingkan sebelumnya. Sangat penting bagi mereka untuk melakukan optimasi ini, karena begitu orang tentu "hidup di luar kemampuan mereka" dan mulai berkata: "Oh! Perangkat lunak ini tidak lagi berfungsi, kami beralih ke Linux, karena lebih cepat dan tidak sebodoh itu. "
Hal yang sama dapat dikatakan tentang semua perangkat lunak yang kami kembangkan. Dan yang mengejutkan: selalu ada kecenderungan untuk bekerja dengan kode asli, di beberapa titik bahkan di Windows mereka memutuskan untuk kembali ke C ++, mereka berkata: "C ++ adalah solusi, .NET sangat lambat, kemudian Pengumpul Sampah dan bla bla ... ". Dan lagi, bahasa asli menjadi relevan.
Pada saat yang sama, V8 di Chrome membawa JavaScript kembali digunakan berkat JIT. JS adalah bahasa scripting, bukan superfast, tapi kadang-kadang berfungsi dua kali lebih cepat dari C ++. Itu sudah cukup baginya untuk bertahan dan bagi kami untuk menggunakannya sekarang untuk hal-hal seperti menulis kode dalam Visual Studio Code. Tetapi jika Anda melihat lebih dekat, itu semua karena persyaratan kinerja diletakkan di sana sejak awal. Bahkan dalam VSCode, meskipun ada banyak JavaScript dan kode skrip pada umumnya, yang lainnya - V8, rendering stack, JIT - semua ini ditulis dalam bahasa yang dirancang untuk kinerja maksimum, yaitu, dalam C ++. Semuanya dapat ditulis dalam bahasa lain, tidak harus C ++, tetapi faktanya semua perangkat lunak ini dikembangkan dengan mempertimbangkan kinerja akun sejak awal.
Jadi ya, kita dapat menggunakan bahasa yang kurang efisien dan produktif, tetapi hanya karena semua teknologi yang mendasarinya dikembangkan dengan tujuan untuk mendapatkan
pengalaman pengguna yang fantastis. Misalnya, Visual Studio Code adalah perangkat lunak luar biasa yang bekerja sangat baik untuk pengembang dan memecahkan masalah mereka. Banyak orang mengatakan: "Meskipun kami suka menggunakan lebih banyak editor kode asli, saat ini kami beralih ke Visual Studio Code" - karena mereka menganggapnya cukup efektif. Performa ada di mana-mana, tetapi kadang-kadang kita tidak melihatnya karena sudah tertanam di semua yang kita gunakan.
Kami pikir: ini ditulis dalam JavaScript, karena cukup cepat. Tetapi JavaScript sangat cepat hanya karena ratusan ratusan insinyur pengembangan telah bekerja selama bertahun-tahun untuk mengoptimalkan JIT. Sekarang kita dapat menggunakan bahasa scripting bahkan untuk menulis aplikasi yang sangat kompleks. Bahasa scripting yang tanpa semua pekerjaan persiapan ini akan jauh lebih lambat. Kita hidup di zaman yang aneh. Kami punya pilihan, tetapi masih ada kisah kinerja ini yang berulang untuk setiap bahasa.
Jadi. NET adalah contoh khas. Pekerjaan besar telah dilakukan di sana selama tiga hingga empat tahun terakhir. Jika Anda melihat ASP.NET Core suatu saat, jika Anda melihat semua pekerjaan yang dilakukan dengan CoreCLR ... Kinerja adalah hal yang laris, membutuhkan biaya dan memungkinkan Anda untuk mencapai lebih banyak. Berusaha memenuhi persyaratan yang ketat, Anda dapat mencoba menjadi lebih produktif, Anda dapat menghemat daya, menghemat uang di akhir bulan - kinerja memengaruhi segalanya. Ketika saya mendengar orang berkata: "Semuanya beres, saya sedang mengembangkan aplikasi saya, itu memiliki kinerja rata-rata, itu akan berhasil ...", apa yang mereka pikirkan? Anda perlu meluangkan sedikit waktu untuk memeriksa apakah Anda dapat membuat aplikasi Anda sedikit lebih produktif. Jika Anda dapat menghemat waktu sumber daya atau aplikasi setidaknya sepersepuluh, itu bagus.
E.: Ada sebagian pertanyaan filosofis. Anda pikir Slack bukan tempat terbaik untuk solusi teknis, tetapi di situs Anda, Anda menawarkan untuk berlangganan RSS jadul. Apakah Anda pikir era baru pengiriman pesan instan membuat pengembang kurang produktif?Tidak, kurasa tidak. Sekarang saya bekerja dari jarak jauh. Di tempat kerja, di Unity, kita dapat bekerja dari jarak jauh, jadi saya terus menggunakan Slack untuk berkomunikasi dengan kolega. Ini adalah cara terbaik bagi saya untuk tetap berhubungan dan tetap produktif. Ini membutuhkan banyak waktu dari pekerjaan, karena Anda perlu memeriksa saluran dan sebagainya, tetapi untuk sementara saya dapat mematikan Slack dan fokus pada pekerjaan. Ketika saya bekerja di perusahaan di ruang terbuka, saya tidak punya pilihan: jika seseorang ingin mengajukan pertanyaan, Anda harus segera menjawab, itu jauh lebih rumit.
Sedangkan untuk Twitter dan email, saya tidak sering memeriksanya. Sekali atau dua kali sehari saya membaca Twitter, itu tergantung pada berbagai faktor: apakah saya berpartisipasi dalam diskusi apa pun dan apa yang saya diskusikan. Jika Anda menggunakan sesuatu seperti Slack, Anda dapat bergabung dengan berbagai saluran di perusahaan, Anda dapat mengikuti banyak topik yang tidak akan dapat Anda ikuti jika Anda bekerja sendiri. Kita perlu menemukan jalan tengah: kita semua khawatir tentang banyak hal yang terjadi di perusahaan, tetapi kita harus selektif, karena Anda tidak dapat berpartisipasi dalam semua diskusi pada saat yang sama. Beberapa orang dapat membaca banyak saluran sehingga saya hanya kagum dengan kemampuan mereka, saya sendiri tidak seperti itu. Hari ini saya membaca sekitar 30 saluran, ini tidak terlalu banyak.
E.: Terima kasih, waktunya untuk pertanyaan Oleg!A.: Karier saya agak mirip dengan karir Anda: Saya bekerja di bank, sekarang di bidang yang sama sekali berbeda - dalam menyelenggarakan konferensi, dan pada saat yang sama saya mencoba mencari cara untuk membangun kompiler. Apa yang dapat Anda sarankan kepada mereka yang mencoba beralih ke pemrograman sistem dari pengembang web perusahaan yang sederhana, adakah kiat untuk transisi semacam itu? Saya yakin tidak ada cukup dari kita di sini, sampai cukup.Tidak yakin apakah ada jalur yang disiapkan untuk transisi semacam itu. Jika Anda tertarik pada teknologi tersebut, maka Anda melakukan beberapa pekerjaan rumah biasa. Di rumah, Anda menulis parser dan hal-hal yang berkaitan dengan kompiler. Tidak perlu menulis seluruh kompiler dari awal hingga akhir, sampai kode mesin dibuat. Anda menjadi tertarik untuk menulis infrastruktur kompiler. Inilah yang telah saya lakukan dalam beberapa tahun terakhir bekerja di Unity. Jika Anda bersemangat tentang hal-hal tingkat rendah, maka ini adalah salah satu tempat di mana Anda dapat memahami bagaimana semuanya bekerja dalam kenyataan. Bagaimana cara meningkatkan pekerjaan, di mana ada baiknya meningkatkan kinerja, dan di mana ini belum dilakukan. Jika Anda khawatir tentang kinerja, sangat penting untuk mengetahui apa yang akan dijalankan aplikasi pada akhirnya.
Kinerja adalah tema saya, dan semua ini telah menjadi peluang besar bagi saya. Saya ingin mendekati solusi untuk masalah pada intinya, yaitu pada level kompiler. Di sinilah kita dapat meningkatkan produktivitas puluhan kali di tempat-tempat di mana diperlukan untuk pengguna kami. Jika kita menjalankan game, aplikasi, film, atau sesuatu seperti itu, terkadang bisa relatif mudah untuk mencapai hasil seperti itu.
Semangat saya untuk hal-hal tingkat rendah dan komponen kompiler membuat saya ke pekerjaan saya saat ini. Tetapi itu bukan sesuatu yang secara spesifik ingin saya lakukan. Terkadang, ketika Anda mendapatkan banyak pengalaman dengan berbagai bahasa, Anda menulis aplikasi - Anda bahkan ingin membuat bahasa Anda sendiri. Saya mulai melakukan ini, tetapi berhenti karena terlalu banyak pekerjaan, dan saya memiliki sedikit waktu luang. Tetapi Anda memiliki keinginan bawah sadar untuk kembali "ke akar", cobalah melakukan sesuatu sendiri untuk memahami segalanya. Tentu saja, saya mengerti bagaimana kompiler bekerja dan semua itu, tetapi saya tidak mengerti kerumitan persyaratan. Pengorbanan yang rumit untuk dihadapi, misalnya, di bidang manajemen memori. Sangat sulit untuk memilih apa yang pada saat yang sama akan memberikan produktivitas yang lebih besar bagi pengembang aplikasi dan akan efektif. Masalah ini masih belum terselesaikan sampai akhir. Rust atau .NET tidak akan pernah menyelesaikan ini. Karat itu indah, luar biasa, tetapi sulit untuk dikerjakan, terutama jika Anda beralih ke sana dengan sesuatu seperti JavaScript. Namun, ada contoh pengembang Python atau JavaScript yang bermigrasi ke Rust, meskipun ini agak mengejutkan.
A: Anda menyebutkan bahwa Anda memprogram dalam C # selama 10 tahun terakhir. Jadi apa yang baik dalam C #? Mengapa tidak C ++, misalnya? C ++ tampaknya menjadi bahasa yang lebih sistemik.Sejujurnya, saya benci C ++, saya benci C, tapi saya bekerja dengan mereka. Saya sungguh-sungguh percaya bahwa mereka menyebabkan banyak bug, ke inefisiensi pengembangan besar. Banyak orang berpikir bahwa karena Anda memprogram dalam C, Anda sudah secara de facto menulis kode cepat bahwa program Anda akan berorientasi pada kinerja. Ini tidak benar. Jika Anda memahat tumpukan malloc dan semua itu, itu akan lambat bahkan dibandingkan dengan apa yang ditulis dalam .NET. Pengembang C / C ++ yang baik dipaksa untuk menggunakan trik seperti
pengalokasi memori wilayah . Anda harus mengubur diri Anda sendiri dalam banyak hal aneh yang belum pernah didengar orang. Meskipun di sini pengembang game biasanya tahu tentang hal-hal seperti itu. Minimal, pengembang AAA atau orang yang membuat game dalam kerangka C / C ++. Beberapa masalah berasal dari kompleksitas bahasa itu sendiri. Sebelumnya, saya sama sekali tidak membaca buku tentang C ++, dan hanya tiga atau empat tahun yang lalu saya mulai membaca buku hanya di C ++, hanya untuk merasakan bahasanya. Saya memprogramnya, tetapi saya tidak memiliki pendekatan formal dan sistematis, dan saya dikejutkan oleh kerumitannya, sejumlah hal yang dapat Anda hancurkan jika Anda tidak menulis semuanya dengan benar.
Baru-baru ini beberapa bulan yang lalu ada bug di Unity, seseorang membuat kesalahan dalam sepotong kode C ++, itu ada di konstruktor, sesuatu diteruskan oleh nilai, dan sebagai hasilnya, kami mengambil alamat dari nilai ini dan mencari di cache. Bahkan, kami merujuk ke nilai yang tidak lagi ada di memori. Dan semua ini karena pointer dicampur dengan non-indikator, dan orang yang melakukan refactoring ini tidak memeriksa semua tempat penggunaan. Kode yang sangat berbeda yang bekerja dengan sempurna tiba-tiba berhenti bekerja. Tampaknya ini adalah kesalahan kecil, tapi itu menghancurkan segalanya. Sebenarnya, ini adalah kesalahan dalam bekerja dengan memori. Jadi ya, ketika saya melihat hal-hal seperti itu, saya yakin bahwa kita harus membatasi akses untuk bekerja di C dan C ++, dan meminimalkan penggunaannya. Di bagian .NET, saya benar-benar membatasi penggunaannya hanya untuk hal-hal khusus platform. Tetapi menulis segala sesuatu di C # cukup suram. Untuk mengakses API, Anda harus melakukan banyak dlopen. Meskipun, misalnya, Anda dapat mencoba merangkum semua ini dalam pembungkus dalam C dan mengatur akses melalui hanya satu fungsi. Saya lebih suka mengisolasi hal-hal seperti itu dan mengembangkannya lebih lanjut dalam C dan C ++. Tapi ini adalah topik yang sempit tentang interop, dan kemudian Anda tetap menggunakan bahasa yang dikontrol normal, gunakan sebagian besar waktu, nikmati kompilasi yang lebih cepat.
Saya benci kesalahan dari C ++ compiler dan linker, saya benci kebutuhan untuk bekerja dengan platform yang berbeda, semua ini sangat, sangat sulit. Anda mulai mengkompilasi pada MSVC, maka Anda harus beralih ke Dentang, lalu ke GCC. Di Linux, di Mac, di Windows, di Android, di iOS dan seterusnya dan seterusnya. Bekerja dengan C ++ adalah mimpi buruk!
Saya benci pemisahan antara file dalam editor, file .h dan file cpp. Orang-orang benar-benar bingung dalam bahasa dan mulai memprogram pada makro. Saya suka metaprogramming, tetapi dalam C ++ modern kita hanya bisa melakukan kegilaan total. Sendiri, hal-hal ini luar biasa, tetapi sebenarnya sudah terlalu banyak.
Untuk meringkas: ya, saya pikir kita dapat mengembangkan perangkat lunak yang efektif dalam C #. Mungkin tidak secepat di C ++, tapi kita bisa. Ini persis apa yang kami coba lakukan di Unity - misalnya, kami melakukan burst compiler untuk mengkompilasi bagian tertentu dari C #, mencapai kinerja maksimum, bahkan lebih di tempat daripada yang akan terjadi di C ++ - tetapi tetap dalam C #. Benar-benar aman. Untuk pointer, Anda harus menyatakan tidak aman, jangan membuang pengecualian, lakukan semuanya secara eksplisit. Dan ini adalah pengalaman pahit. Tetapi Anda masih dapat menulis kode yang akan secepat di C ++. Saya pikir ini persis arah. NET bernilai untuk pergi dan ke mana kita harus pergi.
A:: Jika kita berbicara tentang kode sumber terbuka, misalnya, kita memiliki pengumpul sampah di .NET Core, yang merupakan file C yang sangat besar dan menakutkan. Dua megabyte sampah, kemungkinan besar dihasilkan dari sejenis cadel (hampir tidak banyak surat yang layak ditulis secara manual). Mungkin masuk akal untuk menulis ulang semuanya di C #?Ya! Saya mengobrol dengan orang-orang yang bekerja di JIT di Microsoft dan komunitas. Ada sesuatu yang benar-benar saya yakini. Saya percaya bahwa ada saat ketika bahasa Anda menjadi lebih matang dan mendasar, dan kemudian Anda harus menantang, mengujinya untuk kekuatan. Anda harus bisa menggunakannya sebagai fondasi. Buktikan bahwa Anda bahkan dapat menggunakannya untuk membuat sesuatu yang sangat menuntut kinerja. Dan ini adalah kisah Pengumpul Sampah dan JIT. Persentase yang sangat besar dari subsistem .NET runtime, termasuk JIT dan GC, dapat dilakukan dalam C #. Jika Anda membuat aturan bahwa di C ++ Anda hanya bisa menggambarkan abstraksi platform dasar, ini akan membuat sebagian besar platform runtime independen. Saya akan sangat senang jika ini terjadi. Tapi ini pekerjaan besar.
Ada satu alasan mengapa saya terutama menyukai ide ini. , C/C++ , - . , . - , IDE , , — . C#, . , , . . , , , CoreRT C# C++. .
, .NET GC C#. . , , .NET GC, -. GC, , - GC. Java- Jikes RVM — Java. , Golang C, Golang. Golang-, , . , , , . , . LLVM, .NET JIT.
, , .
.: , . — . , AST- . Golang , . , ? ?, , ! , . : . : -, .
: , , , , . , : « ! !». . , .
LLVM, — , . , , , , , . . , , . , . , , , , ? , , , . , - : «, , , - » — , , , .
, . , , , , , , - . , : , , . , , . , , . , . , — .
— . -. , -, API, . . , SharpDX . . , , , . DirectX C++ API, C++. , . , - , . : , . , SharpDX. , PR, . pull request ( ). - . - , SharpDX - . : « ?» ( , ) , . 90- — . , , .
, , , , : , , .
.: — , ? . , , ?, — , SIMD. , , SIMD , . ( LLVM, , ). , , . , , , . - , . , . . - Intel LLVM. , , LLVM. , , . LLVM — , , , .NET. SIMD, CPU — . , , .NET — SIMD- . , , .
: « ». . . LLVM : -, , . , , Roslyn C#, . , , . , , , . SIMD — . GPU, CPU, — . 6, 8, 16, 42 . - , , .
.: Markdown Markdig, ? , Markdown? , ?, Markdown — , . , , Word - . . ? , , . . , RFC — , , , . , , . , ASCII-art. Word, PDF . Word. - — . , . Markdown, , - — , HTML. , . HTML, Markdown . , Github, Markdown- . . — . , Microsoft Markdown, GitHub, PR — , .
Markdown, CommonMark, , Markdown. , CommonMark — . , , . ,
Github CommonMark . — . . Microsoft CommonMark, Markdig. , Markdig , Markdown-, . , , , CommonMark, Markdig. , . Markdig , , , . , Microsoft .
.: , ? ?, . — , . . , . , , , . , . « , , ». , ? , , , , , - . , Google « X» « ». , — . , , , . , , - — , . « , - ?»
, , . . , , . , - . , , , . — , , ? , ? , .
, . . ? ? , , . , … - , . . , , , .
. . ! , . — . , — - . , , , . , , , . , . , . . , - : « !». -, , , . , . .
Ini adalah kisah tentang pengembangan diri, mengajukan pertanyaan sebanyak mungkin, berusaha bersikap terbuka kepada orang-orang yang Anda temui, tentang peristiwa yang dapat Anda gunakan, dan mengambil bagian dalam sesuatu yang lebih dari diri kita sendiri.
Jumat depan, Alexandra akan memberikan presentasi "Di balik compiler burst, mengkonversi .NET IL ke kode asli yang sangat dioptimalkan dengan menggunakan LLVM" di DotNext 2018 Moscow . Konferensi ini akan diadakan 22-23 November di Moskow dan, tampaknya, itu akan menjadi DotNext terbesar dari semuanya. Kami akan memberi tahu Anda apa lagi yang diharapkan dari konferensi, tetapi lebih baik dilakukan oleh pembicara lainnya, Dylan Beatty - ia merekam seluruh lagu: