Bagaimana peningkatan kompleksitas sistem memengaruhi generasi programmer yang berurutan?

Sebagai seorang programmer "baru" (saya pertama kali menulis sebaris kode pada tahun 2009), saya perhatikan relatif mudah untuk membuat program yang memperlihatkan elemen yang cukup kompleks hari ini dengan hal-hal seperti .NET framework misalnya. Membuat antarmuka visual, atau menyortir daftar dapat dilakukan dengan sangat sedikit perintah sekarang.

Ketika saya belajar memprogram, saya juga belajar teori komputasi secara paralel. Hal-hal seperti pengurutan algoritma, prinsip-prinsip bagaimana perangkat keras beroperasi bersama, aljabar boolean, dan mesin negara-terbatas. Tetapi saya perhatikan jika saya ingin menguji beberapa prinsip dasar yang saya pelajari dalam teori, selalu lebih sulit untuk memulai karena begitu banyak teknologi yang dikaburkan oleh hal-hal seperti perpustakaan, kerangka kerja, dan OS.

Membuat program yang efisien-memori diperlukan 40/50 tahun yang lalu karena tidak ada cukup memori dan mahal, sehingga kebanyakan programmer memperhatikan tipe data dan bagaimana instruksi akan ditangani oleh prosesor. Saat ini, beberapa orang mungkin berpendapat bahwa karena peningkatan daya pemrosesan dan memori yang tersedia, masalah tersebut bukanlah prioritas.

Pertanyaan saya adalah apakah programmer yang lebih tua melihat inovasi seperti ini sebagai anugerah atau lapisan tambahan untuk abstrak, dan mengapa mereka berpikir begitu? Dan apakah programmer yang lebih muda mendapat manfaat lebih banyak belajar pemrograman tingkat rendah SEBELUM menjelajahi ranah perpustakaan yang luas? Jika demikian lalu mengapa?

itu tidak perlu karena peningkatan jumlah daya pemrosesan dan memori yang tersedia.

Memiliki memori yang murah, cakram yang sangat besar, dan prosesor cepat bukanlah satu-satunya hal yang membebaskan orang dari kebutuhan untuk terobsesi pada setiap byte dan siklus. Kompiler sekarang jauh, jauh lebih baik daripada manusia dalam menghasilkan kode yang sangat optimal ketika itu penting.

Selain itu, jangan lupa untuk apa sebenarnya kami mencoba mengoptimalkan, yaitu nilai yang dihasilkan untuk biaya tertentu. Pemrogram jauh lebih mahal daripada mesin. Apa pun yang kami lakukan yang membuat pemrogram menghasilkan program yang berfungsi, benar, kuat, berfitur lengkap lebih cepat dan lebih murah mengarah pada penciptaan nilai lebih di dunia.

Namun pertanyaan saya adalah bagaimana perasaan orang tentang "persembunyian" elemen-elemen tingkat rendah ini. Apakah Anda programmer yang lebih tua melihatnya sebagai anugerah atau lapisan yang tidak perlu untuk dilalui?

Sangat penting untuk menyelesaikan pekerjaan. Saya menulis analisa kode untuk mencari nafkah; jika saya harus khawatir tentang alokasi register atau penjadwalan prosesor atau jutaan detail lainnya, maka saya tidak akan menghabiskan waktu untuk memperbaiki bug, meninjau laporan kinerja, menambahkan fitur, dan sebagainya.

Semua pemrograman adalah tentang memisahkan lapisan di bawah Anda untuk membuat lapisan yang lebih berharga di atasnya. Jika Anda melakukan "diagram lapisan kue" yang menunjukkan semua subsistem dan bagaimana mereka dibangun satu sama lain, Anda akan menemukan bahwa ada puluhan lapisan antara perangkat keras dan pengalaman pengguna. Saya pikir dalam diagram lapisan kue Windows ada sesuatu seperti 60 tingkat subsistem yang diperlukan antara perangkat keras mentah dan kemampuan untuk menjalankan "hello world" di C #.

Apakah Anda pikir programmer yang lebih muda akan mendapat manfaat lebih banyak belajar pemrograman tingkat rendah SEBELUM menjelajahi ranah perpustakaan yang luas?

Anda memberi penekanan pada SEBELUM, jadi saya harus menjawab pertanyaan Anda dengan negatif. Saya membantu seorang teman berusia 12 tahun belajar memprogram sekarang dan Anda sebaiknya percaya saya memulainya di Processing.js dan bukan x86 assembler. Jika Anda memulai seorang programmer muda dengan sesuatu seperti Processing.jsmereka akan menulis game tembak-menembak mereka sendiri dalam waktu sekitar delapan jam. Jika Anda memulainya dengan assembler, mereka akan mengalikan tiga angka bersama dalam waktu sekitar delapan jam. Menurut Anda, mana yang lebih menarik minat seorang programmer yang lebih muda?

Sekarang jika pertanyaannya adalah "apakah programmer yang memahami lapisan n dari kue mendapat manfaat dari memahami lapisan n - 1?" jawabannya adalah ya, tapi itu tidak tergantung pada usia atau pengalaman; itu selalu terjadi bahwa Anda dapat meningkatkan pemrograman tingkat yang lebih tinggi dengan lebih memahami abstraksi yang mendasarinya.

Saya punya ide tentang hal ini, dan saya masukkan ke dalam buku 20 tahun yang lalu . Sudah lama tidak dicetak, tetapi Anda masih bisa mendapatkan salinan yang digunakan di Amazon .

Satu jawaban sederhana untuk pertanyaan Anda adalah setua Aristoteles: Alam membenci kekosongan . Sebanyak mesin menjadi lebih cepat dan lebih besar, perangkat lunak menjadi lebih lambat dan lebih besar.

Agar lebih konstruktif, yang saya usulkan adalah teori informasi, dan relevansinya langsung dengan perangkat lunak, menjadi bagian dari pendidikan ilmu komputer. Itu hanya diajarkan sekarang, jika sama sekali, dengan cara yang sangat tangensial.

Misalnya, perilaku algoritma O besar bisa sangat rapi dan intuitif dipahami jika Anda menganggap suatu program sebagai saluran informasi tipe Shannon, dengan simbol input, simbol output, kebisingan, redundansi, dan bandwidth.

Di sisi lain, produktivitas seorang programmer dapat dipahami dalam istilah yang sama menggunakan teori informasi Kolmogorov. Input adalah struktur konseptual simbolik di kepala Anda, dan outputnya adalah teks program yang keluar melalui ujung jari Anda. Proses pemrograman adalah saluran di antara keduanya. Ketika kebisingan memasuki proses, itu menciptakan program yang tidak konsisten (bug). Jika teks program keluaran memiliki redundansi yang cukup, itu dapat memungkinkan bug untuk ditangkap dan diperbaiki (deteksi kesalahan dan koreksi). Namun, jika terlalu berlebihan, itu terlalu besar, dan ukurannya, dikombinasikan dengan tingkat kesalahan, menyebabkan pengenalan bug. Sebagai hasil dari alasan ini, saya menghabiskan sebagian besar buku yang menunjukkan bagaimana memperlakukan pemrograman sebagai proses desain bahasa, dengan tujuan untuk dapat menentukan domain-bahasa-spesifik yang sesuai dengan kebutuhan. Kami membayar layanan bibir untuk domain-bahasa-spesifik dalam pendidikan CS tetapi, sekali lagi, itu tangensial.

Membangun bahasa itu mudah. Setiap kali Anda mendefinisikan suatu fungsi, kelas, atau variabel, Anda menambahkan kosakata ke bahasa yang Anda mulai, menciptakan bahasa baru yang dapat digunakan untuk bekerja. Apa yang umumnya tidak dihargai adalah bahwa tujuannya adalah untuk membuat bahasa baru lebih cocok dengan struktur konseptual masalah. Jika ini dilakukan, maka itu memiliki efek memperpendek kode dan membuatnya kurang buggy hanya karena, idealnya, ada pemetaan 1-1 antara konsep dan kode. Jika pemetaannya 1-1, Anda mungkin membuat kesalahan dan salah mengartikan konsep sebagai konsep yang berbeda, tetapi program tidak akan pernah mogok, yang terjadi bila dikodekan tanpa persyaratan yang konsisten .

Kami tidak mendapatkan ini. Untuk semua pembicaraan berani kami tentang desain sistem perangkat lunak, rasio kode terhadap persyaratan semakin besar, jauh lebih besar.

Memang benar, kami memiliki perpustakaan yang sangat berguna. Namun, saya pikir kita harus sangat berhati-hati tentang abstraksi. Kita tidak boleh berasumsi jika B dibangun di atas A dan itu bagus, bahwa jika C dibangun di atas B itu bahkan lebih baik. Saya menyebutnya fenomena "putri dan kacang". Menumpuk lapisan di atas sesuatu yang merepotkan belum tentu memperbaikinya.

Untuk mengakhiri posting yang panjang, saya telah mengembangkan gaya pemrograman (yang terkadang membuat saya dalam kesulitan) di mana

• Penemuan bukanlah hal yang buruk. Itu adalah hal yang baik, seperti di cabang teknik lainnya. Tentu itu mungkin menciptakan kurva belajar untuk orang lain, tetapi jika hasil keseluruhan adalah produktivitas yang lebih baik, itu bermanfaat.
• Kode minimalis bergaya Haiku. Itu terutama berlaku untuk desain struktur data. Dalam pengalaman saya, masalah terbesar dalam perangkat lunak saat ini adalah struktur data yang membengkak.

Abstraksi tingkat tinggi sangat penting untuk mencapai kemajuan yang berkelanjutan dalam komputasi.

Mengapa? Karena manusia hanya dapat menyimpan begitu banyak pengetahuan di kepala mereka pada saat tertentu. Modern, sistem skala besar hanya mungkin hari ini karena Anda dapat memanfaatkan abstraksi semacam itu. Tanpa abstraksi itu, sistem perangkat lunak akan runtuh hanya karena beratnya sendiri.

Setiap kali Anda menulis metode, Anda membuat abstraksi. Anda sedang membuat sedikit fungsionalitas yang tersembunyi di balik pemanggilan metode. Mengapa Anda menulisnya? Karena Anda dapat menguji metode, membuktikannya berfungsi, dan kemudian memanggil fungsi itu kapan pun Anda inginkan hanya dengan membuat panggilan metode, dan Anda tidak perlu memikirkan lagi tentang kode yang ada di dalam metode itu.

Pada hari-hari awal komputasi, kami menggunakan bahasa mesin. Kami menulis program logam kecil yang sangat kecil dengan pengetahuan mendalam tentang perangkat keras yang kami gunakan. Itu adalah proses yang melelahkan. Tidak ada pengadu; program Anda biasanya berhasil, atau macet. Tidak ada GUI; semuanya adalah perintah-baris atau proses batch. Kode yang Anda tulis hanya akan berfungsi pada mesin tertentu; itu tidak akan bekerja pada mesin dengan prosesor atau sistem operasi yang berbeda.

Jadi kami menulis bahasa tingkat tinggi untuk abstrak semua detail itu. Kami menciptakan mesin virtual sehingga program kami dapat dibawa-bawa ke komputer lain. Kami membuat pengumpulan sampah sehingga pemrogram tidak harus begitu rajin mengelola memori, yang menghilangkan seluruh kelas bug yang sulit. Kami menambahkan batas memeriksa ke bahasa kami sehingga peretas tidak bisa mengeksploitasi mereka dengan buffer overruns. Kami menemukan Pemrograman Fungsional sehingga kami dapat beralasan tentang program kami dengan cara yang berbeda, dan menemukan kembali baru-baru ini untuk mengambil keuntungan lebih baik dari konkurensi.

Apakah semua abstraksi ini melindungi Anda dari perangkat keras? Tentu saja. Apakah tinggal di rumah bukannya mendirikan tenda melindungi Anda dari alam? Benar. Tetapi semua orang tahu mengapa mereka tinggal di rumah daripada di tenda, dan membangun rumah adalah permainan bola yang sama sekali berbeda dengan mendirikan tenda.

Namun, Anda masih dapat mendirikan tenda ketika perlu untuk melakukan itu, dan dalam pemrograman, Anda dapat (jika Anda cenderung) masih turun ke tingkat yang lebih dekat ke perangkat keras untuk mendapatkan kinerja atau manfaat memori yang mungkin tidak Anda miliki. jika tidak, capai dalam bahasa tingkat tinggi Anda.

Bisakah Anda abstrak terlalu banyak? "Ambil alih pipa ledeng," seperti yang dikatakan Scotty ? Tentu saja Anda bisa. Menulis API yang bagus itu sulit. Menulis API yang baik yang dengan benar dan komprehensif mewujudkan domain masalah, dengan cara yang intuitif dan dapat ditemukan, bahkan lebih sulit. Menumpuk pada lapisan perangkat lunak baru tidak selalu merupakan solusi terbaik. Pola Desain Perangkat Lunak , sampai taraf tertentu, membuat situasi ini lebih buruk, karena pengembang yang tidak berpengalaman terkadang meraihnya ketika alat yang lebih tajam dan lebih ramping lebih sesuai.

Pelatihan yang benar-benar baik melibatkan kedua hal yang ekstrem, serta jembatan di antara keduanya.

Di sisi tingkat rendah: bagaimana komputer menjalankan kode dari bawah ke atas *, termasuk pengetahuan tentang bahasa rakitan dan apa yang dilakukan oleh kompiler.

Di sisi tingkat tinggi: konsep umum, misalnya menggunakan array asosiatif, penutupan, dll. Tanpa harus membuang waktu mengkhawatirkan cara kerjanya di bawah tenda.

IMHO setiap orang harus memiliki pengalaman dengan keduanya, termasuk kelemahan mereka, dan rasa bagaimana untuk mendapatkan dari konsep tingkat rendah ke konsep tingkat tinggi. Suka array asosiatif? Hebat, sekarang cobalah menggunakannya pada prosesor tertanam 50 sen dengan RAM 1kB. Suka menulis kode cepat menggunakan C? Hebat, sekarang Anda punya waktu tiga minggu untuk menulis aplikasi web; Anda dapat menghabiskan waktu Anda berurusan dengan struktur data dan manajemen memori menggunakan C, atau Anda dapat menghabiskan waktu Anda mempelajari kerangka kerja web baru dan kemudian mengimplementasikan aplikasi web dalam beberapa hari.

Sejauh aspek kerumitannya: Saya pikir saat ini terlalu mudah untuk membuat sistem yang rumit tanpa pemahaman yang jelas tentang biaya melakukannya . Sebagai hasilnya, kami, sebagai masyarakat, membangun hutang teknis dalam jumlah besar yang menggigit kami dari waktu ke waktu. Ini seperti gempa bumi (hanya biaya hidup di dekat kesalahan geologis, bukan?), Hanya saja secara bertahap semakin buruk. Dan saya tidak tahu harus bagaimana. Idealnya kita akan belajar dan menjadi lebih baik dalam mengelola kompleksitas, tetapi saya tidak berpikir itu akan terjadi. Pendidikan teknik yang bertanggung jawab perlu memasukkan lebih banyak diskusi tentang konsekuensi kompleksitas daripada yang sebagian besar universitas kami saat ini sediakan.

* dan, bagaimanapun, di mana "tanah" dalam cara komputer mengeksekusi kode? Apakah bahasa assembly? Atau arsitektur komputer? Atau logika digital? Atau transistor? Atau fisika perangkat?

Saya merasa bahwa pemrograman tingkat tinggi memiliki banyak keuntungan dan merupakan bagian penting dari bahasa pemrograman. Salah satu alasan mengapa Jawa menjadi sukses adalah karena ia memiliki perpustakaan yang komprehensif. Anda mencapai lebih banyak dengan lebih sedikit kode - panggil saja fungsi yang telah ditentukan.

Kita sekarang dapat membedakan pengguna bahasa pemrograman dari penulis bahasa pemrograman (penulis kompiler). Kami menyerahkan optimisasi kepada penulis kompiler. Kami lebih fokus pada pemeliharaan, penggunaan kembali, dll

Peningkatan kompleksitas sistem tanpa henti, menindas dan akhirnya melumpuhkan. Bagi saya sebagai programmer generasi yang lebih tua, itu juga mengecewakan.

Saya telah memprogram selama lebih dari 40 tahun, memiliki kode tertulis dalam 50-100 bahasa atau dialek yang berbeda, dan menjadi ahli dalam 5-10. Alasan saya bisa mengklaim begitu banyak adalah karena sebagian besar mereka hanya bahasa yang sama, dengan tweak. Tweak menambah kompleksitas, membuat setiap bahasa sedikit berbeda.

Saya telah menerapkan algoritma yang sama berkali-kali: koleksi, konversi, pengurutan dan pencarian, penyandian / dekode, format / parse, buffer dan string, aritmatika, memori, I / O. Setiap implementasi baru menambah kompleksitas, karena masing-masing hanya sedikit berbeda.

Saya bertanya-tanya pada keajaiban yang ditimbulkan oleh seniman trapeze terbang tinggi dari kerangka kerja web dan aplikasi seluler, pada bagaimana mereka dapat menghasilkan sesuatu yang begitu indah dalam waktu yang singkat. Kemudian saya menyadari betapa mereka tidak tahu, berapa banyak yang mereka butuhkan untuk belajar tentang data atau komunikasi atau pengujian atau utas atau apa pun sebelum apa yang mereka lakukan menjadi berguna.

Saya belajar keterampilan saya di era bahasa generasi keempat, di mana kami benar-benar percaya bahwa kami akan menghasilkan suksesi bahasa tingkat yang lebih tinggi dan lebih tinggi untuk secara progresif menangkap semakin banyak bagian berulang dari perangkat lunak penulisan. Jadi bagaimana hasilnya, tepatnya?

Microsoft dan IBM membunuh ide itu dengan kembali ke C untuk menulis aplikasi untuk Windows dan OS / 2, sementara dBase / Foxpro dan bahkan Delphi merana. Kemudian web melakukannya lagi dengan trio utamanya bahasa assembly: HTML, CSS dan JavaScript / DOM. Semua sudah menurun dari sana. Selalu lebih banyak bahasa dan lebih banyak perpustakaan dan lebih banyak kerangka kerja dan lebih banyak kompleksitas.

Kami tahu kami harus melakukannya secara berbeda. Kita tahu tentang CoffeeScript dan Dart, tentang Less dan Sass, tentang template untuk menghindari keharusan menulis HTML. Kami tahu dan kami tetap melakukannya. Kami memiliki kerangka kerja kami, penuh dengan abstraksi yang bocor, dan kami melihat keajaiban apa yang dapat dilakukan oleh beberapa orang terpilih yang mempelajari mantra misterius, tetapi kami dan program kami terjebak oleh keputusan yang dibuat di masa lalu. Terlalu rumit untuk berubah atau memulai lagi.

Hasilnya adalah hal-hal yang seharusnya mudah tidaklah mudah, dan hal-hal yang seharusnya mungkin hampir mustahil, karena kerumitan. Saya dapat memperkirakan biaya untuk membuat perubahan untuk mengimplementasikan fitur baru dalam basis kode yang sudah ada dan yakin saya akan tepat. Saya bisa memperkirakan, tetapi saya tidak bisa membenarkan atau menjelaskannya. Itu terlalu rumit.

Dalam menjawab pertanyaan terakhir Anda, saya akan sangat menyarankan programmer muda untuk memulai setinggi mungkin pada lapisan kue, dan hanya menyelam ke lapisan bawah karena kebutuhan dan keinginan memberikan dorongan. Preferensi saya adalah bahasa tanpa loop, sedikit atau tanpa percabangan dan kondisi eksplisit. Lisp dan Haskell datang ke pikiran. Dalam praktiknya saya selalu selesai dengan C # / Java, Ruby, Javascript, Python dan SQL karena di situlah komunitas berada.

Kata-kata terakhir: kompleksitas adalah musuh utama! Kalahkan itu dan hidup menjadi sederhana.

Namun pertanyaan saya adalah bagaimana perasaan orang tentang "persembunyian" elemen-elemen tingkat rendah ini. Apakah Anda programmer yang lebih tua melihatnya sebagai anugerah atau lapisan yang tidak perlu untuk dilalui?

Tidak juga.

Layering diperlukan karena tanpa itu, Anda mencapai titik di mana sistem Anda menjadi spageti yang tidak dapat dipelihara. Ini juga salah satu prinsip penggunaan kembali: jika pengembang perpustakaan melakukan pekerjaan dengan baik, orang-orang yang menggunakannya tidak harus peduli dengan detail implementasi. Jumlah kode kalengan yang kami gunakan dalam sistem kami telah tumbuh atas perintah mangitude dari apa ketika saya menulis program pertama saya 35 tahun lalu. Pertumbuhan itu berarti kita dapat melakukan hal-hal yang lebih kuat seiring berjalannya waktu. Ini bagus.

Tempat di mana itu menjadi masalah bagi saya sepenuhnya budaya. Setengah pragmatis saya mengerti bahwa tidak mungkin lagi membungkus pikiran saya dengan setiap detail terakhir dan dapat menyelesaikan hal-hal yang ingin saya selesaikan. (Semakin tua juga tidak membantu.) Setengah uban saya yang tidak tahan banting memiliki waktu yang sulit melepaskan bertahun-tahun untuk memiliki pemahaman yang begitu baik tentang semua yang saya kerjakan.

Apakah Anda pikir programmer yang lebih muda akan mendapat manfaat lebih banyak belajar pemrograman tingkat rendah SEBELUM menjelajahi ranah perpustakaan yang luas?

Seperti yang telah ditunjukkan dalam jawaban lain, ada keseimbangan yang harus dicapai antara menarik dan mempertahankan perhatian orang baru dan memberi mereka pendidikan yang ideal, dari bawah ke atas. Jika Anda tidak bisa melakukan yang pertama, yang terakhir tidak bisa terjadi.

Saya melihat hal-hal di industri kami yang paralel dengan masyarakat. Dulu hampir semua orang menanam makanan mereka sendiri dan menghabiskan banyak waktu untuk melakukan itu. Sejak itu, kami telah menumbuhkan spesialis yang disebut petani yang melakukan pekerjaan itu, membebaskan orang lain untuk melakukan hal-hal lain yang berkontribusi bagi masyarakat. Saya membeli makanan di toko grosir dan benar-benar tidak dapat menghasilkan sebagian besar dari saya sendiri jika saya harus. Kami memiliki hal serupa yang terjadi, meskipun pada skala waktu yang jauh lebih padat. Pemrogram mengkhususkan diri dalam beberapa set lapisan dan bukan yang lain. Orang rata-rata menulis GUI mungkin tahu bahwa ada yang namanya ruang swap tetapi mungkin tidak tahu atau peduli tentang bagaimana sistem operasi mengelolanya.

Hasil dari semua ini adalah bahwa ini tidak lagi hanya tentang pengembangan. Spesialisasi yang berkelanjutan berarti pengembang perlu terus meningkatkan keterampilan komunikasi dan integrasi mereka.

Seperti halnya segalanya, sedikit hal baik bagi Anda, tetapi terlalu menyakitkan. Masalahnya adalah terlalu banyak sistem yang tidak tahu kapan harus berhenti - hanya 1 abstraksi lagi, untuk membantu Anda memprogram lebih cepat ... tetapi kemudian Anda berakhir dengan pengkodean di dunia nyata di mana segala sesuatunya tidak pernah sesederhana yang Anda inginkan, dan Anda menghabiskan lebih banyak waktu bekerja di sekitar tepi daripada yang akan Anda habiskan dengan abstraksi fitur kurang.

Dengan cakap dijelaskan di sini

atau di sini - "dengan satu baris kode Anda dapat menambahkan 500 pengguna ke domain" ...

Abstraksi Anda mencoba menyembunyikan kerumitan dari Anda, tetapi sebenarnya yang mereka lakukan hanyalah menyembunyikan kerumitan itu. Kompleksitasnya masih ada, hanya saja Anda memiliki kendali yang jauh lebih sedikit terhadapnya - dan itulah sebabnya Anda berakhir dengan situasi seperti ini.

Apakah programmer muda mendapat manfaat lebih banyak belajar pemrograman tingkat rendah SEBELUM menjelajahi ranah perpustakaan yang luas? Jika demikian lalu mengapa?

Saya kira tidak. Masih ada banyak situasi di mana itu bermanfaat untuk menyadari rendahnya 'lapisan bawah' karya, misalnya

• Ketika men-debug masalah pada lapisan n, seringkali dapat dijelaskan dengan mempertimbangkan apa yang terjadi pada lapisan n-1(yaitu lapisan di bawah). Saya kira layer 0 akan menjadi "transistor" tetapi jika Anda ingin menjelaskan masalah dengan transistor Anda mungkin akan berbicara tentang fisika (misalnya panas), jadi mungkin fisika benar-benar level 0.

• Ketika mengoptimalkan kode itu (sayangnya) kadang-kadang membantu menurunkan tingkat abstraksi, yaitu menerapkan algoritma dalam hal lapisan tingkat yang lebih rendah. Namun, kompiler menjadi sangat pandai melakukan ini untuk Anda jika mereka benar-benar melihat semua kode yang terlibat. Alasan ini menjadi lebih populer baru-baru ini dengan ledakan perangkat seluler dan tertanam, yang cenderung memiliki prosesor yang lebih lemah dan di mana "kinerja per Watt" jauh lebih relevan daripada pada, katakanlah, sistem desktop.

Namun secara umum, menjadi jauh lebih mudah untuk membuat komputer melakukan hal-hal (bahkan jika dengan cara yang sedikit tidak efisien) yang berarti bahwa ada jauh lebih banyak programmer daripada dulu. Ini pada gilirannya membuat faktor "manusia" jauh lebih penting: jawaban Robert Harvey telah menyebutkan bahwa "manusia hanya dapat memiliki begitu banyak pengetahuan di kepala mereka pada saat tertentu", dan saya pikir itu adalah aspek yang sangat relevan saat ini.

Motivasi utama dalam desain bahasa pemrograman dan perpustakaan (yaitu API) adalah untuk membuat segalanya lebih mudah di otak manusia. Sampai hari ini, semuanya masih dikompilasi ke kode mesin. Namun, ini tidak hanya rawan kesalahan, juga sangat sulit dipahami. Jadi itu sangat diinginkan

• Minta komputer membantu Anda menemukan kesalahan logis dalam program yang Anda tulis. Hal-hal seperti sistem tipe statis atau penganalisa kode sumber (saya mendengar Eric Lippert bekerja pada yang cukup populer hari ini) membantu dengan itu.

• Memiliki bahasa yang dapat diproses secara efisien oleh kompiler dan yang mengkomunikasikan maksud programmer ke programmer lain untuk membuat bekerja pada program lebih mudah. Sebagai ekstrem yang absurd, bayangkan program menulis dalam bahasa Inggris yang sederhana adalah mungkin. Rekan-rekan programmer mungkin memiliki waktu yang lebih mudah untuk membayangkan apa yang terjadi tetapi tetap saja, deskripsi akan sangat sulit untuk dikompilasi menjadi instruktur mesin, dan ini terkenal ambigu. Jadi Anda memerlukan bahasa yang bisa dipahami oleh kompiler tetapi juga bisa dipahami.

Mengingat bahwa banyak (kebanyakan?) Kompiler masih sangat umum, mereka memiliki set instruksi yang sangat umum. Tidak ada instruksi "menggambar tombol" atau "mainkan film ini". Oleh karena itu, menurunkan hierarki abstraksi membuat Anda berakhir dengan program yang sangat sulit untuk dipahami dan dipelihara (meskipun sepele untuk dikompilasi). Satu-satunya alternatif adalah naik hierarki, yang mengarah ke semakin banyak bahasa dan perpustakaan abstrak.

"Jika pemrogram yang lebih tua melihat inovasi seperti ini sebagai anugerah atau lapisan tambahan untuk abstrak, dan mengapa mereka berpikir begitu?"

Saya sudah pemrograman sejak masih di sekolah menengah, sekitar 34 tahun, dimulai dengan Basic dan Z80 Assembler, pindah ke C, berbagai bahasa 4GL, Skema, SQL, dan sekarang berbagai bahasa Web. Ruang lingkup, skala, dan kedalaman masalah yang ditangani oleh profesi mengalami periode inflasi selama waktu itu, terutama di tahun 1990-an. Konstruksi seperti perpustakaan, kerangka kerja, dan layanan OS adalah semua alat dimaksudkan untuk mengatasi kompleksitas yang terjadi seiring dengan ruang masalah yang diperluas. Mereka bukan anugerah atau beban di dalam dan dari diri mereka sendiri - hanya sebuah eksplorasi berkelanjutan dari ruang solusi yang luas.

Tapi, IMHO, "inovasi" lebih baik dipahami dari segi bentuk novel, dan tidak disalahartikan sebagai gerakan menyamping - memperkenalkan kembali bentuk yang sudah kita lihat diperkenalkan. Dalam beberapa hal, kesuburan ekosistem menderita ketika bentuk-bentuk primitif tidak terbentuk, ketika mereka menetapkan keputusan yang dibuat pada awal evolusi, atau tidak dapat memproses kembali detritus mereka sendiri. Beberapa, jika tidak sebagian besar, dari konstruksi yang kami fokuskan tetap tidak memprioritaskan ketahanan nilai jangka panjang sebagai masalah. Itu sudah mulai berubah - pendekatan seperti Service Orientation dan Domain Driven Design, belum lagi model berbasis hypertext dan grafik, misalnya mengubah lanskap. Seperti ekosistem lainnya, pada akhirnya bentuk dominan akan memberi jalan pada bentuk baru; kami paling baik dilayani dengan memungkinkan keragaman,

"Dan apakah programmer yang lebih muda mendapat manfaat lebih banyak belajar pemrograman tingkat rendah SEBELUM menjelajahi ranah perpustakaan yang luas? Jika demikian, mengapa?"

Saya berpendapat bahwa sebagian besar bahasa manusia didasarkan pada metafora yang sudah lama dilupakan, jadi sementara saya mendukung pembelajaran tingkat rendah dari sudut pandang ilmiah / numerik, lebih penting bagi kita mencari primitif yang akan mendukung skala dan ruang lingkup masalah yang sedang kita atasi dengan cara yang bisa kita abaikan dengan tingkat detail yang lebih rendah. Kerangka kerja bukanlah primitif, juga bukan OS atau perpustakaan - mereka cukup miskin dalam melakukan jenis abstraksi yang benar-benar kita butuhkan. Kemajuan nyata akan membawa orang yang (a) tahu apa yang terjadi sebelumnya dan (b) dapat berpikir dengan cara yang cukup novel untuk menghasilkan sesuatu yang cukup berbeda untuk mengeksplorasi ruang solusi yang belum dieksplorasi sebelumnya atau dieksplorasi dan dilupakan.

OTOH, bahkan jika tujuan Anda adalah bekerja sebagai teknisi / tingkat mekanik, beberapa tingkat paparan pemrograman tingkat rendah masih akan membantu untuk mengembangkan keterampilan pemecahan masalah Anda.

Program pertama saya (sebagai remaja berusia 15 tahun) adalah pada tahun 1974 di PL / 1 menggunakan kartu berlubang untuk mainframe IBM 370/168. Ayah saya bekerja di IBM dan saya cukup beruntung bisa pergi ke pusat data pada hari Minggu.

Pada waktu itu, program yang terdiri dari ribuan pernyataan (kartu iepunched) adalah program besar (dan berat juga, karena ribuan kartu yang dilubangi berbobot banyak kilogram). Antarmuka visual tidak ada (program khas membaca dari "input standar" menggunakan perintah kartu menekan dimulai dengan //GO.SYSIN DD *IIRC, tapi saya tidak menguasai JCL ). Algoritma itu penting, dan IIRC perpustakaan standar cukup kecil dari standar saat ini.

Saat ini, program beberapa ribu baris umumnya dianggap kecil. Sebagai contoh, kompiler GCC memiliki lebih dari sepuluh juta baris kode sumber, dan tidak ada yang memahaminya sepenuhnya.

Perasaan saya adalah pemrograman hari ini sangat berbeda dari tahun 1970-an, karena Anda perlu menggunakan lebih banyak sumber daya (khususnya, perpustakaan yang ada dan kerangka kerja perangkat lunak). Namun, saya kira orang-orang mengembangkan perangkat lunak pusat data (misalnya mesin pencari di Google) atau perangkat lunak tertanam lebih peduli tentang algoritma dan efisiensi daripada programmer rata-rata tahun 1970-an.

Saya masih berpikir bahwa memahami pemrograman tingkat rendah adalah penting bahkan hari ini (bahkan jika kebanyakan programmer tidak akan mengkodekan diri mereka sendiri algoritma wadah dasar seperti pohon seimbang, array yang dichotomically diakses, dll ...) karena memahami seluruh gambar masih penting.

Perbedaan utama antara tahun 1970-an dan hari ini adalah rasio biaya antara upaya pengembang (manusia) dan daya komputer.