Peran apa yang dimainkan “sejarah budaya bahasa” dengan platform?


15

Saya baru-baru ini sengaja menemukan iniartikel dari beberapa tahun yang lalu. Ini berpendapat bahwa perbedaan signifikan dalam budaya yang mengelilingi VB dan C #, bukan perbedaan yang sebenarnya dalam bahasa, berkontribusi untuk coders C # yang umumnya lebih berbakat daripada coders VB. Jelas, yang menyebabkan banyak perang api dan pertanyaan apakah C # ers atau VBers adalah dumber tidak akan pernah dijawab. Karena itu, para penulis mengklaim bahwa budaya yang mengelilingi platform tertentu berkontribusi pada kualitas tim masih masuk akal. Misalnya, meskipun Java lebih efisien untuk mengembangkan aplikasi dengan saat ini, tim pengembang Google Go tampaknya akan memiliki kaliber yang lebih tinggi daripada tim pengembang Java, karena untuk belajar Go, pengembang mungkin memiliki menjadi pengadopsi super awal dan jagoan peretasan perbatasan. Singkatnya,bagaimana budaya yang melingkupi satu platform atau yang lain mempengaruhi kualitas pengembang rata-rata pada platform itu, jika sama sekali?


Apakah ini hari C # vs. VB.NET?

@ DeveloperArt- Itu bukan maksud saya. Sebenarnya, pertanyaan yang saya ajukan menarik karena fakta bahwa artikel tersebut tampaknya sangat ketinggalan zaman hari ini, tetapi konsepnya mungkin dapat diselamatkan. Artikel itu membuatnya tampak seperti C # devs semua jenius. Saya adalah satu, jadi saya tahu secara langsung bahwa kita semua bisa menjadi sama ceroboh ketika suasana hati melanda.
Morgan Herlocker

1
@Developer Art: Saya membaca artikel itu kemarin, dan saya cukup yakin itu adalah tautan yang diposting dalam jawaban di sini yang membawa saya ke sana. Mungkin begitulah Prof Plum memukulnya - satu pertanyaan C # vs. VB.NET mengarah ke pertanyaan lain. :-)
Carson63000

Jawaban:


8

Benar-benar pertanyaan menarik. Pendapat pribadi saya adalah bahwa itu adalah pertanyaan yang terlalu sering ditanyakan dan benar-benar tidak mengandung air sama sekali.

Script kiddies (dan perusahaan yang mempekerjakan mereka) membiarkan bahasa pilihan menentukan status mereka di antara eselon "programmer". Insinyur yang baik tidak bisa tidak peduli tentang bahasa pilihan, tetapi berkonsentrasi pada pemecahan masalah yang diberikan dengan cara yang paling optimal (jelas optimal adalah pernyataan umum dan dapat diterapkan pada banyak faktor yang berbeda). Apakah ini adalah C #, VB, C ++, Python atau perakitan tulisan tangan, tidak masalah karena ada manfaat yang jelas untuk menggunakan teknologi itu untuk menyelesaikan masalah.

Jadi singkatnya, saya pikir itu lebih berharga untuk melihat kompleksitas masalah yang diselesaikan secara teratur sebagai lawan dari bahasa apa yang mereka gunakan untuk menyelesaikannya.

Hanya dua sen saya pada subjek :)


2
+1: Lebih jauh, gagasan bahwa ada budaya VB yang entah bagaimana melampaui batas perusahaan itu menggelikan. Bagaimana budaya ini melestarikan dirinya sendiri? Pertemuan rahasia di antara programmer VB di luar pekerjaan? "Serikat" atau "serikat" pemrogram VB untuk menegakkan "budaya" ini? Setelah menghabiskan 30 tahun memantul di antara 100-an toko TI saya dapat mengatakan bahwa satu-satunya budaya yang pernah saya lihat adalah murni terlokalisasi. Pilihan bahasa tidak menciptakan budaya "lain" yang dirujuk dalam pertanyaan.
S.Lott

1
Menarik. Jika Anda memberi ini +1, tanyakan siapa yang memilih dan mengapa: P
Demian Brecht

1
@ S.Lott: Saya kemudian dikoreksi (harus menyukai produk sampingan dari asumsi;)). Lebih sering daripada tidak, saya telah menerima downvotes pada topik-topik seperti ini tanpa benar-benar mendapatkan umpan balik, yang kadang-kadang bisa berharga dan memberi saya informasi yang sebelumnya tidak saya sadari :)
Demian Brecht

1
@prof: Apakah otomatisasi benar - benar membuat yang lebih rendah, atau apakah Anda berpikir lebih unggul karena mereka mengerti cara pintas apa yang dapat mereka ambil untuk mencapai hasil yang sama, tetapi lebih efisien? :) Tentu saja, ini generalisasi berlebihan dan hampir tidak mungkin dijawab secara akurat. Saya agak di pagar tentang Go coders menjadi lebih bersemangat. Anda masih dapat menemukan orang-orang yang sama bersemangatnya dengan Fortran. Ini akan , bagaimanapun, menyebabkan saya untuk percaya bahwa programmer Go lebih bergairah tentang baru teknologi dan praktek, yang merupakan hal yang baik imho :)
Demian Brecht

1
@Prof Plum: "pilihan platform / bahasa tidak ada hubungannya dengan kualitas rata-rata pengembang". Benar. Bagaimana bisa sebaliknya? Lebih dari segalanya, budaya organisasi itu penting. Google Go coders - sendiri - hanyalah orang-orang. The organisasi membatasi orang untuk VB atau mendorong mereka untuk menggunakan Go. Semua orang adalah manusia.
S.Lott

4

Kualitas kode yang dikembangkan di masing-masing bahasa ini didasarkan pada filosofi dasar ini dan kurang pada masing-masing pengembang

Setiap bahasa memang memiliki budaya di sekitarnya, karena setiap bahasa dikembangkan untuk alasan oleh seseorang dengan agenda dan filosofi yang mendasari mengapa bahasa mereka akan menjadi lebih baik pada sesuatu daripada apa yang ada pada saat itu dibuat.

Seperti halnya agama, bahasa pemrograman cenderung menarik orang-orang yang sudah memiliki kecenderungan yang sama dengan kepala sekolah dan filosofi inti dari pembuat bahasa.

Contoh tentang Persepsi Kualitas Solusi

Di satu kamp Microsoft Anda memiliki:

Filosofi C # adalah bahwa itu lebih murni Berorientasi Objek, mempromosikan lebih banyak idiom modern dan membutuhkan lebih banyak pengetahuan untuk melakukannya dengan benar dan karenanya harus memberikan solusi kualitas yang lebih tinggi. Inilah yang menarik orang ke sana melalui VB.

Di kamp Microsoft lainnya:

Filosofi VB adalah saya dapat dengan cepat dan dengan sedikit pengetahuan atau upaya membangun sesuatu yang akan membuat seseorang mengklik tombol dan melakukan sesuatu yang bermanfaat dan bernilai bisnis, bagaimana melakukannya tidak begitu penting. Inilah yang menarik orang untuk itu lebih dari C #.

Inilah beberapa bahasa dan filosofi mereka:

Orang Perl cenderung peduli dengan hal sebaliknya yang orang Python pedulikan.

Orang Jawa peduli tentang menghasilkan uang.

Bahasa JVM (Groovy, Scala) peduli tentang JMV dan bukan tentang bahasa Jawa.

Semua bahasa khusus Microsoft (VB, C #, F #, dikelola C ++) cenderung peduli menghasilkan uang di Windows.

Orang-orang Erlang peduli dengan hal-hal yang tidak perlu diperhatikan orang lain, dan tidak menghargai apa yang tidak mereka ketahui.

Orang bodoh tidak peduli dengan apa yang orang lain pikirkan tentang mereka pedulikan.

Apa yang dipedulikan kelompok-kelompok ini membentuk bahasa, perkembangannya, dan komunitasnya.

Filsafat berubah dengan pengalaman dan kebutuhan

Saya mengadopsi ASM dan BASIC karena pada tahun 1983 hanya itu yang Anda miliki. Saya ingin menulis game dan demo, itu adalah alat untuk melakukannya. Sebagian besar ASM untuk demo.

Saya mengadopsi C dan kemudian C ++ kembali ketika itu adalah satu-satunya cara untuk menulis hal-hal seperti rendering 3D dan cukup banyak hal lain yang merupakan ruang dan waktu kritis. Itu bukan ASM jadi saya mempelajarinya.

Saya mengadopsi VB untuk menghasilkan uang, itu adalah hal yang paling dekat dengan lingkungan pengembangan Scala, Direktur, dan Cando yang biasa saya gunakan di Amiga. Saya setuju dengan filosofi pengembangan yang cepat

Saya mengadopsi Jawa sejak awal untuk menghasilkan uang yang lebih baik. Saya menghasilkan uang dengan VB sampai 1999 dan meninggalkannya ketika Java 1.2 menjadi stabil dan matang dan web telah sepenuhnya ditendang pada saat itu, saya memiliki pengalaman 4 tahun di Jawa ketika orang-orang mulai menganggapnya serius. Saya setuju dengan penulisan itu sekali, jalankan di mana saja di mana semakin banyak kode saya berjalan semakin mudah untuk menjualnya. filsafat.

Saya mengadopsi Python di akhir timeline, 2005 karena ia menggaruk gatal yang tidak dimiliki Java. Saya perlu cepat menulis kode untuk menggunakan beberapa perpustakaan yang hanya tersedia di C dan juga saya perlu melakukan prototipe layanan web yang cepat Python lebih cepat dan lebih sedikit kode untuk melakukan hal yang sama di Jawa. Sesuatu pergi ke produksi karena Jawa beberapa tetap Python, banyak hal tidak pernah berhasil masuk ke alam liar.Saya setuju dengan baterainya termasuk, filosofi idiom tunggal dan yang lainnya.

Saya mengadopsi Lua ketika saya perlu menempatkan mesin scripting ringan di program C ++ dan Java saya. Ini jauh sebelum dukungan JSR233 di Jawa. Saya setuju dengan menanamkan bahasa scripting berfitur lengkap yang mudah digunakan harus filosofi Lua sederhana.

Saya mengadopsi Erlang pada tahun 2006 ketika saya mulai membutuhkan skalabilitas besar dan eksekusi multi-core yang relatif tidak menyakitkan pada masalah yang sangat paralel dan memiliki eksekusi lintas platform. ** Saya setuju dengan negara yang tidak dibagikan, lewat pesan, filosofi negara yang tidak berubah. * 8

Saya mengadopsi Objective-C ketika saya mulai perlu membangun aplikasi OSX dan iOS. Saya setuju dengan tambahannya tentang Orientasi Objek ke C untuk menjadikannya filosofi yang lebih baik . Juga untuk menghasilkan uang yang lebih baik.

Saya mengadopsi JavaScript secara resmi pada tahun 2009 karena saya setuju dengan filosofi CouchDB dan menggunakan JavaScript. Masih tidak suka JavaScript ketika saya harus berurusan dengan DOM.

Saya masih belum secara resmi mengadopsi Lisp, tetapi pada akhirnya saya akan melakukannya! Saya setuju dengan mereka. Mereka yang tidak tahu lisp dikutuk untuk menemukan kembali filsafatnya.


0

Memang pertanyaan yang menarik. Ini adalah salah satu di mana Anda memahami jawabannya di tingkat bawah sadar tetapi berusaha untuk memasukkannya ke dalam kata-kata.

Paling baik dilihat sebagai lingkaran sebab akibat.

Budaya bertanggung jawab atas komposisi "etnis" dari pengembang yang tertarik pada platform. Komposisi itu pada gilirannya menentukan kualitas programmer "rata-rata". Kualitas pengembang yang menggunakan platform saat ini memengaruhi budaya atau persepsinya di luar yang berakibat pada pengembang yang datang ke platform atau meninggalkannya. Nilai "kualitas" berubah sebagai hasilnya.

Saya sudah mencoba untuk membuat aturan khusus tetapi saya merasa sulit untuk menggeneralisasi. Kita perlu menyelidiki secara terpisah setiap platform. Beberapa pengamatan yang telah saya lakukan:

  • Kecepatan di mana platform tertentu dikembangkan, diperluas, ditingkatkan memiliki korelasi langsung dengan kualitas pengembang. Aliran konstan fitur-fitur baru dan alat-alat baru yang menarik menarik pengembang yang antusias (yang rata-rata lebih mampu melakukan pekerjaan berkualitas) dan mengusir pikiran konservatif yang kesal dengan upaya belajar yang konstan.

  • Semakin sedikit batas yang ditawarkan platform bahkan dengan risiko lebih tinggi untuk menembak diri sendiri dengan cara yang sama menarik pikiran eksperimental yang antusias

  • Semakin kompleks hal-hal yang perlu dipahami dan dikuasai seseorang untuk menggunakan platform yang sama-sama menarik minat orang-orang yang terselesaikan dan membuat takut para pengembang yang malas


Bagaimana budaya ini melampaui batas perusahaan?
S.Lott

1
@Lott Technology hampir selalu melampaui batas budaya. Ada perbedaan budaya yang sangat besar antara pengguna OS yang berbeda. Banyak desainer grafis dan insinyur audio yang saya tahu akan berpikir itu adalah pemecah kesepakatan untuk pergi ke perusahaan yang menggunakan apa pun kecuali Mac. Mac telah memupuk budaya di sekitar dua kelompok itu khususnya yang sepenuhnya berwujud. Bahasa pemrograman adalah alat seperti Photoshop dan GIMP, jadi tidak mengherankan bahwa mereka memiliki budaya yang dibangun di sekitar mereka. Jika tidak, maka kita tidak akan memiliki perang api.
Morgan Herlocker

@Prof Plum: Contoh Anda tidak dipetakan ke "budaya" berdasarkan alat. Contoh Anda adalah kebalikannya. Budaya aktual (insinyur audio) memilih alat umum. Bukan berarti semua pengguna Logic Pro dipaksa menjadi insinyur audio karena entah bagaimana Logic Pro menciptakan budaya. Saya pikir contoh dalam komentar Anda (pekerjaan yang sama -> alat serupa) adalah bukti yang sangat baik bahwa tidak ada "sejarah budaya bahasa". Sebaliknya, ada budaya kasus penggunaan umum atau budaya kerja pengguna akhir yang umum.
S.Lott
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.