c++ с чего начать
Средства разработки ПО постоянно совершенствуются уже с 50х годов, а кодеры до сих пор нужны в больших количествах и с разной квалификацией. Причём, кодеры зачастую получают больше всяких постдоков с PhD.
Машины никогда не будут разрабатывать ПО за людей. Если этого не случилось до AI Winter, то почему это должно случиться в ближайшие 50 лет? Какие к тому предпосылки?
Ключевые процессы в индустрии ПО неформализуемы в принципе, и поэтому там математика не играет решающей роли.
-----
Как действующий гражданин СССР именно Я таки имею возможность определять критерии советскости.
речь-то шла о
------
о недоступности ресурсов для детского технического творчества в СССР.
Это - ложь. Они были более доступны, чем на западе.
Как сейчас - не знаю - четверть века там не был...
Arduino тут примечателен тем, что
-----
Не могу обсуждать Ардуино - Я не знаком с его возможностями.
но изготавливать его самому у меня нет никакого желания
-----
Угу... Об возможности сконструировать систему "а-ка сонар" говорить бесполезно.
Как там во времена Брежнева с этим делом было?
-----
А нормально было - ножовки, напильники и надфили примененные к бруску дерева и листу металла вполне решали большую часть проблем.
Заодно с тренировкой рук - тренировались и мозги на понимание базовых основ сопромата.
Отсутствие этих навыков в руках и мозгах у современных детишек приводит к решениям в которых гибнут другие люди.
Примеров - масса. Недавний - рухнула крыша с магазине - 54 трупа. До сих пор не выяснили кто ответственен...
А теперь - контрольный вопрос - сколько мегафлоп имел Ардуино в 60-х? Пусть даже в самой развитой стране запада...
о недоступности ресурсов для детского технического творчества в СССР
я протестую против такой формулировки темы. Лично я влез в эту дискуссию только ради ответов на изначально поставленный вопрос о ПРОГРАММИРОВАНИИ. Если вас напрягает моё "во времена СССР и Ельцина", это я использовал для обозначения кооординаты во времени, а не в пространстве. Мне просто удобнее ориентироваться по российской исторической хронологии. Но можно выбрать американскую историческую или любую другую хронологию, без изменения смысла. Например, "во времена Картера и Шмидта". В конце концов, это раздел не о политике. И я ничего не имею против изучения программирования на "Микро-80", хотя сегодня есть лучшие альтернативы.
А теперь - контрольный вопрос - сколько мегафлоп имел Ардуино в 60-х? Пусть даже в самой развитой стране запада...
В том-то и дело, что "ни сколько", и в этом мой тезис: сейчас по части программирования простора для творчества как минимум не меньше, чем тогда, а с учётом доступности наборчиков типа тех, которые с Ардуино, в изучение программирования вносится дополнительный элемент интересности, даже каких-то примитивных роботов на Ардуино разрабатывают. Здесь подразумевается, разумеется, что помимо Ардуино у человека уже есть ПК, что сегодня обычное дело.
Вот, например, игрушечный робот на базе Ардуино:
https://www.hackster.io/myusufkosoglu/table-cleaner-voice-...
управление голосом по синезубу.
а кодеры до сих пор нужны в больших количествах и с разной квалификацией
Тяжкое наследие прошлого. 
кодеры зачастую получают больше всяких постдоков с PhD.
Тяжелый неблагодарный труд должен как-то поощряться. А вченые просто удовлетворяют личное любопытство за казенный счет.
Машины никогда не будут разрабатывать ПО за людей
Этого и не требуется. Речь шла о том, что РОЛЬ программеров будет снижаться - и она уже снижается - при возрастании роли алгоритмистов-математиков. Программер (толковый) вполне может заниматься разработкой или модификацией алгоритмов, но на каком-то этапе все равно понадобится голова математика. Когда эффективность алгоритмов станет определяющим фактором (ну, к примеру, быстродействие компов подойдет к теоретическим пределам), тогда и платить математикам будут больше, чем самым лучшим программерам. А пока соблюдается некая условная справедливость. Тем не менее, тенденция вполне отчетлива. Повторяю: речь не о ЗАМЕНЕ человека машиной, а о перераспределении значимости между участниками процесса разработки.
Ключевые процессы в индустрии ПО неформализуемы в принципе, и поэтому там математика не играет решающей роли.
Да начхать на процессы в индустрии ПО. Они будут так или иначе подстраиваться под требования заказчиков. А заказчику в будущем будет требоваться в первую очередь все более эффективный алгоритм. И индустрия ПО может хоть на ушах стоять, а без математиков не обойдется. Просто еще прокатывает экстенсивное наращивание вычмощности за счет "железа" и/или "кластеризации".
а я думаю, что распределение ролей в обозримом будущем будет примерно таким же, как и сейчас, потому что на каждого математека с его новым алгоритмом нужен будет как минимум один кодер, который сможет написать эффективную РЕАЛИЗАЦИЮ (а это разные задачи и разные роли) и ещё один кодер, который будет фиксить баги и вобщем поддерживать реализацию и тестер, который сможет проверить, на сколько то, что заявлено в спецификации соотв. действительности на практике. Каждая гениальная идея будет (как и было всегда) порождать пирамиду обслуги, без которой эта идея останется разве что на страницах специализированных научных журналов. И мне пока не понятно, как предел роста вычислительных ресурсов сможет принципиально изменить ситуацию в обозримом будущем. При том, что индустрия до сих пор не может отказаться от технологически устаревших ЯП типа C++. Даже в mission critical системах. Т.е. даже тот теоретический задел, по которому давно уже написаны горы статей и защищены армии докторантов, этот задел не всегда востребован бизнесом.
В принципе, можно порассуждать на эту тему.
Допустим, классические компы достигли пика производительности, а масштабируемых квантовых компов или другой принципиально отличной от классической аппаратной базы так и не появилось.
Вобщем, можно считать, что это уже случилось сегодня.
Что это будет означать кроме возможного коллапса Интел? Люди все равно будут использовать ПО, и нужно будет его модифицировать.
А сколько десятилетий ещё можно будет фиксить баги в легаси коде?
Не будет экстенсивного роста за счёт использования нового железа, но могут открыться новые ниши для создания кастомных более эффективных решений для
конкретных задач. А здесь больший простор как раз для кодерских задач, т.к. вся теория уже известна, и ничего нового изобретать не нужно, а грубо говоря, "надо такой же костюм, но с перламутровыми пуговицами". С профессии программиста снимут, наконец, совершенно незаслуженный нимб элитарности, и она станет всего лишь одним из хороших и нужных традиционных ремёсел.
Новые алгоритмы будут, как и раньше давать существенные толчки прогрессу, но бизнес по-прежнему не будет ориентироваться на теорию (от математика к кодеру), т.к. прогресс в теории практически не то, что не контролируем, его даже сложно предсказать.
А если всё ИТ и около-ИТ навернётся медным тазом по каким-то пока неизвестным причинам, то и интерес к области со стороны теоретиков также угаснет, и они тоже будут не нужны обществу. IT это же не наука, и григориев перельманов тут быть не может, просто как класса.
Да начхать на процессы в индустрии ПО. Они будут так или иначе подстраиваться под требования заказчиков. А заказчику в будущем будет требоваться в первую очередь все более эффективный алгоритм. И индустрия ПО может хоть на ушах стоять, а без математиков не обойдется. Просто еще прокатывает экстенсивное наращивание вычмощности за счет "железа" и/или "кластеризации".
заказчику объяснят, что возможно, а что - нет или "может быть". Выдумывание новых алгоритмов - это как раз из серии "может быть". Т.е., может быть его выдумают через месяц, а может быть, вообще никогда не выдумают.
Речь шла о том, что РОЛЬ программеров будет снижаться - и она уже снижается - при возрастании роли алгоритмистов-математиков.
Не согласен. Понимание важности алгоритмистов будет расти (но медленно, часто проблема решается "а давайте купим еще 20 серверов", если у нас что-то с O(n^2)) а роль программистов снижаться не будет.
Я знаю что вы не любите сравнений, но все же попробую. Это как сказать что при постройке дома роль строителей снижается при возрастании роли архитекторов. Пока нет роботов-строителей с ЧПУ нужны думающие строители. Как и строителю, программисту (в обозримой перспективе, имхо следующие лет 20 ничего не изменится) приходится думать что он делает. Иначе будет налеплено такое, что проще написать заново чем переделать. "Думающий" программист нужен просто потому что математик не может описать что ему надо (поставить ТЗ) так, чтобы можно было не думая взять и написать программу. Да, кусок, отвечающий за, например, 4/3 решение проблемы коммивояжера, можно будет реализовать по бумажке. А всю обвязку - откуда будут поступать данные на вход, как и куда отдавать решение, а в каком виде все это представлять, а что делать если надо параллельно для 1000 запросов обсчитывать, а как мы будем пользователей авторизировать - должен решать программист / архитектор ПО. Как только аналитики начнут все это описывать в формальном виде - программистов можно будет разогнать и генерировать код автоматически, а математики-аналитики вместо 5 страничек с формулами будут писать 1000-е страничные талмуды описывающие все-все-все. Пока что есть только частные решения. Те же модели workflow. Моделировать в UML тот еще геморрой... А искать ошибки в сгенерированном коде - оооо... Не дай бог. Знаю 2 больших фирмы которых так задолбали расходы связанные с генерируемым кодом, что они инвестировав несколько десятков миллионов и несколько лет времени слезли с генерации (низкая роль программистов) и вернулись к написанию кода ручками (высокая роль программистов). У моего работодателя расходы на обслуживание кода снизились с 2008-го примерно в 2 раза.
А заказчику в будущем будет требоваться в первую очередь все более эффективный алгоритм. И индустрия ПО может хоть на ушах стоять, а без математиков не обойдется.
Я знаю "индустрию ПО" с другой стороны... Заказчику за редкими исключениями требуется "чтобы было красиво", "чтобы работало как раньше" и "чтоб все делалось само", а! и "а справа внизу чтоб на зеркальной поверхности наш 3-д логотип крутился". И донести до них мысль что надо инвестировать деньги в разработку более эффективного алгоритма... очень сложно. "А чо, сейчас-то работает? не пытайтесь с нас больше денег содрать!" Заказчик понимает только в еврах. Ему не нужен алгоритм, ему нужно чтобы было быстро, качественно и самое главное дешево сейчас. Даже "вложив сейчас 100к мы предположительно сэкономим через 3 года миллион" понимает хорошо если один из 10. "А дайте мне гарантии что мы этот миллион сэкономим".
Лично мне с математиками приходилось сталкиваться один раз - обсуждали возможность для страховки на лету просчитывать риски. Был скрипт то-ли на R то-ли вообще матлабовский, который по ночам подсчитывал пару сотен коэффициентов, а риски на лету считались исходя из этих значений, а заказчик хотел сделать "чтоб прям щас и все точно". Но слился когда стали выяснять а с какой точностью и что конкретно ему надо на лету считать. Ну, примерно как вы сейчас AlexNek-а пытали.
Все, что Вы тут написали, безусловно верно. Но речь шла о другом. На данный момент ситуация такова, что развитие средств генерации кода еще недостаточно, а выч.мощности позволяют наращивать их экстенсивно. Я же говорил о случае, когда вычмощности будет затруднительно наращивать таким методом, а средства генерации кода станут гораздо более развитыми. Возможно, речь даже не о 20, а о 50 годах, но таковой момент когда-нибудь наступит. Уже сейчас есть отдельные области, где именно алгоритмы определяют качество программно-аппаратного комплекса. Ну, к примеру, на борт АПЛ невозможно впихнуть супер-мега-компьютер, и размеры сонара тоже ограничены, плюс, гидрология бывает настолько сложной, что даже сонар с большой антенной не спасет. Поэтому дальность обнаружения часто будет определяться алгоритмом обработки акустического сигнала на компьютере с ограниченной мощностью. Это лишь частный случай, возможно, нехарактерный для современной практики, но я вижу, что постепенно потребность в математической оптимизации растет. Есть запросы производителей кунштюков для IOT - там часто нужно впихнуть какое-нибудь распознавание в крайне ограниченную память при малой вычмощности.
Я надеюсь, что жизнь заставит заказчиков повышать свою компетентность. Хотя, конечно, это может и маниловщина. В любом случае я вангую постепенное повышение заработков математиков-алгоритмистов на фоне кодеров. Я знаю, что многие программеры выполняют функцию алгоритмистов - образование информатика вполне позволяет - поэтому включаю таких специалистов в число первых
Плюс, развитие средств анализа данных, не требующее особых навыков программиста - те же R, Matlab, Origin позволяют юзеру легко и непринужденно создавать весьма сложные скрипты для манипуляции с данными без глубокого понимания принципов функционирования "железа"
и ОС.
те же R, Matlab, Origin позволяют юзеру легко и непринужденно создавать весьма сложные скрипты для манипуляции с данными без глубокого понимания
Просто офуеть!
Тема все равно остается о том, с чего бы начать ребенку знакомиться практически в программированием. И "где взять программу"... А вы как политики: неважно о чем речь, я должен использовать любую возможность, чтобы показать, какой я крутой и правильный.
Помогите лучше ТС. Хотя я бы ему уже сейчас посоветовал просто погуглить "с чего ребенку начать программировать". Гугль выплюнет много гораздо более полезного, чем рассуждения карликов о будущем мироздания.
зы. сам не пойму, откуда во мне столько желчи : )
В том-то и дело, что "ни сколько"
-----
Угу...
Вот только в СССР можно было "выпаивать" и что-то собирать... Я, например, видел ПАЛ-декодер собранный на транзисторах... а на западе - либо покупался готовый модуль, либо не покупался... при этом как он работает - покупатель мог не иметь никакого понятия... это, кстати, так и осталось...
хотя сегодня есть лучшие альтернативы.
-----
На сегодня - да, есть.
А по состоянию на "во времена Картера и Шмидта" - их не было ни в СССР, ни на западе.
Но в Союзе, с его обязательным и бесплатным средним образованием, обеспеченность кружками и конструкторами была выше западной.
Так что в следующий раз стоит сравнивать с какой-нибудь пигвинией - там нет помнящих что было и может сойти любая фигня...
зы. сам не пойму, откуда во мне столько желчи : )
-----
Это на тебя попали брызги из моей отрыжки... 
Вернемся к нашим баранам: с какого языка начинать.
С++ отличный язык (и становится еще лучше), но начинать с него не есть гут.
Начинать нужно с функциональных языков, таких как Haskell, OCaml, или LISP.
Эти языки дисциплинируют мышление: учат мыслить рекурсивно и избегать "побочных эффектов".
P.S. И вообще, лучше конструктор, чем деструктор!.
Начинать с ЛИСПа - жОстко. Думаю, это весьма изысканный способ отбить у ребенка интерес к программированию. Круче только, наверное, если начинать обучение с Perl-а.
По мне, чем ближе язык к естественному (ну, типа, старорежимного "если...то...иначе...все"), тем лучше. Выскажу крамольную мысль, но старый добрый "паскаль" - как бы ни охаивали его нынче - для _обучения_ _программированию_ достаточно хорош. Привить ребенку основы алгоритмов, научить оптимизировать код можно вполне. Тут главное не язык, а учитель - кто и как будет учить.
Да бл..., полтора года мариновали (с хором и акробатами (с)), тут забудешь, пожалуй.
к исходному вопросу: http://pascalabc.net/primeri-programm/programmi-i-algoritm...
спасибо всем, пока взяли уроки на питоне, на каникулах будет чем заняться