Apakah insinyur perangkat lunak benar-benar perlu mengetahui hal-hal tingkat rendah lagi? [Tutup]

Ketika bahasa pemrograman tingkat tinggi seperti C #, Java, dll berkembang, banyak orang mengklaim bahwa mereka akan menjadi alternatif untuk bahasa seperti bahasa assembly dan C / C ++, yang memberi Anda akses dan kontrol ke perangkat keras komputer, karena programmer harus fokus tentang cara membuat program dan menyelesaikan masalah, tidak membuang waktu berurusan dengan komputer untuk membuatnya bekerja. Karena perangkat keras terus membaik, perbedaan kinerja antara C / C ++ dan Java tidak akan signifikan, dan permainan besar mungkin dapat diprogram dalam bahasa seperti Java.

Itulah ide umum yang saya rangkum secara singkat setelah melihat topik ini di Internet. Apakah Anda pikir itu akan menjadi nyata dalam waktu dekat? Apakah itu berarti semua yang kita pelajari tentang hal-hal tingkat rendah tidak praktis untuk industri perangkat lunak lagi? Apakah itu berarti, bahasa rakitan dan C / C ++ akan menjadi relevan hanya untuk insinyur listrik, karena mereka akan menjadi satu-satunya yang perlu memprogram untuk komponen listrik mereka?

---

Berapa banyak belajar yang cukup? Jika kita belajar terlalu banyak hal-hal tingkat rendah, kita akhirnya akan menjadi lebih berorientasi pada teknik listrik atau jika kita belajar terlalu banyak matematika, kita bisa belajar menjadi ahli matematika, bukan programmer. Saya hanya ingin tahu apakah materi Matematika yang saya pelajari (saya mengambil kursus Matematika yang mencakup materi yang mirip dengan buku ini (mereka menggunakan buku teks yang berbeda): Matematika Terpisah dan penerapannya) sebenarnya sama bermanfaatnya dengan keahlian pemrograman kami. Banyak latihan matematika dapat mengambil sebagian dari kita jam untuk melakukannya, dan jika Anda serius dengan itu, Anda akan memiliki sedikit waktu untuk pemrograman studi. Dalam forum gamedev kita, bahkan Matematika dan Fisika hanya memiliki satu bagian untuk membandingkan untuk pemrograman yang.

Saat ini saya baru saja mulai membaca "The Art of Computer Programming". Matematika hanya dibahas dalam sekitar seperempat buku, tetapi latihan ini sulit bagi kita yang bukan ahli matematika. Bahkan matematika "dasar" semacam itu, apakah kita sering menggunakannya dalam karier? Beberapa orang mungkin akan memberi tahu saya membaca buku TACOP adalah buang-buang waktu dan mungkin harus menghabiskan waktu untuk hal lain yang lebih praktis, meskipun buku ini tentang pemrograman (sedikit lebih akademis dibandingkan buku menjelaskan hal-hal serupa). Tetapi saya pikir penulis berusaha keras untuk memproduksinya. Dia bahkan dapat menulis set lengkap 5 buku, sementara kita - para penonton - hanya memiliki misi untuk membacanya. Kenapa tidak?

Pertanyaan menarik. Saya seorang programmer C ++ lama yang sekarang bekerja di C # (dengan sedikit C ++ tidak dikelola untuk kinerja kritis), dan secara historis harus menambahkan sedikit kode assembly, biasanya untuk alasan kinerja.

Beberapa poin dalam mempersiapkan respons terhadap pertanyaan:

• Demi perbandingan Anda, saya sarankan bahwa perbedaan utama antara bahasa yang Anda sebutkan, C # dan Java, dari set yang lain, Assembly, C / C ++ adalah bahwa yang pertama menggunakan runtime yang dikelola untuk menyediakan pengumpulan sampah. Ada perbedaan-perbedaan lain (misalnya portabilitas biner, ukuran kerangka kerja dan portabilitas), tetapi ketika Anda melihat untuk membandingkan perbedaan kinerja, ini adalah kontributor utama (?)

• Assembly, C, dan C ++ jauh dari "level-rendah" yang sama. Saya pikir Anda benar dalam mengaitkan bahasa Assembly dan C dengan pengembang perangkat keras / firmware / driver, tetapi C ++ biasanya digunakan pada tingkat yang lebih tinggi, dan masih digunakan dengan berat - meskipun jelas C # / Java sedang menggantinya menurut TIOBE indeks.

• Di tingkat C ++, saya akan menambahkan Objective-C, karena lebih mirip dengan C ++ daripada C # / Java. Akhirnya, saya perhatikan bahwa dengan penambahan shared_ptr <> dan fitur manajemen sumber daya otomatis lainnya, bahasa ini memiliki dukungan untuk sesuatu yang dekat dengan pengumpulan sampah.

OK - lanjut ke pertanyaan utama Anda: Apakah insinyur perangkat lunak benar-benar perlu mengetahui hal-hal tingkat rendah lagi?

Jawaban saya: Ya

Alasan:

• Bahkan ketika menggunakan C # / Java, Anda kemungkinan akan mengalami entitas kerangka kerja yang membutuhkan manajemen sumber daya eksplisit, dan / atau mengalami masalah grafik memori "yang disematkan" pada aplikasi non-sepele. Anda perlu memahami cara kerja sistem ini untuk menghindari dan debug masalah ini secara efektif.
• Platform seluler memiliki sumber daya yang lebih terbatas, dan meskipun ada dukungan untuk versi Java dan .NET yang terbatas pada sebagian, dominasi iOS dan Objective-C saat ini menunjukkan live yang sudah lama diperbarui.
• Kinerja: kapan pun Anda menabrak dinding kinerja, Anda mungkin perlu memasukkan potongan kode yang dikompilasi secara asli untuk menyiasatinya.
• Dukungan Legacy: kapan saja Anda perlu interop untuk mendapatkan akses ke fitur yang tidak terpapar (belum) dalam kode terkelola, Anda harus melakukan hal yang sama.

Pertanyaan bagus - tapi saya tidak melihat bahasa yang tidak dikelola hilang dalam waktu dekat.

• Bahwa seseorang secara sah tidak akan belajar tentang dan tidak memahami fungsionalitas tingkat bawah, dan masih menjadi pengembang yang sangat produktif dan berharga, sudah menjadi masalah.
• Bahwa tidak seorang pun perlu mempelajari atau memahami fungsionalitas tingkat bawah, bahwa itu akan selalu membuang-buang waktu, tidak akan pernah menjadi masalah.

Seperti dalam disiplin teknik apa pun, ada banyak langkah menuju produk akhir, yang semuanya penting, menuntut keahlian, dan berharga. Khususnya dalam rekayasa perangkat lunak, kami memiliki banyak lapisan abstraksi. Semua dibutuhkan, dan tidak ada yang bisa menjadi ahli dalam semua itu.

Karena itu, kita membutuhkan lebih banyak pengembang C # / Java / Ruby daripada pengembang Assemby / C. Bagi kami pengembang "tingkat yang lebih tinggi", memahami lebih banyak tentang apa yang terjadi "di bawah tenda" sangat membantu, dan akan menjadikan kami pengembang yang lebih baik. Tapi begitu juga banyak hal lainnya . Sebagai pengembang .NET, untuk exmaple, ada banyak hal yang dapat saya pelajari yang akan membuat saya lebih produktif, sehingga mempelajari Bahasa Menengah kami (apalagi C ++ / C / Assmebly), meskipun sangat membantu, seringkali harus mengambil kursi belakang.

Anda dapat mencari nafkah hari ini sebagai programmer tanpa mengetahui hal-hal tingkat rendah. Saya pikir itu hanya membuat Anda seorang programmer yang lebih baik untuk mengetahuinya.

Mempertahankan kompetensi tingkat tinggi dengan hal-hal tingkat rendah, semakin menjadi kurang penting. Maksud saya, saya belum melakukan apa pun dalam pertemuan selama 20 tahun dan mungkin perlu penyegaran serius sebelum saya bisa produktif lagi, tetapi konsep keseluruhan tentang bagaimana hal-hal bekerja pada tingkat itu masih merupakan bagian dari kesadaran saya dan saya menemukan itu membantu dari waktu ke waktu bahkan ketika bekerja dalam bahasa tingkat yang lebih tinggi.

Saya rasa tidak, pengembang kernel akan selalu membutuhkan hal-hal tingkat rendah. Juga tidak ada salahnya untuk memahami bagaimana semuanya berjalan, jika Anda secara mendasar memahami apa yang sebenarnya Anda lakukan dengan kode yang Anda tulis, Anda akan belajar menulis kode yang lebih baik. Saya pikir menghapus hal-hal tingkat rendah adalah ide yang mengerikan karena pemikiran abstrak ini kadang-kadang berguna tetapi sebenarnya bisa menjadi penghalang jika Anda ingin masalah diselesaikan dengan cara terbaik. Sebagai contoh, memahami bahwa ketika Anda menggabungkan string, Anda sebenarnya membuat string baru adalah penting, tetapi jika Anda tidak mengerti bagaimana string diimplementasikan, Anda mungkin hanya menyatukannya dan menunggu 5 menit yang dibutuhkan program Anda untuk menjalankannya. Ini adalah artikel yang bagus tentang hal-hal seperti ini: http://www.joelonsoftware.com/articles/fog0000000319.html

Ini tergantung pada apa yang benar-benar dikerjakan oleh insinyur perangkat lunak. Adalah mungkin untuk memiliki karir yang produktif, bahagia, dan menguntungkan tanpa pernah menyentuh level rendah apa pun sekarang, tapi itu tidak semua pekerjaan pemrograman. Agar ada sistem operasi dan kompiler, harus ada insinyur yang bekerja pada sistem operasi dan kompiler, dan mereka harus tahu C, C ++, dan bahasa rakitan mesin mereka.

Kinerja juga penting. Laptop saya saat ini kira-kira sejuta kali lebih kuat daripada komputer di rumah pertama saya, dan menjalankan perangkat lunak masih membutuhkan waktu. Saya masih bisa mendapatkan lag di video game. Tentu saja, permainan video terlihat lebih baik, karena masing-masing lebih dari satu juta piksel pada layar dapat diberikan satu juta warna (berbeda dengan seribu posisi karakter hitam-putih, dengan beberapa karakter digunakan untuk grafis ). Saya ragu kita akan mendapatkan seribu kali lipat lagi peningkatan daya komputer dalam waktu dekat, dan jika kita lakukan saya berharap itu akan digunakan oleh perangkat lunak yang semakin kompleks.

Sementara sebagian besar perangkat lunak bisnis akan terus ditulis dalam apa yang tercepat untuk diproduksi dan keluar dari pintu, yang biasanya bukan C, akan ada banyak ruang bagi para pakar C dan C ++.

"Dengan perangkat keras yang terus meningkat, kinerja antara C / C ++ dan Java tidak akan signifikan, dan permainan besar mungkin dapat diprogram dalam bahasa Java seperti itu."

Saya tidak percaya pernyataan itu akan benar dalam waktu dekat. Selalu ada hit dalam kode yang dikelola karena pemeriksaan dilakukan di belakang layar. Ini juga bukan masalah perangkat keras yang lebih baik, karena perangkat keras menjadi lebih baik begitu juga aplikasi yang diharapkan untuk berjalan pada mereka. Sistem yang ditulis dalam kode asli harus memiliki antarmuka untuk kode yang dikelola. Ada hit kinerja yang terjadi ketika beralih di antara keduanya.

Namun hanya sebagian kecil aplikasi yang benar-benar membutuhkan kode yang dioptimalkan ini. Sebagian besar lini aplikasi bisnis baik-baik saja dengan kode yang dikelola, .net, java, dll. Ini tidak berarti meskipun aplikasi yang membutuhkannya akan melakukan peralihan dalam waktu dekat. Namun rakitan tulisan tangan jauh lebih sedikit digunakan sekarang dengan mengoptimalkan kompiler C / C ++ yang begitu baik. Ada baru-baru ini OS yang sepenuhnya ditulis dalam perakitan, jadi masih ada yang memilikinya. Ini juga cukup penting di bidang keamanan.

Saya akan mengatakan, untuk menjadi pengembang yang benar-benar baik, orang harus memahami apa yang sedang terjadi pada level rendah. Ini membantu dalam memecahkan beberapa masalah sulit, terutama ketika memanggil kode asli.

Saya pikir mengetahui beberapa hal tingkat rendah sangat membantu untuk debugging, seperti misalnya dengan pemrograman Embedded sebagian besar dilakukan dengan C, namun ketika debugging mengetahui perakitan untuk kontroler Mikro tertentu sangat berguna.

Ketika komputer pertama kali ditemukan, hanya sedikit orang yang tahu cara menggunakannya. Sekarang, sebagian besar rumah di negara kaya memiliki 1 atau lebih komputer yang dapat digunakan oleh orang kebanyakan. Banyak orang biasa memiliki pekerjaan di komputer setiap hari. Rata-rata orang memiliki kemampuan untuk menggunakan komputer, tetapi kita masih membutuhkan programmer.

Demikian pula, programmer rata-rata tidak perlu tahu atau secara teratur memprogram dalam bahasa assembly. Ini sama seperti kondisi keterampilan yang dapat dipasarkan serta merupakan penghormatan terhadap sejauh mana kita telah mencapai dunia teknologi. Bisnis membutuhkan komputer untuk mengotomatisasi tugas. Oleh karena itu, programmer yang dapat memprogram dalam. NET / Java sangat diminati.

Tugas-tugas yang dapat diotomatisasi, akan diotomatisasi. Tidak semua tugas dapat diotomatisasi. Tidak semua otomasi sempurna. Jadi, apakah perakitan itu penting? Tentu saja. Apakah itu diperlukan untuk menjadi "programmer". Tentu saja tidak.

Hmmm saya benar-benar menikmati belajar hal-hal tingkat rendah.

Mungkin itu bukan perumpamaan yang paling akurat, tetapi bagi saya itu seperti mempelajari intrik di dalam mobil. Saya mungkin tidak tahu bagaimana semua bagian bekerja satu sama lain, tetapi menyenangkan mengetahui bahwa ada mesin, poros engkol, silinder, diferensial, derek, rem, oli, pembakaran, pendinginan, dan kemudian gesekan, stres, panas, gaya, sains — termodinamika, fisika, mekanika fluida ...

Mungkin tidak terlalu berguna (saya tidak akan bisa memperbaiki mobil dengan mengetahui semua ini), tentu saja tidak praktis secara profesional, tetapi, yah, menyenangkan. L'art pour l'art: la connaissance pour la connaissance.

Saya pikir aturan praktis yang berguna adalah - semakin cepat dibutuhkan, semakin rendah level yang Anda butuhkan.

Jadi penembak orang pertama intensif gambar Anda, atau sistem perdagangan FX algoritmik Anda, mereka masih level yang cukup rendah (C ++, dll) karena kecepatan adalah kuncinya. Tetapi aplikasi web yang mengeluarkan laporan penjualan tepat waktu? Sial, Anda bisa menulis itu di Sinclair BASIC, dan itu masih bisa diterima.

Tidak semua pekerjaan rekayasa perangkat lunak adalah sama . Orang-orang yang bekerja pada sistem operasi, kompiler, kerangka kerja, driver perangkat, sistem tertanam, dan komputasi ilmiah berkinerja sangat baik perlu mengetahui 'barang tingkat rendah'. Orang-orang yang menulis formulir Akses CRUD, atau kereta belanja PHP untuk toko Mom dan Pop, mungkin tidak terlalu banyak. Apa jenis rekayasa perangkat lunak yang ingin Anda lakukan, dan Anda ingin melakukannya seumur hidup Anda?

Pendapat saya adalah bahwa Anda perlu belajar setidaknya satu tingkat abstraksi di bawah yang biasanya Anda gunakan. Jika Anda bekerja di C / C ++ maka Anda harus mengambil beberapa arsitektur dan perakitan mesin. Jika Anda bekerja di PHP maka Anda harus memahami HTTP dan sedikit C / C ++ atau Perl. Jika Access adalah roti dan mentega Anda, Anda sebaiknya tahu beberapa teori RDB, dan mungkin sedikit tentang COM atau .Net. Suatu saat dalam karir Anda, Anda pada akhirnya akan berhenti mati di jalur Anda oleh masalah pada tingkat abstraksi yang lebih rendah, dan Anda harus dapat berkomunikasi setidaknya sedikit dengan seseorang yang ahli di bidang itu. Bisakah Anda 'bertahan' tanpa barang-barang ini? Tentu, tetapi merencanakan untuk hanya bertahan di pasar kerja yang kompetitif itu berbahaya.

Saya sendiri bekerja secara luas dalam C # .NET dan selalu menjauh dari C, C ++. Baru-baru ini mulai mencari pekerjaan dan terkejut melihat berapa banyak pekerjaan tersedia dan membutuhkan pengalaman untuk C, C ++. Saya awalnya berpikir bahwa C, C ++ sudah ketinggalan zaman tetapi melihat pekerjaan yang tersedia, tidak terlihat seperti itu masalahnya.

Semua bahasa yang dikelola yang Anda daftarkan memiliki juru bahasa atau mesin virtual yang ditulis dalam C / C ++. Tanpa kedua bahasa itu, sebagian besar bahasa yang dikelola atau ditafsirkan tidak akan ada. Saya akan mengatakan bahwa Anda meremehkan nilai mereka.

Saya benar-benar benci gagasan "praktis" . Segala sesuatu yang Anda pelajari sama-sama praktis. Tidak masalah jika Anda tidak akan beroperasi pada tingkat abstraksi yang dekat dengan perangkat keras, hanya mengetahui konsep dari domain itu selalu bermanfaat untuk membangun pengetahuan baru di tingkat abstraksi lain. Semakin banyak konsep terkait yang Anda ketahui, semakin baik.

Untuk apa yang biasanya saya lakukan, C # adalah bahasa tingkat sangat rendah, dan saya menganggapnya sebagai sesuatu yang sangat dekat dengan perangkat keras. Tetapi saya masih percaya bahwa bahkan pengetahuan saya yang belum sempurna tentang elektronik digital, desain CPU, dll., Sangat berguna untuk semua yang pernah saya lakukan.

Tidak, mayoritas tidak perlu. Meskipun mempraktikkan teknik tingkat rendah memberikan pengembang pengetahuan yang lebih baik tentang apa yang dapat mempengaruhi siklus secara keseluruhan, saat ini pengembang dapat memanfaatkan waktu itu untuk mempelajari teknologi baru, yang pada gilirannya membutuhkan pengetahuan tentang hal-hal tingkat rendah untuk dikembangkan tetapi tidak dapat diandalkan. di.

Dalam pandangan saya, ketika Anda menggunakan kata "Engineer", maksud Anda pria / wanita adalah orang yang mendesain & membangun hal-hal dari awal. Masalah nyata Seorang Insinyur Perangkat Lunak adalah menyelesaikan masalah, tetapi masalah apa? Itu pertanyaan besar.

Pengembang berbeda dengan Insinyur dalam banyak hal. "Pengembang" adalah orang yang biasanya membangun sesuatu di platform yang sudah ada. Dia mengembangkan platform yang ada atau membangun platform baru yang diturunkan dari yang lebih lama tentu menggunakan komponen sistem induknya.

Pengembang biasanya berpikir dari sudut pandang bisnis, dia bukan Ilmuwan. :) Pengembang lebih dekat dengan pengguna sistem, mereka memikirkan berbagai hal dari sudut pandang pengguna dan akhirnya memecahkan masalah pengguna menggunakan teknologi.

Seorang Insinyur yang cerdas. Dia seorang Ilmuwan, dia menyelesaikan masalah yang sangat asli. Sebagian besar masalah, yang komputer itu sendiri miliki sebagai fitur .. Kami pengguna tidak pernah mendekati masalah itu, itu dienkapsulasi. Insinyur adalah orang yang meninggalkan studinya setelah meneliti banyak tentang sistem yang ada dan menghasilkan sesuatu yang baru untuk menyelesaikan masalah, jika solusi menuntut, jika sistem mereka membutuhkan bahasa baru mereka menciptakan bahasa baru karena sistem yang ada tidak mampu menyelesaikan masalah itu .. Insinyur akhirnya membangun sistem di mana Pengembang membangun sistem mereka.

Memang, seorang Insinyur Perangkat Lunak perlu belajar dan berpengalaman dengan hal-hal tingkat rendah ... :)

Sedangkan Pengembang, itu sepenuhnya tergantung pada minatnya. :)