Лучший способ обучения?

brainick: что я там увижу?

AlikDex: Увидите прогресс. )) если подойдете к обучению серьезно

вам будет стыдно за свой код

Neonoviiwolf: чего стыдится? Новичек же, учишься. В целом, с некоторого момента все равно достигнешь своего потолка и выработается определенный стиль. Стыдится будет уже нечего.

Кстати, до сих пор помню как первые программки начал писать еще на бейсике на 286 процессорах ;D
Жаль не сохранилось... было бы круто глянуть свои первые потуги по созданию игрушки ))) Стыдился бы? Врятле, скорее умилялся.

brainick: не знаю как вы, а я пишу комментарии в местах, где может быть не понятно со временем. Они ведь для этого и придуманы, верно?

Есть "История информатики".

т.е. в этой книге описаны фундаментальные понятия?

maksjuk11: часть понятий. Представление информации в компьютере и т.д. (типа особенности вычислений с float и т.д.) - это просто информатика и это просто надо знать всем, чья работа связана с вычислительной техникой.

А приведенная книга, это очень хорошо структурированный материал который с большего покрывает все. Задает основы. Вводит основные понятия. Главное отличие оной книги от большинства других - порядок, в котором выдается информация, он логичен. От простого к сложному. От общего к частному. Вообще это считается чуть ли не самой лучшей книгой по этой теме. Даже то что первая редакция вышла в 80-х не меняет ее актуальности сегодня.

Большая же часть книг выпущенных после 2000-ого года учат контроллеры фигачить, на этом далеко не уедешь и понимания вещей не получишь.

AVKor: Вы не могли бы сообщить авторов книги "История информатики"? Поиском найти эту книгу не получается.

Lkrasnov: Я не книгу имел в виду. Это университетский курс, который я читал студентам пару раз лет 12-13 назад.

Никаких практически книг тогда найти не получилось, собирал материл там-сям.

На русском не уверен, что вообще книги появились, на английском видел, что уже имеется.

Понятно, спасибо. На английском какие бы книги порекомендовали (которые покрывают курс истории информатици)?

Ну почему. Есть в ВУЗах нечто похожее на то, о чем вы говорите, хотя и называется другими словами.
Я оканчивала МАИ.
И программирование было все курсы и по несколько предметов с разными наименованиями.
Основы вычислительных комплексов и сетей, потом базы данных и распределенные вычислительные системы и т.д. и т.п.
Начинали мы с машин Тьюринга и алгоритмов Маркова.
Потом - pascal на Linux
Оканчивали на тот момент С# и Oracle по части баз данных.

И похожее образование в плане программирования в МГУ и физтехе.

Арина Григорьева: не знаю... у меня как бы тоже вроде бы все было неплохо, у меня был довольно хороший курс по сетям, история железа именно, типа там эволюция архитектуры микропроцессоров - прекрасно давали этот материал. И базы данных были, и C#, и компиляторы/интерпритаторы свои писали.
Системное программирование, алгоритмизация, к этому притензий у меня лично нет. Но...

При изучении скажем ООП даже не пытались объяснять что такое полиморфизм... Про SOLID рассказывали на 4-ом курсе внезапно на курсе лекций по сетям... и так, мельком, просто между делом. Тестирование - это уже была магистратура и я к тому времени уже 4 года как практиковал TDD.

Сергей Протько: Ну тут согласна. ООП и паттерны были, конечно, где-то так на старших курсах, но в духе "Вот эту книгу почитайте" и напишите лабу с отрисовкой геометрических фигур И всё. Надо сказать, ООП в полной мере не догоняю и до сих пор. Также сложно далось и понимание таких вещей как лисп и иже с ним. Хотя там преподаватель был поответственнее и старался. И вроде в теории всё просто. Впрочем, как и ООП - всего то 3-4 принципа ;-)

Арина Григорьева: нет, паттерны как раз и были, а вот принципы из которых эти паттрерны выводятся - этого как раз и нет. Паттерны это не важно, важны принципы.

А раскрыть суть идеи о том что объекты изолируют состояние и побочные эффекты, что такое состояние и побочные эффекты... и если это все понимать, то все становится намного логичнее. Что полиморфизм - это теория типов и никакого отношения непосредственно к ООП не имеет. И инкапсуляция это не "фича" ооп, в Си например тоже была инкапсуляция, и все было ок. В javascript например многих смущает отсутствие модификаторов доступа, и потому говорят что там недо-ооп и нет инкапсуляции, а то что сокрытие состояния там достигается за счет модулей - не, не слышали. Ну я думаю вы поняли мой основной посыл. ООП - это сокрытие побочных эффектов, декомпозиция системы и управление зависимостями. Идеальный компромис между функциональными и структурным программированием.

И да, принципов там побольше, но по сути они не привязаны конкретно к ООП. Тут больше здравого смысла.

Сергей, кстати хорошие вещи пишите.
Мне кажется (может, я ошибаюсь), что просто в вузах нет (ну или не было) специалистов, разбирающихся в данном вопросе.
Да, действительно, много старой школы, процедурного программирования, интерпертаторов и компиляторов, основ алгоритмизации - вот там нам могли показывать и рассказывать часами - поиск в дереве, стек, списки, индексация в массиве....
Круто, конечно, только мало кому сейчас нужно.

Арина Григорьева: не, это нужно, и никогда не знаешь когда столкнешься с такими задачами. Просто нужно еще объяснять про то откуда баги берутся, экономическая эффективность разработки и т.д. А то народ из ВУЗов выходит и думают что им за код платить будут.

...кстати про тестирование, QA в ВУЗе нам вообще ничего не говорили...и даже близко не было поползновений писать тесты к своим лабам, например.
...что-то мы куда-то далеко уплыли.

Возвращаясь к вашей идее о предмете истории программирования в вузах и о проблеме отсутствия фундаментальных знаний - а оно надо?...реально...по факту...сегодняшнему молодому разработчику...которому итак выше крыше приходится осваивать технологий, фишек, фреймворков и библиотек... оно вот это всё зачем?
Об этом сейчас много споров, да. Надо ли, например, водителю такси понимать устройство автомобиля и уметь чинить его...или лучше пусть он хорошо ориентируется в приложениях с картами и расписаниями вокзалов? Да и вообще...вон, уже каршеринг развивается, а японцы внедряют автомобили-беспилотники.
Наверное, вопрос в том, где быть таксистом - в мегаполисе или на переферии.
Так и с программированием - что бы там, к примеру, мистер Греф ни говорил, а гугл, амазон и сбербанк - совершенно разные компании... и странно с ними равняться в сфере it.

Арина Григорьева: суть в том, что координально нового в программировании небыло уже лет 30. А стало быть все эти "новые штуки" это всего-лишь видоизменение очень старых идей. Если человек будет понимать примерный ход мысли как мы пришли к такому или к такому решению - то проблем добавить еще десяток новых однотипных фреймворков я не вижу. Да и небыло бы их столько если бы народ знал что они просто переизобретают колесо.

Короче я сторонник идеи что разработчик должен знать как оно что устроено хотя бы на один слой абстракции ниже того с чем ему приходится работать.

Ну и да, сравнивать таксиста и программиста несколько некорректно. Это все же инженерная специальность. Или хотите сказать что архитекторы проэектирующие здание не должны знать нюансов работы с материалами, из которых в конце концов будут дома строить? Или там аэродинамику не надо учитывать и т.д.

Ну так архитекторам их архитектурные пакеты и рассчитают и аэродинамику, и устойчивость, используя библиотеки свойств для каждого материала.
Да, фреймворки - всего лишь инструменты.
И мне вот как-то понравилась статья на хабре, где человек трудоустраивался на Кипр программистом и на собеседовании ему дали только компилятор. Пиши код в блокноте.

Только вот сколько времени в среднем занимает подготовка такого специалиста ? И сколько таких спецов потянет бюджет компаний?

Арина Григорьева: архитектурные пакеты - это хорошо, но от того что архитектору нужно все это знать что посчитать и т.д. объем знаний не уменьшается, уменьшаются трудозатраты. Скажем инсоляцию посчитать и т.д. - нужно уже знать зачем это надо и т.д.

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

Что до бюджета компаний... Ситуация не сильно поменяется, наоборот ЗП выравляются. Сейчас у нас ситуация такая что есть 90% дешевых и средних разработчиков, которые так себе разработчики, и 10% сильных и дорогих. Если же уровень разработчика хоть немного выровняется, выровняются и ЗП. Правила рынка труда. Если больше шансов заменить сотрудника, его ценность на рынке падает. А стало быть никаких проблем.

Ну и опять же, я знаю слишком много примеров когда джуниоров продавали по стоимости синьеров и т.д. Вы бы согласились работать с человеком у которого год опыта коммерческой разработки над своим продуктом?

Я бы согласилась в следующих случаях:
1. Проект большой и нужно очень много рук.
2. Он идет джуниором ну на крайняк мидлом под опеку "проверенного" человека.

Арина Григорьева:

1. если это так, то там скорее всего микросервисы и все такое а значит есть хотя бы парочка дорогих синьеров которые будут следить за всем.

2. У нас есть синьер который будет следить.

А что у нас на рынке фриланса? Нет синьеров. Народ не учится, за ними не следят. В целом это общая проблема индустрии. Даже в небольших компаниях может просто не найтись человека который бы в должной мере менторил людей. Я это наблюдаю в половине компаний Минска когда люди просто не развиваются и не знают как.

И ладно бы такие разработчики загубили просто чей-нибудь "стартап" и кто-то просто деньги потерял. Если бы вы знали насколько стремные вещи используются в крупных индустриях, типа медицины, или аэро-перевозки... вам бы стало страшно.

ну а что делать.... сами знаете, как оно в целом на рынке труда. Только в IT похоже и платят еще на поссоветском пространстве. Кто-то ищет быстрый способ обогащения, кто-то -просто стабильную работу, но таких вот айтишников...увлеченных...да, всё меньше. И дело даже не в образовании. Интересно, если бы зарплата в IT сейчас приравнялась к зарплате врачей, учителей...какой бы процент остался в профессии?
Кстати...что там софт медицинский...к самим врачам ходить не страшно разве?

Сергей Протько: так, а что за книгу вы нашли (написанная в 80-х) ?
Основы информатики и вычислительной техники, она?

mbcsoft: "Структура и интерпритация компьютерных программ".

Сергей Протько: Какие важные книги вы еще посоветуете которые важно знать как и Структура и интерпритация компьютерных программ .И тому подобные который очень важно знать и что вы здесь описывали всякие штучки

читать не нужно ? только работать ?

pro100saniok: Работать не нужно? Только читать?

Есть еще 4(высшее) состояние знания, когда что-то делаешь, у тебя все получается, а ты даже не осознаешь этого.

Егор: а зачем его осознавать, если оно не приносит проблем?!)

xmoonlight: так его и не нужно осознавать. Оно просто "есть".

Егор: тогда его не нужно писать)) а закопирайтить пункты - нужно не забыть)

xmoonlight: Я его написал, потому что встречал в литературе первых 3 написанных вами. И 4-ого не хватало для "полноты картины".

Егор: Ок. Понятно... Ссылка есть под руками или куда копать на первые три? А то вдруг, действительно, уже кто-то придумал)

xmoonlight: сейчас уже не вспомню первоисточник, но в интернете это перефразировали как "теория компетентности".

Егор: почитал, но это совсем не то... Это речь об осознании, а не о владениях навыками на разных стадиях развития (как у меня).

xmoonlight: ну почему же только осознании. О применении также. Разве можно осознать, что умеешь, не применяя этого?

Егор: да. это как раз осознание возможности.