Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 112
Прошу прощения, но по-моему это очевидно.
Согласен с Вами. Но исходя из опыта, не для всех.
а вот, имхо, главное тут вовсе не «знание и понимание принципов проектирования и построения грамотной архитектуры», а умение мыслить абстрактными категориями — в этом и заключается талант по-настоящему хорошего программиста. Если нет воображения, то и «знание и понимание» особо не помогут…
смена языка в рамках близкого синтаксиса- C++/Java/C# это не проблема. Понятно, что если перейти с C++ на lisp то будет жестоко… думаю примерно за месяц можно вполне уверенно себя чувствовать на новом языке в рамках схожих синтаксически языков
проблема в смене платформы. по личному опыту переход с .net на java крайне тяжел. есть конечно дикое число аналогов библиотек и даже прямых портов, но что касается конкретно веб программирования, десктоп то тут тяжелее. Допустим есть 3-4 фреймворка для вебсервисов на java. на .net 1 wcf и что выбрать не знаешь и подходы разные. в общем язык- ерунда. а вот платформа- это дико сложно
проблема в смене платформы. по личному опыту переход с .net на java крайне тяжел. есть конечно дикое число аналогов библиотек и даже прямых портов, но что касается конкретно веб программирования, десктоп то тут тяжелее. Допустим есть 3-4 фреймворка для вебсервисов на java. на .net 1 wcf и что выбрать не знаешь и подходы разные. в общем язык- ерунда. а вот платформа- это дико сложно
В данный момент испытываю на себе переход с Java/AS3/JS/PHP/C на ObjectiveC.
Разница невероятная, хотя за месяц перейти вполне реально. Но это месяц! А после Java-подобных языков я смог освоить Actionscript 3.0 за сутки. Сутки против месяца — это очень весомо. Все зависит от того между какими именно языками переход.
Уверен, все, кто с этим столкнулся, в свое время намучались изучая ObjectiveC.
Разница невероятная, хотя за месяц перейти вполне реально. Но это месяц! А после Java-подобных языков я смог освоить Actionscript 3.0 за сутки. Сутки против месяца — это очень весомо. Все зависит от того между какими именно языками переход.
Уверен, все, кто с этим столкнулся, в свое время намучались изучая ObjectiveC.
по мне, так ObjectiveC сложен не языком, а фреймворком Cocoa. Язык выучить легко, если утрировать, то надо просто точку заменить на пробел и не забыть квадратные скобки)) А вот ориентироваться в новом фреймворке, его не всегда очевидных классах (как, например, метод чтения из файла находится в классе строки), в его архитектурных решениях (практически чистейший MVC) — вот это сложно и непривычно.
* учу его после c#.net
* учу его после c#.net
Синтаксис если и имеет значение, то не очень большое, парадигма имеет значение. Именно поэтому переход с C на lisp тяжёл, а вовсе не из-за синтаксиса.
Я не понимаю, почему при переходе на Lisp синтаксис называют сложностью? С точностью до наоборот, синтаксис учится за 1.5 часа. Скобка, скобка, пробел да кавычка для quotation. Как писал человек ниже, сложна смена парадигмы и переход на языки с кардинально другой семантикой. Вот с С++ на Java\C# переход не так уж прост, хоть и синтаксис похож. Человеку, который всю жизнь мыслил указателями и ручным управлением памяти, будет сложно поначалу привыкнуть к новому подходу.
Говорят, что мышление человека напрямую связано с языком, на котором он говорит. Возможно, подобная связь имеет место и с языком программирования. Понятно, что это только предположение, но если исходить из подобного допущения, то программист просто обязан изучить два-три принципиально отличных друг от друга языка, пусть даже исключительно в целях расширения кругозора.
Когда Вы пишете спроектированный функционал, Вы думаете сущностями. И описываете эти сущности синтаксисом языка.
Вы занимаетесь словоблудием. Выкрикиваете громкие фразы, в общем, не обосновывая их. На практике все не так красочно
На практике да, многие любят поговнокодить. В силу недостатка времени, либо недостаточности знаний. Я говорю об идеальном варианте.
вы говорите о сферическом коне в вакууме. на практике таких коней не встречается, только в теории. видимо, вы просто теоретик. нету смысла обсуждать такие вопросы с теоретиками.
По-вашему, человек перестает «говнокодить», прочитав Фуллера и GoF?
Паттерны — уже давно не silver bullet, а общая практика. Так что в этом топике не вижу ничего нового.
Паттерны — уже давно не silver bullet, а общая практика. Так что в этом топике не вижу ничего нового.
Сущности описываются не синтаксисом. Синтаксис — внутренне дело языка и к решаемой задаче (функционалу) никакого отношения не имеет.
Лично я вижу спроектированный код спроектированного функционала уже в редакторе. Виртульном, в голове. Но с элементами интерфейса.
Странно только то что уже год пишу в Комодо, а виртуальные, еще не рожденные, коды все в эклипсе и в эклипсе…
Странно только то что уже год пишу в Комодо, а виртуальные, еще не рожденные, коды все в эклипсе и в эклипсе…
Думал что-то интересное будет, а тут… мельчаем :(
Да, по большей части знание приёмов и наличие собственной головы гораздо важнее самого языка. Но и не нужно забывать, что языки не универсальны, поэтому не стоит делать на нём то, для чего он не предназначен.
Что касается того, что выучить язык за месяц — не согласен. Синтаксис — да, какие-то базовые вещи, специфичные для языка — тоже. Но что бы действительно хорошо на нём работать нужно гораздо больше, а что бы стать гуру, и подавно. Нужно язык не просто знать на уровне синтаксиса — нужно знать как он работает, знать его особенности, знать наборы библиотек и пласты технологий, которые с ним связаны. А это годы работы и опыта. Особенно если ваш переход более-менее радикален, к примеру PHP -> Java или наоборот — различия очень большие, да и подход всё же отличается настолько, что нужно будет много времени на перестройку. Особенно Java -> PHP (OOP навороченное в PHP не есть хорошо, нужно делать более просто).
Да, по большей части знание приёмов и наличие собственной головы гораздо важнее самого языка. Но и не нужно забывать, что языки не универсальны, поэтому не стоит делать на нём то, для чего он не предназначен.
Что касается того, что выучить язык за месяц — не согласен. Синтаксис — да, какие-то базовые вещи, специфичные для языка — тоже. Но что бы действительно хорошо на нём работать нужно гораздо больше, а что бы стать гуру, и подавно. Нужно язык не просто знать на уровне синтаксиса — нужно знать как он работает, знать его особенности, знать наборы библиотек и пласты технологий, которые с ним связаны. А это годы работы и опыта. Особенно если ваш переход более-менее радикален, к примеру PHP -> Java или наоборот — различия очень большие, да и подход всё же отличается настолько, что нужно будет много времени на перестройку. Особенно Java -> PHP (OOP навороченное в PHP не есть хорошо, нужно делать более просто).
Я бы даже сказал что не просто «хорошо работать», а в принципе работать. Когда я пересел на мак и выучил язык (objective-c), я всеравно не мог написать ни строчки полезного кода. Уже прошло два года, я почти каждый день пишу код, каждый день читаю документацию, но я до сих пор не могу себя назвать даже средним программистом под эту платформу. Мне кажется люди или слишком специализируются, или слишком переоценивают собственные способности.
Полностью с этим согласен. Ну а насчёт специализации, это уже у кого как. Я например специализируюсь на PHP, MySQL и связанные с ними технологии. Слишком узкой специализацией это не назовёшь, но и возможности не переоцениваю, ибо уже 6 лет как и не кидаюсь на Ruby/Python/C# как некоторые. Мне и так комфортно, разнообразия стока, что и так не успеваешь за всем :)
Если внутри одной платформы и парадигмы, то переход за месяц вполне нормален. Например, веб-приложения Perl -> Python, пишу и на том, и на том особых сложностей с переходом не ощутил.
Насчёт того, что нужны годы, чтобы стать действительно хорошим программистом на новом языке — полная чушь. Через пару лет мне, конечно, реже понадобиться лезть в документацию, тестировать свой код в консоли или писать какие-то бенчмарки, но качество моего кода от этого повысится не радикально, скорость написания — да и, возможно, существенно.
Хороший программист хорош независимо от языка.
Насчёт того, что нужны годы, чтобы стать действительно хорошим программистом на новом языке — полная чушь. Через пару лет мне, конечно, реже понадобиться лезть в документацию, тестировать свой код в консоли или писать какие-то бенчмарки, но качество моего кода от этого повысится не радикально, скорость написания — да и, возможно, существенно.
Хороший программист хорош независимо от языка.
Месяц, говорите?
Языки — это не только синтаксис. Это ряд положенных в основу парадигм, библиотеки, комплекс программных решений (Visual Studio + MSDN это такой монстр, размеры которого так сразу не охватить).
Возьмем среднестатистического программиста на Python и посадим его за C++. Дадим ему месяц на подготовку. Что мы получим через месяц? Ставлю 100 баксов, что мы получим Memory Leaks в большом объеме — в языки заложено разное представление о работе с памятью.
Возьмем обратный случай! Ставлю еще 100 баксов, что наш новоявленный C++ программист будет либо бездумно использовать lambda-исчисление, либо не будет использовать его вообще, либо напортачит с Exception. Разные подходы у этих языков. Что с этим делать — непонятно.
Я не думаю, что в этой паре — архитектура/язык что-либо важнее другого. Это комплекс, сильно завязанный друг на друга. Между прочим, совершать какие-либо архитектурные решения, не учитывая платформу — чревато огромными ошибками.
Языки — это не только синтаксис. Это ряд положенных в основу парадигм, библиотеки, комплекс программных решений (Visual Studio + MSDN это такой монстр, размеры которого так сразу не охватить).
Возьмем среднестатистического программиста на Python и посадим его за C++. Дадим ему месяц на подготовку. Что мы получим через месяц? Ставлю 100 баксов, что мы получим Memory Leaks в большом объеме — в языки заложено разное представление о работе с памятью.
Возьмем обратный случай! Ставлю еще 100 баксов, что наш новоявленный C++ программист будет либо бездумно использовать lambda-исчисление, либо не будет использовать его вообще, либо напортачит с Exception. Разные подходы у этих языков. Что с этим делать — непонятно.
Я не думаю, что в этой паре — архитектура/язык что-либо важнее другого. Это комплекс, сильно завязанный друг на друга. Между прочим, совершать какие-либо архитектурные решения, не учитывая платформу — чревато огромными ошибками.
Может я что-то упускаю, но я не понимаю, что вообще можно напортачить с Exception? И про лямбды утверждение как-то не подкреплено никакими соображениями. Уточните.
В С++ и Python несколько разное отношение к Exception. Если в питоне все библиотеки при возникновении ошибки выбрасывают Exception, то в Си библиотеки, как правило пользуются возвратом кодов ошибок. В С использование исключений дает серьезный оверхед, и в библиотеках, чувствительных к производительности вообще не используются (смотрите, например: ddima.livejournal.com/67706.html). Ситуация, когда что-то работает не так, как ты этого ожидаешь чревата ошибками. В итоге, тот код, который выдаст С++ программист не будет выдержан в рамках питоновского отношения к исключениям — как следствие, его будет тяжело прочесть и понять питоновским программистам.
С лямбдой несколько другое — такой возможности в плюсах нету. Возможно две крайности: либо они не будут использоваться вообще (это плохо, преимущества нужно использовать), либо будут использоваться где надо и где не надо, из чего вырастает опять же — плохой для понимания другими программистами код.
С лямбдой несколько другое — такой возможности в плюсах нету. Возможно две крайности: либо они не будут использоваться вообще (это плохо, преимущества нужно использовать), либо будут использоваться где надо и где не надо, из чего вырастает опять же — плохой для понимания другими программистами код.
>В итоге, тот код, который выдаст С++ программист не будет выдержан в рамках питоновского отношения к исключениям — как следствие, его будет тяжело прочесть и понять питоновским программистам.
Как показывает практика, мой «си-образный» код нормально понимают, если я не ленюсь его документировать. Замечания по оптимальности, недоумения по поводу возврата ошибки в коде и т. п. — это есть, но непонимания нет
Как показывает практика, мой «си-образный» код нормально понимают, если я не ленюсь его документировать. Замечания по оптимальности, недоумения по поводу возврата ошибки в коде и т. п. — это есть, но непонимания нет
А Вы возьмите просто программиста, без приставок «на %some_language%». Дайте ему задание и скажите, на чём его хотите увидеть. Уверен, результат Вас не расстроит, если человек способен выполнить декомпозицию длинного пути от постановления задачи к её выполнению.
Программист на С++ — программист, разрабатывающий приложения на С++ в течение 5 лет
Дайте определение «просто программиста».
Дайте определение «просто программиста».
А теперь представим себе несколько болеее сложную задачу, которая встречается гораздо чаще синтетических примеров:
1. Я беру просто программиста
2. Я даю ему задание
3. Я даю ему правки к этому заданию
4. Я даю ему похожее задание
5. Я даю ему совершенно другое задание, но работающее в той же предметной области.
И если результат пункта 2 меня не расстроит, то вот время выполнения заданий 3-5 вполне может.
1. Я беру просто программиста
2. Я даю ему задание
3. Я даю ему правки к этому заданию
4. Я даю ему похожее задание
5. Я даю ему совершенно другое задание, но работающее в той же предметной области.
И если результат пункта 2 меня не расстроит, то вот время выполнения заданий 3-5 вполне может.
Под «просто программистом» я имею в виду человека, не привязывающего выполнение задания к языку, а использующего наиболее подходящий для работы _инструмент_ (то бишь язык, средства проектирования и конструирования, тестирования и коммуникации).
Время выполнения заданий 3-5 я бы оценил качеством проектирования, последовавшего после п. 2. Но если в ТЗ к п. 2 из трех качеств {быстро; качественно; недорого}, как обычно, было выбрано {быстро; недорого}, то и результат будет соответствующим ;-)
Время выполнения заданий 3-5 я бы оценил качеством проектирования, последовавшего после п. 2. Но если в ТЗ к п. 2 из трех качеств {быстро; качественно; недорого}, как обычно, было выбрано {быстро; недорого}, то и результат будет соответствующим ;-)
Это у вас либо «сферический программист в вакууме получился», либо студент, либо программист с 20летним стажем в различных областях.
Качество проектирования может и будет сильно зависеть от выбранной технологии и знания этой технологии — что получится, если человек привыкший к множественному наследованию С++ или макросам ЛИСПа, будет проектировать под Java, или даже под связку: PHP + JS?
Качество проектирования может и будет сильно зависеть от выбранной технологии и знания этой технологии — что получится, если человек привыкший к множественному наследованию С++ или макросам ЛИСПа, будет проектировать под Java, или даже под связку: PHP + JS?
Меньше года назад очень быстро перешёл с перла на джаву. Почти «Питон -> C++». На джаве до этого писал только несколько простых задачек в универе лет 10 назад. В целом за месяц неплохо освоился, учитывая, что пришлось ещё и вникать в архитектуру большого проекта. Разумеется, многое пришлось осваивать и после, что-то осваиваю до сих пор, но программист на то и программист, чтобы постоянно учиться :-) Главное не бояться нового.
К строгой типизации привык быстро. Возможно, использую её активнее некоторых: в проекте со старых времён тянутся непараметризованные коллекции, и кто-то по инерции продолжает с ними работать, а я везде пихаю генерики, так как я сразу познакомился с джавой с генериками и не знал джаву без них. Пользуюсь новыми штуками (к примеру, аннотациями), когда опытные джава-программисты относятся к ним с осторожностью. Тоже потому что я не знал джаву без них. Активно использую регекспы там, где другие программисты токенайзерами парсили. Считаю, это преимуществом, а не недостатком (точнее недостатком других джава-программистов, которые не освоили регекспы). Да, люблю анонимные классы, с тоской вспоминаю цепочки вроде join-map-grep-split, что в джаве возможно (и я иногда делаю), но выглядит по-уродски. При этом понимаю, что адекватный toString часто может заменить map, чем и пользуюсь. Иногда сокрушаюсь из-за невозможности множественного наследования (до перла некоторое время писал на плюсах, но это уже было давно). Обожаю эклипс с его средствами генерации кода, рефакторинга и квик-фиксами.
В общем, да, это два разных мира, но в новом несложно освоиться, если разбираешься в программировании вообще и имеешь голову на плечах. А говнокод можно плодить и с десятилетним опытом одного языка за спиной.
К строгой типизации привык быстро. Возможно, использую её активнее некоторых: в проекте со старых времён тянутся непараметризованные коллекции, и кто-то по инерции продолжает с ними работать, а я везде пихаю генерики, так как я сразу познакомился с джавой с генериками и не знал джаву без них. Пользуюсь новыми штуками (к примеру, аннотациями), когда опытные джава-программисты относятся к ним с осторожностью. Тоже потому что я не знал джаву без них. Активно использую регекспы там, где другие программисты токенайзерами парсили. Считаю, это преимуществом, а не недостатком (точнее недостатком других джава-программистов, которые не освоили регекспы). Да, люблю анонимные классы, с тоской вспоминаю цепочки вроде join-map-grep-split, что в джаве возможно (и я иногда делаю), но выглядит по-уродски. При этом понимаю, что адекватный toString часто может заменить map, чем и пользуюсь. Иногда сокрушаюсь из-за невозможности множественного наследования (до перла некоторое время писал на плюсах, но это уже было давно). Обожаю эклипс с его средствами генерации кода, рефакторинга и квик-фиксами.
В общем, да, это два разных мира, но в новом несложно освоиться, если разбираешься в программировании вообще и имеешь голову на плечах. А говнокод можно плодить и с десятилетним опытом одного языка за спиной.
Спасибо кэп.
Что касается освоения нового языка за месяц, то
1) Почти без труда сразу можно читать код на другом языке, периодически сверяясь с хелпом.
Исключения: пролог, хаскель.
2) Начать писать простейшие вещи и исправлять баги в существующем коде можно довольно быстро.
Часто этого хватает чтобы сосуществовать в команде или делать что-то востребованное.
Пример: узнав что в AI-Contest нет Linq для C# решил писать на хаскеле (который немного учил в рамках занятий в универе). В итоге за пару дней получил бота, который занимает 100+-20 место. И только теперь упёрся в то, что я не понимаю как можно реализовать более-менее специфичные вещи.
3) Чтобы делать более сложные вещи, оптимизировать по производительности нужно, во первых, достаточно неплохо знать особенности и тонкости языка и, во вторых, понимать базовую концепцию этого языка (например ООП). На первое надо порядка нескольких месяцев, на второе (если раньше применялись другие парадигмы) от полугода.
Возможно кто-то сразу понял, как правильно выделять сущности объектов, что нужно сделать с разбивкой на модули и тп, но мне всё-же кажется, чтобы концепция устоялась надо некоторое время.
Что касается освоения нового языка за месяц, то
1) Почти без труда сразу можно читать код на другом языке, периодически сверяясь с хелпом.
Исключения: пролог, хаскель.
2) Начать писать простейшие вещи и исправлять баги в существующем коде можно довольно быстро.
Часто этого хватает чтобы сосуществовать в команде или делать что-то востребованное.
Пример: узнав что в AI-Contest нет Linq для C# решил писать на хаскеле (который немного учил в рамках занятий в универе). В итоге за пару дней получил бота, который занимает 100+-20 место. И только теперь упёрся в то, что я не понимаю как можно реализовать более-менее специфичные вещи.
3) Чтобы делать более сложные вещи, оптимизировать по производительности нужно, во первых, достаточно неплохо знать особенности и тонкости языка и, во вторых, понимать базовую концепцию этого языка (например ООП). На первое надо порядка нескольких месяцев, на второе (если раньше применялись другие парадигмы) от полугода.
Возможно кто-то сразу понял, как правильно выделять сущности объектов, что нужно сделать с разбивкой на модули и тп, но мне всё-же кажется, чтобы концепция устоялась надо некоторое время.
Наверное, это ответ на моё заявление в q&a в ответ на ваше замечание
Вы совершенно неправильно поняли моё замечание. Я не спорю с тем, что архитектура ПО — это важно и часто опыт в разработке архитектуры приложения более важен чем опыт программирования на языке, на котором пишут приложение.
НО!
Задолбали кидать подобные оффтопные понты в любой теме. Такое впечатление, что просто хотите показаться очень умным, опытным и т.п.
Что касается подобных заявлений, что любой язык можно выучить за месяц — это бред. Синтаксис можно выучить, но каждый язык имеет кучу особенностей, нюансов, библиотек. Попробуйте быть хорошим С-прогером, а потом перейти даже на подобный ему Javascript. Куча нюансов с однопоточностью, замыканиями, таймерами, областю видимости и т.п. А куча библиотек — JQuery, MooTools, ExtJS — три совершенно разных фреймворка. Не будете вы знать JS, один из легчайших языков, за месяц.
Еще раз повторю. Вышесказанное не отрицает того, что умение правильной постройки архитектуры ПО — крайне важно при разработке.
awakeЗнаю php на достаточно высоком уровне. Появилось желание выучить что-то ещё. Ruby или Python?
try4tuneРазработчик программирует не на языке, а с помощью языка. Советую больше развивать свои знания в сторону архитектуры ПО. Перейти на почти любой другой язык для грамотного разработчика особого труда не составит.
TheShockв подобной теме хотя бы один должен выебнутся и сказать про то, что мол разработчик программирует не на языке и т.п.
Вы совершенно неправильно поняли моё замечание. Я не спорю с тем, что архитектура ПО — это важно и часто опыт в разработке архитектуры приложения более важен чем опыт программирования на языке, на котором пишут приложение.
НО!
Задолбали кидать подобные оффтопные понты в любой теме. Такое впечатление, что просто хотите показаться очень умным, опытным и т.п.
Что касается подобных заявлений, что любой язык можно выучить за месяц — это бред. Синтаксис можно выучить, но каждый язык имеет кучу особенностей, нюансов, библиотек. Попробуйте быть хорошим С-прогером, а потом перейти даже на подобный ему Javascript. Куча нюансов с однопоточностью, замыканиями, таймерами, областю видимости и т.п. А куча библиотек — JQuery, MooTools, ExtJS — три совершенно разных фреймворка. Не будете вы знать JS, один из легчайших языков, за месяц.
Еще раз повторю. Вышесказанное не отрицает того, что умение правильной постройки архитектуры ПО — крайне важно при разработке.
на изучение языка необходимо минимум полгода серьёзной работы хотя бы по 2 часа в день.
Это вы сильно уж занизили по 2 часа в день. Мало будет. И даже не просто работы. Тут нужно пол года такой хорошей разноплановой работы, или сложный проект, где достаточно большой разброс типов заданий, что бы попалось как можно больше разных аспектов языка, его особенностей, а так же сопутствующих ему библиотек и технологий.
Привет, Psih. Да, согласен, про 2 часа загнул что-то. Имел ввиду, что даже если будешь уделять 20 часов в сутки — меньше чем за полгода не выучишь, надо время на то, чтобы информация переварилась.
сложный проект, где достаточно большой разброс типов заданий
Я вот думаю. А ведь первый такой проект получится полной лажой — и не стыдно будет после этого?
Ну всё зависит от ситауции и человека. Одно дело если он сам по себе не ахти и один делает, другое дело если он работает в компании, где есть опытные спецы — они помогут. Третье если ты один, но сам по себе ты хороший программист и хорошо всё схватываешь и не останавливаешься на первом попавшемся варианте. В общем переменных много, так что формула очень разнообразна :)
>Нет смысла просто сесть и учить ASM или Objective-C просто так, нужна цель.
Целью вполне может быть смена характера решаемых задач или решение нынешних более эффективно. А уж поводов сменить язык может быть множество, особенно если решение о его выборе принимал не сам или «под давлением обстоятельств».
Целью вполне может быть смена характера решаемых задач или решение нынешних более эффективно. А уж поводов сменить язык может быть множество, особенно если решение о его выборе принимал не сам или «под давлением обстоятельств».
Сам по себе язык не критичен. Разработчик с 15+ годами опыта может достаточно легко изучить синтаксис нового языка за 2-3 недели. Но, к сожалению, кроме языка есть еще платформа. Помню, много лет назад я для себя изучил Qt. «Базовые» вещи заняли неделю. А вот чтобы проникнуться архитектурой фреймворка, изучить best practices и наиболее популярные подходы потребовалось порядка двух лет :(.
Работал над одним проектом, предыдущий девелопер ушел, так что разбираться пришлось самому. Код был прямым портом с C# на Java, выполненный программистом C++. Многопоточный, большой, на доработку ушло около года.
Все ваши рассуждения выеденного яйца не стоят.
Все ваши рассуждения выеденного яйца не стоят.
О своем опыте.
Пишу на java, была необходимость писать на perl c++ objC
perl — «Куда я попал, как с этим вообще можно работать»
с++ — «Вроде неплохо, но почему все в подпорках, и почему МС студия такая убогая»
objC — тут все ок
Пишу на java, была необходимость писать на perl c++ objC
perl — «Куда я попал, как с этим вообще можно работать»
с++ — «Вроде неплохо, но почему все в подпорках, и почему МС студия такая убогая»
objC — тут все ок
MS студия (а особенно 2008 и 2010) — самая лучшая IDE из всего, с чем мне приходилось работать. Другое убожество типо еклисов, зендов или нейтивного Xcode даже в сравнение не идет с удобством, функционалом, СТАБИЛЬНОЙ работой, наличием удобных плагинов и т.д.
upload.wikimedia.org/wikipedia/ru/0/07/Futurama_Brain_Slugs.jpg
Не получается прикрепить картинку.
Не получается прикрепить картинку.
Просто транслировать код с одного языка на другой — это не так сложно, даже со Smalltalk на asm и обратно.
Гораздо сложнее, и важнее, знать и уметь использовать преимущества и особенности языка, на котором идет разработка.
Гораздо сложнее, и важнее, знать и уметь использовать преимущества и особенности языка, на котором идет разработка.
Где-то с год работаю с .Net и до сих пор нахожу вещи, которые меня удивляют. Многое я бы мог сделать проще и элегантнее, если бы знал о возможностях платформы.
С месяц назад решил попробовать Java, чисто для себя. Сел раз HelloWorld написал, сумму чисел, сортировку пузырьком, а попробовал векторный редактор простенький написать, так тут уже проблемы появились.
Язык программирования — это не только синтаксис. Это еще и парадигма, и библиотеки, и нюансы. Даже если вы умеете проектировать элегатные приложения, то если вы их проектируйте на конкретный язык — то решение будет более элегантным.
С месяц назад решил попробовать Java, чисто для себя. Сел раз HelloWorld написал, сумму чисел, сортировку пузырьком, а попробовал векторный редактор простенький написать, так тут уже проблемы появились.
Язык программирования — это не только синтаксис. Это еще и парадигма, и библиотеки, и нюансы. Даже если вы умеете проектировать элегатные приложения, то если вы их проектируйте на конкретный язык — то решение будет более элегантным.
А чего месяц? Через неделю имхо уже можно будет выдавать усредненный по больнице код с безупречной архитектурой. :)
Но это, простите серость и быдлость, поскольку каждый хороший язык имеет свой сахар и в общем-то писать на определенном языке — это как думать на живом языке. Можно через неделю-другую выдать оригинальную связную фразу, которую поймут носители. Но выдать смысловой шедевр, да че уж там — просто адекватную мысли фразу, получиться в лучшем случае через полгода интенсивного обучения.
Писать правильно — значить думать соответственно. Если можете перестроить способ мышления за месяц — я уверен что глубина его, мягко говоря, не впечатляет.
Но это, простите серость и быдлость, поскольку каждый хороший язык имеет свой сахар и в общем-то писать на определенном языке — это как думать на живом языке. Можно через неделю-другую выдать оригинальную связную фразу, которую поймут носители. Но выдать смысловой шедевр, да че уж там — просто адекватную мысли фразу, получиться в лучшем случае через полгода интенсивного обучения.
Писать правильно — значить думать соответственно. Если можете перестроить способ мышления за месяц — я уверен что глубина его, мягко говоря, не впечатляет.
var sq = Enumerable.Range(1, 3).Select(x => x * x).ToList();
Не слабо ;-)
Не слабо ;-)
let sq = map (\x -> x * x) [1, 2, 3]
:P
:P
(map #(* % %) (range 1 4))
Clojure:). Вместо ридер макры можно было (fn[x] (* x x))
Clojure:). Вместо ридер макры можно было (fn[x] (* x x))
А как в Clojure тогда вектора записываются? И как определить лямбду, которая просто возвращает значение из контекста? (lambda () *username*)
Я в CL делал штуку, которой можно было писать так:
(mapcar #{(* @1 @1)} (iota 3 :start 0))
sprunge.us/eEMe?cl
Потому что #() в стандарте есть и определяет вектор.
Я в CL делал штуку, которой можно было писать так:
(mapcar #{(* @1 @1)} (iota 3 :start 0))
sprunge.us/eEMe?cl
Потому что #() в стандарте есть и определяет вектор.
Вектора записываются через квадратные скобки. Например: [1 2 3 4 5].
А лямбды определяются именно с помощью fn. То есть выглядеть такая лямбда это будет точно как вы написали:
(fn[] *username*)
А лямбды определяются именно с помощью fn. То есть выглядеть такая лямбда это будет точно как вы написали:
(fn[] *username*)
Благодарю. А #(* % %) — это что-то самописное? Не поделитесь исходниками? Отсутствие результатов в гугле намекает, что это не стандартная запись.
Да нет же, #() — это стандартное reader macro — макрос, который разворачивается на первом же проходе кода, до того, как его увидит компилятор. Reader macro — это сокращения для часто используемых операций, их нельзя обьявлять самому, и их существует немного стандартных.
С помощью того же ридер макро лямбду (fn[x y] (+ x y)) можно записать как #(+ %1 %2). Вообще, их использование поощряется только там, где они совершенно прозрачны и ускоряют чтение, но ни в коем случае не запутывают.
С помощью того же ридер макро лямбду (fn[x y] (+ x y)) можно записать как #(+ %1 %2). Вообще, их использование поощряется только там, где они совершенно прозрачны и ускоряют чтение, но ни в коем случае не запутывают.
В Clojure нельзя объявлять свои reader-макры?!?
Внезапно ABCL стал интереснее Clojure…
Внезапно ABCL стал интереснее Clojure…
Я думаю, Вы не правы. За отказом от пользовательских ридер-макр стоит вполне разумное желание сделать код более понятным для других. Если бы каждый пользователь мог плодить какие-угодно reader macro, то это усложнило бы чтение его кода для его коллег, да и вполне вероятно, для него самого через некоторое время. К ним нужно относится как статическим элементам синтаксиса, не более.
А писать свои обычные макросы — прошу, никаких запретов тут конечно же нет.
А писать свои обычные макросы — прошу, никаких запретов тут конечно же нет.
а зачем? кто такой код потом будет раздуплять и дебажить?
Это все равно что отказаться от форматирования
или все равно что бить по рукам за
a++; result = GetSum(a,b); Wirte(result); /* в одну строку все*/
но при этом писать такое уродство List sq = new ArrayList(){{ for (int x: Arrays.asList(1, 2, 3)) add(x*x); }};
Это все равно что отказаться от форматирования
или все равно что бить по рукам за
a++; result = GetSum(a,b); Wirte(result); /* в одну строку все*/
но при этом писать такое уродство List sq = new ArrayList(){{ for (int x: Arrays.asList(1, 2, 3)) add(x*x); }};
Язык для успешности проекта важен, если бросаться в крайности («будем писать ОС и распознавание образов либо на асме, либо на лиспе!»). Хороший (для данных задач) язык плохую архитектуру не спасёт (проект может и запустится в срок, но его поддержка превратится в ад), но и плохой (для данных условий и задач) язык преимущества хорошей архитектуры может свести к нулю (самый простой пример — проект никогда не завершится).
Но вот проект с посредственной архитектурой и не самым оптимальным для таких задач языком вполне может иметь успех (прежде всего коммерческий) если результаты получились пускай и не оптимальные, но приемлемые — примеров тьма. Потом ставятся новые задачи (и/или изменяются условия) и, возможно, изменяется и язык (причём может быть только частично), и архитектура, а возможно и не меняется, если анализ показывает, что приемлемых результатов можно добиться и без кардинальных изменений в приложении.
Но вот проект с посредственной архитектурой и не самым оптимальным для таких задач языком вполне может иметь успех (прежде всего коммерческий) если результаты получились пускай и не оптимальные, но приемлемые — примеров тьма. Потом ставятся новые задачи (и/или изменяются условия) и, возможно, изменяется и язык (причём может быть только частично), и архитектура, а возможно и не меняется, если анализ показывает, что приемлемых результатов можно добиться и без кардинальных изменений в приложении.
Смешнее всего список книг. Паттерны, снова паттерны и зачем-то требования (а вы не слышали, что требованиями занимаются аналитики?).
Зато нет ни оценки архитектуры (а ведь это единственный способ понять, какой паттерн надо применить в данном случае), ни real-life practices.
Зато нет ни оценки архитектуры (а ведь это единственный способ понять, какой паттерн надо применить в данном случае), ни real-life practices.
Что посоветуете почитать, желательно на русском?
На русском — не знаю, просто не ориентируюсь.
Из недавнего. что мне понравилось: Dino Esposito, Andrea Saltarello. Microsoft .NET: Architecting Applications for the Enterprise.
(она, вопреки названию, не только про .net)
Из недавнего. что мне понравилось: Dino Esposito, Andrea Saltarello. Microsoft .NET: Architecting Applications for the Enterprise.
(она, вопреки названию, не только про .net)
В свете коммента, пожалуй, ценно упомянуть еще Казмановские (Rick Kazman) книги по оценке архитектуры, методолгия ATAM. Названий сейчас не помню, к моему стыду, но по фамилии автора найти можно легко.
Лет 5 писал на PHP. Потом перешел на .NET. Через год пришла мысль, что наконец-то стал более менее нормально на нём писать. Еще через год наконец-то разобрался с финалайзерами, weak references и прочим. Сейчас с опаской гляжу не LINQ. Такие дела.
С опаской? Чего так?
Изучить хочется, но кажется, что технология достаточно сложная, а продукт у нас под второй фреймворк — вроде практической цели в изучении нет. Только любопытство.
Эм… Вам кто-то преувеличил её (технологии) сложность. В форме записи «цепочкой» вызовов — нужно знать только об экстеншн методах, в форме записи sql-like — произвольный диалект sql. Остальное — просто знание конкретных имён методов и аргументов.
Э нет. То, что так легко называют LINQ, на самом деле — очень немаленький набор сложностей и неоднозначностей. Одно отложенное исполнение чего стоит (особенно вкупе с привычкой детерминированно управлять датаконтекстами).
Неужели отложенное выполнение впервые появилось в LINQ и никогда ни в каких, например, ОРМ не использовалось никогда, что это нужно вот так отдельно обсуждать как *достоинство*? В 2010 для DBAL это вполне себе обычное поведение.
Я говорю не про достоинства, а про неочевидности в работе.
В частности, тот факт, что можно вернуть итератор через несколько слоев абстракции, уже давно забыть, что он пришел из linq-ту-что-нибудь, и в момент итерации по нему выяснить, что датаконтекст закрыт, и данные, как следствие, тю-тю.
В частности, тот факт, что можно вернуть итератор через несколько слоев абстракции, уже давно забыть, что он пришел из linq-ту-что-нибудь, и в момент итерации по нему выяснить, что датаконтекст закрыт, и данные, как следствие, тю-тю.
Ещё кроме отложенного исполнения что-нибудь припомните, из «сложностей и неоднозначностей». Интересно :-)
Если говорить о linq как возможностях языка/платформы (т.е., в общем), то самое феерическое — это то, что благодаря структуре провайдеров и extension-методам (впрочем, второе верно для всех расширяющих методов, не только в linq), на взгляд не понятно, что именно сейчас будет выполнено и как. В частности, банальное q.Where(l => l.Id == 1) может быть выполнено одним из как минимум четырех способов в разных местах, причем одно из самых важных разделений банально зависит от того, к чему сейчас приведено q — к IEnumerable или к IQueryable.
Если же говорить о linq как о совокупности провайдеров (как сейчас говорят чаще), то там все еще веселее, поскольку у каждого из них свои причуды, которые не видны вплоть до рантайма. Скажем, в linq2sql нельзя создать его же собственную сущность внутри Select(). Или, скажем, в провайдерах регулярно не работают синонимичные, казалось бы, методы — может работать Count(), но не работать Any(), может работать Take(), но не работать First(). И все это надо держать в голове.
И еще веселее, конечно, то, что надо держать в голове, как твой код смаппится на sql внизу — в частности, любимая шутка про разницу в обработке Any() и Count().
А в-третьих, появление linq знаменовало собой маленький сдвиг парадигмы — от обработки в цикле к обработке операторами множеств (и не важно, как оно устроено внутри). Я за собой заметил, что после того, как я много поработал с linq, я больше не пишу foreach() {if() add}, я всегда постараюсь заменить на AddRange(..Where). И далее по аналогии.
Если же говорить о linq как о совокупности провайдеров (как сейчас говорят чаще), то там все еще веселее, поскольку у каждого из них свои причуды, которые не видны вплоть до рантайма. Скажем, в linq2sql нельзя создать его же собственную сущность внутри Select(). Или, скажем, в провайдерах регулярно не работают синонимичные, казалось бы, методы — может работать Count(), но не работать Any(), может работать Take(), но не работать First(). И все это надо держать в голове.
И еще веселее, конечно, то, что надо держать в голове, как твой код смаппится на sql внизу — в частности, любимая шутка про разницу в обработке Any() и Count().
А в-третьих, появление linq знаменовало собой маленький сдвиг парадигмы — от обработки в цикле к обработке операторами множеств (и не важно, как оно устроено внутри). Я за собой заметил, что после того, как я много поработал с linq, я больше не пишу foreach() {if() add}, я всегда постараюсь заменить на AddRange(..Where). И далее по аналогии.
Иногда на другой язык перейти просто невозможно.
Вот например я.
Знаю Си и Лисп(как функциональный язык).
Читая код на Си, я четко представляю что делает процессор на этой строчке кода и на следующей и во всей программе. Я знаю что лежит сейчас в стеке. Я знаю что моя программа работает.
Читая код на Лиспе я знаю на каком витке рекурсии сейчас находится интерпретатор. (сам его писал).
Я знаю сколько памяти выделено под мои переменные. Я знаю что моя программа работает.
И вот я решил бросить взгляд в сторону C#. Во многих(во всех ли?) книжках 1000 страниц про синтаксис и ни слова о том, как же работает моя программа. Да хотя бы как работает этот первый класс.
Меня пытаются заставить мыслить терминами языка и скрывают истину. Я так и не могу писать на этом языке.
Так что одно дело переходить между С++\Жава\С# и совсем другое изучать язык нового уровня.
Вот например я.
Знаю Си и Лисп(как функциональный язык).
Читая код на Си, я четко представляю что делает процессор на этой строчке кода и на следующей и во всей программе. Я знаю что лежит сейчас в стеке. Я знаю что моя программа работает.
Читая код на Лиспе я знаю на каком витке рекурсии сейчас находится интерпретатор. (сам его писал).
Я знаю сколько памяти выделено под мои переменные. Я знаю что моя программа работает.
И вот я решил бросить взгляд в сторону C#. Во многих(во всех ли?) книжках 1000 страниц про синтаксис и ни слова о том, как же работает моя программа. Да хотя бы как работает этот первый класс.
Меня пытаются заставить мыслить терминами языка и скрывают истину. Я так и не могу писать на этом языке.
Так что одно дело переходить между С++\Жава\С# и совсем другое изучать язык нового уровня.
чтобы понимать, как работает CLR — нужно читать о том, как работает CLR :-)
из очень качественного чтива можно посоветовать, например, «CLR via C#» от Рихтера
из очень качественного чтива можно посоветовать, например, «CLR via C#» от Рихтера
А какой именно Лисп вы знаете? Обычно когда говорят просто Лисп имеют ввиду Common Lisp, но у него с поддержкой функциональной парадигмы не так хорошо, чтобы функциональным называть и всё рекурсией решать.
«От нас скрывают!»
Я например к новому синтаксису адаптируюсь почти моментально (особенно если есть хорошая IDE. Я вообще считаю, что от в основном IDE и прочих средств разработки зависит легкость освоения нового языка/платформы.), но вот чтобы въехать в «философию» языка/платформы/фреймворка надо довольно продолжительное время на этом поработать…
Для программера самый важный язык — это английский.
Очередная статья об очевидном. Более того, наполненная разнообразными ошибками.
настоящий программист на фортране напишет программу на фортране на любом языке :-)
Тот факт, что я знаю несколько языков программирования, не означает, что я их все могу эффективно использовать. На основных я могу разрабатывать ПО в десяток раз быстрее и качественнее, чем на тех, которыми я постоянно не пользуюсь. Как верно и неоднократно отметили выше, уровня знаний вполне хватает на понимание работы программы на другом языке, на написание чего-то простого, на правку мелких багов, внесение мелких изменений и т.п. Но что-то более менее приличное за вменяемое время я могу написать только на тех языках, которые являются для меня основными.
Смена не сложна. Достаточно понять зачем та или иная функция языка нужна. Например нужно понимать, что Java или .NET — это не ещё один PHP со строгой типизацией, а что строгая типизация гарантирует(при правильном её использовании), что в 80-ти процентах случаев ваша программа будет работать так как вы предполагаете, если он скомпилируется.
Но не забываем, что язык это только начало. Есть ещё библиотеки и фрэймворки, архитектура которых часто обусловлена спецификой языка. Их тоже нужно изучать и это самое сложное. Достигается только упорным трудом и практикой. Как в недавней статье писали, что для того, чтобы изучить 95% нового языка(не программирования :) ) нужно три месяца. Для того, чтобы изучить остальные 5 процентов нужно 5 лет. Так вот с библиотеками та же хрень.
Только вот вряд ли вы сможете после нескольких лет разработки и использования инструментов одного языка быть так же эффективны используя другой. Таким образом вряд ли покупатель или наниматель предложит вам те же самые деньги, что и за предыдущую технологию, если конечно вы не будете его обманывать и говорить, что вы достаточно в ней практиковались. Изучение же новых языков и фрэймворков за деньги нанимателя я считаю неэтичным и непроффесиональным.
Но не забываем, что язык это только начало. Есть ещё библиотеки и фрэймворки, архитектура которых часто обусловлена спецификой языка. Их тоже нужно изучать и это самое сложное. Достигается только упорным трудом и практикой. Как в недавней статье писали, что для того, чтобы изучить 95% нового языка(не программирования :) ) нужно три месяца. Для того, чтобы изучить остальные 5 процентов нужно 5 лет. Так вот с библиотеками та же хрень.
Только вот вряд ли вы сможете после нескольких лет разработки и использования инструментов одного языка быть так же эффективны используя другой. Таким образом вряд ли покупатель или наниматель предложит вам те же самые деньги, что и за предыдущую технологию, если конечно вы не будете его обманывать и говорить, что вы достаточно в ней практиковались. Изучение же новых языков и фрэймворков за деньги нанимателя я считаю неэтичным и непроффесиональным.
Изучение же новых языков и фрэймворков за деньги нанимателя я считаю неэтичным и непроффесиональным.
Зря вы так, наниматель платит за сделанную работу. Если его устраивают ваши сроки и качество — то и хорошо, а изучать что-то прийдется всё равно, если только это не «типовой проект».
Зря вы так, наниматель платит за сделанную работу. Если его устраивают ваши сроки и качество — то и хорошо, а изучать что-то прийдется всё равно, если только это не «типовой проект».
>Изучение же новых языков и фрэймворков за деньги нанимателя я считаю неэтичным и непроффесиональным.
Очень спорно, однозначно неэтично только сильно преувеличивать свои знания, а многие наниматели настаивают на обучении (и, например, сертификации) за их счёт, или просто готовы к тому, что трудоемкость выше будет, чем у человека 5 лет занимающегося языком/фреймворком.
Плюс, как уже заметили, есть наниматели, платящие за результат и им всё равно (в разумных пределах) как и на чём вы будете этого результата достигать.
Очень спорно, однозначно неэтично только сильно преувеличивать свои знания, а многие наниматели настаивают на обучении (и, например, сертификации) за их счёт, или просто готовы к тому, что трудоемкость выше будет, чем у человека 5 лет занимающегося языком/фреймворком.
Плюс, как уже заметили, есть наниматели, платящие за результат и им всё равно (в разумных пределах) как и на чём вы будете этого результата достигать.
Сама наивность, поработали бы вы с таким «переходцем», запели бы по другому.
Вспоминается старый разговор с коллегами о том, что на собеседовании плохой работодатель спрашивает про язык программирования, про знание функций, а хороший — интересуется о пути решения поставленной задачи
Отсутствие привязки к одному ЯП — это очень здорово и правильно и как уже писали в комментариях те же Хант и Томас (а не Спольски) советуют изучать по одному ЯП в год, причем не обязательно в промышленном использовании, а хотя бы для ознакомления с концепциями и «перекрессного опыления» идей.
Но вот слово «выучить» нельзя (ну или по крайней мере опрометчиво) применять как к естественным языкам, так и языкам программирования. Спросите у любого лингвиста знает ли он соответствующий язык? Он едва ли ответит вам «да, я его знаю» и тем более он не даст вам ответа на вопрос, «а как выучить английский?».
То же самое справедливо и для ЯП. Небезысвестный Эрик Липперт в одной из своих последних заметок отлично процитировал Питера Норвига о том, что серия книг «ЯП за 21 день» на самом деле должна называться так: Teach Yourself Programming In Ten Thousand Hours Because Realistically That Is About How Long It Takes To Gain Expertise At Any Skill.
Кстати, с этим согласен и Хант в своей книге Refactor Thinking and Learning, где он упоминает о том, что для того, чтобы стать профессионалом в среднем требуется не менее 10 лет.
З.Ы. Я согласен, что ставить ЯП во главу угла глупо и что понятие «программировать с использованием языка», а не «на языке», введенное Макконнеллом очень разумно и полезно, но, нужно отметить, что с изучением чего-либо и ЯП в частности все не так просто;)
Но вот слово «выучить» нельзя (ну или по крайней мере опрометчиво) применять как к естественным языкам, так и языкам программирования. Спросите у любого лингвиста знает ли он соответствующий язык? Он едва ли ответит вам «да, я его знаю» и тем более он не даст вам ответа на вопрос, «а как выучить английский?».
То же самое справедливо и для ЯП. Небезысвестный Эрик Липперт в одной из своих последних заметок отлично процитировал Питера Норвига о том, что серия книг «ЯП за 21 день» на самом деле должна называться так: Teach Yourself Programming In Ten Thousand Hours Because Realistically That Is About How Long It Takes To Gain Expertise At Any Skill.
Кстати, с этим согласен и Хант в своей книге Refactor Thinking and Learning, где он упоминает о том, что для того, чтобы стать профессионалом в среднем требуется не менее 10 лет.
З.Ы. Я согласен, что ставить ЯП во главу угла глупо и что понятие «программировать с использованием языка», а не «на языке», введенное Макконнеллом очень разумно и полезно, но, нужно отметить, что с изучением чего-либо и ЯП в частности все не так просто;)
Я нигде не упоминал слово выучить. Освоить и перейти на новый язык — да. Начать довольно беспроблемно на нем что-то делать, но, естественно, не быть в нем гуру.
В том-то и беда, что чтобы реализовать любые архитектурные паттерны и идеи на любом языке КАЧЕСТВЕННО — лучше быть в нем хоть немножко гуру.
Те же php или C++ сами по себе имеют небольшой словарь зарезервированных слов и синтаксис. Но величие и понимание возможностей языка приходит со знанием хотя бы стандартных библиотек языка. К месяцу работы большинство не будет знать даже о существовании и трети полезных библиотек. Какое ж тут качество даже при условии понимания «назубок» всего Фаулера? Если от незнания «микроскопом гвозди забиваем» (и сам таким страдал, когда срочно надо было с одного в другое въехать и выдавать на-гора стабильно работающий код).
Те же php или C++ сами по себе имеют небольшой словарь зарезервированных слов и синтаксис. Но величие и понимание возможностей языка приходит со знанием хотя бы стандартных библиотек языка. К месяцу работы большинство не будет знать даже о существовании и трети полезных библиотек. Какое ж тут качество даже при условии понимания «назубок» всего Фаулера? Если от незнания «микроскопом гвозди забиваем» (и сам таким страдал, когда срочно надо было с одного в другое въехать и выдавать на-гора стабильно работающий код).
По-моему одно и другое (глубокие знания ЯП и архитектуры) — это параллельные вещи, знание и понимание которых в равной степени дополняет понятие «хороший программист на… (ЯП)».
За месяц можно освоить в лучшем случае синтаксис, основные конструкции и зарезервированные слова и, возможно, основные парадигмы, а также наиболее употребимые (супер-массовые, я бы сказал) функции из основных библиотек…
Но богатство современных ЯП кроется в прилагаемых к ним библиотеках с тысячами полезных и уже готовых функций. Будет ли программист на языке Х со стажем 1 мес на этом языке более-менее четко знать о существовании всех наиболее употребимых и популярных библиотек и содержащихся в них функций? Ответ, понятное дело, отрицательный.
Добавьте сюда уже заботливо разработанные тысячами людей более-менее готовые фреймворки с дополнительной функциональностью на самом языке, с классами «на все случаи жизни» хотя бы для большей части наиболее популярных задач, решаемых на языке Х, и вы осознаете сократовское «я знаю, что я ничего не знаю», если вы до конца честны перед сами собой в отношении вашего знания «языка Х».
И совсем жесть — при смене парадигм. Например, я пока не испытывал потребности, но, возможно, попробую функциональный язык после многих лет императивных. Товарищи временами от такой смены стояли на ушах (одному программирование, например, преподают, и вот, после пары лет С++ и си-подобного...) Или тот же Javascript, который, казалось бы, «как все» (к нему даже встроенных библиотек нет, только сторонние библиотеки/фреймворки! синтаксис си-подобен!), но одно только понимание прототипирования и контекста вызова само по себе может очень многого стоить в дальнейших взаимоотношениях с языком.
Как бы хорошо человек не знал архитектурные решения, он вряд ли сам сможет хорошо решить задачу, если будет использовать кривой функционал языка. Тупо от незнания.
Упирать только в архитектуру может себе позволить аналитик/архитектор, который сам почти ничего не программирует. Упирать на код — кодер. Но, надеюсь, большинство не стремится ни в чистые кодеры, ни в забывающие кодирование архитекторы? :)
За месяц можно освоить в лучшем случае синтаксис, основные конструкции и зарезервированные слова и, возможно, основные парадигмы, а также наиболее употребимые (супер-массовые, я бы сказал) функции из основных библиотек…
Но богатство современных ЯП кроется в прилагаемых к ним библиотеках с тысячами полезных и уже готовых функций. Будет ли программист на языке Х со стажем 1 мес на этом языке более-менее четко знать о существовании всех наиболее употребимых и популярных библиотек и содержащихся в них функций? Ответ, понятное дело, отрицательный.
Добавьте сюда уже заботливо разработанные тысячами людей более-менее готовые фреймворки с дополнительной функциональностью на самом языке, с классами «на все случаи жизни» хотя бы для большей части наиболее популярных задач, решаемых на языке Х, и вы осознаете сократовское «я знаю, что я ничего не знаю», если вы до конца честны перед сами собой в отношении вашего знания «языка Х».
И совсем жесть — при смене парадигм. Например, я пока не испытывал потребности, но, возможно, попробую функциональный язык после многих лет императивных. Товарищи временами от такой смены стояли на ушах (одному программирование, например, преподают, и вот, после пары лет С++ и си-подобного...) Или тот же Javascript, который, казалось бы, «как все» (к нему даже встроенных библиотек нет, только сторонние библиотеки/фреймворки! синтаксис си-подобен!), но одно только понимание прототипирования и контекста вызова само по себе может очень многого стоить в дальнейших взаимоотношениях с языком.
Как бы хорошо человек не знал архитектурные решения, он вряд ли сам сможет хорошо решить задачу, если будет использовать кривой функционал языка. Тупо от незнания.
Упирать только в архитектуру может себе позволить аналитик/архитектор, который сам почти ничего не программирует. Упирать на код — кодер. Но, надеюсь, большинство не стремится ни в чистые кодеры, ни в забывающие кодирование архитекторы? :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Так ли сложна смена языка для программиста?