Как изучая технологию не стать ее заложником?
===============================================

 Здравствуйте уважаемы дамы и господа!  

Я выпускник политеха и в программировании мои уровень где-то чуть ниже junior'a.  

Собственно мой вопрос -- как изучая технологию не стать ее заложником?  
  

Теперь немного подробней.   

Заново заводить песню о том, что мол нигде толком не учат я сейчас не хочу. Эта тема уже многократно обсуждалась. Так вот в связи с этим остается, как и всем в принципе, учиться самостоятельно.   

Свой "уголок" в it я еще не нашел, но для долгосрочного изучения выбрал Ruby и Rails. Сейчас занимаюсь изучением последнего и все бы хорошо, но буквально вчера я разговаривал с приятелем и он заметил, что начинать изучение с готового фреймворка (технологии, библиотеки и т. д.) путь не самый правильный. В качестве аргумента он заметил, что технологии быстро устаревают и уходят со сцены it, а вместе с ними и наши драгоценные время и навыки. И как следствие нам в будущем придется переучиваться. От себя хочу заметить, что применение довольно масштабного каркаса, библиотеки или чего-нибудь другого не дает в полной мере познать все тонкости языка и сферы в которой язык применяется -- знания получаются весьма поверхностные.   

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

Хотелось бы услышать ваше мнение, ведь если не фреймворк так велосипеды, а к ним у меня отношение двуякое.   

Спасибо за внимание! 

 Учиться методом проб и ошибок - как делает человечество и наука уже тысячи лет, несмотря на любые достижения и периодические исключения - тоже ужасный способ развития. Однако, к сожалению, лучше еще не придумали.  
  

Начнем с того, что рельсы появились в 2004 году, когда все было по-другому. И довольно успешно развиваются и подстраиваются под современные требования, что бы там ни говорили.  
  

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

Короче, самый нормальный путь обучения - на реальных задачах. Сегодня, по крайней мере, все реальные серьезные задачи (не берем редкие исключения типа ФБ и ВК, где тоже можно было бы не городить, кстати) делаются на фреймворках. Вывод: шашечки или ехать? 

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

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

Изучайте архитектуру ПО, множество таких вопросов отпадет. Если начнете читать Фаулера или Банду четырех - то буквально в предисловии найдете различия между библиотекой и фреймворком. Правда, о последнем там скажут в контексте написания фреймворка, а не использования.  

Прежде чем начать изучать какую-либо технологию, ну или как можно ее назвать в данном контексте - "надстройку над" чем-то более глубоким - изучите это более глубокое. А тут возникает уже такой вопрос - что может Ruby без Rails? Что может PHP без YII, Symphony? Даже тот же Python крайне хорош для админстрирования системы, а Perl прекрасно работает с текстами, и держит планку. На вашем месте я бы сразу глядел в сторону C, C++, C#, Python, Perl и т.д., и изучал бы сами языки, а уже потом, со знанием языка, его использования в той или иной парадигме программирования, работы с памятью(, и т.д. и т.д. и т.д.) думал бы о фреймворке.  

P.S.: Некоторые могут вылезти с комментариями типа "ну он же новичок", "пусть лучше начнет с интерпретируемых языков", "С и плюсы слишком сложные", "все так начинают" и т.п. Вот тогда и скажите мне, как много интерпретируемых языков и уж тем более фреймворков (в том числе и для С и плюсов) года например 80-ого вы можете назвать, и на чем например будущие программисты после окончания своих ВУЗов писали программы году так в 75ом. 

 Глупости рассказывает ваш друг, алгоритмы они и есть алгоритмы, массовой смены алгоритмов в прошлом веке только был в виде ухода от перфокарточек и странных дисков, к оперативной памяти и магнитным диском, да там изменились алгоритмы существенно, не надо было крутиться в килобайте памяти.  

А так вы же не старик, ну вышел новый руби, купили книжку за неделю прочитали знания обновили. 

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

Просто смиритесь с тем, что выбрав сферу IT вам всю жизнь придётся учится. 

 Ничего плохого в этом нет. Ваша задача научиться программировать, на Ruby, Python или Erlang - это не важно, выучить новый язык программирования, фреймворк не составит труда, если у вас есть опыт работы с похожими технологиями.  
  

Но все же, когда будет время, рекомендую поиграться с С/С++ или Java. Просто для расширения кругозора.