Czy nadmierne poleganie na narzędziach oznacza, że ​​jesteś leniwy? [Zamknięte]

29

Zacząłem programować w C ++ na uni i bardzo mi się podobało. W następnym semestrze zmieniliśmy na VB6 i nienawidziłem tego.

Nie mogłem powiedzieć, co się dzieje, przeciągasz przycisk do formularza, a ide pisze kod dla Ciebie.

Chociaż nienawidziłem sposobu działania VB, nie mogę argumentować, że było to szybsze i łatwiejsze niż robienie tego samego w C ++, więc mogę zrozumieć, dlaczego jest to popularny język.

Teraz nie nazywam programistów VB leniwymi mówiąc, że jest to łatwiejsze niż C ++ i zauważyłem, że wiele nowszych języków podąża za tym trendem, np. C #.

To prowadzi mnie do myślenia, że ​​im więcej firm chce szybkich rezultatów, tym więcej ludzi będzie tak programować i prędzej czy później nie będzie czegoś takiego, jak to, co teraz nazywamy programowaniem. Przyszli programiści powiedzą komputerowi, czego chcą, a kompilator napisze dla nich program jak w star trek.

Czy to tylko niedoinformowana opinia młodszego programisty, czy programiści stają się bardziej leniwi i mniej kompetentni?

EDYCJA: Wiele odpowiedzi mówi, dlaczego wymyśliłem koło, a ja się z tym zgadzam, ale kiedy są dostępne koła, ludzie nie zadają sobie trudu, aby dowiedzieć się, jak zrobić koło. Mogę google, jak zrobić prawie wszystko w dowolnym języku, a połowa języków robi tyle dla ciebie, jeśli chodzi o debugowanie, nie mają pojęcia, co robi kod, jak naprawić błąd.

W ten sposób zgadzam się z teorią, że programiści stają się leniwi i mniej kompetentni, ponieważ nikt nie dba o to, jak działają rzeczy, tak jak się dzieje, dopóki tak się nie stanie.

Skeith
źródło
7
„Czy to tylko niedoinformowana opinia młodszego programisty, czy programiści stają się bardziej leniwi i mniej kompetentni?” - to nie jest jedno lub oba są prawdziwe (tylko nie z powodów, które mówisz).
Jon Hopkins,
15
Jak ktokolwiek może odpowiedzieć na to pytanie, nie obalając tytułu?
Komentatorzy: komentarze mają na celu poszukiwanie wyjaśnień, a nie dłuższą dyskusję. Jeśli masz rozwiązanie, zostaw odpowiedź. Jeśli Twoje rozwiązanie jest już opublikowane, głosuj za nim. Jeśli chcesz omówić to pytanie z innymi, skorzystaj z czatu . Aby uzyskać więcej informacji, zobacz często zadawane pytania .
8
Dlaczego nie zostało to zamknięte jako „subiektywne i kłótliwe” ...?
BlueRaja - Danny Pflughoeft

Odpowiedzi:

103

Nie, programiści nie są bardziej leniwi ani mniej kompetentni. Tak, stale maleje potrzeba rzeczywistego rozwoju w takim sensie, że go znasz. I tak, dzieje się tak bardzo, ponieważ firmy chcą szybkich rezultatów, a dlaczego nie?

Jest jednak punkt końcowy. Niektórzy programiści zawsze będą potrzebować.

Wiele wymagań jest takich samych dla różnych projektów. Ten, o którym mówisz, to kod interfejsu użytkownika. Większość interfejsów użytkownika składa się z określonego zestawu pól - pole tekstowe, pole wyboru, radio, wybór itp. - i naprawdę nie ma sensu opracowywać ich od podstaw, w kółko. Tak więc wstawiane są warstwy abstrakcji, aby zabrać cały ten kod.

Podobnie warstwa danych, która zwykle jest niczym innym jak Wstaw to, Usuń to, Zamień to i wiele różnych widoków tych samych danych. Po co ciągle to pisać? Wymyślmy ORM.

Jedyną rzeczą, którą powinieneś rozwijać, jest kod, który jest unikalny dla firmy, dla której się rozwijasz.

Ale zawsze będzie ta wyjątkowość - tam, gdzie jej nie ma, jest okazja biznesowa - i zawsze będzie potrzeba pisania kodu.

To powiedziawszy, pamiętaj również, że bycie programistą to coś więcej niż pisanie kodu. Niezależnie od tego, czy kodujesz w czystym zespole, czy łączysz komponenty Drupal, aby stworzyć witrynę opartą na treści, przekładasz potrzeby biznesowe na coś, co rozumie komputer.

Najważniejszą częścią bycia programistą jest umiejętne zrozumienie wymagań biznesowych wystarczająco dobrze, aby wyjaśnić to komputerowi.

Tak naprawdę nie ma znaczenia, jakiego języka używasz do wyjaśniania rzeczy na komputerze, liczy się tylko to, co możesz. I to jest ciężka praca, nic leniwego.

pdr
źródło
3
Istnieje różnica między byciem programistą a programistą.
Raynos
9
+1. Dokładnie. Za działające oprogramowanie płaci się. Kod jest środkiem do tworzenia oprogramowania, artefaktu. Czyste „programowanie” to łatwa i przyjemna część tworzenia oprogramowania.
Joonas Pulakka
+1 za całość. Nie jestem pewien, czy mam „jedyną rzeczą, którą powinieneś rozwijać, jest kod, który jest unikalny dla biznesu, dla którego rozwijasz”. Przyznaję jednak, że jest to ważna strategia biznesowa.
SoylentGray
@Chad - Weź swój punkt. Czasami mówię hiperbolą. Jeśli chodzi o kryzys, zdrowy rozsądek zawsze przeważa nad filozofią, ale myślę, że lepiej jest rozmawiać z poszczególnymi przypadkami, niż przyjmować domyślne stanowisko „tak, napiszmy to sami”. :)
pdr
Jako firma najważniejsze pytanie brzmi, jaki jest zwrot z inwestycji w czas poświęcony na opracowanie rozwiązania. Mój szef wcale nie dba o język, w którym się rozwijam, o ile mogę pomóc firmie zarobić więcej pieniędzy niż mi płacą. Coś jeszcze i oni tracą pieniądze na mnie.
Dan Williams
38

Czy mechanik jest leniwy i mniej kompetentny, ponieważ używa klucza hydraulicznego ?

Wyobraźcie sobie dwóch facetów, powiedzmy Brad i Pete. Obaj pracują codziennie w dwóch garażach, zmieniając opony. Brad jest mądrym facetem, wie, że dzięki lepszym narzędziom jego praca może być wykonywana lepiej i szybciej. Użycie klucza hydraulicznego pomaga mu zmienić więcej opon. Klienci czekają w krótszej kolejce - wszyscy są zadowoleni. Bard wie również, że ten klucz jest czasem zbyt duży i nie może mu pomóc przy użyciu różnego rodzaju śrub.

Z drugiej strony Pete twierdzi, że klucz hydrauliczny jest bluźnierstwem, a Brad nie jest „prawdziwym mechanikiem”. Pewnie Pete może zrobić tylko połowę tego, co robi Brad, ale robi to „we właściwy sposób”.

Co teraz myślisz, który klient garażu wybrałby? Taki, który zajmuje 20 minut lub jeden z 40 minutami oczekiwania.

Podobnie jest z programowaniem. C ++ jest dobrym językiem i ma swój cel (głównie wydajność). W językach takich jak C # podoba mi się to, że mogę skupić się na problemie, myśleć o algorytmie bez hałasu, jaki robi C ++, jak niejednoznaczne ostrzeżenia kompilatora, niezdefiniowane zachowania i tak dalej. Rozwój staje się coraz bardziej skomplikowany, że w dawnych czasach komputerów mainframe i pierwszych komputerów PC mózg ludzki pozostał taki sam - prawie głupi. Jedna aplikacja może działać w chmurze, telefonie komórkowym i komputerze, istnieje wiele zależności, problemów bezpieczeństwa i innych problemów. Chcę mieć lepsze narzędzie do koncentrowania się na bardziej skomplikowanych problemach i ich rozwiązywania.

Użyj lepszych narzędzi do wykonania pracy - nie ma w tym nic złego.

Łukasz
źródło
1
Nie sądzę, że analogia działa, ponieważ zarówno Brad, jak i Pete nadal będą wiedzieli, jak zdjąć oponę i wszystko, co się z tym wiąże (klucze, klucze i piwo).
Kristofer Hoch
3
+1 świetna odpowiedź. Dodałbym, że bez względu na to, jakiego narzędzia użyjesz, jeśli zrozumiesz, co to robi, dobrze wykonasz swoją pracę. Z drugiej strony, jeśli tego nie zrobisz, nie ma znaczenia, ile pracy wykonuje narzędzie, w pewnym momencie będziesz coś pieprzyć.
Jacek Prucia
1
@Kristofer: Może lepiej byłoby, gdyby Pete znał elektronikę. Podczas gdy Brad wie tylko, jak korzystać z komputera diagnostycznego i odczytywać, że czujnik O2 zepsuł się, Pete widzi, że drut czujnika jest nieco spalony, wyciąga miernik, aby go zmierzyć, i zdaje sobie sprawę, że regulator napięcia się zakręcił i jest wypalanie czujników O2.
Zan Lynx
@Zan to nie to samo. @Kristofer tylko dlatego, że używam projektanta do szybkiego przeciągania elementów sterujących do elementu formularza i wykonania kodu z podstawowymi kodami, nie oznacza, że ​​nie wiem, jak zmienić ten kod, aby zrobić to, co chcę później.
jcolebrand
Idealny sposób na wyrażenie tego.
riwalk
37

Co teraz nazywamy programowaniem

Mówisz:

Przyszli programiści powiedzą komputerowi, czego chcą, a kompilator napisze dla nich program jak w star trek.

po prostu zrób eksperyment: obejrzyj star trek i spróbuj zinterpretować rzeczy, które komputer nakazuje zrobić trochę „bez wdzięku”.

  • Herbata, Earl Grey, gorąca -> dużo pary.
  • Herbata, Earl Grey, 60 stopni Celsjusza -> kałuża i chmura pary
  • Earl Grey, 60 stopni Celsjusza -> kałuża
  • Earl Grey, 60 stopni Celsjusza, w filiżance -> kubek z kroplą
  • Earl Grey, 60 stopni Celsjusza, 0,2 litra, w filiżance. -> wreszcie (ok, możesz nitpick więcej)

Kiedy wywołujesz Programowanie: „Wiedza na temat użycia pamięci, wskaźników itp.”, Tak, myślę, że stanie się to mniej ważne (ponieważ „Wiedza na temat http, openid, Unicode” stanie się ważniejsza).

Ale moim zdaniem wszystko to „przypadkowa złożoność”, a prawdziwym Hiobem jako programistą jest „sprawienie, by maszyny kompilacyjne rozwiązywały problemy, upewniając się, że rozumie się wystarczająco dużo przypadkowych problemów, aby zrealizować zadanie”, a zgodnie z tą definicją ktoś rozmawia z komputerem star trek musi być programistą (tzn. mieć te same zalety, co teraz).

keppla
źródło
2
@Raynos: soooo true. Szczególnie przygnębiające, gdy ci ludzie są liderami zespołów i tworzą wytyczne, takie jak „gdy dane do wysłania są mniejsze niż X bajtów, użyj GET, gdy więcej, użyj POST”
keppla
8
@keppla - Twój problem nie polega na tym, że lider zespołu nie rozumiał HTTP, ale dlatego, że nie chciał zmienić swojej opinii w świetle dowodów, że się mylił (zakładając, że próbowałeś mu wyjaśnić różne rzeczy). Nie możesz wiedzieć więcej niż wszyscy, którzy pracują dla Ciebie o wszystkim - prawdziwym przestępstwem jest nieakceptowanie faktu, że ktoś inny wie o czymś więcej niż ty.
Jon Hopkins
3
„Tea, Earl Grey, Hot” to deklaratywne programowanie. Zadaniem komputera jest znalezienie kontekstowego wyniku opartego na rozsądnych oczekiwaniach. Wytwarzanie pary z „gorącej herbaty” w tego rodzaju języku byłoby błędem części zespołu projektantów komputera, a nie programisty. Powinien używać kontekstu odpowiedniego przypadku, chyba że zostanie wprowadzone określone zapytanie.
diadem
1
@Diadem: nawet jeśli jest deklaratywny, musisz wiedzieć, co zadeklarować, a jako programista, imho, nie spodziewałbyś się, że komputer może zgadywać z przeszłości, co zrobisz dalej, ponieważ zrobisz coś nowego. Interfejs, który interpretuje Twoje życzenia, jest przeznaczony dla użytkowników końcowych.
keppla
2
@Zan Lynx: Może lepszy przykład: niech komputer ostrzega cię za każdym razem, gdy ktoś zostanie uprowadzony (komputer nie przejmuje się tym w TNG). „Komputer: poinformuj mnie, gdy ktoś zostanie uprowadzony” „Proszę zdefiniować uprowadzonego” „Kiedy zostanie on zabrany wbrew swojej woli” „Proszę zdefiniować wolę” itp. Aby znaleźć rozwiązanie takie jak „Poinformuj odpowiedzialnego oficera, gdy ktoś zmieni lokalizację od znanego do nieznanego, i nie ma logu, że oficer transportowy odesłał go lub wszedł na prom, a statku nie ma w doku. wciąż potrzebujesz nastawienia programistów.
keppla
23

Programiści nie stają się leniwi. Programiści zawsze byli leniwi. Bycie leniwym jest częścią fundamentalnej natury pracy. Problem polega na tym, że ludzie zakładają, że lenistwo jest negatywne. Bycie „leniwym” programistą jest zaletą.

Pamiętaj o starym przysłowie: „Pracuj mądrzej, a nie ciężej”. To podstawowa siła programistów.

Faceci, którzy zbudowali i zaprogramowali pierwsze komputery, nie zrobili tego, ponieważ lubili ciężką pracę, zrobili to, aby UNIKNĄĆ jeszcze cięższej pracy. (robienie stron obliczeń ręcznie)

Bycie „leniwym” jest jednym z podstawowych powodów, dla których programiści programują. Dlatego piszemy nowe i coraz wyższe języki, coraz lepsze debuggery i IDE, powłoki i skrypty, itp.

Programista patrzy na problem, wszystko, co robi i myśli;

„czy mogę to zautomatyzować?” , „ile czasu to zajmie?” , „ile czasu to by mnie uratowało?”

Robimy to, ponieważ jesteśmy leniwi, nie chcemy wykonywać powtarzalnych i nudnych zadań, gdy moglibyśmy robić rzeczy, które są znacznie przyjemniejsze.

Gdyby programiści nie byli leniwi, żaden programista nigdy nie zauważyłby potrzeby napisania jednego nowego języka lub kompilatora.

Jeśli chodzi o przekonanie, że programista jest „leniwy”, ponieważ musi „sprawdzić”, to co, kogo to obchodzi. Założenie, że nauczenie się każdego niuansu danego języka (i nigdy nie trzeba czegoś szukać), wymaga więcej pracy, niż znalezienie i użycie tego, czego potrzebujesz, gdy jest to potrzebne, jest błędem. Poza tym proces wyszukiwania rzeczy to proces uczenia się i to właśnie dlatego istnieją takie strony.

Jeśli ktoś chce ciężkiej pracy programistycznej, powiedziałbym mu, żeby poszedł do kodu szesnastkowego surowego kodu maszynowego. Skończone? Chcesz czegoś trudniejszego? Teraz przejdź do debugowania.

Justin Ohms
źródło
19

Przede wszystkim dzwonienie do ludzi, którzy używają na przykład języków z leniwym śmieciarzem, jest rodzajem dzwonienia do ludzi, którzy prowadzą samochody z automatyczną skrzynią biegów. IMO to trochę śmieszne.

Jeśli chodzi o kompetencje, programowanie jest znacznie bardziej popularną i egalitarną pracą niż kiedyś. Tak, jest wielu przybyszów, którym brakuje wiedzy. Nie chodzi mi jednak o to, że nagle są mniej kompetentni programiści. W rzeczywistości jest ich więcej. Patrzysz tylko na niewłaściwą stronę krzywej dzwonowej.

vartec
źródło
11
Ludzie, którzy prowadzą samochody są leniwi, nie ma w tym nic śmiesznego. Podręcznik z piętą i palcami daje znacznie większą kontrolę i wydajność poza samochodem, ale wymaga dużo umiejętności i dodatkowej pracy.
Koder
11
@Coder: „wymaga dodatkowej pracy” - na autostradzie nie, w korku tak, ale i tak nie daje żadnej przewagi.
vartec
2
Ręczne skrzynie biegów zapewniają również lepszą oszczędność paliwa na autostradzie, choć jest to mniej prawdziwe w przypadku blokowanych przemienników momentu obrotowego.
Dave Markle
4
@Dave w rzeczywistości nowoczesna elektronika sprawiła, że ​​automat był rzeczywiście bardziej wydajny. Mój Ford Fusion z tymi samymi opcjami został oceniony prawie o pełną milę na galon mniej. Jestem pewien, że są chwile, w których instrukcja jest jeszcze lepsza w mikro, ale przede wszystkim automat ma przewagę.
SoylentGray
3
@ Koder - Jeśli uważasz, że prowadzenie instrukcji wymaga „dużej umiejętności”, musisz rozejrzeć się po tysiącach niekompetentnych kierowców na drodze z ręcznymi skrzyniami biegów. ;)
techie007
15

Kusi mnie, by powiedzieć: „tak, niedoinformowani młodsi programiści stali się leniwi i mniej kompetentni”, ale spróbujmy na poważną odpowiedź:

Wiele rzeczy stało się łatwiejszych, ale oczekuje się od nas więcej. Obecnie tworzę aplikację internetową, która ma wiele funkcji zwykle spotykanych w dobrze wykonanych aplikacjach GUI (widoki z kartami, edytowalne i sortowalne siatki, eksport do Excela itp.). Narzędzia, których używam (ExtJS itp.) Sprawiają, że tworzenie takiej aplikacji jest stosunkowo niedrogie.

Dziesięć lat temu stworzenie takiej aplikacji byłoby prawie niemożliwe, a przynajmniej bardzo kosztowne. Ale dziesięć lat temu prosty formularz HTML z tabelą HTML byłby wystarczający dla klientów. Dzisiaj, przy takim samym wysiłku, możliwe są lepsze (przynajmniej piękniejsze) wyniki, a klienci oczekują ich!

Ogólnie rzecz biorąc, dzisiejszy programista musi znać więcej języków niż programista 20 lat temu. Wtedy wystarczało coś takiego jak C i SQL. Dzisiaj używam JavaScript, HTML, Groovy, Java, SQL - wszystko w tym samym projekcie.

281377
źródło
+1 tak, niedoinformowani młodsi programiści stali się leniwi i mniej kompetentni
SoylentGray
12

Programiści stają się pod pewnymi względami mniej kompetentni i leniwi, ale pod innymi są bardziej kompetentni, chociaż podział C ++ / VB nie jest moim zdaniem powodem ani objawem.

Korzystanie z konstruktora GUI nie jest leniwe, jest po prostu inne, dotyczy narzędzi do danego zadania. Jeśli programista asemblera nazywa się leniwym programistą C ++, nazwałbyś to bzdurami (słusznie) i to samo dotyczy C ++ i VB. VB pozwala szybko robić pewne rzeczy kosztem pewnej kontroli. Bariery w rozpoczęciu kodowania są z pewnością niższe, ale to coś zupełnie innego niż lenistwo - po prostu uczysz się różnych rzeczy i stosujesz je na różne sposoby. Programiści VB nie są bardziej leniwi niż programiści C ++ są nieproduktywni, po prostu pracują i produkują na różne sposoby.

Ogólnie rzecz biorąc, edukacja programistów jest teraz lepsza niż kiedykolwiek wcześniej. Pomysł, by na przykład nie używać kontroli źródła, jest bardzo odrażający dla prawie wszystkich, którzy 10 lub 20 lat temu nie byłyby tak prawdziwe. Podobnie są bardziej skłonni do zrozumienia i chcą korzystać z automatycznych testów jednostkowych, ciągłej integracji i tak dalej, więc w tym sensie są bardziej kompetentni niż byli.

Ale myślę, że zmieniło się to, że ludzie nie wiedzą już, jak rozwiązywać problemy w sposób, w jaki kiedyś to robili, i dotyczy to praktycznie każdego głównego nurtu. Natychmiastową odpowiedzią na każdy problem jest teraz Google i chociaż jest to świetne i działa w 95% przypadków, widzę zbyt wielu programistów, którzy nie mają pojęcia, co zrobić, gdy nie.

Nie chodzi o to, że nie rozumieją podstaw (nie rozumieją, ale to nie jest tak naprawdę wielka sprawa), tylko dlatego, że nie potrafią rozwiązywać problemów w taki sposób, że mogą nawet ustalić, jakie podstawy potrzebują zmierzyć się z.

Przed Google nie miałeś wyboru. Twoimi zasobami był twój zespół, kilkadziesiąt fizycznych książek, do których możesz mieć dostęp, i twój mózg. Ta konfiguracja oznacza, że ​​jeśli znajdziesz problem, prawdopodobnie rozwiązujesz go samodzielnie z czegoś bliskiego pierwszemu zleceniodawcy, więc albo dobrze sobie z tym poradzisz, albo szybko jesteś bezrobotny.

I tak było niezależnie od tego, jakiego języka użyłeś. VB jest na wysokim poziomie i dużo ukrywa, ale oznacza to, że w przypadku rozwiązywania problemów oznaczało to, że trzeba było więcej pracować. Jeśli coś nie zadziałało, musiałeś być bardziej kreatywny i pracować ciężej, ponieważ miałeś mniejszą kontrolę. Jako programista VB (i mówię z doświadczenia) nie znałeś mniej niż facetów z C ++, po prostu wiedziałeś różne rzeczy, ale obaj wiedzieliście, jak rozwiązywać problemy.

Ale prawdopodobnie ciężko jest postrzegać to jako poważną krytykę programistów, którzy nie rozwijają umiejętności, ponieważ ich nie potrzebują, ale jest to słabość w porównaniu do tych, którzy podnieśli umiejętności od momentu, gdy były potrzebne.

Jon Hopkins
źródło
więc kiedy nikt nie wie, co to jest algorytm ani jak zaimplementować strukturę danych, ponieważ wszystkie one „programują” w przeciąganiu i upuszczaniu IDE, czy po prostu używają odpowiedniego narzędzia do zadania?
Skeith,
@Skeith - Zależy od zadania, ale jeśli produkuje oprogramowanie, które rozwiązuje problem, to tak.
Jon Hopkins,
1
@ Jon-Hopkins, powiedziałbym, że ogromny rozwój programowania zależnego od Google ma związek z ogromną liczbą interfejsów API, których potrzebujemy obecnie. Zbyt trudno jest to wszystko śledzić. (Ale w zasadzie masz rację)
Jarrod Nettles
1
@Skeith - Budowanie interfejsu użytkownika zajmuje około 5% średniego czasu twórców aplikacji. Jak myślisz, co robią pozostałe 95%? Projektant niewiele pomaga w kodzie zaplecza. Wyraźnie atakujesz słomianego mężczyznę. Większość ludzi zna narzędzia, których potrzebują do swojej pracy, inaczej nie byliby zatrudnieni.
Morgan Herlocker
@Skeith: Czy użytkownik bazy danych musi dbać o to, jak zaimplementować bazę danych? Oczywiście nie; użytkownik bazy danych z niego korzysta . Mogą znać niektóre szczegóły, tak aby mogli zoptymalizować swoje bazy danych, ale nie powinny mieć , aby móc wykorzystać je w celu być godnym jej używania. Ponadto programista może nie wiedzieć, co znaczy słowo „algorytm”, ale to nie znaczy, że go nie piszą . Opracowywałem i wdrażałem algorytmy na długo zanim jeszcze usłyszałem ten termin.
Nicol Bolas
11

Z Twojego profilu wynika, że ​​masz 23 lata. Pozwól mi włożyć zęby i dać ci perspektywę od kogoś w wieku około dwóch lat, który robi to od bardzo dawna:

Kiedyś było wszystkiego o wiele mniej, począwszy od mocy obliczeniowej, pamięci i przepustowości sieci, jeśli w ogóle istniała sieć. Niedobory te ograniczają to, co można rozsądnie zrobić, znacznie ułatwiając owijanie głowy wokół wszystkiego. Oprogramowanie, które dziś uruchamiamy, jest znacznie bardziej wydajne niż rzeczy, z którymi pracowałem 25 lub 30 lat temu, a te możliwości oznaczają, że jest ich o wiele więcej. To sprawia, że ​​zebranie dokładnego zrozumienia wszystkiego jest o wiele trudniejsze dla jednej osoby. Częściowo ma to związek z faktem, że sprawy będą się coraz bardziej komplikować, a częściowo z efektami ubocznymi starzenia się.

Ekosystem komputerowy staje się bardzo podobny do systemów biologicznych: ludzie są bardziej złożeni niż organizmy jednokomórkowe, a niektóre z nas muszą się specjalizować, jeśli chcemy osiągnąć dobre wyniki. Moje komórki mózgowe są okropnie dobre w mądrych rzeczach, ale zostałyby utracone, gdyby wbiły się w moją nerkę i spodziewały się robić nerkowe czynności. Podobnie facet, który jest dobry w pisaniu cyfrowych procesorów sygnałowych, może nie mieć pojęcia, jak działa indeksowanie pełnotekstowe, ponieważ to nie jest jego specjalność. Ale oba mogą nieco ewoluować i nauczyć się je rozumieć, jeśli zajdzie taka potrzeba, ale istnieją granice tego, jak daleko możesz się rozprzestrzeniać i nadal być skutecznym w tym, co robisz.

... nikogo nie obchodzi, jak rzeczy działają tak, jak to działa, dopóki tak się nie stanie.

Kiedy masz zadanie do wykonania, często musisz zrobić skok wiary, że używane narzędzie (biblioteka, RDBMS, cały podsystem itp.) Działa tak, jak powinno. Jedną z rzeczy, które przynosi doświadczenie, jest możliwość wybrania, które królicze dziury będziesz zbierać, aby wyeliminować awarie narzędzi, naprawić problem, a następnie wrócić do tego, co robiłeś.

Teraz nie nazywam programistów VB leniwymi mówiąc, że jest to łatwiejsze niż C ++ i zauważyłem, że wiele nowszych języków podąża za tym trendem, np. C #.

To wszystko kwestia perspektywy. Byłem w pobliżu, aby zobaczyć, jak powstaje C ++, i podąża za tym trendem. C ++ sprawia, że ​​rzeczy są o wiele łatwiejsze niż C, C sprawia, że ​​jest to o wiele łatwiejsze niż asemblowanie, a asemblowanie znacznie ułatwia niż ręczne pisanie kodów. Jako ktoś, kto napisał dużo asemblera i złożył kilka rzeczy od zera, to jako programista C ++ postawiło cię trzy kroki na ścieżce „łatwiej”.

Blrfl
źródło
1
+1 wskazując, że to kwestia perspektywy. Byłem w pobliżu, kiedy UNIX po raz pierwszy wyszedł z Bell Labs i było sporo „tsk tsk”, że języki wysokiego poziomu, takie jak „C”, głuszyły starożytną i ezoteryczną sztukę pisania systemów operacyjnych, a to z pewnością doprowadziłoby do nie dobrze. Ponieważ nasze narzędzia stają się coraz lepsze i zajmujemy się bardziej bezmyślną księgowością, możemy wykorzystać zaoszczędzony czas na trudniejsze i bardziej subtelne problemy.
Charles E. Grant
6

Coś, co utrzymuję od dłuższego czasu, to:

Jedną z największych zalet języka Visual Basic jest to, że początkujący może nauczyć się robić wiele przydatnych rzeczy dość szybko.

Jedną z największych słabości programistów Visual Basic jest to, że nauczą się dość szybko robić wiele przydatnych rzeczy, a potem przestaną się uczyć.

Kiedy uczyłem programowania pierwszego ćwiczenia, pierwszym dniem zajęć było zbudowanie aplikacji w NOTEPAD i skompilowanie jej za pomocą VCC lub VBC. Tak, to są rzeczy, których my (jako programiści) nie robimy na co dzień, ale powinniśmy zrozumieć, co się dzieje, gdy naciskamy „F6”.

Programiści (ogólnie) nie stają się bardziej „leniwi”, niż się spodziewamy, aby uzyskać więcej z naszych narzędzi. Nie muszę wpisywać „get / set” 10 000 razy dziennie, LUBIĘ, że Visual Studio i inne narzędzia, takie jak Code Smith i Resharper, pracują dla mnie, aby zrobić to, co już wiem, jak to zrobić, dzięki czemu mogę włożyć wysiłek w ustalenie jak robić „nowe” rzeczy. Nie czyni mnie to bardziej leniwym, co czyni mnie „innowacyjnym”.

Jako profesjonalny programista nie powinniśmy „marnować czasu” na wynalezienie koła, ale powinniśmy jasno zrozumieć, co składa się na tworzenie koła, którego będziemy używać. Są to rzeczy, których powinniśmy się nauczyć jako studenci (ale niestety często nie są). Jeśli programista nie rozumie niektórych „czarnych skrzynek”, robi to naprawdę mniej „kompetentnymi”. Większość programistów „tylko rozumie”, jak działa sterownik ODBC, po prostu rozumie „co” robi. Czy muszę wiedzieć, jak działa przekładnia, aby być kompetentnym kierowcą? Powiedziałbym, że nie. Czy to sprawia, że ​​jestem bardziej kompetentnym właścicielem samochodu, żeby to wiedzieć, tak.

Cos Callis
źródło
4

Potrzeba szybkiego tworzenia aplikacji (obowiązkowy link wiki: http://en.wikipedia.org/wiki/Rapid_application_development ) oznaczała, że ​​programiści piszą mniej kodu, a nowi programiści mniej rozumieją, ponieważ nie muszą rozumieć, jak zaimplementować połączona lista, ponieważ mają na czymś wyższy poziom, na którym można się skupić.

Nie mogę złapać, zabić, skóry, rzeźnika i leczyć mięsa, i wątpię, czy facet w kawiarni na dole może, ale wciąż otrzymuję od niego kanapkę z boczkiem, podobnie jak biznesmeni dostają swoje aplikacje od programistów, którzy nie wiedzą o wskaźniki (jak ja!)

StuperUser
źródło
4

Mówiono, że wielkie dyscypliny naukowe są przykładami gigantów stojących na ramionach innych gigantów. Mówiono również, że przemysł oprogramowania jest przykładem karłów stojących na palcach innych karłów.
- Alan Cooper

Dobry programista nie jest tym, który odświeża koło. Potrafi korzystać z narzędzi, które zostały zbudowane przed nim. Nie marnuje czasu na przepisywanie tych samych starych nudnych rzeczy, które zostały napisane setki razy, szybko się męczy i prawdopodobnie istnieje już w wyższej jakości wersji.
Jeśli dasz im język, w którym są już okrągłe kamienne dyski, są spore szanse, że nie spędzą zbyt wiele czasu na wymyślaniu nowych kół. Gdybym dostał cent za każdą procedurę kopiowania napisów napisaną w C, prawdopodobnie kupiłbym cały przemysł oprogramowania.

Lenistwo jest w rzeczywistości jedną z trzech wielkich zalet programisty. Narzędzia, o których mówisz, zostały zbudowane przez dobrych programistów dla dobrych programistów, aby zmniejszyć nadmiarowość i nudę, a tym samym zwiększyć wydajność i motywację. Takie narzędzia mogą w rzeczywistości mieć negatywny wpływ na początkujących, ponieważ hamują głębsze zrozumienie uproszczonego aspektu programowania.

back2dos
źródło
4

Nie. Po prostu się starzejesz.

Nie żartujesz, to, co doświadczasz, jest rodzajem prawa przejścia dla programistów. Od tamtej pory pierwsze języki wyższego poziomu wyparły asembler. Wtedy słyszeliście, jak wszyscy programiści ASM narzekają na to samo. Za 5 lat wszyscy twórcy Ruby on Rails będą narzekać na to, jak leniwy jest kolejny zbiór nowych narzędzi, który sprawia, że ​​ludzie.

Refren będzie powtarzany, dopóki maszyny nie zniszczą nas wszystkich: „Czy wydaje się, że technologia X powoduje, że programiści są leniwi i gorzej niż technologia Z, z której zawsze korzystałem?”

Dobra wiadomość jest taka, że ​​mimo że kompilatory przeszły długą drogę, ludzie wciąż potrzebują montażu i C oraz wszystkich innych starych elementów wielu rzeczy ... po prostu nie większość nowatorskich technologii. Jeśli chcesz być w czołówce, proponuję zaktualizować swój zestaw umiejętności.

DougW
źródło
+1: „Te leniwe dzieciaki dzisiaj ze swoimi rydwanami, łukami i strzałami. Kiedy byłem chłopcem, stoczyliśmy nasze bitwy krótkimi mieczami i szliśmy na pole bitwy iz powrotem. I było pod górę.” - Kserkses I, Cesarz Persji, 473 rpne
Bob Murphy
3

Z mojego doświadczenia wynika, że ​​tak i nie, ale to nie wina języków; to wina samych programistów. Współpracowałem z wieloma programistami, którzy nie dbali o robienie rzeczy we właściwy sposób, doskonalenie się, lub naprawdę robienie czegokolwiek innego niż wyrzucenie tego samego badziewia, który robili od lat. Próbowanie nakłonienia tych ludzi do poprawy jest jak rozmowa z murem - w połowie przypadków nie są oni świadomi niczego, z czego nie korzystali w przeszłości lub zupełnie nie chcą „zaryzykować” z czymś, co mogłoby poprawić ich wydajność .

Bardziej zaawansowane języki nie stanowią problemu, to programiści nie traktują tego zawodu jako ciągle rozwijającego się rzemiosła. Nie musisz być całkowicie świadomy wszystkiego, co nowe, ani wskakiwać na każdy nowy modowy wóz, ale powinieneś przynajmniej spróbować stać się lepszym w tym, co robisz.

Konkretny przykład: jestem programistą .NET z zawodu. Oczekiwałbym, że kompetentny programista .NET będzie wiedział o takich rzeczach, jak LINQ, Entity Framework, WPF, MVC i tym podobne; nie muszą go używać ani naciskać w miejscu pracy, ale przynajmniej przelotne zrozumienie „To istnieje” jest lepsze niż absolutna niewiedza, którą widzę zdecydowanie za często.

Wayne M.
źródło
2

Koduję dopiero od około 4 lat w pracy i to prawie całkowicie c #. Nauczyłem się C ++, gdy byłem w College i Uni, ale nie byłbym w stanie wiele z tym teraz zrobić.

W przypadku tworzenia GUI może to być postrzegane jako leniwe, ale z drugiej strony nie można zauważyć, że można mniej skupić się na kodowaniu tej części, a bardziej na rozwijaniu logiki samej aplikacji.

więc może zamiast stać się mniej kompetentnymi, skupiają się, prawdopodobnie dużo na komunikacji i systemach rozproszonych, takich jak przetwarzanie w chmurze i SOA. Choć może to być równie podobne myśli pośredniego programisty.

Kioshiki
źródło
2

Prawdopodobnie prawdą jest, że bariera wejścia na stanowiska programistyczne z każdym rokiem maleje. Na przykład inżynierowie, których specjalizacją nie jest przede wszystkim oprogramowanie i artyści, mogą teraz pisać kod przy użyciu języków skryptowych.

Oznacza to, że poziom kompetencji rzeczywiście wzrósł, jeśli weźmie się pod uwagę szerokość. To, że artyści mogą programować, oznacza również, że jest więcej programistów posiadających umiejętności artystyczne.

Joh
źródło
1
przez kompetencje miałem na myśli programowanie, wszystkie inne umiejętności są nieistotne oprócz matematyki.
Skeith,
3
@Skeith - „przez kompetencje miałem na myśli programowanie, wszystkie inne umiejętności są nieistotne oprócz matematyki” - to takie złe. Jedną z największych usprawnień w branży w ciągu ostatnich 30 lat jest to, że umiejętności komunikacyjne są obecnie uważane za absolutnie kluczowe. Daj mi w zasadzie kompetentnego programistę ze świetnymi umiejętnościami matematycznymi lub takiego, który ma świetne umiejętności komunikacyjne, a to facet z umiejętnościami komunikacyjnymi za każdym razem.
Jon Hopkins,
+1 @Jon - Całkowicie się zgadzam. Programiści, którzy nie rozmawiają z klientami tylko za pomocą rachunku lambda i zupy alaphabet, są bezwartościowi na większości porjectów.
Morgan Herlocker
1
@Skeith: Więc musisz znać programowanie i matematykę, aby być dobrym programistą? W jakim jesteś świecie? Musisz wiedzieć o tym, jak korzystać z komputera, jak komunikować się z klientami i innymi programistami, jak pisać dokumenty itp. To, czego nie musisz wiedzieć, to matematyka. Jasne, matematyka i programowanie nakładają się na siebie, ale wystarczy znajomość części programistycznej.
Martin Vilcans
Kiedy byłem na studiach, wziąłem lekcje rachunku biznesowego. W finale ukończyłem jako pierwszy i dostałem 100 (nauczyciel ocenił mnie właśnie tam - był pod wrażeniem, że tak szybko ukończyłem poprawnie). Jednak jako programista używam zerowej matematyki. To, czego używam, to logika, aby zrozumieć domenę biznesową i używam charyzmy do interakcji z ludźmi. Języki programowania rozwinęły się na tyle, że jeśli potrafisz dobrze pisać po angielsku, możesz dobrze pisać. Uwaga: pisanie w języku angielskim jest trudniejsze niż programowanie, ponieważ programujesz mokre oprogramowanie oparte na DNA ..
Christopher Mahan
2

Istnieje różnica między „programistą” a „prawdziwym programistą”. Nie nazywaj HTML językiem programowania, ale jest wielu „programistów HTML”. Każdy z was (programiści / programiści) może mieć doświadczenie ze współpracownikami - po prostu „wyłącz Internet (w rzeczywistości nie zezwalaj im na korzystanie z wyszukiwarek)”, a przekonasz się, że zasiądzie wielu różnych „programistów” bez pracy. Co mogą zrobić, po prostu wiedzą, że jeśli potrzebują na przykład wyszukiwania w tekście, powinni „wyszukać” wyszukiwanie w tekście w% nazwa_języka% ”? Nie potrafią na to odpowiedzieć - jakie są różnice w algorytmach Boyer-Moore i Knuth-Morris-Pratt.

Tak więc, IMO, programowanie oznacza rozwiązywanie problemów, znając bardzo dobrze jako co najmniej jeden język programowania z jego „STL” i innymi ważnymi rzeczami. Programowanie jest sztuką, jest rodzajem życia, nie jest to coś, co każdy może zrobić.

Przepraszam za więcej sarkazmu niż potrzeba, ale myślę, że ten artykuł mówi lepiej niż ja.

Czy się mylę?

UPD: Najważniejszą i najważniejszą rzeczą jest znajomość podstaw, takich jak algorytmy, struktury danych itp. Ilu z was może wdrożyć biblioteki / funkcje standardowe / itp. Na wypadek, gdyby dzisiejsze zostaną przypadkowo usunięte? IMO, programista powinien używać rozwiniętego / dobrze debugowanego „obcego” kodu (biblioteki / frameworki / etc), ale zawsze powinien być w stanie wymyślić koło na nowo!

3 obrotami
źródło
6
Moim jedynym problemem jest to, że pracowałem jako programista (właściwy programista, nie web / HTML / skrypt) od 20 lat i nie mam pojęcia o algorytmach Knuth-Morris-Pratt. Dla większości programistów tego rodzaju teoria nie ma wpływu na ich codzienne życie, ponieważ te rzeczy są zawarte w bibliotekach.
Jon Hopkins,
2
Standardowe biblioteki, z którymi pracuję, zawierają tysiące klas i setki tysięcy wierszy kodu. Czy mówisz, że powinienem móc to wszystko powtórzyć bez dokumentacji? Jeśli nie, musisz wyjaśnić, jak duże może być coś, zanim przestanie być kołem.
Peter Taylor
6
Ludzie nie mają wystarczającej długości życia, aby nauczyć się wymyślać wszystkie dotychczas wynalezione koła, ani nauczyć się wymyślać wymyślone obecnie koła .
Macke
3
@ Dehumanizer: Mam nadzieję, że będę szkolony i będę miał więcej niż kompilator C w moich rękach, aby uratować świat, w przeciwnym razie i tak mnie spieprzą. (BTW Dlaczego nawet kompilator C? Dlaczego nie tylko pamięć USB, oscyloskop i bateria 9V? Poważnie ....)
Macke
1
Po prostu wyłącz ich kompilatory, a zobaczysz, że większość ludzi siedzi obok, a PRAWDZIWY programiści wpisują kod maszynowy prosto do pliku!
Philip
1

Ponieważ VB jest łatwy w użyciu, a leniwi programiści wybierają VB z tego powodu:

Myślę, że VB jest otoczony jednym wielkim mitem łatwości użytkowania. Mit ten był pierwotnie nieco prawdziwy: w czasach około 1991-1994, kiedy dinozaury kroczyły po ziemi, były tylko dwa prawdziwe narzędzia RAD, VB i Delphi. Były dość podobne, ale UWAGA: Delphi i VB były równie łatwe w użyciu! Jedyną zauważalną różnicą między nimi było to, że VB miał całkowicie nielogiczną składnię i tworzył bardzo powolne programy.

GUI C / C ++ zostały napisane w MFC lub w surowym Win API. Tak więc VB był z pewnością łatwiejszy w użyciu niż alternatywa Microsoft. Potem młyn plotek wyglądał następująco:

  • VB jest łatwiejszy w użyciu niż Microsoft C / C ++ / Win API. ->
  • VB jest łatwiejszy w użyciu. ->
  • VB jest łatwy w użyciu. ->
  • VB jest najłatwiejszy.

Ta plotka trwała dalej, mimo że Delphi zawsze była równie łatwa, jeśli nie łatwiejsza, ponieważ Pascal jest rozsądnym i logicznym językiem.

Następnie pod koniec lat 90. Borland wydał C ++ odpowiadający Delphi: C ++ Builder. Teraz były 3 równie łatwe narzędzia. W tym czasie kilka pozostałych racjonalnych argumentów przemawiających za użyciem VB umarło. Jednak mit żył nadal. „VB jest najłatwiejszy”.

Potem pojawiła się Java i było do niej kilka narzędzi RAD (i jej wersja fiasko Microsoft o nazwie J ++). Jednak mit VB przetrwał.

Następnie Microsoft stworzył obsługę RAD dla C ++, a także wymyślił C #, wypiekając to wszystko w jednym wielkim goo o nazwie .NET. Ponieważ mit VB nadal istniał, byli w stanie oszukać starych programistów VB, aby używali VB.NET zamiast C ++ lub C #. Mimo że VB.NET był dość niekompatybilny z wcześniejszymi wersjami VB.

Dzisiaj VB jest całkowicie zbędnym językiem. Narzędzie RAD nie jest łatwiejsze niż jakiekolwiek inne narzędzie RAD. Składnia języka jest wręcz okropna, tak zła, że ​​w rzeczywistości sprzyja złemu projektowaniu programów i złej praktyce programowania.

użytkownik29079
źródło
dzięki teraz mogę zabrzmieć bardziej usprawiedliwiony w mojej nienawiści do VB, dodając przyczynę
Skeith
1

Istnieje ogromna różnorodność działań, które są połączone pod sztandarem „programowania”, i coraz większa liczba pracowników jest zaangażowana na końcu „technika”. Nie musisz być w stanie pisać kompilatorów, a nawet wybierać spośród zestawu algorytmów, aby rozwiązać konkretny problem, aby stworzyć stronę internetową w PHP. Przemysł / społeczeństwo potrzebuje wielu osób tworzących wspomniane strony (najwyraźniej), a także pewnej liczby programistów pracujących nad trudniejszymi problemami. Ta druga grupa nie jest leniwa ani niekompetentna jako całość, albo nasze samoloty spadałyby w płomieniach, bankomaty dostarczały losowe ilości gotówki, maszyny rentgenowskie dostarczały śmiertelne dawki promieniowania, rynki finansowe szaleje itd. Poczekaj, zapomnij o tym ostatnim :-)

jaybee
źródło
1

Jedną ze stron, na którą, jak sądzę, wszystkie pozostałe odpowiedzi tylko się spoglądają, jest to, że jest to tylko ogólny trend przechodzący od języków niskiego poziomu do języków wysokiego poziomu.

Tak, branża oprogramowania przechodzi z języków niskiego poziomu na języki wysokiego poziomu, zawsze tak jest i prawdopodobnie będzie to robić, o ile będziemy tworzyć lepsze narzędzia. Tak, można to uznać za lenistwo, ponieważ trzeba było naprawdę ciężko pracować, aby robić rzeczy podstawowe według dzisiejszego standardu. Ale nie powiedziałbym, że mniej kompetentny. Kompetencje po prostu przechodzą od wdrożenia do projektowania.

Niski poziom Jest to nieco subiektywne, ale na niskim poziomie pracujesz bliżej sprzętu. Jest mniej trzymania się za ręce i założeń intencji. Przedstawione są podstawowe narzędzia, a wykonanie zadań należy do programisty. Najpierw pojawiły się języki niskiego poziomu i zwykle są one narzędziami starej straży, ponieważ języki wyższego poziomu nie istniały, kiedy zaczęły. Zawsze będzie jakiś rozwój na niskim poziomie. Ale nie stworzyłbym strony internetowej w asemblerze.

Wysoki poziom Celem na wysokich poziomach jest zautomatyzowanie podstawowej funkcjonalności i uproszczenie programowania. To obniża poprzeczkę do wejścia dla nowych programistów, robi rzeczy szybciej i standaryzuje sposób, w jaki reprezentujemy i przetwarzamy dane, często z narzutem. Rozważ ciąg. Na początku ktoś prawdopodobnie używał 1-26 dla az i używał tylko 5 bitów i po prostu musiał wiedzieć, jak duże były jego słowa. Następnie opracowano standard ascii i mieliśmy łańcuchy C ze znakiem terminatora. Teraz mamy obiekty, które radzą sobie z rzeczami, aby uniknąć przepełnienia bufora, oraz specjalne podtypy, które uniemożliwiają znaki ucieczki. Lub pętla. Pętla „za” jest zawsze nieco wyższa niż pętla „podczas”. A pętla „while” jest po prostu reprezentacją ustrukturyzowanego sposobu wywoływania GOTO.

Również,

Przyszli programiści powiedzą komputerowi, czego chcą, a kompilator napisze dla nich program jak w star trek.

Witamy w przyszłości! Właśnie to robią kompilatory. W dawnych czasach ludzie musieli pisać kod maszynowy ręcznie. Teraz zautomatyzowaliśmy to i po prostu informujemy komputer, jak napiszemy dla nas kod maszynowy.

Philip
źródło
1

Myślę, że gdzieś po drodze straciłeś z oczu, za co programiści zarabiają.

Nasz produkt nie jest kodem, tylko działającym oprogramowaniem.

Nie budujemy mebli, w których ręcznie wycinane jaskółcze ogony w jakiś sposób nadają dodatkowej wartości z powodu całego ręcznego „rzemiosła”, które się w nich znalazło.

Dostajemy wynagrodzenie za rozwiązywanie problemów biznesowych na komputerach). Jeśli możesz dostarczyć ten sam produkt w krótszym czasie za mniej pieniędzy, myślę, że naszym OBOWIĄZKIEM jest porzucenie pretensji, że programy C ++ są lepsze po prostu dlatego, że są bardziej skomplikowane w budowie.

JohnFx
źródło
* jest to nadęte oprogramowanie, (czasami)
kagali-san
0

Współczynnik (liczba programistów / programistów podstawowych) maleje, ponieważ:

  • Narzędzia stają się łatwiejsze, co oznacza, że ​​potrzebny jest mniejszy talent do tego samego problemu

  • Ludzie przyzwyczajają się do technologii informatycznych, które chętniej wydają pieniądze na dostosowane narzędzia

  • Literatura informatyczna rośnie wykładniczo, rośnie specjalizacja i podział pracy, więc nie ma już „Arystotelesów”, którzy mówią o wszystkim (tak naprawdę nie muszą wiedzieć wszystkiego z powodu warstw abstrakcji)

  • Więcej ofert pracy, filtr jest poluzowany

  • Potrzebna jest większa automatyzacja na każdym etapie życia, popyt rośnie, a podaż nie wystarcza

  • Wzrasta stosunek deweloperów do liczby ludności.

    Tak więc ludzie nie stają się leniwi i mniej kompetentni, średnia spada, ponieważ komputery są teraz bardziej otwartym obszarem.

oguzalb
źródło
0

Wiele odpowiedzi mówi, dlaczego wymyślam koło, a ja się z tym zgadzam, ale kiedy są dostępne koła, ludzie nie zadają sobie trudu, aby nauczyć się robić koło.

Podważasz cały swój punkt widzenia, ponieważ w jakiś sposób koła wciąż się produkują. Rozumiem twój punkt widzenia, ale zauważyłem, że w każdej dyscyplinie jest wystarczająco dużo ludzi, którzy są zainteresowani niskopoziomowymi rzeczami, aby kontynuować. Na przykład używam Qt do tworzenia GUI. To narzędzie nie pojawiło się za pomocą magii, ludzie rozwinęli związek między rzeczami niskiego poziomu a rzeczami, które robię. Czy mniej osób rozumie rzeczy niskiego poziomu, tak. Mniej ludzi może również zabić własne jedzenie lub naprawić samochód, ale społeczeństwu udaje się przetrwać.

Szansa
źródło
0

Przed latami czterdziestymi komputery były układami przewodowymi. Następnie Von Neuman wpadł na pomysł przechowywania lokalizacji w pamięci. Jestem pewien, że programiści z MIT sądzili, że zdegraduje ich handel do czegoś zbyt łatwego. Potem przyszedł montaż, potem FORTRAN, potem ADA, potem C, potem C ++, potem Java i tak dalej. Chodzi o to, że celem języka jest umożliwienie dalszej i dalszej abstrakcji. To był zawsze cel i jest to powód, dla którego c ++ się przyłapało, a potem Java. Moim największym atutem jest to, że uniwersytety już nie uczą studentów niczego na temat komputerów. Nie zatrudniam programistów c #, jeśli nie znają c ++ jak własną rękę. Czemu? Ponieważ zbyt łatwo jest być złym programistą, język staje się coraz bardziej abstrakcyjny. Muszą zrozumieć wskaźniki, zarządzanie pamięcią, dynamiczne wiązanie itp. . wewnątrz i na zewnątrz, zanim będą w stanie zrozumieć C # do poziomu, w którym ufam, że przyczynią się do naszej bazy kodu. Zmuszam ich także, by zmagali się z tworzeniem plików, zanim pozwolę im korzystać z Visual Studio. To powiedziawszy, uwielbiam C # i dobre IDE, ale są dobre jako narzędzia, gdy są odpowiednio rozumiane. Moim zdaniem abstrakcja jest najbardziej przydatna, gdy rozumiesz szczegóły, które są abstrakcyjne - to bardzo stary pomysł, patrz Thomas Aquinas na temat stosunku abstrakcji do szczegółów.

Myślę, że innym dobrym ćwiczeniem dla programistów na poziomie podstawowym jest zmuszenie ich do napisania kilku aplikacji za pomocą Windows API. Następnie, po ich ukończeniu, niech zorientują obiektowo, gdzie każda forma dziedziczy po twojej ogólnej klasie okna. Poproś, aby zamknęli pętlę zdarzeń i przywrócili niektóre wskaźniki funkcji strzelające z powrotem do swojej klasy postaci. Więc powiedz dobrą robotę, Microsoft już to zrobił dla ciebie, nazywa się System.Windows.Forms. Baw się dobrze.

Jeśli mają być programistami internetowymi, poproś ich o napisanie kilku programów CGI, aby zrozumieli POST, GET itp., A następnie skrypty strony. To sprawia, że ​​ASP.NET i PHP mają znacznie większy sens.

Jeśli pracują w sieci na niższym poziomie, przed wprowadzeniem ich do bibliotek, które już to zrobiły, napisz kilka aplikacji korzystających z gniazd.

Przekonałem się, że poprawia to produktywność na dłuższą metę, ponieważ daje im narzędzia i poprawne intuicje do rozwiązywania własnych problemów.

Uniwersytety powinny to robić, ale nie jest tak, musimy.

To powiedziawszy, zgadzam się, że coraz trudniej jest znaleźć programistów, którzy są cholernie chodzący po studiach, głównie dlatego, że nie zostali wyeliminowani przez zmuszenie do pisania algorytmów rekurencyjnych i powiązanych list. Ponadto zwykle mieli tylko kursy Java lub .NET i dlatego nie rozumieją cholernej rzeczy o tym, jak działają. Mimo to abstrakcja jest całkiem przydatna, jeśli jest właściwie używana.

Jonathan Henson
źródło
0

(..) wcześniej czy później nie będzie czegoś takiego, jak to, co teraz nazywamy programowaniem

Nie zgadzam się z tym punktem.
Bez wiedzy, czym jest świadomość, praca programisty jest bezpieczna.

Oto jak w tej chwili wyglądają „myślące maszyny” :

- Przestań zmieniać temat!
-Myślałem, że nasza miłość była wyjątkowa.
- Przestań zmieniać temat!
-Nie zmieniam tematu.
-Ty jesteś! Próbuję mówić o Twojej niezdolności do zrozumienia, o czym mówimy.
-Nie jest nawet blisko. moja ulubiona piosenka beatles jest z wszechświata. co jest twoje?

Uważam, że tylko ci programiści, którzy nie rozumieją tego punktu, są skazani na zgubę.

Np. Odpowiedź Dehumanizatora :

Nie potrafią na to odpowiedzieć - jakie są różnice w algorytmach Boyer-Moore i Knuth-Morris-Pratt.

A przez „ten punkt” mam na myśli - źle jest wypróbować komputer, który jest najlepszy - algorytmy. Zamiast tego programista powinien pomagać komputerowi w kontekście, opowiadając o problemach, które próbujemy rozwiązać.

Same narzędzia nie naprawiają problemów, po prostu (czasami) zwiększają wydajność programistów.

To tak: „pistolety nie zabijają, ludzie robią”.

Arnis Lapsa
źródło
1
Jeśli się nie mylę, czy Cleverbot po prostu nie powtarza tego, co ludzie już na to powiedzieli?
Andrew Arnold,
0

Absolutnie nie. Z mojego doświadczenia wynika, że ​​korzystanie z odpowiednich narzędzi programistycznych pozwala na szybki rozwój aplikacji bez utraty jakości. W rzeczywistości argumentowałbym, że w większości jakość poprawiła się z powodu naszego „nadmiernego polegania na narzędziach”. Ponadto narzędzia programistyczne mogą zmniejszyć krzywą uczenia się i wprowadzić więcej osób do programowania. Ma to oczywiście wadę, ponieważ jest o wiele więcej początkujących programistów, ale w sumie pomaga w procesie twórczym i przyspiesza rozwój technologii.

Caffeinated Aviator
źródło
0

Czy nadmierne poleganie na narzędziach oznacza, że ​​jesteś leniwy?

Ogólnie rzecz biorąc, „nie”; ale jest jedno wielkie zastrzeżenie.

Zacząłem programować w C ++ na uni i bardzo mi się podobało. W następnym semestrze zmieniliśmy na VB6 i nienawidziłem tego.

Nie mogłem powiedzieć, co się dzieje, przeciągasz przycisk do formularza, a ide pisze kod dla Ciebie.

W rzeczy samej. Twoje doświadczenie na uniwersytecie przemawia do samego zastrzeżenia, o którym wspomniałem.

Jeśli nie wiesz, jaki problem rozwiązuje Twoje narzędzie lub nie możesz rozwiązać problemów, gdy Twoje narzędzie ma własne problemy, oznacza to wielką czerwoną flagę. Ta okoliczność niekoniecznie oznacza lenistwo, ale prawdopodobnie oznacza brak doświadczenia.

Jim G.
źródło
-2

Myślę, że są 2 smaki programistów. Są programiści, którzy po prostu programują, aby wykonać zadanie ze względu na termin, a może po prostu, aby być bardziej produktywnym. Powiedziałbym, że byli leniwi. Po prostu wierzę, że nie są zainteresowani tym, w jaki sposób komputer robi to, co robi, ani w jaki sposób program robi to, co robi.

Są też namiętni programiści, tacy jak ja. Namiętni programiści, tacy jak ja, lubią dokładnie wiedzieć, co dzieje się w procesorze. Tak jak dobry psycholog próbuje dowiedzieć się, co dzieje się w ludzkiej głowie, progrolog, podobnie jak ja, chce wiedzieć, co dzieje się w procesorze. Uczymy się, analizujemy i analizujemy program oraz używamy narzędzi, takich jak Reflector i deasemblery, aby spróbować dowiedzieć się, jak program działa.

Icemanind
źródło
Nie zgadzam się. Różni ludzie są zainteresowani różnymi rzeczami. Niektóre osoby są bardziej zainteresowane programowaniem niższego poziomu i lubią wiedzieć, co dzieje się w sprzęcie. Inne osoby są bardziej zaawansowane i zajmują się głównie aplikacjami. Czy uważasz, że ktoś, kto pisze kod na przykład na Facebooku, ma jakieś obawy dotyczące tego, co dzieje się z procesorem lub działania sterowników? Stwierdzenie, że przypadkiem ludzie pasjonujący się tymi samymi częściami programowania, którymi jesteś, jest pasjonatem, nie ma logicznych podstaw.
Szansa
-3

Mam cichą nadzieję, że wszystko się zmieni. Procesory nie skalują się w pionie tak bardzo, tylko w poziomie, ARM itp. Zostaną w najbliższej przyszłości ograniczone zasobami.

Jest całkiem możliwe, że popyt na programowanie bez przeciągania i upuszczania zmniejszy się, a my zobaczymy kilka ciekawszych zadań.

Koder
źródło