Комментарии 149
лады)
С++ выкинуть из списка. Объективно - он не нужен, захламляет голову спецификацией языка и его "особенностями", которые нафиг не нужны. Си в качестве первого тоже, наверное, не самый удачный выбор. Кмк, можно легко стартануть как с паскаля, так и с python и ничего страшного не случится - небо на голову не упадет. В качестве же второго языка... не знаю... наверное, пускай джава сразу будет, почему нет?
При изучении Си приходит гораздо больше понимания того как всё устроено, чем при Python. После Си очень легко изучать все остальные языки. Поработать с Си строками и указателями must have :)
С++ здесь исключительно для изучения ООП. В нем можно познать проблемы множественного наследования, понять что такое виртуальная функция, деструкторы. Например в Java нет множественного наследования, все методы по умолчанию виртуальные, деструкторов нет
Я лично занимался по этим книгам и считаю их полезными для заложения уверенного фундамента в начале. Я считаю, что с этими знаниями приходит понимание того как устроены верхнии уровни абстракции. Вообще полезно уметь что-то делать на других языках что-то выше уровня hello world, поэтому лишним никогда не будет
При изучении Си приходит гораздо больше понимания того как всё устроено, чем при Python.
увы, но нет. Когда мы изучаем Си, мы изучаем особенности Си, а не особенности той платформы, на которой он работает. Просто если уж так рассуждать - надо ассемблер брать :-)
С++ здесь исключительно для изучения ООП. В нем можно познать проблемы множественного наследования, понять что такое виртуальная функция, деструкторы. Например в Java нет множественного наследования, все методы по умолчанию виртуальные, деструкторов нет
С++ - худший язык, на котором стоит изучать ООП.
Я лично занимался по этим книгам и считаю их полезными для заложения уверенного фундамента в начале. Я считаю, что с этими знаниями приходит понимание того как устроены верхнии уровни абстракции. Вообще полезно уметь что-то делать на других языках что-то выше уровня hello world, поэтому лишним никогда не будет
есть два подхода. Есть подход "сверху вниз". Мы разбираемся с какими-то явлениями, потом их уточняем. Выясняем, что под капотом. Плюс такого подхода в том, что мы сразу получаем цельную картинку и можем сразу что-то делать. А это очень важно, например, при обучении детей. Если же мы идем "снизу вверх" - т.е. от регистров процессора (кстати, Си про это ничего не говорит), от стека, от хипа, от порядка битов в байте и прочего - у нас цельная картинка формируется только в конце. И немногие доходят до этого конца. Я уж не говорю, что в этой парадигме начинать с Си - это начинать с середины... а не с самого начала.
увы, но нет. Когда мы изучаем Си, мы изучаем особенности Си, а не
особенности той платформы, на которой он работает. Просто если уж так
рассуждать - надо ассемблер брать :-)
Си я выбрал в пользу отсутсвтия сахара в синтаксисе. Слишком много магии делает Python, плюс в нем динамическая типизация данных из-за чего может быть проблематично объяснить типы данных. В книге по Си идет объяснение того как данные лежат в памяти, сколько места они могут занимать(есть поверхностное определение памяти). Чтобы не было трудно это все переварить, в самое начало я вставил лекции CS50, где лектор объясняет это студентам, которые хотят въехать.
С++ - худший язык, на котором стоит изучать ООП.
Я оттолкнулся от того в чем был уверен. Мой (и моих одногруппников) опыт показывает, что этот вариант очень даже удачный. Автор в книге постарался за ручку провести читателя, чтобы у него не лопнула голова.
есть два подхода. Есть подход "сверху вниз". Мы разбираемся с какими-то
явлениями, потом их уточняем. Выясняем, что под капотом. Плюс такого
подхода в том, что мы сразу получаем цельную картинку и можем сразу
что-то делать. А это очень важно, например, при обучении детей. Если же
мы идем "снизу вверх" - т.е. от регистров процессора (кстати, Си про это
ничего не говорит), от стека, от хипа, от порядка битов в байте и
прочего - у нас цельная картинка формируется только в конце. И немногие
доходят до этого конца. Я уж не говорю, что в этой парадигме начинать с
Си - это начинать с середины... а не с самого начала.
Я бы очень хотел пункт про архитектуру ЭВМ вынести в самое начало, но посчитал, что это может лишь оттолкнуть. Ну Си это не прям таки середина, я выбрал его как низ откуда можно начать. Он все таки ближе к железу. Про регистры, кэши, выравнивание в памяти в книги есть упоминание, но согласен, что без знания архитектуры ЭВМ это может быть трудно понять. Но можно оттолкнуться от образовательной программы, где сперва идет Си, а потом архитектура ЭВМ. Первокурсники справляются. Поэтому почему нет?
Он все таки ближе к железу.
это ложный тезис. В частности, если речь идет про современный С. Я могу привести много аргументов. Например, тот же UB. Ты такой думаешь, что Си транслируется один-в-один эквивалентный ассемблерный код, а фиг там был. Размер типов C - это тоже песня. Оптимизирующий компилятор, который в результате может доказать, что черное это белое, а белое это черное... ох ты ж мать... Короче, если нас волнуют алгоритмы - Си нафиг. Тот же пайтон прекрасно вывозит. И прекрасно на нем тоже покажете в чем разница разных алгоритмов с разной сложностью (о большое). Дальше - кто захочет - тот пойдет в дебри.
Я оттолкнулся от того в чем был уверен. Мой (и моих одногруппников) опыт показывает, что этот вариант очень даже удачный. Автор в книге постарался за ручку провести читателя, чтобы у него не лопнула голова.
я думаю, что (повторюсь), что С++ может быть хорошим выбором, когда ты уже профессионал и такой смотришь - что бы еще изучить. Отчасти это подтверждается комментариями ниже. Как минимум я могу сказать одно - тот, кто думает, что знает С++, скорее всего его не знает вообще. @0xd34df00d подтвердит. К тому же, правильный ООП - это не то, что в С++, а скорее то, что в SmallTalk. Но вот почему-то этот язык вообще не изучают нигде (развожу руками)
это ложный тезис. В частности, если речь идет про современный С. Я могу
привести много аргументов. Например, тот же UB. Ты такой думаешь, что Си
транслируется один-в-один эквивалентный ассемблерный код, а фиг там
был. Размер типов C - это тоже песня. Оптимизирующий компилятор, который
в результате может доказать, что черное это белое, а белое это
черное... ох ты ж мать... Короче, если нас волнуют алгоритмы - Си нафиг.
Тот же пайтон прекрасно вывозит. И прекрасно на нем тоже покажете в чем
разница разных алгоритмов с разной сложностью (о большое). Дальше - кто
захочет - тот пойдет в дебри.
Ну при изучении основ программирования на Си наверное никто не использует оптимизации компилятора. Хотя в книге есть примеры того, как компилятор может оптимизировать код. И даже есть некоторые примеры того, как сказать компилятору, чтобы он этого не делал, например пометить переменную как volatile.
я думаю, что (повторюсь), что С++ может быть хорошим выбором, когда ты
уже профессионал и такой смотришь - что бы еще изучить. Отчасти это
подтверждается комментариями ниже. Как минимум я могу сказать одно -
тот, кто думает, что знает С++, скорее всего его не знает вообще. @0xd34df00d
подтвердит. К тому же, правильный ООП - это не то, что в С++, а скорее
то, что в SmallTalk. Но вот почему-то этот язык вообще не изучают нигде
(развожу руками)
Я изучал С++ в школе для решения задач по спортивному программированию. Очень много вынес оттуда для себя. Я не был профессионалам, не использовал крутые возможности языка, о которых даже не знаю, также точно не стал профессионалом в нем. Но я твердо уверен, что именно эта книга будет полезна при изучении ООП, потому что старался в качестве материала подать то, через что я сам прошел.
Спасибо, было интересно читать ваш комментарий.
Я посчитал, что будет правильно дать Си, потом С++ и Java(в алгоритмах). Чтобы сложилась некая картина эволюции. В Си есть есть указатели. В С++ указатели, ссылки и шаблоны, в Java свои ссылки и дженерики.
В книге по Си есть зачатки ООП в виде указателей на функции и структуры. В С++ ООП уже в синтаксисе языка. И наверное было бы неправилно сразу дать Java т.к. остались бы пробелы, которые можно было бы понять в С++ (виртуальные функции, множественное наследование, деструкторы, ручное освобождение памяти)
Книга по С++ расчитана на новичков. Они не столкнутся со всем ужасом из-за которого С++ называют монстром. Но внесет некую пользу в общих образовательных целях
В книге по Си есть зачатки ООП в виде указателей на функции и структуры.
WHAT? Это просто указатели )))
В одном соглашусь, что ООП подход можно и в т.н. процедурных язвах использовать. Я хотел про это написать, но застремался, что придут фанаты крестов и наставят минусов.
В С++ ООП уже в синтаксисе языка
только один из вариантов, иначе бы Qtшникам не пришлось бы строить свое надмножество над С++.
WHAT? В одном соглашусь, что ООП подход можно и в т.н. процедурных язвах
использовать. Я хотел про это написать, но застремался, что придут
фанаты крестов и наставят минусов.
Да, тут где-то на хабре статья была про ООП на Си. Есть также книга Экстремальный Си, там вроде как показывают как добиться ООП.
Я не заставляю людей сидеть над С++ вечно. Это одна книга с лекционным материалом и упражнениями по ООП. Упражнения больше заточены под ООП, а не под особенности С++, про которые читатель даже не узнает т.к. цель книги не про них
Еще раз С++ - это не ООП здорового человека, а что-то не то.
Посмотрите еще раз - отцом-основателем ООП является Алан Кей. Он же создатель SmallTalk и он постулировал следующие принципы:
Всё является объектом.
Вычисления осуществляются путём взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия.
Каждый объект имеет независимую память, которая состоит из других объектов.
Каждый объект является представителем класса, который выражает общие свойства объектов (таких, как целые числа или списки).
В классе задаётся поведение (функциональность) объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия.
Классы организованы в единую древовидную структуру с общим корнем, называемую иерархией наследования. Память и поведение, связанное с экземплярами определённого класса, автоматически доступны любому классу, расположенному ниже в иерархическом дереве.
Как минимум уже в первом пункте С++ проваливается с треском куда-то в тартар. Я уж не говорю о том, что в понятии С++ ООП - это классы с функциями. А ООП здорого человека - общение между объектами при помощи сообщений (п.2). Ну, и т.д. Поэтому С++ самый неудачный модельный язык для изучения ООП.
ну, и почему-то ни разу не упомянули про https://habr.com/ru/post/325478/ А это как минимум, на минуточку, не про особенности синтаксиса конкретного языка, а скорее про общие принципы построения объектной модели...
Я старался выбрать то, что уже давно как-то устоялось. Чтобы было уже много ресурсов для изучения. Си, С++, Java подходят идеально. Я считаю, что С++ отлично закрывает пробел между Си и Java в обучении. Никакой другой язык на его месте в этом списке я не хотел бы видеть.
Про SmalTalk я мало что знаю, ничего по нему посоветовать не могу, и наверное это было бы неправильно с моей стороны.
Под ООП давно уже понимаются те самые "классы с функциями". Обмен сообщениями был "поглощён" моделью акторов.
Проблема С++ в том, что даже те самые "классы с функциями" в нём не очень хорошо ложатся на "классы с функциями" ООП, а потому перед тем как ООП использовать, его надо сначала реализовать. В итоге при изучении ООП есть риск выучить эту самую реализацию ООП в С++, а саму парадигму даже не увидеть.
Вот лично я умением чисто формально преобразовывать ООП-программу в ФПшную не владею (однако допускаю ограниченность своих знаний теории и не против эту ограниченость несколько уменьшить).
Напоминаю, что для ООП(того, которому можно научиться по C++) нам нужно получить инкапсуляцию, наследование и полиморфизм, и это — в языке, в котором нет не только переменных типа «функция» (которые могли бы помочь сделать полиморфизм), но и аналога struct из C-подобных языков. Ну, допустим, как сделать инкапсуляцию (ограниченную, области видимости private/protected сделать все равно не получится, в это компилятор должен уметь) было известно ещё во времена настоящих программистов — массив+EQUIVALENCE: «Как все настоящие
программисты знают, единственной полезной структурой данных является массив. Строки, списки, структуры и наборы — это все разновидности массивов и их можно рассматривать как массивы без усложнения вашего языка приграммирования.» (из статьи по ссылке). Правда, формальные параметры в EQUIVALENCE совать нельзя, но что-нибудь, наверное с этим сделать можно.
А вот как сделать наследование — тоже примерно понятно: берем массив большего размера, и прописываем все EQUIVALENCE ручками. А как все-таки реализовать полиморфизм — я так до конца не понял.
PS А вообще-то, наверное, это — тема статьи для хаба «Неномальное программирование», а писать ее в комментариях — так себе идея IMHO; так что можно бы это обсуждение и завершить без засчитывания слива.
PPS Те, кто предыдущий камент Дедфуда заминусовал — поясните за минусы.
ограниченную, области видимости private/protected сделать все равно не получится, в это компилятор должен уметь)
А нужна ли она? Вот ответьте на вопрос - а пайтон ООП язык? Если да, то там нет областей видимости. А если нет, то откуда же там принцип, что все есть объект определенного класса?
Напомню, что в пайтоне есть конвенция о наименовании приветных членов с двойного подчеркивания, но де-факто они доступны всем
А как все-таки реализовать полиморфизм — я так до конца не понял.
Как выше заметили - либо для полиморфизма нужен eval(), который позволяет фигачить самомодифицирующиеся и спмозапускающиеся программы. Либо нужно что-то типа указателя на функцию (в Си есть) и возможность через неё вызвать код. Какого-то третьего пути у меня в голову не приходит. Разве что как-то расфигачить систему макросов Си, но это будет выглядеть как .... известная субстанция
methods[0] = UID_Derived_dtor;
Не получится. Имя функции можно только в качестве фактического параметра передать, в переменную его сохранить нельзя.
PS Но я тут подумал: в FORTRAN IV был такой замечательный оператор — assigned GOTO, для него можно в переменную сохранить (оператором ASSIGN) метку оператора, а потом выполнить переход по этой метке. Вполне можно эмулировать вызов виртуальной функции через этот оператор (а адрес возврата сохранять в другой переменной и возвращаться тоже по assigned GOTO).
Так что, наверное, на FORTRAN G или H для IBM/370 (ЕС ЭВМ Ряд 2 в странах СЭВ) настоящие программисты могли бы писать и похожие ООП программы.
Короче, я, похоже, был не прав. «Да здравствует Фортран !»(с) (из все той же статьи)
Если очень хочется, то с расширениями уже можно работать с функциями-переменными (в данном случае достаточно уметь считать адрес функции с помощью LOC, что было доступно на P400 в 64V mode).
Мануал, по которому писалось: https://sysovl.info/pages/blobs/prime/devel/MAN1674_FortranIV_Jul76.pdf
Кодец
external get_func
double precision res
common /MEM/ X(1)
integer*2 X
integer func, get_func, locx
locx = loc(x)
func = get_func(0)
call eval(x((func-locx+1)/2), 3D0, 6D0, res)
write(*,*) res
func = get_func(1)
call eval(x((func-locx+1)/2), 3D0, 6D0, res)
write(*,*) res
end
function get_func(f)
external add, mul
integer f, get_func
if(f.eq.1) then
get_func = loc(add)
else
get_func = loc(mul)
end if
end
subroutine eval(func, x, y, res)
double precision func
external func
double precision x, y, res
res = func(x, y)
end
function add(x, y)
double precision x, y, add
add = x + y
end
function mul(x, y)
double precision x, y, mul
mul = x * y
endте их на ассемблере»
А вот средствами самого языка — таки задача, решения которой лчино я не знаю.
Ну тема всё равно не раскрыта -- какой именно язык подразумевает каждый из комментаторов в этой ветке когда отвергают ООП C++-edition? Промелькнул только весьма своеобразный SmallTalk. Но, имхо, если новичок как-то вкатывается в IT нестандартным путём, то изучать стоит в первую очередь практический значимые технологии/инструменты. Получив основы и имея представления о кухне уже можно заводить хобби Haskell/SmallTalk/Scala..., но не раньше.
Но, имхо, если новичок как-то вкатывается в IT нестандартным путём, то изучать стоит в первую очередь практический значимые технологии/инструменты
C++ не является практически значимой технологией. Можно возразить - а как же Яндекс? Или кто там еще любит кресты. А вот так. Посмотрите любой индекс популярности языков. Там будут JS, Python, Ruby... И самое главное - об них не нужно так ломать мозг. Своих причуд хватает, но народ пишет. Для промышленного кода - скорее всего инвестиция в Java или C# с точки зрения обучения будет полезнее. С Java интересно - с него можно и на Scala, и на Котлин прыгнуть. И опять же - оба языка, на мой взгляд, более актуальны, чем C++....
С тезисом коллеги ниже
Лично я подразумеваю, что ООП несколько переоценено.
также соглашусь.
Касательно С++ - мое мнение такого - если очень хочется, если хочется постоянно вникать в тонкости компиляторов и новых стандартов, если хочется фигачить на темплейтах, писать головодробительный код и показывать мастерство покруче, чем Александреску и Страуступ - да, пожалуйста. Никто не держит :-) Да и есть неиллюзорный шанс в конце-концов получить высокооплачиваемую работу. Но факт в том, что это путь не для большинства. И очень хорошо было бы, если человек понимал, куда этот путь ведет. А рассказать есть кому - например, @0xd34df00d
Константная ссылка на non-type-аргумент шаблона ведь не будет висячей, верно?
В C++20 — да, идентификатор non-type аргумента обязан обозначать статический объект типа const T. В C++17 было const T для классов и prvalue для не-классов.
И интуитивно я наоборот не рассчитывал бы, что под каждый non-type параметр шаблона при каждой инстанциации компилятор выделит статическую переменную.
No pain - no gain. При учебе очень полезно для понимания, что code never lies.
И чем, скажите на милость, будет полезно изучающему программирование набивать шишки на проблемах, которые являются исключительно заморочками самого C++ и больше ничего?
code never lies.
ага, в частности, при вариативности поведения кода в зависимости от компилятора и его версии (!)...
Вот именно для этого. Для понимания, что нет никакой магии и машина делает только то, что написано и ничего более, никогда. ЕСли что-то выглядит магичееским и непонятным, значит проблема леежит глубже и нужно глубже копать и дальше изучать.
Для понимания, что нет никакой магии и машина делает только то, что написано и ничего более, никогда.
А мы сюда ошибочное поведение компьютера относим? А недетерминированное (например сбои non-ECC памяти или редкие неотлаженные гонки на кристалле в сложных температурных условиях)?
Если учесть всё - то у вас получается какой-то трюизм.
А если проводить разумную границу - то далеко не факт, что C++ с его тысячестраничным стандартом и UB располагается с "разумной для изучения новичком" стороны.
При записи/чтении контроллер шины делает проверки кодов коррекции, контроллер страниц тоже делает проверки, все на всех уровнях защищаются от сбоев, поскольку они часты. Подавляющее большинство разовых сбоев редки и приводят к BSOD, что не является предметом этой статьи. В этих рамках утверждение "машина делает только то, что написано и ничего более" остается верным. И основополагающим.
Подавляющее большинство разовых сбоев редки и приводят к BSOD, что не является предметом этой статьи.
Так в этом и есть весь вопрос.
Вы можете объяснить почему грузить новичка специфичными и мало где ещё нужными аппаратными сбоями не нужно, а грузить новичка специфичными и мало где за пределами С++ нужными особенностями языка и поведения компиляторов - это прям хорошо?
Как по мне и то и то лежит за пределами "полезных при обучении новичка" навыков.
Можно и не грузить, но сразу научить, что всегда есть ответ на вопрос "Why?" из следующеего комментария. Ну и разобрать пару случаев, аж до операционных усилителей.
Да знать, что "магии нет" - это разумеется полезно (с другой стороны "цена багфикса" может оказаться и заградительной - это тоже разумно проговорить), здесь вопросов нет.
У меня вопрос только к имлицитному утверждению, что "проблемы стандарта С++ не баг, а фича, позволяющая вырастить очередное поколение программистов более закалённым к будущим сложностям".
Мне кажется, что если выкинуть отсюда С++, то то же самое время можно потратить с куда большей пользой.
проблемы стандарта С++ не баг, а фича, позволяющая вырастить очередное поколение программистов более закалённым к будущим сложностям".
именно так. А потом выходит следующая версия стандарта С++ и новая версия компилятора и свои знания выкидываешь в унитаз, потому что их нужно слишком сильно доуточнять )))
Мне кажется, что если выкинуть отсюда С++, то то же самое время можно потратить с куда большей пользой.
++ ++ ++ ++
машина делает только то, что написано и ничего более, никогда
Так это опять закидоны сишного и крестового оптимизаторов...
Так там ей и написано, "разыменуй NULL" "делай что угодно".
Вот только в понимании плюсов "делай что угодно" т.е. UB может записываться кучей подозрительно безобидных путей, образно, "адин плюс два" или "0дин плюс два" (с нулем вместо О).
Это ужасно, но это данность, пока мы не похороним Си и не выкинем легаси (вместе с половиной комитета) из плюсов
C++ действительно плохой язык для изучения ООП, ибо слишком много отвлекающих вещей, связанных с самим языком.
Ну, я ООП учил как раз по книжке Страуструпа (древней, переводной).
Но там, насколько я помню, про template ещё ничего не было.
Просили прокомментировать. Я полностью согласен с комментарием @shaykemelov от 4 января этого года, 2:53. Поработайте сначала над неймингами функций и переменных, чтобы они были логически связаны с модулем для которого рассчитаны.
Константная ссылка на non-type-аргумент шаблона ведь не будет висячей, верно?
Не читал раньше этот пример, но как бы интуитивно очевидно, что она вполне может быть висячей - ведь non-type аргумент шаблона вовсе не обязан где-то храниться со static storage duration, он может "сотворяться" прямо в процессе работы функции, особенно в случае простых литералов типа чисел или true/false путем непосредственного помещения константы в регистр, типа mov r0, #1. Поэтому интуитивно очевидно, что лайфтайм non-type template аргумента в общем случае не может превышать времени работы кишок функции.
P.S. А, впрочем, тут уже выше @mk2 ответил.
древнючий буст и весь легаси пример я конечно не хочу заводить, но `-fsanitize=address` обычно отлавливает висячие ссылки на локальные переменные.
Санитайзер я не пробовал, но в простейших случаях даже компилятор как бы намекает, что такой аргумент шаблона - это temporary:
#include <cstdio>
template<int A>
const int &foo() { return A; };
int main()
{
printf("%d\n", foo<1>());
}<source>: In instantiation of 'const int& foo() [with int A = 1]':
<source>:8:26: required from here
<source>:4:27: warning: returning reference to temporary [-Wreturn-local-addr]
4 | const int &foo() { return A; };
| ^Не все примеры тривиальные. В том коде чуть по-другому ошибка появляется.
Ну это понятно, я к тому, что компилятор даёт понять, что это temporary. Просто не всегда способен отследить дальнейшую судьбу этого temporary в силу объективных причин, такскать.
Вот бы были какие-то гарантированные способы отслеживать лайфтаймы…
Ничто не дается бесплатно. Это либо означало бы трудности ("трудности" - это еще мягко сказано) с распространением кода в бинарной форме (и стыковкой с кодом на других языках), либо превратилось бы в очередные паллеты, с переменным успехом прикрывающие дизельный генератор, как в некоторых других языках. В общем, не хочется заводить очередную итерацию данного обсуждения :) Есть языки с автоматическим отслеживанием лайфтаймов, есть с паллетами, каждый волен выбирать по вкусу.
Ну я честно говоря даже не знаю, где там вообще в мейнстримовых языках с нативными интерфейсами есть прямо вообще гарантированные способы отслеживания лайфтаймов. Взять, например, JVM - казалось бы, все круто, GC бдит... но стоит передать ссылку на объект в нативный код, который забыл вызвать NewGlobalRef и начал что-нибудь там с этим объектом делать в отдельном потоке, и все - GC прямо на ходу выдергивает коврик из-под ног и ты получаешь SIGSEGV. Swift/ObjC с ARC - то же самое, напутал с __bridge_retained/__bridge_transfer - опять коврик из-под ног выдергивается. Как только надо взаимодействовать с кодом на другом языке (или даже кодом, доступа к которому ты не имеешь), везде начинается бяда, и все гарантии тают, как с белых яблонь дым. Все это отслеживание лайфтаймов есть очередная абстракция, которая обязательно протечет в самый неожиданный момент. Я не хочу сказать, что абстракции бесполезны, но уповать на них как на панацею, что вы вот передадите в стороннюю либу ссылку, а она там не будет ее хранить, а если уж и будет, то не забудет уведомить об этом отслеживатель лайфтаймов - этого никогда нельзя гарантировать.
Вот только от постоянного удержания в уме "как коварный компилятор может сломать мой код оптимизациями и как ему в этом помешать" мозг быстро устаёт. И чем современнее компилятор — тем больше надо тратить на него усилий. А ведь ещё должны остаться силы на, собственно, изучение программирования!
В то же время можно взять для обучения другой язык с послушным компилятором, который делает ровно то что сказано. А Си изучать уже после, и с позиций абстрактной Си-машины, а не "избегания оптимизаций".
В то же время можно взять для обучения другой язык с послушным компилятором, который делает ровно то что сказано. А Си изучать уже после, и с позиций абстрактной Си-машины, а не "избегания оптимизаций".
а вот вопрос - надо ли? Уверен, что большинство разработчиков прекрасно может обойтись без знания Си... И есть такое мнение, что новым языком для системного программирования становятся Rust, а в качестве замены Си приходит Golang
Ну, лично я изучаю, хотя бы на уровне синтаксиса, все языки которые "на слуху". Хотя бы затем чтобы можно было прочитать чужой комментарий на Хабре.
А про Rust я с вами согласен.
динамическая типизация данных из-за чего может быть проблематично объяснить типы данных
динамическая, НО строгая
увы, но нет. Когда мы изучаем Си, мы изучаем особенности Си, а не особенности той платформы, на которой он работает. Просто если уж так рассуждать - надо ассемблер брать :-)
На уровне джуниора никаких особенностей Си не учат. Учат просто работу языка
С++ здесь исключительно для изучения ООП
«Я придумал термин «объектно-ориентированный», и могу сказать, что я не имел в виду С++». Алан Кэй, конференция OOPSLA, 1997.
«Я сожалею о том, что давным-давно придумал термин «объекты» для этого явления, так как его использование приводит к тому, что многие люди уделяют основное значение идее, которая не так важна, как основная. Основная идея — это обмен сообщениями». Алан Кэй
Потому да, я также считаю, что изучать С++ для Объектно-ориентированного программирования - вредно.
Хотя в школе я любил программирование и участвовал в разных олимпиадах, универ с его Си и Ассемблером напрочь отбили желание иметь с кодингом что либо общее. Только спустя пять лет, когда стал медленно перекатываться с сисадмина в ДевОпсы снова затронул программирование, но теперь уже на Golang'e. Господи, насколько это приятнее, как будто в школу вернулся с темы тёплыми воспоминаниями.
К чему это я — учить Си чтобы настрадаться на своей шкуре и набить болячки это очень, очень узкому кругу лиц подходящий совет. Кто хочет заниматься тем, что крайне больно и неприятно? В целой куче языков разбираться со своими ошибками интересно. Но не в Си. В Си ты либо знаешь, либо идёшь нафиг. Для тех кто не любит докапываться до преподавателей и одногруппников с вопросами он не подходит. Отлично подходит для мазохистов, с этим не поспоришь.
Всенепременно в первой пятёрке изучаемых языков должен быть brainfuck. Считаю его гениальным учебным тренажёром
С некоторыми моментами в статье не согласен и в целом хотелось бы отметить, что во-первых IT это не только разработка, во-вторых некоторые вещи из предложенного roadmap выглядят лишними для входа.
Свой первый домашний проект (по сути пара десятков строк на питоне, который я тогда только начал изучать) я сделал не зная ничего ни про гит, ни про SQL и базы данных. Алгоритмы тоже не пригодились, так как по сути нужно было просто собрать данные с сайта и отрисовать их на карте. Для сбора данных оказалось достаточно иметь знание HTML и представление о GET-запросах. Для отрисовки карты воспользовался онлайн-сервисом, куда было достаточно загрузить готовую таблицу с координатами. В итоге получил свой первый РЕЗУЛЬТАТ. Это было совсем не легко, но так как тема была мне интересна, то я не сдавался и с помощью гугла и stackoverflow довел дело до конца.
Да, в следующих проектах постепенно появлялись базы данных, git, какие-то классические алгоритмы, которые реализованы в библиотеках, но практика шла параллельно с теорией. В статье же предлагается в первую очередь изучить большое количество теории, прежде чем переходить к реальным действиям (pet-проекты).
во-первых IT это не только разработка
С этим я не спорю, поэтому в названии раздела есть упоминание, что это roadmap для разработчиков
Да, я предложил долгий и трудный путь. По времени он должен занять не много больше, чем какой-то разработчик_язык_программирования_курс. Много реальных результатов можно уже получить проходя курс CS50. Там очень интересные лабораторные и практические работы. Например: работа с изображениями, где нужно было применять алгоритмы фильтрации; или задание для работы с аудио дорожкой, где было необходимо с помощью кода изменить громкость. Также в курсе идет знакомство с Python + Flask, SQL, JS/HTML/CSS
Просто я предлагаю более академический(если это можно так назвать) подход. Он даст свои плоды. Многие после курсов в итоге идут изучать все эти основы, потому что на курсе людей учат пользоваться фреймворками, которые к слову рождаются и умирают быстрее чем ты успеешь ими овладеть, а фундаментальные знания будут актуальны всегда. Почему бы сразу не начать изучать их. Будет гораздо быстрая обратная связь - потянешь эту специальность или нет
В свое время у меня пришло прозрение ООП читая книжку по Java, полное руководство (вроде 6th издание). Там все очень хорошо описано для новичка.
До этого пытался С++, чуть от злости не порвал :)) Возможно Java пошла легче так как была позже.
Это вредные советы?
Спрашиваю без иронии.
Нет. Это мое видение того как прокачиваться, чтобы быть хорошим специалистом.
Буду рад услышать ваше мнение
Отлично, а Вы собственно кто, чтобы так авторитетно заявлять свое видение и какие результаты были с таким подходом ко вкату в ИТ?
Я обычный разработчик. Статья - мое видение того как можно стать разработчиком. Я взял материал из своего личного пути, потому что советовать то чего я не знаю, не собираюсь. Постарался взять некий минимум, который позволит войти в IT. Я рекомендую фундаментальные вещи, которые не изменелись с годами, чтобы потом было проще пойти в любое направление в IT. В чем-то даже есть пересечение с основными дисциплинами, которые изучают в ВУЗе на первых курсах. Просто в ВУЗе это может быть расстянуто по времени т.к. есть другие дисциплины.
Я читал много отзывов об образовательных платформах. У меня сложилось мнение, что людям как раз-таки не хватает фундаментальных знаний компьютерных наук, навыкох программирования и алгоритмического мышления, чтобы успешно закончить курс, за который они заплатили деньги. На курсе их бросают изучать фреймворки, которые рождаются и умирают быстрее чем ты их успеешь освоить.
В моем окружении есть люди, которые хотели попробовать себя в IT. Некоторые во время прохождения курса CS50 поняли: понравится им это или нет. Тем кому понравилось пошли дальше, кстати не только в back/front/mobile, но и в data science.
Хорошо, по возможности напишу, но ничего не обещаю. Последнее время занят -- строю учебный кластер kubernetes и продвигаю не менее учебный для меня стартап betspoiler.
Главное замечание -- расстановка приоритетов: изучение языков низкого уровня в начале карьеры даст такой удар по самооценке, что человек бросит айти. Проверено на личном примере, но я учил первым языком программирования хаскель.
У работодателя есть выбор:
1. Взять выпускника ВУЗа, который четыре года трудился, чтобы получить диплом. Ему в среднем 22 года. Скорее всего нет семьи, финансовые запросы еще не выросли. Он еще не зарабатывал денег, у него нет психологического барьера пойти на менее оплачиваемую работу. Многие начинают с 30к-60к рублей. Я не видел, чтобы где-то платили больше начинающему спецу, а если и платят, то скорее всего и требования будут выше.
2. Взять выпускника курса, которому за 6-12 месяцев непонятно что давали изучать. Навряд ли за такой маленький период вы обгоните выпускников ВУЗов.
Я думаю, что выбор очевиден.
Да, но не совсем. У студента есть важный недостаток — хороших на всех не хватит, а плохие, те что без стажировок или / и после крудоформозаборостроительного не факт, что лучше.
Если у вас есть возможность пойти учиться в ВУЗ, то идите. В долгосрочной перспективе вы выиграете. Помимо учебной программы, и всего того о чем я написал выше, у вас будут связи т.к. ваши одногруппники будут работать в разных компаниях, и в будущем будет гораздо проще в случае чего.
Я не уверен, насчет связей в средненьких вузах. Насчёт хороших — уверен (и проверял), и было бы наверное круто перед вхождением в IT закончить хотя бы пару курсов Физтеха / МГУ / ВШЭ. Стенфорд или Калтех было бы ещё круто закончить. Шансов примерно столько же. У нас до середины третьего курса никто не работал, и до поступления ещё год-два на подготовку тратили. Это уже не подушка безопасности нужна, а целая спальня.
Изучать будем на примере языка С++.
Странный выбор даже в сравнии с Java. Особенно с учётом, того что низкоуровневые концепции программирования к этому моменту, уже можно было объяснить на примере чистого Си.
Да, но не совсем. У студента есть важный недостаток — хороших на всех не
хватит, а плохие, те что без стажировок или / и после
крудоформозаборостроительного не факт, что лучше.
Возможно я тут слишком перетянул одеяло в одну сторону. Но весь посыл был в том, чтобы люди понимали ситуацию
Я не уверен, насчет связей в средненьких вузах. Насчёт хороших — уверен
(и проверял), и было бы наверное круто перед вхождением в IT закончить
хотя бы пару курсов Физтеха / МГУ / ВШЭ. Стенфорд или Калтех было бы ещё
круто закончить. Шансов примерно столько же. У нас до середины третьего
курса никто не работал, и до поступления ещё год-два на подготовку
тратили. Это уже не подушка безопасности нужна, а целая спальня.
Связи имеют место быть везде. Никогда не знаешь, где пригодится знакомство.
Странный выбор даже в сравнии с Java. Особенно с учётом, того что
низкоуровневые концепции программирования к этому моменту, уже можно
было объяснить на примере чистого Си.
Мне просто очень понравилась подача материала из этой книги.
Ну сильно погружаться в структуру ЭВМ тоже не стоит. Особенности работы с массивами на современных процессорах например знать стоит, а как объект в оперативную память ложится или как контроллер на физ носителе работает- ну это мелочи жизни для разработчика
Алгоритмы базовые знать надо, но чаще всего сейчас какие то крутые алгоритмы не нужны, так как большинство проектов сводится к конвертированию данных из одного типа в другой, там больших мозгов не надо)
Мало кто из свитчеров пойдёт по настолько сложному пути. Вообще, у Столярова есть отличные книги. Обучение начинается с паскаля, а не с си, что на мой взгляд правильно.
Мало кто из свитчеров пойдёт по настолько сложному пути.
Из альтернатив я мало что вижу, потому что у меня как-то само собой всё сложилось.
Сейчас есть куча платформ, где за 6-12 месяцев можно стать "разработчиком". Люди в итоге тратят много денег и времени на эти курсы. Хотя можно все необходимые знания для страта получить бесплатно. Возможно эта их пробелма, что они поддаются агресивной рекламе. Я решил не проходить мимо и предложить иной путь. Возможно он займет болше времени и сил, но он гораздо раньше даст понять, что получится освоить специальность или нет. На курсах ведь многое в лабораторных условиях, чтобы как можно дольше удерживать людей и выкачать как можно больше денег из них.
Вообще, у Столярова есть отличные книги. Обучение начинается с паскаля, а не с си, что на мой взгляд правильно.
Думал насчет Pascal, но решил что уже не стоит. В 7 (2010 год) классе нам уже преподавали на C++. Мы не использовали классы, namespaces, а для ввода/вывода использовали cin/cout, что в принципе выглядит почти как Си. Решил, что тогда лучше сразу с Си начинать. К тому уже был знаком с книгой Прата и был уверен в том, что рекомендовать.
Взять выпускника ВУЗа
Выпускников не хватает, поэтому и появились разные курсы.
Выпускники курсов конкурируют с выпускниками курсов, если только студент в ВУЗе халяву не гонял
Да, выпускников не хватает. Специалисты уезжает за границу. Я считаю, что курсы еще не достигли того уровня, чтобы готовить специалистов, которые смогут сразу войти в промышленную разработку. Конечно, если у них есть такая цель, сейчас я вижу, что просто происходит высасывание денег
Халявщики в ВУЗе будут всегда. Однако есть и не халявщики, которые каждый год все-таки занимают рабочие места. Каждый год их должно становиться больше, учитывая отток из специалиство из стран СНГ
Я считаю, что курсы еще не достигли того уровня, чтобы готовить специалистов, которые смогут сразу войти в промышленную раразработку
Не сразу это как?
Если речь про стажировку, то она и вчерашнему студенту нужна.
Для Джуна много знаний не надо, на курсах их можно получить при желании. Вся разница что в вузе дают базу с которой легче прогрессировать.
Смотря на отзывы об онлайн курсах, я склоняюсь к мнению, что они были созданы исключительно для заработка на людях. Возможно единицы как-то вывозят курсы, кому-то помогает какой-то бэкграунд из прошлого, у кого-то есть знакомые, которые им как-то могут помочь. Остальные просто отсеиваются.
Не сразу это как?
Это пройти собес на позицию junior разработчика. В рекламе курсов ведь так пишут. А про цель нынешних курсов я уже писал.
Для Джуна много знаний не надо, на курсах их можно получить при
желании. Вся разница что в вузе дают базу с которой легче
прогрессировать.
Много не надо. Вот я и сделал roadmap(очень похож на ВУЗовскую программу) для этого. Считаю это необходимым минимум для джуниора.
Это пройти собес на позицию junior разработчика. В рекламе курсов ведь так пишут.
Если человек - идиот, то это надолго.
Если кто то думает, что его возьмут без собеседования, то ему и в дворники не попасть. Лично мой опыт курсов для вайтишников, таких людей - идиотов очень мало.
Заканчивают курсы действительно не многие, просто бросают, и из тех кто закончил - не все находят работу. Бэкграунд у устроившихся разный, основное это мотивация.
Думаю, новичкам надо начинать с Питона, можно делать почти всё и сразу.
Смешно конечно, что Яндекс собирается учить курьеров на программистов. Сам 25 лет в IT, ВУЗ по специальности, и понимаю что так мало знаю, это путь бесконечного обучения, что не каждому дано. Смотрю на выгорающих людей и понимаю, что это нелёгкие деньги.
С чего автор решил, что кроме тяжелейших вузов спб и мск, которые выпускают очень ограниченное количество студентов, в остальных учат хотя бы 1/10 того, что он себе выдумал?
С другой стороны программирование дейстительно многогранно, но комплекс знаний, не даст ни вуз ни курсы, они лишь обозначат примерный вектор. Только личное желание учиться и развиваться приведет к результату.
А вот лишний мусор и излишек знаний, - ни к чему. База, потом кодить и узнавать уже по мере недостатка знаний нужное, - быстрейший путь. Слишком быстро устаревают знания, чтобы изучать их впрок без надобности
С чего автор решил, что кроме тяжелейших вузов спб и мск, которые
выпускают очень ограниченное количество студентов, в остальных учат
хотя бы 1/10 того, что он себе выдумал?
Я учился в УрФУ, по специальности информатика и вычислительная техника и у меня было это всё в программе.
А вот лишний мусор и излишек знаний, - ни к чему. База, потом кодить и
узнавать уже по мере недостатка знаний нужное, - быстрейший путь.
Слишком быстро устаревают знания, чтобы изучать их впрок без надобности
А что устарело из того, что я предложил? Си, С++, Java, алгоритмы, архитектура ЭВМ, паттерны проектирования, техники чистого кода? Я старался дать список того, что даст фундаментальные знания для того, чтобы можно было уверенно войти в IT
Слишком быстро устаревают знания, чтобы изучать их впрок без надобности
не соглашусь. И тут я солидарен с автором статьи, что есть фундаментальные знания (указатели, O-нотация, базовые алгоритмы, основные парадигмы построения ПО и пр.), которые и нужно изучать, и так или иначе они пригодятся всегда, и прикладные - вроде знания конкретного фреймворка. Вот именно последние и устаревают. В частности, если речь идет о фронт-энд разработке )))
С чего автор решил, что кроме тяжелейших вузов спб и мск, которые выпускают очень ограниченное количество студентов, в остальных учат хотя бы 1/10 того, что он себе выдумал?
Это не "он себе выдумал", а стандартная программа высшего образования для программиста. Астраханский государственный технический университет - вроде не "тяжелейший вуз", а программа такая же. Это же стандарт.
Обращение к тем, кто идет ради денег. Есть множество других способов их заработать. В IT есть потолок по зарплате, а достичь его не просто.
А не в IT потолка нет что ли ? Просто часто, стартовая/средняя зп в IT - это потолок в других профессиях/отрослях
Насчет сложности - все очень относительно
Я решил сменить профессию. Я пытался попасть в IT. Когда я обратился в Центр занятости,то мне предложили отучиться на бесплатных курсах:
-швея
-водитель
-системный администратор
Город миллионник все же. В Москве программа значительно шире и велики шансы на успех. Около 80 образовательных программ.
Выбор был невелик и я поступил на курсы системного администратора.
Завлекали как могли на эти курсы так как осваивание государственных многомиллионных выплат образовательным учреждениям никто не отменял. Где то около 200 млн. с копейками выделено на эти курсы.
Чтобы войти в IT,небходимо хотя бы начать с английского языка,а язык программирования сделать своим хобби.
В регионах достаточно сложно моневрировать хотя бы потому что швея на рынке труда ценится гораздо больше чем it специалист.
Выбор был невелик и я поступил на курсы системного администратора
Не очень удачный выбор для вхождения в ИТ. А точнее очень не удачный, имхо. Говорю, как бывший сисадмин с 15 годами опыта )))
А можете немного развернуть свой ответ? Почему прям очень неудачный выбор?
А можете немного развернуть свой ответ? Почему прям очень неудачный выбор?
Слишком много надо знать, слишком много обязанностей, слишком много ответственности, слишком много нервов при относительно маленькой зп. Сужу лишь по своему личному опыту, когда 6 лет назад переходил из сисадмина в devops инженера.
На тот момент в подчинении было порядка 50 серверов и локальная сеть на 400 пользователей + по мелочи зарубежные офисы. В т.н. IT отделе было два человека - я и мой помощник.
В большинстве случаев - не благодарная работа, а если еще и не IT компания, то будет совсем грустно
Возможно, если вам повезло и вы прям пропали в IT-IT компанию, а еще у вас есть наставник, который обучает - то как старт очень даже ничего, через пару лет можно смело уходить в devops ;) Но в далеком 2000м, когда я только начинал о таком и мечтать даже нельзя было
Конкурировать с выпускниками вуза? Выпускники вуза если все 100% пойдут в программирование не покроют и 10% потребности в программистах. И не всем нужны уберпрограммисты, кому то надо и формы шлепать и прочее.
Конкурировать с выпускниками вуза?
Да, так и есть сейчас
Выпускники вуза если все 100% пойдут в программирование не покроют и 10% потребности в программистах.
Предположим, что про 10% это правда. Считаете причиной этому является появление большое количество онлайн плафторм с курсами, которые смогут закрыть нехватку кадров? Я вот считаю, что они созданы инфоцыганями, чтобы высосать как можно больше денег из людей.
И не всем нужны уберпрограммисты, кому то надо и формы шлепать и прочее.
Выпускники меда тоже не покрывают все потребности. Ко многим узким специалистам очень большая очередь. Я бы не хотел, чтобы кто-то закончил онлайн курс терапевт_за_6_месяцев и потом лечил меня, даже поставить банально укол или взять анализы крови. Я бы не хотел жить в доме, который проектировал человек с курсов архитектор_за_6_месяцев. Люди сами понимают, что это сложные и ответственные профессии и никому в голову не придет(я очень надеюсь) идти на такие курсы. Почему тогда можно создать поток неквалифицированных IT-специалистов? Вы считаете, что в этой профессии меньше ответственности?
Откуда такое пренебрежение к работе связанное с фронтедом? Вы считаете, что они не должны быть квалифицированными специалистами? Потом мы жалуемся, что веб тормозит
Тормозная страничка может раздражать тысячи людей каждый день. Например, они вынуждены заходить на нее по разным причинам. Можно отнести это к приченению массового вреда здоровью. Может даже есть исследования на эту тему.
Тормозная страничка может привести к тому, что клиент уйдет пользоваться другим продуктом. продажи компании упадут, в итоге может произойти сокращение целой команды
Сейчас автоматизируют практически всё к чему притрагиваются. Фронт страничка на форме заполнения платжного поручения может подвиснуть в ненужный момент и отправить не те данные для денежного перевода
А страничка стала тормозной не сразу, а постепенно. В итоге чтобы исправить ошибку придется переделывать все с нуля. А это может в итоге вылиться в еще большие траты, чем если бы сразу нанять хорошего специалиста
Наверное никому не хочется работать в одной команде с человеком за которым нужно переделывать работу. Да и самому человеку скорее всего будет неприятно.
Чтобы тормозила не сильнее чем у прямых конкурентов — это да. Но конкуренты точно так же сэкономили и наняли выпускников заборостроительного техникума, так что планка очень низко.
" ущерб от неквалифицированной работы ниже доплаты за квалификацию "
однако почему то есть огромный дисбаланс - за миддлов бизнес готов платить по 200+, а вот джуны борятся за зарплату условно 30-50к, многие не выдерживают идут в тот же макдоналдс или ещё куда где такие же условия по оплате. Но всё равно джунов слишком много и НИКТО особо не хочет их учить, для бизнеса получается ДЕШЕВЛЕ нанять "специалиста" за 200к. Просто потому что денег много в стране, а вот качественно их распределить видимо у многих не получается
глупости пишите. Те кто IT заканчивает далеко не все идут туда. Насколько покроют тут сложно сказать, с одной стороны джуны никому не нужны, а всем нужны миддлы, которых не хватает. Если это элитный вуз то думаю процентов 90% пойдут, 10-15% это те кто серьёзно заболеет, сменит область деятельности под влиянием родственников, уйдёт в бизнес. Если говорить про обычный вуз, дай бог 60% пойдёт в программисты из них треть будет работать в не очень эффективных конторках условно, по крайней мере раньше так было. Всякие подвальчики с ксероксами, мелкие офисы и прочее. Опять же потому что вряд ли учат в вузе поиску работы. Не все даже поймут что устроились "не туда". Или даже если туда, может быть не самое лучшее отделение сбербанка, газпрома, и прочее, это будет двухэтажное маленькое здание где то рядом с огромным офисом, по иронии судьбы, не у всех, но часто бывает и как мейнтримно попасть в большой офис с хорошими условиями мало кто расскажет.
А само изучение языка в какой момент наступает, или это следует отнести в "невошедшее"?
А что вы подразумеваете под изучением языка? Навыки программирования начинают развиваться с амого начала курса CS50. В книгах есть лекционный материал с упражнениями, выполнение которых также развивает навыки программирования. Задачи по программирования развивают алгоритмическое мышление. Остальное это теоретический computer science, либо необходимые навыки, которые пригодятся после.
Великолепная статья!
Может не идеально, но объясняет и то, почему не у всех получается в ит и где тут сложности, и то, какая последовательность действий нужна для образования.
Я формулировал нечто подобное, но теперь есть хорошая ссылка.
Курсы иногда бывают лучше чем высшее образование. У меня вот есть высшее - но никто не учил меня устраиваться на работу. У программистов же в первую очередь спрашивают навыки, а не то что они заканчивали. И то курсы пока не довели меня до результата, но по результатам других, я вижу что очень многие устраиваются на 200+.
Те же алгоритмы невозможно запомнить, они забудутся, а на работе мало где требуется - а для собесов достаточно просто освежить знания либо просто мелком прочитать про бинарные деревья. И далеко не везде они нужны. Опять же в библиотеках всё реализовано.
По ссылкам согласен плюс на время обучения можно потратить на чтение книжек... И да есть и психологическое и реальное давление. Когда учишь сам, окружащие, особенно близкие во многих случаях будут думать что ты ничем не занят по сравнению с тем если учишься. Работа тоже может мешать сконцентрироваться на том, кем действительно хочешь стать.
Курсы иногда бывают лучше чем высшее образование.
Возможно. Но многое всегда зависит от человека и его бэкграунда. Многие истории успеха не показывают важные ключевые моменты.
Те же алгоритмы невозможно запомнить, они забудутся
Их нужно понимать. Любая программа - алгоритм.
на работе мало где требуется
Это имеет место быть. Все зависит от сферы деятельности. Мне лично пригождались пару раз. Но это не значит, что их не нужно изучать. Придет момент, когда для решения задачи будет полезно воспользоваться хотя бы классическим алгоритмом. Человек, который изучал его, увидиет, что его можно здесь применить. Это как с математикой - не знаешь, когда она пригодится
для собесов достаточно просто освежить знания либо просто мелком прочитать про бинарные деревья.
Это смотря в какую компанию собеседование проходит
И далеко не везде они нужны. Опять же в библиотеках всё реализовано.
Чтобы уметь пользоваться, нужно понимать как они работают. Взгляните на веб, который задыхается от тонный фреймворков. У меня есть пример из жизни, когда один разработчик затащил в проект целую библиотеку для решения одной проблемы. Пришел другой разработчик, удалил библиотеку и решил проблему в пару строчек кода. Первый разработчик не знал алгоритмов для работы с изображениями, второй знал. Это все было в мобильной разработке при работе с QR кодами. Кстати в той же мобильной разработке полезно знать алгоритмы и структуры данных, добиваться производительности кода, чтобы не разряжать батарейку пользователю.
От программиста требуется не тупо вызубрить алгоритмы, а умение на ходу составить свой алгоритм решающий задачу поставленную в ТЗ.
Ну да ну да, а потом получаем такие гениальные решение, придуманные на ходу
От программиста требуется не тупо вызубрить алгоритмы, а умение на ходу составить свой алгоритм решающий задачу поставленную в ТЗ
В ТЗ будет написано - написать генератор случайных чисел, так что формально алогритм на картинке подходит под ТЗ )))
В ТЗ будут требования к ГСЧ. Если их не будет - тогда правильным решением будет использование библиотечной функции. Кстати, формально, приведённый код - крайний случай ГСЧ, когда случайность отсутствует (и хорошая стартовая точка для написания ГСЧ по методике TDD).
А скриншот - это, похоже, гиперболизированная пародия на код, который приписывают выходцам из одного полуострова на южной стороне Евразии. Кстати, думаю, скоро и у нас появится заметное количество людей, которые пишут такой код, т.к. складываются условия, похожие на те, что привели к появлению этого явления там. И я пример такого кода видел, когда нанятый на неплохую з/п реакт-разработчик (кстати, уже звоночек) вместо динамической погрузки компонент, написал более 30 if-ов с их созданием.
Курсы иногда бывают лучше чем высшее образование.
По какому критерию? «Зарплата через месяц после выпуска»?
это не критерий? Я плохой пример, но знаю кто после курсов устраивается на 200+. А после вуза человек, если "не в теме" то есть не понимает рынка, то устраивается в 3, 4, 5 раз ниже рынка и его работодатель тупо использует. То же самое работодатели жалуются, что "специалисты" мало что могут - только пройти собеседования, с другой стороны легко предложут далеко не валидную рынку зарплату и будут пользоваться человеком - так как он когда входит этого не знает
Нет универсального пути в IT. Встречала на своем пути множество разных историй, ребята из иняза, с химфака, даже с консерваторией в анамнезе успешно пишут код. Если обьективно есть знания и желание, и при этом не гнешь пальцы, требуя условные 100+ с самого старта, то и конкурировать со студентами не придется: большинство работодателей просто возьмут всех, ибо спрос на разработчиков сильно превышает предложение.
Я бы сказал, что есть проверенные пути. Многое зависит от самого человека
Знаю нескольких выпускников с химфака, ушедших в IT после выпуска (сам почти такой же). Все они сильно интересовались этой темой еще до окончания вуза (кто-то еще со школы) и уже после выпуска были вполне готовы к тому, чтобы заниматься коммерческой разработкой. Весьма вероятно, что это примеры неудачного выбора факультета из нескольких вариантов, либо сменившиеся интересы в жизни: не всем дано понять в подростковом возрасте, чем из нескольких интересных занятий он. Готовы заниматься и дальше.
метко сказал, я даже не понял :) потому у нас по сути конкуренция среди джунов и зарплат в 30к выше, чем среди зарплат 150к.
Сам начинал с программируемого калькулятора мк-62. Сейчас смотрю что можно посоветовать детям для доВУЗовского образования. К сожалению ничего основательного нет. Везде рисуем сову :-(
Было бы здорово на Хабре завести раздел где уставшие от тупых джунов синьеры и тимлиды набросают тем для изучения с нуля именно базовых вещей, а не "как работает сборка мусора в с#" или "чем сланг хуже жсс". А потом каждый сможет добавить "лекций" и заданий для закрепления на любимом языке, можно даже соревнование устроить. В идеале чтобы темы были языконезависимыми, что позволит учить несколько языков одновременно читая лекции написанные разными людьми.
А потом можно будет сказать - прошел обучение на Хабре - и все, техническое собеседование не нужно.
Я бы посоветовал новичкам покрутить что-то наподобии Wordpress. И если он будет казаться космосом, вызывать кучу сложностей и депресии - то бежать от айти подальше в понятную среду и не ломать себе голову.
Я вспомнил как давным-давно локально поднимал денвер и dle). У моего интернет провайдера была локальная сеть по городу. Люди поднимали свои сервера для разных вещей, даже был свой торрент трекер
Раньше во времена лимитных интернетов в каждом регионе у каждого провайдера были энтузиасты, которые держали сервера линейки, вов, торренты, локальные чаты, сайты и т. д.
И никакого ИТ-образования у них не было, разумеется.
Ну они и не ходили на онлайн курсы, а изучали все сами, что я и предлагаю делать. В то время было куча инструкций на разных форумах. Просто нужно было уметь пользоваться поиском и мозгами.
сейчас уже более 10 лет, как интернет развивается в сторону поощрения потребления контента. В таком окружении надо быть очень мотивированным, чтобы, вместо потребления контента, пойти разбираться. И IT-гиганты, прикладывающие усилия к тому, чтобы интернет был доступен и интересен каждой домохозяйке, заодно уменьшают количество тех, кто пойдёт чтото изучать по форумам, инструкциям и т.п. источникам. Как итог - думаю, в дальнейшем будет гораздо меньше вайтишников, которые туда идут не только за длинным рублём.
В целом со статьёй согласен, но не согласен с выбором конкрентых начальных языков.
В начале надо учить условия, циклыб процедурыб функции и т.д. А это можно делать почти на любом языке. Так что тот же питон или паскаль вполне сойдут. Кто-то на Го начинал учиться и ничего. ООП учить тоже можно на разных языках. Та же Джава, например.
Чего не увидел, так это то, специализации: фронт, бек, ембед, мобайл и т.д. Для выбора провессии это важно и будет влиять на то, что учить дальше.
Как раз таки на Python этого делать не рекомендую. Много всего язык скрывает под капотом. Эта магия вредит при изучении основ программирования.
На Си как раз-таки лучше всего можно показать как работать с типами данных, памятью. Книги предложенные мною ограждают читателей от трудностей с которыми сталкиваются профессиональные программисты, но в то же время дают достаточно знаний и понимания того как устроены многие вещи.
Выше есть большой топик на тему того, что С++ нужно выбросить, что там куча неопределенного поведения, нужно разбираться как работает компилятор и тд. Я скажу, что нет не нужно. Книга расчитана на новичков, она просто не дает материал такой, упражнения ограничены этим материалом.
Чего не увидел, так это то, специализации: фронт, бек, ембед, мобайл и
т.д. Для выбора провессии это важно и будет влиять на то, что учить
дальше.
Это выходит за рамки того, что я хотел. Я старался дать материал для изучения фундаментальных вещей, знаний, которые будут применимы во всех областях.
фронт - фреймворки рождаются и умирают каждый день. Это лишь забьет голову ненужными вещами. Курс CS50 дает достаточно знаний JS/HTML/CSS. Чтобы понять что такое front
back - тоже много всего. java, c#, php, go, python + нужно изучать разные фреймворки. Курс CS50 дает возможность поработать на уровне бэка через python и flask. Дается возможность понять что такое back.
embed - я им не занимался и не могу чего-либо предложить. Мне кажется, что это не для новичков т.к. скорее всего нужно будет изучать больше чем обычно
mobile - придется поискать материал самостоятельно. благо тут выбор не велик. iOS - swift, objective c. Android - kotlin/java. Есть еще flutter и react native. Но опять же я не занимался этими вещами достаточно, чтобы дать материал в котором я буду уверен.
При выборе направлений и стека лучше отталкиваться от доступных вакансий. Где-то может преобладать Java, где-то C++ и тд. Поэтому дать что-то одно, чтобы всем заехало трудно
При выборе направлений и стека лучше отталкиваться от доступных
вакансий. Где-то может преобладать Java, где-то C++ и тд. Поэтому дать
что-то одно, чтобы всем заехало трудно
Вот что-то такое я и хотел бы видеть в статье. Ну то есть, если ты хочешь зарабатывать деньги программированием, то на каком-то этапе надо представлять, как именно это делается и какие есть особенности. Да хотя бы в языках программирования.
Как раз таки на Python этого делать не рекомендую. Много всего язык скрывает под капотом. Эта магия вредит при изучении основ программирования.
На Си как раз-таки лучше всего можно показать как работать с типами данных, памятью.
Шутка только в том, что с памятью им работать и не понадобится скорее всего. А типами данных заморачиваются в функциональных языках, что вообще отдельная песня и не для каждого новичка подходит, так сказать.
Питон. Мне вот сложно сказать, насколько он подходит для первого языка, у меня был Паскаль. Но интуитивно это хороший язык для обучения. Не вижу проблемы в магии. Да, нет типов, зато мультипарадигменный, на нём можно много разных концепций учить - удобно. Плюс синтаксис прост и понятен. Соглашуть разве что в том, что программу обучения надо выбирать аккуратно.
Да и не Питоном единым, есть специализированные языки обучения. АВС вроде как называется.
В общем, не надо так уж сильно полагаться на типы данных и подкапотную работу, не в ней дело.
Вот что-то такое я и хотел бы видеть в статье. Ну то есть, если ты
хочешь зарабатывать деньги программированием, то на каком-то этапе надо
представлять, как именно это делается и какие есть особенности. Да хотя
бы в языках программирования.
Уже лет пять использую Java для промышленной backebd разработки. Мой выбор скорее всего был бы предвзятым. Я скажу, что работы на Java много, проекты интересные и тд. Я этого не хочу. Я лучше предложу минимум, чтобы можно было потом самостоятельно выбрать.
Питон. Мне вот сложно сказать, насколько он подходит для первого языка, у меня был Паскаль. Но интуитивно это хороший язык для обучения. Не вижу проблемы в магии. Да, нет типов, зато мультипарадигменный, на нём можно много разных концепций учить - удобно. Плюс синтаксис прост и понятен. Соглашуть разве что в том, что программу обучения надо выбирать аккуратно.
Да и не Питоном единым, есть специализированные языки обучения. АВС вроде как называется.
В общем, не надо так уж сильно полагаться на типы данных и подкапотную работу, не в ней дело.
Каждый по разному начинал. У меня был путь через С++/С/Java и естественно я буду проталкивать его как проверенный. Многим Python становится интуитвно понятным после другого С-подобного языка и им кажется, что Python идеально подходит для новичков т.к. он простой. Он простой для вас, потому что вы понимаете как внутри устроены циклы, что такое типизация данных, как работает синтаксических сахар и тд. На Pascal тоже многие научились программировать, вроде как этот язык специально созавался для этого. Мне кажется, что изучение через Си не хуже.
embed — я им не занимался и не могу чего-либо предложить. Мне кажется, что это не для новичков т.к. скорее всего нужно будет изучать больше чем обычно
MicroPython — очень дружественный к новичкам; а восторг от робота, ползающего по комнате по твоей программе, намного сильнее, чем от пикселей на мониторе.
Ъ! Страшно-то как, если бы я сейчас надумал пойти в айти и вот это вот всё прочёл и принял на веру, то, наверное, даже не передумал бы, а сразу со страху помер. Это какой-то путь самурая, у которого нет цели, а есть только сам путь))) C, C++, алгоритмы, компиляторы, типы, абстракции, полиморфирзмы, Гиты, кубернетесы-шмубернетесы... Хотите войти в айти легко и быстро - забудьте, забейте, по крайнее мере до лучших времён! Так и быть... Открою секрет, 2 буквы (почти 3 карррты)) - 1С. Всего 3 книжки, 1 официальный сайт, 1 форум, всё по-русски (можно и не по-русски, на любителя, если есть желание поработать во Вьетнаме), 1 библиотека, 3 ступени подтверждения квалификации от 1С (по факту до 3й доходят единицы, но и со второй можно жить). И рынок достаточно ёмкий на просторах бывшего сэсэсэра. Да, есть нюанс: средняя з/п ощутимо пониже, а потолок кратно меньше, чем у разраба с таким бэкграундом, как у автора статьи, но по-любому ощутимо выше, чем там, откуда в айти уходят. Ну, а уже из 1С можно и на другие языки посматривать, всякие интеграции пилить, скилы прокачивать.
Да закидают меня тапками трушные программисты, но 1С - тоже айти)))
Как войти в IT?