Комментарии 32
Очень правильный вывод. Вообще не обязательно скакать от языка к языку — хватает быть профи в своём деле, а богатство технологий позволяет решить почти любые проблемы. Ну а когда небольшая проблема перерастает в самостоятельный проект и требует другого инструментария — лучше нанять спеца, чем мудохаться самому, потому что пройдет куча времени, пока вы сможете эту проблему решить эффективно и без костылей.
согласен, отчасти. речь не о том, чтобы скакать от языка к языку, а в изучении _языка_ и практик, применяемых в нем, использовании возможностей языка на 100%.
2 года назад нужно было переписать проект с PHP на Python/Django, справились качественно и красиво без привлечения сторонних разработчиков. также было с проектом на Rails. 2 месяца назад — на Cpp + Bada.
моя практика показывает, что при глубоком знании практик и паттернов, и поиске возможностей их применения + попытке понять как лучше всего применять все это здесь и сейчас, можно добиться определенных успехов.
скакать не нужно. нужно изучать, исследовать, читать и применять. согласен.
2 года назад нужно было переписать проект с PHP на Python/Django, справились качественно и красиво без привлечения сторонних разработчиков. также было с проектом на Rails. 2 месяца назад — на Cpp + Bada.
моя практика показывает, что при глубоком знании практик и паттернов, и поиске возможностей их применения + попытке понять как лучше всего применять все это здесь и сейчас, можно добиться определенных успехов.
скакать не нужно. нужно изучать, исследовать, читать и применять. согласен.
ниочём статья
А заголовок то еще какой странный, да и запятая не на том месте
Статья о том, какой широкий кругозор у автора :)
По удивительному стечению обстоятельств его не хватило упомянуть о не ОО методолгоиях, для которых новые языки и есть.
По удивительному стечению обстоятельств его не хватило упомянуть о не ОО методолгоиях, для которых новые языки и есть.
не совсем понял посыла: новые языки — для не ОО методолгий?..
вообще говоря, о не-ОО речь была. тут можно и scala вспомнить, и lisp с s-expressions. в нем ОО и persistance как-то не встречал. smalltalk, lisp и cpp придумали много лет назад. на самом деле, с тех пор особенных прорывов совершено не было. dynamic dispatch и объектная модель Ruby — за основы взят smalltalk. lisp сейчас чаще встречается в виде clojure. cpp и его подходы также не новы.
речь совсем не о кругозоре, поверьте ;)
вообще говоря, о не-ОО речь была. тут можно и scala вспомнить, и lisp с s-expressions. в нем ОО и persistance как-то не встречал. smalltalk, lisp и cpp придумали много лет назад. на самом деле, с тех пор особенных прорывов совершено не было. dynamic dispatch и объектная модель Ruby — за основы взят smalltalk. lisp сейчас чаще встречается в виде clojure. cpp и его подходы также не новы.
речь совсем не о кругозоре, поверьте ;)
Много прорывов с того времени было, pure functional languages, finger trees, theorem prover's и formal verification.
Не много толку учить еще один фреймоврк и еще один метод решения чего-то, нужно учить более общие тероии, позволяющие выводить эти методы самому, тоерию типов, категорий, множеств и тп
Не много толку учить еще один фреймоврк и еще один метод решения чего-то, нужно учить более общие тероии, позволяющие выводить эти методы самому, тоерию типов, категорий, множеств и тп
За новые языки и против укуривания мегабайтами манов к API… вы рвете шаблон большей части кодеров )))) (и правильно делаете)
Очень интересно было впервые почувствовать на себе как новый язык меняет твое отношение к програмированию и к использованию уже извесных тебе технологий. Я как обычный обыватель начал с Pascal, а потом пошел php который «обьяснил» мне множество неясних элементов и научил внимательнее относиться к коду, а дальнейший С++ научил продумывать все на несколько шагов вперед. Новый язык действительно дает возможность посмотреть на все используемое с другой точки зрения, в чем я собственно и согласен с автором.
Потом откроете для себя ФП и вообще офигеете )
А потом придет понимание, что язык — это что-то вроде гаечного ключа. Для толковой работы неплохо бы иметь набор.
А потом откроете для себя DSL и сами будете делать наборы по мере необходимости ;)
А иногда мне кажется, что рядом какая та выставка, с сотней тысяч разновидностей ключей, которые все нахваливают, изучают. При этом большинство из этих ключей решают не более 5% задачи проекта и сокращаюат (удлиняют?) время разработки очень незначительно.
А я сижу рядом, и кручу своим старым набором ключей, форды или ферари :). Изредка нравится побаловаться новыми ключами конечно… но, их влияние мало очень.
А я сижу рядом, и кручу своим старым набором ключей, форды или ферари :). Изредка нравится побаловаться новыми ключами конечно… но, их влияние мало очень.
Заголовок поражает глубиной своей мысли, как впрочем и вся статья.
кеп вы снова тут?
Довольно таки неграмотная и плоская статья.
Не совсем понял, о чем статья. Изучать языки — хорошо, изучать API — хорошо, изучать код — очень хорошо. Да, учиться — это всегда хорошо.
По-моему, самое полезное в статье — это ссылки.
> Если говорить об объектно-ориентированных языках со статической типизацией, на самом деле разница небольшая
ну да, а если ограничиться, скажем, объектно-ориентированными языками со статической типизацией, имя которых начинается с C, то разница будет ещё меньше. а если поставить условие, что имя не содержит символа "+", или, наоборот, имя начинается с любого символа, но содержит решётку, то разница будет совсем маленькой.
lisp? prolog? haskell? forth?
ну да, а если ограничиться, скажем, объектно-ориентированными языками со статической типизацией, имя которых начинается с C, то разница будет ещё меньше. а если поставить условие, что имя не содержит символа "+", или, наоборот, имя начинается с любого символа, но содержит решётку, то разница будет совсем маленькой.
lisp? prolog? haskell? forth?
А как насчет clojure? Scala? Erlang? Nemerle?
Думаю, что всего не перечислить.
Я выбираю язык в качестве инструмента. Мне подходит одно а вам другое…
Думаю, что всего не перечислить.
Я выбираю язык в качестве инструмента. Мне подходит одно а вам другое…
ну так вы выбираете язык в качестве инструмента, а потом жалуетесь, что все языки похожи.
вот, например, Василий делает сайты, выбирает язык в качестве инструмента (получается всё время php) и жалуется, что все языки похожи. Иван делает энтерпрайз-приложения. он использует C# и C и C++. тоже жалуется на похожесть языков.
если использовать язык как инструмент для решения задачи, то, поскольку спектр задач обычно ограничен, то и выбор языка ограничен каким-то набором.
вот, например, Василий делает сайты, выбирает язык в качестве инструмента (получается всё время php) и жалуется, что все языки похожи. Иван делает энтерпрайз-приложения. он использует C# и C и C++. тоже жалуется на похожесть языков.
если использовать язык как инструмент для решения задачи, то, поскольку спектр задач обычно ограничен, то и выбор языка ограничен каким-то набором.
я лично считаю, что многие языки самоценны.
как минимум, это
(Lisp / scheme / их диалекты), Prolog, Forth, Haskell. их стоит изучить, поскольку они дают новый подход к решению задач. а если повезёт — то добавляют ещё и «чёрт возьми, как мало я оказывается знаю», ну и уж точно лишают иллюзии, будто бы «все языки похожи».
как минимум, это
(Lisp / scheme / их диалекты), Prolog, Forth, Haskell. их стоит изучить, поскольку они дают новый подход к решению задач. а если повезёт — то добавляют ещё и «чёрт возьми, как мало я оказывается знаю», ну и уж точно лишают иллюзии, будто бы «все языки похожи».
я не жалуюсь на похожесть языков, вовсе.
речь о том, что из каждого языка есть, что почерпнуть. и часто — чтение кода и изучение решений может помочь развиться. хотя, возможно, в статье это не так четко сформулировано.
ограничение спектра задач — относительная штука. можно выбирать разные инструменты для решений схожих задач.
на самом деле, я большему научился из комментариев (тут — немного конструктивных было, на NH и у меня на блоге + личных больше было толковых), нежели изложил. статья получилась сбитая, сумбурная и неполная. хотя, дошло до меня только после того, как люди дали фидбеки.
речь о том, что из каждого языка есть, что почерпнуть. и часто — чтение кода и изучение решений может помочь развиться. хотя, возможно, в статье это не так четко сформулировано.
ограничение спектра задач — относительная штука. можно выбирать разные инструменты для решений схожих задач.
на самом деле, я большему научился из комментариев (тут — немного конструктивных было, на NH и у меня на блоге + личных больше было толковых), нежели изложил. статья получилась сбитая, сумбурная и неполная. хотя, дошло до меня только после того, как люди дали фидбеки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем нужны «другие» языки программирования: может, я обойдусь фреймворком?