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

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.

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.

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.

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).

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.

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.

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.

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.

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”.

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.

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!)

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.

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.

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.

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.

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.

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!

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.

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 :-)

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.

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.

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.

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ć.

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.

(..) 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ą”.

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.

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.

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.

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ń.