Apakah ilmu Ilmu Komputer mati? [Tutup]


18

Pertanyaan: Apakah sains dan seni CS mati? Maksud saya, persyaratan nyata untuk berpikir, merencanakan dan menyelesaikan masalah secara efisien tampaknya jauh dari CS saat ini. Lapangan tampaknya menurunkan entry-barrier sehingga lebih banyak orang dapat 'memprogram' tanpa harus belajar bagaimana memprogram dengan benar.

Latar belakang: Saya lulusan baru dengan gelar BS dalam Ilmu Komputer. Saya bekerja pada posisi awal di sebuah perusahaan berukuran layak di departemen TI. Saya kebanyakan melakukan .NET dan teknologi Microsoft lainnya di pekerjaan saya, tetapi sebelum ini saya telah melakukan hal-hal Java melalui magang dan sejenisnya. Saya pribadi adalah seorang programmer C ++ untuk proyek-proyek menyenangkan saya sendiri.

Dalam Kedalaman: Melalui pekerjaan yang telah saya lakukan, bagi saya tampaknya bahwa disiplin ilmu sains yang nyata tidak ada lagi di CS. Di masa lalu, programmer harus menyelesaikan masalah secara efisien agar sistem menjadi kuat dan cepat. Tetapi sekarang, dengan teknologi yang berlaku seperti .NET, Java dan bahasa scripting, sepertinya efisiensi dan ketahanan telah diperjualbelikan untuk kemudahan pengembangan.

Sebagian besar kolega yang bekerja dengan saya bahkan tidak memiliki gelar di bidang Ilmu Komputer. Sebagian besar lulus dengan gelar Teknik Elektro, beberapa dengan Rekayasa Perangkat Lunak, bahkan beberapa yang berasal dari sekolah teknologi tanpa program 4 tahun. Namun mereka mendapatkan dengan baik tanpa memiliki latar belakang teknis CS, tanpa mempelajari teori dan algoritma, tanpa memiliki perhatian untuk membuat solusi elegan (mereka hanya pergi untuk solusi termudah, termurah).

Perusahaan mendorong kami untuk menggunakan teknologi Microsoft, yang mengambil semua pemikiran nyata dari masalah ini dan menggantinya dengan perpustakaan dan alat yang dapat membangun proyek Anda secara otomatis untuk Anda separuh waktu. Saya tidak mencoba membenci bahasa, saya mengerti bahwa mereka melayani tujuan dan melakukannya dengan baik, tetapi ketika karyawan Anda tidak tahu bagaimana hash-table bekerja, dan menggunakan metode penyortiran yang salah, atau menjalankan perintah SQL yang sangat tidak efisien (tetapi menyelesaikan pekerjaan dalam waktu yang dapat diterima), rasanya seperti lebih banyak upaya dilakukan untuk mengembangkan teknologi yang memanjakan 'programmer' baru daripada benar-benar mengajar orang bagaimana melakukan sesuatu dengan benar.

Saya tertarik untuk membuat program yang efisien dan, menurut saya, indah. Jika ada cara yang lebih baik untuk melakukannya, saya lebih suka kembali dan memperbaiki daripada membiarkannya meluncur. Tetapi di dunia korporat, mereka mendorong saya untuk menyelesaikan tugas dengan cepat daripada dengan elegan. Dan itu benar-benar menggangguku.

Apakah ini yang akan saya nantikan seumur hidup saya? Apakah masih ada posisi di luar sana untuk orang-orang yang menyukai ilmu dan seni CS daripada hanya gaji?

Dan dengan catatan yang sama, inilah bacaan yang bagus jika Anda belum pernah melihatnya di The Perils Of Java Schools


2
Dua hal - 1. Pembangunan tidak harus sulit. 2. Program yang ditulis dengan baik akan sangat penting dalam situasi di mana skalabilitas penting, yang mana Anda mungkin akan bersinar. Saya setuju dengan apa yang Anda katakan pada prinsipnya. Meskipun saya menganggap diri saya seorang programmer pemula, saya tertarik untuk mempelajari semuanya pada level rendah (sampai batas tertentu) dan tidak menggunakan kerangka kerja pra-tertulis, dan seterusnya ... (setidaknya untuk memulai dengan ... atau ketika Saya menggunakan segala jenis kerangka kerja itu akan menjadi milik saya sendiri
Anonim

48
Saya pikir CS Anda membingungkan dengan pemrograman, ini terkait tetapi dua hal yang berbeda.
Darknight

1
@ Chris saya sepenuhnya setuju. Saya menggunakan banyak kerangka kerja dan perpustakaan, tetapi saya mencoba melakukannya tanpa terlebih dahulu memahami masalah dan bagaimana perpustakaan menyelesaikannya. Setelah saya tahu, maka saya dapat memilih perpustakaan mana yang memecahkannya paling baik DALAM INSTANSI INI, alih-alih hanya melempar perpustakaan umum pada setiap masalah dan berharap itu tetap ada
Veaviticus

8
Masalah apa yang Anda coba selesaikan dengan pertanyaan ini?
Jeremy

15
@Veaviticus, benar-benar Anda mengharapkan tukang ledeng Anda mengetahui dinamika fluida (sehingga mereka dapat melakukan pekerjaan mereka dengan lebih baik?). Sebagian besar aplikasi Line Of Business (desktop / web) tidak perlu menyelesaikan masalah yang sangat kompleks (sangat jarang). Apakah memiliki latar belakang di CS membantu ya! hampir dipastikan. Apakah itu diperlukan untuk LOB -> tidak juga.
Darknight

Jawaban:


25

Iya dan tidak

Pertanyaan bagus, tapi asumsi buruk.

Bagian sains dari pendidikan memang tampaknya kurang, tetapi asumsi bahwa sains ada di sana hanya untuk membuat program menjadi efisien adalah salah arah.

Ilmu itu diperlukan untuk mengajar orang bagaimana mendefinisikan dan memecahkan masalah.

Sayangnya, bagian dari beberapa kurikulum "CS" ini (kurikulum?) Tampaknya dihilangkan sepenuhnya, digantikan oleh masalah mainan dengan solusi sepele atau yang diketahui, dan dimaksudkan hanya untuk mengajarkan keakraban dengan alat.

Mengecewakan; banyak lulusan sekolah Jawa yang mengalami kekurangan, tidak pernah diajarkan cara menguraikan masalah, merancang algoritma, menentukan tes, atau bahkan men-debug secara efektif.


2
Saya menghadiri sebuah sekolah yang bahkan tidak terlalu menekankan Java, sebagian besar yang saya lakukan adalah di C ++. Tetapi mereka masih tidak mengajari kami bagaimana melakukan hal-hal yang Anda sebutkan. Mereka membahas dasar-dasar, membaca beberapa hal dan mempelajari secara mendalam apa yang diminati setiap profesor. Sepertinya sekolah akhir-akhir ini berusaha memompa sebanyak mungkin 'pengembang' daripada ilmuwan.
Veaviticus

@Veaviticus: Itu untuk siswa yang beruntung. Di universitas saya, para profesor memiliki tingkat abstraksi skizofrenia dan gagasan mereka tentang ujian adalah "melafalkan definisi formal".
DeadMG

Bahasa tidak ada hubungannya dengan ajaran membusuk masalah. Masalah adalah masalah terlepas dari apakah itu C, Java, atau Ruby.
Rig

29

Apakah ilmu Ilmu Komputer mati? "..." Saya lulusan baru dengan gelar BS dalam Ilmu Komputer. Saya bekerja pada posisi awal di sebuah perusahaan berukuran layak di departemen TI .

Sejujurnya, dua sen saya sendiri: Anda tidak akan menemukan "ilmu" ilmu komputer bekerja di departemen TI di perusahaan berukuran layak, karena itu adalah departemen TI, bukan departemen CS. Coba kembali ke sekolah untuk mendapatkan gelar PhD, atau bekerja di departemen teknik perusahaan yang fokusnya adalah ilmu komputer (misalnya, pemrosesan gambar, jaringan berkinerja tinggi, sistem aljabar komputer, dirgantara, dll ...). Di sinilah Anda akan menemukan masalah yang sulit dan menarik di mana desain ceroboh [umumnya] tidak akan ditoleransi.

"Apakah masih ada posisi di luar sana untuk orang-orang yang mencintai ilmu pengetahuan dan seni CS daripada hanya gaji?"

Ya, tentu saja, tetapi mungkin tidak di departemen TI perusahaan menengah.


16

Jika Anda seorang programmer, jangan menganggap diri Anda seorang "ilmuwan komputer"; ilmuwan komputer adalah orang-orang yang menciptakan generasi komputer berikutnya, beberapa di antaranya masih berupa fiksi ilmiah sampai campuran material yang benar, miniaturisasi, dan teori komputasi diturunkan. Mereka hanyalah awal dari jalur pipa. Orang yang mengembangkan perangkat lunak di sini dan sekarang adalah "insinyur perangkat lunak"; mereka mengambil teori dan alat, kadang-kadang meletakkan teori praktis dan alat dunia nyata di atas, untuk memanfaatkan kekuatan potentia dari sepotong sihir elektrik yang rumit ini dan membuatnya melakukan apa yang kita inginkan. Hal ini pada gilirannya adalah salah satu spesialisasi bidang "teknik komputer", yang mengambil teori-teori para ilmuwan komputer dan menerapkannya, perangkat keras dan perangkat lunak, ke solusi elektronik pengguna akhir dunia nyata.

Inilah, IMO, tempat bisnis bertemu teori. Dalam kasus-kasus seperti ini, pepatah lama "musuh yang lebih baik sudah cukup baik" dapat dengan mudah dibalik untuk membaca "musuh yang cukup baik itu lebih baik". Mempertimbangkan diri Anda sebagai seorang "insinyur" dan bukan "ilmuwan", dan menempatkan apa yang Anda lakukan secara paralel dengan disiplin ilmu teknik lainnya, membuat perbedaan menjadi lega.

Katakanlah seorang klien mendatangi Anda, seorang insinyur sipil / struktural, dan meminta Anda membangun jembatan. Jembatan perlu merentang 20 kaki, menopang dirinya sendiri dan satu ton muatan pengangkut, itu harus bertahan 10 tahun dengan pemeliharaan rutin, dan mereka menginginkannya dalam sebulan seharga $ 20.000. Itu adalah kendala Anda; memenuhi minimum tanpa maksimum. Melakukan itu "cukup baik", dan memberi Anda gaji. Ini akan menjadi rekayasa yang buruk bagi Anda untuk membangun Jembatan Golden Gate, jauh melebihi spesifikasi desain dan anggaran dengan beberapa urutan besarnya. Anda biasanya berakhir dengan penyimpangan biaya dan membayar penalti untuk kelebihan waktu. Ini juga akan menjadi rekayasa yang buruk bagi Anda untuk membangun jembatan tali dengan nilai 5 pria dewasa walaupun biayanya hanya $ 1000 dalam waktu dan bahan; Anda tidak mendapatkan ulasan dan testimonial klien yang baik,

Kembali ke perangkat lunak, misalkan Anda memiliki klien yang membutuhkan sistem pemrosesan file yang dibangun untuk mencerna file yang masuk dan memasukkan informasi ke dalam sistem. Mereka ingin itu dilakukan dalam seminggu dan harus menangani lima file sehari, sekitar 10MB nilai data, karena itu semua lalu lintas yang mereka dapatkan saat ini. Teori-teori berharga Anda sebagian besar keluar dari jendela; tugas Anda adalah membangun produk yang memenuhi spesifikasi tersebut dalam seminggu, karena dengan melakukan itu Anda juga memenuhi anggaran biaya klien (karena bahan umumnya setetes dalam ember untuk kontrak perangkat lunak sebesar ini). Menghabiskan dua minggu, bahkan untuk mendapatkan sepuluh kali lipat, bukanlah suatu pilihan, tetapi kemungkinan besar, tidak ada program yang dibangun dalam satu hari yang hanya dapat menangani setengah dari throughput, dengan instruksi untuk menjalankan dua salinan.

Jika Anda berpikir ini adalah kasus pinggiran, Anda salah; ini adalah lingkungan sehari-hari sebagian besar in-housers. Alasannya adalah ROI; program awal ini tidak memerlukan biaya banyak dan dengan demikian akan membayar sendiri dengan sangat cepat. KETIKA para pengguna akhir membutuhkannya untuk melakukan lebih banyak atau lebih cepat, kodenya dapat di refactored dan diskalakan.

Itulah alasan utama di balik keadaan pemrograman saat ini; asumsi, yang ditanggung oleh seluruh sejarah komputasi, adalah bahwa suatu program TIDAK PERNAH statis. Itu akan selalu perlu ditingkatkan dan pada akhirnya akan diganti. Secara paralel, peningkatan konstan komputer tempat program dijalankan memungkinkan penurunan perhatian terhadap efisiensi teoretis, dan peningkatan perhatian pada skalabilitas dan paralelisasi (suatu algoritma yang berjalan dalam waktu N-squared tetapi yang dapat diparalelasikan untuk berjalan pada N core akan muncul linier, dan seringkali biaya lebih banyak perangkat keras lebih murah daripada pengembang untuk menemukan solusi yang lebih efisien).

Selain itu, ada prinsip yang sangat sederhana bahwa setiap baris kode pengembang adalah sesuatu yang lain yang bisa salah. Semakin sedikit yang ditulis pengembang, semakin kecil kemungkinan bahwa apa yang ditulisnya memiliki masalah. Ini bukan kritik atas "tingkat bug" siapa pun; itu adalah pernyataan fakta yang sederhana. Anda mungkin tahu cara menulis MergeSort ke belakang dan ke depan dalam 5 bahasa, tetapi jika Anda hanya menggunakan satu pengidentifikasi dalam satu baris kode, seluruh Urutan tidak berfungsi, dan jika kompiler tidak menangkapnya, Anda dapat melakukannya jam untuk debug itu. Bandingkan dengan List.Sort (); itu ada di sana, efisien dalam kasus umum, dan, inilah yang terbaik, itu sudah berfungsi.

Jadi, banyak fitur platform modern, dan prinsip metodologi desain modern, dibangun dengan pemikiran ini:

  • OOP - membangun data terkait dan logika menjadi objek, dan di mana pun konsep objek itu valid, maka objek, atau derivasi yang lebih khusus.
  • Template yang dibuat sebelumnya - 60% atau lebih kode yang bagus adalah sintaksis dan dasar-dasar untuk membuat program menampilkan sesuatu di layar. Dengan menstandarkan dan membuat kode ini secara otomatis, Anda mengurangi beban kerja pengembang hingga setengahnya, memungkinkan peningkatan produktivitas.
  • Perpustakaan algoritma dan struktur data - Seperti di atas, Anda mungkin tahu cara menulis Stack, Queue, QuickSort, dll, tetapi mengapa Anda harus, ketika ada perpustakaan kode yang memiliki semua ini dibangun di dalamnya? Anda tidak akan menulis ulang IIS atau Apache karena Anda memerlukan situs web, jadi mengapa menerapkan algoritma QuickSort atau objek pohon merah-hitam ketika beberapa implementasi hebat tersedia?
  • Antarmuka yang lancar - Di sepanjang baris yang sama, Anda mungkin memiliki algoritma yang menyaring dan mengurutkan rekaman. Ini cepat, tetapi mungkin tidak terlalu mudah dibaca; itu akan membutuhkan pengembang junior Anda sehari hanya untuk memahaminya, apalagi membuat perubahan bedah yang diperlukan untuk mengurutkan pada bidang tambahan dalam objek rekaman. Sebaliknya, pustaka seperti Linq mengganti banyak kode yang sangat jelek, sering rapuh dengan satu atau dua baris pemanggilan metode yang dapat dikonfigurasi untuk mengubah daftar objek menjadi objek yang difilter, diurutkan, diproyeksikan.

2
Jawaban yang bagus, tetapi Anda kehilangan satu poin penting. "Itu yang tidak bisa saya tiru, saya tidak mengerti." Mengetahui cara kerjanya tidak berarti Anda mengetiknya untuk setiap proyek; alih-alih, itu memastikan bahwa Anda mengetahui setiap kekuatan dan kelemahan mereka yang akan membantu Anda memilih yang terbaik. Kemudian, yang harus Anda ketahui adalah apakah algoritma / struktur data itu ada di perpustakaan standar Anda.
Michael K

Kecuali bahwa pepatah Anda salah; Saya dapat memahami dengan sangat jelas konsep di balik beberapa hal materi yang saya tidak punya harapan untuk berhasil ditiru. Saya setuju secara prinsip; seorang insinyur yang sukses dari segala jenis perlu mengetahui teori yang cukup untuk memilih solusi yang berhasil. Itu tidak berarti bahwa seorang insinyur harus mampu membangun setiap jenis bola lampu untuk mengetahui spesifikasi masing-masing dan dengan demikian memilih yang tepat untuk sebuah rumah. Demikian pula, saya dapat menggunakan pohon merah-hitam, memahami kinerjanya dan aplikasi yang tepat, tanpa memiliki petunjuk bagaimana menerapkannya dari awal.
KeithS

Analogi dengan teknik bukanlah yang baik. Ini bukan kasus bahwa "jembatan yang lebih baik" di CS tentu membutuhkan biaya banyak - seringkali hanya masalah pemahaman alat mana yang sesuai untuk pekerjaan yang tepat. Bahkan menerapkan algoritma buku teks yang cukup kompleks sering kali merupakan jalan keluar dari zona nyaman orang, namun itu bukan gagasan yang sulit atau mahal (tergantung pada ruang lingkup - tetapi dengan asumsi ini adalah proyek dalam man-tahun, bukan man-days). Biasanya lebih mudah - tidak ada implementasi kustom, hanya pertanyaan mengetahui alat yang tepat dan kata kunci untuk google.
Eamon Nerbonne

8

Tampak bagi saya bahwa Anda melakukan IT dan bukan CS dan seharusnya tidak menyiratkan bahwa CS sudah mati. CS tidak mati, hanya saja sebagian besar pekerjaan dalam pengembangan Perangkat Lunak. Karena sebagian besar siswa CS belajar memprogram, mereka biasanya mempekerjakan sebagai programmer dan bukan sebagai ilmuwan komputer. Pekerjaan Ilmu Komputer sangat kecil dibandingkan dengan pekerjaan pemrograman. Anda bahkan mungkin melakukan aplikasi yang kompleks menggunakan teknik ilmu komputer, tetapi menurut saya (dan saya tidak suka pendapat-jawaban karena mereka subjektif), yang jatuh di kamp rekayasa daripada kamp ilmuwan.

Juga, kode yang indah dan elegan ada di mata yang melihatnya , tetapi bagi sebagian besar perusahaan / manajer, memiliki desain yang cukup baik dan tepat waktu jauh lebih penting daripada kode yang indah tetapi tidak pernah selesai tepat waktu.

Terakhir, ada dunia nyata dan daratan. Sayangnya, kami mendapatkan gaji dari yang pertama, dan di situlah "ilmu / seni" pengembangan perangkat lunak muncul tentang bagaimana menghasilkan kualitas perangkat lunak yang tinggi dengan kendala waktu / anggaran. Saya merasakan jenis perasaan yang sama dengan yang Anda miliki di awal karier saya. Saya selalu ingin menciptakan "yang terbaik", tetapi segera saya menyadari bahwa "yang terbaik" bukan yang paling efisien atau elegan, tetapi desain yang paling hemat biaya.


3
"kode yang indah dan elegan" vs "enuogh yang baik, tetapi tepat waktu" adalah dikotomi yang salah. Lebih mudah selesai tepat waktu jika desain Anda sederhana, dan desain sederhana sama dengan desain yang indah. Hanya saja, simpel bukan berarti simplistis .
pembuat pil

1
@pillmuncher, Ya saya setuju, bagi saya, kode yang indah itu sederhana (tapi tidak lebih sederhana) tapi sayangnya premis itu subyektif / relatif. "desain sederhana sama dengan desain yang indah" bukan merupakan pernyataan tetapi pendapat (pendapat yang sangat populer bahwa saya setuju 100%, tetapi masih pendapat). Yang bukan pendapat, adalah jadwal, persyaratan dan biaya. Kendala tersebut cenderung mengarah pada desain yang cukup baik untuk kendala yang diberikan.
Armando

"[1] Tampak bagi saya bahwa Anda melakukan TI dan bukan CS dan seharusnya tidak menyiratkan bahwa CS sudah mati. [2] CS tidak mati, hanya saja sebagian besar pekerjaan ada dalam pengembangan Perangkat Lunak". Pernyataan pertama Anda benar - OP ada di TI dan bukan CS. Saya menerima masalah dengan pernyataan kedua Anda, karena banyak yang disebut "ilmuwan komputer" juga melakukan pengembangan perangkat lunak. Ini disebut "penelitian dan pengembangan", dan contohnya mungkin para ilmuwan komputer yang mendefinisikan, memecahkan, dan membuktikan kebenaran dari algoritma perutean pada topologi jaringan tertentu, kemudian menerapkan implementasi "resmi" atau prototipe
Bill VB

8

Pertama-tama, Anda salah. "Berpikir, merencanakan, dan menyelesaikan masalah secara efisien" bukanlah ilmu pengetahuan, itu rekayasa. Ilmu pengetahuan lebih banyak tentang mengeksplorasi bidang baru. Dan sebenarnya di dunia akademik orang kurang peduli tentang efisiensi kode, apalagi di industri. Di dunia akademis lebih tentang pembuktian konsep dll.

Tidak, yang Anda uraikan adalah bahwa pengetahuan yang kurang mendalam diperlukan untuk pengembangan perangkat lunak. Yang mungkin benar, jika persyaratannya sama. Namun saat ini, insinyur perangkat lunak diharapkan untuk mengetahui cara menangani multi-threading, komputasi terdistribusi, penskalaan, dll. Mereka diharapkan mengetahui cara memimpin proyek secara efisien. Sebagian besar ini sama sekali tidak ada dalam kurikulum beberapa dekade lalu.


Masih belum, dari apa yang saya baca di sini. Banyak sekolah tidak mengajarkan teknik, mereka mengajar bahasa. Itu sama saja dengan mengajar Autocad kepada seorang mahasiswa teknik sipil.
Michael K

@Michael: Belum pernah melihat universitas yang layak melakukan itu.
vartec

1
Saya pergi ke RIT. Ini peringkat tinggi, dan masih agak jelek. Tidak ada sekolah yang mengajarkan pemrograman dengan benar, karena itu tidak dapat dilakukan hanya dalam empat atau lima tahun dalam konteks kursus lain.
Jon Purdy

4

Saya tidak berpikir apa yang Anda katakan adalah tepat, tetapi Anda memiliki sesuatu dari titik pula. Secara khusus, saya pikir seiring waktu, ilmu komputer dan rekayasa perangkat lunak telah tumbuh terpisah.

Rekayasa perangkat lunak (seperti teknik lainnya) adalah tentang menerapkan sains untuk membangun produk, menyelesaikan masalah, dll. Ilmu komputer terutama tentang penelitian dalam algoritma dan (meskipun bagian ini sering agak dilupakan) bagaimana menerapkan algoritma tersebut (setidaknya dalam beberapa pengertian teoritis - mis., mungkin memperlakukan semua mesin PRAM sebagai setara).

Mempertimbangkan hal itu, saya pikir alasan di balik bifurkasi menjadi jelas: sebagian besar masalah algoritmik yang terlibat dalam sesuatu seperti situs web biasa telah diselesaikan - sebagian besar, sudah lama . Mungkin yang lebih penting, sebagian besar dari mereka telah dipecahkan dengan cukup baik sehingga bagi pengembang web rata-rata, masalahnya hampir sepenuhnya hilang. Misalnya, melakukan pembaruan atom ke database terdistribusi jelas merupakan tugas yang tidak sepele - tetapi pengembang web biasa hanya menulis beberapa SQL, dan tidak memiliki petunjuk (atau kepedulian) tentang berapa banyak penelitian yang diperlukan untuk mengetahui bagaimana membuat pekerjaan. andal.

Pada suatu waktu, pada dasarnya mustahil memisahkan ilmu komputer dari rekayasa perangkat lunak. Begitu sedikit masalah yang telah dipecahkan sehingga penulisan bahkan suatu program yang relatif sepele memerlukan penelitian terhadap dasar-dasarnya. Jika Anda ingin melakukan sesuatu yang sederhana seperti menyortir sekelompok data di akhir tahun 50-an atau awal 60-an, kemungkinannya cukup baik bahwa Anda akan harus melakukan beberapa analisis data Anda, dan mencoba merancang sebuah algoritma yang sesuai dan sebaik mungkin dengan apa yang diperlukan untuk mengurutkan data tertentu - tidak ada yang dekat dengan banyak algoritma pengurutan yang dikenal seperti saat ini, dan bahkan algoritma yang dikenal tidak dikenal hampir sebaik mereka sekarang. .

50 tahun penelitian dan pengembangan telah membuahkan hasil - pengembangan yang paling khas dapat menggunakan tidak hanya algoritma yang dikenal, tetapi implementasi pra-tertulis. Sebagian besar masalah dapat diselesaikan dengan cukup masuk akal berdasarkan pengetahuan yang ada (dan bahkan implementasi yang ada) dari algoritma.

Itu tidak berarti ilmu komputer mati - masih ada lebih banyak algoritma untuk penelitian, dan orang-orang melakukan penelitian ke dalamnya. Namun, ini berarti bahwa sebagian besar penelitian lebih terspesialisasi, dan hanya mungkin berlaku untuk bidang yang cukup khusus. Mungkin juga ada "kesenjangan" yang lebih besar antara memperoleh dan menerapkan pengetahuan. Pada suatu waktu, Anda menemukan cara yang lebih baik untuk menyortir dalam proses menulis program penyortiran, dan itu ditulis ke dalam kode nyata segera. Sekarang banyak ilmu komputer dikhususkan untuk hal-hal seperti bagaimana menggunakan prosesor yang pada dasarnya tak terbatas - yang mungkin akan berguna suatu hari nanti, tetapi bahkan suku primitif tidak akan menghitung dual core di komputer saya sebagai "banyak" ... :-)


1

Pengembangan perangkat lunak dan ilmu komputer bukan hal yang sama, dan saya menemukan bahwa sebagian besar teman sekelas saya dalam B.Sc. Program Comp Sci merasa frustrasi dengan ini.

Saya menganggap perangkat lunak sebagai produk ilmu komputer ... seperti lukisan adalah produk seni visual.

Saya pikir sebagian besar orang dengan gelar CS mendapatkan pekerjaan untuk melakukan pengembangan perangkat lunak, terutama pada tahap awal karir mereka. Saya pikir banyak orang dalam peran ini tetap di sana dan tidak melangkah lebih jauh.

Saya pikir perbedaan mulai muncul ketika masalah atau paradigma baru muncul atau ketika "menampar itu bersama" tidak cukup baik. Siapa yang membangun kerangka kerja atau bahasa baru? Siapa yang duduk dan memalu detail mesin fisika baru? Siapa yang menggunakan teori grafik / transformasi grafik untuk mengeluarkan beberapa siklus per iterasi kinerja dari suatu algoritma?

Saya akan menyelesaikan di mana saya mulai, setuju bahwa ada banyak ilmuwan komputer dalam pengembangan perangkat lunak / peran rekayasa, mungkin tidak memenuhi potensi mereka.


1

Anda tampaknya membingungkan ilmu komputer dengan pemrograman dan pengembangan perangkat lunak secara umum. Keduanya tidak sama, bahkan tidak dekat. Terlepas dari apa yang derajat kita katakan, sebagian besar dari kita adalah programmer, bukan ilmuwan komputer. Kecuali jika Anda secara aktif terlibat dalam akademisi di tingkat tinggi maka saya akan bertaruh bahwa Anda tidak benar-benar tahu apa yang sedang terjadi dalam ilmu komputer.


0

Saya dapat memberitahu Anda bahwa Ilmu Komputer masih hidup dan sehat. Saya harus menyelesaikan masalah baru setiap hari dan menghasilkan solusi yang efektif dan elegan untuk masalah itu. Saya harus menggunakan keahlian saya sebagai seorang insinyur setiap hari dan menggunakan pengetahuan saya dan kolega saya untuk memecahkan masalah-masalah itu bagi pelanggan kami.

Saya tidak mencoba membenci bahasa, saya mengerti bahwa mereka melayani tujuan dan melakukannya dengan baik, tetapi ketika karyawan Anda tidak tahu bagaimana hash-table bekerja, dan menggunakan metode penyortiran yang salah, atau menjalankan perintah SQL yang sangat tidak efisien (tetapi menyelesaikan pekerjaan dalam waktu yang dapat diterima), rasanya seperti lebih banyak upaya dilakukan untuk mengembangkan teknologi yang memanjakan 'programmer' baru daripada benar-benar mengajar orang bagaimana melakukan sesuatu dengan benar.

Ini terdengar seperti masalah dengan karyawan dan tentu saja tidak berlaku untuk setiap programmer.

Hanya karena alat yang membuat pekerjaan kita lebih mudah ada, bukan berarti kita tidak seharusnya memahami teknologi yang digarisbawahi, jika kita tidak melakukannya, kita tidak membantu siapa pun dan tentu saja tidak melakukan pekerjaan kita dalam menyelesaikan masalah dengan cara yang benar.


Saya setuju. Saya tidak mencoba mengatakan tidak ada pekerjaan yang tidak perlu dipikirkan, atau bahwa semua pengembang tidak tahu apa yang mereka lakukan, tetapi baru saja datang dari program CS, saya dapat memberi tahu Anda bahwa sekolah saya tidak ajari aku setengah hal yang aku tahu sekarang. Saya mempelajarinya sendiri. Dan sekarang saya tahu mereka, saya bisa menggunakan kerangka kerja yang melakukannya untuk saya. Tetapi jika saya tidak mempelajarinya sendiri, saya hanya akan secara buta menggunakan kerangka kerja, paling sering salah
Veaviticus

0

Anda hanya belum mengerti masalah yang dihadapi. Masalahnya bukan mendapatkan kinerja maksimum - itu mendapatkan kinerja yang cukup untuk aplikasi Anda menjadi responsif dan cukup cepat. Belajar program adalah tentang memecahkan masalah, dengan jumlah uang terkecil.

Saya benci mengatakannya dengan cara ini, tetapi kesan Anda tentang kematian CS hanyalah pra-konsepsi Anda sendiri tentang apa yang harus dilakukan oleh programmer "nyata".


Baik. Saya tahu bisnis perlu menghasilkan uang. Dan saya tentu saja tidak bersalah membuat bagian dari aplikasi saya 'cukup cepat' daripada yang terbaik yang mereka bisa. Saya lebih ingin tahu tentang tren secara keseluruhan yang banyak (setidaknya dari apa yang bisa saya katakan) pengembang belum pernah belajar CS. Mereka datang ke lapangan dari tempat lain, dan memiliki sedikit atau tidak ada teori nyata di belakang mereka, hanya pengalaman dengan kerangka kerja
Veaviticus

@Veaviticus: Menggunakan kerangka kerja mungkin bukan teori akademis yang inovatif, tapi pasti masih CS.
DeadMG

0

Baik, mati atau tidak bisa diperdebatkan!

Faktanya adalah bahwa di era teknologi saat ini sebagian besar perusahaan mempekerjakan orang untuk menyelesaikan tugas-tugas jenis alur kerja dunia nyata melalui otomatisasi perangkat lunak. Mereka tidak tertarik pada seberapa elegan atau lebih cepat sebuah program yang dapat Anda tulis, asalkan memungkinkan bisnis untuk mengeksekusi lebih cepat dengan output yang lebih tinggi.

The stres adalah pada output lebih dalam waktu kurang. (Pikirkan komersialisasi tanaman / pangan; pertumbuhan lebih cepat dan lebih banyak dengan biaya lebih sedikit). Hal yang sama terjadi di dunia teknologi (ide baru berikutnya).

Ingat, di zaman sekarang ini, segala sesuatu bergerak lebih cepat daripada sebelumnya karena jumlah dan akses ke pengetahuan daripada di masa lalu. Di masa lalu, output kecil dan lebih baik, keuntungan lebih besar. Sekarang, permainan telah berubah sepenuhnya. Lihat saja hal-hal seperti kualitas layanan pelanggan dan secara umum hal itu tidak bertahan lama.

Keanggunan dan efisiensi penting bagi perusahaan teknologi seperti Google, dll. Walaupun tempat-tempat itu tidak sempurna, tetapi Anda dapat mendekatinya dengan bekerja di salah satu perusahaan itu di tahun-tahun mendatang.

Selalu ada pertukaran dalam hidup. Anda dapat menemukan pekerjaan yang membayar lebih sedikit, di mana Anda memiliki semua waktu dan perhatian. Atau, Anda memilih untuk berenang bersama kami yang lain untuk pembayaran yang lebih baik dan mengabaikan hal-hal yang tidak sempurna. Semakin cepat realisasi ini meresap dalam diri Anda, Anda bisa bersiap diri untuk dunia nyata. Saya tidak mengatakan Anda harus mengabaikan kualitas dan keanggunan tetapi tahu dinamika. Anda akan Lebih Bahagia :)


0

Menurut saya beberapa hal yang paling menarik di masa depan mungkin akan didasarkan pada bagian sains dari ilmu komputer, khususnya perbaikan visi komputer / pembelajaran mesin dan algoritma sematisizing lainnya. Ini mungkin akan didorong maju dalam industri (misalnya menggunakan Microsoft Kinect) tetapi merupakan masalah yang sangat sulit, mereka pasti akan didasarkan pada badan besar penelitian dan kemajuan yang dibuat dalam bidang akademik (sekali lagi, ambil Microsoft Kinect).


0

Saya pikir pemrograman standar sehari-hari adalah tentang sebanyak seni sebagai ilmu tetapi pasti ada daerah yang sangat tertarik pada aspek-aspek sains dari ilmu komputer. Misalnya peneliti untuk perusahaan dan universitas. Jika Anda benar-benar ingin terlibat dalam ilmu profesional maka Anda harus mencari gelar doktor. Namun, saya menemukan bahwa bagian sains dari pendidikan saya terus bernilai, meski juga harus mengandalkan sisi kreatif saya yang lebih nyata!

Orang-orang yang tidak tahu apa yang mereka lakukan dapat meretas dengan beberapa alat yang Anda sebutkan tetapi mereka biasanya mempekerjakan orang-orang CS yang nyata untuk membuat alat, Anda hanya perlu lebih abstrak untuk benar-benar mendorong diri sendiri.

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.