Вы меня обвинили в самоуверенности на основании моих чисто пользовательских наблюдений за YouTube.
Я вам про YouTube вообще ничего не говорил, это вы почему-то выбрали из списка крупных проектов на Python тот, с которым у вас не сложилось, и на этом примере стали рассказывать про то, что одни языки предназначены для крупных проектов, а другие нет.
А ответил я вам на вот это:
Но комментатор ниже прав: наличие крупных проектов само по себе не доказывает, что язык для них пригоден.
Проблема роста проекта успешно решается через модульность уже много лет. Причём модульность в любом виде, так что даже проекты на C, в котором на уровне языка такого понятия нет, прекрасно растут просто за счёт правильной организации кода и инклюдов. Единственная проблема масштабируемости, которая зависит от языка и технологии, это проблема роста производительности. Но к организации кода она не имеет никакого отношения.
Так вот в ESS практически всё то же самое — редактор с подсветкой синтаксиса и автодополнением, выполнение произвольных комманд, в т.ч. и для показа графиков (в отдельном окне, правда, но, я думаю, это можно пережить :)), даже дебаггер вроде как есть (хотя я сам им не пользовался, так что про качество ничего не скажу). Так что тоже вполне себе IDE!
Когда случается потребность (пусть и редкая) — становится очень даже критичной. Ну и для работы с внутренними переменными тоже бывает полезно
Внутренние переменные прекрасно заменяются через string replace, так что это вообще не проблема. Для внешних вполне работает grep и sed. Но если это может делать IDE, то это несомненный плюс, тут не поспоришь. Однако я честно не думаю, что IDE для Java получили такое развитие только из-за необходимости время от времени переименовывать переменные.
Инструменты рефакторинга это делать аккуратнее, быстрее и с лучшим охватом мест использования (не приходится их искать).
Да ладно, что именно во внешних зависимостях поменяется, если вы часть методов вынесите из данного класса в его абстрактного предка?
Понимаю, но слишком уж максималитичо было сказано.
Я это к тому, что никогда нельзя делать однозначные заявления о том, почему и зачем что-то произошло. И никогда не стоит решать за других людей, как им удобней работать и какие инструменты для них важнее.
Это значит, что на подготовку более или менее самостоятельного C++ разработчика уходит чертовски много времени.
А если подключить ещё пару фреймворков и вспомнить огромное JDK — то даже на простом проекте без поиска приходится тяжеловато (все классы не запомнишь).
Apache Spark — прекрасный пример, где структура директорий практически однозначно определяет местоположение какого-то куска кода. По сути, если пропустить общий для всех пакетов префикс «org.apache.spark», то получается практически двухуровневая иерархия — имя подпакета (например, «rdd», «storage», «scheduler») и дальше список файлов-классов.
можно, но в процессе написания кода, бывает, приходит понимание более точного названия — вручную переименовывать?
Внешний API модуля меняется редко, так что на практике даже ручное переименование не создаёт особых проблем. Т.е. фича полезная, но не критичная.
опять же в процессе разработки класс разрастается + появляются классы с похожим функционалом — вынести общее в общий абстрактный — вполне себе вариант.
Ctrl+X Ctrl+V раз в месяц — не проблема, проблема именно когда рефакторинг становится ежедневным и/или длительным процессом.
И да, вы ещё забыли кучу различных рефакторингов
Я ничего не забыл, но ведь и вы помните, что всё это спекуляция, и к реальности может не иметь никакого отношения?
А хотите, я вам расскажу альтернативную притчу? C 91 по 95 год человек по имени Джейсм Гослинг работал над языком Oak в компании Sun Microsystems. Sun Microsystems на тот момент, вообще говоря, была не столько софтварной, сколько хардварной компанией, производящей большое разнообразие серверов, десктопных и микрокомпьютеров. Естественным желанием компании было найти общий знаменатель для всех своих систем. Отсюда и появился Java bytecode, а также знаменитый лозунг «write once, run anywhere».
В начале 2000х случился бум доткомов, тотальное распространение интернета и клиент-серверного ПО. Если есть потребность в программах, есть и потребность в разработчиках, способных их создавать. Проблема в том, что в тот момент достаточно квалифицированных разработчиков, способных писать на менстримовом C++ серверное ПО, которое бы не «текло» и не приводило к segfault-ам, было гораздо меньше, чем требовалось. Процесс обучения новых рекрутов был длительным и болезненным, поэтому нужно было снижать планку.
И вот тут Java выстрелила. В ней не нужно было следить за выделением и освобождением памяти, не нужно было учить 100500 замысловатых конструкций и концепций языка и даже исключения везде указывались явно, так что забыть их проверить было просто невозможно. Просто идеальный язык для толпы низкоквалифицированных недоспециалистов.
Но одной только смены языка недостаточно, чтобы успешно (с точки зрения дальнейшей продажи) писать большие проекты. Всё-таки нужны были тим лиды, простые правила, показывающие, как «правильно», и постоянный рефакторинг. Вручную перерефакторить говнокод, написанный толпой обезъянок, — та ещё работёнка. Поэтому нужны были средства для упрощения поиска нужных классов (из структуры директорий то непонятно, где что лежит), массового переименования (сразу то подумать как назвать переменную нельзя), вынесения методов в общий абстрактный класс (ведь простые правила, которые показал тимлид, в данном случае оказались слишком упрощёнными).
А как автоматизировать все эти задачи? Правильно, написать IDE, которая не заставит недоспециалистов писать хороший код, но позволит потом проще разгребать получившуюся кашу. И именно поэтому, как уже неоднократно замечали тут в комментариях, Java — это практически единственный язык, писать на котором без IDE просто невозможно.
Вся эта история, конечно, ложь и профанация — я за спиной у Гослинга и IBM не стоял, и как всё было на самом деле знать не могу. Но скажите, чем ваша история лучше?
Так а что в ней есть от «настоящих IDE»? ) Вроде адских инструментов для рефакторинга нет? Визуализация графиков? Так она и в чистой консоли есть. Дебаггер? Ну может быть, но вроде как REPL его вполне неплохо заменяет.
Чисто из интереса, а чего вам в Emacs + ESS не хватает, что есть, например, в той же RStudio?
Скажем, выдаст она в автодополнении 1000 вариантов названий функций
Это если вы попросите её показать вообще весь список доступных в этом месте функций?
2-3 символов обычно вполне хватает, чтобы сократить список до вполне разумных пределов.
А каким боком области видимости влияют на возможности IDE? Проанализировать include-ы ничуть не сложнее, чем проанализировать import-ы, а C — синтаксически достаточно простой язык, в разы проще той же Scala, например.
Так или иначе, это только один из примеров одного известного человека. А есть целые сообщества и даже компании, которые уходят с тяжеловесных IDE на что-то более простое и кастомизируемое. Например, посмотрите на Atom от GitHub-а — они его явно не от безделия создали. Или на сообщество языка Julia, где главный рекоммендуемый редактор — Juno — построен на LightTable. Ну или на R, где основная альтернатива — это либо Emacs+ESS, либо RStudio, которая тоже мало чем отличаетя от блокнота со встроенным REPL-ом. Примеров — сотни.
А уж взять код имеющегося плагина (если он open-source) и добавить в него простую фичу — это вообще час-два работы.
Час-два работы — это круто. Последнюю фичу в Emacs — переключение на консоль и переход в конец буфера — я написал примерно за 10 минут. Вы бы как раз к этому моменту докачали код плагина и открыли проект.
И давайте на чистоту: как много пользователей IDEA пишут для неё плагины? Для пользователей Emacs это обычные и даже немного рутинное дело.
вместо того, чтобы мирно признать, что их проекты просто меньше, чем те, в которых работают на IDE. Это же удар по самолюбию — вроде как несерьезное дело делаешь…
В языках «таких как Java» не требуется добавлять временный метод main, так как достаточно проставить точку останова в нужное место и после этого ввести в Watch нужное вам выражение.
А теперь давайте поиском по странице найдём мой комментарий со словом «watch», в котором я подробно рассказываю, почему дебаггер + watch даже рядом не стоят с REPL.
Я никаких выводов не делал. Всего лишь указал вам на то, что считаю неверным и предупредил, что вас могут понять превратно.
Интересный у вас способ отреагировать на это заявление, если процитировали вы совершенно другое. Ну ладно, пусть будет по-вашему. Может быть у вас есть какие-то аргументы, почему вы считаете, что я на своём языке программирования делаю свои же задачи неправильно? Расскажите мне, пожалуйста, как мне правильно программировать на Python и самое главное почему?
Но загвоздка в том, что ее надо настраивать, изучать (а современные IDE сложны), а это — лень. А без адекватной настройки она — да — будет скорее мешать, увы.
Интересно, что большинство сторонников IDE здесь в комментариях придерживаются как раз мнения, что настраивать нужно «редактор».
Я вам про YouTube вообще ничего не говорил, это вы почему-то выбрали из списка крупных проектов на Python тот, с которым у вас не сложилось, и на этом примере стали рассказывать про то, что одни языки предназначены для крупных проектов, а другие нет.
А ответил я вам на вот это:
Внутренние переменные прекрасно заменяются через string replace, так что это вообще не проблема. Для внешних вполне работает grep и sed. Но если это может делать IDE, то это несомненный плюс, тут не поспоришь. Однако я честно не думаю, что IDE для Java получили такое развитие только из-за необходимости время от времени переименовывать переменные.
Да ладно, что именно во внешних зависимостях поменяется, если вы часть методов вынесите из данного класса в его абстрактного предка?
Я это к тому, что никогда нельзя делать однозначные заявления о том, почему и зачем что-то произошло. И никогда не стоит решать за других людей, как им удобней работать и какие инструменты для них важнее.
Не входит, пользуйтесь на здоровье базовой версией.
Это значит, что на подготовку более или менее самостоятельного C++ разработчика уходит чертовски много времени.
Apache Spark — прекрасный пример, где структура директорий практически однозначно определяет местоположение какого-то куска кода. По сути, если пропустить общий для всех пакетов префикс «org.apache.spark», то получается практически двухуровневая иерархия — имя подпакета (например, «rdd», «storage», «scheduler») и дальше список файлов-классов.
Внешний API модуля меняется редко, так что на практике даже ручное переименование не создаёт особых проблем. Т.е. фича полезная, но не критичная.
Ctrl+X Ctrl+V раз в месяц — не проблема, проблема именно когда рефакторинг становится ежедневным и/или длительным процессом.
Я ничего не забыл, но ведь и вы помните, что всё это спекуляция, и к реальности может не иметь никакого отношения?
В начале 2000х случился бум доткомов, тотальное распространение интернета и клиент-серверного ПО. Если есть потребность в программах, есть и потребность в разработчиках, способных их создавать. Проблема в том, что в тот момент достаточно квалифицированных разработчиков, способных писать на менстримовом C++ серверное ПО, которое бы не «текло» и не приводило к segfault-ам, было гораздо меньше, чем требовалось. Процесс обучения новых рекрутов был длительным и болезненным, поэтому нужно было снижать планку.
И вот тут Java выстрелила. В ней не нужно было следить за выделением и освобождением памяти, не нужно было учить 100500 замысловатых конструкций и концепций языка и даже исключения везде указывались явно, так что забыть их проверить было просто невозможно. Просто идеальный язык для толпы низкоквалифицированных недоспециалистов.
Но одной только смены языка недостаточно, чтобы успешно (с точки зрения дальнейшей продажи) писать большие проекты. Всё-таки нужны были тим лиды, простые правила, показывающие, как «правильно», и постоянный рефакторинг. Вручную перерефакторить говнокод, написанный толпой обезъянок, — та ещё работёнка. Поэтому нужны были средства для упрощения поиска нужных классов (из структуры директорий то непонятно, где что лежит), массового переименования (сразу то подумать как назвать переменную нельзя), вынесения методов в общий абстрактный класс (ведь простые правила, которые показал тимлид, в данном случае оказались слишком упрощёнными).
А как автоматизировать все эти задачи? Правильно, написать IDE, которая не заставит недоспециалистов писать хороший код, но позволит потом проще разгребать получившуюся кашу. И именно поэтому, как уже неоднократно замечали тут в комментариях, Java — это практически единственный язык, писать на котором без IDE просто невозможно.
Вся эта история, конечно, ложь и профанация — я за спиной у Гослинга и IBM не стоял, и как всё было на самом деле знать не могу. Но скажите, чем ваша история лучше?
Ага, аж на 0.6%.
Вам бы почитать, что из себя представляет init.el, и как его можно использовать для кастомизации редактора.
Чисто из интереса, а чего вам в Emacs + ESS не хватает, что есть, например, в той же RStudio?
Это если вы попросите её показать вообще весь список доступных в этом месте функций?
2-3 символов обычно вполне хватает, чтобы сократить список до вполне разумных пределов.
Вот в следущий раз лучше сразу начинайте комментарий со слов «по-моему мнению», это снимет много вопросов.
Охх, как же уже надоели эти мифы...
Т.е. вы сначала прочитали первое предложение, потом ответили, а потом дочитали комментарий? Окааай.
Нет, я написал полное время разработки — от появления необходимости, до готовой к использованию фичи.
Так или иначе, это только один из примеров одного известного человека. А есть целые сообщества и даже компании, которые уходят с тяжеловесных IDE на что-то более простое и кастомизируемое. Например, посмотрите на Atom от GitHub-а — они его явно не от безделия создали. Или на сообщество языка Julia, где главный рекоммендуемый редактор — Juno — построен на LightTable. Ну или на R, где основная альтернатива — это либо Emacs+ESS, либо RStudio, которая тоже мало чем отличаетя от блокнота со встроенным REPL-ом. Примеров — сотни.
Час-два работы — это круто. Последнюю фичу в Emacs — переключение на консоль и переход в конец буфера — я написал примерно за 10 минут. Вы бы как раз к этому моменту докачали код плагина и открыли проект.
И давайте на чистоту: как много пользователей IDEA пишут для неё плагины? Для пользователей Emacs это обычные и даже немного рутинное дело.
CPython — почти миллион строк кода и 25 лет разработки. Это достаточно большой проект? Однако же Гвидо всё ещё пишет его в Vim/Emacs и недолюбливает Eclipse.
А теперь давайте поиском по странице найдём мой комментарий со словом «watch», в котором я подробно рассказываю, почему дебаггер + watch даже рядом не стоят с REPL.
Интересный у вас способ отреагировать на это заявление, если процитировали вы совершенно другое. Ну ладно, пусть будет по-вашему. Может быть у вас есть какие-то аргументы, почему вы считаете, что я на своём языке программирования делаю свои же задачи неправильно? Расскажите мне, пожалуйста, как мне правильно программировать на Python и самое главное почему?
Интересно, что большинство сторонников IDE здесь в комментариях придерживаются как раз мнения, что настраивать нужно «редактор».