Comments 324
Пропущен целый слой индустрии - собственно разработка движков/компонент браузеров, движков баз данных, движки AI-фреймворков. А то получается так что sql и js существуют, а то что их исполняет рождается само по себе. Ну и тот же движок tensorflow это не python, а просто имеет python-биндинги.
И тут возникает внезапно C++ или его модные/современные заменители (golang, rust), которые не подходят ни в одну из описанных вами категорий
Мой юбилейный (1000-ый) комментарий!
Для меня разработчики делятся на две категории, те которые могут с нуля написать компилятор и всех остальных :) Первые это инженеры. Другие это ремесленники. Индустрии нужны и те и другие.
Любое деление на категории и генерализация автоматически упрощает картину мира и сразу вносит недостоверное его понимание. Будете выглядеть как та блондинка, которая встречала динозавра с вероятностью 50%.
Да нет, я не делю на самом деле никого. И да, конечно, я оцениваю уровень со своей колокольни. И естественно, умение написать компилятор это не критерий. Есть масса бестолковых программистов которые могут написать бестолково спроектированый компилятор. Я просто взял то, что для меня является потолком в практическом понимании компьютерных систем.
На самом деле мне в работе нужно знать к кому и с какими вопросами можно обратиться, когда мне нужен совет. Потому что у меня, как автоматизатора, широкий, но не глубоко развитый набор знаний и навыков. И если я хочу быть уверен, что этот совет основан на фундаментальном понимании устройства системы, то в таком случае мне нужен инженер (часто это например архитектор на проекте). Если вопрос практической направленности то тут, выбор к кому обратиться будет шире. Условно говоря, regex помочь написать может любой, а подсказать как лучше сделать какую-то сложносоставную систему, типа фреймворка - нет. С инженером можно говорить практически на любые айтишные темы, с линейным разработчиком - скорее выборочно. Во всяком случае на в моей практике так и было.
Условно говоря, regex помочь написать может любой, а подсказать как лучше сделать какую-то сложносоставную систему, типа фреймворка - нет. С инженером можно говорить практически на любые айтишные темы, с линейным разработчиком - скорее выборочно.
Сложносоставную систему, типа фреймворка вы для кого делаете? Для инженеров или линейных разработчиков?
Вы зря недооцениваете пользу от общения с "линейными разработчикам". Даже если под этой категорией вы имеете ввиду неопытных разработчиков.
Нет ничего лучше, чем комментарий или мнение разработчика, который не хочет или не понимает "сложносоставную систему". Это всегда спасает от перегиба в дремучие, понятные и полезные только лично вам, аспекты космолётостроения.
Есть опытные линейные разработчики. Спрашиваешь у него про другой фреймворк, а он ни к чему другому даже руки не прикладывал. Т.е. узкий специалист. Но в своей области он точно наступил на все грабли какие есть, поэтому с вопросами по этой системе я пойду к нему. Или человек который восемь лет сидит на одном проекте и делает одну и ту же работу. Хорошо делает. Но ничем больше не интересуется. Таких примеров масса. Ничего в этом такого оскорбительного нет. Это линейные разработчики, им дали борозду, они и пашут и хорошо пашут. Качественно.
Если я знаю, что наши разрабы делают что-то похожее или сталкиваются с подобными задачами я пойду к ним. И были такие случаи, где я знал что они применяют какой-то шаблон, который может мне быть полезен, и я спрашивал как его применить в моем контексте. Но если мне нужен принципиально "другой взгляд" или какой-то принципиально/философский вопрос, то я пойду к инженеру/архитектору. Потому что у них них чаще видение широкое. Они могут смотреть на вопрос с разных сторон, а не только со стороны своих личных предпочтений. (Тоже не все)
И что все обиделись, как будто я "водителя-механика" назвал "шофером". Нет. Есть водитель-механик, а есть инженер-конструктор. Разные классы задач.
В универе была история, проходили алгоритмы сортировки, я после занятия подхожу к преподавателю и спрашиваю, мол если есть алгоритмы сортировки, есть те которые делают обратную задачу, приводят массив в идеальный беспорядок. На что преподаватель ответила: "А зачем?". И есть масса людей которые скажут: "а зачем", но есть те, кто знают, что это целый подкласс проблем, а в частности подобный алгоритм крутится на функции shuffle в музыкальном плеере.
Ну а если я делаю систему для других, то естественно я буду спрашивать конечного пользователя как ему удобнее и почему.
Обиделись все на то, что вы пренебрежительно отозвались о линейных разработчика, как будто бы всех их назвали бестолковыми.
После вашей разъяснений я бы сказал, что это не "линейность", а "экспертность". Ну и называть людей экспертами, всегда приятнее.
Насчет широты взглядов. Рекомендую вам ознакомится с тем, как люди понимают сам процесс изобретений и научного прогресса (например, есть история про изобретение фотоаппарата). Похоже всё сводится к тому, что изобрести новое из ничего невозможно. Новые изобретения — наблюдение и совмещение удачных идей из разных сфер деятельности, порой самых неожиданных.
В этом плане мнение даже самого узконаправленного специалиста иногда помогает сделать лучше решение инженера самых широких взглядов.
Вообще интересно если так по интернету шарить, то впечатление, что профессии как системный программист нету вовсе, что макоси, виндоусы и линуксы растут сами по себе, и размножаются почкованием, а новые компьютеры попадают к нам из торговой площадки. Где весь айтишный хардкор тусуется?
Мне на работе однажды попался человек он работал когда-то в антивирусе доктора веба. Вот он мог тебе про винду рассказать всё.
Т.е. по сегодняшним меркам таких людей бы причислили к специалистам. Высококвалифицированный разработчик узкой направленности. Но это как-то оскорбительно сказать, что такой спец - узкой направленности. Ведь он справится с любой программистской задачей, просто в его области он обладает преимуществом опыта.
А, ну вот, я сам тоже пришел к этому определению. Это экспертность. Он эксперт в своей области. И да если ему дать программировать фронтенд, он скорее всего довольно быстро полезет в дебри смотреть как там node.js плохо устроена внутри. А это совсем не нужно заказчику. Т.е получается уровень экспертности это не то, что обязательно нужно повышать. Для некоторых видов задач, она может оставаться низкой.
Но тогда мне не совсем понятно как можно, например, за восемь лет не повысить свой уровень экспертности? Вот коллега мой с бывшего проекта: работа и система одна и та же, он сетует на то ему не дают курсы повышения квалификации до архитектора, Но при этом получается, если бы он хотел быть архитектором он бы им стал у себя в команде. Значит ему каких-то софт-скиллов не хватает? Так-то он весьма умен, аккуратен и работящ, а вырваться из колеи не может. И это не единичный случай. Были еще такие работники без амбиций. ЗП вовремя приходит и нормально. Я за это время успел три команды поменять и зарплату почти утроить. Мне жалко времени сидеть и делать линейные задачи. Мне с них опыт не капает. Время утекает слишком быстро, я это чувствую. Поэтому суечусь как-то, хочется сделать больше, использовать свой ресурс эффективнее. Помочь еще одному проекту настроить автоматизацию, чем написать тридцать новых тестов в существующей системе. А вот на одном проекте со мной работал молодой специалист, он сказал что ему нравится "не пыльно" клепать тестики по шаблону. И остался клепать тестики дальше. Видимо от человека зависит.
Но тогда мне не совсем понятно как можно, например, за восемь лет не повысить свой уровень экспертности?
Мне жалко времени сидеть и делать линейные задачи. Мне с них опыт не капает. Время утекает слишком быстро, я это чувствую. Поэтому суечусь как-то, хочется сделать больше, использовать свой ресурс эффективнее.
А вот на одном проекте со мной работал молодой специалист, он сказал что ему нравится "не пыльно" клепать тестики по шаблону.
Могу на это ответить только рассуждениями из собственной опыта.
Увлекаюсь программированием независимо от того, приносит это деньги или нет. Работаю над собственными проектами и на выходных, и параллельно основной работе.
Раньше удивлялся, почему многие люди вокруг не вкладываются в изучение технических дисциплин, с такой же упоротостью, как и я, ведь это так интересно и перспективно!
А потом как-то резко осознал, что у этих людей кроме экспертности в своей профессии есть много чего, что для меня недостижимо: семья и дети, опыт восхождения на горы, навыки в оперном пении, собственная группа по игре D&D. Всё сразу стало на свои места, и как-то полегчало.
На заре индустрия состояла исключительно из экспертов и научных деятелей, целиком увлеченных компьютерами. Но сейчас это обычная работа, не нужно удивляться что многие умеют делать тоже что и вы и получить за это деньги без каких-либо романтических и героических замыслов. Лучше поинтересуйтесь чем они таким интересным занимаются вне рабочего времени.
Раньше удивлялся, почему многие люди вокруг не вкладываются в изучение технических дисциплин, с такой же упоротостью, как и я, ведь это так интересно и перспективно!
Смотрите, есть хитрость: вы можете вкладываться в изучение технических дисциплин в обычном режиме, без упоротости. И иметь время на хобби, на семью, кататься на лыжах, петь в балете, танцевать в опере и так далее. Это ведь интереснее, чем быть просто крутым техническим спецом.
И что все обиделись, как будто я "водителя-механика" назвал "шофером". Нет. Есть водитель-механик, а есть инженер-конструктор. Разные классы задач.
"Обиделись" все на то что вы по какой-то непонятной причине решили что разработчик компилятора (т.е. программы превращающий команды процессору из текстового формата в бинарный) разительно отличается от веб-разработчика. Что программа для монопольной переработки файлов многократно сложнее например чем система высокочастотного трейдинга или современный графический движок.
Такое себе деление конечно
Беспорядок - это тот же порядок но со своими критериями. Если вам нужен некий абстрактный хаос, то решения не существует. А упомянутый shuffle реализуется банально выбором позиции от random при выборе очередной композиции.
А упомянутый shuffle реализуется банально выбором позиции от random при выборе очередной композиции.
Это годится, если вас не волнуют повторы. А вот если вам нужно содержимое массива с данными выдать в случайном порядке (мне, например, в каком-то скрипте на Powershell для Exchange, например, потребовалось перетасовать список п/я в случайном порядке), но без повторов, потребуется случайная перестановка элементов массива. Впрочем, алгоритм для нее тоже есть, и весьма несложный.
Опять же перестановка оптимальна тут но не обязательна, мы можем тупо айдишники проигранных треков кидать в хэшмап как ключи и перед выбором рандомом чекать проигран трек уже или нет, либо же перед рандомом бить по айдишникам весь интервал плейлиста на несколько кусков, рандомом выбирать кусок и рандомом в рамках диапазона брать трек для проигрывания. Вы завязались на конкретный алгоритм перестановки и не видите других решений. И да, даже та же яндекс музыка при shuffle иногда вкидывает повторы
Ну не просто же так, а для построения картины (модели) мира и происходящего в нем (безобразия). Понятное дело что можно переуссердствовать, но и отрицать полезность тоже не стоит. Не медитировать же все время на "великое ничто".
Ну Вы тоже, фактически, делите на тех, кто "умно сказал" и остальных :))
Люди "любят" говорить глупости, потом долго извиняться за них :)
Нет, я совершенно "за" Ваш текст и мнение. Тут без вопросов. Только "Сейчас к людям надо помягше, а на вещи смотреть ширше!" :)) (С) Операция ''Ы'' и другие приключения Шурика
А что в вашем понимании "с нуля"?
То же самое, что и идиома "from scratch".
С нуля имея какой-то высокоуровневый язык программирования? С нуля имея только ассемблер? С нуля имея справочник машинных кодов и программатор? С нуля, имея пачку проводов и тактовый переключатель? С нуля, сперва написав собственный микрокод для процессора? С нуля, разработав собственный процессор? С нуля разработав собственный компьютер?
Вот да, отличный комментарий. И на каждый последующий вопрос в целом нужен свой спец.
В познавательных целях можно книжку почитать в духе 'writing a compiler in go', но это не поможет сделать что-то толковое без опыта) имхо, вместо изучения кучи языков стоит сфокусироваться на области, в которой ведется работа на текущий момент
Тоже придерживаюсь такого подхода, плюс сам работаю в вебе и перед глазами прошло довольно много фуллстеков, которые условно могут писать на .net бэк, на фронте юзать реакт или vue, а по факту что во фронте, что в бэке их знания достаточно поверхностные и узкоспециализированный спец всегда сделает задачу в своей области лучше чем фуллстек, плюс учтет большее количество нюансов как при оптимизации выполнения, так и в самом языке и фреймворке, на котором крутится реализация, тупо потому что у него больше опыта в области и он погружен в нее лучше
Нет, не осилю. Я уже ответил в другом комментарии что для меня это потолок практического осмысления. Но я и не пытался, так в общих чертах, "чего-то там абстрактное синтаксическое дерево" помню и все. Хотя те кто это делал говорят, что это не самая сложная задача.
Я и рекурсию написать не смогу сходу. И вообще я себя программистом не считаю. Так, скриптики односложные пишу.
Ну и вопрос — литературой можно пользоваться или
Ну так в этом и дело. По учебнику любой напишет. Если ты понимаешь задачу и способ ее решения сам разворачивается у тебя в голове, то тебе не понадобится учебник. И никакого ограничения по времени нет, это только на собеседованиях нужно.
Если можно, то напишут процентов 95. Если нет, то наверное теже 95, но уже получится говнокомпилятор.
Странно оценивать успех даже не спросив о технических требованиях к задаче. Я думаю что процент сильно ниже, если брать срез всего народа в IT.
Не обьяснить как работает, а написать. И не интерпретатор, а компилятор. Он должен ведь не только прочитать и распарсить, а самое главное что, перевести инструкции в машинный код который бы соответствовал бинарному протоколу операционной системы. Т.е. нужны знания из нескольких дисциплин информатики, чтобы охватить эту задачу с начала и до конца. А до уровня операционной системы большинству программистов сегодня вообще не приходится опускаться. Многие программисты на Javа могут даже не знать как работает JVM, которая выполняет их код.
Я думаю если распределить всех айтишников по глубине знаний то получится вафельный рожок, перевернутая пирамида, где 80% болтаются где-то в верхнем слое системных абстракций. Т.е. на уровне языка программирования и никогда не спускались ниже. И это нормально. Я на каком-то довольно свежем докладе слышал, что по оценкам специалистов для того чтобы угнаться за будущими потребностями индустрии (в частности в автомобильном секторе) нужно ускорить темп разработки ПО в три раза. В три. Поэтому прикладных програмистов должно быть сравнительно много. Этот тот слой который первым принимает на себя удар. И только если им не удается впитать задачи приходят системные интеграторы, а за ними системные программисты и развивают системы под новые потребности индустрии. Вот например потребности криптомайнинга пробили всю пирамиду насквозь аж до железа.
для того чтобы угнаться за будущими потребностями индустрии (в частности в автомобильном секторе) нужно ускорить темп разработки ПО в три раза.
И конечно же тогда мухой появятся новые аккумуляторные батареи, по емкости равноценные соляре. Вот это - главная проблема автоиндустрии и не только. Вторая - ну, может быть, полноценные автопилоты, но и то, для большинства дорог в мире ,а местами и в Штатах они - из разряда фантастики.
Написать под бекенд типа LLVM или QBE (который собственно и будет в конце концов выполять перевод в машинный код) действительно не самая сложная задача. Я ведь не имею ввиду, я имею ввиду все полностью, с нуля, без ничего, вот у тебя язык программирования на операционке, и пиши на нем. А после компиляции, компилированый исполняемый код должен работать под этой операционной системой. Там уже не все так просто.
Почему вы считаете что перевод уже отпарсенного текста в маш код это проблемы? Это же по сути самая простая часть: буквально словарь который переводит лексемы в маш коды. Ну да, надо этот словарь иметь. Но глобально задача то вполне по силам нормальному джуну.
Написать грамотный парсер(если никогда не писал) выглядит более сложной задачей.
Это же по сути самая простая часть: буквально словарь который переводит лексемы в маш коды.
Если вы не пишите компилятор для чего-то типа Pascal, который специально проектировался так, чтобы быть компилируемым в один проход — в какой-то момент вам придётся писать аллокатор регистров. Хотя бы такой, который будет тупо всё на стек спиллить.
Разобрать арифметическое выражение, хоть со скобками, хоть без – это вообще простейшая задача для школьников. Там по лексической структуре сразу всё ясно. К написанию компилятора это имеет отдалённое отношение.
Извините, но если вы не в состоянии написать сходу рекурсию, то ваше мнение о разработке совершенно нерелевантно.
Вот и тут удивился, бесконечную рекурсию написать наверное каждый школьник сможет, что-то типо
func test(int x) {
print x;
test(x++);
}Не вижу проблем (да, по итогу написанное мной либо упадет по памяти, либо выйдет за range инта, тут зависит от конкретного языка и компилятора, но суть не в стабильности, а в демонстрации самой рекурсии), тем более вопрос про рекурсию это стандартный вопрос на собесе для джунов, те же числа Фибоначчи например, это как раз та самая база без которой ты не то что программистом не можешь считаться, но и линейным говнокодером, тебя даже на стажировку не возьмут
Я и рекурсию написать не смогу сходу.
wat?
Не-не, не так просто написать говнокомпилятор. Это как бы такое программирование второго порядка, требует большой абстрактности мышления.
Думаю, что процентов 80 за месяц не отладят до такого состояния, чтобы легко не находился ошибочно транслируемый пример. А процентов 20 – за всю жизнь.
Хотя во времена старика Уэзерелла подразумевалось, что это рядовая задача для изучающего программирование.
Спасибо за отсылку! Мне эта книга еще не попадалась.
Даже у Уэзерелла написание компилятора не считалось рядовой задачей:
"Не каждый студент возьмется в одиночку за создание компилятора" (стр. 158 в русском переводе)
Это предполагалось направлением специализации (спецкурс), т.е., далеко не для всех изучающих программирование. И оценивалась такая работа как курсовая (минимум — семестровая).
У меня собственно год и ушел на написание реального компилятора/интерпретатора. Учебный год, разумеется. Если грубо — по полтора-два часа в день в течение примерно восьми месяцев.
Не понятно, с какого перепуга написание компиляторов стало таким убер-критерием.
У нас в вузе народ писал компиляторы в качестве курсовой и многие справились без проблем. Стали ли они потом все великими "инженерами"? Отнюдь.
Вы смешиваете область деятельности и уровень работника. Это совершенно не связанные, ортогональные понятия. Это настолько очевидная мысль, что даже странно об этом писать.
Я где-то читал в комментарии на Quora что операционки, виртуальные машины, компиляторы и игровые движки считаются сложными в разработке системами. И я чисто интуитивно согласен с таким мнением, хотя сам не пробовал писать ничего из вышеперечисленного.
А как на Ваш взгляд? Какие программные системы самые сложные в разработке? Уклончивый ответ типа "Те к которым плохо прописаны требования" не принимается :)
Я работал над одной коммерческой ОС. Сложность там не "hard", а скорее "complex". Много компонентов, разные подходы к их исполнению и к архитектуре, из которых нужно выбрать подходящий. Написать минимальную ОС типа загрузчик + планировщик + менеджер виртуальной памяти тянет на хороший курсач (а то и диплом), а вот поддерживать дальше всякие libc, сдк, драйвера - это уже в одно рыло просто не затащить, просто потому что этого слишком много.
Собственно, все то же самое относится и к компиляторам с движками. Самому не так уж сложно накатать что-то на коленке, но оно так и останется игрушкой, ибо в аналоги уже вложено over 9000 человеко-лет, а у вас столько нет.
На мой взгляд, у вас есть желание поделить людей на две категории - "вот те - дааа" и "вот эти - фуу". И смотреть на одних снизу вверх, а на других сверху вниз. Действительно ли это необходимо?
Судя по тому, как многим не в то горло попал мой комментарий, складывается, а точнее подтверждается, впечатление, что у программистов в принципе нет и не может быть авторитетов. Т.е это и есть проявление обратной стороны одной из тех трех добродетелей, о которых говорил Ларр Уолл.
Для меня ориентироваться на лучших - норма. Поэтому я всегда стараюсь искать среди хороших лучших, а среди лучших самых лучших.
Интересно, что когда лучших из лучших ищет работодатель, и для этого заставляет писать код на бумажке, или делать еще какую нибудь гиманстику, потому что не в состоянии по разговору определить профессиональный уровень собеседника - то это тупо, но ладно.
Предлагаю всем на следующем техническом собеседовании сказать:
- Знаете, уважаемый, судя по заданию у Вас есть желание поделить людей на две категории.
- Эмм-м...ну-у-у... э-э-э.., как бы да. Одни будут у нас работать а другие нет!
Начинающие художники и музыканты зачастую берут пример с работ мастеров, музыканты, поэты и писатели берут пример с работ мастеров. А с кого берут примеры программисты? Вам удастся назвать имена тех, с кого Вы брали пример в своем профессиональном становлении? Любопытно, что сделать это не так то и просто. Интересно, почему?
(Тут не надо путать "учился у" и "брал пример с". Все учились у Дядюшки Боба, Дональда Кнута или Джефа Сазерленда, но с них никто не берет пример)
P.S.: Как мало люди склонны к рефлексии, а ведь это интересно, понять, что делает нас такими какие мы есть.
P.P.S: И да я понимаю, чем задел мой комментарий людей и прошу прощения за неудачную формулировку. Но по смыслу все еще считаю, что в разработке есть задачи требующие высшей, а может и наивысшей квалификации, а есть работа таковой не требующая. Квалификация определяется по большей части объемом понимания системы, и навыками пригодными для решения задач.
Дело не в рефлексии программистов. У программистов давно есть градации - джун, мидл, сеньор, тимлид, архитектор. Эти градации не точны, они размыты, и у разных людей или компаний они могут означать разное. Но эти градации работают. Они дают ответ на вопрос "Насколько хорошо человек решает задачи?". И в этой градации нет оскорблений. Хочет человек вырасти - набирается опыта и растет.
Я бы сказал, что ваш способ градации "написал компилятор или нет" - достаточно оторван от жизни. Это не относится с задачами, которые стоят перед программистами. Учитывая, что компилятор за свою жизнь написали 2-3% программистов, это выглядит просто, как попытка "обоснованно" унизить 97% программистов. Поэтому такая градация никому и не нравится.
Если использовать немного другую формулировку, например "Меня всегда восхищали программисты, которые написали свой компилятор", ни у кого бы не было вопросов. Потому что здесь нет унижения)
Я бы сказал, что ваш способ градации «написал компилятор или нет» — достаточно оторван от жизни.
Особенно — в наше время, когда уже давно существует такое средство как yacc (акроним Yet Another Compiler Compiler), который получает на вход грамматику, а на выходе выдает код на C, который делает разбор по этой грамматике.
Помнится, лет уже довольно много назад помогал знакомой делать курсовик как раз с использованием этого самого yacc. Короче, сложность задачи — курсовая для студента — понимаете.
Ну что поделать, слово не воробей ¯\_(ツ)_/¯ .
Лучше на хабре получить очередное отрезвляющее напоминание, что сначала нужно думать, а потом говорить, чем ляпнуть что-нибудь бестактное среди людей с которыми тебе потом работать и удивляться почему у всех лица каменные.
Насчёт компилятора не знаю, а интепретатор Бейсик подобного языка для микроконтроллера писал на сишнике, но при этом я вэб разработчик и 90 процентов своего рабочего времени клепаю сайтики, так кто я?
Сложность написания компиляторов преувеличена.
Будучи юным специалистом написал свой язык скриптовый(с JIT компиляций), потому что... не осилил интеграцию Lua в проект.
А время учитываеися?
"Могу хоть сейчас" и "Могу через год, когда изучу тему" это и то и другое "Могу" но как говорится есть нюанс
А я делю на тех, кто может решить конкретную задачу самостоятельно и тех, кому на каждый чих нужно ТЗ. И вот обычно те, кто может с нуля написать компилятор, нифига не помнимают в реальных бизнес-процессах и чтобы он сделал что-то полезное нужна целая команда, которая скажет, что делать)
Тут можно посмотреть еще с другой стороны - а что нужно бизнесу? Если бизнесу нужен разработчик, который будет гонять джисоны из БД на фронт и обратно и он готов платить, и именно за это - зачем ассемблер и все остальное?
"нужно бизнесу" измеряется количеством публично доступно вакансий в какой-то конкретной стране/городе/регионе? ну если так, то в условном верхнем урюпинске "нужны бизнесу" максимум 1С-ники и "специалисты" по изготовлению сайтов на тильде
на самом деле, есть еще и другие факторы, а именно порог вхождения и востребованность специалиста в вашем регионе/стране/штате (многие вакансии, к сожаленью, закрыты для удаленки). с другой стороны - желание рискнуть и стать высокооплачиваемым с пониманием того что за жизнь может придется релоцироваться не один раз
Автор, не обижайтесь, но какая-то бесполезная статья, созданная с непонятной целью.
Уже более 6-8 лет успешно программирую на С и С++ микроконтроллеры, DSP-процессоры, различные Cortex-A. Применяю ОСРВ и Linux (портирую с использованием ассемблера при необходимости на архитектуры, где до этого их не было).
При этом не бум-бум в CSS, HTML. Ниразу мне не пригодились зачатки этих знаний со времен университета - я далек от вэба так же, как и топор от плавания в воде. Да и не хочется мне в эту сферу даже смотреть (Так же, как например в финтех)
Я не настоящий программист/специалист ?
Не обижаюсь, у всех свое мнение. Как раз и хотел услышать, что считают другие люди.
Программированием микроконтроллеров не занимался, не могу что-то внятное ответить.
По поводу CSS, HTML могу сказать только то, что в "списке базы" я их не упоминал. Все приведенное должно помочь при желании покопаться в какой-то смежной сфере, если захочется ее поменять. Для вас это может быть не актуально.
JS уже универсальный язык и подходит для работы вне браузера, забыл упомянуть его в таком контексте.
Сейчас тенденция, что вся нагрузка переходит в браузеры, и лагерь делится на два типа: тех, кто разрабатывает движки и тех, кто на их основе что-то создают.
Знание JS скорее минус, чем плюс, потому что засоряет разум
Язык как язык. Как и любой язык не идеальный и со своими особенностями.
Не пускать новое знание в свой мозг боясь его "засорить" это по крайней мере странно. Ведь мозг засорить невозможно. В мозге встроен мощнейший сборщик мусора. Он сам выкидывыет все что ему не нужно, трудно и непонятно.
Засорит невозможно а вот на работать паттерны мышления запросто. И когда разработчик с подходами одной области приходит в другую он непроизвольно начинает их применять. В голове джуна который освоил весь этот набор на хорошем уровне будет творится такой хаос, что когда он придёт в конкретную область на конкретный проект, ему (и команде) будет тяжело. Если новую область изучает уже достаточно опытный разработчик (верхняя планка мидла и выше) уже проще, он понимает отличия и их причины, он уже отделяет их, понимает применимость, хотя эффект все равно наблюдается. Тут как с изучением языков, если ребёнка с младенчества параллельно учить сразу нескольким обычным языкам то он будет их смешивать и путаться. Ну или как с "мышечной памятью" у борцов единоборств. Мозг отлично нарабатывает паттерны, любого уровня, от рефлексов до серьёзных абстракций, и когда наработал старается их использовать, меняет он их очень неохотно.
Мне кажется, вам бы понравилось в средние века. Там многие считали, что «знание» в принципе от сатаны, засоряет не только разум, но и душу. А вот вера в кресты — единственное спасение.
А некомпетентность, демонстрирующая подобными формулировками, засоряет комментарии.
тех, кто разрабатывает движки и тех, кто на их основе что-то создают.
вряд ли где-то сидит гуру-программист который знает наперед что и как нужно сделать, чтобы обычные ремесленники творили свои поделки. Симбиоз нужен, фреймворки не на ровном месте появились, а решали какие-то проблемы. Точно так же они не могут развиваться просто потому, что кто-то умный считает "так правильно", а потому, что у прикладных разработчиков появляются новые потребности
По-хорошему, чтобы ответить на этот вопрос, нужно писать отдельную, обстоятельную статью, с анализом рынка и т.п., в общем, работа это немаленькая. Да и кстати говоря, на эту тему на хабре в последнее время уже были пара очень хороших статей (ссылок прямых к сожалению не дам, но можно найти через поиск). Мне сильно проще отвечать на конкретные вопросы.
Я попытаюсь написать в совсем общих чертах с точки зрения наемного работника.
В России есть своя специфика, связанная в первую очередь с тем, что очень много вакансий и проектов связано с военкой. На обычные проекты попасть можно, но придется фильтровать вакансии, работу возможно придется искать какое-то продолжительное время. В целом работа будет сильно зависеть от руководителя - процессы редко где налажены, как заведено в конкретном месте - так и будет. ЗП находятся около нижней границы рынка, здесь сейчас все очень плохо. Жена, которая работает сеньором (C#, бэкенд) в обычной, среднестатистической компании (чисто софт) зарабатывает в ~2 раза больше меня. Ну и в целом условия такие, что про удаленку никто не слышал, и т.п. и т.д.
На Западе ситуация лучше - процессы более налажены, скорее всего почти всегда у вас будут нормальные условия труда, наличие нужного оборудования, и так далее - общая культура производства выше. Зарплаты тоже выше, но не драматично.
Грубо говоря, и сильно обобщая - из всего IT, embedded пока находится в роли догоняющих, и особенно сильно это проявляется в том, что область сильно консервативна - вам никто не даст писать прошивки на С++ или Rust, если вы не сами определяете технологический стэк. Никто не будет отправлять вас на конференции для повышения квалификации т.п. - если вы работаете там, где все это есть - вам очень сильно повезло.
Сейчас еще стоит учесть текущие и дальнейшие события, которые для этой сферы могут принести в перспективе как и очень много хорошего, так и причинить много разрушений, т.к. сейчас очень много проблем с элементной базой - например, ПЛИСы не достать вообще никакие, даже китайские.
А вот я до сих пор ощущаю недоученность из-за того, что всё, что касается теории типов прошло мимо меня. Алгоритмы и теория сложности - да, а вот типизация почему-то мимо. Приходится навёрстывать задним числом, что довольно сложно.
Как по мне, зачем идти в вуз на программиста, если этих знаний нет до поступления? В программисты должны идти по призванию, а не потому, что модно и это надо бизнесу. Это как научится дизайнерству и т.п.
Высшее образование знания систематизирует.
Когда самообучением занимаешься - круто прокачиваешь отдельные темы, но при этом они часто между собой связи в мозгу не имеют, а также отдельные темы просто проходят мимо.
Вышка дает систему: связи между блоками и заполнение пробелов.
Без вышки вполне можно жить, но хорошая вышка помогает.
Систему и связи даёт практика, а не ВУЗ
Смею не согласится. Практика касается конкретных тем и не дает базу.
В моей области чтобы трансформировать вектор из локальных координат в мировые - нужно умножить его на матрицу. Программист который с этим сталкивается знает что надо умножить.
Но если он сталкивается с транспонированной матрицей - это тупик. Ничего не работает. При этом глядя на содержимое матрицы он и понять не может что она транспонирована. Потому что внутри "магия", а не понятная математика.
ВУЗ же дает понмиание и что такое матрица, и что там внутри и как оно работает.
Если постоянно работать с матрицами, придет понимание, что нужно дополнительно почитать. ВУЗ ускорит это понимание, не спорю, но вовсе не обязателен.
Ну конечно нет никакой проблемы в том, что у тебя пробелы в знаниях, если ты не сталкиваешься с задачами когда эти пробелы нужны.
А если сталкиваешься - вынужден разбираться и пробела уже нет.
Проблема в том, что чувак с пробелами - не специалист. Потому что "крутой" прогер, который придет на высокую зарплату и споткнется о транспорнированную матрицу не будет в команде восприниматься спецом.
Биться башкой о все проблемы, чтобы стать в итоге специалистом всё знающим выглядит странным путем. И долгим.
Ну и вернемся к первоначальному тезису: практика НЕ дает систематизацию. Она лишь закрывает те пробелы, с которыми сталкиваешься.
"крутой" прогер, который придет на высокую зарплату и споткнется о транспорнированную матрицу не будет в команде восприниматься спецом
Это стереотип, что крутой прогер должен знать, как транспонировать матрицу - вовсе нет! Он может быть прекрасный программистом и, например, не разбираться в матрицах, безграмотно писать и т. д., так как не пользуется этим ввиду того, что нет такой необходимости. А если он делает движок для игр, то он с этим будет сталкиваться и получит именно те навыки, которые ему нужны. Это будут как раз систематезированные навыки (которые получены путем практики). Только практика позволяет выработать нужные нейронные связи, на это нужно время, в ВУЗе такого не будет. Ну научишься ты решать типовые задачки на матрицы, только толку от этого немного, если тебе это не интересно и ты не идешь в GameDev/ML. Программист крут не потому, что он умеет применять ВУЗовскую программу, а потому, что успешно решает задачи, которые требуются и пишет достаточно хороший код для того, чтобы его поддерживать (либо недостаточно - опять же, все зависит от задач, требований и много чего еще). И если меня в команде не будут воспринимать спецом из-за незнания транспонирования матрицы - то мне будет все равно, так как это уже не моя команда, а люди, которые ввиду недостаточной информации пытаются сделать выводы и попадают под действие когнитивных искажений.
Крутого специа берут в команду чтобы решать крутые задачи.
Так что "он в этом спец потому что 100500 раз делал" не прокатывает. 100500 раз делал и сделает еще раз - это мидл.
Хотите называться сеньером - будьте готовы решать то, что никогда не решали. И вот тут база и нужна. Потому что без базы нет видения цельной картины и способности решать те самые "крутые" задачи.
Начнем с того, что специалист становится специалистом как раз потому, что решает задачи, которые до этого никогда ее решал. И спустя тысячи часов обучения на своих ошибках он становится специалистом в какой-то области и в ней способен решать в том числе и те задачи, которые он не решал, в голове уже построены нужные абстракции. За это время он успеет много чего прочитать/отпрактиковать/опробовать. Ему вряд ли встретиться что-то абсолютно новое, так как он уже в этом сидит, он так или иначе будет иметь точки соприкосновения. Конечно, если не давать задачю по ML бекендеру. Такой ерундой уж точно заниматься не следует.
Вывод следующий - за тысячи часов практики специалист получит необходимую базу и будет решать задачи. 5 лет ВУЗа ему скорее всего что-то дадут, если там будут предметы, покрывающие его специальность, но это лишь позволит ему быстрее развиваться как специалист, но никак не ограничит его в дальнейшем.
Я обратил внимание, что вы занимались 3D-движками. Ну, значит ваша база транспонирование матриц. И многое-многое другое, что вы получили за все время обучения и практики. Ваша обишка только в том, что вы пытаетесь всем эту базу навязать, которая вовсе не обязательна в других сферах разработки. Это ваша база, как разработчика игр. И я очень сомневаюсь, что эти знания нужны frontend- или backend-разработчикам, например.
В программисты должны идти по призванию, а не потому, что модно и это надо бизнесу.
Угу, и в адвокатуру надо идти по призванию, а не потому что закрываемый по 228.4 готов отдать здесь и сейчас 1.5 миллиона лишь бы съехать по недоказанности или хотя бы по условке. Или в милицию идти, потому что верю в дядю Степу, а не потому что за помощь в (не)находе угнанного кайена отдают 16000 долларов. Или во врачи идти потому что хочется лечить людей, а не ожирение бумажника, вымогая 6 миллионов за курс химии в блохе. Чем ИТ сектор так уникален, что от него ожидается работа исключительно по призванию?
В айти, кроме программистов и быдлокодеров, кормится еще куча разных спциалистов. Тестировщики, админы, сетевики.. Требования очень разные.
Без конкретики в SQL, FP и JS всё отлично. Как и (в меньшей степени) без shell.
Чтобы быть хорошим специалистом нужно знать:
Язык компьютера (железок) - С++
Язык операционной системы - С++
Язык работы с операционной системой - С++
Язык прикладных программ для платформы - C++
Язык браузера - С++
Язык баз данных - С++
Язык функциональный - метапрограммирование на шаблонах С++
Язык документации и литературы - английский
а английский вам зачем? доку тоже на плюсах пишите
самодокументируемый код, да, надо будет исправить
а английский вам зачем? доку тоже на плюсах пишите
А читать доку? А гуглить тоже на плюсах? Надеюсь, что это был такой сарказм.
Чтобы вот так не было:
void PoluchitSummu(int vneshniyPrixod, int vnutrenniyPrixod)
Это пример утрировнный, конечно(хотя и такое встречается). Но даже в больших проектах у профессионалов код выглядит плохо, когда люди совсем не знают английского.
Чтобы быть хорошим специалистом нужно знать:
... C++
... C++
... C++
C++ не знает никто, включая его автора, следовательно, хороших специалистов не существует !
Получить job offer на позицию программиста С++
После первых семи пунктов английский будет очень легко выучить - они там почти все слова из C++ взяли.
Язык компьютера (железок) - ассемблер
Язык операционной системы - С
Язык работы с операционной системой - Bash/PowerShell
Язык прикладных программ для платформы - Python/Swift/Java/C++/C#/Ruby/..
Язык браузера - JavaScript
Язык баз данных - SQL
Язык функциональный - Haskell/Lisp/Elixir
Язык документации и литературы - английский
А потом годами на полную ставку докерфайлы писать и всякие AWS-ные джейсоны.
Название статьи не соответствует ее смысловой нагрузке. Получается название ради хайпа?
Хороший специалист должен уметь переходить от одного языка к другому, от высокого уровня к низкому.
Кому должен? Работодателю, чтобы тот заработал на новый феррари быстрее?
Не зря говорят, не сотвори себе кумира. Master of all trades, master of none.
А вообще хорошая статья. Чем выше кажущаяся кривая входа в профессию, тем меньше программистов в будущем. Чем меньше программистов в будущем, тем больше зп у меня. Хорошая статья.
Так то да, но все же стремиться к этому стоит. В первую очередь такое полезно для себя любимого.
Например если ты не зациклен на одном языке - у тебя больше возможностей для поиска работы, выше мобильность. Это касается кстати не только языков программирования, но и человеческих - некоторые рынки требуют своих специфичных языков.
С другой стороны распыляться тоже нехорошо - все имеет свою цену: за одно и тоже время ты освоишь хорошо один язык или средне два.
На начальном этапе это будет тормозить развитие и нежелательно. Но после - почему бы и нет?
Начинается такое обычно для себя, из интереса - пощупать новое. Потом постепенно твои возможности растут, и становится доступна миграция между языками, можешь +/- эффективно что-то делать и там и там. А там недалеко и до смены сферы на более комфортную или параллельная работа на два лагеря.
Это уже каждый сам решает куда двигаться. Тут важно, что развитие в принципе дает такую возможность, позволяет не застаиваться в своем болоте.
Кому должен?
Себе. Я в целом с автором не согласен. Но программист всегда должен себе. Потому что если он делает то что должен - то становится более востребованным и высокооплачиваемым.
Чем меньше программистов в будущем, тем больше зп у меня.
Это работает только до определенного предела. Если программисты станут слишком дорогими - начнется стагнация рынка.
Это хорошо заметно по переходу продаж в онлайн.
Лет 10 назад каждый Вася Пупкин нанимал веб программиста и получал себе сайт.
Сейчас стоимость поддержки своего сайта выросла, а эффективность упала.
В итоге Вася Пупкин идет на яндекс маркет или озон, платит коммисию, но не имеет проблем и трат на свой сайт.
А если бы стоимость поддержки своих сайтов не выросла так сильно - по прежнему делали бы отдельные сайты, пусть это было бы не так эффективно как продаваться на аггрегаторе.
Второй момент - смерть конкретных направлений. Предположим я крутой программист на условном фортране. Когда вокруг полно программистов слабее - много компаний выберут этот язык, чтобы реализовывать свои задачи: потому что компетенции вокруг много. При этом я сам легко найду работу, потому что легко покажу свою крутость по сравнению с средним предложением на рынке.
Если же порог входа слишком высокий - средних специалистов не будет, а значит этот язык не будут выбирать для использования. Не будет вакансий. А значит и для меня, супер крутого специалиста, не будет работы. Или, как минимум, выбор будет сильно ограничен.
Подводя итог: выгодно быть крутым специалистом, рядом с толпой середняков.
Но программист всегда должен себе.
"Должен" это внешний локус контроля. Всегда. Внушенный долг - это навешенный рычаг манипуляции. Общества, семьи, рода, начальника, партии и т.д. Себе человек хочет.
Если же вы считаете, что ваша субличность "программист", должна основной личности, это звучит так будто вы сами на себя повесили рычаг манипуляции, чтобы заставить себя быть или оставаться программистом.
Жить, чтобы программировать, или программировать, чтобы жить?
Чем меньше программистов в будущем, тем больше зп у меня.
Тут я несколько постебался все же. Но если все затронуть эту тему.
начнется стагнация рынка.
Она вероятно и так начнется рано или поздно. Человек не будет пользоваться 5 ОС, 5 браузерами, 5 офисными пакетами, 5 почтовиками, и тд. Поэтому в этих сегментах итак нет массовой потребности в программистах. Взрывной рост потребности в программистах произошел только в вебе и в мобилках. Но и эти рынки рано или поздно придут к насыщению потребности, как в продуктах автоматизации, так и в программистском ресурсе эти продукты производящем.
Вася пупкин идёт на яндекс не за заменой сайту, он идёт туда за аудиторией. Васе чтобы сформировать такой трафик, причём заинтересованный и таргетированный, придётся отдельно под это сформировать компанию или неслабый отдел, нанять кучу людей (среди которых хорошо если 10% будут разработчиками) и вложить кучу денег, и все это без гарантий. А Вася просто хочет торговать своими пылесосами телефонами. У него кстати скорее всего есть свой сайт, но основные заказы все же приходят с площадок.
В остальном все верно, меня тоже всегда улыбали такие шутки, как будто у рынка постоянный фиксированный запрос на абстрактных программистов, и чем их меньше тем выше зп. Разве что чуть поправлю, благодаря динамике развития рынка ( по крайней мере сейчас), выгоднее быть крутым специалистом среди крутых специалистов. На рынке IT слишком много денег, потребностей и идей, поэтому спрос на рынке труда IT всегда превышает предложение (если мы говорим о крутых специалистах). то есть работу все равно найдёте, но крутые специалисты уже научились ценить и продавать себя, так что чем их больше тем активнее растёт конкурентная ЗП. ну и опять же конкретный язык (фреймворк, технология) становятся популярнее (есть специалисты) , что опять же повышает спрос. Великий парадокс активно растущих рынков, высокое потенциально предложение повышает спрос и тем самым снижает предложение, но спрос при этом все равно растёт, и все это почти без участия цены в этой формуле. на стабильных рынках такое редкость. Плюс большое количество хороших специалистов в одной области может сформировать новые тенденции, технологии и подходы в ней, которые, упс, тоже требуют достаточно высокой квалификации, а значит нужны крутые специалисты. Это достаточно хорошо видно на феномене зарплат девопсов. Обычные сисадмины сидели и делали свою работу, за хорошую но не особо высокую зарплату. Потом началась виртуализация, докер и прочие облака. Но компании и продукты не спешили переезжать, не было понимания что это даст, не было человека который объяснит почему это полезно. Постепенно облачные технологии развивались, админы тоже обучались, компании начали переходить, что спровоцировало ещё большее развитие, появилась концепция девопса который может не уметь в *nix но зато хорошо умеет в кубернетус и прочие, компании начали переходить ещё активнее, это стало менстримом, и образовался дефицит девопсов. Команды уже не представляют жизни без CD, компании хотят на aws а не десяток-сотню серверов покупать и ставить в дата центр, и страдать с ними, потребность стабильная и растёт, с ней активно растут зп девопсов. Когда предложение хоть как то догонит спрос - зарплаты хороших специалистов не упадут. А вот если бы те сисадмины (ну и техлиды с техдирами конечно) забили на "что-то новенькое" а действовали золотому правилу "хороший админ это админ который отдыхает, потому что у него все настроено и работает" то aws, docker и прочие могли бы потухнуть за неимением спроса, без них бы не появилось оркестрации и прочей магии, а облака так и остались бы просто возможностью дёшево и быстро (с точки зрения инфраструктуры) запустить проект и удобно его масштабировать на начальной стадии, а потом уже покупать сервера, на а бедные админы продолжали бы выяснять почему у сервера в дц глючит винт и где купить новый, все это за зп в пару раз меньшую чем сейчас. Короче невидимая рука А игроков иногда рулит покруче рыночной потребности и пузырей.
С каждым годом требуется все меньше строчек кода для решения поставленной задачи.
Сколько строк кода надо, чтобы вывести один пиксель по центру экрана? Мне кажется, тут число строк кода только растёт.
Базовое понимание бизнеса и мира ещё бы не помешало. Некоторые 80% времени формашлепят фичи для 5% пользователей. - А зачем?
Ну и сложность используемых теологий для того чтобы потом красиво вставить в резюме.
Можно было сделать в 3х проще. - А зачем?
Немного всё совсем не так:)
1. Язык компьютера (железок) - ассемблер
Правильно писать "Архитектура ЭВМ" ( взаимодействие с железками ).
2. Язык операционной системы - С
Большинство драйверов действительно пишется на С. Но язык операционной системы - это язык, на котором написана ОС. Он может быть любым, даже asm.
3. Язык работы с операционной системой - Bash/PowerShell
Это называется одним словом - shell, и это не язык операционной системы. Это командный интерпретатор - обычная app, которая имеет доступ к ОС, а взаимодействие идёт через другие процессы/app. Обычно говорят, что это командная строка.
4. Язык прикладных программ для платформы - Python/Swift/Java/C++/C#/Ruby/..
Конечно на каждом из перечисленных языков можно прикладные app делать, но и на уровень системного программирования можно опуститься. Правда есть нюансы.
5. Язык браузера - JavaScript
JS - это встраиваемый язык, который больше всего распространён в браузерах. Но он совсем не язык браузера. Например, есть интерпретатор Node.js транслирующий JS в машинный код (движок V8). А язык браузера - это протокол, который браузер понимает.
Ну и т.д.
Вывод: Путь в IT надо начинать с предмета "Архитектура ЭВМ".
Вот и согласен и нет. Когда мы учились в университете нам говорили "не стоит изобретать велосипед", но в тоже время для решения задач нельзя было использовать готовые либы\фреймворки а надо было писать свой велосипед. Оно и понятно, надо же как-то проверить твои базовые навыки и оценить. Но, вот если придумали уже быструю сортировку, мне зачем свою выдумывать если мне надо просто отсортировать и все?) Кто-то работает инженером и создает платы для управления электросамоварами, а кто-то делает начинку для марсохода, на мой взгляд оба инженеры, просто задачи разные.
Про то, что вы пишете (практически) только про веб-разработчиков, полностью опуская как разработчиков всего нижележащего (ОС, компиляторы, движки, фреймворки итп), так и забываете прикладников из других отраслей (где помимо Python и JS - C#, Java, Kotlin, Swift, C++ и чего только нет) уже сказали.
О том, что это все может быть ненужно для того, чтобы быть спецом - тоже сказали.
Но я не соглашусь с тезисом.
демотиватор
сложности с которыми можно столкнуться по пути и ответить на вопрос, что делает кодоклепателя настоящим специалистом.
Разве это демотиватор? Я трогал и работал с кучей технологий из разных направлений, потому что это было интересно в тот или иной период. Разработка GUI приложений под винду на WinAPI, Qt (C++), Windows Forms, WPF (C#). Веб разработка на ASP.NET и весь этот вот HTML, CSS, JS, React, Vue. Разработка мобильных приложенйи на Java, Kotlin. Программирование микроконтроллеров на C. Библиотеки и утилиты под линукс на C и Python. Разработка модулей ядра Linux. Компьютерное зрение на OpenCV. Роботы на ROS. Нейронные сети с Keras. OpenGL. Ассемблер. Ядро ОС. Где-то в универских годах пылятся трансляторы и verilog.
Я дилетант широкого профиля (в основном - всё-таки Си), и не такой успешный, как 25-летние сеньоры, получающие 500к/нсек. Но ничуть не могу сказать, что столкновение с кучей технологий на разных языках, стеках и уровнях абстракции - это какой-то демотиватор, отталкивающий от работы программистом. Наоборот, это просто офигенно, и возможность потрогать какую-нибудь технологию, иногда совсем из другого конца стека технологий - это приятно и интересно.
С ЯП низкого уровня согласен - знать нужно, не обязательно хорошо, но пощупать стоит, и желательно вглубь: "Code: The Hidden Language of Computer Hardware and Software" дает неплохую базу, как и старые советские детские книжки времен dos. Ну а если удалось "пощупать" cpu изнутри, например писали что-то под микроконтроллеры - это вообще замечательно: многие из "железных" проблем и абстракций становятся ближе и понятнее, как и уникальные возможности, которые на уровне прикладного софта просто недоступны.
Понимание ООП+ФП тоже нужно. В новых курсах некоторые уже начинают сразу оба подхода параллельно давать: где-то применим один, где-то другой. А заодно рассказывают и о других, уже устаревших, подходах - для целостной картины мира.
Все это начинает играть где-то со 2-3 года опыта, когда рефакторинг выходит на значимое место.
Что касается остального - оно часто опционально, и зависит от области деятельности. Многие могут за всю практику так никогда и не столкнуться с тем же html. У каждого на рынке сейчас своя специализация: то-то пишет драйвера, кто-то прошивки, кто-то сайты, кто-то приложения, а кто-то вообще какие-нибудь внутренние модули абстрактной большой системы, которые никакого интерфейса наружу вообще в принципе не имеют.
Там, где нужна интерфейсная часть, везде своя специфика: где-то достаточно cli, где-то требуется gui, ну а где-то web-интерфейс или какое-либо апи.
По БД тоже самое - кто-то хранит данные в текстовых файлах, кто-то пользуется sqlite, кто-то взрослыми СУБД, кто-то работает через апи другой системы, кто-то даже в памяти все хранит (и, что странно, вполне успешно - недавно такая статья тут уже была), а кто-то вообще ничего не хранит. Отсюда и соответствующие потребности.
Но в целом SQL хотя бы в общем виде знать нужно - это наиболее распространенное решение для хранения данных. Хотя бы на уровне "не пугаться незнакомых слов". Как минимум это поможет сэкономить силы и время, когда и если потребность в БД придет - тот же sqlite можно куда угодно подпихнуть при необходимости, готовое и доступное решение в любом случае лучше попыток изобрести что-то свое.
А что касается web-интерфейсов - основы html еще можно по-быстрому освоить, а вот углубляться в верстку и фронт думаю не стоит, это отдельная большая область знаний, ее лучше оставить соответствующим специалистам. Эта область слишком динамичная, без постоянной практики не удержаться. Ради разовой потребности смысла погружаться мало, под разовую задачу лучше найти специалиста конкретно по фронту - будет быстрее и качественнее, чем самому что-то изобретать.
Сейчас такое время, когда важно даже не столько что-то уметь, сколько знать о существовании какой-либо возможности или технологии. Такие знания расширяют твой инструментальный набор: если ты слышал о какой-либо технологии, у тебя уже больше возможностей, чем у того, кто о ней не слышал - если потребуется, найти документацию и освоить технологию всегда можно, а вот заранее узнать что такое вообще в принципе существует и возможно - это уже не так просто, нужно постоянно расширять профессиональный кругозор. Те, кто не слышал про технологию, вынуждены будут изобретать свой велосипед, фактически делающий тоже самое, но хуже, к тому же еще и дольше/сложнее/дороже, чем воспользоваться готовым.
После слов «Да, теперь можно знать только один язык, чтобы писать программы. » я закрываю эту статью и даже читать не буду. Загляну сразу в конец «Но стать настоящим специалистом без всего остального будет проблематично.» и понимаю, что вы вводите людей в заблуждение. Писать можно программы на одном языке и зваться программистом на этой языке - это факт и если рынок вам за это платит вы можете этим заниматься хоть 100 лет. Но на рынке труда надо знать сейчас намного больше языков и иметь больше знаний, чем это было лет так 20 назад. Так что с одной стороны вроде проще стало программировать с помощью готовых библиотек, но с другой стороны стало сложнее из-за множества языков и быстрого отмирания разных направлений. Кто-то сидел делал сайт наикрутейшие на флеше, миллионы рублей стоили...и где они? Уроды, даже через вебархив не смог взглянуть и всплакнуть :) Так что все умрет...но где-то и останется и скорее всего останется как раз не веб, а обычная локальная программа на любом умершем языке может жить на виртуалке. Не, у кого-то может и сайт так живет, только для него обычно намного больше надо, да и что за жизнь такая одному. Короче, идите вы туда, куда хотите и если деньги платят, то почему бы и нет...ну или не платят, но есть интерес, то почему бы и не программировать под древние компьютеры...ну, просто так, кому же это в виде увлечений и нравится.
Вы написали перечень смелых утверждений, которые нуждаются в серьёзной аргументации. В Вашей статье нет никаких стоящих подтверждений выводов, потому становится грустно от того, что ожидал прочитать статью и задуматься о вопросе, а на деле прочитал какой-то текст.
Я бы не рекомендовал читать данную статью кому бы то ни было, тем более начинающему программисту.
Во-первых, как уже писали, айти - это далеко не только программисты. Во-вторых, пугать начинающего фронтендера тем, что ему в будущем нужно будет изучить ассемблер, чтоб стать "хорошим начинающим специалистом" - абсурд.
Я занимаюсь профессиональной разработкой более 17 лет и ни разу не сталкивался даже отдаленно с Haskell/Lisp/Elixir. А вот чего действительно у многих нынешних программистов не хватает - так это знаний основных комбинаторных алгоритмов.
Можете дать ссылку на хорошее руководство / пособие по алгоритмам, желательно с минимумом теории и максимумом практики.
Возможно вам стоит посмотреть в сторону каких то онлайн курсов на udemy/coursera/яндексе, там, как правило, встречается больше всего практики (пример: https://practicum.yandex.ru/algorithms/).
Ну а чего не указали какой-нибудь бесполезный язык который может потребоваться в будущем, например Q# (для квантовых компьютеров)
Часто вижу что даже "писатели" на крестах и решетке не знают битовых операций, что уж говорить про всякие там, прости господи, java. Но все гордо называют себя программистами. :(
Начну с банальности: программист занимается созданием программ — решений задач, используя для этого некий исходный материал. Материал, из которого программист делает программы — это абстракции: некие идеальные сущности, обладающие определенными свойствами.
Но материалом программисту могут служить не всякие абстракции, а лишь абстракции, реализованные в реальной жизни чем-то материальным, что может работать и исполнять программу самостоятельно, а не только в голове человека (этим программирование отличается от, например, математики).
Обычно реализации абстракций имеют слоистую структуру: абстракции определенного слоя (иначе — уровня) реализуются на базе абстракций более низкого уровня. И этих уровней может быть много. Один пример я все-таки приведу, а то, наверное совсем непонятно будет: веб-приложение сделанное на базе фреймворка (первый уровень) для языка JS (второй уровень), исполняющееся в веб-браузере(третий уровень), написанном на языке высокого уровня, например C++ (четвертый уровень), откомпилированном в систему команд определенной архитектуры процессора (пятый уровень), которые команды процессор исполняет в рамках своей микроархитектуры (шестой уровень), реализованной электронными элементами — транзисторами, конденсаторами и т.д. (седьмой уровень).
Такое слоистое построение абстракций, используемых программистом, резко упрщает его работу: в идеале программисту не нужно задумываться, что там происходит на нижних уровнях.Но это — в идеале.
А в нашем реальном мире реализации абстракций, с которыми программист работает, практически всегда являются неполными и неточными, или, как говорят — абстракции имеют дыры (или, используя выражение-кальку с английского — «протекают»). И это осложняет работу программиста: ему приходится заглядывать через эти дыры на нижние уровни и работать с тамошними абстракциями. Насколько осложняется работа зависит от разных факторов. Например — от качества абстракций, грубо говоря, как много дыр они имеют. А еще — от требуемой эффективности использования тех устройств реального мира, которые будут исполнять программу.
Дыры в абстракциях делятся, в целом на два класса. Первый класс — это ограничения, они возникают из-за того, что абстракция реализована не полностью. Типичный пример (ещё один, к сожалению) — абстракция натуральных чисел, которых бесконечно много, реализованная челочисленным типом данных, который имеет максимальное значение, и при превышении этого значения «что-то происходит»: что именно — зависит от рализации, но всегда совсем не то, что ожидается от натурального числа. И это поведение приводит, в общем случае, к ошибкам в программе.
Но, на самом деле, ограничения это не так страшно: их можно сделать частью абстракции, а потом следить за тем, чтобы они не нарушались. Сложнее с другими дырами, влияющими на эффективность реализации абстракций. Пример (все-таки ещё без одного примера не обойтись): хотя программисты, даже работающие напрямую с архитектурой и системой команд процессора (а тем более — с более высокими уровнями абстракции), как правило, используют абстрактный процессор, выполняющий команды с одной скоростью и чисто последовательно, и память, время доступа к ячейкам которой не зависит от истории доступа, реальные современные процессор и память устроены совсем не так. И, если требования к эффективности программы достаточно велики, то программисты этого и более высоких уровней вынуждены для успешной работы учитывать дыры в абстракциях процессора и памяти.
Таким образом, именно из-за несовершенства абстракций, появляется требование к хорошему (а то и к обычному) программисту, которое фактически изложено в статье — способность работать на разных уровнях абстракций, понимать эти уровни. Иначе говоря — изучать многое за пределами того уровня (например, фреймворка), которого, в идеале, было бы достаточно для реализации программы решения задачи. С точки зрения развития и раскрытия возможностей человека это даже хорошо, но вот с точки зрения экономики, это плохо — повышаются требования к работнику достаточно массовой профессии, то есть — снижается число людей, способных ее освоить, и растет время, требуемое на обучение этой профессии. Иначе говоря: увеличивается цена труда такого работника и издержки производства, в котором он задействован.
Но, увы, наш реальный мир — он такой. И куда он пойдет — неизвестно: с одной стороны, появляются все новые уровни абстракций — например, 30 лет назад не было ни браузеров, ни JS — в которых тоже неизбежно сеть и будут дыры, с другой — абстракции уточняются, а влияние дыр сокращается (например, из-за роста производительности оборудования). Потому лично я совета идущим в айти — ограничиваться ли только одним фрейворком или отлодить с сторону все приятные дела и учить много всего — дать не могу.
Ну пока экономика и опыт миллионов компаний и проектов говорит что выгоднее масштабировать горизонтально на универсальном и дешёвом железе, чем изобретать дорогое железо и все уровни абстракции вверх под конкретную задачу. Исключения редки. Само собой они будут расти, но в ближайшие 30-50 лет вряд ли стоит ожидать что количество кастомного железа перевалит универсальное, опять же с точки зрения экономики и проектов, в штуках без проблем перевалит.
В вашем спойлере «TLDR» не то, что принято считать под «TL;DR».
Время, все упирается во время. Слои как вы сказали множатся, плюс растут горизонтально, плюс проекты усложняются и к каждому слою повышаются требования для входа и работы. Плюс внутри слоев появляется все больше абстракций (внешние сервисы, инструменты, фреймворки, хранилища данных, шины данных, альтернативные языки и технологии и прочее). Нельзя быть специалистом во всем. А лезть в область в которой ты не специалист часто опасно для проекта. Поэтому широкие знания того с чем соприкасаешься (на уровне понимания возможностей, областей применимости, плюсов, минусов, схем использования) и глубокие той области и инструментов с которыми в основном работаешь. Первое нужно чтобы понимать где лучше отдать другим, или какой инструмент лучше использовать для специфический задачи. Второе - для работы самому. Разработка давно уже коллективная работа. Подключить специалиста по нужному профилю лучше чем пытаться что-то сделать самому. Написать, при проблеме, разработчикам инструмента или сервиса надёжнее чем пытаться исправить самому. Применить другой инструмент более подходящий для задачи выгоднее чем пытаться всеми силами выжать нужные параметры из изученного до деталей инструмента. Например лет 5 назад я ещё встречал разработчиков которые пытались выдать максимум из mysql или postgresql, оптимизируя до фанатизма, и тогда им сложно было принять что если просто посмотреть на проблему под другим углом, вынести часто используемые данные в redis или эластику, то и страдать не надо и производительность получается даже выше чам та за которую боролись. Простой пример. Сейчас это норма. Но люди сознательно ограничили свой стек, привыкли к нему, погрузилась, изучили, и из-за этого у них не было времени и желания поэкспериментировать с альтернативой. Время, все упирается в время, усилия, энергию, мышление. Поэтому лично я даю обычно совет: Широкие и актуальные знания того с чем соприкасаешься, и относительно глубокие того с чем работаешь. И знания возможностей (о том что существует инструмент, библиотека, сервис и прочее) и как ими пользоваться, важнее глубоких знаний нескольких инструментов, особенно если они не из твоей области. Банально потому что углубить знания всегда можешь когда видишь дефицит, а вот то о чем не знаешь использовать не сможешь.
И знания возможностей (о том что существует инструмент, библиотека, сервис и прочее) и как ими пользоваться, важнее глубоких знаний нескольких инструментов, особенно если они не из твоей области.
Как-то это плохо стыкуется с типичным подходом хрюш из корпоративного мира, где сплошь и рядом считается что jack of all trades - master of nothing.
*С сумрачным сарказмом*
Для пытливых умов давно уже написан теоретический минимум программиста.
Какой ужас. Хочу пообщаться с джуном который все это знает, на достаточно адекватном уровне. Причём лучше не на собеседовании а сразу в бар, взять по бокалу пива, и проникновенно так спросить: "что же такое случилось в твоей жизни парень, что ты так перестраховываешься? Ты потратил столько лет жизни, только для того чтобы Начать программировать, сформировать свой минимум, почему? Понимаешь ли ты что за эти 4-6-10 лет ты мог стать весьма неплохим профессионалом в своей области, с твоей то обучаемостью? Ты мог даже попробовать несколько областей и в каждой набрать неплохую базу опыта. И осознаешь ли ты что 95% этой информации ты скорее всего воспользуешься пару раз в ближайшие 10 лет, а потом многое из этого станет не особо актуальным? ". И выпить с ним этот бокал за то чтобы следующие 5-10 лет он потратил на то чтобы изучать то что нужно ему, а не что придумали какие-то странные люди и оформили в список обязательного минимума некого абстрактного программиста в сферическом вакууме. А потом заказать ещё по паре бокалов, потому что у парня будет стресс, столько усилий потрачены почти зря, и я, как честный человек, обязан помочь ему этот стресс преодолеть.
Джуну вполне могло нравиться само освоение всех этих тем, без оглядки на зарабатывание денег с их помощью.
Известный комикс
А я что-то писал про деньги? Если нравится - пожалуйста, специалистом он не будет но кайф получит. Я писал не про нравится а про попытки некоторых личностей убедить что это все надо, надо безусловно и без этого никуда, более того надо до того как полноценно начать программировать. Что нужно садиться и все это изучать, даже если не лезет а то не станешь "настоящим программистом". Об этом и была речь.
С сумрачным сарказмом
Именно так, о таких вещах без сарказма говорить нельзя)
А вообще дай бог вот всем тем людям, которые говорят, что программист что то там им должен, вернуться в прошлое и иметь необходимость все это изучить перед началом работы, иначе никак - в джуны не сгодятся, и зарплату им платить не за что. Шарлатаны.
Химия кремния) Ну и юмористы)
Химия кремния - это, конечно, лол. Но в целом, если выкинуть сарказм, то получается приличная программа среднестатистического ВУЗа. Все правильно написали, молодцы.
А вообще дай бог вот всем тем людям, которые говорят, что программист что то там им должен,
Такая возможность есть. Поступаешь в профильный ВУЗ и получаешь профильное образование. Программист - это, внезапно, профессия.
Тезис об "базе" напоминает крайне дурной тезис о том, что прежде чем играть на электрогитаре, нужно освоить акустическую. Хорошо, что я в свое время купил электруху просто потому, что мне хотелось играть на электрухе, а не соответствовать "правилам".
Второй момент в том, что знаний впрок не бывает. Советовать новичку изучать тонну материала под предлогом, что без этого ты поддельный контрафактный программист завезенный через параллельный импорт, и вот однажды через 10 лет тебя не возьмут на крутой проект потому, что ты этого не знаешь... Ну это как совет носить каску каждый день. Типа вдруг кирпич - а ты в каске, с "базой".
Ну это как совет носить каску каждый день. Типа вдруг кирпич - а ты в каске, с "базой".
Абсолютно не работает, если ты на войне и под страховкой. Или на стройке хотя бы.
Тезис об "базе" напоминает крайне дурной тезис о том, что прежде чем играть на электрогитаре, нужно освоить акустическую.
Действительно, дурной тезис. А вот если его заменить на другой, уже будет профит: получить музыкальное образование.
Но в целом понятно: в АйТи самоучек стало настолько до хрена, что аж удручает. Нет, это не плохо само по себе, но понимать, что самоучки упускают из виду - было бы здорово.
Язык компьютера (железок) - ассемблер
Скорее всего, не совсем это. Сам ассемблер редко бывает нужен для высокоуровневого разработчика. Принцип же работы базовой ЭВМ - вполне себе отправная точка для интересующихся "базой". Дальше уже архитектурные особенности можно рассматривать используемых процессоров, коих много
А где язык математики???
Без него вы накодите таких алгоритмов, что "блокнот" будет 5 секунд открываться. А поиск нужной транзакции в банковском приложении займет часы.
Я знаю, что в большинстве стандартных библиотек языков, sort() использует быструю сортировку (или её варианты), поэтому будет работать в среднем за O(n log n). Но я не уверен, что смогу это доказать формально (строго, не «ну там как бы дерево из рекурсивных вызовов, глубина — логарифм от количества элементов, поэтому вроде как всё сходится»). Значит ли это, что я должен прямо сейчас забросить своё ворочание JSON'ами в Rust и идти читать теорию алгоритмов?
Языки вообще тут не причем, это довольно простой инструмент. Любой язык изучается максимум за пару часов.
Более корректный вопрос - нужно ли идти на разработку, в любой сфере, не только в it?Разработку выдержит не каждый, и в ней как раз неминуемо выгорание.
Другой вопрос - какая платформа? Готовы вы годами копаться в ней, постоянно подгорая от проблем в ней?
> Любой язык изучается максимум за пару часов.
Серьёзно? Можете описать свой подход к изучению языка за 2 часа?
Зачем так жестоко, пусть для начала T-SQL или WPF/XAML освоит на свободном уровне. Или F#
F#, Haskel, BrainFuck уже и так знаю. XAML и SQL - это вообще не языки программирования.
Если вы не можете загуглить несколько основных команд и синтаксис языка - то вы некомпетентны. Это умещается в одну страницу.
А вот на изучение платформ .Core, Java VM, x86 и других, может уйти десятилетия, и в основном методом проб и ошибок.
Вы путаете язык и платформу. Тот же С++ может быть скомпилирован и на .Core, x86, Arduino, GPU. Общее между ними только синтаксис.
C# и F# на одной платформе .Core и CLR , это значит что можно на обоих языках писать в фукнциональном и императивном стиле, или писать сразу на двух языках одновременно.
Тот же C# может быть и для платформы Mono, WebAssebly и Unity3d.
Хотя бы общее представление надо иметь.
А то потом нафигачат в каждый кадр конвертацию string to int для координат объектов на карте и удивляются: "а чё всё тормозит"?
P.S. Это не выдуманный пример.
Ну нафигачит. В чем проблема то? Увидит, отдебажит, исправит, запомнит. Хорошие процессы не пустят это в прод. Дешёвая ошибка с минимальными рисками, пара часов на дебаг и исправление. Детская? Ну и что? Взрослые ошибки уровня архитектуры или неправильных инструментов обходятся намного дороже и страдают от них намного больше и дольше. И тут примеры даже выдумывать не надо, у любого опытного разработчика их вагон чужих и солидная телега своих.
Зато пока вы учили низкоуровневые язык, потратив месяцы чтобы предотвратить ошибку стоимостью в пару часов, он поигрался с новой фичей в свежей версии вашего графического движка, и когда увидит задачу которую лучше сделать через неё - предложит, и сэкономите кучу времени, ресурсов, выиграете по производительности там где просто и не подозревали что можно выиграть, потому что не знали о возможности, вы в это время учили С. Или почитает статью с новым подходом к архитектуре в вашей области, что потенциально потом позволит сэкономить человеко-годы и кучу нервов. Время ограничено, информации и точек развития намного больше чем можно изучить, поэтому предотвращение дешёвых детских ошибок - это последнее на что стоит тратить время.
"Хорошие процессы". Да, вы смешно пошутили )
Я нее знаю в каком мире вы живете, я живу в мире где хорошие процессы есть у одной компании из 10.
Еще две из 10 пытаются изображать процессы. Остальные даже не пытаются.
Хотя, конечно, все декларируют отличный уровень процессов.
Увидит, отдебажит, исправит, зазапомнит.
Если бы все было так просто, не было бы истории, когда новый Gmail начинает тормозить даже на современных процессорах.
Прежде чем ездить на АКПП, надо освоить сначала механику?
Язык компьютера (железок) - ассемблер
Язык компьютера это нолики и единички, а не ассемблер. Как вы в айти то вошли, не зная этого?
У компьютера вообще нет языка
Умение абстрактно мыслить - главный навык программиста.
У компьютера нет набора команд. Там только электроны бегают )
Там только электроны бегают )
Электрон никуда не бегают, только электромагнитные волны. Но волны это тоже абстракция. И как это мы делаем компьютеры не зная что на самом низком уровне физики? Наверное так же как и программисты пишут программы, есть предсказуемое поведение, с ним и работаем, а что там на всех уровнях вниз, от реализации библиотеки до возмущений электромагнитного поля, не особо важно.
Важно уметь писать качественный и эффективный код. Изучение ЯП и практика программирования не приблизит к пониманию чем отличается эффективный код от неэффективного. А это уже - навыки из фундамента. Теория сложности нужна просто вообще всем. Базовые классические алгоритмы - тоже. Несмотря на то, что уже все реализовано в рамках стандартных библиотек и фреймворков. Должно быть понимание как изобретать алгоритмы. И кроме как погрузившись в эти темы вы этих навыков не получите. Никакие советы старших товарищей не помогут.
Вы говорите - геймдев? Да, можно в юнити и без знания математики. Вы тупо используете кватернионы и не задумываетесь, что же за этим стоит. Можно? Можно! Но ваш уровень ограничен потребительством: без движка вы игру не напишете. Поучаствовать в разработке движка не сможете. Да и в рамках движка какие-нибудь свои алгоритмы напишете криво. Потому что многократное повторение и написание игр не даст вам представления об обходе графов, поиска кратчайшего пути и прочего.
мое мнение заключается в том, что нельзя быть хорошим программистом без понимания устройства компьютера, принципа работы, взаимодействия с его пользователем...
В прошлом веке в вузе я брал дополнительные курсы по системотехнике на несколько месяцев чтобы стать хорошим программистом. Все три тома Крута прочитал. Ну, почти прочитал :)
В 21 веке, в средней школе (типичной развитой страны) курс информатики все это покрывает с тем же результатом. Дочь в 14 лет в системном блоке как в своей косметичке.
стать полноценным специалистом можно только обладая всеми навыками.
Очень вредный посыл.
Профессионализм и компетенция это прежде всего понимание того что важно, а что нет.
А некая база по CS, это сейчас уровень школьной программы. То есть минимум очевидный как для вождения автомобиля. Доступный на уровне мультиков для детей там, где раньше это была занудная вузовская программа.
Хороший программист это давно уже не технический стэк, с которым дети уже чуть-ли не рождаются давя кнопки с 2 лет.
Дочь в 14 лет в системном блоке как в своей кокосметичке.
Ваша дочь скорее исключение. По моему опыту сейчас в целом наоборот меньше детей понимают как устроен компьютер. Это стало обыденностью, и большинство даже не задумывается об этом, как люди не задумываются о том, как работает радиоприёмник, телевизор или Wi-Fi роутер.
Такие дети вряд ли в зрелом возрасте, через 10-15 лет, резко решат идти в IT.
Взрыв значимости IT уже произошел.
Те же дети, кому интересно в школьном возрасте, по сути могут получать наши вузовские знания уже в школе. При желании.
Как минимум, моя жена, HR в Кремниевой долине, получает неплохие CV от 14 летних.
Очевидно что процесс входа в IT сильно меняется. Позиция автора поста что нужно овладевать языками от ассемблера до скриптов, мне кажется несколько самобытной.
В современном мире есть Computer Science, где даже в рамках школьной программы дается вполне достаточная база. После который уже можно специализироваться на выбранной специализации.
Вот пример материалов
Cambridge IGCSE Computer Science.pdf
Школьная программа. Для старших классов школы перед поступлением в колледж.
Contents
Introduction
Section 1 Theory of computer science
Chapter 1 Binary systems and hexadecimal
1.1 Introduction
1.2 The binary system
1.3 Measurement of the size of computer memories
1.4 Example use of binary
1.5 The hexadecimal system
1.6 Use of the hexadecimal system
Chapter 2 Communication and internet technologies
2.1 Introduction
2.2 Data transmission
2.3 Error-checking methods
2.4 Internet technologies
Chapter 3 Logic gates and logic circuits
3.1 Introduction
3.2 Logic gates
3.3 Truth tables
3.4 The function of the six logic gates
3.5 Logic circuits
3.6 Logic circuits in the real world
Chapter 4 Operating systems and computer architecture
4.1 Introduction
4.2 Operating systems
4.3 Interrupts
4.4 Computer architecture
4.5 The fetch–execute cycle
Chapter 5 Input and output devices
5.1 Introduction
5
5.2 Input devices
5.3 Output devices
Chapter 6 Memory and data storage
6.1 Introduction
6.2 File formats
6.3 Lossless and lossy file compression
6.4 Memory and storage
6.5 How to estimate the size of a file
Chapter 7 High- and low-level languages
7.1 Programming languages
7.2 Translators
7.3 What happens when things go wrong?
Chapter 8 Security and ethics
8.1 Introduction
8.2 Security and data integrity
8.3 Cookies
8.4 Loss of data and data corruption
8.5 Firewalls and proxy servers
8.6 Security protocols
8.7 Encryption
8.8 Applications
8.9 Computer ethics
8.10 Free software, freeware and shareware
Section 2 Practical problem-solving and programming
Chapter 9 Problem-solving and design
9.1 Introduction
9.2 Algorithms
9.3 Test data
9.4 Validation and verification
9.5 Using trace tables
9.6 Identifying and correcting errors
9.7 Producing algorithms
6
Chapter 10 Pseudocode and flowcharts
10.1 Introduction
10.2 Assignment
10.3 Conditional statements
10.4 Loop structures
10.5 Input and output statements
10.6 Standard actions
10.7 Examples of algorithms in pseudocode
10.8 Standard flowchart symbols
Chapter 11 Programming concepts
11.1 Introduction
11.2 Programming
11.3 Declaration and use of variables and constants
11.4 Basic data types
11.5 How to make your program work
Chapter 12 Data structures: arrays and using pre-release
material
12.1 Introduction
12.2 Arrays
12.3 Using pre-release material
Chapter 13 Databases
13.1 Introduction
13.2 What are databases used for?
13.3 The structure of a database
13.4 Practical use of a database
Можно освоить HTML, CSS, JS и называть себя
сайтоклепателем
веб-программистом. Но стать настоящим специалистом без всего остального
будет проблематично. Для дальнейшего роста будет необходима такая база.
А с чего вы это взяли ?
О боже, опять, каждый год одно и то же. И снова в комментариях понты про программистов, кодеров, инженеров, ремесленников и конечно же веб разработку. Про php пошутить забыли. Или не забыли? Программирование сейчас это узкая специализация. Программисты работают с абстракциями, с api, не важно rest это, инструменты фреймворка, или функции микроконтроллера. В работе используется куча инструментов, библиотек, внешних и внутренних сервисов. Исходя из аналоги и выводов статьи для хорошей работы вам надо знать детали их реализаций. Так? Но это невозможно, в сутках тупо нет столько времени, даже если бы они не обновлялись, а они это делают. Вам надо знать их ожидаемое поведение, их api, понимать что делает этот чёрный ящик, как с ним работать, как получить нужный вам результат и если это невозможно как найти другой ящик который вам подойдет. В сам ящик залазить придётся крайне редко, и то если его разработчики накосячили с документацией или кодом. В большинстве случаев вам нужно просто нагуглить уже эту ошибку и обновится, или написать разработчикам если ещё не обнаружили и не исправили. Чем вам поможет среднее знание js (если вы бэкенд например) на проекте со сложным фронтом? По хорошему вас туда даже пускать нельзя, есть api, есть фронтендеры, это их задача. Чем поможет знание ассемблера или C в случае если у вас проблема с тем же mysql? Вы реально полезете его декомпилировать и оптимизировать? Сколько раз вы это делали? Теперь по существу, вот почитает новичек такую статью и начнёт учить все по списку (а этот ещё короткий, я видел намного длиннее) . Потратит год, два, может больше, с нуля это все поднять не просто, учитывая разную логику языков. И захочет устроится, ну например в геймдев. Как вы думаете куда его пошлют с такими навыками? Правильно, учится дальше. На его удивлённый вопрос "так а как это так, у меня же есть База!??" опытный лид который его собеседовал ему ответит: "твоя база это твоё мышление, умение работать с абстракциями, понимание ООП тоже неплохо, хотя и не везде, это то что общее. А все остальное очень зависит от области. ты эту базу нарабатываешь в процессе, вместо всей этой чепухи лучше бы ты игру сделал и в процессе разобрался в том что тебе интересно и в той области где ты планируешь работать. Если тебе будет потом не хватать понимания чего-нибудь, ты изучаешь когда это будет актуально, то что нужно, в нужное время и тогда расширишь свою базу. А сейчас она бесполезна. Нам не нужны (да и тебе тоже) твои знания js и ассемблера. Более того, она вредна, пока ты во всем этом разбирался ты наработал привычки, зависимые от области и языка привычки, которые тут будут мешать, теперь тебя переучивать придется". Ну а теперь традиционный совет: хотите изучить программирование - программируйте. Берите и делайте то что нравится, не книжки читайте а сделайте то что работает, результат а не теория и примерчики с книжки. Но, в процессе, читайте статьи, книги, видео, смотрите как сделать это лучше. Ну а когда наберёт минимальный объем - идите в компанию, и ориентируйтесь не на зарплату или размеры компании, а на команду и проект. На интересном сложном проекте вы будете развиваться быстрее, а хорошая сплоченная команда с хорошими процессами и культурой укажет на ошибки, покажет как лучше и вы будете набирать свой опыт. Не надо учить языки просто ради языков, это бесмысленно, более того это вредно. Язык это только инструмент, ваше мышление, опыт, наработанные схемы решения проблем и умение выходить за них и применять новые - это делает вас программистом, а не языки. Захотите потом поменять язык - поменяете, это не так уж и сложно, это будет меньшая из ваших проблем при смене области, язык это очень небольшая часть знаний и навыков по сравнению со всем необходимым. Ну и раз уж в статье была аналогия, дам другую, поближе к реальности - настоящий писатель должен великолепно разбираться в лингвистике и знать русский, английский, китайский, немецкий, испанский и французский, это база, без неё никуда, и её достаточно чтобы начать писать отличные книги. Такие настоящие писатели пусть сидят на кафедре плохого университета, а хорошие писатели просто берут и начинают писать, в процессе уже набивая руку и повышая мастерство (плохие тоже, их единственное отличие они мастерство не повышают, тупо гонят текст, не анализируя хорошо или плохо, не улучшая, не переписывая и не читая других писателей, не слушая ничьих советов и зацикливаясь на небольшом наборе привычных им сюжетов и приемов ).
Тоже верно. А так же хорошее продуманное изложение, желательно краткое но емкое и понятное. Я в курсе что всего этого в моем комментарии нет. Но вам шашечки или ехать? Форма или содержание? Спор или результат? Суть или придраться? Ну вы поняли, по сути комментарии есть?
> Ну вы поняли, по сути комментарии есть?
конечно есть, можно добавить к примеру что как разработка sw так и изучение программирования процесс итерационный, типа движения по спирали с одного уровня на другой, и так всю жизнь
ps
так и хочется сказать bootstrapping :)
Поддерживаю. Все очень хорошо и правильно сказано. Вообще, все вот эти заявления с умным видом про некую "базу" и про "настоящий программист должен" это что то из области психологических проблем.
Программисты работают с абстракциями, с api, не важно rest это, инструменты фреймворка, или функции мимикроконтроллера.
Проблема в том, что у микроконтроллера обычно очень плохо с api :) И там таки надо понимать детали реализации, так же как вам надо будет их понимать, если вы захотите написать ОС. Это как раз тот уровень где кончается API и начинаются регистры, порты, страницы и адреса, и API тут придётся уже вам самим проектировать.
☹️☹️ Бред. Поток мыслей неврастеника. Очень похоже на статью: "Послушайте меня о моём горьком опыте, почему я Не стал бизнесменом".
Такие мысли посещают всех без исключения программистов со стажем более 2х лет.
Напоминает то как девушка за 30 предпринимает пойти на отчаянный шаг пожертвовать молодостью за богатого маленького миллиардера. Такая девушка думает что только она пришла к такой мысли. Не понимая то что все без исключения за 30 приходят точно к такой же мысли.
Так и автор материала думает что только он думает об этом, и что как он думают еще 10 человек в России. А если бы он по больше бы общался с людьми, он бы понял, что об этом думают практически все.
То что Вы называете "База" в быту называется профильное высшее образование, где Вам дадут эту базу, а уж специализацию Вы потом сами выберете по душе.
Нынешние же модные курсы "приди в IT за 30 дней" порождают армии весьма странных специалистов, натренированных на решение узких синтетических задач ограниченным числом инструментов.
И потом на интервью с удивлением обнаруживаешь "программистов", которые не знаю что такое байт.
Рискую сказать непопулярную тут вещь, однако не соглашусь. Просто лично мне это напоминает ситуацию, когда прежде чем приготовить условный стейк, ты начинаешь изучать механизмы работы плиты, физику, ибо без ее знания невозможно понять, при какой температуре оптимально готовить этот самый стейк, а также зазубриваешь весь модельный ряд ножей для резки мяса. Хотя надо было просто открыть рецепт и сделать его.
Ну и из разряда "держу в курсе": Моя практика привела к тому что целесообразно сперва что-то начать делать, а потом разбираться в процессе. Я даже слышал что это называется "Модель Колба". Мне помогло очень при разработке игры. Игра простенькая, но я ее хотя бы сделал, а не увяз в изучении теории, что уже радость
Просто лично мне это напоминает ситуацию, когда прежде чем приготовить условный стейк, ты начинаешь изучать механизмы работы плиты, физику, ибо без ее знания невозможно понять, при какой температуре оптимально готовить этот самый стейк, а также зазубриваешь весь модельный ряд ножей для резки мяса. Хотя надо было просто открыть рецепт и сделать его.
Вы прекрасно сами объяснили назначение базы aka профильного высшего образования.
Если вы хотите приготовить стейк по готовому рецепту - вам тупо надо сделать все по инструкции. Ака кодеры. которым база не нужна и которых большинство.
Если вы хотите создать новый рецепт, который вызывает оргазм у неживой материи, то вам нужно и физику изучить и свойства стопицот ножей и механизмы работы плиты и биологический цикл животных и растений и 100500 других фундаментальных знаний.
Очевидно, нужны и те и другие. Сами определяйте себе потолок развития.
Ну и из разряда "держу в курсе": Моя практика привела к тому что целесообразно сперва что-то начать делать, а потом разбираться в процессе. Я даже слышал что это называется "Модель Колба". Мне помогло очень при разработке игры. Игра простенькая, но я ее хотя бы сделал, а не увяз в изучении теории, что уже радость
Проблемы начнутся при попытке масштабировать опыт. А точнее - не начнутся.
Вы откроете для себя мир Юнити или Анрила и на этом вся магия закончится.
А вот написать свой движок - уже в математику надо, в оптимизацию алгоритмов и прочее, что системно дается в ВУЗе.
Вообще, непонятно как это все стыкуется с реальностью. А реальность такова, что многие люди учат только фреймворк и то по верхам, особо не заморачиваясь с языком и сопутствующими технологиями.
Типичный пример по фронте - пишут на реакте, но толком не зная js. Или в бэке - используют фреймворк, не зная SQL. И реальность такова, что эти люди каким то образом устраиваются на работу, получают зарплату, растут по карьерной лестнице.
И параллельно с этим постоянно появляются люди, заявляющие, что каждый должен знать ассемблер, си, боже упаси, и далее по списку. Иначе вы не настоящий.
То есть существуют две такие крайности, и как они стыкуются между собой в реальности?
Одни пишут хабр, другие пишут комментарии на хабре. Делает ли это тех кто пишут комментарии менее опытными и амбициозными чем те кто пишут хабр? Или это просто взаимодействие, симбиоз, как в ваших примерах, одни пишут платформу, на которой другие напишут что-то свое, полезное, зачастую более сложное и требующее более высокой квалификации чем сама платформа? Вообще глупо мерятся сложностью и определять кто важнее и круче, особенно такими зависимостями. А то ведь прибегут электрики и скажут что это они самые крутые и без них все развалится, ведь если электричества не будет то и ваши компьютеры работать не будут. Понты вообще глупая штука, хоть и популярная.
Ох, уел так уел, и даже 2 раза с одной подколкой. Простите, а можно нескромный вопрос: вам сколько лет? А то у меня ощущение что я общаюсь с капризный ребёнком которому читать лень, обсуждать по сути беседы влом, зато подколоть и поспорить (с победой конечно же) очень важно для почесывания ЧСВ и повышения социального статуса хотя бы в своих глазах.
Да нормально они стыкуются. Помню в универе у меня были преподаватели отлично знающие Sql но ничего не понимающие в нагрузках и оптимизации. Уже 30 лет преподающие С но не участвововавшие ни в одном коммерческом проекте. И они тоже говорили. Они даже были уверены что знают. Но между знаниями и экспертизой (опытом) есть разница.
Обычная эта фигня с кучей языков и знаний про запас и прочей "базой" приходит к людям когда они достигают планки мидла, и часто совпадает с их стэком, ведь они уже опытные, и знают цену знаниям, а значит пора перестать комплексовать, начинать понтоваться и учить других что им нужно знать чтобы стать настоящими. Иногда она ещё проявляется на последних курсах (или сразу после) универа. Обычно эта фигня заканчивается где-то по достижению планки синьора (не всегда), когда к людям приходит понимания что важны не столько знания а умения их применять, мышление, подходы, наработанная экспертиза, и что языки лишь инструмент и занимают довольно небольшую часть знаний программиста.
Короче все зависит от людей, их характера, занятий и опыта.
П. С. Я бы не сказал что знание Sql на высоком уровне является маст хэв для разработчика, давно не видел чистый Sql в коде, да и сейчас часто удобнее вынести данные из базы на другое хранилище чем выжимать максимум из оптимизации запросов, про идеальную нормализацию вообще молчу, нет её и не нужна. На минимальном или среднем знать надо конечно. С другой стороны сколько надо часов чтобы освоить селект, джоины и условия. Я кстати па собесах, когда меня спрашивают про уровни изоляции транзакций люблю пообщаться на тему как и почему вы применяете это в проекте. Часто это очень забавно, правда иногда и полезно.
Я думаю, что это понимание, которое приходит к синьерам-помидорам, по хорошему бы должно быть у каждого человека и в начале профессионального пути в айти. Но таки да, реальность такова, что часть людей будет меряться длиной своего ассемблера и этой мерой судить всех остальных.
Чем меньше развит человек, тем больше он будет считать себя умнее других. А в качестве доказательства для самого себя будет превозносить именно те знания, которыми обладает.
Насчет применения чистого SQL - это же вроде популярный холивар: SQL или ORM.
Я замечаю тенденцию, что за чистый SQL топят, например, прогеры на Go и Node js.
Я замечаю тенденцию, что за чистый SQL топят, например, прогеры на Go и Node js.
Может это потому что у них в экосистеме нет ORM, и все приходится делать как на механике - выжал сцепление, приотпустил, газу поддал, воткнул первую, поехал?
Ну нода и го используются в областях высокой нагрузки или быстрого отклика, им на всем экономить приходится, лишний слой может быть роскошью. Правда по сравнению с запросом к базе это все равно экономия на спичка. Но может так тюнить запросы удобнее. Ну и да, хз как у них в плане orm.
Ну да, должно у всех быть, но понты появились раньше человека разумного, это старое генетической заболевание, а тут ещё и на пространстве СНГ it чуть ли не в отдельную высшую касту отделяют, благоприятная среда. Так что это к сожалению естественно.
То есть существуют две такие крайности, и как они стыкуются между собой в реальности?
Очень просто: нужны и те и другие. Для 80% задач достаточно 20% усилий/знаний/навыков и прочего.
Вот те, кто берет по верхам, да считает, что чем больше языков - тем круче, не понимая, что есть огромный пласт других навыков и знаний = кодеры, прекрасно занимают эти самые 80% рутины.
Те же, для кого программирование - это не только ЯП + фреймворк, но и некая фундаментальная база (математика, алгоритмы и пр.), они закрывают остальные 20% задач, которые не по зубам тем, кто говорит "фи" про математику и прочую базу.
Те же, для кого программирование - это не только ЯП + фреймворк, но и некая фундаментальная база (математика, алгоритмы и пр.), они закрывают остальные 20% задач, которые не по зубам тем, кто говорит "фи" про математику и прочую базу.
100% задач - это сеньор по уровню, а не математик. И сеньора делает уровень понимания предметной области реального мира, а не уровень математики.
И если в ряде специализаций предметной областью служит математика, это не делает ее базой. Алгоритмы же не являются инструментом, а часть предметной области.
Тут вопрос что есть база. Еще 30 лет назад это действительно была все больше математическая и алгоритмическая база. Но сейчас, с проникновением программирования во все сферы жизни, есть системное и есть прикладное программирование.
таненбаум - это системное программирование. Бинарные поиски, сортировки вставками и прочее - это системное программирование. Low level.
Для прикладного же программирования база:
владение фреймворком/продуктом, знание технологического стека (Junor +)
умение работать с любой свалкой кода (Middle +)
понимание прикладной области (Senior +)
Яндекс кончено прекрасен со своими алгоритмами на входе, но возьмите практически любую вакансию по той же Java. И там уже не про знание математики, а про знание конкретных технологий организации кода. High level.
Что есть профильное образование - вопрос крайне открытый.
иметь представление надо
Не спорю. В рамках общего кругозора. Тот же школьного уровня Computer Science дает необходимое представление. Точно не в рамках математического образования которым многие пытаются подменить Computer Science.
Вот здесь пример школьной программы.
https://habr.com/en/post/672814/comments/#comment_24472576
То, что я изучал, в рамках профильного высшего образования по программированию ПК и ЛС, 20 лет назад, моя дочь сейчас изучает в средней школе.
По поводу квадратичной сложности (кода), не уверен что это релевантно академическому образованию. SOLID, KISS, YAGNI и прочее - это культура написания кода, чувство кода. То что достигается только тем самым презираемым самоучением:)
С квадратичной сложностью как один из примеров, просто реально уже десятки раз видел как разные люди подобное пишут, и никак не могут научиться и понять почему у них код медленный получается слишком что даже на небольших коллекциях тормозить начинает заметно глазу.
в каких правда школах это проходят все — даже не представляю
Для возраста 14-16 лет. Необязательный предмет, Computer Science, но в школьной программе. Один из возможных, на выбор, экзаменов по окончании средней школы.
Вот пример материалов
Cambridge IGCSE Computer Science.pdf
Hidden text
Школьная программа. Для старших классов школы перед поступлением в колледж.
Contents
Introduction
Section 1 Theory of computer science
Chapter 1 Binary systems and hexadecimal
1.1 Introduction
1.2 The binary system
1.3 Measurement of the size of computer memories
1.4 Example use of binary
1.5 The hexadecimal system
1.6 Use of the hexadecimal system
Chapter 2 Communication and internet technologies
2.1 Introduction
2.2 Data transmission
2.3 Error-checking methods
2.4 Internet technologies
Chapter 3 Logic gates and logic circuits
3.1 Introduction
3.2 Logic gates
3.3 Truth tables
3.4 The function of the six logic gates
3.5 Logic circuits
3.6 Logic circuits in the real world
Chapter 4 Operating systems and computer architecture
4.1 Introduction
4.2 Operating systems
4.3 Interrupts
4.4 Computer architecture
4.5 The fetch–execute cycle
Chapter 5 Input and output devices
5.1 Introduction
5
5.2 Input devices
5.3 Output devices
Chapter 6 Memory and data storage
6.1 Introduction
6.2 File formats
6.3 Lossless and lossy file compression
6.4 Memory and storage
6.5 How to estimate the size of a file
Chapter 7 High- and low-level languages
7.1 Programming languages
7.2 Translators
7.3 What happens when things go wrong?
Chapter 8 Security and ethics
8.1 Introduction
8.2 Security and data integrity
8.3 Cookies
8.4 Loss of data and data corruption
8.5 Firewalls and proxy servers
8.6 Security protocols
8.7 Encryption
8.8 Applications
8.9 Computer ethics
8.10 Free software, freeware and shareware
Section 2 Practical problem-solving and programming
Chapter 9 Problem-solving and design
9.1 Introduction
9.2 Algorithms
9.3 Test data
9.4 Validation and verification
9.5 Using trace tables
9.6 Identifying and correcting errors
9.7 Producing algorithms
6
Chapter 10 Pseudocode and flowcharts
10.1 Introduction
10.2 Assignment
10.3 Conditional statements
10.4 Loop structures
10.5 Input and output statements
10.6 Standard actions
10.7 Examples of algorithms in pseudocode
10.8 Standard flowchart symbols
Chapter 11 Programming concepts
11.1 Introduction
11.2 Programming
11.3 Declaration and use of variables and constants
11.4 Basic data types
11.5 How to make your program work
Chapter 12 Data structures: arrays and using pre-release
material
12.1 Introduction
12.2 Arrays
12.3 Using pre-release material
Chapter 13 Databases
13.1 Introduction
13.2 What are databases used for?
13.3 The structure of a database
13.4 Practical use of a database
Зависть меня берет :) Хотел бы я тоже так учиться в свое время.
никак не могут научиться и понять почему у них код медленный получается
Писать код который исполняется быстрее за счет знания алгоритмов - это редкая потребность. По крайней мере в Enterprise.
Все же обычно это просто использование готовых коллекций типа
https://docs.oracle.com/javase/tutorial/collections/implementations/index.html
Оттуда же
The performance of the implementations is described using words such as constant-time, log, linear, n log(n), and quadratic to refer to the asymptotic upper-bound on the time complexity of performing the operation. All this is quite a mouthful, and it doesn't matter much if you don't know what it means. If you're interested in knowing more, refer to any good algorithms textbook.
Там где есть база данных, уже она узкое место, и тут уже другая экспертиза, но по прежнему не обход графов.
Важная мысль в том, что не нужно впрок создавать базу. Быть самоучкой - вот основной навык. Когда понадобиться тогда и алгоритмы в зубы. А то я Кнута в свое время начитался, как-то не сильно он мне помог, в отличие от хороших книг по Java и .NET.
Писать код который исполняется быстрее за счет знания алгоритмов — это редкая потребность. По крайней мере в Enterprise.
Забавно что как раз когда был 1сником приходилось и по деревьям бегать, и некоторые другие вещи.
Все же обычно это просто использование готовых коллекций типа
Да вот беда, если не держать в голове в целом что надо оценивать код который пишешь — у многих возникает соблазн даже так не заморачиваться. Set/Map? Не, пройдемся в цикле по списку, а внутри еще в одном цикле по нему же чтобы нужные элементы найти. Ах да, предварительно список еще и отсортировав (что вообще там не нужно было, но без понимания как работать с данными человек добился того что код работает и видимо побоялся что то править, это конечно джун был, но и от «мидлов» подобное видел).
Не, пройдемся в цикле по списку, а внутри еще в одном цикле по нему же чтобы нужные элементы найти. Ах да, предварительно список еще и отсортировав
Исходя из моего понимания людей, условный бывший таксист в принципе не полезет такое делать, в то время как чистый технарь с "фундаментальной" базой - очень даже может.
Хороший программист - это ленивый программист понимающий что велосипедов вокруг на все случаи жизни.
Джун может просто не знать, что надо что-то еще.
Нет насмотренности хорошего кода, когда просто чувство что это - красиво, а так - режет глаз. От знания 10 языков программирования и 5 лет вуза, такое чувство правильности не появится само по себе.
Довольно странный вообще выбор технологий.
Допустим, вот у меня научрук был анализу данных - знает SQL, R и немного JS. И ОЧЕНЬ МНОГО МАТАНА. Вот матана там действительно много было. Был ли он плохим специалистом? Да не, он был отличным специалистом, мог за все кишочки пояснить, а т.к. опыта довольно много - он показывал недокументированные штуки, о которых он знал - а вот нагуглить это не представлялось возможным. Назвал бы я его разработчиком? Нет. Но вот к айти он точно относится.
К чему я это? К тому, что во-первых, АйТи не ограничивается разработкой; во-вторых, чтобы быть крутым в чем-то, внезапно, нужно лезть вглубь, а вот это вот: ассемблер изучи, си изучи, перл изучи, чтобы потом гонять json в базу на спринге - это оставьте для студентов и людей, которым заняться нечем.
IMHO главное отличие трушного програмера - это железный зад, трезвый взгляд и чтобы пёрло, от того что делаешь
Найти работу на С и ассемблере не вариант? Ну или подождать немного, до осознания что язык это только инструмент а возможности для творчества зависят от компании, проекта, процессов и команды а не языка. Архитекторов и техлидов (да и синьоров в основном) от языков не прёт, их прёт от интересных вызовов, идей, возможности их реализовать и часто просто от ощущения что и продукт полезный и работать с ним удобно.
Но лучше конечно не страдать и найти работу по душе. благо в современную постковидную эру с возможностью удаленки почти везде -
единственный барьер это языковой (ну ок, в некоторых случаях ещё и географический, но решаемо же).
Мой знакомый 30 лет пишет на С/С++, с 1992. Он в гробу видал JS и всякие Хаскелы. Они ему не нужны, он специалист в своей области. При этом его солидная зарплата совсем не зависит от локации, сейчас работает в Австрии. Скажу ему, что он не "настоящий" программист.
С js не согласен, в остальном да. А ещё на английском надо гуглить
Очередная статья как стать "настоящим" программистом. Выучи кучу языков, которые непойми по какой логике стали БАЗОЙ, и стань сразу кем? Знатоком языков? Дискретная математика, основы микроэлектроники, компиляторы, ядро операционной системы, не не не знание асемблера и С оказывается расскажут как это работает. А хирургу не курс анатомии рассказывает как операции проводить, а скальпель с зажимом. Изучи скальпель и зажим и ты настоящий хирург! Удалите статью не вводите в обман новичков, и не тратьте их время пуская по ложному пути.
Если вы знаете 1 язык, вы - кодер.
Если вы знаете 10 языков, вы - кодер...
Если вы знаете 100 языков, вы - все равно кодер.
А что нужно, чтобы стать программистом?
Нужна - база. И это ни разу не языки программирования.
Вот так базу представляю я:
Минимально необходимая база - математика. Вся. Вообще вся. И матан, и алгебра, и геометрия и дискретка и все прочее. Это - незыблемый фундамент, вокруг которого все вращается.
Далее, неплохо посмотреть вокруг. Что мы собрались программировать? Физика, химия - как фундаментальные науки. В каком-то начальном виде, просто чтобы иметь кругозор.
Далее, информатика - там словоблудие, но это словоблудие дает понятие о месте айти в мире.
Далее, архитектура. Тут из математики всплывают замечательные вещи о теории вычислимости, появляются машины Тьюринга, мельком всплывают теория вычислимых функций, лямбда-исчисление и функциональные языки. Тут же появляется понимание парадигм программирования. И, внезапно, оказывается, что вокруг далеко не только ООП. Оказывается раньше была процедурная парадигма, функциональное программирование и логическое программирование. Тут же закономерно появляется понимание, почему на смену процедурной парадигме пришла ООП. Тут же появляется понимание, куда упирается ООП и при чем тут аспекты и обобщенное программирование.
А с этим пониманием приходит понимание, какие языки какие элементы имеют, у кого стырили и зачем.
Алгоритмы и структуры данных. Виртовское уравнение Алгоритмы + Структуры данных = программы - актуально до сих пор. Вся дискретка, вычислительная геометрия и другие прекрасные разделы математики, вроде теории сложности, рассказывают нам про алгоритмы, базовые структуры данных, и про то, насколько больно со всеми этими красотами работать.
Из математики рождаются классические постановки задач, вроде транспортной, коммивояжера и др., которые легко находят приложения в экономической практике. Правда, поскольку, подавляющее большинство "программистов" не осилило в фундаментальное базовое образование, то проблематика и нормальные алгоритмы решения задач для них недоступны. Вот и появляются потом на хабре статьи-откровения, как чел придумал и решил задачу нахождения кратчайшего пути в графе.
Железо. Тут надо понимать и ТАУ и логику и какое-никакое представление об устройстве железа иметь. Ну а далее имеет смысл познакомиться с ассемблером, теорией трансляторов и компиляторов, операционными системами. Здесь рукой машет мат. логика, теория формальных грамматик, исследование операций. И оказывается, что в написании ОС, есть кой-какие хитрости. А потом внезапно оказывается, что компилятор/интерпретатор написать - не высший пилотаж, а стандартная такая задачка, которая порождает простой и красивый код.
Далее понадобится понимание методов проектирования софта. Процессы, архитектура и т.д.
Теория систем, микросервисы, паттерны GoF, Солиды, шаблоны eip, распределенные системы и многое-многое другое.
JavaScript?
Видимо сейчас не модно вспоминать, что кроме JS есть куча всего другого, например, VBScript, Flash (царство небесное). Я уж молчу, что современный фронт сильно сложнее базового JS. DOM? HTML5? Фреймворки, Node.JS? Да там целый мир!
А еще не плохо бы понимать, как это все работает под капотом.
Ой, а тут мы оказывается сети затронули... Здравствуйте, OSI, TCP/IP, прикладные протоколы и многое-многое-многое....
SQL? Владение SQL - это must have в любой области. Но не делает программистом. Программист еще должен понимать про архитектуру СУБД. Индексы, партиции, и прочее-прочее. Еще не плохо бы знать, что кроме реляционных СУБД (здравствуй, реляционная алгебра - опять матан всплыл )) ) есть и другие, например, новомодные NoSQL.
Ну и на закусь - английский. Без него на самом деле никак.
Ой... Кажется я перечислил почти все, что в ВУЗах дают. При чем, список можно пополнять. Ну так собственно в этом и вопрос. Хотите быть программистами? Вэлкам в фундаментальное образование. Программисты потом способны двигать индустрию. Развивать ИИ, сочинять новые архитектуры нейросетей и всякие там автопилоты. Кодеры же способны струячить тонны простейшего кода. Кажется, правило Парето работает и здесь. 80% задач требуют 20% напряжения мозга. 80% задач способны решить кодеры. А вот оставшиеся 20% - без программистов никак.
Ну и фантазии у вас...
Что, прям даже и DOM? И даже удалось попробовать поработать с нереляционными базами? Новомодными. А можете описать проекты в которых вы это использовали и как. На примерах оно же гораздо наглядное и понятнее. Можно парочку, все не обязательно. Простите за сарказм (надеюсь вы его заметили), но реально какой то винегрет описали, как будто где-то что то услышали и на бросили все это в кучу, и все это с какой то фанатичноц рекламой такой же солянки из математики.
Мне почему-то вспомнил один преподаватель из универ, он так же сыпал. Но это была середина нулевых, тогда действительно нереляционные базы были новыми, пусть ещё и не модными, а document object model был одной из основных тем в статьях и книжках "javascript за 24 часа".
Ну и да, он за свою жизнь не участвовал ни в одном реальном проекте, зато любил как он говорил "расширять свои горизонты", обычно это ограничивплось тем что он брал в магазине очередную книжку, читал её и повторял примеры. Потом брал другую, по другой теме. По две, а иногда даже по 3 книжки в год.
Вы случаем в Бнту не преподавали?
Ну ок, ваши представления о фундаменте программиста?
Или вы тоже сторонник "С - язык ОС"? И про математику: алгебра, матан, дискретка - актуальны до сих пор. Даже та программа, которую давали в ВУЗах 80х. А вот С++ 20 летней давности совсем не такой как сейчас, да и всякие SOLIDы сформулировали вот-вот буквально только.
Про моё отношение ко всяким фундаментам и базам, и тем более попыткам сформировать абстрактного программиста в сферическом вакууме, я писал выше, там длинная простыня неформатированного текста.
Solid принципам где-то между 20 и 40 лет, смотря как считать.
Про моё отношение ко всяким фундаментам и базам, и тем более попыткам сформировать абстрактного программиста в сферическом вакууме, я писал выше, там длинная простыня неформатированного текста.
Ок, ваш подход понятен и имеет право на существование. Кодеры тоже нужны.
Слушайте, вот мне реально любопытно, а почему вам так хочется делить людей на программистов и кодеров? Как понимаю (опять же по вашим комментариям) колеры это какие-то неполноценные программисты, этакое ругательство. Почти в каждом вашем комментарии это есть. Это какой то комплекс? Необходимость почесать свое ЧСВ? Что то другое? И я бы ещё понял если бы вы действительно были хорошим профессионалом в области разработки, плохо но хотя бы имели бы право, но вот странно слышать такой выпендреж от человека который считает DOM чем то особенным, nosql базы новинкой, а Solid, принципами которые "вот-вот сформулировали". Ну пожалейте людей, они читая это фейспалмами себе уже лицо отбили, будут с синяками ходить. Да, оценивать уровень по оговоркам не особо правильно, но проекты вы так и не показали. Зато нелепых понтов про кодеров вагон.
Слушайте, вот мне реально любопытно, а почему вам так хочется делить людей на программистов и кодеров?
Я просто хочу показать важность фундаментального образования. В исходной статье чел перечислил ЯП и считает, что это и есть суть программиста. Я же показал, что есть много всего еще, что выходит далеко за рамки ЯП.
Самоучкой вы можете работать программистом. Даже до сеньора можете дорасти. Но только в решении обыденных задач.
А вот в решении эпических и легендарных задач, всплывут вопросы, о которых самостоятельно вы 100% не задумаетесь.
Я такое видел. Чел решает задачу автоматизации раскроя металла. Он навешал крутой технологический обвес у него там код красивый.... Но ключевой момент - он вообще не в курсе, что раскрой-упаковка - это раздел математики, в котором накоплен определенный пласт результатов. И вот свое тривиальное решение, он выдает за вершину мысли. И вот тут действительно фейс-палм.
Наличие фундамента подсказало бы, что задача несколько сложнее, чем выглядит. Что математически точно она не решена, поскольку NP-трудная. И что там накоплено 100500 алгоритмов для разных случаев жизни. Есть точные - всякие методы ветвей и границ, которые позволяют решать задачу точно до нормальных размерностей, есть приближенные, которые дают приемлемые варианты с приличной скоростью и т.д.
Но нет, чел реализовал самый тупой вариант, потому что ему даже в голову не пришло, что можно по другому. Ему даже в голову не пришло, что разные варианты решения задачи можно оценить по эффективности.
Потому что, когда он решил стать программистом, он справедливо решил, что питон - наше все. и погрузился. И до поры до времени, пока задачки были уровня вытащить из базы модельку, отдать ее на фронт и что-то поворочать на бэке по разжеванному сценарию - все было хорошо.
Или как? В данном случае АНАЛИТИК должен был проаналитить задачу и предложить алгоритм?
Так и я про то же! Программист-профессионал (который взял фундаментальное образование) - он и в аналитику может и в тестирование и, в админы и прочая-прочая. Самоучка может только в ЯП и идти четко по сценарию.
GPT3? Dall-E? Беспилотники Яндекса? Торговая платформа биржи? Вряд ли на такое способны самоучки без фундамента.
И я бы ещё понял если бы вы действительно были хорошим профессионалом в области разработки,
Ну, вам не известно на сколько я хороший профессионал.
такой выпендреж от человека который считает DOM чем то особенным
Я не считаю его чем-то особенным. Я считаю, что JS - сильно недостаточно для веб-разработки. И DOM недостаточно. И React без JS - все равно недостаточно. Но автор статьи решил, что JS - сделает из новичка веб-программиста.
nosql базы новинкой,
nosql появились в конце нулевых, начале 10х. Т.е. им 10-15 лет. Реляционным СУБД уже полтинничек стукнул. Так что чем не новинка?
а Solid, принципами которые "вот-вот сформулировали".
А что? Не вот-вот? )) Их сформулировали в начале 2000х. Я как раз учился в институте тогда. И нам в ВУЗе про них не рассказывали. А популярность они обрели уже в 10х. И теперь ни один собес не обходится без паттернов/солида.
плохо но хотя бы имели бы право, но вот странно слышать такой выпендреж
Осталось уточнить, с какой радости вы высшее образование считаете выпендрежом.
Выпендрежом я считаю деление программистов на кодеров и программистов, себя как понимаю вы причисляете с "высшей касте"?
Для индустрии которой 20-30, с натяжкой 40 лет, 20 лет это совсем не вот вот, и без разницы когда были разработаны реляционные базы, антикерскому механизму 2200 лет стукнуло, это не делает индустрию it 2200- летней. если для вас nosql, solid это новинки, я могу лишь (на основе только этих данных, других вы так и не предоставили) сделать вывод что либо вы очень далеки от этих областей (хотя solid более менее универсален, местами даже слишком), либо вы просто некомпетентны, то есть слышали но не пользовались, экспертизы нет, это в принципе нормально, на зачем тогда выпендриваться и рассуждать, у меня нет экспертизы в ИИ или микроконтроллерах, я и не даю советы разработчикам в этих областях. ну да ладно.
Вы привели пример из специфической области, требующей специфической математики. Но почему-то из этого сделали вывод что эта математика необходима для всех доменов. Но ведь это не так. в других доменах нужны будут другие знания. Но это же не повод учить в университете медицину, ботанику, документооборот, бухгалтерию, продажи, рекламную индустрию и прочее и прочее. Приходя в компанию или на проект прогаммист осваивает домен на минимальном необходимом уровне, его задача понимать о чем речь. В хорошей компании, если требуется экспертиза достаточно высокого уровня, нанимают специалиста этого профиля. В данном случае, вот уж сюрприз, наняли бы математика , и не просто математика а математика нужного профиля с опытом в аналогичных задачах, и добавили бы его в команду, в качестве консультанта, или для разработки математических моделей которые программисты уже бы реализовывали. Представляете, программирование это командная работа, если конечно это взрослая компания ориентированная на результат, типичные ситуации заводов СНГ когда программист и швец и жнец и метал кроит, и станки программирует, и камеры подключает и бухгалтерии винду ставит я не рассматриваю, это извращение.
Фундаментальное образование? ну в принципе я не против, оно имеет смысл. но не в таком виде какой есть сейчас, и не настолько большой насколько вы его превозносите. Если кратко основные проблемы в области IT и на пространстве СНГ: устаревшие требования, излишняя универсальность, плохое понимание теми кто создает программу и преподает реалий разработки софта, огромная инерционность, за частую полное отсутствие у преподавателей практики и следовательно экспертизы, непонимание рынка разработки и рынка труда IT, отсутствие качественной конкуренции между вузами и как следствие отсутствие внятных мотиваторов для решения проблем выше, туда-же подчиненность программам всяких министерств, люди в которых относятся к IT так же как и к математике или истории, по принципу "за 20 лет ничего не поменялось, компьютеры как были ящиком с экраном так и есть, так чего программу зря пересматривать".
Если более полно то, как результат на выходе люди с "фундаментом" который состоит из непонятных кусков (большинство из которого никогда не пригодится, часть безнадежно устарела, меньшинство пригодится очень иногда), и больше у них ничего, они не готовы к работе, ни в какой области, они универсалы которые ничего не знают, ничего не умеют, к моменту когда им будет нужна эта математика (если они ее еще не забыли к моменту получения диплома) они ее точно забудут. Исключение - 1-2 на тысячу которые попадут в узкую область, тогда им пригодится процентов 20 а не 2. То есть вместо того чтобы дать знания которые позволят начать уже сейчас что-то делать, и научить работать с информацией, учится, развиваться - дают некую абстрактную базу которая абсолютна не нужна ему в этот момент (джуну) но может пригодится позже, но вот того что нужно у него просто нет. получается человек потратил 5 лет зря, он не готов к работе, но у него есть база. теперь ему нужно, как любят говорить в универе "забыть все чему учили ранее" и начать учится. Подход который подойдет для стабильных областей, которые развиваются медленно, полностью бесмысленнен для таких динамичных областей как IT. тут правильный подход "учится всегда" а не "сделать из человека специалиста и потом он эти знания всю жизнь применять будет". Если вы действительно разработчик, а не эникейщик на заводе или преподаватель в университете, вы должны прекрасно понимать что то что вы называете "фундаментом" на самом деле всего лишь кусок знаний для одной области. и разработчик изучает такие вещи по мере необходимости, или если изучить это достаточно быстро невозможно, на нужном уровене, то подключается специалист и они работают вместе, каждый в своей области на общий результат. Универсалы программисты невозможны. Программисты, которые после универа ничего не изучают - бесполезны (за редкими исключениями, очень редкими и специфическими). Программист может в тестирование, но на уровне "понимаю о чем речь и как с этим взаимодействовать", так же он может и в devops, и в менеджмент, и в аналитику, и в доменные знания. но хороший программист не заменит хорошего PM, для этого ему нужно быть И хорошим программистом И хорошим PM. учитывая на то что чтобы стать хорошим в каждой из областей связанных с разрабокой нужно 5-10 лет, и многие знания быстро устаревают, выводы можете сделать сами, универсалов не существует.
"GPT3? Dall-E? Беспилотники Яндекса? Торговая платформа биржи? Вряд ли на такое способны самоучки без фундамента." - вот в этом и суть, для каждой из этих областей нужен свой "фундамент". И да, среди людей которые это разрабатывают много как вы выразились "самоучек". Я без понятия почему самоучка у вас звучит пренебрежительно, умение учится самому, качественно и быстро - один из ключевых навыков программиста.
Ну а теперь гвоздь нашего вечера "А вот в решении эпических и легендарных задач, всплывут вопросы, о которых самостоятельно вы 100% не задумаетесь.". Чего? Легендарных задач? Эпических? А где Божественные? Доспехи легендарные знаю, задачи нет. Да, плохой юмор, плоский, ну так ночь на дворе. Но откуда столько помпезности? Бывают задачи сложные, бывают простые, бывают интресные, бывают рутинные, почти все требуют специфических знаний и опыта в какой-то своей области. вы там писали про "что-то поворочать на бэкенде", ну простите, упомянутые вами биржи это вполне "что-то поворочать на бэкенде", причем не самое сложное поворочать, да очень высокие требования к нагрузкам, консистентности данных и стабильности но в плане логики я бы не назвал их особо сложными. Так вот, а вы "ворочали"? сможете? ваша математическая и прочая база дает вам эту специфическую экспертизу, которая позволит делать эти вещи? или все же нужна специфическая "база"? Разные задачи бывают, и разные домены и опыт, и соответственно разные знания необходимые для них, но о Легендарных и Эпических еще не слышал.
Ладно, может я что-то не то делал последние 20 лет, не туда модельки передавал, давайте решим этот спор раз и навсегда хотя бы в рамках этой статьи. Раз уж вы столько писали про кодеров и программистов, про рутину и Эпические задачи, про быдло и элиту (косвенно, этих слов вы не писали но в каждом комментарии прослеживается), про фундамент и базу, и конечно же про его величество Фундаментальное Образование без которого хорошим программистом не стать, в принципе, невозможно вот совсем, может все же покажете нам неучам на примере, какой он настоящий программист (а не кодер) который занимается Легендарными задачами (а не модельки таскает и что-то там шебуршит)? Опишите одну, одну единственную, не прошу много, но по настоящему Легендарную задачу, которую вы делали, и как именно в ней вы использовали свой фундамент и какой.
Давайте от абстрактного эпоса и пафоса спустимся к конкретике, не надо описывать ничего что закрыто NDA, в общих чертах - домен, проект, задача, что делали, почему считаете ее Легендарной (или даже Эпической) и какие знания и вашего фундамента вам пригодились. На ваш выбор, что угодно, лишь бы легендарное по максимуму. У меня только одно требование (и тут полагаюсь на вашу честность, потому что называть проект не обязательно, может быть закрыто NDA) - проект должен быть реальным, коммерческим, живым или "жившим", короче проверенным реальностью, пользователями а не написанным в стол. дипломы, курсовые, пет-проекты которые не увидели свет - все это мимо, потом что необьективно, они в глазах автора могут быть не просто Легендарными а даже Божественными, но по факту оказаться кривым бесполезным велосипедом с кучей проблем, все мы такое делали, нет, только прод показывает истину. Я понимаю что надоел с этой просьбой, но ведь один пример лучше тысячи абстрактных воззваний, да и реально же интересно, что вы такое пишете чтобы считалось Легендарным и чтобы разделять программистов на "настоящих" и быдло кодерское, необразованное и бездипломное. Потому что даже софт для марсохода или упомянутые беспилотники в моем понимании не тянут на такой пафос, ИИ уровня Dall-E или ватсона, не знаю, может быть, как уже писал нет опыта в этой олбласти чтобы оценить, да и теория в этой области очень поверхностная, на уровне универа. Чем черт не шутит, а вдруг я ошибаюсь, и тогда мы предметно сможем поговорить и уже из частного выйти к общему и сделать выводы.
Так я изначально написал, что нужны и те и другие ) За что топлю я? За то, что программист - ПРОФЕССИЯ. Можно и без образования (в определенных условиях), но отрицать важность образования не стоит.
Можно научиться лечить болячки без образования? Лехко! Я - полноценный врач. Грамотно себе назначаю парацетомол, антибиотики и прочее... При этом если я подам объявление о врачебной практике, у меня справедливо спросят, где мое фундаментальное образование? Но, постойте, я в своей практике успешно лечусь парацетомолом и мне норм. Если парацетомол не помог - надо спросить совета у соседа со стажем и практиковаться дальше.
Кчему это? А в копилку аналогий ) При этом в АйТи без образования и можно и получается. Но - с оговорками.
Как понимаю каких либо личных примеров я не дождусь. Опять аналогии, которые как известно всегда немного врут. Ну хоть без пафоса и понтов, уже хлеб. Пора заканчивать, разговор потерял смысл, пруфов и примеров не будет, а без них это пустая болтовня, с таким же успехом можно кричать что каждому программисту нужно носить бороду и свитер, иначе не по канону и код будет плохой, без бороды программист не программист а кодер. И чем больше борода тем лучше программист. Доказывать не буду, это и так же всем очевидно. В качестве примера могу рассказать что программист который никогда не носил бороду накосячил в коде распознавания лиц и из-за этого первые face id глючили на бородатых людях. Не стоит отрицать критическую важность бороды в области разработки софта! Лишь люди с очень густой и длинной бородой способны написать Эпический код и решить Легендарную задачу. Угу, свёл к абсурду чтобы продемонстрировать нелепость воззваний без доказательств, бывает. На этом я все.
Для индустрии которой 20-30, с натяжкой 40 лет
Индустрии около 90 лет. Да, она изменилась до не узнаваемости, но фундамент - все тот же.
и без разницы когда были разработаны реляционные базы
А вы что доказать пытаетесь? Все еще пытаетесь прицепиться к словам и сохранить лицо, доказывая, что я - верблюд? )
Простите, антикитерский механизм в мире АйТи - это точно не реляционные СУБД. На это звание может претендовать машина Беббиджа, может и всякие методы счета на камешках, но никак не СУБД.
если для вас nosql, solid это новинки
"новинка" - это, как говорил мой науч. рук. - прилагательное. Конкретные даты я вам назвал, при чем не сам придумал. Предлагаю на этом прекратить обсасывание тезиса "сам дурак". Что я хотел донести своей простыней - повторил кратко, причем несколько раз. Это не фаллометрия, а напоминание, что АйТи - профессия. Со своим профессиональным образованием. Если вы отрицаете его необходимость - это ваше мнение. Не единственно верное, но имеющее право на существование. Правильно ли пропагандировать за ваш подход? Мое мнение - нет. Я привел примеры почему и где ваш подход будет узким. При этом всему свое время. Если школьник выбрал для себя путь айтишника и получил профессию - это одно, если состоявшийся специалист не из АйТи решил сменить род занятий, то тут да - базу освоить будет практически нереально. Просто по причине, что не возникнет необходимости. Если же этот момент подсветить (как я, или как список теоретический минимум программиста), то эффект будет лучше. Страждущий сможет подтянуть самостоятельно свои пробелы в знаниях.
Вы привели пример из специфической области, требующей специфической математики.
Что такое специфическая математика? Теория сложности? Я вас умоляю. Это - основы computer science. Универсальные основы. Которые всем нужны. Раскрой-упаковка? Так это подраздел исследования операций. Как бы тоже основы computer science. Я сейчас страшное скажу: простые модели, вроде рюкзачной задачи или задачи коммивояжера, формулируются наглядными примерами. При этом приложения у них самые разнообразные. Из самых разных областей. Это не специфичная узкая математика.
Но это же не повод учить в университете медицину, ботанику, документооборот, бухгалтерию, продажи, рекламную индустрию и прочее и прочее.
То, что прикладные программисты имеют дело с ЛЮБЫМИ доменами означает ровно одно: у ПРОФЕССИОНАЛА должны быть способность без специфичного образования переварить задачу из любого домена, причем не потратив на это с пяток лет. И, что самое удивительное, это можно сделать! Нужно получить ФУНДАМЕНТАЛЬНЫЕ ЗНАНИЯ. Обычно такая триада идет: математика, физика, химия. У нас выпускники ВУЗа успешно погружались в научные работы по биоинформатике. Нет, программисты не стали получать дополнительно биологическое образование. Но технический бэкграунд позволяет изучать весьма компактные методички, написанные строгим научным языком биологии. И позволяет алгоритмизировать биологические задачи. И позволяет решать их.
Когда в ВУЗе щелкал формальные грамматики и другую дискретку, освоить бухучет - как два пальца об асфальт. Внезапно выясняется, что проводки на бух. языке - это выражения некого формального языка. А опыт уже наработан. Итог? Среднестатистический программист, бухучет способен вести лучше специально обученной девочки. Проверено.
Продажи? Реклама? Программист способен без особых усилий общаться с такими специалистами и способен переводить их хотелки в алгоритмы. Да, что-то почитать придется, но не 5 лет в ВУЗе.
Аналогично - с любым доменом. Есть база, она - помогает.
Приходя в компанию или на проект прогаммист осваивает домен на минимальном необходимом уровне, его задача понимать о чем речь
Это делать легче, если за плечами уже есть база в виде высшего профессионального образования. Я спокойно могу представить, как физик, понимает биологию. И с трудом - как историк понимает физику. Разный фундамент.
В хорошей компании, если требуется экспертиза достаточно высокого уровня, нанимают специалиста этого профиля.
Ага, значит у вас, судя по вашей же реакции на мой комент, крепкая экспертиза ведения бизнеса?
а, или для разработки математических моделей которые программисты уже бы реализовывали.
Сюрприз: в карточке моей специальности черным по белому написано, что программист способен разрабатывать мат. модели.
и не просто математика а математика нужного профиля с опытом в аналогичных задачах, и добавили бы его в команду, в качестве консультанта,
Знаете, я читал много интервью с Олегом Медоксом. Из его слов вытекает, что все мат. модели полета и полетной физики разрабатывали... Программисты!
И это - не единичный случай. В одной питерской игрописной конторе, возникла задача улучшить честность ИИ, но в этом случае движения получались дергаными. Нагуглили задачу TBU (truck backer-upper problem) и погрузились в математику задачи... Правда там не возникало вопросов в необходимости фундаментального образования. Ибо тим лид - выпускник СПбГУ, тех. дир. - профессор СПбГУ. Просто: возникла задача - ее решили. Без найма доп. персонала.
типичные ситуации заводов СНГ когда программист и швец и жнец и метал кроит, и станки программирует, и камеры подключает и бухгалтерии винду ставит я не рассматриваю, это извращение.
А вы твердо уверены, что имеет место быть именно такое? Сочувствую.
Я про ситуацию, когда интегратор выигрывает тендер на автоматизацию и делает проект для завода на аутсорсе.
ну в принципе я не против, оно имеет смысл. но не в таком виде какой есть сейчас, и не настолько большой насколько вы его превозносите
А это уже другой вопрос. Вся моя изначальная простыня была просто, чтоб показать, что мир - гораздо больше языков программирования. По моему, весьма красочно получилось. Вас - бомбануло. Цель достигнута.
Нужно реформировать образование? Имхо - нужно. Нужно выкидывать общенаучный курс из ВПО? Большой вопрос. Да, в высшем образовании ему, видимо не место. Кажется, что философия, политология, история и прочее, что не имеет отношения к специальности, можно закинуть в 10-11 классы школы. А образование оставить специальным. Но это спорный вопрос.
Насколько велика роль высшего образования в индустрии? А это зависит лично от вас. Какую планку вы себе ставите? Правило Парето прекрасно работает в индустрии.
устаревшие требования, излишняя универсальность, плохое понимание теми кто создает программу и преподает реалий разработки софта, огромная инерционность, за частую полное отсутствие у преподавателей практики и следовательно экспертизы, непонимание рынка разработки и рынка труда IT, отсутствие качественной конкуренции между вузами и как следствие отсутствие внятных мотиваторов для решения проблем выше,
Еще на первом курсе, на самой первой лекции по информатике препод ровно так и сказала: вы изучаете сейчас те технологии, которые устареют к вашей защите. Математика не устареет никогда.
Мораль? Программист учится всю жизнь. Либо вылетает с рынка. Отсюда, самое ценное, что может дать ВУЗ - это вовсе не фреймворки и не конкретный ЯП. ВУЗ может дать СИСТЕМНОЕ ОБРАЗОВАНИЕ.
У нас в не самом крупном ВУЗе, все преподы, кроме самых стареньких - практикующие программисты. А самые старенькие - ведут как раз фундаментальные дисциплины, вроде методов оптимизации. И, кстати, преподы приветствовали сдачу работ на нестандартных для ВУЗа языках программирования. Весь поток пишет на Delphi, потому что так проще. А несколько человек - на плюсах. Получают свой профит.
к IT так же как и к математике или истории, по принципу "за 20 лет ничего не поменялось, компьютеры как были ящиком с экраном так и есть, так чего программу зря пересматривать".
Самое интересное, новинки есть во всех науках. В математике тоже примерно до хрена всего нового происходит.
А другое интересное - программа сейчас меняется каждый год. И утверждается каждый год. Что неиллюзорно доставляет преподам. Так что, новинки или нет - это на 100% от препода зависит. Что захочет, то и даст. И если преподу влом следить за новинками - это именно преподу влом. Но я понимаю, система такова, что отдала этот вопрос на откуп преподам.
Если более полно то, как результат на выходе люди с "фундаментом" который состоит из непонятных кусков
Кому как. У меня с кусками все ок. Я понимаю что с чем и каким образом взаимосвязано и в голове вполне стройная система.
и больше у них ничего, они не готовы к работе, ни в какой области, они универсалы которые ничего не знают,
Это не так. Они готовы к работе программистом-стажером. Ну а дальше все зависит от того, кто что из образования взял. Кому-то - не дано. Так бывает. Кто-то готов горы сворачивать и у него глаза горят.
к моменту когда им будет нужна эта математика (если они ее еще не забыли к моменту получения диплома) они ее точно забудут.
Это работает немного не так. Леммы-Теоремы-Доказательства - забываются напрочь. Концепции - остаются. И к моменту, когда эта математика будет нужна, программист будет точно знать, что нужно в памяти освежить, и чем чревато. Например, мне в голову не придет сравнивать две небольшие выборки случайных величин тупо по среднему арифметическому. У меня в голове всплывет, что результат такого сравнения - случаен. Нужно подключать мат. статистику и пользоваться инструментами сравнения мат. ожиданий. Я забыл подробности. Но я знаю, что нужно гуглить.
Если у меня нет бэкграунда в виде теор. вера, я даже знать не буду, что так делать нельзя. Просто потому что мимо. Не очевидные знания.
То есть вместо того чтобы дать знания которые позволят начать уже сейчас что-то делать, и научить работать с информацией, учится, развиваться - дают некую абстрактную базу которая абсолютна не нужна ему в этот момент (джуну) но может
Теория сложности и алгоритмы - на всю жизнь. Это просто образ мышления. И он радикально отличается у самоучек и у профессионалов.
Физика, матан и прочие высшие материи, которые прям сейчас не нужны - они вколочены в головы малой кровью и дают в голове систему.
Я сплю и вижу, как 50 летний дяденька изучает матан, мат.стат, диффуры в своем великом возрасте, потому что ему понадобилось, а в 20 летнем возрасте он не удосужился это получить. Очень сомнительно. А вот очередную Java в полтос - без проблем. Она прекрасно ляжет рядом к огромному базису.
А чего же не дополучил джун? Жабу? Сишарп? Котлин? Питон?
Представляете, интеграторы частенько организуют курсы жабы, куда приглашают, в том числе, дипломированных специалистов. Еще 1-3-6-12 месяцев и перед вами готовый джун со всеми необходимыми навыками. Это называется профессиональная переподготовка. Кстати, там тупо указывают минимальные требования и не интересуются, имеется ли вышка.
Все упирается, куда сядут эти курсы джавы. Или на подготовленный базис, где уже вращаются знания по SQL, алгоритмам и определенный опыт программирования на любом языке, или на умения продавать продавать пылесосы или коровам хвосты крутить.
Что интересно, видел всякое. "Профессиональные программисты" с дипломом - тоже не все одинаково полезны. Видел таких, которым давали-давали фундаментальное образование, а они его не взяли. Ну бывает, че. И это тоже проблема.
получается человек потратил 5 лет зря, он не готов к работе, но у него есть база. теперь ему нужно, как любят говорить в универе "забыть все чему учили ранее" и начать учится.
Это как в анекдоте? Чем отличается атеист от представителей 2000 конфессий? Только тем, что он считает ошибочными на одну религию больше.
Вы же сами говорите, что программист - учится всю жизнь. Ну так он и учится всю жизнь! Что мешает начать учиться еще в ВУЗе? Что мешает в ВУЗе программировать на современных языках? Ко мне подходил выпускник ВУЗа - он все работы писал на питоне. Питон сейчас не востребован? Востребован.
Таки проблема в другом: на лабораторках и курсачах студент учится делать лабораторки и курсовые. У него не закладываются навыки реальной работы. Ну так я это решил просто: устроился на работу во время учебы. И к окончанию ВУЗа у меня уже был 4 летний стаж реальной работы. Но даже если и нет. После трудоустройства навыки реальной работы быстро прививаются. Выпускник вполне способен за год-два дойти до уровня миддла.
тут правильный подход "учится всегда" а не "сделать из человека специалиста и потом он эти знания всю жизнь применять будет".
Так и я о том же. Отличия только в том, что я еще плюсом к "всю жизнь учиться" подчеркиваю важность математики и вообще "теоретического минимума программиста".
е, вы должны прекрасно понимать что то что вы называете "фундаментом" на самом деле всего лишь кусок знаний для одной области.
Я прекрасно понимаю обратное. То, что я называю фундаментом - является фундаментом. А вот применяете вы этот фундамент или нет - совсем другой вопрос.
Этот фундамент - тесно переплетен друг с другом. И невозможно выдернуть отдельно от матана теорию сложности. По отдельности - это бессмысленные куски. А вместе - система научного знания.
или если изучить это достаточно быстро невозможно, на нужном уровене, то подключается специалист и они работают вместе, каждый в своей области на общий результат.
Программист - и есть этот самый специалист. Выше я приводил прекрасные примеры.
И да, профессионал и кодер могут работать вместе на общий результат. О чем мы вообще спорим? Вас по сути, зацепило лишь уничижительное "кодер" и вы не хотите в высшее образование. Вы хотите вопросы по сложнее спихнуть, например, на аналитика. я же говорю, что это тоже программист, но, который смог в высшее образование.
Универсалы программисты невозможны.
Сейчас всплакну ) В свое время был в геймдеве, потом в бухгалтерии, в науке и в энтерпрайзе... Успел и в Delphi и в C++ и в джаву и в 1С. Видимо, я джун везде, хотя и на позиции сеньора..
Но да, с окончанием ВУЗа учеба не закончилась.
Программист может в тестирование, но на уровне "понимаю о чем речь и как с этим взаимодействовать"
Программист может в тестирование на том же уровне, на котором он может программировать. Сеньор? Значит и тестер - сеньор. Причем - автотестер. Хинт: перед тем, как свои поделки программист передаст тестеру, он сам ТЕСТИРУЕТ свое творение. И юнит тесты пишет. И интеграционные. И еще какие.
так же он может и в devops
И не является девопсом не потому что не спец, а потому что роль у него другая. Есть проекты, где каждый программист - сам себе девопс. Было внезапно, но работает.
но хороший программист не заменит хорошего PM,
Хороший PM может вырасти из хорошего программиста.
стать хорошим в каждой из областей связанных с разрабокой нужно 5-10 лет
Не соглашусь. Если программист - профессионал, то войти в другую область и стать в ней профессионалом - год максимум. Опыт и база рулят.
Да, тулзы меняются, но опыт остается.
Да, индустрия выросла. Но тут вы правы - программист учится всю жизнь.
вот в этом и суть, для каждой из этих областей нужен свой "фундамент".
Неа. Фундамент везде общий. Приложения разные. А математика - она одна.
И да, среди людей которые это разрабатывают много как вы выразились "самоучек"
Ну, смотрите, самоучка самоучке - рознь. У меня коллега пришел в разработку из ядерной физики. Блин, у него без программистского образования фундамент хоть куда. Естественно, он досамоучится до удобоваримого состояния за не фиг делать.
А другой самоучка - он машины продавал. И на входе показал такой говнокод, что волосы шевелятся. Но! Он упорный и твердо идет к цели. Он тоже в айти, только ему придумывать алгоритмы и способы нормализации данных - не с руки. Зато он может нарисовать обвес. Дайте API - на выходе будет готовый сервис.
А вообще, я не особо понимаю, как "самоучка" может пройти, элементарно, собес. Ну вот у человека нет вышки. И ему дают на собес олимпиадную задачку по программированию. На 40 минут. Ну в принципе, на этом вся магия и заканчивается. Не прошел отбор.
Я без понятия почему самоучка у вас звучит пренебрежительно, умение учится самому, качественно и быстро - один из ключевых навыков программиста.
Самоучка решил заработать карму и написал сию статью. Качество вызывает фейспалм. В принципе, этим все сказано. Вы же топите за то, что когда возникнет потребность - вы обратитесь к специалисту. Ну так профессиональный программист - и есть тот самый специалист. Который не только учится всю жизнь, как самоучка, но еще и осилил в профессиональное образование и имеет отличный бэкграунд.
"что-то поворочать на бэкенде", причем не самое сложное поворочать, да очень высокие требования к нагрузкам, консистентности данных и стабильности но в плане логики я бы не назвал их особо сложными.
Так вы видите сложность в этой задаче? Или нет? Высокие требования к нагрузкам - вам нужно знать архитектуру до гвоздика, чтобы понимать где и что оптимизировать. Вам нужны алгоритмы, чтобы понимать временную и пространственную сложность. И, будьте уверены, там в плане логики все тоже не просто. И в плане математики - тоже. Можно вот этот кусок заменить на тот? Точно? Докажи. И понеслась.
, но о Легендарных и Эпических еще не слышал.
У Кнута в издании, кажется 89года было упражнение доказать Великую Теорему Ферма. При чем без имен и фамилий. При чем, подходили издалека. Была элементарная постановка, а рядом - задача со звездочкой. Задача по сложности была оценена в 50 баллов. Из 50. И означало это, что автору неизвестно решение задачи. Там же была сноска: "Если Вам удалось решить это упражнение, пожалуйста, свяжитесь с автором".
В 94м году, теорема была доказана.
Чем не Легендарная задача? )
В программировании тоже встречаются сложные задачи. При чем повсеместно. Достаточно оглянуться по сторонам. Геймдев из таких задач состоит чуть более, чем полностью. Но в свое время появился Unity и вся магия исчезла. Сейчас любой самоучка за 15 минут может сотворить игру. Правда, чтобы такая магия произошла, вполне себе не самоучки должны были этот самый юнити запилить.
про быдло и элиту (косвенно, этих слов вы не писали но в каждом комментарии прослеживается),
А вот с этим, прошу пардону, не ко мне. С этим - к психотерапевту. Что там вы проследили в моих комметариях - это по другому профилю.
Что я явно имел ввиду - я уже многократно повторил. Что вы сами себе придумали - на меня не вешайте.
Опишите одну, одну единственную, не прошу много, но по настоящему Легендарную задачу, которую вы делали, и как именно в ней вы использовали свой фундамент и какой.
Я не буду с вами играть в эту игру. Примеры - выше по комментариям. И нет, там не про легендарные задачи. Просто про те, куда путь самоучкам (без негатива), закрыт. Легендарные задачи - естественно есть. Когда я вижу результат обучения RUGPT3 - это именно, что легендарная задача. Когда я вижу, как робот-доставщик вполне вменяемо ездит по улицам - это тоже легендарные задачи решены, куда самоучкам путь закрыт. Когда на конференции аспиранты рассказывают про архитектуру нового робота - там тоже самоучкам путь закрыт.
А вообще, я не особо понимаю, как "самоучка" может пройти, элементарно, собес. Ну вот у человека нет вышки. И ему дают на собес олимпиадную задачку по программированию. На 40 минут. Ну в принципе, на этом вся магия и заканчивается. Не прошел отбор.
И я не пройду. С двумя вышками и 20 годами программистом. Потому что в разработку пришел "доцент". Откинулся из науки на свободу.
Мужчины не меряются размером лба. Это проф. деформация вузовской зоны где конкурентная иерархия.
А когнитивный интеллект - штука такая, скорее баланс гуманитарных и технических, без перекоса в глубокую яму отдельных наук.
И я не пройду. С двумя вышками и 20 годами программистом. Потому что в разработку пришел "доцент". Откинулся из науки на свободу.
Я общался с людьми, кто прошел и кто успешно работал и применял навыки. Их есть. Если вы не прошли - значит ваши навыки не дотягивают до требований компании. Все в ваших руках. У Яндекса есть список рекомендованной литературы, дабы прокачать навыки.
Кто и куда откинулся - пробуйте задать вопрос непосредственно в Яндекс. Но, смею предположить, все гораздо проще. Яндекс хотят видеть в своей команде профессионала, который может не только в синтаксис языка и стандартную библиотеку, но и может решать сложные алгоритмические задачи. Смею предположить, что это их желание основано на возникающих перед компанией задачах.
Реальный мир это всегда контекст. Гуманитарного происхождения термин. Взаимосвязи, окружение, сценарии - вот это все. Что инородно для математического восприятия мира, которое стремится именно к абстрагированию от любого контекста.
Математик со скальпелем в руках в контексте операции на живом организме - тот еще образ. Для него важно натянуть одно на другое из любви к искусству абстракции.
Яндекс - это другой контекст. Откуда он возник, мне непонятно.
Я общался с людьми, кто прошел и кто успешно работал и применял навыки.
Правильно я понимаю, что вы аспирант/доцент из вузовской/научной среды который устраивается в Яндекс или советует как устроится в Яндекс?
Или вы работаете в Яндекс и проводите интервью?
Реальный мир это всегда контекст. Гуманитарного происхождения термин. Взаимосвязи, окружение, сценарии - вот это все. Что инородно для математического восприятия мира, которое стремится именно к абстрагированию от любого контекста.
Ничего не понятно, но очень интересно ) Как наличие математической базы мешает воспринимать контекст? Как она помогает - я понимаю. Вы слышите постановку задачи от гуманитария и мозг автоматически раскладывает ее на известные модели и известные решения и показывает известные плюсы и минусы. Как но может помешать - не понимаю.
Математик со скальпелем в руках в ко
нтексте операции на живом организме - тот еще образ.
А вот если математик программирует робота-хирурга, то математика там нужна очень крепкая. Но мы ведь не про любые профессии? Мы - про программистов.
Для него важно натянуть одно на другое из любви к искусству абстракции.
Такое может сказать только человек далекий от математики.
На самом деле - математика очень конкретная наука. Да, можно ставить задачи из любви к прекрасному и натягивать одну абстракцию на другую. Но развитие математики сопряжено с решением весьма конкретных задач. Геометрия? Арифметика? Вообще очевидно откуда взялись. Дифференциальное исчисление? Механика потребовала. И т.д.
Яндекс - это другой контекст. Откуда он возник, мне непонятно.
Как пример компании, где требуются профессионалы, а не любители. Другой собеседник доказывал, что профессиональное образование не нужно. По крайней мере, всю математику - в утиль.
Правильно я понимаю, что вы аспирант/доцент из вузовской/научной среды который устраивается в Яндекс или советует как устроится в Яндекс?
Или вы работаете в Яндекс и проводите интервью?
Не правильно считаете. Но кандидатскую защитил и попреподавать успел.
Как наличие математической базы мешает воспринимать контекст? Как она помогает - я понимаю. Вы слышите постановку задачи от гуманитария и мозг автоматически раскладывает ее на известные модели и известные решения и показывает известные плюсы и минусы. Как но может помешать - не понимаю.
Общий опыт программирования и конкретный опыт работы в конкретной системе/фреймворке - вот что раскладывает. От математической базы при этом ни жарко ни холодно.
И биолог, и журналист, и режиссер, тоже прекрасно умеют раскладывать. Да, в кибернетике конечно есть математика, так же как и в автомобиле двигатель. Но хороший водитель тот кто может доехать из точки А в точку B без проблем и в срок. И тут про все про навигацию что не про математику.
От математической базы при этом ни жарко ни холодно.
От математической базы и холодно и жарко.
1) Вы понимаете теорию сложности (это - математика). А значит вы понимаете как быстро будет отрабатывать ваш алгоритм при прочих равных. И вы не будете делать ошибок, которые делает кодер, не знакомый с теорией сложности. То, что 4 вложенных цикла с итерацией по миллиону в каждом, плохо - ни разу не очевидно. Ок. Тут опытом можно набить шишек. А более сложные варианты? Где вложенных циклов напрямую нет?
Я понимаю, что большая часть задач не предполагают сложных алгоритмов. Но это вовсе не означает, что их нет. И там где они есть, голый опыт в решении простых задач - не поможет. Понадобится еще и понимание теории.
2) Куча разделов математики напрямую связаны с программированием и родились/получли развитие именно в программировании.
Ваш великолепный опыт сядет в лужу, когда вы займетесь не стандартными задачами компьютерной графики. Да, готовые движки покрывают большую часть задач, но есть и меньшая часть задач.
Есть огромный раздел методов оптимизации, когда нужно что-то где-то сэкономить, например, время обработки. Здесь тоже ваш прекрасный опыт сядет в лужу. Вы или знаете алгоритм/где про него почитать или не знаете. Еще веселее, когда реальная постановка отличается от классической модельной. Тут опять же, у вас или есть знания или их нет. Опыт вам этого не даст.
3) Некоторые разделы математики просто универсальны и нужны каждому. Например, теор. вер., мат. статистика, матан. Знание статистики подскажет, как избежать ложных выводов при работе со случайными величинами (т.е. практически всегда). Я это про всевозможные глубокоидущие выводы о повышении эффективности на 3% при анализе выборок в единицы объектов. То, что такие выводы делаются - говорит о том, что статистика прошла мимо. Человек даже не думает, что тут есть подвох, а он есть. И это не какие-то сугубо узкоспециализированные отрасли. Да просто торговля. Анализ маркетинговый мероприятий.
Ну в принципе, можно долго продолжать.
И биолог, и журналист, и режиссер, тоже прекрасно умеют раскладывать.
Нет, не умеют. У них область интересов совсем другая.
При чем, у биолога тоже есть математическая база, внезапно. И он будет использовать именно ее.
Программистские задачи отличаются от журналистских. Вам нужно понять постановку и придумать как ее решить. Алгоритм придумать.
Да, большинство задач содержат алгоритм решения в своей постановке. И тут вам нужно знать фреймворк, ЯП и иметь опыт. Но, то, что таких задач большинство, не означает, что нет других задач, где очевидный алгоритм будет очень хреновым или вообще не будет очевидного алгоритма.
Без навыков математики, вы можете писать обвес под голосовые помощники, но не сможете, разрабатывать ядро. Без математики, вы можете написать фронт к торговой системе, но вас не пустят пилить ядро.
Ну и т.д.
Но хороший водитель тот кто может доехать из точки А в точку B без проблем и в срок.
Хороший водитель помимо прочего знает физику на неплохом уровне и очень не плохо представляет себе устройство авто.
Или не водитель?
Подготовка пилотов ОБЯЗАТЕЛЬНО включает в себя аэродинамику (физика), метеорологию (там тоже физика есть), устройство самолета (при чем, не абстрактное, а своего типа, на который есть допуск). При чем, тут требования не просто высшего/среднего образования. Тут требования производителя самолетов. Как думаете, почему? Ведь можно продолжить: хороший пилот - тот, кто может долететь из точки А в точку Б без проблем и в срок?
От математической базы и холодно и жарко.
Математика она есть и на крыльях бабочки, и нужна и токарю, и снайперу. И даже повару. Но мы ведь о другой базе, верно?
Той самой которая чтобы алгоритм.
Но как много математики в алгоритме заварки чая?
Сколько алгоритмов на кухне ресторана? Сколько там математиков на этой кухне?
Программистские задачи отличаются от журналистских. Вам нужно понять постановку и придумать как ее решить. Алгоритм придумать.
Ну вот после 20 лет программирования, ко мне на кухне где все жарится и тушится, шипит и шевелится, заходит Учитель и говорит что мне нужна Математика.
Можно еще пойти в воинскую часть и учить снайперов расчетам упреждений с учетом высоты и скорости ветра.
Или журналиста поучить как найти и анализировать информацию.
Без математики, вы можете написать фронт к торговой системе, но вас не пустят пилить ядро.
Про "пилить", особенно от научного работника.
– Ничего не понимаю. Неа, это не золото.
– Пилите, Шура, пилите.
Навыки повара по умению держать процесс и журналиста по работе с информацией - сейчас гораздо более нужнее в программировании. Терпение и выдержка снайпера важнее чем его математические способности.
Доля математики есть. Но эдакая 1/12 в общем наборе. Не стоит ей так высоколобить.
Математика она есть и на крыльях бабочки, и нужна и токарю, и снайперу. И даже повару. Но мы ведь о другой базе, верно?
Той самой которая чтобы алгоритм.
Окей, реальный пример. В бухучете есть математика или нет? Не сложение/умножение/дебет/кредит, а такая математика, чтобы побалдеть?
А если найду? ))
Задача называется расчет себестоимости. Из года в год в мире 1С жил партионный учет для расчета себестоимости. Как это работало?
Все проводки в 1С делаются документами. Чтобы документ сделал проводки - его нужно провести. В момент проведения запускается алгоритм, который что-то считает и результат расчета пишет по разным агрегатам. В терминах 1С - регистры бухгалтерии, регистры накопления и т.д. Затем по этим агрегатам можно быстро строить отчеты.
Так вот, про себестоимость. В числе прочего, документ пишет записи по расчету себестоимости. Если это торговая контора, то документ реализации для проданного товара подыскивает купленную партию товара и считает для нее закупочные цены.
В чем беда? Менеджеры/бухгалтера вводят документы вразнобой в 100% контор. Нет и не может быть такой схемы работы, чтобы документы проводились в хронологическом порядке. А проведение в разнобой портит себестоимость (неверно подбираются партии).
Чтобы себестоимость посчитать, нужно восстановить последовательность проведения документов.
В разных конторах этот процесс занимает сильно разное время. Например, в не самой крупной конторе, перепроведение квартала занимает неделю.
И только по окончании этого процесса, можно увидеть реальные цифры по себестоимости.
Можно улучшить процесс?
Можно. Можно ввести специальную сущность "последовательность", которая будет затрагивать только документы, релевантные себестоимости. Например, в целях корректного расчета себестоимости, в последовательность войдут закупки, продажи, возвраты и перемещения со склада на склад. И не войдут, например, кадровые документы или чисто бухгалтерские (если речь об управленческой себестоимости).
Дает это выигрыш? Дает. Процентов 10. Т.е. вместо недели, теперь последовательность восстанавливается 6 дней. Круто, выиграли аж целый день.
Это - путь "программиста".
И пока не впечатляет. Можно еще лучше? Можно! Надо переработать алгоритм проведения. Давайте из проведения уберем все проверки, например, на наличие партий. И будем эти проверки делать уже по факту, когда все проводки сформированы. Круто. Выиграли еще 10%. И это тоже путь "программиста". Математики здесь нет, даже на крыльях бабочки.
А теперь давайте применим, наконец, ту самую "мифическую" математическую базу, которая вам на хрен не нужна (выж 20 летее не применяли и не собираетесь).
Ок. Можно заметить, что все проводки, связанные с себестоимостью формируют граф затрат. Изменения стоимости происходят только внутри центров затрат. Что такое центр затрат? Это совокупность аналитик, имеющих важность для потребителя информации. Склад, организация, вид запасов (продукция, полуфабрикат, сторонний товар и т.д.), контрагент и т.д. И в какой бы последовательности мы не проводили документы, меняться будут только цифры, центры затрат - гвоздями прибиты к документу.
По каждому центру затрат мы можем посчитать себестоимость товара - для этого нужно сложить все входящие потоки стоимости и вычесть все исходящие потоки. Количества известны, остатки - тоже. Соответственно, себестоимость можно найти, решив линейные уравнения.
Итак, получаем следующий подход:
1) В момент проведения документа мы пишем в специальную таблицу ребра для графа затрат. В этот момент нам не важно, в какой последовательности проведены документы. Важно, чтобы все документы были проведены в любой последовательности. От этого зависит, полностью будет собран граф или нет.
2) В момент, когда захотим посчитать себестоимость, собираем граф затрат и по графу затрат строим СЛАУ.
3) Решаем численно СЛАУ. Любым методом. В 1С - метод Ньютона.
4) Получаем себестоимость.
Теперь не нужно восстанавливать последовательность проведения документов вообще. Документы проводятся в момент введения и больше к этому вопросу не возвращаются вообще.
В той самой конторе, где последовательность восстанавливалась неделю, себестоимость стало возможным получить за 10 минут.
Приведенная простыня - это эволюция расчета себестоимости в 1С, во всей линейке учетных систем. Последний алгоритм носит название РАУЗ: Расширенная Аналитика Учета Затрат.
Сначала, для решения СЛАУ на SQL формировался запрос чудовищного вида и размера (около 30000 строк), позже - для поддержки этого метода в платформу был добавлен объект РасчетСистемЛинейныхУравнений.
Что интересно, 1сники так и не поняли смысла новшества, а оно применялось прям в типовых решениях.
Но, кажется, кто-то должен этот алгоритм придумать. Я правильно понимаю, что в вашей картине мира это делает кто угодно (аналитик, методист, математик, экономист, финансист, штатный астролог), но не программист?
Но, кажется, кто-то должен этот алгоритм придумать. Я правильно понимаю, что в вашей картине мира это делает кто угодно (аналитик, методист, математик, экономист, финансист, штатный астролог), но не программист?
Добавление таблиц для хранения/подсчета текущей себестоимости чтобы не ходить по всем проводкам - это шаблонное решение, уровень старшего программиста. Именно решение, на базе знания системы/продукта и предметной области.
Математика на уровне 7 класса школы здесь она конечно есть, в виде линейных уравнений. Но опять таки, школьная алгебра.
Вы подменяете уровень старшего программиста (senior) фигурой математика, и решения которые он принимает каждую неделю на автомате, в силу опыта разработки, показываете как апофеоз математической мысли.
старший программист != математик
решение != математическая модель
Добавление таблиц для хранения/подсчета текущей себестоимости чтобы не ходить по всем проводкам - это шаблонное решение, уровень старшего программиста.
ШТОАА?? )) Я, конечно, прошу пардону, но так удобно рассуждать, когда алгоритм перед глазами. Придумать его - это задача. Простите, я не случайно показал метания именитой конторы, которая не видела "шаблонного" решения ажно 20 лет.
И вообще, что есть крутая математика? Численные методы решения диффуров вчастных производных? Так, если это все разложить на алгоритмы и перевести в программы, то останутся только сложения да умножения. Как вы говорите, уровень 7 класса?
Добавление таблиц для хранения/подсчета текущей себестоимости чтобы не ходить по всем проводкам - это шаблонное решение
Таки исторически и были таблицы для подсчета чего угодно, чтобы не ходить по проводкам. Такие таблицы называются "регистры" и они умеют считать итоги. Я же описал в чем проблема? Проблема в том, что записи в этих таблицах становятся не актуальными и зависят от порядка проведения документов. И возвращаемся к проблеме восстановления последовательностей.
Шаблонным вы назвали решение, которое в несколько тысяч раз ускоряет решение задачи? Ну, сильно, че.
Именно решение, на базе знания системы/продукта и предметной области.
Ага. Вон оно что, Михалыч ) Таки вы считаете, что в нормативке бухучета зарыт АЛГОРИТМ? Спешу разочаровать: нет.
Что такое граф затрат? Что такое центры затрат? Как это все строится - это придумка от программистов 1С.
Программистов, которые могут в математику. И да, это уровень ведущего разработчика, который смог в математику. Как минимум в теорию сложности, теорию графов, линейную алгебру и численные методы. 7 класс.. Нуну... )))
Шаблонным вы назвали решение, которое в несколько тысяч раз ускоряет решение задачи? Ну, сильно, че.
Именно так. Здесь нет математики, а есть записи в базе данных и события в системе.
То что вы называете в данном контексте алгоритмом, это очевидное архитектурное решение. Поздравляю, вас можно назвать старшим программистом.
И здесь все про базу данных и количество записей, про понимание операций которые делает пользователь.
То что видите на крыльях бабочки фракталы, а я нет, не мешает нам обоим пришпилить ее к стене. Это про долю математики в вашей оптике, а не про ее наличие в требуемых решениях.
Именно так. Здесь нет математики, а есть записи в базе данных и события в системе.
Вы или не слышите, или не хотите слышать. Я вам конкретно перечислил разделы математики, которые пригодились при разработке алгоритма РАУЗ. Теория сложности, теория графов, линейная алгебра, численные методы.
То что вы называете в данном контексте алгоритмом, это очевидное архитектурное решение.
Это я вас поздравляю, вы с очевидностью не понимаете о чем говорите, но продолжаете стоять на своем.
И здесь все про базу данных и количество записей, про понимание операций которые делает пользователь.
Нет. Здесь про другое. Увидеть в проводках общие закономерности. Увидеть другой подход к расчету. Применить голову.
То что видите на крыльях бабочки фракталы, а я нет, не мешает нам обоим пришпилить ее к стене. Это про долю математики в вашей оптике, а не про ее наличие в требуемых решениях.
Facepalm... В конкретном алгоритме РАУЗ есть КОНКРЕТНАЯ математика. А именно: численное решение СЛАУ. Если для вас численное решение СЛАУ - не проблема - это круто. Скорее всего это означает, что вы просто не втыкаете в суть проблемы. Те, кто более в теме, вполне себе могут порассуждать о сходимости, плюсах, минусах и асимптотической сложности.
И это я молчу про то, что эту самую систему уравнений нужно еще построить. А для этого нужно хотя бы знать, что такое граф и каким образом его можно представить в программе. Таких представлений несколько.
Далее, для доп. оптимизаций, с этим графом проводится доп. обработка. Дабы размерность понизить. И тут уже всплывают алгоритмы на графах.
Но да, если рассуждать с вашей колокольни, то получится, что "а какие графы? Коллекции, очереди - больше вам ничего не надо"
Это стандартная архитектура всех MRP/ERP систем там где такая проблема прохода по записям возникает. То решение о котором вы говорите я вижу как шаблонное начиная с 2004 года.
Этой стандартной архитектуре, которую вы видите, больше 30 лет. Вот только именно в таком "шаблонном" решении и возникает проблема с производительностью. Если вы не поняли, то неделю занимает восстановление актуальности записей в доп. таблицах. И в пресловутых сапах такая же проблема вполне себе есть. Возможно там быстрее за счет более аккуратной работы с СУБД, но сути не меняет. Покажите мне, где в САПе решаются системы линейных уравнений (численно, ага, 7й класс).
в первую очередь будет думать о записи в дополнительные таблицы для ускорения вычислений.
Любой отечественный программист думает о том же самом. Но вы просто провтыкали суть проблемы. А именно: эти дополнительные записи в дополнительных таблицах протухают при определенных действиях. И чтобы работать с валидными данными, нужно - правильно! Грохнуть не валидные данные и ЗАНОВО сформировать эти самые записи. Что и занимает конское время. В мире 1с. В Сап - аналогично.
А потом вы вы эти специальные таблицы используете при расчете.
Именно в этот момент и возникает математика, но вы упорно не можете этого понять.
Стандартная схема:
1) Берем агрегатные таблицы (регистры, в терминах 1С). Считаем итоги по ним (это быстро).
2) Выводим в отчет (это быстро).
Схема с себестоимостью прекрасно ложится сюда, но требует восстановления актуальности этих таблиц.
А вот как сделать, чтобы актуальность не портилась (и, соответственно, не пришлось выполнять трудоемкую процедуру) - ни разу не очевидно, не выпендривайтесь. И в 1С это решили.
Теперь схема выглядит так:
1) Берем агрегаты, восстанавливаем граф затрат.
2) По графу затрат составляем систему уравнений
3) Решаем ее. Можете попросить семиклассника помочь с программированием этого этапа. Пусть расскажет вам об особенностях алгоритма Ньютона. А 1С с ним поспорит и скажет, что они придумали оптимизации, которые понижают сложность алгоритма в логарифм раз (меньше, но вам по фиг: вы не втыкаете в асимптотическую сложность за ненадобностью).
4) Выводим отчет
И не математик его создает, а просто опытный разработчик.
Совершенно верно. Опытный разработчик, который знает теорию графов, линейку и численные методы. А еще прекрасно понимает вычислительную сложность своих решений и думает об оптимизациях. Математик, одним словом.
Но это про предметную область скорее где нужна математика.
Т.е. практически любая )
Давайте на примере врача (вы же любите аналогии?).
Врач утверждает, что в его обязанности входит заполнение карточки, ведение больничного листа и выписка рецептов на лекарства. Врач с опытом научился определять ОРЗ и назначать грамотное лечение. При этом врач глубоко убежден, что знать что-то сложнее воспаленного горла - это от лукавого. Тут нужны узкие специалисты. Не преувеличивайте, пациенты приходят только с больным горлом и все. Лучше потратить время на скоростное ведение карточки и на улучшение почерка в рецептах.
Как, пойдете к такому врачу лечиться?
В моей картине мира, программист способен в любую предметную область. И математика его не остановит.
А где-то нужно знать геологию при визуализации геологического софта, это OK.
Геологию вам геолог поставит. А алгоритмы этой самой визуализации где возьмете? Там как раз и возникнут интересные задачки, которые среднестатистическим Unity не покрываются никак. Но в моей картине мира, компьютерная графика - это часть образования программиста. И я, может быть, и забыл на хрен детали, потому что не пересекался с предметной областью уже 15 лет, но концепции помню. И о чем почитать - знаю.
его пространственное мышление, про его склонности, чем про знания математики.
Да ну вот жеж. Задача - построение выпуклой оболочки. Прекрасно пригодится в геологии, например.
Алгоритм, кстати, не сложный. Но только с опытом в программировании, без обременения математикой, вы 100% сделаете кратно тормознее.
Для вас программирование это создание алгоритма, c использованием математической базы. Обратите внимание как часто вы упоминаете слово "алгоритм".
То что вы упомянули как оргазмический триумф алгоритма
https://infostart.ru/1c/articles/181748/
это логическое представление для публики примерно такое же как UML диаграмма процесса для клиента.
Технический дизайн решения и собственно код будет бесконечно далек от этих формул. Так как средства реализации слишком примитивны. Где не математикой, а работой с памятью компьютера и структурами данных, особенностями именно программирования.
Даже если вы возьмете специальные языки для построения математических моделей это будет синтаксический сахар поверх многомерных массивов.
В моей картине мира, программист способен в любую предметную область. И математика его не остановит.
Именно так. Но если в контексте то именно предметное образование как к примеру экономическое/ бухгалтерское будет намного полезнее для 1С.
И в приведенном примере себестоимости, задача решилась бы точно так же и без подобной математически красивой иллюстрации. Бухгалтер + опытный программист.
автоматически определяет количество центров затрат, строит соответствующий граф. Затем формируется система уравнений и регламентными документами производится расчет себестоимости
Жалко что я не математик, потому что мне явно не хватает удовлетворения от понимания того что я строю именно граф:)
И формирование системы уравнений - это реально круто.
Математика не создает, математика - описывает.
Любой достаточно сложный процесс созданный просто прикладниками можно описать в формулах как триумф математики. В то время как это всегда элементарная работа с коллекциями в памяти и выборками из базы данных, при понимании прикладной области. Тупо в силу примитивности инструментов.
Поэтому в графе затрат удаляем все дуги, которые не отражают реальных потоков затрат. Одновременно учтем, что на начало месяца на любом складе могут существовать остатки товаров.
Сначала написали используя просто здравый смысл, потом задокументировали реализацию.
Математики они действительно нужны в программировании. Только не для того чтобы мучить студентов, а для того чтобы впечатлить пользователя глубиной.
Математика не создает, математика - описывает.
Для вас программирование это создание алгоритма, c использованием математической базы. Обратите внимание как часто вы упоминаете слово "алгоритм".
Программирование для меня - перевод алгоритма в ЯП. И тут нужно знать и фреймворки и иметь опыт программирования и все прочее, за что топите вы. Одно но: некоторые задачи решаются "в лоб". Вы продумываете архитектуру решения исходя из опыта программирования, а дальше реализация идет как по маслу.
Так вот, не все задачи решаются в лоб и с использованием только лишь опыта в программировании.
Есть задачи, где нужно применить мозг, подумать, разработать алгоритм (да-да, с применением математической базы). Примеры я вам привел.
Всякие архитектурные улучшения только опытом программирования и навыками создания удобных структур данных - это 10% прироста производительности. Математика в данном случае дала десятки тысяч процентов производительности. Просто была исключена самая трудоемкая операция. Без математики вы это решение не родите, не льстите себе.
То что вы упомянули как оргазмический триумф алгоритма
Начался детский сад какой-то... Вы с очевидностью не понимаете о чем говорите, но продолжаете настаивать даже там, где вы откровенно не правы.
А что вы не упомянули вот эту статью от самой 1С:
https://habr.com/ru/company/1c/blog/420029/
Там дисклеймер есть:
Важно: статья и описанный алгоритм требуют понимания линейной алгебры и теории графов на уровне первого курса университета.
И да, именно этот алгоритм и реализован 1ской в 1С. В саму платформу добавлен объект РасчетСистемыЛинейныхУравнений.
А вот статья на ИТС, как это использовать в приложениях: https://its.1c.ru/db/v8314doc#bookmark:dev:TI000002120
Технический дизайн решения и собственно код будет бесконечно далек от этих формул.
Нет, это не так. Загляните в код 1С. Там будет ровно две вещи:
1) Технологический обвес. Который нужен, чтобы собрать нужные данные.
2) Непосредственно решение СЛАУ по приведенным формулам.
Про п.2 выше статья на хабре. Про п.1 - это ровно то, за что топите вы.
Так как средства реализации слишком примитивны. Где не математикой, а работой с памятью компьютера и структурами данных, особенностями именно программирования.
Вы здесь бесконечно не правы. Не зная математики, вы тупо не родите те формулы, которые потом нужно будет перекладывать на работу с памятью компьютера. Я уже сотый раз привожу этот пример. Без математики вы решите себестоимость. Вы создадите кучу вспомогательных таблиц, вы даже что-то по оптимизируете. Но ваш результат будет гарантированно в десятки тысяч раз хуже того, что по итогу придумали в 1С.
Если же случится невероятное и вы родите таки, что-то похожее, это будет означать, что вы самостоятельно повторили ту самую математику, которая лежит в основе. А отсюда вытекает, что вы могли сэкономить кучу времени и сил, если бы этой математикой владели.
Об варианта идут в разрез с вашим подходом. А вы своим примером (глубоким непониманием обсуждаемых проблем) доказываете мою правоту. Кстати, наличие математической базы - не противопоставлено программистским навыком. Нужно и то и другое.
Даже если вы возьмете специальные языки для построения математических моделей это будет синтаксический сахар поверх многомерных массивов.
Не несите, пожалуйста, чушь. Нет разницы, как оно представлено на самом низком уровне. В конце концов, процессор даже умножать не умеет, там сумматор только есть.
Чтобы родить решение, в котором ничего не останется от математики, математику все равно нужно знать. Вы же как-то от модели должны перейти к программе? Численные методы решения диффуров в частных производных, внезапно, будут содержать только 4 базовых арифметических операции. Но этот результат невозможно создать без понимания диффуров. Вы сперва исходя из модели составляете эти самые диффуры. А уж как они потом будут переложены в код - дело десятое.
А, да, я в свое время работал с графикой. Нужно было сделать чтобы камера плавала по помещению и куда-нибудь заруливала. Это было в 2006-2007годах. Юнити как раз только-только появился, но у нас был свой движок.
В итоге, езду камеры сделали по сплайнам. Сплайны рисовали в 3ds Max. А на перекрестках - делал интерполяцию - строил кривые Безье. И у меня в коде были такие вещи как векторное произведение, скалярное произведение, линейная интерполяция. Матричное умножение и некоторые другие вещи.
С вашей колокольни - нет никакой математики, векторное произведение - это 3 умножения и 3 сложения. Скалярное произведение - тоже.
Вот только, не зная линейки, вы эти умножения со сложениями в правильной комбинации не подберете никогда.
Но если в контексте то именно предметное образование как к примеру экономическое/ бухгалтерское будет намного полезнее для 1С.
Здесь нет противопоставления. Только экономическое/бухгалтерское образование не приведет вас к прорыву. Математика плюсом к другим компонентам - приведет.
И в приведенном примере себестоимости, задача решилась бы точно так же и без подобной математически красивой иллюстрации. Бухгалтер + опытный программист.
Совершенно нет. СЛАУ - это не иллюстрация. Это ровно то, что решается в коде. И бухгалтер это не поставит. И я понимаю вашу убежденность. Вы не осилили в математику и рассуждаете со своей колокольни.
Если бы перед вами стояла задача поставить себестоимость, вы наверняка смогли бы придумать партионный учет или какие еще способы посчитать себестоимость, но гарантированно никогда в жизни не дошли бы до РАУЗ.
Жалко что я не математик, потому что мне явно не хватает удовлетворения от понимания того что я строю именно граф:)
Так вы его и не строите. Подход с графом просто не доступен для вас.
И формирование системы уравнений - это реально круто.
Конечно, круто. Способность построить и решить СЛАУ - качественно меняет подход к себестоимости. Но для вас это недоступно, ибо нет необходимых знаний.
Математика не создает, математика - описывает.
Ваше мнение очень ценно, к сожалению, вы не в теме и не понимаете о чем говорите. Математика - безусловно язык. Но без этого языка невозможно делать некоторые вещи. Не только РАУЗ.
Например, благодаря довольно крутой математике, существует весь e-commerce. То, что уже реализовано в виде криптоалгоритмов - не может быть создано без математики. RSA, DSA, ГОСТ - это все последствия исследования односторонних функций, теор. вера, теории групп и т.д. Да, в коде не будет работы с конечными группами (и то не факт), но без понимания этой математики, невозможно создать этот алгоритм. Использовать - можно. Разрабатывать - нельзя. Т.е. вы - гарантированно не будете автором более крутого криптоалгоритма.
Любой достаточно сложный процесс созданный просто прикладниками можно описать в формулах как триумф математики.
Но не любой достаточно сложный (или не очень) процесс прикладники смогут РЕАЛИЗОВАТЬ. Математика - универсальна. Вы можете искать ее на крыльях бабочки (к чему вы и свели всю дискуссию, я - явно о другом применении математики), а можете использовать для решения задач. Вам этот кейс не доступен.
В то время как это всегда элементарная работа с коллекциями в памяти и выборками из базы данных, при понимании прикладной области. Тупо в силу примитивности инструментов.
Это совершенно не так. Дай вам любую постановку задачи, где худо-бедно пахнет математикой, вы ее гарантированно завалите. Или не реализуете вовсе, или реализуете сильно хуже. Гарантированно. Беда в том, что я знаю о чем говорю, вы - нет. С очевидностью.
Например, вы так и не смогли въехать, что именно сделала 1с со своим РАУЗ. Но, это не мешает вам не верить, что РАУЗ в 10000 (и больше) раз быстрее партионного учета.
Например, для вас задачки компьютерной графики связаны с пространственным воображением, а не с пониманием вычислительной геометрии (мне смешно). Примитивная задача на построение выпуклой оболочки. Вы сделаете алгоритм (если сделаете), который гарантированно будет кратно хуже оптимального - алгоритма плоского заметания.
И да, там на выходе, в программе, будут несколько циклов и работа с коллекциями... Но как это отменяет математику, которая приводит к решению?
Ладно, хрен с ним, вы можете нагуглить алгоритм и реализовать его, не понимая, как он работет. Это хреновый вариант - но вариант. Но что делать, если задачка чуток отличается от классики? Нормальный программист (который осилил математику) способен допилить алгоритм до нужного состояния. Или способен понять, что этого сделать нельзя, например, потому что в новой постановке задача окажется NP-трудной. Вы же даже слов таких не знаете, поэтому этот класс проблем для вам просто закрыт. Кстати, куча кандидатских диссертаций появляется в результате такого допила классического модельного алгоритма до реальной задачи, а не от того, что кто-то решил просто абстрактно науку потолкать или в стол что-нибудь сделать.
Сначала написали используя просто здравый смысл, потом задокументировали реализацию.
Фейспалм. Но я уже повторяюсь.
В принципе, этот аргумент - квинтэссенция вашего взгляда на программирование.
Именно так. Беда в том, что мое понимание приправлено знанием, ваше - гаданием на гуще.
Скорость - это физическая величина.
Нет. Скорость - это математическая величина. Давайте с википедии:
Вычисли́тельная сло́жность — понятие в информатике и теории алгоритмов, обозначающее функцию зависимости объёма работы, которая выполняется некоторым алгоритмом, от размера входных данных. Раздел, изучающий вычислительную сложность, называется теорией сложности вычислений. Объём работы обычно измеряется абстрактными понятиями времени и пространства, называемыми вычислительными ресурсами. Время определяется количеством элементарных шагов, необходимых для решения задачи, тогда как пространство определяется объёмом памяти или места на носителе данных. Таким образом, в этой области предпринимается попытка ответить на центральный вопрос разработки алгоритмов: «как изменится время исполнения и объём занятой памяти в зависимости от размера входа?». Здесь под размером входа понимается длина описания данных задачи в битах (например, в задаче коммивояжёра длина входа почти пропорциональна количеству городов и дорог между ними), а под размером выхода — длина описания решения задачи (наилучшего маршрута в задаче коммивояжёра).
Я скоростью это все называю весьма условно. Речь про сложность алгоритма в приведенном смысле выше.
Этот раздел математики прошел мимо вас, поэтому спорить с вами бессмысленно.
Но попробую объяснить: одна и таже программа будет по разному выполняться в зависимости от железа. Как абстрагироваться от железа и сравнивать производительность алгоритмов?
Был придуман грубый, но эффективный прием, который применяется повсеместно - асимптотическая оценка сложности.
Так вот, вокруг этого понятия и крутится вся теория сложности.
Давайте на классическом примере?
Сортировка массива?
Сейчас вы избалованы фреймворками. В Джаве вам достаточно написать collection.sort(comparator). И все. Успех.
Как это реализовано под капотом? И можно ли реализовать лучше? В фреймворках с этим все ок.
Самостоятельно же вы родите что-то вроде
for (i = 0; i < arr.length; ++i) {
for (j= i+1; j < arr.length; ++j) {
int temp = arr[i];
arr[i] = arr[j];
arr[]j] = temp;
}
}
Т.е. пузырек. Красивый лаконичный и совершенно ужасный код.
Сколько времени займет сортировка 1000000000 записей? Правильно - лярд в квадрате пополам итераций. Ибо сложность алгоритма O(n^2).
Сколько времени займет быстрая сортировка (пирамидальная, например), правильно - O(n log n), т.е. примерно 30 лярдов итераций. Кажется, не нужно быть математиком, чтобы понимать, что второе решение - в миллионы раз быстрее на указанных объемах.
Понимание теории сложности, позволяет прикидывать насколько хороший код вы пишете. Но это пролетает мимо вас, поскольку математика не создает, математика - описывает. )
Создание оптимального кода ничего общего с математикой не имеет. Математика - это абстрактный уровень описания, но не реализации.
Вы с очевидностью не понимаете чего говорите. Выше - наглядный пример. Вы пишете два вложенных цикла. Кода мало? Красиво? Читаемо? Дальше вы не будете задумываться, поскольку убеждены в своей правоте.
Математики же родили под сотню алгоритмов сортировки. Из универсальных самый крутой - пирамидальная сортировка. Которая быстрая в худшем случае. Можно ли быстрее, чем O(n *log n)? Нельзя. Математически доказано
Ваш комментарий относился к задаче построения выпуклой оболочки (например, визуализация нефтеносных слоев). Во первых, далеко не факт, что вы сможете родить решение. Так-то нужно еще проверить, что у вас получилась выпуклая оболочка. Я знаю критерий из курса аналитической геометрии - вы нет. Но, допустим. Вы что-то наговнокодили и получили результат. Чудом - правильный (скорее всего - нет и вам придется гуглить тот самый критерий, а потом опять обсирать математиков за то, что они мучают студенстов). Дальше вы будете изобретать алгоритм.
На физических основах, а как же иначе? И родите, что-нибудь более-менее простое, сложностью не ниже O(n^3). А то и O(n^4).
А я, поскольку, вычислительная геометрия (математика, ага) не прошла мимо меня, реализую алгоритм плоского заметания, у которого сложность - O(n log n) на плоскости, а в пространстве - O(n^2), что в тысячи и миллионы раз лучше, чем у вас.
Ну и чтобы насладиться "физикой" - вот вам статья на хабре с разбором задачи:
https://habr.com/ru/post/529352/
Давайте, делайте одним лишь пространственным воображением, без математической базы.
Вы что-то наговнокодили и получили результат. Чудом - правильный
...
А я, поскольку, вычислительная геометрия (математика, ага) не прошла мимо меня, реализую алгоритм плоского заметания
Вы знаете, я всегда любил математику, и сейчас очень спокойно к ней отношусь. Надо будет - разберусь. 1-2 недели, поверьте. Сомневаюсь, что в следующие 20 лет программирования потребуется, но ничего не имею против.
Хотелось бы отметить три момента.
Первый - это сомнительная привлекательность для команды, и бизнеса в целом, программистов с фундаментальной математической базой. Если только этого не требует домен, тот же блокчейн.
Причина - вы реально странные. Софт скиллз сейчас важнее, чем умение плоско заметать.
Второй - редко требуется та экспертиза о которой вы говорите, и если требуется, то в третью очередь. За внутреннюю красоту - не платят, за оптимизацию - платят отдельно.
Причина - рынку не интересны алгоритмы и формулы, интересно решение бизнес-проблем, где скорость чаще не в приоритете. Для ночного пересчета не важно 30 минут или 3 часа. Многие проблемы производительности проще решить запуском на отдельном сервере и прочими чисто организационными способами. Представители бизнеса проповедуют теорию простоты.
Третий - вы интересны миру своим проектным опытом. И больше ровно ничем. Внутренняя кухня и чем вы перемешиваете свои мысли, как выравниваете макароны в кипящей кастрюле - мир оценить не в состоянии. Когда вы говорите могу это и могу то, потому что фундаментальная математическая база - рынок этого не слышит.
Причина - хороший код, хороший программист, хорошо подходящий, и прочее - с фундаментальной математической базой ничего общего не имеет. И это не моя оценка. Это reality check.
Вы знаете, я всегда любил математику, и сейчас очень спокойно к ней отношусь.
О, да ))) Вся дискуссия с вами именно о вашем ровном отношении к математике и как вы ее всегда любили (ну там, знания математики нужны, чтобы гнобить студентов и т.д.). Впрочем, это - ваша печаль.
Надо будет - разберусь. 1-2 недели, поверьте.
Не поверю. Из следующих соображений:
1) У вас не возникнет необходимости. Если вы не знаете, что математика может помочь, то она вам и не поможет. Вы или сделаете хреновое решение и будете гордиться собой, или "это должен проаналитить аналитик". А готовые формулы вы спокойно вобьете в код.
2) Всему свое время. Время фундаментального образования - студенческая пора. Вы или взяли образование, или не взяли его. Я могу представить себе, как взрослый умудренный опытом дяденька будет изучать джаву, котлин, паттерны и что угодно еще. Но никак представить себе не могу, чтобы бородатый дяденька сел пределы последовательностей изучать. Вспомнить - да. Освоить - нет. Ну просто психология.
3) Математика - штука неоднородная. Какой раздел ни возьми, там такая взаимосвязь, что закачаешься. Одно тянет за собой другое и т.д. Короче, за 1-2 недели точно не разберетесь.
Сомневаюсь, что в следующие 20 лет программирования потребуется, но ничего не имею против.
А это - ключевое. Если не видеть, что есть математика, то вы ее и не увидите. В моем примере, вы - просто не будете автором алгоритма РАУЗ. И все.
И, кстати, мне непонятно, почему вы противопоставляете чисто программистские навыки (ну там, джава, СУБД, архитектура железа и т.д.) и фундаментальное образование. Почему вы решили, что одно - обязательно исключает другое?
Нормальный программист как раз взял все: и математику и программистские скиллы.
Первый - это сомнительная привлекательность для команды, и бизнеса в целом, программистов с фундаментальной математической базой.
Практика противоречит вашей фантазии:
1) Я уже приводил несколько примеров, где реально навыки математики выруливали очень круто.
2) Некоторые навыки математики, а именно - теория сложности, дискретка и алгоритмы, нужны всем без исключения программистам. Оценка сложности алгоритма - это что-то из подкорки. Подобрать мат. модель к бизнес-постановке - тоже.
3) Часто на собесах гоняют по алгоритмам и теории сложности. Провалы в памяти автоматически понижают ранг с сеньора до мидла.
Причина - вы реально странные. Софт скиллз сейчас важнее, чем умение плоско заметать.
Кто сказал такую глупость? Софт скиллы нужны, но явно идут сильно после хард скиллов.
Второй - редко требуется та экспертиза о которой вы говорите
Я изначально говорил, что нужны и кодеры и программисты. Но, подчеркиваю, из того, что таких задач мало, не значит, что их нет. Это один момент. Второй - понимание теории сложности нужно вообще везде и вообще всегда. Это просто один из навыков, которые применяются на автомате. И помогают фильтровать хороший код от говнокода. У вас такового нет - не вижу повода для гордости.
За внутреннюю красоту - не платят, за оптимизацию - платят отдельно.
Математика - это не внутренняя красота. И про оптимизацию - тоже пассаж за гранью фантастики. Мне трудно представить себе вашу предметную область, что вы в таком непробиваемом танке находитесь. Извините, во всех проектах без исключения, где я работал, прописывались требования к производительности в разделе нефункциональных требований. И нагрузочные тестировщики старательно проверяли, укладываемся или нет. И, кстати, провал нагрузочного тестирования - аргумент к невыпуску проекта в пром.
Причина - рынку не интересны алгоритмы и формулы,
Верно. А вот скорость вывода новых фич, сложность поддержки, скорость исправления багов, количество багов и производительность решения - интересны.
А это вот все, опирается в том числе и на красивые формулы и алгоритмы. Пример про неделю и 10 минут - он вполне себе реальный. На самом деле, с выходом редакции 11.1 программы "Управление торговлей" от 1С, был исключен процесс восстановления партионного учета. Собственно и сам партионный учет был убит. Зато конторы получили возможность оперативно пользоваться корректным расчетом себестоимости.
А когда в высоконагруженной системе не укладываешься в мерики, алгоритмы чекают в первую очередь. Если у вас не обоснованная линейная сложность, там где достаточно логарифмической, а то и константной - это сразу же даст бешенный прирост производительности. И может быть отпадет необходимость ковыряться с профайлером.
Для ночного пересчета не важно 30 минут или 3 часа
А для рантайма? Да и ночью фоновых задач может быть столько, что разница между 0.5ч и 3 - катастрофическая.
Многие проблемы производительности проще решить запуском на отдельном сервере и прочими чисто организационными способами. Представители бизнеса проповедуют теорию простоты.
Вы прям каноничный пример асимптотическому анализу сложности ))) Мне не сложно представить, как программист-диссидент, наговнокодивший на O(n^2) вместо O(1) полетит из конторы как фанера над Парижем. Просто потому, что бизнес всегда найдет применение отдельному серверу. А алгоритм оптимизировать - это зачастую просто скилл разработчика, который не стесняется в математику.
Третий - вы интересны миру своим проектным опытом. И больше ровно ничем.
На минуточку: на одной чаше весов - неделя подготовки к получению отчетности, на другой - 10 минут.
На минуточку: вся нефтянка. Непрерывные производства описываются системами диффуров. Соответственно АСУ ТП - это солверы систем диффуров. Как вы говорите, это "специфический домен"? Ровно так. Специфический домен, который на 50% покрывает бюджет страны. Я это про вклад в ВВП. И про узость отрасли.
На минуточку, все игроделы. Вы на хрен не нужны в геймдеве со своим утонченным нейтральным взглядом на математику. Или вы шарите в ней, или не работаете в геймдеве.
Что в сухом остатке? В любой отрасли можно нарваться на математику, которая не для внутренней красоты, а для дела.
Но, я не однократно говорил, нужны и кодеры, и программисты.
Когда вы говорите могу это и могу то, потому что фундаментальная математическая база - рынок этого не слышит.
Зато рынок слышит результат, полученный фундаментальной математической базой. Алгоритм РАУЗ ознаменовал переход от редакции 11.0 на редакцию 11.1 И в ближайшее время, вышла новая версия платформы 1С 8.3.14, в которую был включен солвер СЛАУ. По этому поводу, бизнес затеял десятки конференций, на которых с пеной у рта показывались преимущества нового подхода. А франчи быстренько учились находить дыры в алгоритме и предлагать доработки под частные нужды.
Когда визуализация данных - бизнес-фича, бизнесу по фиг, что там крутая математика и внутренняя красота, главное, чтоб фича работала как надо.
Причина - хороший код, хороший программист, хорошо подходящий, и прочее - с фундаментальной математической базой ничего общего не имеет.
Имеет. Я (и не только) вам неоднократно показал. Хороший код O(n^2) на высоконагруженной системе - это говнокод. А код O(1) - это хороший код.
Кроме того, математическая база и программистские скиллы не противопоставлены. Нормальный программист успешно осваивает и то, и другое.
И это не моя оценка. Это reality check.
Это не ваша оценка, это - ваша фантазия.
А мир - он большой. В нем разное можно видеть. Вы можете не замечать математики, но это не значит, что ее нет. Это значит, что ваш кругозор недостаточно широк.
Давайте подытожим по триумфальному РАУЗ.
1C очень одаренно спроектировал хранение проводок и потому требовался процесс восстановления записей чтобы залатать дыры.
Специалисты 1С решили эту проблему дизайна решением линейных уравнений чтобы эти дырки посчитать математически.
При этом алгоритм не совершенен и партнеры 1С зарабатывают на его доводке.
Корректный итог?
-
Давайте подытожим по вашему широкому кругозору.
Вы - настоящий программист, с фундаментальной математической базой. Имеете обширный опыт на проектах связанных с графикой, с джавой. Имеете научный опыт и опыт преподавания в вузе. Сейчас работаете или подрабатываете с 1С в качестве программиста.
Считаете важным писать оптимизированный код который соответствует метрикам указанным в технической спецификации. Или, по крайней мере, имеете только такой опыт проектов где это критично.
Умеете подобрать мат. модель к бизнес-постановке. Можете решить любую задачу. Считаете математику фундаментом успешной карьеры и залогом профессионализма.
Корректно?
Давайте подытожим по триумфальному РАУЗ.
Ай как замечательно :) На лицо - галоп Гиша.
Давайте напомню вам эволюцию ваших взглядов:
1) Математика - не нужна. Нужно программистские скиллы качать. Математика нужна только в узких специфических доменах (правда непонятно, как все же необходимость математики в узких и редких доменах бьется с дальнейшими утверждениями, но, ладно).
2) Математика не создает, математика - описывает. Соответственно, математика не нужна, потому что по фиг как оно описывается, главное, чтоб работало. (как это пересекается с узкими доменами, вроде блокчейна - не понятно. По идее - пусть математики описывают, а программисты как-нибудь пилят блок-чейн при помощи листов, мапов и какой-то матери).
3) 1С - идиоты, еслиб грамотно спроектировали сразу (не иначе как отточенными на западе скиллами проектироваия ЕРП), не пришлось бы потом триумфально исправлять свои же косяки при помощи математики.
Ничего не пропустил? :)
1C очень одаренно спроектировал хранение проводок и потому требовался процесс восстановления записей чтобы залатать дыры.
Дело вовсе не в 1С. Это, как вы говорите, бест практис разработки ЕРП. У САПа тоже самое. Да и вообще, у кого угодно тоже самое. Порядок ввода документов в систему критически важен в учете. Это - особенность учетных систем в принципе. Просто по определению. В требованиях любого учета есть обязательный пункт про хронологичность, непрерывность и полноту.
1С первая поставила вопрос, а можно ли отвязаться от восстановления последовательностей, дабы иметь возможность анализировать себестоимость ежедневно, а не раз в квартал, как в нормальных ЕРП системах.
Так что нет, 1С - нормально спроектировал хранение проводок и подсчет агрегатов. Отчет по агрегатам строится секунды даже для больших наборов данных.
Специалисты 1С решили эту проблему дизайна решением линейных уравнений чтобы эти дырки посчитать математически.
Специалисты 1С смогли найти способ (слава математике) качественно улучшить нормально спроектированный процесс. Хронологичность - базовое требование к учету. Так что имели право забить. Но решили сделать хорошо клиентам.
При этом алгоритм не совершенен и партнеры 1С зарабатывают на его доводке.
Алгоритм покрывает типовые ситуации. Партнеры 1С ищут пробелы (они всегда так делают, дело не только в РАУЗ) и нестандартные ситуации и автоматизируют их (например, к типовым аналитикам добавляют другие, частные, разрезы). Речь не про "несовершенство" алгоритма, а про его приложение к нестандартным задачам.
Корректный итог?
Нет, как видите. Корректным будет такой итог: математика - часть образования программиста. Есть разделы, которые программист применяет в повседневной рутинной практике (теория сложности), есть применения, которые всплывают нечасто, но, иногда, во внезапных областях. Например, в ERP встретить математику - неожиданно (РАУЗ).
Задачи есть разные, потребности - разные. Можно работать и всю жизнь не пересекаться с математикой (теория сложности все равно должна быть на подкорке), а можно и столкнуться. Человек, вошедший в АйТи - тоже программист, но нужно понимать его ограничения.
Давайте подытожим по вашему широкому кругозору
А у нас где-то ставился вопрос моего кругозора? Кажется, мы дискутировали про важность фундаментального образования, а не про мои профессиональные успехи.
Считаете математику фундаментом успешной карьеры и залогом профессионализма.
Математика - часть профессионального образования программиста.
1) Математика - не нужна. Нужно программистские скиллы качать.
2) Математика не создает, математика - описывает. Соответственно, математика не нужна, потому что по фиг как оно описывается, главное, чтоб работало.
3) 1С - идиоты, если б грамотно спроектировали сразу (не иначе как отточенными на западе скиллами проектирования ЕРП), не пришлось бы потом триумфально исправлять свои же косяки при помощи математики.
Ничего не пропустил? :)
Именно так. Спасибо.
Разве что 1С спроектировали математики. Ни автомобиль, ни самолет, ни ERP абстракционисты создать не способны. Потому что не могут удержаться от того чтобы соединить голову и ягодицы по признакам общности. Им так красиво.
Математика - часть профессионального образования программиста.
Человек, вошедший в АйТи - тоже программист, но нужно понимать его ограничения.
Ограничения накладывают знания математики. Потому что, если слишком долго в нее смотреть - она будет смотреть из тебя. Там где у программиста из глаз не смотрит эта бездна, он решает ту же задачу через использование базы данных.
Сложность вычислений - это кодер на уровне метода. Программист же решает задачи на уровне архитектуры конкретной системы в целом. Вообще не вопрос как написать код, вопрос в том, где и зачем.
Безусловно, математика - это мощь. Потенциал. Действительно можно получать 10 - 15 тысяч USD в месяц просто разрабатывая модели, даже находясь в России.
Но явно не в 1С, и не в ERP, и не в CRM и не в прочих классических User Cases/ DB продуктах.
Это не вопрос багажа, это вопрос пути. В вашем вещмешке конечно есть что-то, чем вы гордитесь и цените. Но критерий полезности и нужности - это то, где вы сейчас на своем пути с этим багажом.
И чему вы будете учить своих детей если вы захотите чтобы они стали успешными программистами.
Ни автомобиль, ни самолет, ни ERP абстракционисты создать не способны.
А можно подробнее про автомобиль и самолет? :) А, по вашему, конструкторы, проектирующие самолеты не владеют математикой? Или программисты, создающие САПР для конструкторов самолетов не знают математику?
Ну, простите, без комментариев. Один вопрос: где такая трава забористая растет?
Потому что не могут удержаться от того чтобы соединить голову и ягодицы по признакам общности. Им так красиво.
Мне решительно непонятно, зачем прорывается детский сад и вы начинаете нести поток сознания? Вы о чем вообще? Кому красиво? Какие головы и ягодицы? Можете наглядный пример привести?
Там где у программиста из глаз не смотрит эта бездна, он решает ту же задачу через использование базы данных.
Вы уже начали повторяться. Вся пластинка заново. И ладно бы еще понимали о чем говорите, но нет - просто несете чушь своих убеждений.
Сложность вычислений - это кодер на уровне метода. Программист же решает задачи на уровне архитектуры конкретной системы в целом
Вы снова несете чушь. Прекращайте. Сложность - она и на уровне архитектуры и на уровне метода. Алгоритм - это часть архитектуры.
Но явно не в 1С, и не в ERP, и не в CRM и не в прочих классических User Cases/ DB продуктах.
В них, внезапно, тоже. Пример с РАУЗ - один из многих. Вы не работали с транспортными компаниями? У них весьма популярна задача маршрутизации в разных постановках. На эту тему пишут сотни диссертаций. А казалось бы. Да, можно и не нарваться. Но такие задачи тоже есть.
Это не вопрос багажа, это вопрос пути.
Это уже ближе к делу. Я об этом сразу же сказал: нужны и те и другие. Но если вы не владеете математикой - хотя бы понимайте, что конкретно проходит мимо вас. Математика же гораздо шире, чем представлено в дискуссии. Я,например, не знаю, где и как применять теорию категорий, фракталы, теорию хаоса и функан. Хотя, раз разделы появилсь, значит они зачем-то нужны.
Но критерий полезности и нужности - это то, где вы сейчас на своем пути с этим багажом.
Ну так я и оцениваю теорию сложности - как must have для программиста.
И чему вы будете учить своих детей если вы захотите чтобы они стали успешными программистами.
Обратите внимание: детей я буду учить ДРУГИМ языкам программирования и фреймворкам. Они устареют. А математике я буду учить той же самой. Она не устареет никогда.
И еще раз: нет противопоставления математика ИЛИ языки/фреймворки. И то И другое.
Путь программиста - учиться всю жизнь
А можно подробнее про автомобиль и самолет?
Создают инженеры. Реализуют технологи. Обслуживают механики. Которые имеют профильное образование.
Какие головы и ягодицы? Можете наглядный пример привести?
Сущность Документ в 1С это как Часть тела. Отношение к архаике ООП. Но это ненужный флейм. Прошу прощения.
Сложность вычислений
В данном словосочетании вы видите математику в слове "сложность". А я вижу в слове - "вычислений".
В советской системе образования математику подняли несколько выше чем принято в остальном мире. Область вычислений в других науках, где это инструмент, преподнесли как самостоятельную фундаментальную науку на фоне деградации всех остальных.
Результат виден на способности создать свой собственный автомобиль, смартфон, операционную систему и прочее. При наличии действительно выдающейся математической школы и гениальных математиков.
Обратите внимание на разницу в вики по термину математика на русском и английском языках
https://ru.wikipedia.org/wiki/Математика
https://en.wikipedia.org/wiki/Mathematics
Для программистов профильное образование это Computer Science. И детям надо давать то же образование что получил Линукс Торвальд. Себя не привожу в качестве примера, это нескромно.
если вы не владеете математикой - хотя бы понимайте, что конкретно проходит мимо вас. Математика же гораздо шире, чем представлено в дискуссии.
По дискуссии. Скажите будет ли юрист или востоковед или журналист, с тем же IQ как у вас, после обучения программированию в 1C, работать хуже и цениться меньше чем вы?
Создают инженеры. Реализуют технологи. Обслуживают механики. Которые имеют профильное образование.
Инженерам не нужна математика, чтобы спроектировать автомобиль/самолет? САПР, в котором считается нагрузка на крыло, например, не содержит в себе модуль профильной математики?
Сущность Документ в 1С это как Часть тела.
Вопрос сильно спорный, что там не туда натянули. Я слышал претензии к 1С (поддерживаю их), что там не довели до ума ООП. Претензий, что выделили сущность Документ - не видел. Это дает свой профит. Низкий порог входа. Быстрый старт. Я складской учет, которым можно пользоваться, напишу за день. Вместе с отчетностью. Сколько вам потребуется времени реализовать аналогичный функционал на том же САП? Или, не дай Бог, на голой джаве? Любое решение - палка о двух концах.
В данном словосочетании вы видите математику в слове "сложность". А я вижу в слове - "вычислений".
Это - демагогия. Суть не меняется - теория сложностей. Если вы ее не хотите знать/использовать - вы ССЗБ.
Область вычислений в других науках, где это инструмент, преподнесли как самостоятельную фундаментальную науку на фоне деградации всех остальных.
В политику я с вами не готов. Да и сути не меняет. Математика - инструмент. В приложении к программистам - этого достаточно.И это точно описывает роль математики в программировании. Это точно такой же инструмент, как и джава и субд и т.д. Вы же пытаетесь этот инструмент выкинуть из своей практики. ССЗБ.
Результат виден на способности создать свой собственный автомобиль, смартфон, операционную систему и прочее. При наличии действительно выдающейся математической школы и гениальных математиков.
Вы смешали в кучу инженерию и науку. Не надо так. Инженерия у нас страдает. При чем тут наука? Пусть гениальнейшая школа физики не у нас, а в США. И что? Инженеры не могут получить научный журнал и почитать статью? Аналогично про физику. Разве наши коллективы не принимают участие в том же БАК или ИТЭР? Принимают и вполне себе заметную роль.
Про политику спорить не готов. Математика - часть инженерного образования. Как конструкторам нужна, так и программистам.
Но как вы заметили - вектор может быть разный. Вы вполне себе можете всю жизнь писать hello, world! И вам работы хватит. Но это - ваш выбор.
Обратите внимание на разницу в вики по термину математика на русском и английском языках
Ткните уже пальцем. Весомой разницы не увидел.
Для программистов профильное образование это Computer Science
Ну а в computer science соответственно входят некоторые разделы математики:
https://en.wikipedia.org/wiki/Computer_science
Computer science spans theoretical disciplines (such as algorithms, theory of computation, information theory and automation)
Скажите будет ли юрист или востоковед или журналист, с тем же IQ как у вас, после обучения программированию в 1C, работать хуже и цениться меньше чем вы?
Будет. Более того, сравнить можно практикой. Востоковеды и журналисты в 1С могут, но пишут жутчайший говнокод, который кратно глючнее, тормознее и непонятнее того, что выдаю я. И математика тут вполне себе при чем. И не только математика.
Человек со стажем в 1С около 15 лет продолжает программировать так, будто у него платформа 7.7. Он не способен втыкнуть про новую модель разработки. Даже в терминах документации 1С. И дело не в том, что он тупой. Он - не тупой. Он прекрасно шарит в бухучете. Он круто разбирается в бухгалтерских кейсах, но вот беда: переложить на язык программирования свои идеи у него получается через жопу.
Ткните уже пальцем. Весомой разницы не увидел.
Она не то что весома - она принципиальна разная начиная с перевода истока. На русском языке это самостоятельная наука, в то время как на английском это инструмент других наук.
Матема́тика (др.-греч. μᾰθημᾰτικά[1] < μάθημα «изучение; наука») - точная (формальная) наука.... В более современном понимании, это наука об отношениях между объектами.
vs
Mathematics (from Ancient Greek μάθημα; máthēma: 'knowledge, study, learning') is an area of knowledge.... Mathematics is essential in the sciences, engineering, medicine, finance, computer science and the social sciences.
Математика - инструмент. В приложении к программистам - этого достаточно. И это точно описывает роль математики в программировании. Это точно такой же инструмент, как и джава и субд и т.д. Вы же пытаетесь этот инструмент выкинуть из своей практики. ССЗБ.
Инструмент на то и инструмент, чтобы применять его когда он наиболее подходит для задачи. Мы не слагаем стихи об инструменте и не пытаемся всем доказать что виртуозное владение напильником делает нас мастером дела. Мы даже можем не замечать, что поработали напильником, просто потому что это происходит с опытом машинально.
Мастера делает философия. То, что количественно не измерить. KISS, YAGNI и прочее.
Востоковеды и журналисты в 1С могут, но пишут жутчайший говнокод, который кратно глючнее, тормознее и непонятнее того, что выдаю я. И математика тут вполне себе при чем.
Они продолжают работать и получают такую же зарплату?
Бывает и такое, что новичок, оценивая код более опытных коллег, видит далеко не нормализованный код, но просто не понимает почему именно так.
Бывает и такое, что надо быстро, плохо, много - это тоже моменты профессии.
Просто хотел отметить, что такие специалисты могут быть не менее успешны в программировании, чем чистый математик. Это больше не про базу, а про характер.
Она не то что весома - она принципиальна разная начиная с перевода истока. На русском языке это самостоятельная наука, в то время как на английском это инструмент других наук.
Да ну не фантазируйте. Те же яйца - вид сбоку. Видимо вы в английском предпочли не замечать "an area of knowledge", что таки трактуется, как наука. И разница тут философская - по критерию Поппера считать математику наукой или нет. Например, философия - не наука. Но около нее. И определенная ценность в ней есть.
Инструмент на то и инструмент, чтобы применять его когда он наиболее подходит для задачи.
Именно. Так все просто: вы - не владеете инструментом и призываете других не владеть им. Недальновидный подход. То, что вы ошибаетесь - я вам привел примеры.
Мы не слагаем стихи об инструменте и не пытаемся всем доказать что виртуозное владение напильником делает нас мастером дела.
Очень даже слагаем. Еще сам Ленин завещал: "Учиться, учиться и еще раз учиться".
Весь спор-то он про то, нужна программисту математика или нет. Нужна. Аргументы были. Владение инструментом дает преимущества перед теми, кто не владеет инструментом.
Мастера делает философия. То, что количественно не измерить. KISS, YAGNI и прочее.
Мастера делает много что. Философия без базовых навыков - мало стоит. Математика - часть computer science.
Они продолжают работать и получают такую же зарплату?
Да. Продолжают работать и получают определенные деньги.
Проблемы начинаются не в момент сдачи заказчику говнокода. Уж профессионал-то должен понимать )
Говнокод приводит к тому, что эти доработки становится тяжело сопровождать. Итог? Заказчик начинает платить больше и больше. Рано или поздно говнокодер заваливает задачу, потому что больше не способен вариться в своем говнокоде. Это проявляется бесконечными глюками, сбоями, зависаниями и тому подобными спецэффектами, которые сильно не нравятся заказчику.
Дальше закономерно говнокодер исчезает в закат (или его выпиныват в закат), а приходит следующий. Если приходит опять говнокодер, то он представляет свое особое видение ситуации и всю предшествующую работу объявляет говнокодом и убедительно доказывает, что дальше так нельзя. И история повторяется.
Если приходит не говнокодер, то он точно так же показывает, что там был жуткий говнокод, но дальше предлагает какой-либо выход из ситуации. И дальше заказчик на собственном опыте начинает видеть разницу между говнокодом и хорошим кодом.
Математика тут при чем и computer science тут тоже при чем.
Бывает и такое, что надо быстро, плохо, много - это тоже моменты профессии.
Бывает, бывает. А потом бывают последствия за быстро-много-плохо. Нормальный программист знает и про управление инцидентами и про управление проблемами.
Просто хотел отметить, что такие специалисты могут быть не менее успешны в программировании, чем чистый математик. Это больше не про базу, а про характер.
Так я ровно об этом изначально писал. Работы хватит для всех. Каждый сам себе устанавливает потолок. Не можете в математику? Прекрасно, занимайтесь чем можете, вместо вас эту задачу решат те, кто могут в математику. Только обижаться не надо, что в яндексе доценты от науки откинулись и кошмарят сеньорных программистов, без фундаментальных знаний.
Вы сделаете это за день. Сколько вам за это заплатят?
Какая разница? Мы сейчас о чем вообще? Я не про деньги, я про инструмент для решения задачи. И если передо мной ставится вопрос создания складской системы, я без вариантов буду в качестве основы предлагать 1С. Так и быстрее и дешевле.
Сколько заплатят тому кто сделает то же самое за месяцы на том же САП и голой джаве?
Как вариант - нисколько. Потому что свое решение нужно еще ОБОСНОВАТЬ. И если для заказчика нет профитов от голой джавы, по сравнению с 1С, то джавист - пролетит. Только речь тут о другом. Джависты востребованы и рулят по зп. Только у них сегмент несколько другой.
Кстати, разводить заказчика, как лоха, на деньги - ну такое себе.
Но да, я такое видел. Видел также, как спустя время, такие деятели вылетали с рынка.
Знаковый для профессиональных программистов с профильным образованием.
Понимаю ваши предрассудки. Дилетантское мнение - оно такое.
Чем не угодила? Писать на русском - это же бреееед? :)
как и любая унификация, может просто отторгаться мозгом не-математика как извращение
При чем тут математика? Вообще не понятно. Вся эта унификация просто захватила рынок. Вы не представляете сколько народу сидит на этой 1С с этой отторгающей абстракцией.
Таки что вас там отторгает-то? Ну реально? Возможность написать полноценную учетку за день? Сомнительный недостаток. Производительность? Изначально 1С лезла в малый бизнес, где и является стандартом. Сейчас лезет в крупный - огребает проблемы и нарывается на ограничения. В какой-то степени, это решается. В какой не решается - переезжается на более другие системы.
В терминах восприятия данного человека. Он смотрит через процессы, и просто не понимает как можно (и вообще зачем) смотреть через объекты и их свойства.
Видимо, вы не очень понимаете суть учетных систем. Как раз таки объектная модель - это то, что обычно не возникает вопросов.
Вопросы у говнокодера возникают в несколько иной плоскости. В 7.7 был совсем свой язык запросов. Топорный и квадратный. В 8.Х -это уже SQL. Расширенный и русифицированный. Модель работы приближена к большим ЯП. Ну не может говнокодер в запросы. То, что можно вытащить из таблиц одним запросом - он делает кучу запросов в цикле (джойн то еще осилить надо), а потом делает итерацию по объектам (объектную модель - осилил). Итог? Тормозит, ни хрена не понятно, глючит.
Видимо вы в английском предпочли не замечать "an area of knowledge", что таки трактуется, как наука. И разница тут философская - по критерию Поппера считать математику наукой или нет. Например, философия - не наука. Но около нее. И определенная ценность в ней есть.
То что вы называете теорией сложности находится в энциклопедии философии того же Стенфорда,
Stanford Encyclopedia of Philosophy
Computational Complexity Theory
https://plato.stanford.edu/entries/computational-complexity/
Вот к примеру
The Philosophy of Computer Science
https://plato.stanford.edu/entries/computer-science/
Онтология и эпистемология вычислительных систем.
Без философии образование слепо. Более того, и системный подход, и алгоритм, и собственно системное мышление, построение систем - это именно что философия. Как вы количественно оцените ту же архитектуру MDA да и любой подход?
Ну не может говнокодер в запросы. То, что можно вытащить из таблиц одним запросом - он делает кучу запросов в цикле (джойн то еще осилить надо), а потом делает итерацию по объектам (объектную модель - осилил). Итог? Тормозит, ни хрена не понятно, глючит.
Основной ваш пример был про систему линейных уравнений, которая возникла в результате недостаточно системного проектирования базы данных в 1С, и здесь также, весь вопрос в умении пользоваться языком запросов.
C опытом, я перестал писать эффективнейший код с точки зрения скорости выполнения. Удобный, для дебага и изменений, код - намного практичней. Оптимизация производительности, если потребуется, уместна потом, когда все работает как надо, но нужно быстрее.
Правильно ли я понял ваш пример, что вы называете говнокодером программиста который работает в данной системе уже 15 лет? Он на хорошем счету, им все довольны, не так ли?
Обратите внимание, как у вас уползает скоуп дискуссии :) Ну ладно, будем считать, что по основам договорились - математика нужна программистам. Слава Богу. )
То что вы называете теорией сложности находится в энциклопедии философии того же Стенфорда,
А то, что мы называем "Кандидат физико-математиеских наук", у них называется... Доктор Философии )) И что?
1) Абсолютно плевать, как это все классифицируется. Суть - в самих знаниях. Хотите называть их философией? Ради Бога. Значит буду утверждать, что программисту нужна философия.
2) Computational complexity theory is a subfield of theoretical computer science Следовательно или вы чет поняли не так, или computer science - подраздел философии. Ну да Бог с ним! Мне по фиг куда нужно отнести конкретные знания. Мой тезис не изменится: кроме ЯП программисту еще нужны некие теоретические знания. И они дают плюс.
построение систем - это именно что философия.
Да хоть горшком назови, только в печь не ставь. (с)
Основной ваш пример был про систему линейных уравнений, которая
Основной мой пример был ровно про то, что математика может всплыть там, где ее не ожидаешь увидеть. И примеров намного больше, чем 1. В том числе и в моей практике.
которая возникла в результате недостаточно системного проектирования базы данных в 1С
Ваши голословные громкие утверждения говорят больше о вас, чем о криворукой 1с, которой потом пришлось применять математику. Раз вы такой умный - предложите, как грамотно?
здесь также, весь вопрос в умении пользоваться языком запросов.
Это не так. Разберитесь в предмете. Глупо выглядит, когда вы уверенно утверждаете о том, в чем совершенно не разбираетесь.
Как вариант - приведите развернутый пример. А я вам покажу, где в этом примере косяк.
C опытом, я перестал писать эффективнейший код с точки зрения скорости выполнения
Вот потихоньку, опытным путем, приходим к сужению области вашей деятельности. Ваша деятельность однозначно не связана с high load. Продолжайте дальше вариться в песочнице :)
Удобный, для дебага и изменений, код - намного практичней.
Что мешает дебажить неудобный код? Что такое код - неудобный для дебага и изменений?
Оптимизация производительности, если потребуется, уместна потом, когда все работает как надо, но нужно быстрее.
Верно. Но есть, недоступный для вас нюанс: оптимизации, которые всякие хитрости со знанием архитектуры процессора, особенностей виртуальной машины, особенностей среды исполнения и прочих грязных хаков, дадут вам секунды, милисекунды и наносекунды. Грамотный выбор алгоритма может дать вам тысячи и миллионы процентов. Или в сравнимых единицах - дни и недели. Быстрый поиск или линейный? Быстрая сортировка или n^2? Хэш-таблица с константным доступом или линейное сканирование? Хитрые структуры данных, вроде мин-кучи? octree vs полное сканирование? Полный перебор vs метод ветвей и границ. И т.д., что для вас недоступно, поскольку лезет математика из всех щелей.
Правильно ли я понял ваш пример, что вы называете говнокодером программиста который работает в данной системе уже 15 лет? Он на хорошем счету, им все довольны, не так ли?
Да, верно понимаете, кроме последнего пункта. Довольны не все и не всегда. Им довольны, пока он делает простые задачи. Сложные задачи он имеет склонность заваливать. Потому что установил планку для себя. Как и вы.
Говнокодер он не потому что тупой, плохой или неисполнительный. У него ровно одна проблема. Он - не программист. И не хочет расти профессионально. Точнее, у него свое утонченное видение профессионального пути. Он победил бухучет и экономику, он освоил 1с 7.7, и слегка - 8.х. Ну а дальше - он не видит необходимости в философии программирования, паттернах, и прочем, про что топите вы, ну и следом, не хочет в математику.
И выливается это ровно в том, что напилив определенных доработок, все начинает шататься и гудеть. После чего, он поднимает лапки к верху и просит привлечь более сильных специалистов, так как сам уже не справится. Что и происходит.
Основной пойнт в том, что программист с профильным образованием, или просто с серьезным проектным опытом, впадет в глубокую депрессию от такого контрафакта.
Программист с профильным образованием или просто с серьезным проектным опытом просто сделает дело. Точка. 1С - просто еще один вижуал бейсико подобный инструмент.
Язык настоящей профессии - английский.
Английский, безусловно, must have для программиста. Но по другой причине. Слишком много полезных материалов крутятся на аншлийском.
Сам по себе факт кода на русском, г
Говорит ровно о том, что продукт предназначен для российской аудитории. И ни о чем больше. Все остальное - кривость мозгов критиканов. Кстати, если вас так коробит от русского языка - нет проблем, можете программировать на английском. Но есть и практичный нюанс: программируя для русской аудитории, если ваш ЯП - русский, вам не надо переключать раскладки. А если на английском - то будете переключать постоянно. Так что - предрассудки и только. По сути - 1С тьюринг-полный ЯП.
Такое вот мое дилетантское мнение. Такие вот предрассудки.
Пример с запросом прекрасен. Мне по кайфу объектные расширения 1с. Да, я знаю, что под капотом - джойн, но мне проще написать через точку, чем 10 таблиц иметь ввиду.
у вас уползает скоуп дискуссии
Скоуп - про необходимое образование для программиста.
Собственно начали с вашей позиции, что программисту нужна фундаментальная база. Причем в виде математики как науки наук.
При этом вы демонстрируете, как кандидат физико-математических наук, всю полезность вашей фундаментальной базы в программировании вообще, и в 1С в частности.
Подчеркиваете, что вы можете создавать лучший код чем ваши более опытные коллеги, и что настоящий программист, это тот кто взял математику.
Более того, как опытный преподаватель с научной степенью, пытаетесь донести до кодеров и самоучек очень важные мысли, столь очевидные для вашего уровня развития
есть общий фундамент, который реально общий вообще для всего IT. Алгоритмы, теория сложности, математика, управление проектами, анализ требований - все это общее и в целом - важнее знания конкретной технологии. И, обычно, именно эти сферы благополучно пропускаются самоучками за ненадобностью. Но именно это все и отличает сеньора от джуна.
Есть ваш коллега, работающий 15 лет программистом 1С.
Имеющий колоссальный проектный опыт и прекрасно знающий предметную область.
Он - джун. У него нет той необходимой фундаментальной базы.
Есть вы, работающий 2-3 года программистом 1С. Предполагаю такой опыт просто в силу вашего максимализма.
Вы - сеньор, просто в силу своих технических возможностей.
Вы - идеальный программист.
Вопрос:
Как вы оцениваете его и свои возможности на рынке труда 1C? С точки зрения нахождения новой работы, карьеры, повышения зарплаты?
Скоуп - про необходимое образование для программиста.
Ога, и который раз он уползает в какие-то другие плоскости. А открытые вопросы оставляет без ответа. В лучших демагогических традициях, ага.
Собственно начали с вашей позиции, что программисту нужна фундаментальная база. Причем в виде математики как науки наук.
Ваше отношение к математике понятно, можете не изгаляться в дальнейшем. Вы пытаетесь устраивать противопоставление математика vs философия разработки ПО. Почему-то вы считаете, что если человек смог в математику, он не сможет в KISS YAGNI, DRY и прочее.
Я же утверждаю, что человек, который смог в математику точно также сможет и в философию разработки ПО. У него будет просто больше знаний. И про то, что учиться всю жизнь - я тоже говорил.
\ Есть вы, работающий 2-3 года программистом 1С.
Смишно )) Повторюсь: мы не обсуждали мою личность. Мы обсуждали профессию. Который раз вы меняете тему.
Я все жду, когда от вас будет разгром наголову 1С? Вы же утверждаете, что 1С - криворукие. Достаточно грамотно спроектировать структуру таблиц, грамотно воспользоваться языком запросов и без всякой математики будет решена проблема расчета себестоимости. Вы настолько уверенно об этом говорите, поскольку все западные бест практики построения ЕРП - в вашей голове. Ну жду. Давайте прекращать пустословие. Я все свои тезисы покрыл аргументами в виде примеров. От вас - только голословные громкие заявления и лютая ненависть к математике. Опять же, ничем не подкрепленная.
Вопрос:
Как вы оцениваете его и свои возможности на рынке труда 1C? С точки зрения нахождения новой работы, карьеры, повышения зарплаты?
Я получаю в единицу времени в 4 раза больше него. Когда я говорил, что он смог в бухучет. Я ничего не говорил о себе. Я тоже смог в бухучет. И проектная деятельность - она разная. Можно 20 лет вариться на задачках уровня кнопочки подвигать - это как-то сильно даст опыту разработки и хард скиллов?
Есть вы, работающий 2-3 года программистом 1С. Предполагаю такой опыт просто в силу вашего максимализма.
Сравните мой максимализм:
Программист - профессия. Кроме знания ЯП нужны теоретические знания, например, математика (некоторые разделы).
Нужны все: работы хватит как кодерам, кто не смог в математику, так и программистам. Действует правило Парето: для 80% задач достаточно 20% знаний.
И свой максимализм:
Вместо математики лучше изучать ЯП, фреймворки и т.д.
Математика не создает - математика описывает.
Доцент от науки откинулся и кошмарит программистов
Если из глаз горит математика, то такой программист не способен программировать
Если понадобилась математика, значит изначально было хреново спроектировано. Я знаю как, на Западе знают как, но мы не расскажем.
Я перестал писать эффективный код, его сложно отлаживать (штоаа??? отлаживать удобно любой код, если прокачаны хард скиллы. Ну да, иногда с этой целью надо некий обвес писать).
Таки ваши выпады на самом деле показывают, что у вас 2-3 года опыта, если они есть. Есть подозрение, что у вас есть непроработанная детская психологическая травма. Подозреваю, вас математик в школе покусал. А иначе непонятно ваше неравнодушие к математике.
И еще непонятно: взрослый, сформировавшийся человек способен признать свою неправоту. Высказал свою точку зрения, в ответ - с аргументами опровержение. Достаточно сказать "спасибо, буду знать" - и все ок. Доказывание с пеной у рта заведомо проигрышной позиции - признак незрелого вьюноша.
показывают, что у вас 2-3 года опыта, если они есть. Есть подозрение, что у вас есть непроработанная детская психологическая травма. Подозреваю, вас математик в школе покусал. А иначе непонятно ваше неравнодушие к математике.
Если исходить из того что
допускается что покусал учитель математики в школе,
кандидат физико-математических наук самоутверждается на нежном junior кодере самоучке, с 2-3 годами, а то нулевом (естьNull) опыте.
то неравнодушие к определенного типа математикам вполне объяснимо.
Достаточно сказать "спасибо, буду знать" - и все ок.
Ваше отношение к математике понятно, можете не изгаляться в дальнейшем.
Не к математике, а к "математикам". У вас софт скиллы такие, что не дай бог такого в команде. Если только не изолировать в отдельной комнате с отдельными задачами.
-
Моя позиция: Узкая специализация и софт скиллы. Образование AS YOU GO.
Ваша позиция:: Глубокие знания и hard скиллы. Фундаментальное образование.
-
Давайте все же сформулируем вас бесценный опыт.
"Не взял математику - ты кодер", "Возьми математику - стань программистом 1С"?
Представьте что вы выступаете перед тщедушным подростком c доверием смотрящим вам в глаза. Дайте совет по построению карьеры.
то неравнодушие к определенного типа математикам вполне объяснимо.
Нунуну, 18+, дееспособный, а тонкая душевная организация - ваши проблемы исключительно. Да и совет вам дал хороший - обратиться к психологу.
И, кстати, как смешно получается: пока вы самоутверждались на математиках (откинулся от науки, нездоровый блеск в глазах и т.д.) - все было ок, а как вам ответили - тут же заскулили.
У вас софт скиллы такие, что не дай бог такого в команде. Если только не изолировать в отдельной комнате с отдельными задачами.
И, что характерно, так и не понимаете, почему ответка прилетела )
Моя позиция: Узкая специализация и софт скиллы. Образование AS YOU GO.
Я вам привел примеры, когда эта позиция уступает моей.
Дальше - каждый ССЗБ. Хочите всю жизнь вариться в hello, world и где-то около - you are welcome. Хотите быть более ценным спецом и решать те задачи, где ваш подход дает сбой - you are welcome.
Давайте все же сформулируем вас бесценный опыт.
А вы упорный :) Т.е. не получилось макнуть по деньгам (предыдущий тред про сравнение зп с говнокодером), будете пытаться дальше макать, демонстрируя свои восхитительные софт скиллы.
Я могу только повториться: мы обсуждаем профессию программиста. Обезличенно я вам привел аргументы. Мою личность мы не разбираем.
"Не взял математику - ты кодер", "Возьми математику - стань программистом 1С"?
Мне вообще пофиг на каком языке писать. На каком потребуется - на таком и буду. Да, основательный переезд на другие рельсы - болезненный. Но не невозможный. Java, C++, Delphi - это то, с чем я спокойно работаю. Понятно, что дельфи уже не актуален, но было дело.
Т.е. не получилось макнуть по деньгам (предыдущий тред про сравнение зп с говнокодером), будете пытаться дальше макать, демонстрируя свои восхитительные софт скиллы.
Это скорее про то, что практика - критерий истины. Успех он все же не в идеальном коде и моральном удовлетворении, а в терминах получения благ. Другой объективности просто нет.
Это не про макнуть, а включить осознанность, где вы и почему. Но вы правы, вы меня не просили быть вашим карьерным коучем.
пока вы самоутверждались на математиках (откинулся от науки, нездоровый блеск в глазах и т.д.) - все было ок, а как вам ответили - тут же заскулили.
Психолог меня спасет :)
мы обсуждаем профессию программиста
Легко. Бери ПРОФЕССИОНАЛЬНОЕ образование. Языки устаревают, концепции - появляются новые. Математика и прочая теория - на века.
Решил стать программистом? Молодец! Будешь учиться всю жизнь. Как только остановишься - вылетишь с рынка.
Вот про рынок интересно. Как ПРОФЕССИОНАЛЬНОЕ образование влияет на успех на рынке труда. Если, как только проектный опыт прохудился, - ты на обочине?
Это скорее про то, что практика - критерий истины
Значит скоуп опять убежал :) Ну да ладно.
Успех он все же не в идеальном коде и моральном удовлетворении, а в терминах получения благ. Другой объективности просто нет.
Больше знаний -> больше возможностей
Как ПРОФЕССИОНАЛЬНОЕ образование влияет на успех на рынке труда
Знания программиста состоят из разных частей.
Вот одна из них - фундамент в виде теории (математика и философия) закладывается с получением профессионального образования в ВУЗе. И пополняется сравнительно редко.
Другая часть - знания ЯП и фреймворков. Пополнять нужно постоянно. Как только здесь остановился - вылетел с рынка.
Фундамент дает плюсы на собеседовании.
фундамент в виде теории (математика и философия) закладывается с получением профессионального образования в ВУЗе. И пополняется сравнительно редко.
Другая часть - знания ЯП и фреймворков. Пополнять нужно постоянно. Как только здесь остановился - вылетел с рынка.
Фундамент дает плюсы на собеседовании.
Актуально для уровня junior и middle, при рынке работодателя по конкретной специализации.
Как бы грузчики, постоянно демонстрирующие что они смогут и рояль, и хрусталь на 16 этаж и без лифта.
Даже в гос компаниях РФ вам простят ваш фундамент и даже полное отсутствие высшего образования, если вы редкий эксперт с проектным опытом.
Широта и универсальность навыков она в АСУ, на галерах, и прочих не самых привлекательных местах. В то время как приличный уровень жизни там, где узость и глубина этой узости, которая ничего общего с примитивностью "hello word" не имеет.
Актуально для уровня junior и middle, при рынке работодателя по конкретной специализации.
Меня на сеньора по алгоритмам гоняли. И про сложность спрашивали.
если вы редкий эксперт с проектным опытом.
А рядом будет редкий эксперт с проектным опытом и пониманием алгоритмов и матана. Кто победит?
Как бы грузчики, постоянно демонстрирующие что они смогут и рояль, и хрусталь на 16 этаж и без лифта.
Вы все не хотите уловить мысль, что computer science (куда входит и математика в том числе) - общая база для всех специализаций. Впрочем, мир - он большой. В моей картине мира профессиональное образование дает плюсы. Я это вижу. Не видите - ваше право. Работы хватит всем.
В то время как приличный уровень жизни там, где узость и глубина этой узости, которая ничего общего с примитивностью "hello word" не имеет.
Я вижу приличный уровень жизни как раз там, где предлагаются сложные задачи, которые завязаны на алгоритмы и матан. Биг дата, машин ленинг, и всякие интересные штуки вроде ядра торговой системы или ядра биллинга или еще какой хайлоад.
Меня на сеньора по алгоритмам гоняли. И про сложность спрашивали.
Всяко бывает, но хватает и других, от простого разговора за жизнь до тестового задания по специализации.
А рядом будет редкий эксперт с проектным опытом и пониманием алгоритмов и матана. Кто победит?
Тот у кого лучше soft skills. Тот кто умеет себя продать.
В моей картине мира профессиональное образование дает плюсы.
У меня высшее техническое образование по специальности программирование. И математика там была. Но как взял, так и положил обратно. Моя особенность была в том что я учился после первого юридического, и в зрелом возрасте. Очень хорошо понимал, что мне надо, а что нет. Закончилось тем, что все что мне действительно было нужно - пришлось брать самому во время обучения самостоятельно. За отличное преподавание С++ я при этом благодарен преподавателям.
По факту, диплом одного из ведущих технических университетов мне пригодился только однажды в начале карьеры - при устройстве в компанию где были выпускники этого вуза и знали этих преподавателей.
Сейчас у меня одна из дочерей входит в программирование, и есть понимание что ВУЗ сейчас не нужен от слова совсем. Но должен сказать, что это не в России. И что у меня супруга HR хорошо знающая и Российский, и международный рынок IT.
Я вижу приличный уровень жизни как раз там, где предлагаются сложные задачи, которые завязаны на алгоритмы и матан.
Можно решать наукоемкие задачи в условном НИИ, и заниматься формошлепством за компенсацию на порядок больше. Наукоемкость и уровень зарплаты - не связаны.
Уникальность и дефицит таких специалистов - да, так как спрос-предложение определяет зарплату (при наличии рынка как такового). Условно говоря специализироваться по Hadoop, по Postgres к примеру, на уровне эксперта. Где ваша математика это просто ваш способ брать любую глубину.
Представьте что вы выступаете перед тщедушным подростком c доверием смотрящим вам в глаза. Дайте совет по построению карьеры.
Легко. Бери ПРОФЕССИОНАЛЬНОЕ образование. Языки устаревают, концепции - появляются новые. Математика и прочая теория - на века.
Решил стать программистом? Молодец! Будешь учиться всю жизнь. Как только остановишься - вылетишь с рынка.
Понимаю ваши предрассудки. Дилетантское мнение - оно такое.
Чем не угодила? Писать на русском - это же бреееед? :)
Основной пойнт в том, что программист с профильным образованием, или просто с серьезным проектным опытом, впадет в глубокую депрессию от такого контрафакта.
Язык настоящей профессии - английский. Как и базы данных 1C, к которой этот запрос обращается. Как и ядра системы 1C, которое тоже на английском. Уровень профессионализма программиста очень тесно связан со знанием английского языка.
Сам по себе факт кода на русском, говорит о том, что целевая аудитория это не профессиональные программисты или непрофессиональные программисты, если угодно.
Такое вот мое дилетантское мнение. Такие вот предрассудки.
Пойду скушаю ничего.
ВЫБОР КОГДА ЕСТЬ ТОГДА ИНАЧЕ
ВЫБРАТЬ
СправочникНоменклатуры.Наименование,
ВЫБОР КОГДА УчетНоменклатурыОстатки.КоличествоОстаток ЕСТЬ NULL ТОГДА 0 ИНАЧЕ УчетНоменклатурыОстатки.КоличествоОстаток КАК КоличествоОстаток
ИЗ
Справочник.Номенклатура КАК СправочникНоменклатуры
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.УчетНоменклатуры.Остатки КАК УчетНоменклатурыОстатки
ПО УчетНоменклатурыОстатки.Номенклатура = СправочникНоменклатуры.Ссылка
ГДЕ
СправочникНоменклатуры.ЭтоГруппа = ЛОЖЬПропущенное:
Я складской учет, которым можно пользоваться, напишу за день. Вместе с отчетностью. Сколько вам потребуется времени реализовать аналогичный функционал на том же САП? Или, не дай Бог, на голой джаве?
Вы сделаете это за день. Сколько вам за это заплатят?
Сколько заплатят тому кто сделает то же самое за месяцы на том же САП и голой джаве?
Вы вполне себе можете всю жизнь писать hello, world! И вам работы хватит. Но это - ваш выбор.
Работать, за $2000 или за $10,000 это тоже выбор. Работать с 1С это тоже выбор. Знаковый для профессиональных программистов с профильным образованием.
Человек со стажем в 1С около 15 лет продолжает программировать так, будто у него платформа 7.7. Он не способен втыкнуть про новую модель разработки.
... Он круто разбирается в бухгалтерских кейсах, но вот беда: переложить на язык программирования свои идеи у него получается через жопу.
Если вы о некой недоразвитости данного человека по восприятию абстракций, где вы в отличие от него все схватываете на лету. Model Driven Architecture в 1С:8 как и любая унификация, может просто отторгаться мозгом не-математика как извращение, в то время как для математика это красиво. Уверен, что нет непонятных вещей, есть непонятные объяснения. В терминах восприятия данного человека. Он смотрит через процессы, и просто не понимает как можно (и вообще зачем) смотреть через объекты и их свойства.
Хронологичность — базовое требование к учету. Так что имели право забить. Но решили сделать хорошо клиентам.
Утверждение, возможно, верное теоретически, но (в частности, по информации моего друга-белого бухгалтера) совершенно не соотвествовавшее практике ведения «белого» бухгалтерского учета. Потому что на практике немалое количество документов первичного учета («первички», по взаимодействию с, якобы, сторонними «черными» фирмами) генерилось уже post factum, в процессе закрытия отчетного периода, исходя из соображений минимизации налогов. Мой тогдашний друг тогда занимался, в частности, и этим, и делился трудностями и интересными случаями.
Так что, видимо, в 1С хорошо знали реальные потребности своих клиентов, а потому позаботились об их удовлетворении.
А сейчас эта забота вызывает удивление у тех, кто не совсем в теме.
Потому что на практике немалое количество документов первичного учета («первички», по взаимодействию с, якобы, сторонними «черными» фирмами) генерилось уже post factum, в процессе закрытия отчетного периода, исходя из соображений минимизации налогов.
Я вам более того скажу. С первичкой всегда в 100% случаев возникает какая-нибудь засада. То бумажка едет неделю с экспедитором, то забили, то потеряли, то просто менеджер по закупу в запой ушел и начал свои накладные через неделю заводить...
Т.е. даже не обязательно в серые схемы играть, чтобы получить нарушение хронологичности. Нет ни одной конторы, где бы строго следили за порядком ввода документов - это просто не реально. Даже с автоматизацией документооборота.
Раньше в Зарплате 7.7 была такая штука как "Сторно". Как раз придумано с целью избежать проведения задним числом. Так вот от этой затеи отказались по причине потрясающего количества багов и чрезвычайного усложнения логики. Для целей зарплаты как раз придумали специальный агрегат - регистр расчетов. Там есть разные механизмы вытеснения. Для расчетов ЗП - подходит, для других задач - не очень. 1С сделали механизм универсальным, но применяется все равно только в зарплате. Были попытки притянуть к себестоимости и амортизации ОС, но не взлетело. Слишком сложно и профит не ясный. Другое дело РАУЗ - это чуть ли не главный аргумент был в переходе с 7ки и с 10.3 на 11.1 (конфигурация - Торговля).
Справедливости ради, в РАУЗ тоже есть проблемы. Например, система может не решаться, если есть проблемы в корректности и полноте ввода первички. Но решить эти проблемы существенно проще, чем с партионным учетом и восстановлением последовательностей.
А как же обстоят дела в крупных конторах? А никак. Тем или иным способом восстанвливаются последовательности проведения (в САП есть аналогичная процедура, подробностей не знаю). Затем закрывается период. После этого бухгалтер получает возможность анализировать себестоимость.
В 1С есть своя специфика - это правда. Сам термин проведение придуман фирмой 1С. Эта штука дает как неимоверный профит (простота доработки под нужды пользователя, простота архитектуры), так и создает нереальные проблемы (производительность в первую очередь).
Как бы то ни было, особо не поспоришь, что идеи 1С взлетели. Вся Россия сидит на 1ске. Ее еще и экспортировать умудряются.
Но только с опытом в программировании, без обременения математикой, вы 100% сделаете кратно тормознее.
В принципе, этот аргумент - квинтэссенция вашего взгляда на программирование.
Скорость - это физическая величина. Создание оптимального кода ничего общего с математикой не имеет. Математика - это абстрактный уровень описания, но не реализации.
Уровень же написания кода это физика и опыт программирования. Понимание как используются ресурсы и какой код от тебя ожидается в данной системе.
Физика и механика на уровне реализации.
Иначе мы берем сливки 10% и 20% и вычисляем 30% сливки. А если мы знаем как получить 30% сливки, то понимание того что это сумма 10% и 20%, оно ни о чем.
Ага. Вон оно что, Михалыч ) Таки вы считаете, что в нормативке бухучета зарыт АЛГОРИТМ? Спешу разочаровать: нет.
Что такое граф затрат? Что такое центры затрат? Как это все строится - это придумка от программистов 1С.
Это стандартная архитектура всех MRP/ERP систем там где такая проблема прохода по записям возникает. То решение о котором вы говорите я вижу как шаблонное начиная с 2004 года.
Любой старший программист в области ERP, в западном понимании этого термина, в первую очередь будет думать о записи в дополнительные таблицы для ускорения вычислений.
Очевидный шаблон на подкорке. Это не алгоритм. Какая же эта четкая последовательность действий когда у вас с десяток событий и запись в пяток дополнительных таблиц. А потом вы вы эти специальные таблицы используете при расчете. Это дизайн решения, а не алгоритм. И не математик его создает, а просто опытный разработчик.
И, вы же понимаете, это один из примеров, но не единственный.
Нестандартные задачи компьютерной графики?
Ну, например, построить выпуклую оболочку? Вряд ли unity умеет это. Задача-то специфическая. Специфическая, но распространенная. Столкнуться можно с такой.
Про оптимизацию - уже рассказывал. Реальный запрос производства на оптимизацию раскроя. Программист-кодер наваял жуткое решение и с гордым видом, что никто так не умеет начал объяснять, как он дошел до жизни такой. Внезапно (после могучего фейспалма) ему открылись целые учебники, где тоже самое и проще и лучше. Но чел даже не знал, что можно гуглить эту тему.
А мой коллега погрузился в биржевую торговлю. Решил заработать на бинарных опционах. Нашел жуткий матан по теме. Разобрался в нем (благо, база позволяла) и на основе матана собрал торгового робота, который ему успешно приносил гарантированные, хоть и не большие деньги, зато непрерывно. Одну зп он получал ковыряя 1с, а вторую зп ему приносил робот.
Примеров уйма. Да, таких задач не много. Но они есть.
Программист-кодер потому что. Senior сделает как надо. Не имея при этом никакой математической базы кроме школьной программы.
А вот, там где биржа, трейдинг - да, разработка моделей. Но это про предметную область скорее где нужна математика.
А где-то нужно знать геологию при визуализации геологического софта, это OK.
Математик != Senior
Нестандартные задачи компьютерной графики
Думаю что использование графических библиотек это просто про особенности головы конкретного человека, его пространственное мышление, про его склонности, чем про знания математики.
Но спорить здесь не буду. Понятно что где-то умение жонглировать семью тарелками все же нужно. Не зря же столько времени на это жонглирование потрачено.
Если вы знаете 100 языков, вы - все равно кодер.
А что нужно, чтобы стать программистом?
Нужна - база. И это ни разу не языки программирования.
Вот так базу представляю я:
Минимально необходимая база - математика. Вся. Вообще вся.
Есть Computer Science и есть Maths.
Представляется более верным формировать нейронные связи сразу на реляционной базе данных, чем усваивать реляционную алгебру саму по себе.
База для программиста это (само)-образование по Computer Science. Системное и охватывающее.
Программист-профессионал (который взял фундаментальное образование) - он и в аналитику может и в тестирование и, в админы и прочая-прочая. Самоучка может только в ЯП и идти четко по сценарию.
То есть эдакий с кандидатским минимумом условный матмех, c гордостью о том, что он может и в тестирование и в DevOps, а еще и уборку в офисе?
Подозреваю что вы подменяете фундаментальное образование для программиста университетским образованием на факультетах матмех, физмат и прочих садомазо.
Примерно о том, что отслужил в армии - теперь могу мыть полы. Не пугаюсь любого объема уборки.
Профессиональным программистом может быть и junior который только в ЯП.
А непрофессиональным программистом может быть эникейщик который вроде бы может все, да никто ему не дает.
В жопу фундаментальное образование по уборке всего и вся. Сейчас время специалистов. И чем уже, тем лучше. И вам и ей.
Какая у вас в конце изящная игра слов на грани фола.
Представляется более верным формировать нейронные связи сразу на реляционной базе данных, чем усваивать реляционную алгебру саму по себе.
Ок, т.е. с вашей точки зрения, программист не должен заморачиваться на планы запросов. БД ведь сама их строит? А мне кажется, что знание реляционной алгебры углубит понимание построения планов запросов и лишним точно не будет.
База для программиста это (само)-образование по Computer Science. Системное и охватывающее.
Ну да. Осталось договориться о деталях: входит в computer science математика или нет? )
Подозреваю что вы подменяете фундаментальное образование для программиста университетским образованием на факультетах матмех, физмат и прочих садомазо.
Ну "садомазо" - это лишь ваше отношение, и это не означает, что это единственно верная позиция. Лично для меня матмех, физмат и прочее "садомазо" означает, что кандидат невероятно крут. Если он, конечно, взял образование. Мозги, отформатированные математикой, гораздо лучше работают в программирование, чем гуманитарные мозги.
Профессиональным программистом может быть и junior который только в ЯП.
Такому не доверишь проектирование архитектуры решения.
А непрофессиональным программистом может быть эникейщик который вроде бы может все, да никто ему не дает.
По мне - эникейщик и джун только в ЯП - примерно одного уровня. Почему эникейщику не дают быть джуном - большой вопрос.
В жопу фундаментальное образование по уборке всего и вся. Сейчас время специалистов. И чем уже, тем лучше. И вам и ей.
Ну а проблема-то в чем? в жопу образование? Прекрасно. Для вас есть море работы. Еще не все jsonы переложены из одной БД в другую. Очевидно, что сложные вопросы, будут решаться теми, у кого другое отношение к образованию. Мехмату, физтеху и прочими садомазо.
Ок, т.е. с вашей точки зрения, программист не должен заморачиваться на планы запросов. БД ведь сама их строит? А мне кажется, что знание реляционной алгебры углубит понимание построения планов запросов и лишним точно не будет.
Очень хочется чтобы углубители углублялись в друг друга. Нет смысла учить реляционную алгебру отдельно. Хорошей дисциплины по базам данных достаточно.
Ну а проблема-то в чем? в жопу образование? Прекрасно. Для вас есть море работы. Еще не все jsonы переложены из одной БД в другую. Очевидно, что сложные вопросы, будут решаться теми, у кого другое отношение к образованию. Мехмату, физтеху и прочими садомазо.
Сложный вопрос, это вспомнить адрес жительства своего преподавателя по реляционной алгебре, когда ты стоишь в комнате разработчиков ebay, которым срочно нужна экспертиза по СУБД большого размера. Чтобы сел и сделал. Экспертиза, а не понимание.
Ты можешь сделать или ты не можешь сделать. Твое понимание никого не углубляет.
Нет смысла учить реляционную алгебру отдельно. Хорошей дисциплины по базам данных достаточно.
Почему нельзя изучить реляционную алгебру в рамках курса по БД?
которым срочно нужна экспертиза по СУБД большого размера. Чтобы сел и сделал.
Так это связанные вещи. Понимание, во что превратится твой select с десятком джойнов - это как раз та самая экспертиза, в которой в том числе есть и понимание реляционной алгебры.
Почему нельзя изучить реляционную алгебру в рамках курса по БД?
Реляционная алгебра и так неотъемлемая часть дисциплины. Ей не нужно выпячиваться. Многие могут даже не осозновать, что это математика, но прекрасно применять джойны будучи полными "гуманитариями".
Понимание, во что превратится твой select с десятком джойнов - это как раз та самая экспертиза, в которой в том числе есть и понимание реляционной алгебры.
Математику можно найти и на крыльях бабочки. Правильный результат выборки это давно уже не уровень специалиста.
В моем примере, на миллионах записях на MS SQL, то во что превращается запрос - это уже физический дизайн всего и вся, то есть железо и атрибуты, где дух Эдгара Кодда пролетает. Он даже вреден там где мы говорим про производительность. И в расследовании всего этого математический архитип убьет себя об стенку. Совсем другие мозги нужны.
Очередная статья-куча про войти вайти в том смысле что навалено все в одну кучу от необходимости знать асемблер до лиспа (спасибо что не слои OSI или как электроны там по проводам бегают). По-моему это всё какой-то снобизм и по факту чтобы состояться в профессии надо всего-то уметь гуглить/учиться, иметь зачатки логического мышления и толерантность к возникающим сложностями (ошибку погуглить, ага).
Начало ну очень интересное. На прошлой недели решил поставить цели для своего профессионального и творческого роста. Мой список практически идентичный списку автора.Единственное чего не хватает так это поддержка физической формы. Последнее может по разному выражаться. Но как по мне точно от базы не оторвать.
Почему не нужно идти в айти — демотиватор