Bilgisayar Bilimi bilimi öldü mü? [kapalı]


18

Soru: CS'nin bilim ve sanatı öldü mü? Demek istediğim, problemleri düşünmek, planlamak ve verimli bir şekilde çözmek için gerçek gereksinimler bugünlerde CS'den düşüyor gibi görünüyor. Alan, giriş engelini düşürüyor gibi görünüyor, böylece daha fazla insan gerçekten nasıl programlanacağını öğrenmek zorunda kalmadan 'programlayabiliyor'.

Geçmiş: Bilgisayar Bilimi lisans derecesi ile yeni mezun oldum. BT departmanında iyi bir şirkette başlangıç ​​pozisyonunda çalışıyorum. Çoğunlukla işimde .NET ve diğer Microsoft teknolojilerini yapıyorum, ancak bundan önce stajlar ve benzerleri aracılığıyla Java şeyler yaptım. Ben şahsen kendi eğlenceli projelerim için bir C ++ programcısıyım.

Derinlemesine: Yaptığım çalışma sayesinde, gerçek bir bilimin yoğun disiplinlerinin artık CS'de mevcut olmadığı anlaşılıyor. Geçmişte, programcılar sistemlerin sağlam ve hızlı olması için sorunları verimli bir şekilde çözmek zorundaydılar. Ancak şimdi, .NET, Java ve komut dosyası dilleri gibi hakim teknolojilerle, verimlilik ve sağlamlığın geliştirme kolaylığı için takas edildiği anlaşılıyor.

Birlikte çalıştığım meslektaşların çoğunun Bilgisayar Bilimi diploması bile yok. En çok Elektrik Mühendisliği bölümünden mezun oldu, bazıları Yazılım Mühendisliği ile, hatta bazıları 4 yıllık bir program olmadan teknoloji okullarından gelmişti. Yine de, CS'nin teknik altyapısına sahip olmadan, teorileri ve algoritmaları incelemeden, zarif bir çözüm yapmaya hiç dikkat etmeden gayet iyi olurlar (sadece en kolay, en ucuz çözümü ararlar).

Şirket, tüm gerçek düşünceyi ortadan kaldıran ve projenizi sizin için yarı zamanlı olarak otomatik olarak oluşturabilecek kütüphaneler ve araçlarla değiştiren Microsoft teknolojilerini kullanmaya zorluyor. Dillerden nefret etmeye çalışmıyorum, bir amaca hizmet ettiklerini ve iyi yaptığını anlıyorum, ancak çalışanlarınız bir karma tablonun nasıl çalıştığını bilmediğinde ve yanlış sıralama yöntemlerini kullandıklarında veya SQL komutlarını çalıştırdıklarında korkunç derecede verimsiz (ancak işi kabul edilebilir bir zamanda yapın), insanlara bir şeyleri nasıl doğru yapacaklarını öğretmekten ziyade yeni 'programcıları' kodlayan teknolojiler geliştirmek için daha fazla çaba harcanıyor gibi geliyor.

Verimli ve bence güzel programlar yapmakla ilgileniyorum. Bunu yapmanın daha iyi bir yolu varsa, geri dönüp kaymasına izin vermemeyi tercih ederim. Ama kurumsal dünyada, beni zarif bir şekilde değil, hızlı bir şekilde görevleri tamamlamaya itiyorlar. Ve bu gerçekten beni rahatsız ediyor.

Hayatımın geri kalanında dört gözle bekleyeceğim şey bu mu? Hala maaş kontrolünden ziyade CS bilimini ve sanatını seven insanlar için hala pozisyonlar var mı?

Aynı notta, Java Okullarının Perils'inden önce görmediyseniz, iyi bir okuma


2
İki şey - 1. Gelişim zor olmak zorunda değil. 2. Ölçeklendirilebilirliğin önemli olduğu, muhtemelen parlayacağınız yerlerde iyi yazılmış programlar gerekli olacaktır. Prensipte söylediklerinize katılıyorum. Kendimi acemi bir programcı olarak görmeme rağmen, her şeyi düşük düzeyde (bir dereceye kadar) öğrenmekle ve önceden yazılmış çerçeveler kullanmamaya ve diğerlerine ... (en azından ... Kendi olacak her türlü çerçeveyi kullanıyorum
Anonim

48
Programlama ile kafa karıştırıcı CS düşünüyorum, bunlar ilgili ama iki farklı şey.
Darknight

1
@chris Kesinlikle katılıyorum. Çerçeveleri ve kütüphaneleri kapsamlı bir şekilde kullanıyorum, ancak sorunu ve kütüphanenin nasıl çözdüğünü anlamadan önce bunları yapmaya çalışıyorum. Bir kez bildiğimde, o zaman her soruna genel bir kütüphane atmak ve
yapışmasını

8
Bu soru ile hangi sorunu çözmeye çalışıyorsunuz?
Jeremy

15
@Veaviticus, gerçekten tesisatçılarınızın sıvı dinamiklerini bilmelerini bekliyorsunuz (böylece işlerini daha iyi yapabilirler mi?). İş Hattı uygulamalarının (masaüstü / web) çoğunluğunun oldukça karmaşık sorunları (çok nadiren) çözmesi gerekmez. CS'de bir geçmişe sahip olmak evet'e yardımcı olur mu? kesinlikle. LOB için gerekli mi -> gerçekten değil.
Darknight

Yanıtlar:


25

Evet ve hayır

İyi soru, ama kötü varsayım.

Eğitimin Bilim kısmı eksik görünmektedir, ancak bilimin sadece programları verimli hale getirmek için orada olduğu varsayımı yanlış yönlendirilmiştir.

Bilim insanlara problemleri nasıl tanımlayacaklarını ve çözeceklerini öğretmek için gerekliydi .

Ne yazık ki, bazı "CS" müfredatlarının (müfredat?) Bu kısmı tamamen atlanmış gibi görünüyor, yerini önemsiz veya bilinen çözümlerle ilgili oyuncak problemleri alıyor ve sadece araçlara aşinalık öğretmeyi amaçlıyor

Hayal kırıklığı; Birçok Java okulu mezunu kısa süre önce değiştirildi, bir sorunun nasıl çözüleceğini, bir algoritmanın nasıl tasarlanacağını, bir testin nasıl belirleneceğini ve hatta etkili bir şekilde nasıl hata ayıklanacağını öğretmediler.


2
Java'yı çok fazla vurgulamayan bir okula gittim, yaptığım şeylerin çoğu C ++ idi. Ama yine de bize bahsettiğiniz şeylerin nasıl yapılacağını öğretmediler. Temel konuları ele aldılar, bir şeyler yağdılar ve her bir profesörün ilgisini çekti. Bu günlerde okullar mümkün olduğunca bilim adamları yerine 'geliştiriciler' pompalamaya çalışıyor gibi görünüyor.
Veaviticus

@Veaviticus: Bu şanslı öğrenciler için olurdu. Üniversitemde profesörlerin şizofrenik bir soyutlama seviyesi var ve sınav fikirleri "resmi tanımı oku" dır.
DeadMG

Dilin bir sorunu çözme öğretileri ile ilgisi yoktur. Bir sorun, C, Java veya Ruby olmasına bakılmaksızın bir sorundur.
Rig

29

Bilgisayar Bilimi bilimi öldü mü? "..." Yakın zamanda Bilgisayar Bilimi lisans derecesi ile mezun oldum. BT departmanında iyi bir şirkette başlangıç ​​pozisyonunda çalışıyorum .

Dürüst olmak gerekirse, kendi iki sentim: Bilgisayar biliminin "bilimini", iyi büyüklükteki bir şirketteki bir BT bölümünde çalışan bulamazsınız, çünkü CS bölümü değil, BT bölümüdür. Doktora için okula geri dönmeyi veya odağı bilgisayar bilimi olan bir şirketin mühendislik bölümlerinde çalışmayı deneyin (ör. Görüntü işleme, yüksek performanslı ağlar, bilgisayar cebir sistemleri, havacılık, vb.). Bu, özensiz tasarımın (genellikle) hoş görülmeyeceği zor, ilginç sorunları bulacağınız yerdir.

"Sadece maaş kontrolünden ziyade CS bilimini ve sanatını seven insanlar için hala pozisyonlar var mı?"

Evet, kesinlikle, ama muhtemelen orta büyüklükteki şirketlerin BT departmanlarında değil.


16

Bir programcıysanız, kendinizi bir "bilgisayar bilimcisi" olarak düşünmeyin; bilgisayar bilimcileri, doğru malzeme karışımı, minyatürleştirme ve hesaplama teorisi elde edilene kadar bazıları hala bilim kurgu olan yeni nesil bilgisayarları yaratanlardır. Bunlar sadece boru hattının başlangıcıdır. Burada ve şimdi yazılım geliştiren insanlar "yazılım mühendisleri" dir; teorik ve araçları, bazen pratik teoriyi ve gerçek dünya araçlarını üst üste yerleştirerek, bu karmaşık elektinik sihirbazlık parçasının potansiyelindeki gücü kullanmak ve istediğimizi yapmasını sağlamak için alıyorlar. Bu, bilgisayar bilimcilerinin teorilerini alıp, donanım ve yazılımı gerçek dünyadaki son kullanıcı elektronik çözümlerine uygulayan "bilgisayar mühendisliği" alanının bir uzmanlığıdır.

Burası, iş dünyasının teoriyle buluştuğu IMO'dur. Bu tür durumlarda, "daha iyinin düşmanı yeterince iyidir" eski atasözü "yeterince iyinin düşmanı daha iyidir" okumak için kolayca döndürülebilir. Kendinizi bir "bilim adamı" yerine bir "mühendis" olarak görmek ve yaptıklarınızı diğer mühendislik disiplinlerine paralel koymak, farklılıkları rahatlatır.

Diyelim ki bir inşaat mühendisi / inşaat mühendisi size geliyor ve bir köprü inşa etmenizi istiyor. Köprünün 20 feet'e yayılması, kendini ve bir ton taşıma yükünü desteklemesi gerekiyor, rutin bakım ile 10 yıl sürmeli ve bir ay içinde 20.000 $ karşılığında istiyorlar. Bunlar sizin kısıtlamalarınızdır; maksimumları aşmamakla birlikte minimumları karşılar. Bunu yapmak "yeterince iyi" ve maaş çeki alır. Golden Gate Köprüsü'nü inşa etmek, hem tasarım özelliklerini hem de bütçeyi birkaç büyüklükte aşan çok kötü bir mühendislik olurdu. Genellikle maliyet aşımlarını yiyor ve zaman aşımları için ceza ödüyorsunuz. Ayrıca, zaman ve malzeme olarak sadece 1000 dolara mal olmasına rağmen, 5 yetişkin erkeğin ağırlığı için bir halat köprüsü inşa etmeniz de kötü bir mühendislik olacaktır; iyi müşteri yorumları ve referansları almazsanız,

Yazılıma geri dönersek, gelen dosyaları sindirmek ve bilgileri sisteme koymak için oluşturulmuş bir dosya işleme sistemine ihtiyaç duyan bir müşteriniz olduğunu varsayalım. Bir hafta içinde yapılmasını istiyorlar ve günde beş dosya, yaklaşık 10 MB değerinde veri işlemek zorundalar, çünkü şu anda aldıkları tüm trafik bu. Değerli teorileriniz büyük ölçüde pencereden dışarı çıkar; göreviniz bu özellikleri bir hafta içinde karşılayan bir ürün oluşturmaktır, çünkü bunu yaparak müşterinin maliyet bütçesini de karşılayabilirsiniz (malzemeler genellikle bu boyuttaki bir yazılım sözleşmesi için kovada bir düşüş olduğu için). İki haftayı, kazancın on katına bile harcamak bir seçenek değildir, ancak büyük olasılıkla, iki kopyanın çalışması talimatıyla birlikte, verimin sadece yarısını işleyebilecek bir günde oluşturulmuş bir program da değildir.

Eğer bunun bir yan dava olduğunu düşünüyorsanız yanılıyorsunuz; bu çoğu ev içi çalışanın günlük ortamıdır. Nedeni yatırım getirisi; bu ilk programın maliyeti fazla değildir ve bu nedenle çok hızlı bir şekilde ödeme yapar. Son kullanıcılar daha fazlasını yapmak veya daha hızlı gitmek için buna ihtiyaç duyduklarında, kod yeniden düzenlenebilir ve ölçeklendirilebilir.

Programlamanın mevcut durumunun arkasındaki ana sebep budur; bilgi işlem tarihinin tamamından doğan varsayım, bir programın ASLA statik olmadığıdır. Her zaman yükseltilmesi gerekecek ve sonunda değiştirilecektir. Buna paralel olarak, programların üzerinde çalıştığı bilgisayarların sürekli iyileştirilmesi, hem teorik verimliliğe daha az dikkat çekilmesini hem de ölçeklenebilirlik ve paralelleştirmeye (N-kare zamanında çalışan, ancak N çekirdeğinde çalışacak şekilde paralelleştirilebilen bir algoritma) artan ilgiyi sağlar. doğrusal görünür ve genellikle daha verimli bir çözüm tasarlamak için daha fazla donanım maliyeti geliştiricilerin maliyetinden daha ucuzdur).

Bunun da ötesinde, her geliştirici kodu satırının yanlış gidebilecek başka bir şey olduğu çok basit bir ilke vardır. Bir geliştirici ne kadar az yazarsa, yazdığı şeyin bir sorunu olması da o kadar az olasıdır. Bu kimsenin "hata oranına" yönelik bir eleştiri değildir; bu basit bir gerçektir. Bir MergeSort'u 5 dilde nasıl ileri ve geri yazacağınızı biliyor olabilirsiniz, ancak bir kod satırında sadece bir tanımlayıcıyı parmakla basarsanız, tüm Sıralama işe yaramaz ve derleyici onu yakalamazsa sizi alabilir hata ayıklamak için saat. List.Sort () ile bunu karşılaştırın; orada, genel durumda etkilidir ve işte en iyi şey, zaten çalışıyor.

Bu nedenle, modern platformların birçok özelliği ve modern tasarım yöntemlerinin ilkeleri, bu düşünülerek oluşturulmuştur:

  • OOP - bir nesneye ilgili verileri ve mantığı oluşturun ve bu nesne kavramının geçerli olduğu her yerde, böylece nesne veya daha özel bir türetme.
  • Önceden oluşturulmuş şablonlar - iyi bir% 60 veya daha fazla kod, sözdizimsel sarsıntı ve programın ekranda bir şey göstermesini sağlamanın temelidir. Bu kodu standartlaştırarak ve otomatik olarak oluşturarak geliştiricinin iş yükünü yarıya indirerek üretkenliğin artmasına izin verirsiniz.
  • Algoritmalar ve veri yapıları kütüphaneleri - Yukarıda belirtildiği gibi, bir Stack, Queue, QuickSort, vb.'nin nasıl yazılacağını biliyor olabilirsiniz, ancak tüm bunları içeren bir kod kütüphanesi olduğunda neden yapmanız gerekiyor? Bir web sitesine ihtiyaç duyduğunuz için IIS veya Apache'yi yeniden yazmazsınız, bu yüzden neden birkaç harika uygulama olduğunda bir QuickSort algoritması veya kırmızı-siyah ağaç nesnesi uygulayalım?
  • Akıcı arayüzler - Aynı satırlar boyunca, kayıtları filtreleyen ve sıralayan bir algoritmaya sahip olabilirsiniz. Hızlı, ama muhtemelen çok okunabilir değil; küçük geliştiricinizin, kayıt nesnesindeki ek bir alanda sıralamak için gereken cerrahi değişikliği yapmasına izin vermek yerine, onu anlamak için bir gün sürecektir. Bunun yerine, Linq gibi kütüphaneler, nesnelerin listesini filtrelenmiş, sıralanmış, yansıtılmış nesnelere dönüştürmek için çok çirkin, genellikle kırılgan bir kodun bir veya iki satır yapılandırılabilir yöntem çağrısı ile değiştirilir.

2
Güzel cevap, ama önemli bir noktayı kaçırıyorsunuz. "Çoğaltamayacağım, anlamıyorum." Nasıl çalıştıklarını bilmek, onları her proje için elle yazdığınız anlamına gelmez; daha ziyade, en iyisini seçmenize yardımcı olacak güçlü ve zayıf yönlerinin her birini bilmenizi sağlar. Ardından, bilmeniz gereken tek şey algoritmanın / veri yapısının standart kütüphanenizde olup olmadığıdır.
Michael K

Atasının yanlış olması dışında; Başarıyla çoğaltma umudum olmayan bazı maddi şeylerin arkasındaki kavramları çok net bir şekilde anlayabiliyorum. Prensipte katılıyorum; her türlü başarılı bir mühendis, işe yarayan çözümü seçmek için yeterli teoriyi bilmelidir. Bu, bir mühendisin her birinin özelliklerini bilmek ve böylece bir ev için doğru olanı seçmek için her tür ampulü inşa edebilmesi gerektiği anlamına gelmez. Benzer şekilde, kırmızı-siyah bir ağacı, performansını ve doğru uygulamasını anlayarak, sıfırdan nasıl uygulanacağına dair bir ipucu olmadan kullanabilirim.
KeithS

Mühendislikle benzetme iyi bir şey değildir. CS'deki "daha iyi bir köprü" mutlaka çok pahalıya mal değildir - bu genellikle hangi aracın doğru iş için uygun olduğunu anlamakla ilgilidir. Oldukça karmaşık bir ders kitabı algoritması uygulamak bile insanların rahatlık alanından oldukça uzaktır, ancak bu zor veya pahalı bir kavram değildir (kapsama bağlı olarak - ancak bunun insan-günlerde değil, insan-günlerde bir proje olduğunu varsayarsak). Genellikle daha da kolay - özel bir uygulama yok, sadece doğru aracı ve google için anahtar kelimeleri bilmekle ilgili bir soru.
Eamon Nerbonne

8

Bana öyle geliyor ki, CS değil BT yapıyorsunuz ve bu CS'nin öldüğü anlamına gelmemelidir. CS ölmedi, sadece çoğu iş Yazılım geliştirme aşamasında. Çoğu CS öğrencisi programlamayı öğrendiğinden, genellikle bir bilgisayar bilimcisi olarak değil, programcı olarak işe alınırlar. Bilgisayar Bilimi işleri programlama işlerine kıyasla çok küçüktür. Bilgisayar bilimi tekniklerini kullanarak karmaşık bir uygulama bile yapabilirsiniz, ancak bence (ve öznel-çünkü onlar görüş-cevaplarını sevmiyorum), bu bir bilim kampından daha mühendislik kampına düşüyor.

Ayrıca, güzel ve zarif kod bakanın gözündedir , ancak çoğu şirket / yönetici için, zamanında yeterince iyi bir tasarıma sahip olmak, güzel koddan çok daha önemlidir, ancak hiçbir zaman zamanında bitmez.

Son olarak, gerçek dünya ve lala-land vardır. Maalesef, maaş ödemesini öncekinden alıyoruz ve bu noktada yazılım geliştirmenin "bilim / sanatı", zaman / bütçe kısıtlamaları ile yüksek yazılım kalitesinin nasıl üretileceği konusunda devreye giriyor. Kariyerimin başlangıcında hissettiğin aynı hisleri hissettim. Her zaman "en iyiyi" yaratmak istedim, ama yakında "en iyinin" en verimli veya zarif değil, aynı zamanda en uygun maliyetli tasarım olduğunu anlıyorum.


3
"güzel ve zarif kod" vs "iyi enuogh, ama zamanında" yanlış bir ikilik. Tasarımınız basitse ve basit tasarım güzel tasarıma eşitse zamanında bitirmek daha kolaydır. Sadece, basit anlamına gelmez basit .
pillmuncher

1
@pillmuncher, Evet, kabul ediyorum, bana göre, güzel bir kod basit (ama daha basit değil) ama maalesef bu öncül öznel / göreceli. "Basit tasarım güzel tasarıma eşittir" bir iddia değil bir fikirdir (% 100 katılıyorum, ama yine de bir fikir). Fikir olmayan, program, gereksinimler ve maliyettir. Bu kısıtlamalar, verilen kısıtlamalar için yeterince iyi bir tasarıma yol açacaktır.
Armando

"[1] Bana öyle geliyor ki, CS değil BT yapıyorsunuz ve bu CS'nin öldüğü anlamına gelmemelidir. [2] CS ölmedi, sadece çoğu iş Yazılım geliştirme aşamasındadır". İlk ifadeniz doğrudur - OP CS'de değil BT'de. Ancak, "bilgisayar bilimcileri" olarak da adlandırılan pek çok yazılım dev. Buna "araştırma ve geliştirme" denir ve bir örnek, belirli ağ topolojileri üzerinde bir yönlendirme algoritmasının doğruluğunu tanımlayan, çözen ve ispatlayan, daha sonra "resmi" veya prototip uygulamasını uygulayan bilgisayar bilimcileri olabilir
Bill VB

8

Her şeyden önce, yanlış anladınız. "düşün, planla ve verimli bir şekilde çöz" sorunları bilim değil mühendisliktir. Bilim, yeni alanları keşfetmekten çok daha fazlasıdır. Aslında akademik dünyada insanlar kodun verimliliğine sektörden çok daha az önem veriyorlar. Akademide daha çok kavram kanıtı vb. İle ilgilidir.

Hayır, tanımladığınız şey, yazılım geliştirme için daha az derinlemesine bilgi gerekmesidir. Gereksinimler aynı olursa, bu doğru olabilir. Ancak günümüzde, yazılım mühendisinin çoklu iş parçacığı, dağıtılmış bilgi işlem, ölçekleme vb. İle nasıl başa çıkacağını bilmesi bekleniyor. Projenin verimli bir şekilde nasıl yönlendirileceğini bilmeleri bekleniyor. Bunların çoğu birkaç on yıl önce müfredatta hiç yoktu.


Hala burada okuduğumdan değil. Birçok okul mühendislik öğretmez, dil öğretir. Bu sadece bir inşaat mühendisliği öğrencisine Autocad öğretmek demek.
Michael K

@Michael: Bunu yapan iyi bir üniversite görmedim .
vartec

1
RIT'e gidiyorum. Yüksek ve hala oldukça berbat sırada. Hiçbir okul programlama hakkını öğretmez, çünkü diğer dersler bağlamında sadece dört ya da beş yıl içinde yapılamaz .
Jon Purdy

4

Söylediklerinin tam olarak doğru olduğunu düşünmüyorum, ama yine de önemli bir şeyin var . Özellikle, zamanla bilgisayar bilimi ve yazılım mühendisliği parçalandı.

Yazılım mühendisliği (diğer mühendislik gibi) hakkındadır uygulayarak inşa ürünlere bilimi, sorunları çözmek, vb Bilgisayar bilimi öncelikle algoritmalar içine araştırma ve hakkındadır (bu kısmı genellikle biraz unutulur rağmen) nasıl bazı teorik anlamda en az (bu algoritmaları uygulamak - örneğin, tüm PRAM makinelerine eşdeğer muamele edilmesi gibi).

Bunları akılda tutarak, bifurkasyonun arkasındaki nedenin belirginleştiğini düşünüyorum: tipik bir web sitesi gibi bir şeyde yer alan algoritmik sorunların çoğu zaten çözüldü - çoğu, uzun zaman önce. Belki daha da önemlisi, bunların çoğu, ortalama web geliştiricisi için sorunun neredeyse tamamen ortadan kalktığı kadar iyi çözülmüştür. Örneğin, dağıtılmış veritabanlarında atomik güncellemeler yapmak kesinlikle önemsiz bir görevdir - ancak tipik bir web geliştiricisi sadece bazı SQL yazar ve işi nasıl yapacağını anlamak için ne kadar araştırma yapıldığına dair hiçbir ipucu (veya bakım) yoktur. dependably.

Bir zamanlar bilgisayar bilimini yazılım mühendisliğinden ayırmak aslında imkansızdı. O kadar az sorun çözüldü ki nispeten önemsiz bir program bile yazmanın temelleri araştırmayı gerektiriyordu. Eğer 50'li yılların sonlarında veya 60'lı yılların başında bir grup veriyi sıralamak kadar basit bir şey yapmak istediyseniz, verilerinizin analizini yapmak ve tasarlamaya çalışmak gibi bir olasılıkla oldukça iyiydi. belirli bir veriyi sıralamak için gerekenlere uyan bir algoritma - bugün kadar çok sayıda sıralama algoritmasına yakın bir yerde bulunmadı ve bilinen algoritmalar bile bugün olduğu kadar iyi bilinmiyordu .

Yine de 50 yıllık araştırma ve geliştirme işe yaradı - çoğu tipik geliştirme sadece bilinen algoritmaları değil, önceden yazılmış uygulamaları da kullanabilir. En tipik problemler, mevcut algoritma bilgisine (ve hatta mevcut uygulamalara) dayanarak oldukça makul bir şekilde çözülebilir.

Bu bilgisayar biliminin öldüğü anlamına gelmez - araştırılacak daha fazla algoritma ve bunlarda araştırma yapan insanlar var. Bununla birlikte, araştırmanın çoğunun daha uzman olduğu ve sadece oldukça uzmanlaşmış alanlara uygulanması muhtemel olduğu anlamına gelir. Muhtemelen bilgiyi edinme ve uygulama arasında daha büyük bir "boşluk" vardır. Bir kerede, bir sıralama programı yazma sürecinde daha iyi bir sıralama yöntemi buldunuz ve hemen gerçek koda yazılmıştır. Şimdi bir çok bilgisayar bilimi, esasen sonsuz sayıda işlemcinin nasıl kullanılacağı gibi şeylere adanmıştır - ki bu muhtemelen bir gün yararlı olacaktır, ancak ilkel kabileler bile bilgisayarımdaki çift çekirdeği "çok" olarak saymazlar ... :-)


1

Yazılım geliştirme ve bilgisayar bilimi aynı şey değildir ve sınıf arkadaşlarımın çoğunun bir B.Sc. Comp Sci programı bundan bıkmıştı.

Yazılımı bilgisayar biliminin bir ürünü olarak düşünüyorum ... resimler gibi görsel sanatın bir ürünü.

CS derecesi olan çoğu insanın, özellikle kariyerlerinin erken aşamalarında, yazılım geliştirme yapmak için işe alındığını düşünüyorum. Bu roldeki birçok insanın orada kaldığını ve daha fazla gitmediğini düşünüyorum.

Bence yeni sorunlar ya da paradigmalar ortaya çıktığında ya da “onu tokatlamak” yeterince iyi olmadığında fark ortaya çıkmaya başlıyor. Yeni çerçeveleri veya dilleri kim oluşturur? Kim oturuyor ve yeni bir fizik motorunun detaylarını kırıyor? Kim bir teoriden performans yinelemesi başına birkaç döngü sıkıştırmak için grafik teorisi / grafik dönüşümlerini kullanır?

Başladığım yeri bitireceğim, yazılım geliştirme / mühendislik rollerinde çok fazla bilgisayar bilimcisi olduğunu, belki de potansiyellerini karşılamadığını kabul edeceğim.


1

Bilgisayar bilimini genel olarak programlama ve yazılım geliştirme ile karıştırıyorsunuz. İkisi aynı değil, hatta yakın değil. Derecelerimizin ne dediğine bakılmaksızın, çoğumuz bilgisayar bilimcileri değil programcıyız. Akademiye yüksek düzeyde aktif olarak katılmadığınız sürece, bilgisayar bilimlerinde neler olduğu hakkında gerçekten hiçbir fikriniz olmadığından emin olabilirsiniz.


0

Bilgisayar Bilimi'nin canlı ve iyi olduğunu söyleyebilirim. Sorunları günlük olarak çözmem ve bu sorunlara etkili ve zarif bir çözüm bulmam gerekiyor. Becerilerimi her gün mühendis olarak kullanmam ve bu sorunları müşterimiz için çözmek için kendimin ve meslektaşlarımın bilgisini kullanmalıyım.

Dillerden nefret etmeye çalışmıyorum, bir amaca hizmet ettiklerini ve iyi yaptıklarını anlıyorum, ancak çalışanlarınız bir karma tablonun nasıl çalıştığını bilmediğinde ve yanlış sıralama yöntemlerini kullandıklarında veya SQL komutlarını çalıştırdıklarında korkunç derecede verimsiz (ancak işi kabul edilebilir bir zamanda yapın), insanlara bir şeyleri nasıl doğru yapacaklarını öğretmekten ziyade yeni 'programcıları' kodlayan teknolojiler geliştirmek için daha fazla çaba harcanıyor gibi geliyor.

Bu, çalışanla ilgili bir sorun gibi görünüyor ve her programcı için kesinlikle doğru değil.

İşimizi kolaylaştıran araçların var olması, altı çizili teknolojiyi anlamamamız gerektiği anlamına gelmez, eğer kimseye yardım etmiyorsak ve kesinlikle sorunlarımızı doğru şekilde çözmek için işimizi yapmıyoruz.


Katılıyorum. Düşünmeye gerek olmayan işler olmadığını veya tüm geliştiricilerin ne yaptıklarını bilmediklerini söylemeye çalışmıyorum, ama sadece bir CS programından geldikten sonra size okulumun Bana şimdi bildiğim şeylerin yarısını öğret. Onları kendi başıma öğrendim. Ve şimdi onları tanıdığım için, bunu benim için yapan çerçeveler kullanabilirim. Ama eğer kendi başıma öğrenmemiş olsaydım, körü körüne çoğunlukla çoğunlukla yanlış bir çerçeve kullanırdım
Veaviticus

0

Sorunu henüz anlamadınız. Sorun maksimum performansı elde etmiyor - uygulamanızın yanıt verebilmesi ve yeterince hızlı olması için yeterli performans alıyor. Programlamayı öğrenmek, en az miktarda para için sorunu çözmekle ilgilidir.

Bunu bu şekilde ifade etmekten nefret ediyorum, ancak CS'nin ölümü hakkında edindiğiniz izlenimler, "gerçek" bir programcının ne yapması gerektiğine dair kendi ön fikirlerinizdir.


Sağ. İşletmelerin para kazanması gerektiğini biliyorum. Ve kesinlikle uygulamalarımın bir kısmını olabildiğince iyi olmak yerine 'yeterince hızlı' yapmaktan masum değilim. Bir çok genel olarak (en azından söyleyebileceğim kadarıyla) geliştiricilerin hiç CS çalışmadığı eğilimi daha çok merak ediyorum. Başka bir yerden sahaya girdiler ve arkasında çok az teori var ya da hiç gerçek teori yok, sadece çerçevelerle deneyim
Veaviticus

@Veaviticus: Bir çerçeveyi kullanmak çığır açan bir akademik teori olmayabilir, ama kesinlikle hala CS.
DeadMG

0

Ölü ya da değil tartışmalı!

Gerçek şu ki, günümüzün teknolojik döneminde çoğu şirket, yazılım otomasyonu yoluyla gerçek dünya iş akışı tipi görevleri çözmek için insanları işe alıyor. İşletmenin daha yüksek çıktı ile daha hızlı çalışmasına izin verdiği sürece, bir programın ne kadar zarif veya daha hızlı yazabileceğinizle ilgilenmezler.

Stres daha kısa sürede daha fazla çıktı üzerindedir. (Bitkilerin / gıdaların ticarileştirilmesini düşünün; daha az maliyetle daha hızlı ve daha fazla büyüme). Aynı şey teknoloji dünyasında da yaşanıyor (bir sonraki yeni fikir).

Unutmayın, bu gün ve yaşta, miktar ve bilgi erişimi nedeniyle günlere göre her zamankinden daha hızlı hareket ediyor. O eski günlerde, üretim küçük ve daha iyiydi, karlar daha yüksekti. Şimdi oyun tamamen değişti. Sadece müşteri hizmetlerinin kalitesi gibi şeylere bakın ve genel olarak daha uzun sürmez.

Google gibi teknoloji şirketleri için zarafet ve verimlilik önemlidir, ancak bu yerler bile mükemmel değildir, ancak önümüzdeki yıllarda bu şirketlerden birini çalışarak ona yaklaşabilirsiniz.

Hayatta her zaman bir değiş tokuş vardır. Daha az ödeyen, her zaman ve dikkatinizin olduğu bir iş bulabilirsiniz. Ya da, daha iyi ödeme yapmak ve mükemmel olmayan şeyleri görmezden gelmek için geri kalanımızla yüzmeyi seçersiniz. Bu gerçekleşme sizin için ne kadar hızlı batırılırsa, kendinizi gerçek dünyaya uygun hale getirebilirsiniz. Kaliteyi ve zarafeti görmezden gelmeniz gerektiğini söylemiyorum ama dinamikleri biliyorsunuz. Daha Mutlu Olacaksın :)


0

Bana göre geleceğin tutabileceği en ilginç şeylerden biri kesinlikle bilgisayar biliminin bilim kısmına, özellikle geliştirilmiş bilgisayar görme / makine öğrenmesine ve diğer sematize edici algoritmalara dayanacaktır. Bunlar muhtemelen endüstride ileriye doğru itilecek (örneğin, Microsoft Kinect'i ele alalım), ancak akademisyenlerde yapılan büyük araştırma ve ilerlemeye (yine Microsoft Kinect'i ele alalım) dayanacak kadar zor problemlerdir.


0

Bence standart günlük programlama, bir bilim kadar sanatla da ilgilidir, ancak kesinlikle bilgisayar biliminin bilim yönleriyle derinden ilgilenen alanlar vardır. Örneğin şirketler ve üniversiteler için araştırmacılar. Eğer gerçekten profesyonel bilimlere katılmak istiyorsanız o zaman bir doktora gerekir. Ancak, gerçekte daha yaratıcı yönüme güvenmeye ihtiyacım olmasına rağmen, eğitimimin bilim bölümlerinin sürekli olarak değerli olduğunu gördüm!

Ne yaptığını bilmeyen insanlar, bahsettiğiniz bazı araçlarla işleri hackleyebilirler, ancak genellikle araçları yapmak için gerçek CS insanlarını işe alırlar, kendinizi gerçekten zorlamak için daha soyut olmanız gerekir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.