Живём, слаатеосподи, уже в пресловутом "двадцать первом веке".
Технологии позволяют вести практически все проекты не выходя из дома или из, снимаемой в складчину с такими же олдскульными старыми перцами, квартирки, переоборудованной под программистский "шэк". Хороший вариант. Из дома, если проект - не веб-онанизм, типа очередного интернет-магазина - особо не наработаешь. Особенно, если надо ещё и с формулками поработать-повыводить или с реальным железом повозиться. Или - порешать системные вопросы в проекте в живую с коллегами. По скайпу или ещё каким вебеэксам - не всегда сподручно...
Да, так - о чём это я, собсна?!
О катастрофе.
Она - неминуема.
На четырёх последних проектах средний возраст коллег уже вплотную приблизился к 40-45. Тематика проектов - железяки для авиации. В смысле - электроника с программами. Её обслуживание на земле. Разработка с нуля и - модернизация того, что проектировалось в 70-90-е на современную элементную базу (с (пере)проектированием соответствующего софта). Заказчики - из РФ и Европы.
Нет молодёжи в проектах. Вернее - есть, но - на уровне статпогрешности.
Где молодёжь? В аутсорсинге. Вебят. Или - "тестируют". Короче, "заносят хвосты" загранице. Не сказать, что бы и наши заказчики не оттуда. Или - платят меньше... Но - не идёт сюда молодёжь. Уровень порога вхождения и время наработки этого порога - неизмеримо выше, чем там.
Недавно проехался по знакомым. От Львова и Одессы и - до Харькова с Киевом. Посетил несколько семинаров самых знаменитых украинских "ИТ-конюшен", послушал доклады, побеседовал с народом, посмотрел людей... Пичалька. Песочница с установленными правилами и стереотипами для крысиных бегов. По кругу. Даже те проекты, что выдаются за инновационные и, прости, Господи! прорывные - лишь выцепляние багов или тестирование в базисе и наработках, сделанных за границей... Масса народа играется в бирюльки с "ведением проектов". Менеджмент откровенно играет в игру "наколи заказчика или менеджмент высшего слоя за лужей". Работает куча схем по откатам или "мертвым душам", очковтирательстве за толику малую. Посмотрел на пару проектов в здравоохранении (амерском) и автомобильной электронике (европейцы)... Ну, что сказать? Там, где мог справиться десяток человек для наработки базиса за год-полтора, сидят десятки и сотни человек уже помногу лет. Бюджеты - сумасшедшие. Возле проектов крутится море народа, совершенно не имеющих отношения к самому процессу разработки. Да её, собственно, уже нигде и нет, как я уже сказал.
Переговорил с одногруппниками и теми, с кем пересекался по НИИ, КБ и по проектам 20-10-тилетней дваности. Поколение 20-35 уже ни к чему новому НЕ стремится. Произошло закрепление стереотипа "всё уже и так сделано, зачем изобретать велосипед?" Произошло резкое падение количества молодёжи из Украины, участвующей в опенсорсных проектах, пишущих свои вещи. Даже стартапы - просто использование имеющегося наработанного материала в другой упаковке или его комбинирование.
Происходит практически полное "вымывание" направлений РАЗРАБОТКИ и ПРОЕКТИРОВАНИЯ наукоёмких проектов из совокупной украинской ИТ-отрасли. Остались только "игры в кубики" в вебе и огромные тестировочные конюшни. Есть ещё "исправление багов" и "поддержка" того, что прислали с Запада и Индии.
Тенденции чётко уже оформились. Лет даже 7-10 назад такого ещё не было. Меняться всё начало примерно тогда, когда Ющ впервые заговорил про Украину, как великую ИТ державу. Сейчас ДАЖЕ джависта нормального трудно стало найти. Вакансии С/С++ разработчика выставлены уже месяцами. При том, что и суммы зарплат там даже юниорам - какие-то нереальные начинают проскальзывать! Но людей - НЕТ. Старики - или уже в долгоиграющих "выстреливших" проектах, или - уже укатили в РФ и на Запад. А притока молодёжи на эти места - НЕТ. Физически просто нет. Все ушли в ДжаваСкрипт и Эджайл. Ещё есть прослйка, пишуших нечто для андроида и эппловской системы. Но там - те же высокоуровненвые графические свистелки с перделками на основе готовых компонентов и библиотек.
Думаю, что при таких темпах и тенденциях, лет через 7-10 из украинского ИТ (если Украина к тому времени ещё будет как-то существовать), просто исчезнут многие понятия и направления специализации работников. Будет всё - очень примитивненько. На уровне - окошек и веб-страничек, через которые будут вызываться облачные веб-сервисы.
И - всё.
варианты темных веков или новых пустошей
Комментарии
Если кто-то работал на любом ассемблере, переход на другой язык программирования не займёт много времени. Для математика - алгоритмиста программирование зачастую сложная задача.
Глупо начинать обучение программированию с ассемблера.
Согласен полностью.
Более того, уровень программиста определяется его уровнем МАТЕМАТИЧЕСКОГО мышления.
Так что если хотите вырастить грамотного программиста, ненавязчиво так стимулируйте его интерес к математике.
Акцент не верный. Мышление - логическое, абстрактное. Математики в программировании на уровне старшей группы детсада - арифметика.
Я, как-то поболе чем 10 лет преподавал олимпиадное программирование. Так, что публикую результат опыта, а не абстрактные рассуждения на тему О...
Я думаю, это особенность именно школьного подхода. Задачи специально подбираются математические. Я тоже 10 лет преподаю, кстати.
Дело не в задачах. При попытке научить детей основам программирования, они достаточно быстро разбиваются не на два класса. У одних всё получается и они сравнительно легко осваивают программирование. У других не идёт и всё тут. Так вот, идёт у тех, у кого развито математическое мышление.
Поэтому, когда я в дальнейшем смотрел браться ли за обучение или подготовку к ЕГЭ, я всегда выяснял как у ребёнка дела с математикой.
Мне приходилось общаться с университетскими математиками. Я обсуждал с ними этот вопрос. И их мнение аналогично.
А у меня почему-то все осваивают программу ЕГЭ по информатике.
У меня тоже, сдавали все, рекомендованные грамотной математичкой.
Нет. Просто надо учить на реальном железе. У меня это начиналось в одном из институтов Академа ещё в фымышуге, на реальной установке. на MACRO-11. Мозги поставили сразу и - на нужные рельсы. Снизу вверх потом пошло по всему набору уровней и технологий. Повезло просто с учителями, задачами и ситуациями.
Вот кстати да - MACRO-11! Когда пришлось пересесть на 8086, сильно поразился убожеству соответствующего ассемблера.
Вообще любой язык программирования не сложен, вопрос - как объяснять. Объяснить любой язык с позиций асм сложно. Си - просто удобная надстройка над асм. В js, например, следов асм вообще нет. Но задачи низких и высоких языков слишком разные, чтобы их смешивать.
"Для какой операционки" -- это вы сильно спросили :-)
Любому ассемблеру.
Хотите сказать, связь с операционной системой - несущественная мелочь? А в какой среде разработку вести?
Например?
Да-да, расскажите мне, как меняются коды операции в зависимости от загруженной ОС.
Учить надо любому ассемблеру, для которого есть учителя либо в котором разбираешься сам.
Вы плохо представляете, насколько сильно все меняется. Еще раз вопрос: ассемблер для какой архитектуры Вы имеете в виду? Ассемблеры для ардуино и интел "немного" отличаются.
Я очень хорошо представляю себе, как ничего не меняется.
Вас заело? Для любой архитектуры. После освоения одной архитектуры переход к любой другой не представляет серьёзной проблемы.
Трепло, ты, дружок. Сомневаюсь, что ты знаком хоть с одним ассемблером. А их много. И они ОЧЕНЬ разные.
Создаётся впечатление, что вы с трудом еле освоили один и теперь страшно этим гордитесь :-)
И, кстати, мы на брудершафт не пили.
Дайте ребёнку Спектрум.
Я лет 15 в них не смотрел, но когда-то давно так и не уловил фундаментальных отличий. И там, и там надо читать\писать в память, в которую проецируется адресное пространство периферии.
Вас смущает, что коды (машинные) операций разные или мнемоники ассемблера отличаются?
Вам знакомо понятие "архитектура процессора"? Вы знаете, что есть много разных архитектур процессоров? Ассемблер лишь надстройка над той или иной архитектурой (системой команд).
О божечки, в PIC надо переключать банки памяти перед обращением к ячейке памяти, а в AVR память линейна. В zx команда называется ld, а в x86 - mov. Как жить дальше - совершенно непонятно. Шок........
А если писать в ассемблере, не затачиваясь под конкретную архитектуру - хороший (почти любой) компилятор для высокоуровневого языка - справится лучше...
Так что - если учить "любой" ассемблер - лучше учить с/с++.
Лучше сначала изучить ассемблер, а потом уже С/С++.
На ассемблере - высок риск потерять интерес до получения чего-то наглядно рабочего. А с математикой указателей можно разобраться и из С.
И уже потом, при желании - учить ассемблер, понимая для чего он используется.
С одной стороны да. С другой стороны можно изначально придумать интересную задачу и предложить решить её на АСМе.
Учить ребенка ассемблеру - это как учить ребенка читать. Никто ведь не учит детей читать сразу абзацами, начинают с отдельных буковок и слогов. Из которых потом можно собрать что угодно. Важно мозги настроить в правильном направлении. Вот и с ассемблером так же. Если речь не идет о студенте, которому завтра надо программать под конкретную железяку, в конкретной команде, в конкретной обстановке, то учить можно любому ассемблеру, под который есть среда, литература и, хорошо бы, преподаватель. Научивишись на ассемблере под любую железяку, ребенок понимает ПРИНЦИП работы оборудования и смотрит на объекты программирования совсем другими глазами. Никакой Паскаль, ДжаваСкрипты и прочий Скретч, прости господи, даже рядом не стоит с точки зрения прививания правильных навыков алгоритмизации процесса и его воплощении в конкретрый код. А вот уже после ассемблера любой другой язык программирования под любую платформу/ОС/среду становится полным пустяком.
Все вот удивляются, откуда такое бесовское количество ошибок и дырок в программах (я не о закладках говорю - их как раз только высококвалифицированный программер может хорошо сделать)? Да все от низкой культуры программастов. Потому что подавляющее большинство даже не задумывается о том как происходит обмен данными, что код программы может жить в тех же ячейках памяти, что и данные, что существуют естественные ограничения на скорость обработки данных, что у разных перефирийных систем есть свои естественные/искусственные ограничения. Эти кодеры даже не подозревают о таких вещах как стек, регистры, страницы, режимы работы процессора и т.п. И да, я согласен с автором статьи - чем дальше, тем становится хуже. Специалиста, умеющего соображать, днем с огнем не найти. А, что бы и с компьютером на "ты" на всех уровнях (а не в экселе макрос какой набросать), и в технологии объекта автоматизациии понимать - это уже по нынешним временам штучные экземпляры, за которые конторы дерутся и предлагают уже совсем неприличные деньги.
Простите, я немного не понял почему вы мне адресовали это сообщение.
Я лично начал программировать на ассемблере в 10 лет, руководствуясь статьями из ZX Review, и именно благодаря ассемблеру я осознал, что такое есть 0 и 1 на самом деле.
И я с вами абсолютно согласен, что именно ассемблер позволяет понять суть вещей и событий.
Но параллельно с этим я осознаю, что детей, способных понять ассемблер в 10 (и даже в 15) - очень мало. Это факт.
Мне кажется, что детей-то как раз много. А вот преподавателей, которые могут их научить, нет.
Полностью поддерживаю. Сейчас многие студенты не то, что софт писать, они думают, что процессор в жесткий диск вставляется. Самолично присутствовал на экзамене группы по профилю "информационная безопасность". Печаль. И потом такие "праграммисты" кричат в сети, что основы, считай АСМ, и не важно под какую архитектуру, знать не обязательно и истинные тру-программисты пишут нейросети на питоне.... ТБМ.
Я чувствую, что повстречался на моем нелегком жизненном пути настоящий "проффесионал". Я давно мечтал узнать что такое "ассемблер для ардуино", что это за процессор-то такой ардуино? уже весь гуголь перерыл, а не могу найти.
Жаль, что Вас забанили в википедии.
Ассемблер очень привязан к железу. В пром. контроллерах в подавляющем числе - гарвардская архитектура, в персоналках - фон-Неймановская, когда и данные и программа в одной памяти. Программировать на ассемблере бессмысленно, когда есть компиляторы на Си. А вот поизучать - можно, чтобы понимать как внутри всё устроено и работает.
Нам в училище рассказывали, что архитектура у них одна - фоннеймановская, а вот классы - разные: - гарвардский и принстонский. Персоналки бывают обоих классов. Моя первая персоналка гарвардского класса - Искра-226, моя первая персоналка принстонского класса - ДВК-2. (Искра - быстрее)
Это вам наврали.
Загляните на досуге в библиотеку Сишного компилятора и посмотрите, во что он превращает любую вашу команду. Душераздирающее зрелище...
Сначала идут 10 команд, запушкивающих в стэк все нужные и ненужные регистры, затем 15 команд, проверяющих входные данные на принадлежность к диапазону допустимых значений, чтобы - ничего не сделав - швырнуть вам в лицо код ошибки при возврате, затем идёт одна или две-три команды, которые делают вам полезную работу, затем опять анализы на корректность результата и поиски чего бы вам ещё швырнуть в лицо при возврате - снова 15 команд, и, наконец, распопкивание из стэка прежнего содержимого регистров - ещё 10 команд. Итого - 50 команд накладных расходов на одну-две-три действительно делающих дело.
И в нэй усэ тило такэ...
Помнится, когда появились интеловские процессоры - долго недоумевал - что мешало им сделать трёхадресные команды вида B:=C*D хотя бы внутри процессора ...
Более - менее свобода появилась, когда перешёл на микропрограммный уровень - там тоже не без ограничений, но вы хотя бы понимаете, куда уходит драгоценное время, пока ваш результат неспешно обрабатывается на конвейере операционного автомата под чутким руководством конвейера управляющего автомата.
Но это дела прошлые...
Сейчас свобода поднялась на невиданные доселе высоты; правда, для этого пришлось переместиться ещё чуть ближе к железу - на язык описания аппаратного уровня. Последние 5 лет пользую VHDL.
Нужно что-то сложить - из ниоткуда появляется сумматор, нужно что-то зафиксировать - появляется D-триггер, нужно проанализировать десяток условий - появляется мультиплексор. И так под каждое конкретное действие - мечта идиота...
Кстати, ...
говорят, что появились компиляторы с Си прямо на RTL.
Но если его писали те же - это туши свет...
Ну, это Вы загнули! Мой LPC1226 с этим бы не справился.
Подобное я видел в PASCAL для PDP-11 - он промежуточный текст на ассемблере формировал. И даже при отключении всех проверок делал много лишнего. В итоге плюнул и все критичные ко времени выполнения фрагменты принялся писать на ассемблере.
Уж никак, вы в собранный для отладки( не релиза ) результат заглядывали.. с нулевой оптимизацией ?)
А вообще, нечто подобное там обычн делается перед вызовом всяких функций( мало ли кто и чего там додумается наворотить с регистрами.. тем более, что некоторые из них, и в самих функциях вполне естественным образом используется ).
Лучше - MIPS. Linux. + С + guile
Научите его плавать, подтягиваться, отжиматься и далее по списку. Шутка
Одно другому не мешает, кстати :-) А где-то даже наоборот :-)
Первичному пониманию "как там всё устроено" учить надо, но это относительно несложно объясняется "на пальцах" .
А на перспективу - советую учить чему-нибудь объектному (C++/C#/Java) + показать нейросети. Научить машинку объезжать препятствия и распознавать хозяина - приятный, и относительно быстрый практический результат.
*Машинка на арудинке, или чём посерьёзнее, с датчиками, с управлением с сервера - очень способствует обучению.
С++, С-шарп и Джава - НЕ объектные, а - эрзац для массово штампованных мозгов мэйнстрим-конюшен. Настоящее ОО - CLOS, Smalltalk, Self, Eiffel и Oberon.
Вот даже интересно, а вакансии на ваши "настоящие" в природе существуют? Сколько? А не в дефолт-сити?
Ну и - попробуйте сформулировать прикладную задачу в которой у ваших "настоящих" было бы абсолютное преимущество, стоящее того чтобы достать их с пыльной полки.
Пользуетесь тем, что посетители АШ не знают и не поймут смысл слов "функции высшего порядка" и "замыкания"? ;) С точки зрения парадигмы ФП любое ОО - эрзац для массово штампованных мозгов, которым даже не пытаются объяснить разницу между линейно-рекурсивным и линейно-итеративным алгоритмами вычисления факториала.
Нынче даже курс SICP уже не тот, с LISP перешли на Python и это место пришлось переписать через цикл while! Чтобы не ломать психику будущих программистов хвостовой рекурсией и каррированием.
Оно всё, конечно, красиво и занимательно. Но, помимо написания собственного компилятора/парсера - какие определяющие практические применения вы сможете назвать? Не задумываясь сильно надолго?
Вот и в MIT не смогли...
А в остальном - функциональный сахар постепенно переползает и в другие языки. Костыли, конечно, но для практического применения - хватает.
Понять бы сначала ваш вопрос. Но я уже догадываюсь, что вы разделяете мнение Гвидо ван Россума
В общем, предлагаю не устраивать на АШ выездное заседание Хабрахабра. А то после слова "гомоиконность" на нас начнут косо смотреть. "Мужики-то не знают", что ассемблер - гомоиконный язык программирования.
Думается, коллега, перспектива будет куда яснее, если удастся внятно объяснить, в чём состоят отличия между объектно-ориентированным программированием, функционально-ориентированным программированием и целе-ориентированным программированием. Тогда и нейросети будут не плюсом, а точно в кассу.
Страницы