Чи означає надмірна опора на інструменти, що ти лінивий? [зачинено]

Я почав програмувати на C ++ в університеті і мені сподобалось. На наступному терміні ми змінили VB6, і я його ненавидів.

Я не міг сказати, що відбувається, ти перетягуєш кнопку до форми і ide записує код для тебе.

Хоча я ненавидів спосіб функціонування VB, я не можу стверджувати, що це було швидше і простіше, ніж робити те саме в C ++, щоб я міг зрозуміти, чому це популярна мова.

Тепер я не називаю розробників VB ледачими, просто кажучи простіше, ніж C ++, і я помітив, що багато нових мов слідкують за цією тенденцією, як C #.

Це наштовхує мене на думку, що оскільки більше бізнесу хоче швидких результатів, тим більше людей програмує так, і рано чи пізно не буде такого поняття, як те, що ми називаємо програмуванням зараз. Майбутні програмісти скажуть комп'ютеру, що вони хочуть, і компілятор напише програму для них, як у зірковому поході.

Це лише недостатньо усвідомлена думка молодшого програміста чи програмісти стають лазями та загалом менш компетентними?

EDIT: Дуже багато відповідей говорять, чому винайдіть колесо, і я згоден з цим, але коли є колеса, люди не намагаються навчитися робити колесо. Я можу google як зробити майже все на будь-якій мові, і половина мов так багато робить для вас, коли справа доходить до налагодження, вони не мають уявлення, що там робить код, як виправити помилку.

Ось так я дотримуюсь теорії, що програмісти стають лінішими та менш компетентними, тому що нікого не цікавить, як працює так, як це робиться, поки це не відбувається.

Ні, розробники не мають лазерного або менш грамотного характеру. Так, постійно понижується потреба у фактичному розвитку, в тому сенсі, що ви це знаєте. І так, це дуже багато, тому що підприємства хочуть швидких результатів, а чому вони не повинні?

Однак є кінцева точка. У деяких розробниках завжди буде потреба.

Дуже багато вимог однакові в різних проектах. Той, про який ви говорите, - це код інтерфейсу користувача. Більшість користувальницьких інтерфейсів складаються з певного набору полів - текстового поля, прапорця, радіо, вибору тощо. - Немає сенсу розробляти їх з нуля, знову і знову. Тож укладаються шари абстракції, щоб забрати весь код котла.

Аналогічно шару даних, який зазвичай є не що інше, як Insert This, Delete This, Replace This та велика кількість різних поглядів одних і тих же даних. Навіщо продовжувати писати це знову і знову? Давайте винайдемо ORM.

Єдине, що вам слід розробити - це унікальний для бізнесу, який ви розвиваєте.

Але завжди буде така унікальність - там, де її немає, є можливість для бізнесу - і люди завжди будуть потребувати написання коду.

Все, що сказано, також майте на увазі, що бути розробником набагато більше, ніж писати код. Незалежно від того, чи кодуєте ви в чистому складі або з’єднуєте компоненти Drupal, щоб створити веб-сайт, керований контентом, ви перекладаєте необхідність бізнесу на те, що комп'ютер розуміє.

Найважливіша частина бути розробником програмного забезпечення - це вміння достатньо добре зрозуміти вимогу бізнесу, щоб пояснити це комп'ютеру.

Насправді не важливо, якою мовою ви користуєтеся, щоб пояснити речі на комп’ютері, це важливо лише те, що ви можете. І це важка робота, нічого ледачого в цьому немає.

Механік лінивий і менш грамотний, бо використовує гідравлічний ключ ?

Образ двох хлопців, скажімо, Бред і Піт. Вони обидва працюють у двох гаражах, щодня міняють шини. Бред - розумний хлопець, він знає, що за допомогою кращих інструментів можна зробити свою роботу краще і швидше. Використання гідравлічного ключа допомагає йому змінити більше шин. Клієнти чекають у коротшій черзі - всі радіють. Бард також знає, що цей ключ іноді занадто великий, і він не може допомогти йому різними видами гвинтів.

З іншого боку, Піт каже, що гідравлічний ключ - це богохульство, і Бред не є "справжнім механіком". Впевнений Піт може зробити лише половину того, що робить Бред, але він робить це "правильним чином".

Тепер, що ви думаєте, яких клієнтів гаража обрали б? Той, що займає 20 хвилин, або той, який чекає 40 хвилин.

Це досить схоже з програмуванням. C ++ - це гарна мова і має своє призначення (головним чином, продуктивність). Що мені подобається у таких мовах, як C #, це те, що я можу зосередитись на проблемі, подумати про алгоритм без всякого шуму, який C ++ робить, як неоднозначні попередження компілятора, невизначені поведінки та інші. Розвиток стає все складнішим, коли в старі часи мейнфреймів та перших ПК все ж мозок людини залишається таким же - досить німим. Один додаток може працювати в хмарних, мобільних, робочих столах, існує багато залежностей, проблем безпеки та інших проблем. Я хочу мати кращий інструмент, щоб зосередитись на більш складних проблемах і вирішити їх.

Використовуйте кращі інструменти для роботи - нічого поганого в цьому немає.

Отже, що ми зараз називаємо програмуванням

Ти кажеш:

Майбутні програмісти скажуть комп'ютеру, що вони хочуть, і компілятор напише програму для них, як у зірковому поході.

просто зробіть експеримент: дивіться зірковий похід і намагайтеся інтерпретувати те, що комп’ютер наказав зробити трохи «непотрібним».

• Чай, граф сірий, гарячий -> багато пари.
• Чай, граф сірий, 60 градусів Цельсія -> калюжа і хмара пари
• граф сірий, 60 градусів Цельсія -> калюжа
• граф сірий, 60 градусів Цельсія, в чашці -> чашка з краплею в неї
• граф сірий, 60 градусів Цельсія, 0,2 літра, в чашці. -> нарешті (гаразд, ви можете ниткати більше)

Коли ви телефонуєте програмуванню: "Знання про використання пам'яті, покажчики тощо", так, я думаю, це стане менш важливим (оскільки "Знання про http, openid, unicode" отримає більше значення).

Але, на мою думку, все - це «випадкова складність», і справжньою роботою як програміста є «Змушення машин для вирішення проблем, переконуючись, що хтось розуміє достатньо випадкових проблем для досягнення поставленого завдання», і за цим визначенням хтось розмовляє із зірковою дорогою комп'ютер повинен бути програмістом (тобто мати ті самі чесноти, що і зараз).

Програмісти не лінуються. Програмісти завжди ліниві. Ледачі - частина фундаментального характеру роботи. Проблема полягає в тому, що люди припускають, що лінуватися - це негатив. Бути "ледачим" програмістом - це чеснота.

Запам’ятайте стару приказку: «Працюй розумніше, а не важче». Це основний привід програмістів.

Хлопці, які побудували та запрограмували перші комп’ютери, цього не зробили, тому що їм подобалося робити важку роботу, вони робили це, щоб уникнути ще більш важкої роботи. (робити сторінки обчислень вручну)

«Ледачий» - одна з основних причин, чому програмісти програмують. Тому ми пишемо нові та все більш високі мови, кращі та кращі налагоджувачі та IDE, сценарії оболонки та збирання тощо ...

Програміст розглядає проблему, все, що він робить, і думає;

"чи можу я це автоматизувати?" , "скільки часу це займе?" , "скільки часу це врятує мене?"

Ми робимо це через те, що ми ліниві, ми не хочемо робити повторювані та нудні завдання, коли ми могли б робити речі, які набагато веселіші.

Якби програмісти не лінувалися, жоден програміст ніколи не побачив би потреби написати єдину нову мову чи компілятор.

Що стосується поняття про те, що програміст "ледачий", тому що йому доводиться "шукати речі", то що, кого хвилює. Припущення про те, що це більше роботи, щоб вивчити кожен нюанс певної мови (і ніколи не потрібно щось шукати), то це знайти та використати те, що вам потрібно, коли вам це потрібно, - це помилка. Крім того, процес пошуку речей - це процес навчання, і саме тому існують подібні сайти.

Якщо хтось хоче важкої роботи з програмування, я б сказав їм передати код шрифту в сировині. Зробив це? Хочете щось складніше? Тепер перейдіть до налагодження.

Перш за все, телефонувати людям, які використовують, наприклад, мови з сміттям для сміття, - це те, що називати людей, які керують автомобілями з автоматичною коробкою передач, ліниво. ІМО це трохи смішно.

Щодо компетенції, програмування - це набагато популярніша та егалітарна робота, ніж раніше. Так, так, є багато новачків, яким не вистачає знань. Я не маю на увазі, що раптом є менш грамотні програмісти. Насправді їх більше. Ви просто дивитесь на неправильну сторону кривої дзвону.

Мені спокушається сказати: "так, необізнані самовпевнені молодші програмісти стали ледачими і менш компетентними", але давайте спробуємо серйозну відповідь:

Багато речей стало простіше, але від нас очікується більше. В даний час я створюю веб-додаток, який має безліч функцій, які зазвичай знаходяться у добре створених програмах gui (вкладки, вкладки для редагування та сортування, експорт Excel тощо). Інструменти, які я використовую (ExtJS тощо), роблять досить дешевим створення такої програми.

Десять років тому створити такий додаток було б майже неможливо, принаймні дуже дорого. Але десять років тому для клієнтів було б достатньо простої форми HTML із таблицею HTML. Сьогодні з тими ж зусиллями можливі кращі (принаймні красивіші) результати, і клієнти розраховують отримати їх!

Загалом, розробник програмного забезпечення сьогодні повинен знати більше мов, ніж розробник програмного забезпечення 20 років тому. Тоді чогось на зразок C і SQL було достатньо. Сьогодні я використовую JavaScript, HTML, Groovy, Java, SQL - все в одному проекті.

Програмісти стають в меншій мірі менш грамотними та лазерними, але в інших - більш компетентними, хоча розрив C ++ / VB не є причиною чи симптомом у моїй свідомості.

Використання конструктора графічного інтерфейсу не лінь, це просто різне, це стосується інструментів для роботи. Якщо програміст асемблера назвав програміста C ++ ледачим, ви б подзвонили по глупості на це (правильно), і те саме стосується C ++ та VB. VB дозволяє робити якісь речі швидко за рахунок деякого контролю. Перешкоди для початку кодування в ньому, безумовно, нижчі, але це дуже різна річ у ліні - ви просто дізнаєтесь різні речі та застосовуєте їх по-різному. Програмісти VB не лінивіші, ніж програмісти C ++ - непродуктивні, вони просто працюють і виробляють по-різному.

З іншого боку, загалом освіта програмістів зараз краща, ніж це було колись. Наприклад, ідея не використовувати керування джерелами є досить огидною для майже всіх зараз, де 10 чи 20 років тому це не було б таким правдивим. Аналогічно, вони з більшою ймовірністю розуміють і хочуть використовувати автоматизовані тести блоку, постійну інтеграцію тощо, тому в цьому сенсі вони більш компетентні, ніж були.

Але те, що я думаю, що змінилося, це те, що люди вже не знають, як вирішити проблеми, як вони звикли, і це правда майже для будь-якої основної мови. Миттєвою відповіддю на будь-яку проблему зараз є Google, і хоча це чудово і працює 95% часу, я бачу занадто багато програмістів, які не мають уявлення, що робити, коли цього не відбувається.

Справа не в тому, що вони не розуміють основ (вони цього не роблять, але це насправді не така вже й велика справа), це те, що вони не можуть розбити проблеми таким чином, щоб вони могли навіть розробити, які основи їм потрібні впоратися з.

Попередньо Google у вас не було вибору. Вашими ресурсами були ваша команда, кілька десятків книжок, до яких ви можете мати доступ, і ваш мозок. Це налаштування означає, що якщо ви знайдете проблему, швидше за все, ви вирішите її самостійно з чогось близького до перших директорів, тож ви або отримаєте досить непоганий результат, або досить безробітний.

І це було правдою незалежно від того, якою мовою ви користуєтесь. VB є високим рівнем і приховує багато, але це означає, що якщо мова йде про вирішення проблем, що насправді означало, що вам потрібно більше працювати. Якщо щось не спрацювало, вам довелося бути більш креативними і працювати більше, оскільки у вас було менше контролю. Як програміст VB (і я кажу з досвіду), ви не знали менше, ніж хлопці C ++, ви просто знали різні речі, але ви обоє знали, як вирішити проблеми.

Але, мабуть, суворо це сприймати як суттєву критику програмістів у наші дні, вони не розвивають навичок, оскільки вони їм не потрібні, але це слабкість порівняно з тими, хто здобув навички, коли вони були необхідні.

Я зауважу з вашого профілю, що вам 23 роки. Дозвольте мені поставити зуби і дати вам деяку точку зору від того, хто приблизно вдвічі перевищує ваш вік, який займається цим дуже довго:

Раніше було набагато менше всього, починаючи з обчислювальної потужності, пам’яті та пропускної здатності мережі, якщо у вас взагалі була мережа. Ці недоліки обмежують те, що ви могли розумно зробити, полегшуючи обернути голову навколо всього. Програмне забезпечення, яким ми сьогодні керуємо, є набагато більш здатним, ніж речі, з якими я працював 25 або 30 років тому, і ці можливості означають, що це набагато більше. Це робить збір тонкого розуміння всього набагато складнішим для однієї людини. Частина цього пов'язана з тим, що справи продовжуватимуть збільшуватися у складності, а частина пов'язана з побічними ефектами віку.

Обчислювальна екосистема стає дуже схожою на біологічні системи: люди складніші, ніж одноклітинні організми, і частинам із нас доводиться спеціалізуватися, якщо ми хочемо щось робити. Мої клітини мозку страшенно хороші в розумних речах, але втратили б, якби заграли в мою нирку і очікували робити ниркові речі. Так само хлопець, який добре пише цифрові сигнальні процесори, може не уявляти, як працює повнотекстова індексація, адже це просто не його спеціальність. Але обидва можуть трохи розвинутися і навчитися розуміти це, якщо їм це потрібно, але є обмеження в тому, наскільки далеко ви можете поширити себе і все ще бути ефективними в тому, що робите.

... нікого не цікавить, як працює так само, як це робиться, поки він цього не робить.

Коли у вас є робота, вам часто доводиться робити стрибок віри в те, що інструмент, який ви використовуєте (бібліотека, RDBMS, ціла підсистема тощо), працює як слід. Одне з речей, яке приносить досвід, - це можливість вибирати кролячі нори, якими ви збираєтеся бігти, щоб вивести з ладу ваші інструменти, виправити проблему і повернутися до того, що ви робили.

Тепер я не називаю розробників VB ледачими, просто кажучи простіше, ніж C ++, і я помітив, що багато нових мов слідкують за цією тенденцією, як C #.

Це все питання перспективи. Я збирався бачити, як C ++ з'явився, і це також слід за цією тенденцією. C ++ робить речі набагато простішими, ніж C, C робить речі набагато простішими, ніж збирання, а складання робить речі набагато простішими, ніж писати опкоди вручну. Як хтось, хто написав багато збірок і зібрав кілька речей вручну з нуля, це поставить вас, як програміста на C ++, три кроки вниз по шляху "легше".

Я щось довго підтримував:

Одна з найбільших сильних сторін Visual Basic Language є те, що новачок може навчитися робити багато корисних справ досить швидко.

Однією з найбільших недоліків програмістів Visual Basic є те, що вони навчиться робити багато корисних справ досить швидко, і тоді вони перестануть навчатись чому-небудь.

Коли я навчав би програмуванню першої вправи, перший день заняття полягав у тому, як створити додаток у NOTEPAD та компілювати його за допомогою VCC чи VBC. Так, це те, що ми (як програмісти) не робимо щодня, але повинні розуміти, що відбувається, коли ми натискаємо "F6".

Програмісти, як правило, не стають «лазячими» стільки, скільки ми розраховуємо отримати більше наших інструментів. У мене немає потреби вводити "отримати / встановити" 10 000 разів на день, мені подобається, що Visual Studio та інші інструменти, такі як Code Smith і Resharper, працюють для мене, щоб робити те, що я вже знаю, як це зробити, щоб я міг прикласти свої зусилля до фігурації як робити "нові" речі. Це не робить мене ледачим, це робить мене "новатором".

Як професійний розробник, ми не повинні «витрачати час» на винахід колеса, але ми повинні чітко розуміти, що стосується виготовлення колеса, яке ми будемо використовувати. Це те, чому ми повинні «вчитися» як студентські розробники (але, на жаль, часто це не так). Якщо розробник не розуміє якоїсь технології «чорного ящика», це робить їх справді менш «компетентними». Більшість розробників лише «в основному розуміють», як працює драйвер ODBC, вони просто розуміють, що він робить. Чи повинен я знати, як працює трансмісія, щоб бути компетентним водієм? Я б сказав, що ні. Чи робить це я більш компетентним власником автомобіля знати це, так.

Необхідність швидкої розробки додатків (обов'язкове посилання на вікі: http://en.wikipedia.org/wiki/Rapid_application_development ) означає, що розробники пишуть менше коду, а новіші розробники розуміють менше, оскільки їм не потрібно розуміти, як реалізувати пов'язаний список, оскільки у них є щось більш високий рівень, на який слід зосередити увагу.

Я не можу ловити, вбивати, шкуру, м'ясника і вилікувати м'ясо, і я сумніваюся, що хлопець у кафе внизу може, але я все-таки дістаю свій бутерброд з беконом, як і ділові хлопці отримують свої програми від розробників, які не знають про покажчики (як я!)

Кажуть, що великі наукові дисципліни - це приклади гігантів, що стоять на плечах інших гігантів. Також було сказано, що індустрія програмного забезпечення - це приклад багетів, що стоять на пальцях інших клинок.
- Алан Купер

Хороший розробник програмного забезпечення - це не той, хто винаходить колесо. Він вміє використовувати інструменти, побудовані до нього. Він не витрачає час на переписування тих самих старих нудних речей, які були написані сотні разів, швидко стає стомлюючим і, ймовірно, існує у версії більш високої якості вже там.
Якщо ви дасте їм мову, у якої вже є круглі кам'яні диски, велика ймовірність, що вони не витратять занадто багато часу на винахід колес. Якби я отримав цент за кожну програму копіювання рядків, коли-небудь написану на C, я, ймовірно, міг би придбати всю галузь програмного забезпечення.

Лінь насправді одна з трьох великих чеснот програміста. Інструменти, про які ви говорите, були створені хорошими програмістами для хороших програмістів, щоб зменшити зайві та нудьгу і тим самим підвищити продуктивність та мотивацію. Такі інструменти можуть насправді мати негативні наслідки для початківців, так як вони гальмують більш глибоке розуміння аспектів програмування вони спрощувати.

Ні. Ти просто старієш.

Не жартуйте, що ви переживаєте - це своєрідне право проходу для розробників. З тих пір, як перші мови вищого рівня витіснили збірку. Тоді ви б чули, як усі програмісти ASM скаржилися на одне і те ж. Через 5 років усі розробники Ruby on Rails будуть скаржитися на те, як ледачий ще один урожай нових інструментів робить людей.

Цей рефрен буде повторюватися, поки машини не знищать усіх нас: "Чи здається, що технологія X робить розробників ленішими та гіршими за технологію Z, яку я завжди використовував?"

Хороша новина полягає в тому, що, хоча компілятори пройшли дуже довгий шлях, людям все ще потрібні збірки та C та всі інші старі перешкоди для багатьох речей ... тільки не більшість передових технологій. Якщо ви хочете бути в цій передній частині, я пропоную вам оновити набір навичок.

З мого досвіду, так і ні, але це не вина мов; це вина самих розробників. Я працював з багатьма розробниками, які нічого не піклувались про те, щоб робити все правильно, вдосконалювати себе або дійсно робити щось інше, крім того, щоб виганяти те саме лайно, яке вони робили роками. Намагатись покращити цих людей - це як розмовляти з цегляною стіною - половину часу вони не знають нічого, чого раніше не використовували або зовсім не бажають "ризикувати" чимось, що може підвищити їхню продуктивність .

Більш просунуті мови не проблема, адже програмісти не сприймають цю професію як ремесло, що постійно розвивається. Вам не потрібно глибоко усвідомлювати все нове або стрибати на кожній новій стрічці, але вам слід хоча б спробувати стати кращим у тому, що ви робите.

Для конкретного прикладу: я розробник .NET в галузі торгівлі. Я би сподівався, що грамотний розробник .NET буде в курсі таких речей, як LINQ, Entity Framework, WPF, MVC тощо; їм не доведеться ним користуватися або натискати на робочому місці, але принаймні розуміння "Це існує" краще, ніж абсолютна незрозумілість, яку я бачу занадто часто.

Я кодую вже близько 4 років у роботі, і це майже повністю c #. Я навчився C ++, коли навчався в коледжі та університеті, але зараз не зміг би з цим багато чого зробити.

Отже, для розвитку графічного інтерфейсу це можна вважати ледачим, але потім не можна було б бачити, що ви можете менше зосереджуватися на кодуванні цієї частини, а більше на розробці логіки самого додатка.

тому, можливо, замість того, щоб стати менш компетентними, вони рухаються фокусом, ймовірно, багато в напрямку комунікації та розподілених систем, наприклад, хмарних обчислень та SOA. Хоча це може бути так само, як і аналогічні думки проміжного програміста.

Напевно, правда, що бар'єр для вступу на роботу з програмування з кожним роком стає все нижчим. Наприклад, зараз інженерам, спеціальністю яких є не в першу чергу програмне забезпечення та художники, можна писати код за допомогою мов сценарію.

Це означає, що рівень компетентності фактично підвищився, якщо врахувати ширину. Те, що художники можуть програмувати, також означає, що зараз більше програмістів з мистецькими навичками.

Існує різниця між "програмістом" і "реальним програмістом". Будь ласка, не називайте HTML мовою програмування, але є багато "програмістів HTML". Кожен з вас (програмісти / розробники) може зробити досвід роботи з колегами - просто "вимкніть Інтернет (фактично не дозволяйте їм користуватися пошуковими системами)", і ви побачите, що величезна кількість "програмістів" буде сидіти без роботи.Що вони можуть зробити, вони просто знають, що якщо їм потрібно, наприклад, шукати текст, вони повинні "шукати" пошук тексту в% language_name% '"? Вони не можуть на це відповісти - які відмінності в алгоритмах Боєра-Мура та Кнута-Морріса-Пратта.

Отже, IMO, програмування означає вирішення проблем, дуже добре знати як мінімум одну мову програмування з її STL та іншими важливими речами. Програмування - це мистецтво, це своєрідне життя, це не річ, яку кожен може зробити.

Вибачте за більше сарказму, ніж потрібно, але я думаю, що ця стаття говорить краще, ніж я.

Я помиляюся?

UPD: Головне і важливе - це знання основ, таких як алгоритми, структури даних тощо. Скільки з вас може реалізувати бібліотеки / стандартні функції / тощо, якщо сьогоднішній день буде випадково видалено? IMO, програміст повинен використовувати розроблений / добре налагоджений 'чужорідний' код (бібліотеки / рамки / тощо), але повинен мати можливість винаходити колесо завжди!

Що стосується простоти використання VB, а лінивих програмістів вибирають VB через нього:

Я думаю, що VB оточений одним великим міфом про простоту використання. Цей міф спочатку був дещо вірним: ще в часи 1991-1994 років, коли динозаври ходили по землі, навколо було лише два справжні інструменти RAD - VB та Delphi. Вони були досить схожими, але ПРИМІТКА ЦЕ: Delphi та VB були однаково простими у використанні! Єдина помітна відмінність між ними полягала в тому, що VB мав абсолютно нелогічний синтаксис і створював неймовірно мляві програми.

Графічні інтерфейси C / C ++ писалися або в MFC, або в необробленому Win API. Тож VB, безумовно, був простішим у використанні, ніж альтернатива Microsoft. Тоді млин чуток пішов так:

• VB простіший у використанні, ніж API Microsoft C / C ++ / Win. ->
• VB простіший у використанні. ->
• VB простий у використанні. ->
• VB - найпростіший.

Тоді ця чутка жила далі, хоча Дельфі завжди було однаково легко, якщо не простіше, оскільки Паскаль - це розумна і логічна мова.

Тоді наприкінці 90-х Borland випустив C ++, еквівалентний Delphi: C ++ Builder. Зараз було 3 однаково прості інструменти. Приблизно в цей час загинуло небагато раціональних аргументів щодо використання В.Б. І все-таки міф жив досі. "VB - найпростіший".

Потім з'явилася Java, і для неї також було кілька інструментів RAD (і для версії фіаско Microsoft, яка називалася J ++). І все-таки жив міф про В.Б.

Тоді Microsoft також підтримав RAD для C ++, а також придумав C #, виклавши все це в один великий під назвою .NET. Оскільки міф про VB все ще жив, вони змогли обманути старих розробників VB на використання VB.NET замість C ++ або C #. Навіть незважаючи на те, що VB.NET був зовсім несумісним із більш ранніми версіями VB.

Сьогодні VB - це абсолютно зайва мова. Інструмент RAD не простіший, ніж будь-який інший інструмент RAD. Синтаксис мови прямо жахливий, настільки поганий, що насправді заохочує поганий дизайн програми та погану практику програмування.

Існує величезна кількість різноманітних заходів, які збираються разом під прапором "програмування", і все більша кількість робітників залучається в кінці шкали "технік". Вам не потрібно вміти писати компілятори або навіть вибирати з набору алгоритмів, щоб вирішити певну проблему для складання веб-сайту в PHP. Промисловість / суспільство потребує безлічі людей, які виробляють вказані веб-сайти (мабуть), а також певну кількість програмістів, які працюють над більш складними проблемами. Ця друга група в цілому не лінива або некомпетентна, або наші літаки спалахнуть полум’ям, банкомати доставляють випадкову кількість готівки, рентгенівські машини доставляють смертельну дозу радіації, фінансові ринки йдуть на озброєння тощо. про останній :-)

Одна зі сторін цього, на яку я думаю, що всі інші відповіді лише оглядаються, - це лише узагальнена тенденція, що переходить від мов низького рівня до мов високого рівня.

Так, галузь програмного забезпечення переходить від мов низького рівня до мов високого рівня, завжди є, і, ймовірно, буде продовжувати це робити, поки ми створимо кращі інструменти. Так, це можна вважати лінивим, оскільки вам довелося дуже важко працювати, щоб робити речі, які є основними на сьогоднішній день. Але я б не сказав менш компетентним. Компетенція просто переходить від впровадження до дизайну.

Низький рівень Це дещо суб'єктивно, але на низькому рівні ви працюєте ближче до обладнання. Тут менше тримання рук і припущень про наміри. Представлені основні інструменти, а виконання завдань залишається програмісту. Мови низького рівня, звичайно, з’явилися спочатку, і зазвичай є інструментом старої гвардії, оскільки мови вищого рівня не існували при їх запуску. Завжди буде якась низька розробка. Але я б не робив веб-сайт в зборах.

Високий рівень Завдання на високому рівні - автоматизувати основні функціональні можливості та спростити програмування. Це знижує смугу вступу для нових програмістів, робить роботу швидше і стандартизує те, як ми представляємо та обробляємо дані, часто з накладними витратами. Розглянемо рядок. У перші дні хтось, ймовірно, використовував 1-26 для az, а використовував лише 5 біт і просто повинен був знати, якого розміру мають його слова. Потім був розроблений стандарт ascii, і ми мали струни C з символом термінатора. Тепер у нас є об'єкти, які обробляють речі, щоб уникнути переповнення буфера та спеціальні підтипи, які забороняють втечу символів. Або петля. Цикл "для" - це настільки дещо вищий рівень, ніж цикл "поки". А цикл "поки" - це справді лише представлення структурованого способу виклику GOTO.

Також,

Майбутні програмісти скажуть комп'ютеру, що вони хочуть, і компілятор напише програму для них, як у зірковому поході.

Ласкаво просимо в майбутнє! Саме так і роблять компілятори. За старих часів люди мусили виписувати машинний код вручну. Тепер ми це автоматизували і просто розповімо комп’ютеру, як написати машинний код для нас.

Я думаю, що десь по дорозі ви втратили зір, що програмістам платять.

Наша продукція - це не Кодекс, це працює програмне забезпечення.

Ми не будуємо меблі, де вирізані вручну рукоятки якось надають додаткову цінність через всю ручну «майстерність», яка входила в неї.

Нам платять за вирішення бізнес-проблем на комп’ютерах). Якщо ви можете доставити один і той же продукт за менший час за менші гроші, то я думаю, що це ОБОВ'ЯЗКА відмовитись від того, що програми C ++ є вищими просто тому, що вони складніші для побудови.

Коефіцієнт (основні розробники програми / кількість розробників) зменшується через:

• Інструменти стають легшими, це означає, що для тієї ж проблеми потрібно менший талант

• Люди звикають до ІТ-технологій, вони охочіше витрачають гроші на спеціальні інструменти

• Література з інформатики зростає експоненціально, зростає спеціалізація та розподіл праці, тому більше немає людей "Арістотелів", які говорять про все (насправді їм не потрібно знати все через шари абстракції)

• Більше запропонованих завдань, фільтр розпущений

• Більше автоматизації потрібно на кожному життєвому циклі, попит збільшується, а пропозиція недостатня

• Зростає співвідношення розробників до кількості населення.

  Тож люди не стають лінивішими та менш компетентними, середні падіння, тому що обчислення зараз є більш відкритою сферою.

Дуже багато відповідей говорять, чому винайти колесо, і я згоден з цим, але коли є колеса, люди не намагаються навчитися робити колесо.

Ви підриваєте всю свою точку зору через те, що так чи інакше колеса все-таки виготовляються. Я бачу вашу думку, але я помітив, що в будь-якій дисципліні є достатньо людей, які зацікавлені в матеріалах низького рівня, щоб продовжувати це. Наприклад, я використовую Qt для створення графічних інтерфейсів. Цей інструмент не прийшов за допомогою магії, люди розвивали зв’язок між предметами низького рівня та речами, які я роблю. Чи менше людей розуміє речі низького рівня, так. Менше людей також може вбити власну їжу або поправити власний автомобіль, але суспільству вдається вижити.

До комп’ютерів 1940-х років були жорсткі дротові схеми. Тоді Фон Нейман придумав ідею зберігати місця пам'яті. Я впевнений, що програмісти в MIT думали, що він збирається деградувати їх торгівлю на щось надто просто. Потім прийшла збірка, потім прийшов FORTRAN, потім ada, потім C, потім c ++, потім java і так далі. Справа в тому, що мова мови полягає в тому, щоб дозволити подальше і подальше абстрагування. Це завжди було ціллю, і це є причиною того, що c ++ наздогнав, а потім ява після нього. Моя найбільша яловичина полягає в тому, що університети вже нічого не навчають студентів про комп'ютери. Я не наймаю програмістів c #, якщо вони не знають c ++, як тил власної руки. Чому? Оскільки бути поганим програмістом занадто просто, мова стає все більш абстрактною. Вони повинні розуміти покажчики, управління пам'яттю, динамічне прив'язування тощо. . всередині і зовні, перш ніж вони могли зрозуміти C # до рівня, який я їм довіряю, щоб внести свій внесок у нашу базу кодів. Я також змушую їх боротися через створення файлів, перш ніж я дозволятиму їм використовувати Visual Studio. Однак, я люблю C # і хороший IDE, але вони хороші як інструменти, коли їх правильно розуміють. На мою думку, абстракція є найбільш корисною, коли ви розумієте деталі, які абстрагуються - це дуже стара ідея, див. Тома Аквінський про відношення абстракції до деталей.

Я думаю, що ще одна хороша вправа для розробників початкового рівня - це змусити їх написати кілька додатків за допомогою API Windows. Потім, після того, як вони закінчать його, попросіть його зробити об'єктно-орієнтованим, де кожна форма успадковується від вашого загального класу вікон. Запропонуйте їм зафіксувати цикл подій і поставити деякі покажчики функцій, відстрілюючи їх до класу форм. Тоді скажіть хорошу роботу, Microsoft вже зробив це за вас, його називали System.Windows.Forms. Весело.

Якщо вони мають бути веб-розробниками, попросіть їх написати кілька програм CGI, щоб вони зрозуміли POST, GET тощо ..., а потім викреслили сторінку. Це робить ASP.NET і PHP набагато більше сенсу.

Якщо вони працюють на чомусь нижчому рівні в мережі, змусьте їх написати кілька додатків за допомогою сокетів, перш ніж представити їх бібліотекам, які вже це зробили.

Я виявив, що це підвищує продуктивність у довгостроковій перспективі, оскільки дає їм інструменти та правильну інтуїцію для вирішення власних проблем.

Університети повинні робити це, але це не так, як ми повинні.

З цього приводу я погоджуюся з тим, що стає важче і важче знайти програмістів, котрі коштують чорт, які виходять з коледжу, головним чином тому, що вони не були відпущені, тому що їх змушували писати рекурсивні алгоритми та пов'язані списки. Крім того, вони, як правило, мали лише курси Java або .NET, і тому не розуміють проклятого в тому, як вони працюють. Все-таки абстракція є досить корисною при правильному використанні.

(..) рано чи пізно не буде такого поняття, як те, що ми називаємо програмуванням зараз

Я не згоден з цим пунктом.
Не знаючи, що таке свідомість, робота програміста безпечна.

Ось як виглядають "мислячі машини" на даний момент:

-Перемістіть тему!
-Я думала, що наша любов особлива.
-Перемістіть тему!
-Я не змінюю тему.
-Ти є! Я намагаюся поговорити про твою нездатність зрозуміти, про що ми говоримо.
-Ні навіть не близько. моя улюблена пісня битлів - по всій всесвіті. що твоє?

Я вважаю, що лише ті програмісти, які не досягли цього, є приреченими.

Наприклад, відповідь дегуманізатора :

Вони не можуть на це відповісти - які відмінності в алгоритмах Боєра-Мура та Кнута-Морріса-Пратта.

І під цим пунктом я маю на увазі - неправильно намагатися перемогти комп’ютер у тому, що їм найкраще - алгоритмам. Натомість програміст повинен допомагати комп’ютеру з контекстом, розповідаючи про проблеми, які ми намагаємося вирішити.

Самі інструменти не усувають проблем, вони просто (іноді) роблять програмістів більш ефективними.

Це як з: "гармати не вбивають, люди роблять".

Абсолютно не. На мій досвід, використання правильних інструментів розробки дозволяють швидко розвивати програми без шкоди для якості. Насправді я б заперечував, що здебільшого якість зросла через наше «надмірна залежність від інструментів». Крім того, засоби розробки можуть зменшити криву навчання та запровадити більше людей до програмування. Це, звичайно, має і зворотний бік, оскільки є набагато більше початківців програмістів, але в цілому це допомагає в творчому процесі і підштовхує технології вперед.

Чи означає надмірна опора на інструменти, що ти лінивий?

Взагалі кажучи, "ні"; але є один великий застереження.

Я почав програмувати на C ++ в університеті і мені сподобалось. На наступному терміні ми змінили VB6, і я його ненавидів.

Я не міг сказати, що відбувається, ти перетягуєш кнопку до форми і ide записує код для тебе.

Так, справді. Ваш досвід в університеті говорить про той самий застереження, який я згадав.

Якщо ви не знаєте, яку проблему вирішує ваш інструмент, або ви не в змозі вирішити проблеми, коли у вашого інструмента є проблеми, то це величезний червоний прапор. Ця обставина не обов'язково означає лінощі, але, мабуть, передбачає недосвідченість.

Я думаю, що є 2 смаки програмістів. Є програмісти, які просто програмують виконати роботу через, можливо, термін або, можливо, просто, щоб бути більш продуктивними. Я б сказав, що вони ліниві. Я просто вважаю, що вони не зацікавлені в тому, як "як" комп'ютер робить те, що робить, або "як" програма робить те, що робить.

Потім є пристрасні програмісти, як я. Пристрасні програмісти, як я, люблять точно знати, що відбувається в процесорі. Так само, як хороший психолог намагається зрозуміти, що відбувається в людській голові, прохолог, як і я, хочу знати, що відбувається всередині процесора. Таким чином, ми вчимось, розчленовуємо та аналізуємо програму та використовуємо інструменти, такі як Reflector та розбирачі, щоб спробувати з'ясувати, як працює програма.

У мене мовчазна надія, що все зміниться. Процесори не масштабують вертикально стільки, а лише по горизонталі, а ARM і т.д. в найближчому майбутньому будуть обмежені ресурсами.

Цілком можливо, що попит на програмування без перетягування зменшиться, і ми побачимо ще кілька цікавих завдань.