Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 198
Мда… Я сам такой начинающий программист, о котором вы упомянули в статье. Теперь я действительно всерьез задумался об изучении фундаментальных конструкций. А то метаюсь от одного к другому
Я очень рад, что был услышан. Значит это день уже прожит не зря.
Помнится в одном треде глумились над «конфигураторами cms», и я тогда отгреб минусов, за замечание, что в большинстве случаев современные программисты выступают в роли «конфигураторов фреймворков», что не многим лучше
Хорошая формулировка :)
Кстати говоря, сконфигурировать современный фреймворк зачастую оказывается немногим проще, чем написать с нуля свой собственный.
Мне, например, так и не удалось собрать Qt-static под MinGW. Даже после изрядного шаманства получилось нечто урезанное — без QtDeclarative, WebKit'а и плагинов.
Да и нередка ситуация, когда одни только скрипты сборки фреймворка используют например Perl, makefile, bat и bash одновременно, т.ч. когда возникнет ошибка сборки/линковки (а она 100% возникнет раньше или позже), у непрограммистов возникнут неразрешимые проблемы.
Мне, например, так и не удалось собрать Qt-static под MinGW. Даже после изрядного шаманства получилось нечто урезанное — без QtDeclarative, WebKit'а и плагинов.
Да и нередка ситуация, когда одни только скрипты сборки фреймворка используют например Perl, makefile, bat и bash одновременно, т.ч. когда возникнет ошибка сборки/линковки (а она 100% возникнет раньше или позже), у непрограммистов возникнут неразрешимые проблемы.
Суть вашего поста сводится к «Читайте МакКонела» ) У него отлично написано про то что вы хотели выразить в своем посте словами «Есть два типа программирования с помощью языка и на языке».
Я последнее время начал жалеть, что 5 лет назад начал уходить от программинга по причине того, что делфи-программисты получают меньше чем нормальные сисадмины =( На днях решил вернуться, но на этот раз переходить на C++ с будущими идеями насчёт карьеры в этой области. Не знаю что из этого выйдет, но знаю точно что админство поднадоело конкретно, всё одно и то же изо дня в день.
Делфи пять лет назад уже умер и не удивительно, что дельфины получали мало, т.к. тупо не нужны. Если где-то и можно поднять бабла на делфи, то это на поддержке legacy кода, но много инженеров для этого не надо.
А по поводу перехода на C++ — вы сначала определитесь ЧТО вы будете программировать и в какой области, а потом уже изучайте необходимую технологию. А то получится как с Делфи.
А по поводу перехода на C++ — вы сначала определитесь ЧТО вы будете программировать и в какой области, а потом уже изучайте необходимую технологию. А то получится как с Делфи.
Рекомендую почитать Айзека Азимова — Профессия. Реально мотивирует быть настоящим программистом.
Но это же нормально: при появлении некого нового явления адепты этого явления расслаиваются. С одной стороны — пользователи, «казуалы», довольно бездумные и производящие адову тонну низкосортного продукта; с другой — профессионалы, которые производят качественный продукт, но и стоят времени, денег и т.п.
Но, что приятно, вы не избавитесь ни от одних, ни от других, хорошая такая экосистема. :)
Но, что приятно, вы не избавитесь ни от одних, ни от других, хорошая такая экосистема. :)
Согласен, что это нормальный и естественный процесс. Но, цитируя Наполена:
«Плох тот солдат, который не хочет стать генералом»!
«Плох тот солдат, который не хочет стать генералом»!
Это сказал Суворов
а вот и не Суворов: http://www.bibliotekar.ru/encSlov/15/67.htm
У Суворова есть офигенные слова: «Не знаешь что делать делай шаг вперед». Они очень часто меня спасают меня от перфекционизма. Именно они заставляют меня начать любым более-менее правильным способом известный в момент когда уже слишком долго сижу над проектированием и думанием чего-нить
Не всем быть генералами.
«Всяк сверчок знай свой шесток». :)
«Всяк сверчок знай свой шесток». :)
Я думаю, что здесь просто идет подмена концепций. «Программист» который сделал красивый сайт на супер-современном движке программистом попросту не является. Это не плохо, и не хорошо — просто он совсем другой специалист, но не программист. Скажем, для меня проще застрелиться, чем сделать красиво выглядящий UI — ну не люблю я его делать, и не умею. А для этого специалиста (назовем его слогом старинным, веб-мастером) такой же непосильной задачей будет написать то, чем занимаюсь я.
Но это все, тем не менее, не прощает тех wannabe, которые считают что для программирования достаточно знать пару фреймворков, какой-нибудь Yii и уметь сконфигурировать (криво) Apache на VPS.
Но это все, тем не менее, не прощает тех wannabe, которые считают что для программирования достаточно знать пару фреймворков, какой-нибудь Yii и уметь сконфигурировать (криво) Apache на VPS.
«Программист» который сделал красивый сайт на супер-современном движке программистом попросту не является.
Дело не в понятиях, и не в том кто чем является. А в том, что появляется сообщество людей, считающих себя программистами, не являясь ими при этом. При этом им даже объяснить сложно, в чем разница.
А надо? Чем меньше они знают, тем ценнее я как специалист.
Тоже подход :-)
Можно даже завести касты программистов и цеховые тайны!
Можно даже завести касты программистов и цеховые тайны!
Поддерживаю. Особенно странно в таком контексте выглядят непризнанные гении, не сумевшие получить высшее образование, но при этом с таким неоправданно завышенным эго, что кажется, что от них сияние исходит…
Эффект Даннинга — Крюгера
Эффект Даннинга — Крюгера
Если никто не знает разницы, то ваша ценность — никому непонятна.
В том числе и непрофессиональным заказчикам.
В том числе и непрофессиональным заказчикам.
Согласен с вашей точкой зрения с одной маленькой оговоркой. Это все справедливо, если мы говорим о профессиональных программистах. С другой стороны, нет ничего плохого в том, что каждый пользователь, потратив немного времени, может сделать себе сайт из кусочков, как мозаику, не вникая в какие-то дебри. Или написать простенькую программку для каких-то своих нужд. Главное, чтобы при этом не возникало слишком завышенного самомнения.
В общем, такие программки под себя продвинутые пользователи Microsoft Office пишут уже довольно давно и без всякого самомнения. Я наблюдал начальника отдела, который для себя на Access сочинил некоторую системку документооборота. А еще в одной организации автоматизировали логистику с помощью общедоступной таблицы excel. Но никто из них не считал себя программистом.
Конечно, нужно знать основы. К сожалению, во многих ВУЗах не понимают, как это важно и насколько это облегчает дальнейший путь программиста. До сих пор «переучиваюсь», удивляясь сам себе, каких элементарных вещей я не знаю.
Даже самые тру-хардкор программисты открывают для себя паттерны, структуры данных etc не просто так, а в контексте конкретных проблем.
Пока нет проблем — никто и не заморачивается. И это нормальное человеческое поведение.
Пока нет проблем — никто и не заморачивается. И это нормальное человеческое поведение.
«Проблема» в данном случае это не когда все пропало, а просто какая-то сложная задача, требующая решения.
Для меня как программиста, я считаю нормальным не заморачиваться вопросами устройства сливного бачка, пока он не потечет. Это не моя тема. Но аналогичное отношение к вопросам, связанным со своей профессией — это ненормальное поведение.
Чтобы «что-то» вдруг понадобилось — нужно хотя бы знать о его существовании. Любую задачу можно решить без применения паттернов и стандартных методик, а нахрапом, да с разбегу. Другое дело, что получится в результате.
Профессионал должен постоянно самосовершенствоваться, при этом совершенно необязательно вгрызаться и основательно разбираться во всем на свете — это просто невозможно. Но постоянно расширять свой кругозор новыми понятиями и идеями, чтобы при необходимости изучить их более подробно — необходимо.
Чтобы «что-то» вдруг понадобилось — нужно хотя бы знать о его существовании. Любую задачу можно решить без применения паттернов и стандартных методик, а нахрапом, да с разбегу. Другое дело, что получится в результате.
Профессионал должен постоянно самосовершенствоваться, при этом совершенно необязательно вгрызаться и основательно разбираться во всем на свете — это просто невозможно. Но постоянно расширять свой кругозор новыми понятиями и идеями, чтобы при необходимости изучить их более подробно — необходимо.
Поддерживаю автора с небольшим замечанием.
Явление «казуализации» и низкого профессионализма множества современных разработчиков повышает рыночную стоимость настоящих профессионалов. Это нужно понимать, особенно начинающим.
Явление «казуализации» и низкого профессионализма множества современных разработчиков повышает рыночную стоимость настоящих профессионалов. Это нужно понимать, особенно начинающим.
Часто вспоминаю в таких случаях слова одного умудренного опытом человека: «Не хотите — не учитесь. Чем меньше вы знаете, тем ценнее я как специалист.»
Можно объяснить мне (начинающему) — каким образом? Как неспециалист может отличить профессионала от казуала?
А так же повышает требования к временным затратам. Многие не очень «продвинутые» фирмы дают заказ тому, кто сделает быстрее и дешевле, а не тому, кто сделает офигенно круто, но помедленнее и подороже. Им-то невдомёк, что сопровождение говнокода стоит дороже.
Вы, безусловно, правы относительно того, что программисту необходимы базовые знания, однако одними знаниями, все же, не обойтись, необходимо понимать что происходит в программе, которую человек пишет, понимать что происходит на каждом этапе исполнения программы и уметь, так сказать, исполнять программу в голове, да, для этого нужны знания о внутреннем устройстве исполняющего механизма компьютера/ОС/виртуальной машины.
Не так давно, около года назад, я читал очень великолепную статью про «дырявые» абстракции, где довольно подробно был разжеван данный термин. Так вот, не бывает абсолютных, идеальных абстракций, что бы использовать эту абстракцию по-уму просто необходимо знать как устроена эта абстракция, однако тем людям, коих комментатор выше назвал «wannabe» не хотят, на данный момент, задумываться о внутреннем устройстве, им важнее, на мой взгляд, поучаствовать в процессе, и вот тут вступает всем известный принцип естественного отбора, когда такие люди начинают разделяться на два лагеря: первые осознают, что необходимо углубляться т.к. стало интересно, вторые же будут и дальше работать с абстракциями, напрасно думая что они и так знают все отлично, и все равно перейдутна темную сторону к первым или же забросят это дело только встретив первую проблему с абстракцией, которая не желает работать как им надо. Так что, ИМХО, все имеют право на жизнь и не заслуживают быть осужденными, жизнь все равно всех рассудит, так или иначе :)
Не так давно, около года назад, я читал очень великолепную статью про «дырявые» абстракции, где довольно подробно был разжеван данный термин. Так вот, не бывает абсолютных, идеальных абстракций, что бы использовать эту абстракцию по-уму просто необходимо знать как устроена эта абстракция, однако тем людям, коих комментатор выше назвал «wannabe» не хотят, на данный момент, задумываться о внутреннем устройстве, им важнее, на мой взгляд, поучаствовать в процессе, и вот тут вступает всем известный принцип естественного отбора, когда такие люди начинают разделяться на два лагеря: первые осознают, что необходимо углубляться т.к. стало интересно, вторые же будут и дальше работать с абстракциями, напрасно думая что они и так знают все отлично, и все равно перейдут
Программисты как и любая другая профессия, не вещь в себе. Мы отвечаем на запросы общества. Расслоение по проф. уровню и напралениям будут только увеличиваться. Это на прямую связано с задачами, на машинных кодах сейчас не пишут, потому что железо дешевле, чем такой уровень оптимизации. Как современный мебельщик не пойдет корчевать деревья, так и нам не приходится иметь дело с машинными кодами.
В понятие программист сейчас вкладывается слишком много вариаций. При этом каждая вариация накладывает свой отпечаток на знания и дает свою уникальную деформацию личности.
Какие то знания остались со школы/университета, а какие приобрелись на практике. Есть том Кнута посвещенный сортировкам, но сколько из них вспоминаются хотя бы раз в 5 лет? Многие медалисты знают кучу интересных вещей, но толку от этого в реальной работе нет.
Если человек умеет думать, умеет искать и работать с информацией, то при необходимости и/или желание разберется с любым уровнем.
PS: как то сумбурно получилось
В понятие программист сейчас вкладывается слишком много вариаций. При этом каждая вариация накладывает свой отпечаток на знания и дает свою уникальную деформацию личности.
Какие то знания остались со школы/университета, а какие приобрелись на практике. Есть том Кнута посвещенный сортировкам, но сколько из них вспоминаются хотя бы раз в 5 лет? Многие медалисты знают кучу интересных вещей, но толку от этого в реальной работе нет.
Если человек умеет думать, умеет искать и работать с информацией, то при необходимости и/или желание разберется с любым уровнем.
PS: как то сумбурно получилось
Знания тоже не вещь в себе. Может, прочитав том кнута, вы через год и не вспомните все сортировки, но а) все-таки у вас что-то отложится, и б) эта информация так или иначе изменит ваше представления о других вещах. Даже прочитав книгу и поняв, что описанное в ней вам не подходит (возможно, в данный момент), вы все равно растете как профессионал.
вот-вот-вот
Ну и? Знаний полон интернет бери не хочу. В результате охота за знаниями стала, больше походить на олимпиады по яндексу.
Источников много, голосов вокруг твердящих «надо вот именно это», еще больше. Где критерий, по которуму выбирать из чего черпать знания? Почему вы считаете, что ваш критерий точнее моего? А как посчитать рост профессионализма?
Я несколько раз начинал читать Кнута, мне его книги даются очень тежело, в результате откладывал в пользу чего то другого. В частности Фаулер и ГОФ читаются на порядок легче и были с удовольствием прочитаны. Подход к получению тактически и стратегических знаний у каждого разный. Да и глобально, сейчас самый ценный ресурс время, при двух работах и семье я выбиру, то что ближе к текущим задачам, чем что то жутко глобальное.
Делай работу хорошу и в охотку, а остальное приложится.
Источников много, голосов вокруг твердящих «надо вот именно это», еще больше. Где критерий, по которуму выбирать из чего черпать знания? Почему вы считаете, что ваш критерий точнее моего? А как посчитать рост профессионализма?
Я несколько раз начинал читать Кнута, мне его книги даются очень тежело, в результате откладывал в пользу чего то другого. В частности Фаулер и ГОФ читаются на порядок легче и были с удовольствием прочитаны. Подход к получению тактически и стратегических знаний у каждого разный. Да и глобально, сейчас самый ценный ресурс время, при двух работах и семье я выбиру, то что ближе к текущим задачам, чем что то жутко глобальное.
Делай работу хорошу и в охотку, а остальное приложится.
Вы совершенно справедливо заметили про «олимпиады по яндексу». Только это как раз не то, к чему нужно стремиться. В конце концов, мы говорим о программистах, а не участниках «что где когда». Вот не понравился вам Кнут, ради Бога, не читайте. Но зато вы можете сказать
Я несколько раз начинал читать Кнута, мне его книги даются очень тежело, в результатевместо «ай, какой-то Кнут, или как там его, Пряник, это все ерунда, не читал и читать не буду, мне это не надо, я буду и дальше лепить зеленые кнопки». Вот в этом-то и разница. В конце концов, давайте оставим Дональда в покое, никто ведь не говорит, что нужно обязательно читать это и это, а те, кто читает другие книги — еретики. Вопрос скорее в самом желании познать свою предметную область, что ли…
Знаний полон интернет бери не хочуС этим тоже не всё так просто. Наблюдаю иногда, когда гуглится что-то вроде «как сделать ABC» и ничего не находят и впадают в уныные: «это ДАЖЕ ГУГЛ не знает». Гугл/яндекс стал величиной высшего порядка, если ОН не знает, то это что-то жутко сложное, доступное лишь богам. При этом воспользовавшись этим же гуглом можно спокойно найти «как сделать A», «как сделать B», «как сделать C» и потом слепить это самое ABC.
ИМХО, зря вы напрягаетесь. В отрасли уже сложилось, что есть программисты и «обезьянки». Первые строят, проверяют и модифицируют архитектуру, вторые её реализуют. Значительная часть крупного современного ПО — реализация бизнес-логики, а там очень редко нужно понимать особенности и реализацию тех или иных алгоритмов — достаточно просто пользоваться уже написанными, условно, в ядре фреймворка. При этом в целом реализация всей бизнес-логики _со всеми_ граничными случаями — жуткая нудятина.
В реальности, печаль происходит только в тот момент, когда «обезьянки» осознают себя самостоятельными и начинают сами делать какой-нибудь «стартап». Особенно печально видеть действительно крутой стартап, жёстко реализованный на каком-нибудь раскрученном фреймворке без хоть какой-то возможности горизонтального шардинга. Ещё печальнее видеть «архитекторов» такого проекта, не понимающих, например, что такое «локи» и зачем они нужны.
В реальности, печаль происходит только в тот момент, когда «обезьянки» осознают себя самостоятельными и начинают сами делать какой-нибудь «стартап». Особенно печально видеть действительно крутой стартап, жёстко реализованный на каком-нибудь раскрученном фреймворке без хоть какой-то возможности горизонтального шардинга. Ещё печальнее видеть «архитекторов» такого проекта, не понимающих, например, что такое «локи» и зачем они нужны.
Языки высокого уровня и фреймворки создавались для того, чтобы иметь возможность создавать качественно более сложные программы, которые без них невозможно было бы сделать, поскольку есть предел сложности конструкций, которыми может оперировать человеческий мозг
Возможность создавать качественно более сложные программы существует и без фреймворков. Разбиваем все на подсистемы, декомпозируем, инкапсулируем…
Я бы даже так сказал: Хочешь быть настоящим профессионалом в %PROFESSIONNAME% — будь им! :)
Я тоже разделяю программирование как некое философское течение, где одним из ключевых моментов является умение упрощать и оптимизировать какие-либо сущности виртуального или реального мира, за счет понимания как это устроено и применения возможностей языка программирования.
Почти каждый начинающий программист изобретает какой-либо велосипед именно по этой причине. Никогда не понимал негатив к изобретателям велосипедов, ведь это новые идеи или реализации известных идей, что является здравой конкуренцией, что способствует развитию и прогрессу.
Почти каждый начинающий программист изобретает какой-либо велосипед именно по этой причине. Никогда не понимал негатив к изобретателям велосипедов, ведь это новые идеи или реализации известных идей, что является здравой конкуренцией, что способствует развитию и прогрессу.
«Наука занимается поиском наиболее компактных методов описаний мира, пригодных для деятельности.» (с) Алан Кей
«Методы описания… связаны с языком (формальным), поэтому наука… практически перекрывается с математикой». (отсюда)
«Методы описания… связаны с языком (формальным), поэтому наука… практически перекрывается с математикой». (отсюда)
>Соискатель:
>— Ну, список, конечно, лучше!
Надо было еще спросить, насколько и услышать в ответ «раза в полтора-два».
>— Ну, список, конечно, лучше!
Надо было еще спросить, насколько и услышать в ответ «раза в полтора-два».
:-)
Проводил как-то целый цикл собеседований, и всем задавал этот вопрос.
Ответы, прямо скажем, были разные, были и похожие на этот.
Проводил как-то целый цикл собеседований, и всем задавал этот вопрос.
Ответы, прямо скажем, были разные, были и похожие на этот.
Так а какой правильный ответ? :)
правильный ответ — «зависит от ситуации». Далее предлагалось привести пример ситуаций, в которых разумно использовать тот или иной подход и объяснить почему.
Я так и думал :)
Первое что в голову приходит, данные для отображения таблицы к примеру.
Массив массивов какой-нибудь Variant было бы нормальным решением. Списки в стандартной реализации все же не идеальны в random access…
Массив массивов какой-нибудь Variant было бы нормальным решением. Списки в стандартной реализации все же не идеальны в random access…
А что такое «стандартная реализация списка»? Классический связный список — тут да. Если же рассматривать просто как абстрактный интерфейс коллекции, то всё от реализации зависит, нужно просто нужную выбирать и всё. В Java той же самый распространённый как раз на массивах и построен, как следствие всё у него нормально с random access.
Не особо знаком с Java, потому и спрошу:
Может то таки не список, а массив с динамическим размером? Как там он называется?
Может то таки не список, а массив с динамическим размером? Как там он называется?
Что в Java, что в .Net он называется List<?>. Хотя в глубине души, он, конечно, динамический массив. Для меня всегда было загадкой, почему эти классы так назвали.
Нет, это просто реализация List, называется ArrayList, реализуется через обычный массив внутри, вернее (емнип) это не регламентируется, но очевидно, т.к. гарантируется O(1).
О(1) для какой операции?
видимо, имеется в виду обращение по номеру.
Потому как вставка в такую структуру может достигать и O(n)
Но не все про это знают/думают…
Потому как вставка в такую структуру может достигать и O(n)
Но не все про это знают/думают…
Вставка без изменения размера самой структуры тоже O(1), конечно. Расширение уже другое дело, за этим надо следить если это критично.
Вставка со сдвигом «хвоста» (а не добавление в конец) у массива всё же O(N).
Вы имеете ввиду вставка нового элемента между уже существующими элементами? Ну да, разумеется. В ArrayList так и делается — массив разрезается и двигается, тут условно конечно уже O(N). Хотя в Java оно делается через System и массив двигается более хитро, не попеременным переносом элементов, конечно же. Но тем не менее.
Извиняюсь, для доступа, конечно же, мы же с разговора про random access начали.
Вектор
Так я может не особо понял изначальную тему. Имелось в виду
double *array=new double[128]
против
std::listили
std::vector против std::list?
я как-то про второе подумал (для себя сравнив QList и QVector — да я знаю про сложность в QList, в векторе чуть быстрее все равно).
double *array=new double[128]
против
std::listили
std::vector против std::list?
я как-то про второе подумал (для себя сравнив QList и QVector — да я знаю про сложность в QList, в векторе чуть быстрее все равно).
Позолоти ручку, яхонтовый, все раскажу.
Всегда был противником всяких там Вижуал бейсиков и прочих калек, как и вообще самой идеи «программирования для не-программиста».
Но целиком не соглашусь, ни с вами, ни с цитируемой вами статьей. Да, я считаю, что каждый программер должен иметь необходимый минимум знаний в своей специализации — структуры данных, банальные алгоритмы (типа бинарного поиска) для императивных языков + паттерны для ООП, оптимизация запросов и прочие execution plans, если это программист баз данных и тд. Но по-моему нельзя говорить об «отуплении» нынешних программистов, когда есть книги типа C# in Depth — которая не шпаргалка к очередному зачету на бумажку, а обстоятельно объясняющая особенности программирования на данном языке — и на такие книги есть спрос. Если вы интервьируете студентов, которые ни черта ни смыслят в структурах данных — возможно проблема в локальных ВУЗах, и человек с радостью бы научился, стоит показать ему дорогу.
Но целиком не соглашусь, ни с вами, ни с цитируемой вами статьей. Да, я считаю, что каждый программер должен иметь необходимый минимум знаний в своей специализации — структуры данных, банальные алгоритмы (типа бинарного поиска) для императивных языков + паттерны для ООП, оптимизация запросов и прочие execution plans, если это программист баз данных и тд. Но по-моему нельзя говорить об «отуплении» нынешних программистов, когда есть книги типа C# in Depth — которая не шпаргалка к очередному зачету на бумажку, а обстоятельно объясняющая особенности программирования на данном языке — и на такие книги есть спрос. Если вы интервьируете студентов, которые ни черта ни смыслят в структурах данных — возможно проблема в локальных ВУЗах, и человек с радостью бы научился, стоит показать ему дорогу.
Дело не в том даже, что программист (да и любой профессионал — на эту тему было обсуждение выше) должен знать. А, в первую очередь в том, к чему он должен стремиться. Я говорю не об «отуплении», а о потере стремления к обучению вещам, необходимость которых поначалу не очевидна, поскольку «результат» стал слишком быстро достижим. Но только вот что это за результат…
Это есть. Только учтите, что незнание таких вещей прокатит только у джуниора. Захочется подняться повыше — придется учить паттерны и особенности языка.
То что «молодые» уже не те — так студенту, которого пичкают всякой чушью в вузе, может быть сложно выделить действительно нужные знания. Возможно раньше, требования в индустрии были другие, и программы в вузе ориентированы на языки низкого уровня, как С, где без знания структур вообще никуда, и те, кто шли туда, действительно знали, что хотят.
То что «молодые» уже не те — так студенту, которого пичкают всякой чушью в вузе, может быть сложно выделить действительно нужные знания. Возможно раньше, требования в индустрии были другие, и программы в вузе ориентированы на языки низкого уровня, как С, где без знания структур вообще никуда, и те, кто шли туда, действительно знали, что хотят.
индустрия такова — что и подниматься выше необязательно.
Вполне можно клепать поделки на фрилансе не утруждая себя изучением чего либо.
Я нисколько не осуждаю таких товарищей — это их выбор (по крайней мере, пока мне не приходится иметь дело с результатами их творчества). Но мне их немного жалко. Осознанно или нет, но они сами себя лишают изрядной части удовольствия.
Вполне можно клепать поделки на фрилансе не утруждая себя изучением чего либо.
Я нисколько не осуждаю таких товарищей — это их выбор (по крайней мере, пока мне не приходится иметь дело с результатами их творчества). Но мне их немного жалко. Осознанно или нет, но они сами себя лишают изрядной части удовольствия.
О, фанаты васика подтянулись. Есть что сказать, или только минусовать умеем?
и человек с радостью бы научился, стоит показать ему дорогуЯ обычно наблюдаю более полярное разделение. Люди, которые «с радостью научатся», но они же и сами дорогу находят. А если не находят, то спрашивают об их наличии. Другим, хоть носом в дороги тыкай, учиться они не хотят. Которые не видят дорогу, а если показать начинают двигаться, таких единицы на десятки. И часто пройдут метров 5 и опять во что-то упрутся.
Статья хорошая. Жизненная. Хотя мне все-таки немного грустно от того, что я скорей динозавр программирования и мне все проще сделать самому, чем прикручивать готовый супер крутой фреймворк. Проще лишь потому, что лениво досконально разбираться в логике работы этого фреймворка. Даже если я знаю, что он _умеет_ что-то делать и знаю, что он делает это _без ошибок_, у меня все равно останется куча сомнений по поводу того, действительно ли данный фреймворк делает все _должным образом_, т.е. именно так, как я того ожидаю. Чтобы это определить, мне нужно писать кучу тестов или лезть в исходники фреймворка, чтобы разобраться, как именно он обрабатывает те или иные ситуации. Время этих ковыряний зачастую соизмеримо со «сделать самому маленький механизм для данной конкретной ситуации». К тому же у своего кода есть и другие преимущества: я сам сопровождаю его, а не чешу затылок, когда выходит новая версия «супер крутого фреймворка» со слегка измененной логикой.
У кого то еще есть похожие ощущения?
У кого то еще есть похожие ощущения?
С грустью присоединяюсь. Но я над собой работаю — по капле выдавливаю из себя динозавра :-)
Все-таки истина где-то посередине. В современном мире надо владеть современными технологиями, но и не забывать а базовых навыках.
Все-таки истина где-то посередине. В современном мире надо владеть современными технологиями, но и не забывать а базовых навыках.
Пользоваться чем-либо надо только тогда, когда четко понял, что это что тебе надо. А это понимание диктуется ТЗ, Проектом, Требованиями, Бюджетом и многими многими другими факторами. Если у Вас требование написать быстро, пусть даже в ущерб скорости выполнения не думаю, что вы сядете за реализацию чего-либо.
Чаще задавайте себе вопрос перед действием: «Почему это надо делать?».
Чаще задавайте себе вопрос перед действием: «Почему это надо делать?».
Нужно руководствоваться не тем, что вам проще, а что проще в сопровождении.
>>маленький механизм для данной конкретной ситуации
А потом потребуется еще один маленький механизм для реализации похожей, но не совсем такой ситуации. И еще один. И еще. А потом эти механизмы не разгрести будет.
>>маленький механизм для данной конкретной ситуации
А потом потребуется еще один маленький механизм для реализации похожей, но не совсем такой ситуации. И еще один. И еще. А потом эти механизмы не разгрести будет.
>>еще один маленький механизм для реализации похожей, но не совсем такой ситуации
Поверьте, если у этих механизмов найдется хоть что-то общее, всегда можно провести рефакторинг/реинжиниринг, выделить общие части и сделать их одним, более гибким механизмом. Гораздо хуже, когда я, завязавшись на некий чужой фреймворк, сталкиваюсь с «похожей, но не совсем такой ситуацией» и с грустью узнаю, что обработку такой ситуации фреймворк не предусматривает. И тут уже может начаться изобретение таких велосипедов, что два (а даже и три!) раздельных маленьких механизма по сравнению с ними — гораздо меньшее зло. Я не против использования каких-то общепризнанных гибких и удобных готовых решений. Я лишь хочу сказать, что, во-первых, научиться эффективно и качественно применять такие решения не сильно проще, чем научиться самому создавать подобные решения, а во-вторых, в любых решениях всегда есть и ошибки, и неочевидные с первого взгляда ограничения, что добавляет рисков, когда мы решаем взять какое-то готовое решение в качестве фундамента для нашего приложения. Не стоит забывать и о проблемах сопровождения: свой код сопровождать всегда проще
Поверьте, если у этих механизмов найдется хоть что-то общее, всегда можно провести рефакторинг/реинжиниринг, выделить общие части и сделать их одним, более гибким механизмом. Гораздо хуже, когда я, завязавшись на некий чужой фреймворк, сталкиваюсь с «похожей, но не совсем такой ситуацией» и с грустью узнаю, что обработку такой ситуации фреймворк не предусматривает. И тут уже может начаться изобретение таких велосипедов, что два (а даже и три!) раздельных маленьких механизма по сравнению с ними — гораздо меньшее зло. Я не против использования каких-то общепризнанных гибких и удобных готовых решений. Я лишь хочу сказать, что, во-первых, научиться эффективно и качественно применять такие решения не сильно проще, чем научиться самому создавать подобные решения, а во-вторых, в любых решениях всегда есть и ошибки, и неочевидные с первого взгляда ограничения, что добавляет рисков, когда мы решаем взять какое-то готовое решение в качестве фундамента для нашего приложения. Не стоит забывать и о проблемах сопровождения: свой код сопровождать всегда проще
>>Свой код сопровождать проще
Вы в одиночку делаете проекты? Тогда понятно. Только если после вас проект будет сопровождать другой программист, для него этот код своим уже не будет.
Мне легче сопровождать проект, который сделан на известном фреймворке(даже если я его не знаю), чем изобретенном noname чуваком.
>>обработку такой ситуации фреймворк не предусматривает
Фреймворк реализует базовый функционал низкого уровня, остальное — надстраивай, расширяй, бизнес-логика само собой вся самописная.
>>в любых решениях всегда есть и ошибки, и неочевидные с первого взгляда ограничения
Вы считаете, что в вашем велосипеде не будет таковых?
Ограничения фреймворка вполне закономерны и полезны. Это рамки, при выходе за которые фреймворк как бы говорит тебе — «ты начинаешь писать говнокод, вернись и подумай как использовать существующие механизмы».
Если ядро не накладывает ограничений, то ядра как такового и нет. Есть спагетти-код, с которым можно делать все что хочешь — полная свобода.
Вы в одиночку делаете проекты? Тогда понятно. Только если после вас проект будет сопровождать другой программист, для него этот код своим уже не будет.
Мне легче сопровождать проект, который сделан на известном фреймворке(даже если я его не знаю), чем изобретенном noname чуваком.
>>обработку такой ситуации фреймворк не предусматривает
Фреймворк реализует базовый функционал низкого уровня, остальное — надстраивай, расширяй, бизнес-логика само собой вся самописная.
>>в любых решениях всегда есть и ошибки, и неочевидные с первого взгляда ограничения
Вы считаете, что в вашем велосипеде не будет таковых?
Ограничения фреймворка вполне закономерны и полезны. Это рамки, при выходе за которые фреймворк как бы говорит тебе — «ты начинаешь писать говнокод, вернись и подумай как использовать существующие механизмы».
Если ядро не накладывает ограничений, то ядра как такового и нет. Есть спагетти-код, с которым можно делать все что хочешь — полная свобода.
Фреймворк реализует базовый функционал низкого уровня, остальное — надстраивай, расширяй, бизнес-логика само собой вся самописная.
Не каждый фреймворк предлагает удобный механизм расширения/изменения базовой функциональности — хуки, декораторы, и прочее middleware. А если предлагает, то, ка правило, весьма тормозной оказывается.
Не каждый фреймворк предлагает удобный механизм расширения/изменения базовой функциональности — хуки, декораторы, и прочее middleware. А если предлагает, то, ка правило, весьма тормозной оказывается.
Скажу честно — соблазн делать так, как Вы, велик.
Ничего личного, но вряд ли Вы динозавр от этого, скорее Вы себя переоцениваете и пишите очередной велосипед, в итоге от этого страдает весь проект. Знаю об этом не понаслышке и бью себя по рукам, когда хочу написать в очередной раз свой фреймворк(«маленький механизм для данной конкретной ситуации»).
Ничего личного, но вряд ли Вы динозавр от этого, скорее Вы себя переоцениваете и пишите очередной велосипед, в итоге от этого страдает весь проект. Знаю об этом не понаслышке и бью себя по рукам, когда хочу написать в очередной раз свой фреймворк(«маленький механизм для данной конкретной ситуации»).
И вы тоже впадаете в крайность.
Разнообразные фреймоврки, билдеры и конструкторы просто позволяют большему количеству народа вкусить прелести, прежде доступные лишь посвященным. Это не ставит разные системы на одну доску, но человек, который взял и воплотил свою задумку в реальность — программист и не важно сделал он это в вижуал билдере или на ассемблере. Так же как и не важно знает ли он какой-нить пузырек или поиск подстроки, если результат на лице.
Да, качество может быть разным — профи сделает быстрее и лучше, а любитель — хуже, но оба будут при этом программистами.
Разнообразные фреймоврки, билдеры и конструкторы просто позволяют большему количеству народа вкусить прелести, прежде доступные лишь посвященным. Это не ставит разные системы на одну доску, но человек, который взял и воплотил свою задумку в реальность — программист и не важно сделал он это в вижуал билдере или на ассемблере. Так же как и не важно знает ли он какой-нить пузырек или поиск подстроки, если результат на лице.
Да, качество может быть разным — профи сделает быстрее и лучше, а любитель — хуже, но оба будут при этом программистами.
Боюсь, что не совсем уловили ту мысль, которую я хотел донести.
Хотя бы потому, что профи простую задачу, скорее всего, будет делать дольше любителя :-)
Хотя бы потому, что профи простую задачу, скорее всего, будет делать дольше любителя :-)
С точки зрения того что такое программирование — это несущественные мелочи.
Важно не то как и на чем и сколько данный индивид решал данную задачу. Важно что он увидел в этом задачу, свог ее формализовать и придумать как решить и реализовал. Все! Пусть хоть пирамиду для этого строит, важен результат — если пирамида может решить проблему, значить ее создатель — программист.
Важно не то как и на чем и сколько данный индивид решал данную задачу. Важно что он увидел в этом задачу, свог ее формализовать и придумать как решить и реализовал. Все! Пусть хоть пирамиду для этого строит, важен результат — если пирамида может решить проблему, значить ее создатель — программист.
Я думаю, с точки зрения формального подхода — программист — любой, кто грубо говоря делает exe, dll и прочие работающие файлики, не важно как. Ну это если формализовать до абсурда :)
Но нормальный, профессиональный программист сделает не абы как, чтобы работало, не важно, что тормознее на порядок, глючнее, код неподдерживаемый, библиотеки не лучшие (первые попавшиеся под руку), а именно хорошо работало и при этом затратит на задачу разумное количество усилий (что надо написать — напишет, что лучше взять готовое — возьмёт готовое).
У меня в своё время было одно интересное собеседование в отделе тестирования NVidia, где меня просили решить простенькую задачку: и в частности зашла речь о нахождении количества элементов массива. В общем я написал какой-то простой код, где в цикле для всех элементов заново высчитывал это количество (вместо выноса этой величины за цикл). Вроде как бы мелочь — но тормозов это прибавляет огого. А потом мне ещё и рассказали, что на C++ функция вычисления количества элементов массива работает на порядок дольше, чем на паскале… в общем я понял отличие себя от профи программистов :)
Но нормальный, профессиональный программист сделает не абы как, чтобы работало, не важно, что тормознее на порядок, глючнее, код неподдерживаемый, библиотеки не лучшие (первые попавшиеся под руку), а именно хорошо работало и при этом затратит на задачу разумное количество усилий (что надо написать — напишет, что лучше взять готовое — возьмёт готовое).
У меня в своё время было одно интересное собеседование в отделе тестирования NVidia, где меня просили решить простенькую задачку: и в частности зашла речь о нахождении количества элементов массива. В общем я написал какой-то простой код, где в цикле для всех элементов заново высчитывал это количество (вместо выноса этой величины за цикл). Вроде как бы мелочь — но тормозов это прибавляет огого. А потом мне ещё и рассказали, что на C++ функция вычисления количества элементов массива работает на порядок дольше, чем на паскале… в общем я понял отличие себя от профи программистов :)
Ну, есть те кто делает хобби профессией, а есть те кто нет.
Если ты требуешь за свою работу денег, то наверно ожидать что к ней будут применяться определенные требования.
С другой стороны история знает кучу примеров, когда любители делали лучше чем профи.
А насчет абсурда — это именно так, ну почти, если забыть что «exe» файл делает компилятор, которому программист подсовывает программу, которую надо бы еще и написать, перед чем неплохо бы понять зачем.
Если ты требуешь за свою работу денег, то наверно ожидать что к ней будут применяться определенные требования.
С другой стороны история знает кучу примеров, когда любители делали лучше чем профи.
А насчет абсурда — это именно так, ну почти, если забыть что «exe» файл делает компилятор, которому программист подсовывает программу, которую надо бы еще и написать, перед чем неплохо бы понять зачем.
ИМХО, проблема немножко в другом!
На данный момент в мире программы охватывают все больший и больший сектор применения и, имея программистов которые отлично разбираются в написании драйверов на ассемблере, но не могут збацать за пол часа сайт с картинками, невозможно удовлетворить спрос в программах!
Развитие данного сектора создает огромное кол-во областей где нужны дедикейтед персоны для реализации. Другими словами понятие программист просто потихоньку размывается и преобретает все более обширный смысл!
На данный момент в мире программы охватывают все больший и больший сектор применения и, имея программистов которые отлично разбираются в написании драйверов на ассемблере, но не могут збацать за пол часа сайт с картинками, невозможно удовлетворить спрос в программах!
Развитие данного сектора создает огромное кол-во областей где нужны дедикейтед персоны для реализации. Другими словами понятие программист просто потихоньку размывается и преобретает все более обширный смысл!
Автору — спасибо. Оказывается, можно и без агрессии)
Язык и стандарты весьма сильно влияют на ваш теоретический каркас и набор концептов, которыми вы оперируете. Функциональное программирование весьма серьезно отличается по подходам от императивного, также как синхронное от асинхронного, также как однопоточное от многопоточного.
Абстрагироваться можно лишь в рамках определенной методологии. Возьмите Erlang и OTP — вы не найдете в нем ничего общего с PHP/всякими фреймворками к нему, так как сама методология другая.
Абстрагироваться можно лишь в рамках определенной методологии. Возьмите Erlang и OTP — вы не найдете в нем ничего общего с PHP/всякими фреймворками к нему, так как сама методология другая.
Не мог пройти мимо этой статьи.
Уважаемый автор, не могли бы вы пояснить, что в этом списке делают «скриптовые языки»? Точнее не так, объясните мне, чем (даже в рамках написанного вами в статье) программирование на скриптовых языках отличается, по сути, от написания программ на С? Динамической типизацией? Управляемой памятью? Организацией работы с данными?
Мне вот интересно, неужели кто-то действительно думает, что проставлять тип перед переменной и указывать тип результата функции/метода это сложно? Или что сложно аллоцировать память перед использованием переменной определенного типа? Другой вопрос, в каких задачах это может быть плюсом, а в каких — минусом. Но тем не менее.
Я считаю, что это не более, чем частности, не более, чем какие-то признаки языка и сферы, в которой его можно использовать. Я, конечно, понимаю, что на JavaScript и PHP написать драйвер невозможно. Лично для меня интерпретируемые языки отличаются от компелируемых только наличием в первых eval-функций, которые я никогда в жизни не использовал, по правде говоря. В остальном же отличие скорее надуманное, потому что программирование, по сути, везде одинаковое. Просто в рамках одних проектов проще взять какие-то части (организация работы веб-сервера, организация работы клиента) как «черный ящик» и программировать другие части системы, бизнес-логику. Это все входит в одно большое понятие эффективности.
По моему мнению, языки программирования можно поделить только на такие группы — низкоуровневое программирование (ассемблеры), декларативное программирование и императивное программирование. Даже функциональное и процедурное, объектно-ориентированное, прототипно-ориентированное и что-то еще -ориентированное, это лишь признаки языка. Это становится очевидно тогда, когда на функциональных языках решаются императивные задачи, например. Все остальные отличия — статическая типизация, замыкания, динамическое классовое ООП, динамическое ООП на конструкторах — все это лишь частные случаи каких-то реализаций и на само программирование оказывают разве что косвенное влияние. Так же, как и разные разговорные языки почти не оказывают влияние на какую-то конкретную обсуждаемую тему.
Я считаю, что современные средства разработки, фреймворки, скриптовые языки и множество доступных библиотек, решающих почти любую прикладную задачу
Уважаемый автор, не могли бы вы пояснить, что в этом списке делают «скриптовые языки»? Точнее не так, объясните мне, чем (даже в рамках написанного вами в статье) программирование на скриптовых языках отличается, по сути, от написания программ на С? Динамической типизацией? Управляемой памятью? Организацией работы с данными?
Мне вот интересно, неужели кто-то действительно думает, что проставлять тип перед переменной и указывать тип результата функции/метода это сложно? Или что сложно аллоцировать память перед использованием переменной определенного типа? Другой вопрос, в каких задачах это может быть плюсом, а в каких — минусом. Но тем не менее.
Я считаю, что это не более, чем частности, не более, чем какие-то признаки языка и сферы, в которой его можно использовать. Я, конечно, понимаю, что на JavaScript и PHP написать драйвер невозможно. Лично для меня интерпретируемые языки отличаются от компелируемых только наличием в первых eval-функций, которые я никогда в жизни не использовал, по правде говоря. В остальном же отличие скорее надуманное, потому что программирование, по сути, везде одинаковое. Просто в рамках одних проектов проще взять какие-то части (организация работы веб-сервера, организация работы клиента) как «черный ящик» и программировать другие части системы, бизнес-логику. Это все входит в одно большое понятие эффективности.
По моему мнению, языки программирования можно поделить только на такие группы — низкоуровневое программирование (ассемблеры), декларативное программирование и императивное программирование. Даже функциональное и процедурное, объектно-ориентированное, прототипно-ориентированное и что-то еще -ориентированное, это лишь признаки языка. Это становится очевидно тогда, когда на функциональных языках решаются императивные задачи, например. Все остальные отличия — статическая типизация, замыкания, динамическое классовое ООП, динамическое ООП на конструкторах — все это лишь частные случаи каких-то реализаций и на само программирование оказывают разве что косвенное влияние. Так же, как и разные разговорные языки почти не оказывают влияние на какую-то конкретную обсуждаемую тему.
Я упомянул в этом ряду скриптовые языки, как средства программирования высокого уровня абстракции. В некоторых случаях они позволяют лучше сосредоточиться на задаче, не заботясь вопросами управления памятью и точностью синтаксических конструкций.
Кроме этого, программирование на интерпретируемых языках очень сильно отличается от программирования на пресловутом С тем, что интерпретируемая программа существенно более динамична. Есть возможность сконструировать объект на лету, приделать к нему требуемые методы, собрав их реализацию по кусочкам, и передать такой объект дальше. Конечно, и на С это можно сделать, но там для этого придется вывернуть мозг наизнанку, а здесь это является нормальным функционалом.
Кроме этого, программирование на интерпретируемых языках очень сильно отличается от программирования на пресловутом С тем, что интерпретируемая программа существенно более динамична. Есть возможность сконструировать объект на лету, приделать к нему требуемые методы, собрав их реализацию по кусочкам, и передать такой объект дальше. Конечно, и на С это можно сделать, но там для этого придется вывернуть мозг наизнанку, а здесь это является нормальным функционалом.
Ручное управление пямятью — программирование, автоматическое управление памятью — не программирование. Я правильно уловил мысль? То, что на С нельзя сконструировать объект на лету (ведь С вообще не объектно-ориентирован, но не важно, пускай Object-C), это плюс или минус? Знание того, сколько памяти и как выделяется при создании структуры данных, это часть программирования? Сам процесс аллоцирования/очистки памяти как-то относится вообще к самому программированию?
Мне кажется, что это скорее как ручная и автоматическая коробка передач. Вроде бы принцип разный, но по городу едут все одинаково.
Мне кажется, что это скорее как ручная и автоматическая коробка передач. Вроде бы принцип разный, но по городу едут все одинаково.
:-) Чувствую какой-то негатив, и сразу хочется сказать: Ребята, давайте жить дружно!
а теперь по порядку.
1. я не хочу обсуждать достоинства и недостатки языков программирования. каждый из них создан для какой-то задачи, сравнивать их часто просто бессмысленно
2. я пытался объяснить, почему я упомянул скриптовые языки. Я это сделал потому, что, на мой взгляд, их появление кардинально изменило жизнь программиста. Порог входа в них очень низок, а потенциальные возможности велики.
3. Если касаться управления памятью — то тут, как и везде. все зависит от ситуации. В какой-то ситуации мне важно удержать количество потребляемой памяти в определенных рамках, я придумываю свой менеджер памяти. В каких-то ситуациях мой опыт подсказывает мне, что возможностей стандартного сборщика мусора будет достаточно — и я опираюсь на него, сосредотачивая свои усилия на взаимосвязях между объектами.
Ключевая мысль, которую я пытался донести, заключается в том, что программирование — это не просто складывание конструктора лего из готовых кусочков. Что тут есть место и для создания своих кусочков. А изучение разных систем связывания этих кусочков позволяет придумывать более интересные решения.
а теперь по порядку.
1. я не хочу обсуждать достоинства и недостатки языков программирования. каждый из них создан для какой-то задачи, сравнивать их часто просто бессмысленно
2. я пытался объяснить, почему я упомянул скриптовые языки. Я это сделал потому, что, на мой взгляд, их появление кардинально изменило жизнь программиста. Порог входа в них очень низок, а потенциальные возможности велики.
3. Если касаться управления памятью — то тут, как и везде. все зависит от ситуации. В какой-то ситуации мне важно удержать количество потребляемой памяти в определенных рамках, я придумываю свой менеджер памяти. В каких-то ситуациях мой опыт подсказывает мне, что возможностей стандартного сборщика мусора будет достаточно — и я опираюсь на него, сосредотачивая свои усилия на взаимосвязях между объектами.
Ключевая мысль, которую я пытался донести, заключается в том, что программирование — это не просто складывание конструктора лего из готовых кусочков. Что тут есть место и для создания своих кусочков. А изучение разных систем связывания этих кусочков позволяет придумывать более интересные решения.
Прошу прощения, никакого негатива. Просто на самом деле, по личному опыту, самой большой моей ошибкой десяток лет назад было изучения программирования с паскаля, который имеет огромный порог вхожения. Еще одной ошибкой было после этого пытаться выучить С. Еще одна ошибка, что в ВУЗах преподают разработку под коммерческую платформу Delphi, в которой порог вхождения еще выше.
Если даже не рассматривать удобство скриптовых языков, я считаю, что в них есть и огромный потенциал для обучения программистов. Гораздо проще давать материал по программированию, начиная со скриптовых динамических языков, объясняя базовые типы, циклы, алгоритмы, объектно-ориентированное программирование, а уже потом объяснять, как это все работает на уровне памяти, на уровне процессора, в чем польза и вред динамической типизации и сборщиков мусора, объяснять, какие типы как хранятся в памяти и уже после этого давать компилируемые статические языки, или C#, например.
Вам может показаться это довольно странным, но я сам, после неудачных попыток взять программирование, начиная с паскаля и С (если не считать бейсик еще раньше, конечно), перешел на скриптовые языки, а уже потом легко смог усвоить то, как это все работает внутри и без проблем перешел на компилируемые, зная весь «фундамент» самого программирования, на примере скриптовых языков. И мне это не мешало интересоваться парадигмами программирования, в т.ч. функциональным подходом. И никаких проблем с необходимостью указывать типы переменных и управлять памятью у меня не было. А проблемы были только изначально, с пониманием того, как вообще программируют. И освоить это сразу на С или (не дай бог) на C++ — задача довольно сложная.
Если даже не рассматривать удобство скриптовых языков, я считаю, что в них есть и огромный потенциал для обучения программистов. Гораздо проще давать материал по программированию, начиная со скриптовых динамических языков, объясняя базовые типы, циклы, алгоритмы, объектно-ориентированное программирование, а уже потом объяснять, как это все работает на уровне памяти, на уровне процессора, в чем польза и вред динамической типизации и сборщиков мусора, объяснять, какие типы как хранятся в памяти и уже после этого давать компилируемые статические языки, или C#, например.
Вам может показаться это довольно странным, но я сам, после неудачных попыток взять программирование, начиная с паскаля и С (если не считать бейсик еще раньше, конечно), перешел на скриптовые языки, а уже потом легко смог усвоить то, как это все работает внутри и без проблем перешел на компилируемые, зная весь «фундамент» самого программирования, на примере скриптовых языков. И мне это не мешало интересоваться парадигмами программирования, в т.ч. функциональным подходом. И никаких проблем с необходимостью указывать типы переменных и управлять памятью у меня не было. А проблемы были только изначально, с пониманием того, как вообще программируют. И освоить это сразу на С или (не дай бог) на C++ — задача довольно сложная.
Полностью с Вами согласен, и в плане удобства обучения и в плане сложности освоения С. И про это я тоже писал в статье — высокий порог вхождения в профессию задавал определенную планку. И еще Кнут в своей книге приводил примеры не на С, а на некотором псевдоязыке, призванном только иллюстрировать описываемые концепты.
Надо сказать, что паскаль в свое время считался очень простым языком — он был создан как раз таки для обучения программированию.
Ну, и чтобы подытожить: программирование — это не автоматическое и не ручное управления памятью, это, в первую очередь, понимание того, что есть на свете такая штука, как память, и ей надо управлять.
Надо сказать, что паскаль в свое время считался очень простым языком — он был создан как раз таки для обучения программированию.
Ну, и чтобы подытожить: программирование — это не автоматическое и не ручное управления памятью, это, в первую очередь, понимание того, что есть на свете такая штука, как память, и ей надо управлять.
Между прочим, С и Паскаль появились почти одновременно. И то, что Паскаль изначально был простым — это факт, тем не менее, он был простым только в рамках концепции существующих тогда языков программирования и задач, которые тогда вставали в программировании и вообще для того времени (1970 год), когда программирование было чем-то более научным (самоучек было очень мало).
Тем не менее, сейчас паскаль не эффективен, не для работы, не для изучения, по крайней мере — первоначального. Что касается планки, задачи перед программистами, в 70ых стояли куда более простые, чем сейчас. Достаточно было уметь писать небольшие утилиты и простейшие драйверы, чтобы работать в microsoft в 80ых в должности ведущего программиста. Но это на самом деле все не так важно.
Скажите мне хотя бы одну задачу программирования, какой-нибудь алгоритм, за исключением самой задачи управления памятью, в которой бы это управление было частью непосредственного программирования, а не рутинной операцией или оптимизацией?
Тем не менее, сейчас паскаль не эффективен, не для работы, не для изучения, по крайней мере — первоначального. Что касается планки, задачи перед программистами, в 70ых стояли куда более простые, чем сейчас. Достаточно было уметь писать небольшие утилиты и простейшие драйверы, чтобы работать в microsoft в 80ых в должности ведущего программиста. Но это на самом деле все не так важно.
Скажите мне хотя бы одну задачу программирования, какой-нибудь алгоритм, за исключением самой задачи управления памятью, в которой бы это управление было частью непосредственного программирования, а не рутинной операцией или оптимизацией?
самоучек было очень мало
Мне как-то казалось, что ровно наоборот, что практически все программисты были самоучками в то время. Математики, электронщики, ученые и инженеры в других областях, но не программисты по образованию.
Мне как-то казалось, что ровно наоборот, что практически все программисты были самоучками в то время. Математики, электронщики, ученые и инженеры в других областях, но не программисты по образованию.
>>Скажите мне хотя бы одну задачу программирования, какой-нибудь алгоритм, за исключением самой задачи управления памятью, в которой бы это управление было частью непосредственного программирования, а не рутинной операцией или оптимизацией?
Ну на самом деле таких алгоритмов довольно много :) Например, собственная реализация BlockingCollection (thread-safe коллекция, в которую могут писать и читать сразу несколько потоков) на основе lock-free структур — как раз таки требует довольно нетривиального управления памятью ;)
Ну на самом деле таких алгоритмов довольно много :) Например, собственная реализация BlockingCollection (thread-safe коллекция, в которую могут писать и читать сразу несколько потоков) на основе lock-free структур — как раз таки требует довольно нетривиального управления памятью ;)
Ну например, в одной системе для статистического анализа данных, я реализовывал хитрый кэш, для которого требовалось, с одной стороны быстрый доступ, а с другой стороны — не сожрать всю доступную память. Так что там присутствовал эвристический алгоритм вытеснения и принудительной выгрузки «лишних» элементов.
Я почему-то думаю, что всё же лучше обучать сразу на С. Хотя в принципе не важно, на каком языке, но второй этап легче будет даваться.
Т.е. на первом этапе нужно изучить базовые алгоритмы, без работы с динамической памятью. Циклы, ветвления, побегать по массивам. Если на этом этапе не грузить студента всеми прелестями (т.е. сложностями) С, а ограничить работу только со стеком и несколькими типами, и настаивать, что это занятия не по С, а только по базовым вещам, то язык в принципе не так и отличаться будет от паскаля.
Вторым этапом уже гоняют по алгоритмам, по работе с памятью. А если еще потом плюсы приплесть, так у студента должно сложиться отвращение к такой работе. Вот тут под это дело уже можно давать языки со сборкой мусора и функциональные языки. И учить студентов уже мыслить правильно, не писать говнокод, не стремиться к оптимизации, как к самоцели. Если они это не попробуют, не напишут пару задач или курсовых через ж, то так и будут потом писать.
Такой путь обучения, конечно, спорный. Как бы изучается лишнее. А некоторые могут застрять на начальных этапах и не понять, что хорошо, а что плохо. Но я не вижу выхода. И база нужна, и понимание, как работает память, и понимание, как работают компиляторы, СУБД, чтобы потом уметь ими пользоваться, писать простой код и не брать на себя лишнюю ответственность в плане написаний велосипедов.
Т.е. на первом этапе нужно изучить базовые алгоритмы, без работы с динамической памятью. Циклы, ветвления, побегать по массивам. Если на этом этапе не грузить студента всеми прелестями (т.е. сложностями) С, а ограничить работу только со стеком и несколькими типами, и настаивать, что это занятия не по С, а только по базовым вещам, то язык в принципе не так и отличаться будет от паскаля.
Вторым этапом уже гоняют по алгоритмам, по работе с памятью. А если еще потом плюсы приплесть, так у студента должно сложиться отвращение к такой работе. Вот тут под это дело уже можно давать языки со сборкой мусора и функциональные языки. И учить студентов уже мыслить правильно, не писать говнокод, не стремиться к оптимизации, как к самоцели. Если они это не попробуют, не напишут пару задач или курсовых через ж, то так и будут потом писать.
Такой путь обучения, конечно, спорный. Как бы изучается лишнее. А некоторые могут застрять на начальных этапах и не понять, что хорошо, а что плохо. Но я не вижу выхода. И база нужна, и понимание, как работает память, и понимание, как работают компиляторы, СУБД, чтобы потом уметь ими пользоваться, писать простой код и не брать на себя лишнюю ответственность в плане написаний велосипедов.
Ну да, возможно вы правы. Тогда учить детей говорить тоже стоит со старославянского, чтобы они понимали, как образовались современные словоформы, или лучше с какого-нибудь более древного языка индоевропеской группы, из которого появился славянский. А уже в институте потом давать русский язык, чтобы они понимали, о чем говорят.
Да и вообще, что касается институтов, я считаю, что профильное образование должен получать человек, который уже знаком с программированием (на начальном уровне) до поступления. Как и с математикой, например. Давать в институте на первом курсе введение в программирование в духе «hello, world!», с современным уровнем развития интернета (в роли информационного пособия), это какой-то абсурд. Из моего ВУЗа, например, те, кто никогда не сталкивались с программированием до ВУЗа, по всей видимости, больше никогда в жизни с ним не столкнутся.
Да и вообще, что касается институтов, я считаю, что профильное образование должен получать человек, который уже знаком с программированием (на начальном уровне) до поступления. Как и с математикой, например. Давать в институте на первом курсе введение в программирование в духе «hello, world!», с современным уровнем развития интернета (в роли информационного пособия), это какой-то абсурд. Из моего ВУЗа, например, те, кто никогда не сталкивались с программированием до ВУЗа, по всей видимости, больше никогда в жизни с ним не столкнутся.
возможно мои взгляды устарели. Возможно надо начинать с SICP, со Scheme.
Но все же зная нашу реальность, я пока думаю, что С подойдет. Да и вообще говорю про то, как с нуля надо изучать. В вузах всё равно будут изучать циклы и ветвления, будут обязательно повторять.
Да и в школах хотя всё больше и больше выделяется на «информатику», на само программирование всё меньше и меньше.
Потом, я сам не знаю другого пути, потому что такой приблизительно прошел. Начинал изучать на древнем бейсике. Когда еще строки нумеровались. Потом паскаль. Потом С, потом плюсы, потом шарп, потом функциональный, потом снова шарп.
В этой цепочке явно лишним был бейсик и паскаль. Можно было сократить время, начиная с С.
А с другой стороны работаю с людьми, которые чуть ли не помешаны на оптимизациях. Откровенную чушь городят, делая наивные предположения как работают компиляторы и СУБД. И всё стремятся оптимизировать зараннее. Думая, что они умнее, смогут обмануть, сделать лучше свой велосипед. Мечтают в памяти работать, с многопоточностью и т.д. и т.п. причем делая это совершенно не обоснованно, делая необоснованные предварительные предположения, что оптимально, что нет.
В результате жесткий говнокод получается. И суть в том, что у людей не было опыта в написании оптимальных программ. Нет понимания, как может оптимизировать компилятор. Нет понимания, как этот процесс проводить. И из-за этого странная страсть это делать. И фанатичное убеждение, что говнокод — это код, который работает медленно (при первом его создании).
Как с этим бороться? Наверное, надо сразу дать на своей шкуре прочувствовать и научить выбирать нужные инструменты.
Но все же зная нашу реальность, я пока думаю, что С подойдет. Да и вообще говорю про то, как с нуля надо изучать. В вузах всё равно будут изучать циклы и ветвления, будут обязательно повторять.
Да и в школах хотя всё больше и больше выделяется на «информатику», на само программирование всё меньше и меньше.
Потом, я сам не знаю другого пути, потому что такой приблизительно прошел. Начинал изучать на древнем бейсике. Когда еще строки нумеровались. Потом паскаль. Потом С, потом плюсы, потом шарп, потом функциональный, потом снова шарп.
В этой цепочке явно лишним был бейсик и паскаль. Можно было сократить время, начиная с С.
А с другой стороны работаю с людьми, которые чуть ли не помешаны на оптимизациях. Откровенную чушь городят, делая наивные предположения как работают компиляторы и СУБД. И всё стремятся оптимизировать зараннее. Думая, что они умнее, смогут обмануть, сделать лучше свой велосипед. Мечтают в памяти работать, с многопоточностью и т.д. и т.п. причем делая это совершенно не обоснованно, делая необоснованные предварительные предположения, что оптимально, что нет.
В результате жесткий говнокод получается. И суть в том, что у людей не было опыта в написании оптимальных программ. Нет понимания, как может оптимизировать компилятор. Нет понимания, как этот процесс проводить. И из-за этого странная страсть это делать. И фанатичное убеждение, что говнокод — это код, который работает медленно (при первом его создании).
Как с этим бороться? Наверное, надо сразу дать на своей шкуре прочувствовать и научить выбирать нужные инструменты.
Курсы вождения, по всей видимости, тоже стоит начинать с курсов добычи руды. Иначе просто невозможно человека научить ездить не слишком медленно и не слишком быстро, а еще соблюдать ПДД.
Я, на самом деле, никого не хочу задеть своими комментариями, они, кстати говоря, вполне в рамках темы статьи — программирование везде одно, ставить ли типы перед переменными, или не ставить. Просто на самом деле для первого знакомства с программированием явно не подходят такие языки, как С и С++, которые явно имеют признаки оптимизационных приемов, например, полного ручного управления памятью, которое сейчас можно рассматривать, как оптимизационное решение, в эпоху .NET и C#. Начинающему программисту не нужно учиться управлять памятью, если во многих задачах это эффективно делает и сам компилятор/виртуальная машина.
Эти возможности могут помочь при создании оптимизированных программ, но не факт, что это нужно абсолютно всем и каждому, в каждой задаче. Тем более, что это уже более высокий уровень понимания, высшая лига, по сравнению с базовыми знаниями, которые, повторюсь, во много раз легче освоить на динамических языках.
Я, на самом деле, никого не хочу задеть своими комментариями, они, кстати говоря, вполне в рамках темы статьи — программирование везде одно, ставить ли типы перед переменными, или не ставить. Просто на самом деле для первого знакомства с программированием явно не подходят такие языки, как С и С++, которые явно имеют признаки оптимизационных приемов, например, полного ручного управления памятью, которое сейчас можно рассматривать, как оптимизационное решение, в эпоху .NET и C#. Начинающему программисту не нужно учиться управлять памятью, если во многих задачах это эффективно делает и сам компилятор/виртуальная машина.
Эти возможности могут помочь при создании оптимизированных программ, но не факт, что это нужно абсолютно всем и каждому, в каждой задаче. Тем более, что это уже более высокий уровень понимания, высшая лига, по сравнению с базовыми знаниями, которые, повторюсь, во много раз легче освоить на динамических языках.
а я и сказал, что сразу не надо учить работать с динамической памятью на С.
Там можно вполне не работать, а работать со стеком. Но поработать с ней надо. Тем более, что это не так и сложно. В эпоху .Net и C# как раз надо понимать, что такое ссылка и что такое куча. Чтобы хотя бы понимать, почему при передаче объекта в метод, изменение его состояния внутри метода, отразится на состоянии переданного объекта (что это не две копии). И нет ничего лучше, чем поработать с сырой памятью, понять, как это работает и заодно понять, как это плохо так программировать.
Потом, как раз о том статья, что программисты должны обладать некоторым кругозором и базовыми знаниями. Не потому, что они в работе каждый день нужны, а потому, чтобы легче и без заблуждений изучать новые технологии. ВУЗы отличаются от техникумов тем, что дают побольше знаний, чем просто узконаправленный специалист.
Нет, возможно, я ошибаюсь в последовательности обучения. Возможно, нужно мышление сразу правильным ставить и начинать с направлений более приоритетных. Но если уже начинают с императивного программирования (не важно, динамический скриптовый язык), то почему не с С.
И не вижу никаких оснований считать С высшей лигой. А может и к лучшему, если студенты не могут это сразу понять. Отсевать надо. А то потом работай с ними )) Если они того не могли понять, то что об остальном говорить.
Вам просто, возможно, плохо объясняли или плохие книги попались, что вы отнеслись к языку так, что у него высокий порог вхождения. В результате преподавания не требуется научить студента его знать досконально и не требуется научить его прямо стилю работы на этом языке.
А вот как раз начать с С#, я бы не стал. Шарп — это в первую очередь дотнет с огромной библиотекой. И там по стилю и по смыслу чем меньше люди пишут алгоритмы — тем лучше. Типы уже есть. Всё что надо есть. Сортировки есть. Списки, хеш-таблицы — есть.
Его или подобный язык уместно в курсе ООП изучать. Но это ж не сразу. Потом, ООП в шарпе (Джава, плюсы) — это такой себе синтаксический сахар над императивным программированием с маленькими вкраплениями функционального. ООП не стоит изучать сразу. Оно не является элементарным. Не зная алгоритмов чистыми классами (без методов) ничего не напишешь.
Так что шарп и джава не подходят для обучения на начальном этапе. Прививать желание писать алгоритмы на шарпе — не хорошо.
Там можно вполне не работать, а работать со стеком. Но поработать с ней надо. Тем более, что это не так и сложно. В эпоху .Net и C# как раз надо понимать, что такое ссылка и что такое куча. Чтобы хотя бы понимать, почему при передаче объекта в метод, изменение его состояния внутри метода, отразится на состоянии переданного объекта (что это не две копии). И нет ничего лучше, чем поработать с сырой памятью, понять, как это работает и заодно понять, как это плохо так программировать.
Потом, как раз о том статья, что программисты должны обладать некоторым кругозором и базовыми знаниями. Не потому, что они в работе каждый день нужны, а потому, чтобы легче и без заблуждений изучать новые технологии. ВУЗы отличаются от техникумов тем, что дают побольше знаний, чем просто узконаправленный специалист.
Нет, возможно, я ошибаюсь в последовательности обучения. Возможно, нужно мышление сразу правильным ставить и начинать с направлений более приоритетных. Но если уже начинают с императивного программирования (не важно, динамический скриптовый язык), то почему не с С.
И не вижу никаких оснований считать С высшей лигой. А может и к лучшему, если студенты не могут это сразу понять. Отсевать надо. А то потом работай с ними )) Если они того не могли понять, то что об остальном говорить.
Вам просто, возможно, плохо объясняли или плохие книги попались, что вы отнеслись к языку так, что у него высокий порог вхождения. В результате преподавания не требуется научить студента его знать досконально и не требуется научить его прямо стилю работы на этом языке.
А вот как раз начать с С#, я бы не стал. Шарп — это в первую очередь дотнет с огромной библиотекой. И там по стилю и по смыслу чем меньше люди пишут алгоритмы — тем лучше. Типы уже есть. Всё что надо есть. Сортировки есть. Списки, хеш-таблицы — есть.
Его или подобный язык уместно в курсе ООП изучать. Но это ж не сразу. Потом, ООП в шарпе (Джава, плюсы) — это такой себе синтаксический сахар над императивным программированием с маленькими вкраплениями функционального. ООП не стоит изучать сразу. Оно не является элементарным. Не зная алгоритмов чистыми классами (без методов) ничего не напишешь.
Так что шарп и джава не подходят для обучения на начальном этапе. Прививать желание писать алгоритмы на шарпе — не хорошо.
Я написал про высшую лигу в своем сообщении, имея в виду ручное управление памятью. На самом деле эта дискуссия не имеет смысла.
Вы говорите про студентов. Я говорю про тех, кто начинает изучать программирование. Студент, который начинает осваивать программирование в ВУЗе уже совсем скоро станет неконкурентоспособным, даже если он не только про ручное управление памятью будет знать к выпуску, но и про стек, адреса возврата, переполнение буффера и о регистрах процессора x86. Учиться никогда не поздно, расширить кругозор можно даже не учась в ВУЗе, а читая документации и практические статьи.
Из вашего примера: рассказать новичку о том, что такое ссылка, гораздо проще, чем рассказать о том, что такое указатель и указатель на указатель. И проще объяснить что такое указатель, рассказав про ссылку. И проще, чем рассказать почему нельзя нормально сделать конкатенацию строк. И почему строка это массив символов, а иногда указатель на массив символов, и чем, в действительности, отличается тип с плавающей точкой от целого числа.
Вы говорите про студентов. Я говорю про тех, кто начинает изучать программирование. Студент, который начинает осваивать программирование в ВУЗе уже совсем скоро станет неконкурентоспособным, даже если он не только про ручное управление памятью будет знать к выпуску, но и про стек, адреса возврата, переполнение буффера и о регистрах процессора x86. Учиться никогда не поздно, расширить кругозор можно даже не учась в ВУЗе, а читая документации и практические статьи.
Из вашего примера: рассказать новичку о том, что такое ссылка, гораздо проще, чем рассказать о том, что такое указатель и указатель на указатель. И проще объяснить что такое указатель, рассказав про ссылку. И проще, чем рассказать почему нельзя нормально сделать конкатенацию строк. И почему строка это массив символов, а иногда указатель на массив символов, и чем, в действительности, отличается тип с плавающей точкой от целого числа.
Э…
Объяснить, что такое указатель — просто. Грубо — адрес. Объяснить, что такое ссылка, если понял, что такое указатель — вроде тоже просто. А объяснить, что такое указатель на указатель… Вы думаете, это не нужно? В шарпе есть такое слово ref, и с помощью него можно передать ссылку на ссылку в метод. Так вот я встречал людей, даже собеседовавших меня, ведущих программистов, которые задавали мне вопросы по ref, но оказывалось, что сами не знали, в чем отличие ссылки и ссылки на ссылку. Дотнет не совсем и тривиальная вещь. Кругом работают с ссылками. Что несет определенные нюансы, даже если не работают с памятью напрямую.
Со строками в С, конечно, лишние проблемы. Но не сложно и пережить. Тем более легче будет объяснить, почему в дотнете задолбались с этим типом и сделали имутабельным. А с числами, ну вроде ж надо знать. Не лишнее. Оно и в других языках где-то так.
Потом, повторю, задачи курса — изучение основ работы с алгоритмами и памятью. А не изучение всех особенностей языка С. Не обязательно опускаться на низкоуровневое программирование. Простые алгоритмы сортировок, беганий по массивам, вполне на стеке реализуются. Структуры данных в куче. Тоже ничего такого страшного из С там не нужно. Кроме указателей. А вот они то и нужны, чтобы понять, как сделать двусвязный список, дерево т.д. Вот и всё, что требуется от курса. Шишки понабивать. Понять принцип.
Без этого особо не поймут, что делает сборщик мусора. И как оно вообще работает. Вообще-то у нас давно не берут на дотнете на работу, если таких вещей кто-то не знает.
А далее, уже ООП с юмлями. ФП.
Объяснить, что такое указатель — просто. Грубо — адрес. Объяснить, что такое ссылка, если понял, что такое указатель — вроде тоже просто. А объяснить, что такое указатель на указатель… Вы думаете, это не нужно? В шарпе есть такое слово ref, и с помощью него можно передать ссылку на ссылку в метод. Так вот я встречал людей, даже собеседовавших меня, ведущих программистов, которые задавали мне вопросы по ref, но оказывалось, что сами не знали, в чем отличие ссылки и ссылки на ссылку. Дотнет не совсем и тривиальная вещь. Кругом работают с ссылками. Что несет определенные нюансы, даже если не работают с памятью напрямую.
Со строками в С, конечно, лишние проблемы. Но не сложно и пережить. Тем более легче будет объяснить, почему в дотнете задолбались с этим типом и сделали имутабельным. А с числами, ну вроде ж надо знать. Не лишнее. Оно и в других языках где-то так.
Потом, повторю, задачи курса — изучение основ работы с алгоритмами и памятью. А не изучение всех особенностей языка С. Не обязательно опускаться на низкоуровневое программирование. Простые алгоритмы сортировок, беганий по массивам, вполне на стеке реализуются. Структуры данных в куче. Тоже ничего такого страшного из С там не нужно. Кроме указателей. А вот они то и нужны, чтобы понять, как сделать двусвязный список, дерево т.д. Вот и всё, что требуется от курса. Шишки понабивать. Понять принцип.
Без этого особо не поймут, что делает сборщик мусора. И как оно вообще работает. Вообще-то у нас давно не берут на дотнете на работу, если таких вещей кто-то не знает.
А далее, уже ООП с юмлями. ФП.
Причем тут берут на работу?
Я говорю о начинающих программистах. Зачем, чтобы учить общим признакам языков программирования (типы, циклы, функции, базовые структуры), учить их абсолютно ненужной (для начинающего программиста) работе с памятью?
Зачем человеку, который только знакомится с тем, что такое программирование вообще, знать о указателях и том, как данные хранятся в оперативной памяти? Зачем знать о сложностях работы со строками в С и с чем эти сложности связаны? Зачем знать о том, что действительные числа имеют отдельные типы и арифметику? Зачем знать о том, что функции должны возвращать установленный им тип и почему?
Я говорю лишь о том, что для того, чтобы начать делать базовые программы на С нужно знать довольно много, причем даже того, что не так просто объяснить человеку, который вообще не понимает то, как работают программы и как их пишут. Гораздо проще человеку объяснить что такое указатель и как с ним работать, если он знает что такое ссылка. Просто объяснить, что в этих языках передаются не данные, а адреса этих данных, потому что так же происходит на уровне процессора и так далее и тому подобное. Тут вопрос в том, насколько это нужно начинающему программисту, задача которого изучить базовые программы, вроде подсчета суммы элементов массива, сортировки или бинарные деревья.
Все, что касается управления памятью, да и вообще то, что касается серьезного программирования — архитектура, ООП и паттерны, сложные алгоритмы, регулярные выражения, наследованные из ФП приемы — все это легко поднять, зная базис. Но зачем без базиса грузить человека особенностями языков с неуправляемой памятью — загадка.
Я говорю о начинающих программистах. Зачем, чтобы учить общим признакам языков программирования (типы, циклы, функции, базовые структуры), учить их абсолютно ненужной (для начинающего программиста) работе с памятью?
Зачем человеку, который только знакомится с тем, что такое программирование вообще, знать о указателях и том, как данные хранятся в оперативной памяти? Зачем знать о сложностях работы со строками в С и с чем эти сложности связаны? Зачем знать о том, что действительные числа имеют отдельные типы и арифметику? Зачем знать о том, что функции должны возвращать установленный им тип и почему?
Я говорю лишь о том, что для того, чтобы начать делать базовые программы на С нужно знать довольно много, причем даже того, что не так просто объяснить человеку, который вообще не понимает то, как работают программы и как их пишут. Гораздо проще человеку объяснить что такое указатель и как с ним работать, если он знает что такое ссылка. Просто объяснить, что в этих языках передаются не данные, а адреса этих данных, потому что так же происходит на уровне процессора и так далее и тому подобное. Тут вопрос в том, насколько это нужно начинающему программисту, задача которого изучить базовые программы, вроде подсчета суммы элементов массива, сортировки или бинарные деревья.
Все, что касается управления памятью, да и вообще то, что касается серьезного программирования — архитектура, ООП и паттерны, сложные алгоритмы, регулярные выражения, наследованные из ФП приемы — все это легко поднять, зная базис. Но зачем без базиса грузить человека особенностями языков с неуправляемой памятью — загадка.
ВУЗы отличаются от техникумов тем, что дают побольше знаний, чем просто узконаправленный специалист.
Оно, конечно, так, но база у знаний выпускника вуза и техникума (колледжа) должна быть общей. Хотя бы потому что последних обычно берут в вуз не на первый курс, а на второй-третий. И если у обоих в зачётке есть предметы «Программирование» и «Структуры и алгоритмы обработки данных в ЭВМ», то и знать они должны примерно одно и то же в пределах этих курсов. И Си для этих предметов будет, имхо, не лучший выбор. Слишком много деталей, не относящихся к собственно программированию и алгоритмам, прежде всего управление памятью, а это уже «Организация и функционирование ЭВМ» — вот там Си и Ассемблер(ы) будут уместны, как языки прежде всего системного программирования, а собственно программирование, алгоритмы и структуры данных лучше изучать на чём-то более высокоуровневом. Идеальны, имхо, для этого (из современного мэйнстрима) Python или Ruby. Да даже Basic, Fortran или PHP будут более уместны, чем C.
Оно, конечно, так, но база у знаний выпускника вуза и техникума (колледжа) должна быть общей. Хотя бы потому что последних обычно берут в вуз не на первый курс, а на второй-третий. И если у обоих в зачётке есть предметы «Программирование» и «Структуры и алгоритмы обработки данных в ЭВМ», то и знать они должны примерно одно и то же в пределах этих курсов. И Си для этих предметов будет, имхо, не лучший выбор. Слишком много деталей, не относящихся к собственно программированию и алгоритмам, прежде всего управление памятью, а это уже «Организация и функционирование ЭВМ» — вот там Си и Ассемблер(ы) будут уместны, как языки прежде всего системного программирования, а собственно программирование, алгоритмы и структуры данных лучше изучать на чём-то более высокоуровневом. Идеальны, имхо, для этого (из современного мэйнстрима) Python или Ruby. Да даже Basic, Fortran или PHP будут более уместны, чем C.
В этой цепочке явно лишним был бейсик и паскаль. Можно было сократить время, начиная с С.
Не факт, что время, потраченное суммарно на изучение всех трёх оказалось бы значительно меньше времени изучения только Си. Не говоря о более узком кругозоре. Паскаль может и можно было бы опустить, но лично я не считаю потерянным зря время на его изучение — переход от Бэйсика к Си был бы слишком резким, вероятно, и просто не стал бы его изучать, оставаясь на Бэйсике и Ассемблере :)
Не факт, что время, потраченное суммарно на изучение всех трёх оказалось бы значительно меньше времени изучения только Си. Не говоря о более узком кругозоре. Паскаль может и можно было бы опустить, но лично я не считаю потерянным зря время на его изучение — переход от Бэйсика к Си был бы слишком резким, вероятно, и просто не стал бы его изучать, оставаясь на Бэйсике и Ассемблере :)
А т.н. «синдром утенка» и нежелание развиваться, как программисту, кстати, есть у всех, в том числе и у тех программистов, у которых первый хорошо освоенный язык был С. Я до сих пор я встречаю таких людей, которые обладают манией переписывания на С и при этом явно заблуждаясь в эффективности такого решения.
Даже «драйверы на С», которые становятся в каждом подобном споре тяжелым аргументом, тем не менее, я не вижу в написании драйвера каких-то фундаментальных отличий, от разработки веб-сервиса на PHP, который обменивается данными с другим сервером через XML. Казалось бы, что тут нет никаких аналогий. Но мне хватило начальных знаний C для того, чтобы написать службу уровня ядра (по сути — драйвер) для Windows XP, которая работала с системными структурами данных и обменивалась ими через обычные интерфейсы, как драйверы.
Я хочу сказать, что на самом деле написание драйвера и прошивки микроконтроллера, например, это не такие уж и сложные задачи, чтобы их можно было вот так просто ставить в противовес. Особенно, когда они разрабатываются по спецификации железа (другими словами — всегда), а сам процесс это просто кодинг интерфейса работы с железкой. Это уже не говоря о том, что начиная с Vista 64bit в Windows драйвера теперь запускаются на уровне пользователя и их программирование еще меньше отличается от написания обычных программ. А про linux и блочные/символьные устройства, я думаю, и говорить не стоит.
Я хочу сказать, что на самом деле написание драйвера и прошивки микроконтроллера, например, это не такие уж и сложные задачи, чтобы их можно было вот так просто ставить в противовес. Особенно, когда они разрабатываются по спецификации железа (другими словами — всегда), а сам процесс это просто кодинг интерфейса работы с железкой. Это уже не говоря о том, что начиная с Vista 64bit в Windows драйвера теперь запускаются на уровне пользователя и их программирование еще меньше отличается от написания обычных программ. А про linux и блочные/символьные устройства, я думаю, и говорить не стоит.
> Работодатель: — Вот есть такие структуры данных, массив и список. Как Вы считаете, какую из них лучше использовать в своих программах?
А что это за провокационный вопрос, все равно что спросить вот есть такие циклы while и for — какой использовать лучше :)
А что это за провокационный вопрос, все равно что спросить вот есть такие циклы while и for — какой использовать лучше :)
Этот вопрос был именно провокационным. Задавая его требовалось сохранять невозмутимый вид и ни в коем случае не улыбаться. ;-) Но сейчас не могу удержаться.
Меня бы такой вопрос в тупик поставил. Особенно если задают его с серьёзным видом. Не «в чём разница», не «когда лучше», а «что лучше» — как-то заставляет задуматься об адекватности спрашивающего.
Ну ладно, давайте переформулируем — «Какую структуру Вы предпочитаете использовать в своих программах и почему?».
Смысл не меняется. Цель вопроса — понять, насколько человек понимает различие хотя бы между элементарными структурами. Пусть это понимание хотя бы промелькнет в глазах в виде недоумения — значит можно продолжать разговор. Это показатель наличия хоть какой-то базы. Если же ответ вида «конечно, список лучше», то разговаривать о сбалансированных деревьях уже бессмысленно.
Смысл не меняется. Цель вопроса — понять, насколько человек понимает различие хотя бы между элементарными структурами. Пусть это понимание хотя бы промелькнет в глазах в виде недоумения — значит можно продолжать разговор. Это показатель наличия хоть какой-то базы. Если же ответ вида «конечно, список лучше», то разговаривать о сбалансированных деревьях уже бессмысленно.
Да просто растет количество знаний, а значит увеличивается «специализация». Кому-то сайтики клепать. Кому-то еще алгоритмы нужны.
Количество информации растет, по-моему, также из-за укоренившегося подхода к программированию. Императивный подход. Слишком много усилий тратится на вылизывание кода. Даже на оптимизации. И всегда вероятность багов высокая. Из-за чего жалко выбрасывать код. Отсюда следует, что невыброшенный код собирают в библиотеки. Библиотеки обрастают новыми именами (классами, методами, функциями). И далее приходится, чтобы снова не писать велосипеды, новому поколению программистов всё это учить больше и дольше.
Другие подходы, возможно, не решат кардинально проблему, но скорость образования снежного информационного кома могла бы быть ниже.
Ну и:
Полчаса — принято. Если это экономически выгодно. Действительно, если сайт — законченный продукт, сделан за полчаса и работает (не важно как), то пусть работает. У хороших программистов и зарплата хорошая. Так пусть и хорошими делами занимаются, а такие сайты пишут те, кто умеют их за полчаса клепать задешево.
Каждый час нашей работы — это мера нашей эффективности. Идеальных продуктов не должно быть. Только соотношение — качество/цена.
Количество информации растет, по-моему, также из-за укоренившегося подхода к программированию. Императивный подход. Слишком много усилий тратится на вылизывание кода. Даже на оптимизации. И всегда вероятность багов высокая. Из-за чего жалко выбрасывать код. Отсюда следует, что невыброшенный код собирают в библиотеки. Библиотеки обрастают новыми именами (классами, методами, функциями). И далее приходится, чтобы снова не писать велосипеды, новому поколению программистов всё это учить больше и дольше.
Другие подходы, возможно, не решат кардинально проблему, но скорость образования снежного информационного кома могла бы быть ниже.
Ну и:
Вот вам сайт, он работает, картинки красивые, что еще нужно? Архитектура, говорите, плохая? Зато я его сделал на суперсовременном движке! И всего за полчаса!
Полчаса — принято. Если это экономически выгодно. Действительно, если сайт — законченный продукт, сделан за полчаса и работает (не важно как), то пусть работает. У хороших программистов и зарплата хорошая. Так пусть и хорошими делами занимаются, а такие сайты пишут те, кто умеют их за полчаса клепать задешево.
Каждый час нашей работы — это мера нашей эффективности. Идеальных продуктов не должно быть. Только соотношение — качество/цена.
Блин, ну есть инженер, а есть кодер:-) В чем по Вашему между ними разница?
ИМХО: один глубоко знает академическую часть(инженер «программирует» в Вашем понимании этого слова), другой — практическую часть(в статье не рассматривается, но уверен, что почти любой кодер не заморачивается на тему знания паттернов проектирования или алгоритмов и структур данных — у него само собой все приходит через практику).
По Вашему посту видно, что Вы радеете за инженеров, глубоко знающих теорию и отличаете их от новичков, которые ни хрена не знают, но говорят «Мы программисты». Думаю с «фотографами» ситуация гораздо хуже, так как таких новичков больше:-)
Статья конечно о другом, но должен сказать, что лично я никогда не пойду работать в компанию, в которой на собеседовании спрашивают «какая структура данных лучше?», ибо практика показывает, что я знаю ответ на этот вопрос лучше собеседника и этот ответ не из учебника…
ИМХО: один глубоко знает академическую часть(инженер «программирует» в Вашем понимании этого слова), другой — практическую часть(в статье не рассматривается, но уверен, что почти любой кодер не заморачивается на тему знания паттернов проектирования или алгоритмов и структур данных — у него само собой все приходит через практику).
По Вашему посту видно, что Вы радеете за инженеров, глубоко знающих теорию и отличаете их от новичков, которые ни хрена не знают, но говорят «Мы программисты». Думаю с «фотографами» ситуация гораздо хуже, так как таких новичков больше:-)
Статья конечно о другом, но должен сказать, что лично я никогда не пойду работать в компанию, в которой на собеседовании спрашивают «какая структура данных лучше?», ибо практика показывает, что я знаю ответ на этот вопрос лучше собеседника и этот ответ не из учебника…
В не совсем правильно меня поняли. Я радею не за инженеров. Я радею — за вектор развития. Меня настораживает не то, что начинающие чего-то не знаю. Меня пугает, что они не хотят этого знать.
Разница между инженером-программистом и «кодером» (техник-программист?) в том, что инженер решает проблему реального мира, а «кодер» просто пишет программу «в вакууме».
Кодер != техник-программист, а пишет в вакууме как раз новичок, ну или «техник-программист»:-)
Кодер умеет решать реальные задачи(из реального мира) и часто делает их быстрее чем инженер-программист, потому что не заморачивается на архитектуру, паттерны и тд.
Кодер умеет решать реальные задачи(из реального мира) и часто делает их быстрее чем инженер-программист, потому что не заморачивается на архитектуру, паттерны и тд.
> потому что не заморачивается на архитектуру, паттерны и тд.
Значит это вообще не программист, а хрен с посудной лавки.
Значит это вообще не программист, а хрен с посудной лавки.
Хм. Знаете, инженер программист тоже в ряде случаев может не заморачиваться на архитектуру.
Но заметьте разницу — он это делает потому что знает, что в данной ситуации этим можно пренебречь. Кодер так делает — потому что по другому не умеет.
И в дополнение хочу сказать, что прекрасно понимаю, что никто с рождения программировать не умеет, и всему надо учиться. Но меня удивляет ситуация, когда человек свое невежество выпячивает как достоинство.
Не хочешь — не надо, твое право. У нас свободное общество.
Но гордится этим?..
Но заметьте разницу — он это делает потому что знает, что в данной ситуации этим можно пренебречь. Кодер так делает — потому что по другому не умеет.
И в дополнение хочу сказать, что прекрасно понимаю, что никто с рождения программировать не умеет, и всему надо учиться. Но меня удивляет ситуация, когда человек свое невежество выпячивает как достоинство.
Не хочешь — не надо, твое право. У нас свободное общество.
Но гордится этим?..
На самом деле нет никакой надобности знать «чем отличается алгоритм Кнута-Морриса-Прата от алгоритма Бойера-Мура» и т.п. вещи. На самом деле я всегда забываю даже синтаксис цикла, и как правило копирую написав однажды.
На самом деле программисту не нужно знать все древности из прошлого. Программист должен просто уметь хорошо владеть «настоящим». А для этого ему уметь разделять задачу на подзадачи, по умному — декомпозировать. Для этого необходимо знать ООП+UML все прочие синтаксические вопросы языка и знание библиотек функций — совершенно не важны, они приложатся. Но вот если программист не может успешно комбинировать то, чему он научился — не видит аналогий, и не может придумать как использовать различные операторы в комбинации — это проблема. Я видел достаточно людей, которые знают синтаксис и вроде как вызубрили ООП, но они ужасно писали программы. У таких людей начинается «одержимости» новыми веяниями — будь то COM (правды ради, это мало кто осваивал из-за сложности), Обобщенными типами, Многопоточностью, Функциональным программированием и т.д. Причем одержимость заключалось в том, что суют это там где надо и где не надо. Вот это действительно реальная проблема.
На самом деле программисту не нужно знать все древности из прошлого. Программист должен просто уметь хорошо владеть «настоящим». А для этого ему уметь разделять задачу на подзадачи, по умному — декомпозировать. Для этого необходимо знать ООП+UML все прочие синтаксические вопросы языка и знание библиотек функций — совершенно не важны, они приложатся. Но вот если программист не может успешно комбинировать то, чему он научился — не видит аналогий, и не может придумать как использовать различные операторы в комбинации — это проблема. Я видел достаточно людей, которые знают синтаксис и вроде как вызубрили ООП, но они ужасно писали программы. У таких людей начинается «одержимости» новыми веяниями — будь то COM (правды ради, это мало кто осваивал из-за сложности), Обобщенными типами, Многопоточностью, Функциональным программированием и т.д. Причем одержимость заключалось в том, что суют это там где надо и где не надо. Вот это действительно реальная проблема.
> На самом деле программисту не нужно знать все древности из прошлого
Но тут надо сделать одну оговорку, не зная ряд вещей ему будет сложнее понимать именно почему это хороший код, а это плохой, почему это удачно использовано, а там нет. И соответственно гавнокод он не сможет отличить от приличного кода. Отсюда собственно и начинается увлечения «новыми веяниями», т.к. собственно не имеет возможности оценить пригодность той или иной идеи, адекватности ее применения и ее полезности. Такому программисту это просто с не с чем сравнить, вот и начинаем верить тому что говорят вокруг — а говорит кто? Такие жепродвинутые пользователи беспомощные двуногие пукалки :)
Но тут надо сделать одну оговорку, не зная ряд вещей ему будет сложнее понимать именно почему это хороший код, а это плохой, почему это удачно использовано, а там нет. И соответственно гавнокод он не сможет отличить от приличного кода. Отсюда собственно и начинается увлечения «новыми веяниями», т.к. собственно не имеет возможности оценить пригодность той или иной идеи, адекватности ее применения и ее полезности. Такому программисту это просто с не с чем сравнить, вот и начинаем верить тому что говорят вокруг — а говорит кто? Такие же
Как-то странно называть функциональное программирование новым веянием.
Давайте честно, что вы об этом знали 5-7 лет назад? Не вообще, как сейчас нашли исторические корни аж с 60-х, а реально что конкретно Вы или другой конкретный программист об этом знал 5 лет назад? Какие были написаны образцы функциональных программ?
Я слышал про lisp 5-7 лет назад, по крайней мере. И читал про практики, которые используются в функциональных языках. Сейчас на функциональных языках императивные задачи решают только программисты-тролли и разработчик ejabberd, который делает это ради смеха.
Шучу, конечно, но тем не менее.
Шучу, конечно, но тем не менее.
Вы уверены, что когда слышали о лиспе вы слышали о нем как о функциональном программировании, а не языке для ИИ? Вы программировали на Лиспе?
У меня есть теоретические знания о CommonLisp, конечно сколько-нибудь полезного софта я на нем не писал (возможность этого вообще многими подвергается сомнению).
В рамках изучения программирования, а конкретно лямбда-вычислений и прочего, что пришло из функциональных языков, я натыкался на отсылки к некоторым языкам, вроде того же Lisp (который не является, впрочем, чистым функциональным языком). Я бы не сказал, что бум использования функциональных языков происходит сейчас, можно сказать даже, что бум создания и использования функциональных языков приходился на 70ые-80ые. А потом, как и сейчас, знание этих языков можно было назвать разве что плюсом в резюме, но никак не профессиональной направленностью. Если не касаться научной среды, конечно же.
В рамках изучения программирования, а конкретно лямбда-вычислений и прочего, что пришло из функциональных языков, я натыкался на отсылки к некоторым языкам, вроде того же Lisp (который не является, впрочем, чистым функциональным языком). Я бы не сказал, что бум использования функциональных языков происходит сейчас, можно сказать даже, что бум создания и использования функциональных языков приходился на 70ые-80ые. А потом, как и сейчас, знание этих языков можно было назвать разве что плюсом в резюме, но никак не профессиональной направленностью. Если не касаться научной среды, конечно же.
> Я бы не сказал, что бум использования функциональных языков происходит сейчас
Я вообще-то тоже этого не вижу, но почему-то на хабре в частности (и порой на просторах интернета) этот бум ощущается. Очень много пишут статей о прелестности ФП, и ни одной критической. В то время как ООП подвергают постоянной критике. Но при этом практически не одно программирование в промышленных масштабах без ООП не обходится. Объяснить, чем то другим такую тенденцию как начало рекламной акции на ФП, т.е. бума не получается. Причем без зазрения совести к ФП присовокупляют авторитетность SQL и Лиспа, хотя они явно построены на других идеях и разработаны для других задач.
Я вообще-то тоже этого не вижу, но почему-то на хабре в частности (и порой на просторах интернета) этот бум ощущается. Очень много пишут статей о прелестности ФП, и ни одной критической. В то время как ООП подвергают постоянной критике. Но при этом практически не одно программирование в промышленных масштабах без ООП не обходится. Объяснить, чем то другим такую тенденцию как начало рекламной акции на ФП, т.е. бума не получается. Причем без зазрения совести к ФП присовокупляют авторитетность SQL и Лиспа, хотя они явно построены на других идеях и разработаны для других задач.
Это все исходит из стремления почувствовать себя немножко элитнее других. Например, знать haskell, пускай даже не написав и одной законченной программы на нем. Но вообще, для расширения кругозора, полезно знать о существовании функционального подхода и о плюсах отсутствия мутабельности и о прочем.
Ну, вот поэтому я и поставил ФП в один ряд — под названием «мода на… », дело не в том, что что-то есть совершенно бесполезное, дело в том что «то, что модно пытаются использовать там где не надо». А авторы этой статьи и «Я, пользователь!» задались вопрос, что вечно, а на что мода пройдет. То, что было найдет свою узкую нишу, будет засунуто как методы библиотек или особенностей компиляторов, но никто это не будет изучать с тем же усердием. Никто не спорит ассемблер важно знать, но на нем мало кто пишет :)
ФП надо. Просто хотя бы понимание основ. Оно для ООП как раз очень полезно.
ООП и ФП как в ортогональных измерениях. Можно и то и другое параллельно использовать. И понимание, как строятся ФП компиляторы, дает понимание, как лучше писать ООП программы.
Ну вот, пара секретов, которые я применяю в ООП:
1. Никогда не дублировать данные и ссылки на данные в полях. По возможности. У ФП нет состояний. В ООП сводим состояния к минимуму, «приближая» к ФП. Любое дублирование данных приводит к возможности их рассинхронизации. (логика не относится к передаче в методы, там можно моделировать имутабельность).
2. К полям обращаться только через методы. В ООП принято к делать паблик сеттеры или геттеры, но я усиливаю условие — даже к внутренним. Т.е. у каждого внутреннего поля один сеттер и геттер и они тоже условно закрыты.
Что это дает. Состояние как бы нигде не дублируется. Над ними строятся система методов. Которые на ходу перевычисляют всё что надо. Промежуточные результаты вычислений нигде не хранятся.
Когда такая система построена, то багов там минимум. Еще, понятно, фокусы, чтобы в рекурсию случайно не попали.
Такая система легко поддается изменениям. Нет издержек на синхронизацию дублированных данных. Минимизированы сайд-эффекты. Далее, если такая система не очень производительна, то ее очень легко оптимизировать. Оптимизация дается почти даром — механически. Все тормоза обычно как раз в лишних перевычислениях. Поэтому просто в нужных методах по результатам замеров, делается кеширование. Приходят одинаковые аргументы, например, а метод «почти» чистый, можно завести словарь, и вычислять один раз результаты.
Конечно, с этим нужно быть осторожным. Но обычно всё довольно прозрачно. Гораздо лучше, чем если люди на свой лад без никаких правил себе сооружают класс и что хотят, то и творят в нем.
У меня как раз «переворот сознания» произошел после работы на функциональном языке. Когда вернулся в шарп, заметил, что думаю совсем по другому. До этого казалось, что можно на шарпе писать как угодно. Что это только там нудят педантичные люди, как надо писать. Что задачу можно писать сотнями спопобов и они почти одинаковы. Лишь бы работало. А после работы на функциональном языке начал видеть кругом «потенциальные баги». И писать стал намного осторожнее.
ООП и ФП как в ортогональных измерениях. Можно и то и другое параллельно использовать. И понимание, как строятся ФП компиляторы, дает понимание, как лучше писать ООП программы.
Ну вот, пара секретов, которые я применяю в ООП:
1. Никогда не дублировать данные и ссылки на данные в полях. По возможности. У ФП нет состояний. В ООП сводим состояния к минимуму, «приближая» к ФП. Любое дублирование данных приводит к возможности их рассинхронизации. (логика не относится к передаче в методы, там можно моделировать имутабельность).
2. К полям обращаться только через методы. В ООП принято к делать паблик сеттеры или геттеры, но я усиливаю условие — даже к внутренним. Т.е. у каждого внутреннего поля один сеттер и геттер и они тоже условно закрыты.
Что это дает. Состояние как бы нигде не дублируется. Над ними строятся система методов. Которые на ходу перевычисляют всё что надо. Промежуточные результаты вычислений нигде не хранятся.
Когда такая система построена, то багов там минимум. Еще, понятно, фокусы, чтобы в рекурсию случайно не попали.
Такая система легко поддается изменениям. Нет издержек на синхронизацию дублированных данных. Минимизированы сайд-эффекты. Далее, если такая система не очень производительна, то ее очень легко оптимизировать. Оптимизация дается почти даром — механически. Все тормоза обычно как раз в лишних перевычислениях. Поэтому просто в нужных методах по результатам замеров, делается кеширование. Приходят одинаковые аргументы, например, а метод «почти» чистый, можно завести словарь, и вычислять один раз результаты.
Конечно, с этим нужно быть осторожным. Но обычно всё довольно прозрачно. Гораздо лучше, чем если люди на свой лад без никаких правил себе сооружают класс и что хотят, то и творят в нем.
У меня как раз «переворот сознания» произошел после работы на функциональном языке. Когда вернулся в шарп, заметил, что думаю совсем по другому. До этого казалось, что можно на шарпе писать как угодно. Что это только там нудят педантичные люди, как надо писать. Что задачу можно писать сотнями спопобов и они почти одинаковы. Лишь бы работало. А после работы на функциональном языке начал видеть кругом «потенциальные баги». И писать стал намного осторожнее.
Ну, мне для этого не надо было знать ФП.
В принципе вы написали правильные «секреты». Но давайте я спрошу:
1. А как же вы реализуете аналоги Model-View-Controller — если не дублируете данные?
2. Геттеры и сеттеры — это хорошо, но утомительно. Ни когда не понимал педантов в этом. Тем более на С#. По сути через геттер Вы получаете точно также значение поля, так зачем усложнять? Другое дело если там нужно, что-то предобработать, но это 10-20%. И тогда заменяем просто поле на свойство (геттер) и те кто прямо раньше обращался к полю, будут обращаться к свойству и ничего не заметят.
В принципе вы написали правильные «секреты». Но давайте я спрошу:
1. А как же вы реализуете аналоги Model-View-Controller — если не дублируете данные?
2. Геттеры и сеттеры — это хорошо, но утомительно. Ни когда не понимал педантов в этом. Тем более на С#. По сути через геттер Вы получаете точно также значение поля, так зачем усложнять? Другое дело если там нужно, что-то предобработать, но это 10-20%. И тогда заменяем просто поле на свойство (геттер) и те кто прямо раньше обращался к полю, будут обращаться к свойству и ничего не заметят.
2. Во-первых, геттеры и сеттеры — как минимум, хорошая рекомендация к приведению кода в один вид. Ну знаете, есть правила как называть поля/методы, а теперь есть еще и правила как писать классы. Во-вторых, в C# и других .NET-based языках есть такая фича как Reflection. По сути, это штука которая позволяет «правильно» нарушать инкапсуляцию и не только. И вот в Reflection есть различие между полем и свойством. Поэтому все нужно делать через геттеры/сеттеры
1. MVC паттерн слишком много имеет реализаций, чтобы говорить о том, как реализовывать простые вещи на нем. Но и там то же самое. Если у вас представление знает о контроллере, то так писать нехорошо:
Пример упрощенный, не говорю о биндингах, просто о сути. Правильно писать этот же код так:
Если хочется не дергать метод всегда у контроллера, можно обернуть его в приватное свойство.
Если представление не знает о контроллере, а используется MVP паттерн, то логика приблизительно одна и та же: данные брать из одного и того же места и стараться не дублировать ни данные, ни ссылки.
2. В общем-то нет особой разницы, кроме того факта, что геттеры и сеттеры — это функции. Во первых в один вид всё приводится. Во-вторых мышление тогда немного иначе работает. Вы не оперируете данными напрямую, а оперируете функциями. Добавлю еще к сказанному выше об отражении, то, что иногда может быть тяжело станет рефакторить — поле заменить на свойство. Если кто-то вдруг уже начал пользоваться ссылками на поле (ref).
Недавно был случай, когда коллега занялся оптимизацией. Но он в коде вот так поля напрямую (приватные) использовал. Кеширование он сделал верно. Но усилий у него на понимание, как это делать — ушло намного больше, чем нужно. Он рассматривает класс с разбросанными данными. Оптимизация для него — это попытка выбрать из множества нафантазированных вариантов.
Когда если бы он использовал только методы, то стало бы очевидно, что другого пути просто нет. Только ставишь вопрос, что тормозит и на какие жертвы можно пойти, ответ — что делать — возникает автоматически.
this.person = controler.GetPerson();
textBox.EditValue = this.person;
Пример упрощенный, не говорю о биндингах, просто о сути. Правильно писать этот же код так:
textBox.EditValue = controller.GetPerson();
Если хочется не дергать метод всегда у контроллера, можно обернуть его в приватное свойство.
Если представление не знает о контроллере, а используется MVP паттерн, то логика приблизительно одна и та же: данные брать из одного и того же места и стараться не дублировать ни данные, ни ссылки.
2. В общем-то нет особой разницы, кроме того факта, что геттеры и сеттеры — это функции. Во первых в один вид всё приводится. Во-вторых мышление тогда немного иначе работает. Вы не оперируете данными напрямую, а оперируете функциями. Добавлю еще к сказанному выше об отражении, то, что иногда может быть тяжело станет рефакторить — поле заменить на свойство. Если кто-то вдруг уже начал пользоваться ссылками на поле (ref).
Недавно был случай, когда коллега занялся оптимизацией. Но он в коде вот так поля напрямую (приватные) использовал. Кеширование он сделал верно. Но усилий у него на понимание, как это делать — ушло намного больше, чем нужно. Он рассматривает класс с разбросанными данными. Оптимизация для него — это попытка выбрать из множества нафантазированных вариантов.
Когда если бы он использовал только методы, то стало бы очевидно, что другого пути просто нет. Только ставишь вопрос, что тормозит и на какие жертвы можно пойти, ответ — что делать — возникает автоматически.
1. Не в даваясь в детали, хочу отметить, что строкой
textBox.EditValue = controller.GetPerson();
вы продублировали данные (аналогично возможно для ссылок). Наличие метода тут ничего не меняет.
2. > иногда может быть тяжело станет рефакторить — поле заменить на свойство. Если кто-то вдруг уже начал пользоваться ссылками на поле (ref)
Не станет. Для этого нужно следовать всего лишь стилю наименования. Если было
public string PersonName
то если припрет меняем на
private string personName
public string PersonName
{ get { return personName;}}
(а ссылками на поле (ref) вообще надо запретить пользоваться, это намного хуже, чем отсутствие инкапсуляции поля.)
textBox.EditValue = controller.GetPerson();
вы продублировали данные (аналогично возможно для ссылок). Наличие метода тут ничего не меняет.
2. > иногда может быть тяжело станет рефакторить — поле заменить на свойство. Если кто-то вдруг уже начал пользоваться ссылками на поле (ref)
Не станет. Для этого нужно следовать всего лишь стилю наименования. Если было
public string PersonName
то если припрет меняем на
private string personName
public string PersonName
{ get { return personName;}}
(а ссылками на поле (ref) вообще надо запретить пользоваться, это намного хуже, чем отсутствие инкапсуляции поля.)
Я показал код, где одна ссылка была явно лишней, а потом способ, как ее избежать. Что там делает текстбокс — не мое дело. копирует данные или нет.
Хотя да, копирует ссылку, если учесть, что геттер есть. И что. Я просто показал направление, в какую сторону думать. А вообще, биндинг для таких случаев лучше. DataSource — контроллер, DataMember — свойство персон. Тогда точно не мое дело, как работает элемент управления.
Хотя да, копирует ссылку, если учесть, что геттер есть. И что. Я просто показал направление, в какую сторону думать. А вообще, биндинг для таких случаев лучше. DataSource — контроллер, DataMember — свойство персон. Тогда точно не мое дело, как работает элемент управления.
То, что вы устранили локальную переменную — это правило рефакторинга от Фаулера, и не имеет ничего общего с ФП.
Binding — это по своей сути декларация о дублировании данных, но с определенным объектным смыслом.
Я же вам показываю, что следование ФП приводит или к фикции, или к маразму. В первом случае, вы все равно дублируете данные, а во втором остаетесь без присваивания. Последние имеет очень узкую сферу применения, и декларировать что вот это и естьмечта идиота идеал функционалиста — несколько странно.
Binding — это по своей сути декларация о дублировании данных, но с определенным объектным смыслом.
Я же вам показываю, что следование ФП приводит или к фикции, или к маразму. В первом случае, вы все равно дублируете данные, а во втором остаетесь без присваивания. Последние имеет очень узкую сферу применения, и декларировать что вот это и есть
Рефакторинг Фаулера и ФП — никак не взаимоисключающие понятия. У языков ФП часто сам компилятор проводит такие рефакторинг. А в шарпе нам приходится.
Устроены так элементы управления, что я для их работы либо должен что-то присвоить, чтобы они отобразили, либо прибиндить. Я бы с радостью передал бы ему делегат, чтобы он сам брал из первоисточника данные. Но так нельзя прямо делать. Зато биндинг — это приблизительно одно и то же. И у каждого класса есть зона ответственности. Мне дела нет, дублируются там данные или нет. Если меня нет, пусть меня хоть и бьют. ))
И в принципе я говорил о минимизации дублирования данных и ссылок. Не вижу в своих доводах и примерах противоречий :)
Устроены так элементы управления, что я для их работы либо должен что-то присвоить, чтобы они отобразили, либо прибиндить. Я бы с радостью передал бы ему делегат, чтобы он сам брал из первоисточника данные. Но так нельзя прямо делать. Зато биндинг — это приблизительно одно и то же. И у каждого класса есть зона ответственности. Мне дела нет, дублируются там данные или нет. Если меня нет, пусть меня хоть и бьют. ))
И в принципе я говорил о минимизации дублирования данных и ссылок. Не вижу в своих доводах и примерах противоречий :)
С этим никто не спорит. Но думаю показательно то, что вы пишите на C#, а не Haskell :)
С# конечно же, более распространенный язык. Но тут много факторов. Далеко не доказывающих, что шарп — лучший язык. Наоборот, часто распространенность — признак посредственности. Программирование — это и индустрия тоже. Крутятся деньги. Нужно много программистов. А не только очень умных. И большое количество людей, освоивших язык и далее положительно влияет на рост изучающих. Работодатель себя лучше чувствует, когда работники легко заменяемые.
Плюс, возможно, лень моя. Я не изучил еще до сих пор Хаскел. Но и работу на нем тяжело найти. Многие говорят о языке, но вакансии я видел очень редко. На F# дела вроде лучше обстоят, даже в моем городе. А тот язык, на котором я писал, вообще редкий. Работы нет, пишу на шарпе.
А шумиха на счет ФП не зря. И майкрософт давно понял положительные стороны ФП и создал язык, да и шарп развивает в функциональную сторону. И даже в плюсах лямбды собираются ввести в стандарт.
Плюс, возможно, лень моя. Я не изучил еще до сих пор Хаскел. Но и работу на нем тяжело найти. Многие говорят о языке, но вакансии я видел очень редко. На F# дела вроде лучше обстоят, даже в моем городе. А тот язык, на котором я писал, вообще редкий. Работы нет, пишу на шарпе.
А шумиха на счет ФП не зря. И майкрософт давно понял положительные стороны ФП и создал язык, да и шарп развивает в функциональную сторону. И даже в плюсах лямбды собираются ввести в стандарт.
> У языков ФП часто сам компилятор проводит такие рефакторинг
А вот это ошибочное мнение. Это Вас вынуждают так писать программу, чтобы сразу было «с рефакторингом». Это все равно, чтобы вас заставили писать для оптимизации на MSIL, а не C#.
А вот это ошибочное мнение. Это Вас вынуждают так писать программу, чтобы сразу было «с рефакторингом». Это все равно, чтобы вас заставили писать для оптимизации на MSIL, а не C#.
я тут под рефакторингом не совсем честно термин использовал. В том смысле, что компилятор функционального языка и рантайм определяют часто последовательность действий. Т.е. компилятор на свое усмотрение двигает методы, превращает рекурсивные вызовы в циклы, заботится о кеше и т.д. Т.е. двигает и разворачивает код как ему удобно.
Конечно, у него цели другие, чем у рефакторинга человеком. Но тем не менее, действия могут быть похожи. Функциональное программирование говорит «почему» один код хуже другого. А книга Фаулера по рефакторингу — скорее просто методы изменений кода. При этом даны противоположные методы. Т.е. «выделение метода» и «встраивание метода».
Вот поэтому знание хотя бы принципов функционального программирования полезно. В нагрузку к Фаулеру.
Конечно, у него цели другие, чем у рефакторинга человеком. Но тем не менее, действия могут быть похожи. Функциональное программирование говорит «почему» один код хуже другого. А книга Фаулера по рефакторингу — скорее просто методы изменений кода. При этом даны противоположные методы. Т.е. «выделение метода» и «встраивание метода».
Вот поэтому знание хотя бы принципов функционального программирования полезно. В нагрузку к Фаулеру.
> Я просто показал направление, в какую сторону думать
Все правильно, но это не имеет отношения к ФП. ФП показывает как думать совсем в другую сторону.
Конечно, неисповедимы пути… и не знаю почему ФП заставляет думать о качестве кода (в то время к ООП дает куда больше критериев качества), хотя по сути ФП — это аналог макросов. Почему от макросов начали отказываться, а ФП переживает бум — я не знаю. Но тенденция странная…
Все правильно, но это не имеет отношения к ФП. ФП показывает как думать совсем в другую сторону.
Конечно, неисповедимы пути… и не знаю почему ФП заставляет думать о качестве кода (в то время к ООП дает куда больше критериев качества), хотя по сути ФП — это аналог макросов. Почему от макросов начали отказываться, а ФП переживает бум — я не знаю. Но тенденция странная…
Вы возможно правы о том, что ФП сейчас переживает бум. Просто раньше вычислительные мощности были слабее, а все программисты умнее, поэтому ФП явно проигрывало ИП. Сейчас же компы мощные, памяти много, быдлокодеров много, их программы медленные и глючные, поэтому относительно умные программисты начинают интересоваться ФП как концепцией которая позволяет писать программы красиво — все равно от обычной программы по скорости отличаться не будет, багов будет скорее всего меньше, а удобство сопровождения выше.
Ну да это мое общее впечатление от хвалебных статей.
Ну да это мое общее впечатление от хвалебных статей.
А для этого ему уметь разделять задачу на подзадачи, по умному — декомпозировать. Для этого необходимо знать ООП+UML
Сильно. Что, без ООП задачу никак не разбить на подзадачи? А без UML это вообще не мыслимо? :)
Сильно. Что, без ООП задачу никак не разбить на подзадачи? А без UML это вообще не мыслимо? :)
Слушайте, я только сейчас заметил это в вашем комментарии:
Вы серьезно?
На самом деле я всегда забываю даже синтаксис цикла, и как правило копирую написав однажды.
Вы серьезно?
Если тот самый новый программист обходится без старых понятий и решает все поставленные перед ним задачи, на кой черт тратить время на изучение старого материала? Чтобы похвастаться, мол я все знаю и я мегакрут?
П. С. Ведь в физике сейчас не пользуются теми, базовыми теориями Галилея, Ньютона? Они все сведены к более понятным и простым теориям. Так же и в программировании я думаю.
П. С. Ведь в физике сейчас не пользуются теми, базовыми теориями Галилея, Ньютона? Они все сведены к более понятным и простым теориям. Так же и в программировании я думаю.
Хм. А на кой черт тратить время на изучение придуманных черт-те когда и черт-те кем ПДД чтобы водить машину? что там сложного-то? завел, поехал, крутишь руль — все в порядке, доехал!
ПДД созданы для того, чтобы минимизировать проблемы на дороге в большинстве ситуаций. Такую же роль играют эти самые «старые понятия» в программировании. Перед тем как их нарушать — важно понимать, какое правило нарушаете и почему в этом случае это возможно.
Конечно можно этого и не делать… одно из первых правил, которое объясняют начинающим водителям — это правило трех «Д».
ПДД созданы для того, чтобы минимизировать проблемы на дороге в большинстве ситуаций. Такую же роль играют эти самые «старые понятия» в программировании. Перед тем как их нарушать — важно понимать, какое правило нарушаете и почему в этом случае это возможно.
Конечно можно этого и не делать… одно из первых правил, которое объясняют начинающим водителям — это правило трех «Д».
Ведь в физике сейчас не пользуются теми, базовыми теориями Галилея, Ньютона? Они все сведены к более понятным и простым теориям.
Да, теория относительности очень понятная и простая
Я согласен с тем что принципы программирования важны, неизменны. И в любом вузе по профильной специальности они изучаются в обязательном порядке. Однако для изучения, понимания и использования базовых алгоритмов, а тем более для создания новых, нужно быть прежде всего математиком, и соответствующий род деятельности называется математик-программист. Их относительно мало по причине того что мало людей с математическим складом ума, к тому же выбирающих профессией программирование. Они ценились но не покрывали нужды в программистах. Поэтому такие люди написали библиотеки, фреймворки, ide, движки, конструкторы. И вот сейчас кодовая база покрывает 99% проблем и нужд бизнеса, а для *того самого* программирования места осталось мало, меньше чем было 15 лет назад. Те кто остались работать над тем 1% проблем и им за это хорошо платят — счастливчики. Массовый рынок труда не требует знания основ и базы, а спрос как известно рождает предложение. Так что тсс, чем меньше людей знают об удовольствии истинного программирования тем больше из них в счастливом неведении, а то потом еще чего, свободный софт будут по ночам писать ради удовольствия, а на работе все те же фреймворки конфигурировать…
Если Вы считаете, что современные фреймворки покрывают 99% проблем — то это означает, что человечество бесконечно развилось и дальше расти некуда, все открытия были сделаны и весь мир нам понятен?
Увы, это совсем не так. Современные системы выглядят безумно умными и все умеющими. Особенно, если их сравнивать с теми, которые были 20 лет назад. Но почему-то пользоваться большинством программных продуктов, за исключением самых примитивных, ужасно неудобно. Особенно это касается мобильных платформ. Их создатели почему-то оказались не в курсе кучи полезных решений, сделанных в свое время для настольных систем. Видимо, считая что ни к чему им «заниматься изучением старых понятий (с)».
Фреймворки тоже нужно конфигурировать. И даже программисты-профи часто (и даже большую часть времени) вынуждены этим заниматься. Но, черт возьми, неужели вам не хочется большего?
Увы, это совсем не так. Современные системы выглядят безумно умными и все умеющими. Особенно, если их сравнивать с теми, которые были 20 лет назад. Но почему-то пользоваться большинством программных продуктов, за исключением самых примитивных, ужасно неудобно. Особенно это касается мобильных платформ. Их создатели почему-то оказались не в курсе кучи полезных решений, сделанных в свое время для настольных систем. Видимо, считая что ни к чему им «заниматься изучением старых понятий (с)».
Фреймворки тоже нужно конфигурировать. И даже программисты-профи часто (и даже большую часть времени) вынуждены этим заниматься. Но, черт возьми, неужели вам не хочется большего?
«Неудобно» это большей частью вопрос юзабилити, а не программирования.
А когда просто программируешь, а не конфигурируешь фреймворк, то все вокруг кричат: «велоспедист» :)
А когда просто программируешь, а не конфигурируешь фреймворк, то все вокруг кричат: «велоспедист» :)
Я специально написал — «бизнеса». А вы про открытия — это уже область науки. Я пару лет назад участвовал в совместном с НИИ проекте на базе кафедры математического обеспечения информационных систем, у них есть математики но они ни капли не программисты, максимум что они знают это матлаб. Зарплаты там были весьма печальными, весьма. Зато новые алгоритмы и «настоящее увлекательное программирование».
А мобильные платформы — молоды. И конечно туда хлынули портировать и писать заново все что было наработано для PC, неудобство и ошибки здесь — побочный эффект бурного роста, в десять раз превышающего скорость роста кодовой базы для настолок. Не более.
Мне то хочется, но я несколько другую сторону проблемы попытался затронуть в комментарии.
А мобильные платформы — молоды. И конечно туда хлынули портировать и писать заново все что было наработано для PC, неудобство и ошибки здесь — побочный эффект бурного роста, в десять раз превышающего скорость роста кодовой базы для настолок. Не более.
Мне то хочется, но я несколько другую сторону проблемы попытался затронуть в комментарии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хочешь быть программистом — будь им!