Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 96
> 7. Зависайте на сайтах и форумах по программированию, читайте блоги
Вместо этого должно быть:
Подпишитесь на англоязычные списки рассылки, организованные разработчиками ваших компиляторов, языков, библиотек, фреймворков, whatever else. Всё движение, всё «мясо» — там. А на форумы и блоги попадают лишь слабые отголоски дальних гонгов.
Вместо этого должно быть:
Подпишитесь на англоязычные списки рассылки, организованные разработчиками ваших компиляторов, языков, библиотек, фреймворков, whatever else. Всё движение, всё «мясо» — там. А на форумы и блоги попадают лишь слабые отголоски дальних гонгов.
Кстати не подскажете англоязычный портал на подобие хабра?
хабра уникальный портал=)
Что-то вам не то советуют. Спешу на помощь: slashdot.org/
news.ycombinator.com/ конечно же (ссылку на оригинал данной статьи автор разместил первым делом именно там :)
Думаю это стоит добавить как отдельный пункт…
А подскажите какие нибудь сайты (раз тут там много опытных людей) где обсуждаются роботы. Т.е. часто вижу по ТВ, как собираются интузиасты робототехники. От простых, где лампочки моргают до бегающих роботов, играющих в футбол :) Очень интересуюсь этой темой, но именно с точки зрения интузиастов-самоделкиных.
> Если у вас есть чем дополнить линк-лист (желательно русские ресурсы, книги) — пишите в ЛС, обязательно добавлю
К пункту 7 добавить habrahabr можно.
К пункту 7 добавить habrahabr можно.
Каждую новую программу начинайте делать «с нуля». Разрабатывайте самостоятельно всю архитектуру и реализуйте ее.
Очень хороший совет. Чем больше практики, тем больше навыков.
Ещё очень хорошая вещь — это «изобретение велосипедов». Сколько бы не говорили, что это потеря времени, оно все равно остается самым лучшим способом обучения. Вроде, хотите узнать как работают cms — напишите свою. Это же относится к 3d технологиям, игровым движкам и т.п.
Почему все так против велосипедостроения?)
Тут всё скорее зависит от того, где начинается это «велосипедостроение» :)
Не думаю что кто-то против велосипедов в качестве обучения, речь везде скорее идет о «велосипедах» в крупных/коммерческих проектах, которые тратят время и вероятно снижают качество кода…
Не думаю что кто-то против велосипедов в качестве обучения, речь везде скорее идет о «велосипедах» в крупных/коммерческих проектах, которые тратят время и вероятно снижают качество кода…
Вероятно, вы правы. В крупных проекта (действительно крупных) это может сильно сократить время и затраты на разработку, но, иногда, возникают проблемы именно в заимствованном «велосипеде», и тогда все эти затраты могут сойти на нет.
Вообще, я за создание собственных велосипедов с целью образования, и, если они удачны, последующее их использование в своих проектах. Ну, а если не удачны, то хотя бы знания получили)
Вообще, я за создание собственных велосипедов с целью образования, и, если они удачны, последующее их использование в своих проектах. Ну, а если не удачны, то хотя бы знания получили)
Тут вопрос скорее в другом — насколько разумно писать велосипед в данном, конкретно взятом случае
По своему опыту могу сказать, что все велосипеды в моих проектах по качеству были хуже уже написанных. Просто очень часто многие программисты думают, что они могут написать лучше и быстрее, однако, как это часто бывает, они ошибаются. Только в редких случаях имеет смысл писать что-то свое. В любом случае это зависит от ситуации и решаемых задач.
Но велосипеды быть практичнее в эксплуатации (например, если в процессе поддержки изменились концептуальные процессы) к тому же, обладают «родным» кодом — который и проще и быстрее обслуживать. Но согласен, принимать решение нужно по обстоятельствам, учитывая сильные и слабые стороны двух подходов
Тут всё просто объясняется — проектирование 87.4% велосипеда — вещь очень приятная и действительно хорошо помогает обучаться. Но вот оставшиеся 12.6% — это документирование, сопровождение, отладка, оптимизация, профайлинг и прочие неприятные задачи. К тому же все слышали что на последние 10% объёма задачи нужно будет затратить 90% времени. А энтузиазм-то уже кончился ;-) И не только у разработчика, ещё и у того кто распоряжается ресурсами. +давление возросло. Напорядок. Сроки начали поджимать, то что казалось интересным и простым — оказывается, зачастую, нудным и громоздким…
Вот и сдаётся чуть более чем наполовину закончиный движок. Чуть более чем наполовину выполняющий задачи модуль. Чуть более чем наполовину сильнее задуманного тормозящий сервер. И на всём этом всё равно надо ехать. И едут. И некоторые даже доезжают до промежуточных чекпойнтов. Но тем кто пару лет участвовал в проектах где за фундамент взят недостроенный велосипед, а ещё лучше — оплачивал разработку ТАКОГО — становится понятно — что строить велосипеды в рабочее время — это саботаж.
И даже большинство разработчиков в итоге понимают — что тот период триумфа от стройной архитектуры в мозгах, проходит за 3-4 месяца, а работа ведь только начата. А ещё ведь и «кнопочки расставлять». А признать свою ошибку и вернуться на развилку — не всем позволяет гордость и смелость.
Вот ездим на велосипедах с квадратными колёсами по дорогам мёбиуса (
И пьём пиво на встречах и семинарах, и после тяжёлых трудовых будней, которые сами же себе и устроили, обсуждаем вопросы «почему индустрия/проект/компания в жопе».
Поверьте — велосипеды это не выбор смелых и решительных. Это для тех кто «играет в жизнь» (с) «Изображая жертву». Ну или для новичков.
Вот и сдаётся чуть более чем наполовину закончиный движок. Чуть более чем наполовину выполняющий задачи модуль. Чуть более чем наполовину сильнее задуманного тормозящий сервер. И на всём этом всё равно надо ехать. И едут. И некоторые даже доезжают до промежуточных чекпойнтов. Но тем кто пару лет участвовал в проектах где за фундамент взят недостроенный велосипед, а ещё лучше — оплачивал разработку ТАКОГО — становится понятно — что строить велосипеды в рабочее время — это саботаж.
И даже большинство разработчиков в итоге понимают — что тот период триумфа от стройной архитектуры в мозгах, проходит за 3-4 месяца, а работа ведь только начата. А ещё ведь и «кнопочки расставлять». А признать свою ошибку и вернуться на развилку — не всем позволяет гордость и смелость.
Вот ездим на велосипедах с квадратными колёсами по дорогам мёбиуса (
И пьём пиво на встречах и семинарах, и после тяжёлых трудовых будней, которые сами же себе и устроили, обсуждаем вопросы «почему индустрия/проект/компания в жопе».
Поверьте — велосипеды это не выбор смелых и решительных. Это для тех кто «играет в жизнь» (с) «Изображая жертву». Ну или для новичков.
Потому что навыки выбора и освоения чужого не появляются. Ремесленник, делающий все с нуля, не станет инженером, работающим с полуфабрикатами. Разделение труда нарушается.
Как обучение это хорошо, но многие предпочитают учиться всю жизнь на деньги заказчика.
Как обучение это хорошо, но многие предпочитают учиться всю жизнь на деньги заказчика.
11. Помогайте другим решать проблемы.
Stackoverflow — отличный ресурс, где можно помочь другим. Каждый полезный ответ улучшает рейтинг, кстати.
Stackoverflow — отличный ресурс, где можно помочь другим. Каждый полезный ответ улучшает рейтинг, кстати.
Не только помочь другим, но и самому спросить совета в трудной ситуации. Хорошие вопросы там тоже ценятся.
Совершенно верно, ценятся. Но все-таки навыки улучшаются от попытки решить проблему, с которой столкнулись другие. Кстати, там же можно потренироваться на написание кода на скорость — дело в том, что ответы на новые вопросы появляются очень быстро, иногда буквально за минуты. Бывает, что вы пытаетесь ответить на чей-то вопрос, кодите примерчик неторопливо, а когда решение найдено и вы хотите его опубликовать — бум! — оказывается, что четверо уже дали свои ответы, и один из них в точности такой же, как и ваш :)
Из русскоязычных ресурсов — хорош rsdn.ru
Из русскоязычных ресурсов — хорош rsdn.ru
Полностью согласен с 7ым пунктом — сам часто зависал на форумах, давая ответы/задавая (иногда глупые) вопросы. И не редкостью было найти в чьем-то сообщении очень интересную штуку/решение/идею, которые наталкивали на новое направление или же изучение неведомой ранее части языка.
P.S. Насчет ресурсов — лично я как-то пользовался forum.sources.ru/ и forum.vingrad.ru/ — 2 крупных форума по всевозможным языкам программирования.
P.S. Насчет ресурсов — лично я как-то пользовался forum.sources.ru/ и forum.vingrad.ru/ — 2 крупных форума по всевозможным языкам программирования.
Впрочем, не подумайте чего — с остальными пунктами я тоже более чем согласен.
Причем я бы даже добавил, что заниматься самообучением, «совать нос» в различные open-source проекты, заниматься новыми для себя языками программирования и все другие варианты полезны не только начинающим, а даже опытным разработчикам. Ведь невозможно знать всё на свете — всегда есть что-то, что ты упустил, не заметил или даже не предполагал…
Причем я бы даже добавил, что заниматься самообучением, «совать нос» в различные open-source проекты, заниматься новыми для себя языками программирования и все другие варианты полезны не только начинающим, а даже опытным разработчикам. Ведь невозможно знать всё на свете — всегда есть что-то, что ты упустил, не заметил или даже не предполагал…
Еще RSDN.ru Из форумов особенно C/C++, декларативное программирование, и философия программирования (хотя .NET тоже должен быть силен).
12. Среда разработки — выжимайте максимум из IDE (изучайте горячие клавиши, macros, snippets, наxодите полезные addons/extensions/plugins).
А я соглашусь насчет 9-го пункта. Помню как еще в школе изучил ассемблер, и далее в институте на схемотехнику учил. После этого изучить новый язык не проблема. И хорошо понимаешь где в программе узкие места по производительности, памяти и т.п. И как вообще все работает на низком уровне.
По-моему личному субъективному мнению, 6-й пункт наиболее важен.
Порекомендуйте, где можно почитать чужой perl-код.
Порекомендуйте, где можно почитать чужой perl-код.
12. Доскональна изучите тот язык на котором вы программируете сейчас, уберите все пробелы в понимании, разберитесь как работает каждый оператор даже если он интуитивно понятен (привет instanceof из JavaScript). Это будет на много полезнее чем пункт 1. Часто знают результат функции/оператора, но не знают почему это так — появляется куча бредовых мнений (echo быстрее print) и куча вопросов, ответы на которые не дают понимания сути проблемы (часто дают решение, но не объясняют почему так).
1. Нужен хотя бы один язык основанный на прототипном наследовании, из актуальных: ECMAScript (JavaScript)
ECMAScript взрывает мозг, тем кто не знаком с прототипным делегирующим наследованием. Не поленитесь почитать как все устроено, уверяю, вас ждёт много открытий.
1. Нужен хотя бы один язык основанный на прототипном наследовании, из актуальных: ECMAScript (JavaScript)
ECMAScript взрывает мозг, тем кто не знаком с прототипным делегирующим наследованием. Не поленитесь почитать как все устроено, уверяю, вас ждёт много открытий.
> Доскональна изучите тот язык на котором вы программируете сейчас… Это будет на много полезнее чем пункт 1
Нет, не будет. Само собой, в языке, который непосредственно используется в разработке прямо сейчас, нужно разбираться досконально, но если вы хорошо знаете один и только один язык, то всю жизнь будете забивать гвозди микроскопом. Ну либо с помощью молотка изучать строение молекул.
Нет, не будет. Само собой, в языке, который непосредственно используется в разработке прямо сейчас, нужно разбираться досконально, но если вы хорошо знаете один и только один язык, то всю жизнь будете забивать гвозди микроскопом. Ну либо с помощью молотка изучать строение молекул.
Соглашусь, что молотком сложно изучать строение молекул. Но уж лучше знать 1 язык доскональна — с глубоким знанием поймешь подойдет он для конкретной задачи или нет, чем N языков поверхностно — да будешь знать принципы, заложенные в языки, но напишешь ли хорошую программу в стиле данного языка?! Понятно, что базовые понятия ты будешь знать и реализуешь так или иначе говнокод алгоритм. Я уверен, что при поверхностном изучении каждый будет писать на одном языке в стиле другого — это как пересесть левого руля на правый или с мотоцикла на авто и водить с крыши.
Вот примеры смешения стиля:
1. UglifyJS / lib / parse-js.js (Lisp → JavaScript) — чистый функциональный стиль, годно, но сложно разобраться
2. binary-parser (??? → JavaScript) — ахтунг, лучше не открывать… на понятно на чем писал человек, но так не пишут на JavaScript
Я выступаю за качество знаний, но не говорю о том, что нужно упереться в один язык и писать на нем всю жизнь. Знаешь свой язык на высоком уровне — изучи другой, возможно он больше понравится. Конечно, в случае поиска языка (после ВУЗа часто ищут на чем бы писать) мой совет, безусловно, не подходит.
Вот примеры смешения стиля:
1. UglifyJS / lib / parse-js.js (Lisp → JavaScript) — чистый функциональный стиль, годно, но сложно разобраться
2. binary-parser (??? → JavaScript) — ахтунг, лучше не открывать… на понятно на чем писал человек, но так не пишут на JavaScript
Я выступаю за качество знаний, но не говорю о том, что нужно упереться в один язык и писать на нем всю жизнь. Знаешь свой язык на высоком уровне — изучи другой, возможно он больше понравится. Конечно, в случае поиска языка (после ВУЗа часто ищут на чем бы писать) мой совет, безусловно, не подходит.
> появляется куча бредовых мнений (echo быстрее print)
Теплый, ламповый echo
Теплый, ламповый echo
Мне прототипное наследование мозг не взорвало. Может, Вы расскажете, чем оно принципиально отличается от наследования в языках с классами?
Внезапно вспомнилось ещё насчёт наследования и взрыва мозга. Посмотрите на язык io, в котором тоже нет классов, но вместо наследования используется клонирование. Вот тут уже есть принципиальное отличие как от языков с классами, так и от EcmaScript: порождённый объект не обязан быть похожим на родителя, а «класс» порождённых объектов не обязан быть подмножеством (в смысле теории множеств) «класса» родительских объектов.
Последний пункт особенно удачен.
Ого, моя VictoriaOS ещё кому-то интересна, здорово! Если у кого-то будут вопросы касательно её устройства, обращайтесь.
Хотелось бы найти побольше сайтов с программистскими головоломками, чтобы было из чего выбирать. Очень понравился совет.
acm.timus.ru/ как бонус :)
А еще acm.sgu.ru, codeforces.ru, topcoder.com
И от нашего университета: acm.mipt.ru/
И ещё один http://www.spoj.pl/
programmingpraxis.com/ -хаскельно-лисповый хардкор, иногда питон проскакивает (хардкор — это для меня, я не программист, а лишь сочувствующий :)
Нельзя забывать про блог Алёна C++: habrahabr.ru/blogs/cpp/47765/
10. пункт эдакий мудрый старец)
Это скорее личностная характеристика, которую надо вырабатывать — усидчивость,
И если нырнуть в эту усидчивость, то волна сама по остальным пунктам понесет.
Это скорее личностная характеристика, которую надо вырабатывать — усидчивость,
И если нырнуть в эту усидчивость, то волна сама по остальным пунктам понесет.
Может показаться странным, но разбор кода с govnokod.ru/ порой неплохо тренирует мышление и знакомит с директивами, редко встречающимися в «правильных» исходниках.
Сейчас натаскиваю студента-программера. Искренне ему завидую. На что у меня ушли месяцы и годы ему объясняется за минуты. Подход может и не системный, но в совокупности с другими пунктами дает хороший эффект.
> Среди языков программирования отличный познавательный эффект и наверстывание опыта дают…
Я бы еще добавил сюда Lua как удачный пример embeddable языка. Нашёл весьма интересным и познавательным для себя писать программы одновременно на C и на Lua. Лучше понимаешь как language bridges устроены (в том числе и для других языков).
> Присоединитесь к open source проекту
Именно так. Причем к проекту с технологией которая вам нравится. Изучайте — знания вам всегда пригодятся! Для себя открыл пару интересных проектов на github которые я активно изучаю (и даже пытаюсь хакать):
— Прекрасная и быстрая билд система написаная на C github.com/gittup/tup
— Реализация Fuse для MacOSX. github.com/fuse4x/ Позволяет лучше понять XNU — ядро MacOSX. А вместе с ней структуру драйверов и vfs api BSD.
Я бы еще добавил сюда Lua как удачный пример embeddable языка. Нашёл весьма интересным и познавательным для себя писать программы одновременно на C и на Lua. Лучше понимаешь как language bridges устроены (в том числе и для других языков).
> Присоединитесь к open source проекту
Именно так. Причем к проекту с технологией которая вам нравится. Изучайте — знания вам всегда пригодятся! Для себя открыл пару интересных проектов на github которые я активно изучаю (и даже пытаюсь хакать):
— Прекрасная и быстрая билд система написаная на C github.com/gittup/tup
— Реализация Fuse для MacOSX. github.com/fuse4x/ Позволяет лучше понять XNU — ядро MacOSX. А вместе с ней структуру драйверов и vfs api BSD.
На Facebook и Yandex есть интересные задачки, но требуют регистрации
www.facebook.com/careers/puzzles.php
imat2011.yandex.ru/ — конкурс уже закрыт, но вроде как решения можно слать на проверку (конкурсы предыдущих лет тоже доступны)
еще интересные конкурсы на ICFP, но это лучше гуглить.
www.facebook.com/careers/puzzles.php
imat2011.yandex.ru/ — конкурс уже закрыт, но вроде как решения можно слать на проверку (конкурсы предыдущих лет тоже доступны)
еще интересные конкурсы на ICFP, но это лучше гуглить.
> Вы уже часик-второй (время зависит от размера проблемы) мучаетесь с этим куском кода?
ну, бывает по 12 часов, не вставая из-за компа :)
ну, бывает по 12 часов, не вставая из-за компа :)
это шутка?
13. Как говорил мой научный руководитель: «Лучший способ изучить какой-то аспект программирования — это начать преподавать его другим». Сам теперь преподаю — способ подтверждаю.
Сколько раз уже встречал рекомендацию № 9 — при этом вменяемого обоснования оной не встречал ни разу. Всё сводится к чему-то типа «изучите ассемблер, чтобы понять, как работает ассемблер — это очень поможет в изучении ассемблера».
Изучите ассемблер, чтобы понять, как работают алгоритмы и даже базовые конструкции высокоуровневых языков — это очень поможет в оптимизации ваших программ.
Опять эта сказка про белого бычка…
Скорость работы — это не белый бычок.
«Скорость работы» и «ассемблер» — это давно уже две настолько параллельных реальности, что большинство программистов, даже не являясь лохами и чайниками, никогда не попадёт в места их взаимопересечения.
Чтобы понять, как работают алгоритмы — надо, как это ни банально звучит, изучать алгоритмы и структуры данных. Изучение ассемблера тут не поможет никак — возможно, даже и навредит, потому что всё понимание, собственно, алгоритмов окажется погребено под нагромождением заталкиваний значений ячеек памяти в стэк и опросом регистров, а всё понимание структур данных — соответственно, под нагромождением байтов и DWORD-ов. Чтобы понять, как работают базовые конструкции высокоуровневых языков — надо, как это ни банально звучит, изучать базовые конструкции высокоуровневых языков. Чем тут, опять-таки, может помочь изучение ассемблера с его, по-сути, единственной языковой конструкцией — условным переходом по адресу? Научит применять goto в высокоуровневых языках?
Единственный рациональный аргумент проповедников ассемблера, который мне удалось уловить (я, кстати, не уверен, что все они его сами осознают) — полезно видеть детали реализации программы на уровень ниже (глубже) того, на котором, собственно, реализуешь. Ну, чтобы не удивляться потом, что у тебя функция strlen имеет сложность O(n), или при сложении двух больших положительных X и Y вдруг получается отрицательный Z. Но при чём же тут, пардон, ассемблер? Как знание MOV AEX, EAX поможет оптимизировать код на, допустим, Джаваскрипте или Питоне… да хрен с ними — даже на C?
Чтобы понять, как работают алгоритмы — надо, как это ни банально звучит, изучать алгоритмы и структуры данных. Изучение ассемблера тут не поможет никак — возможно, даже и навредит, потому что всё понимание, собственно, алгоритмов окажется погребено под нагромождением заталкиваний значений ячеек памяти в стэк и опросом регистров, а всё понимание структур данных — соответственно, под нагромождением байтов и DWORD-ов. Чтобы понять, как работают базовые конструкции высокоуровневых языков — надо, как это ни банально звучит, изучать базовые конструкции высокоуровневых языков. Чем тут, опять-таки, может помочь изучение ассемблера с его, по-сути, единственной языковой конструкцией — условным переходом по адресу? Научит применять goto в высокоуровневых языках?
Единственный рациональный аргумент проповедников ассемблера, который мне удалось уловить (я, кстати, не уверен, что все они его сами осознают) — полезно видеть детали реализации программы на уровень ниже (глубже) того, на котором, собственно, реализуешь. Ну, чтобы не удивляться потом, что у тебя функция strlen имеет сложность O(n), или при сложении двух больших положительных X и Y вдруг получается отрицательный Z. Но при чём же тут, пардон, ассемблер? Как знание MOV AEX, EAX поможет оптимизировать код на, допустим, Джаваскрипте или Питоне… да хрен с ними — даже на C?
Знание «MOV AEX, EAX», как вы выразились (гусары, молчать) — это то, что можно получить за день/неделю не напряжённого чтения книги для совсем уж чайников. По сути, изучение ассемблера подразумевает помимо знания опкодов и постановки низкоуровневого мышления изучения среды, в которой будет исполняться код.
Простор для оптимизации заключается не в том, чтобы просто взять и переписать функцию на ассемблере. Простор для оптимизации заключается в возможности переписать функцию с использованием/учётом низкоуровневых особенностей железа/системы, на котором будет исполняться программа. Например, использовать те или иные расширения (SSE различных версий, MMX, 3DNow и т. д.), или писать код, учитывая особенности конкретного микроконтроллёра (если мы говорим о встраиваемых системах), или конкретной операционной системы (если мы говорим о десктопах/серверах). Какие особенности? Алгоритмы работы планировщика, переключающего между задачами, алгоритмы работы со страницами памяти и т. д.
В конце-концов изучение ассемблера открывает ранее недоступные области: встраиваемые системы, системное программирование, взаимодействие с чужим исполняемым кодом (начиная от инструментов, вроде профайлеров и отладчиков, заканчивая антивирусами и виртуальными машинами). Программирование — оно такое, оно не заканчивается на прикладном ПО и числодробилках.
Простор для оптимизации заключается не в том, чтобы просто взять и переписать функцию на ассемблере. Простор для оптимизации заключается в возможности переписать функцию с использованием/учётом низкоуровневых особенностей железа/системы, на котором будет исполняться программа. Например, использовать те или иные расширения (SSE различных версий, MMX, 3DNow и т. д.), или писать код, учитывая особенности конкретного микроконтроллёра (если мы говорим о встраиваемых системах), или конкретной операционной системы (если мы говорим о десктопах/серверах). Какие особенности? Алгоритмы работы планировщика, переключающего между задачами, алгоритмы работы со страницами памяти и т. д.
В конце-концов изучение ассемблера открывает ранее недоступные области: встраиваемые системы, системное программирование, взаимодействие с чужим исполняемым кодом (начиная от инструментов, вроде профайлеров и отладчиков, заканчивая антивирусами и виртуальными машинами). Программирование — оно такое, оно не заканчивается на прикладном ПО и числодробилках.
Если программисту надо, реально надо оптимизировать свои программы на столь низком уровне — ассемблер, вероятно, уже является его основным рабочим инструментом. И в этом случае совет «изучите ассемблер» автоматически превращается в «изучите свой основной рабочий инструмент» — истину настолько банальную, что её не упоминают даже в статьях с названиями «10 способов...»
Если же ему не надо, а он всё равно оптимизирует, просто потому, что знает ассемблер — вероятно, его надо гнать из профессии сцаными тряпками :)
При этом как один из языков для изучения в п. 1 он очень хорош — но, опять-таки, как «один из», а не «единственный незаменимый труъ-мастхэв, кто не знает — тот не программист, а говно на палочке».
Если же ему не надо, а он всё равно оптимизирует, просто потому, что знает ассемблер — вероятно, его надо гнать из профессии сцаными тряпками :)
При этом как один из языков для изучения в п. 1 он очень хорош — но, опять-таки, как «один из», а не «единственный незаменимый труъ-мастхэв, кто не знает — тот не программист, а говно на палочке».
Кажется, уже не раз говорили о том, что компиляторы оптимизируют код куда лучше людей.
Дело не только в оптимизации. Ревёрсинг и низкоуровневая разработка — Asm тут нужно знать.
На выбор алгоритма компилятор повлиять не может. Ну, разве что совсем чуть-чуть.
Я бы спросил, с какого бодуна вы надумали, что знание ассемблера == знанию алгоритмов, но мне уже страшно…
А я этого и не утверждал, вам померещилось. Я лишь заметил, что знание ассемблера помогает оценить их сложность, и не столько алгоритмов, сколько их реализаций. Например, что быстрее — рекурсия или хранение промежуточных результатов в стэке? Исключения или возврат кода ошибки?
А при рекурсии где промежуточные результаты хранятся — не в стэке?
Верно! Но человек, знающий, в какие процессорные инструкции компилируется такая банальщина, как вызов функции, вспомнил бы, что в этот же стэк складывается некоторое количество служебных данных.
Не самый удачный пример, потому что эту проблему частично решает оптимизация хвостовой рекурсии, но она есть не во всех языках, и под неё, как правило, надо специально подгонять свою функцию, и это не всегда удаётся сделать.
Не самый удачный пример, потому что эту проблему частично решает оптимизация хвостовой рекурсии, но она есть не во всех языках, и под неё, как правило, надо специально подгонять свою функцию, и это не всегда удаётся сделать.
Как по мне, изучение изучение ассемблера даёт то же, что и изучение любого другого языка программирования (см. совет номер 1). Да, парадигма вроде бы та же императивная, но после изучения появляется возможность взглянуть на некоторые вещи совершенно по-другому.
Не охота — не изучайте, делов-то. Ни разу не встречал человека, утверждающего «почитал асм, это были худшие 2 дня в моей жизни, и не понадобилось ни разу»
Это всё здорово, но где взять ВРЕМЯЯААА?
избегайте литературы типа «Для чайников», "… за 24 часа", "… за 3 недели"
И статей вроде «10 способов...» :)
И статей вроде «10 способов...» :)
«Программирование — лучший способ научится программированию.»
По пункту 7 (крупные форумы для программистов) рекомендую rsdn.ru — очень зрелый форум с хорошим сообществом
К пункту №1 можно добавить F#
Тут всё просто объясняется — проектирование 87.4% велосипеда — вещь очень приятная и действительно хорошо помогает обучаться. Но вот оставшиеся 12.6% — это документирование, сопровождение, отладка, оптимизация, профайлинг и прочие неприятные задачи. К тому же все слышали что на последние 10% объёма задачи нужно будет затратить 90% времени. А энтузиазм-то уже кончился ;-) И не только у разработчика, ещё и у того кто распоряжается ресурсами. +давление возросло. Напорядок. Сроки начали поджимать, то что казалось интересным и простым — оказывается, зачастую, нудным и громоздким…
Вот и сдаётся чуть более чем наполовину закончиный движок. Чуть более чем наполовину выполняющий задачи модуль. Чуть более чем наполовину сильнее задуманного тормозящий сервер. И на всём этом всё равно надо ехать. И едут. И некоторые даже доезжают до промежуточных чекпойнтов. Но тем кто пару лет участвовал в проектах где за фундамент взят недостроенный велосипед, а ещё лучше — оплачивал разработку ТАКОГО — становится понятно — что строить велосипеды в рабочее время — это саботаж.
И даже большинство разработчиков в итоге понимают — что тот период триумфа от стройной архитектуры в мозгах, проходит за 3-4 месяца, а работа ведь только начата. А ещё ведь и «кнопочки расставлять». А признать свою ошибку и вернуться на развилку — не всем позволяет гордость и смелость.
Вот ездим на велосипедах с квадратными колёсами по дорогам мёбиуса (
И пьём пиво на встречах и семинарах, и после тяжёлых трудовых будней, которые сами же себе и устроили, обсуждаем вопросы «почему индустрия/проект/компания в жопе».
Поверьте — велосипеды это не выбор смелых и решительных. Это для тех кто «играет в жизнь» (с) «Изображая жертву». Ну или для новичков.
Вот и сдаётся чуть более чем наполовину закончиный движок. Чуть более чем наполовину выполняющий задачи модуль. Чуть более чем наполовину сильнее задуманного тормозящий сервер. И на всём этом всё равно надо ехать. И едут. И некоторые даже доезжают до промежуточных чекпойнтов. Но тем кто пару лет участвовал в проектах где за фундамент взят недостроенный велосипед, а ещё лучше — оплачивал разработку ТАКОГО — становится понятно — что строить велосипеды в рабочее время — это саботаж.
И даже большинство разработчиков в итоге понимают — что тот период триумфа от стройной архитектуры в мозгах, проходит за 3-4 месяца, а работа ведь только начата. А ещё ведь и «кнопочки расставлять». А признать свою ошибку и вернуться на развилку — не всем позволяет гордость и смелость.
Вот ездим на велосипедах с квадратными колёсами по дорогам мёбиуса (
И пьём пиво на встречах и семинарах, и после тяжёлых трудовых будней, которые сами же себе и устроили, обсуждаем вопросы «почему индустрия/проект/компания в жопе».
Поверьте — велосипеды это не выбор смелых и решительных. Это для тех кто «играет в жизнь» (с) «Изображая жертву». Ну или для новичков.
все испытал на своей шкуре…
самый действенный способ: 3 ;) после 2:)
хорошие книги, который должен изучить каждый:
— Cовершеный код
— Архитектура корпоративных приложений
— Рефакторинг
— Анализ программного кода (на примере OpenSource)
Вот как раз последняя учит понимать чужой код, смотрим п. 6
там хорошее сравнение: «читаем код, как художественную литературу»
кто-то из авторов пишет хорошо, а кто-то похуже,
а с кем-то засыпаешь на второй странице…
самый действенный способ: 3 ;) после 2:)
хорошие книги, который должен изучить каждый:
— Cовершеный код
— Архитектура корпоративных приложений
— Рефакторинг
— Анализ программного кода (на примере OpenSource)
Вот как раз последняя учит понимать чужой код, смотрим п. 6
там хорошее сравнение: «читаем код, как художественную литературу»
кто-то из авторов пишет хорошо, а кто-то похуже,
а с кем-то засыпаешь на второй странице…
Среди языков программирования отличный познавательный эффект и наверстывание опыта дают:
Я бы добавил ещё Smalltalk, как хороший пример полностью объектного языка. Ну и из уважения к роли, которую он сыграл в истории программирования ;-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 способов улучшить свои навыки программирования