Comments 42
Больше похоже на первоапрельский пост, на первый взгляд
Пытаюсь понять, на что пародия? По аргументации похожа на какую-то конкретную статью.
Так автор явно написал, что пародия на статьи и комментарии divan0 про язык Go.
В начале же есть ссылка на оригинал, клик
В треш.
А мне понравилось безотносительно того, что этот перевод пародирует.
Видел компании, которые разрабатывали свои стандарты кода месяцами, тратя время на их разработку, модернизацию, приведение кода к стандарту и так далее. Причём некоторые правила были неформализуемыми для IDE — то есть, внедрить их можно было только руками.
Бессмысленные правила, стандарты, соглашения, регламенты, "хороший стиль" — всё это убивает безумное количество человекочасов, и в большинстве случаев никоим образом не влияет на качество продукта. Большинство таких правил абсолютно субъективны, на что так же намекает статья.
Вообще, обо всём этом уже было сказано у Джонатана Свифта касательно войны "остроконечников и тупоконечников". Но за последние несколько тысяч лет человеческая природа изменилась не так сильно, как кажется — и война бессмысленных вопросов всё ещё актуальна.
Видел компании, которые разрабатывали свои стандарты кода месяцами, тратя время на их разработку, модернизацию, приведение кода к стандарту и так далее. Причём некоторые правила были неформализуемыми для IDE — то есть, внедрить их можно было только руками.
Бессмысленные правила, стандарты, соглашения, регламенты, "хороший стиль" — всё это убивает безумное количество человекочасов, и в большинстве случаев никоим образом не влияет на качество продукта. Большинство таких правил абсолютно субъективны, на что так же намекает статья.
Вообще, обо всём этом уже было сказано у Джонатана Свифта касательно войны "остроконечников и тупоконечников". Но за последние несколько тысяч лет человеческая природа изменилась не так сильно, как кажется — и война бессмысленных вопросов всё ещё актуальна.
Давно уже пора перестать писать программы буквами, это пережиток прошлого. Программы нужно собирать из схем, каталогов элементов, интерактивно конфигурируемых компонентов и т.д. Всё в облаке и коллаборативно, конечно, и через тачевый интерфейс. С автоматическим анализом противоречивости архитектуры, с эвристическими подсказками, с версионностью компонентов и ролями программистов. Некоторые алгоритмы обработки данных (сортировки/фильтры/поиски), конечно, могут описываться языковыми конструкциями, но для прикладного программиста должны быть просто элементами меню «Параметры контейнера данных».
Современные программисты, кажется, погрязли в спорах об отступах, о кэмэлкейсах, о скобках, отодвинув алгоритмы и архитектуру на второй план. Слишком много усилий прикладывается к тому, чтобы в виде исходного текста описать всего лишь какую-нибудь одну стрелку, соединяющую два компонента, или какой другой атомарный аспект умозрительной схемы приложения в голове программиста. Было бы гораздо эффективнее этой стрелкой оперировать непосредственно, без конвертирования в текст туда-сюда и контроля того, как поняли этот текст остальные. Зачастую на выдумывание имени промежуточной переменной тратится изрядное количество усилий, когда она является всего лишь способом «тыкнуть пальцем сюда и сюда и сказать, что это одно и то же».
Промышленное визуальное программирование — неизбежное, хотя ещё и не наступившее будущее. Рано или поздно текстовые языки программирования вымрут (в прикладном программировании) как ассемблер или латынь, IMHO.
Современные программисты, кажется, погрязли в спорах об отступах, о кэмэлкейсах, о скобках, отодвинув алгоритмы и архитектуру на второй план. Слишком много усилий прикладывается к тому, чтобы в виде исходного текста описать всего лишь какую-нибудь одну стрелку, соединяющую два компонента, или какой другой атомарный аспект умозрительной схемы приложения в голове программиста. Было бы гораздо эффективнее этой стрелкой оперировать непосредственно, без конвертирования в текст туда-сюда и контроля того, как поняли этот текст остальные. Зачастую на выдумывание имени промежуточной переменной тратится изрядное количество усилий, когда она является всего лишь способом «тыкнуть пальцем сюда и сюда и сказать, что это одно и то же».
Промышленное визуальное программирование — неизбежное, хотя ещё и не наступившее будущее. Рано или поздно текстовые языки программирования вымрут (в прикладном программировании) как ассемблер или латынь, IMHO.
Вы передёргиваете. Если бы вы оставались в рамках моей метафоры, то предложили бы использовать телепатию и нейроинтерфейсы вместо текстового общения. И да, это тоже было бы предложением, которым, увы, нельзя воспользоваться прямо сейчас. Но мечтать о таком не вредно и даже полезно, на мой взгляд.
Я как шумер могу сказать вам, что у клинописи всегда будет преимущество перед буквенной письменностью. Почему обычно удобнее пользоваться картой, а не текстовым описанием карты? Почему инженеры пользуются чертежами, а не текстовыми описаниями? Возможно, вы слишком категоричны в оценках _практичной_ сводимости любого типа абстрактной информации к тексту.
Я как шумер вижу вокруг, что все пользуются клинописью. Действительно, других форм не наблюдается (почти). Не связано ли это с сопутствующими технологиями изготовления текстовых носителей и их заполнения? А теперь сравните клинописную палочку с тачевым планшетом. Не пора ли попробовать поискать новые формы?
У "идеографической и иероглифической" информации иногда есть преимущество, если все адресаты точно понимают смысл и имеют ту же не-текстовую информацию (типа эмоций). Но попробуйте иностранцу показать эту картинку.
Если информация из большего количества слов, чем два-три, то прочитать быстрее. Особенно поэтому я не люблю видеоуроки.
何？
Ну как сказать, возможность вставить картинку или диаграмму прямо в код в качестве комментария — это очень удобно. Особенно когда дело математики касается.
Реализуйте.
Возможно вы станете одним из отцов-основателей Нового Программирования ))
На самом деле о таком программировании многие мечтают, но когда дело касается практики, все равно все сводится к тому, что нужно щелкнуть на компоненте и написать какой-то код в окошке (и это в лучшем случае).
Возможно вы станете одним из отцов-основателей Нового Программирования ))
На самом деле о таком программировании многие мечтают, но когда дело касается практики, все равно все сводится к тому, что нужно щелкнуть на компоненте и написать какой-то код в окошке (и это в лучшем случае).
Верно, пока это всего лишь мечты. Различные редакторы блоксхем уже были, были и RAD-средства типа Delphi или VВ, были и попытки заменить редактирование текста редактированием AST (с автоматическим конвертированием представления логики в несколько ЯП). Но до цельной и монолитной концепции пока дело не дошло, всё это было в большей степени пока лишь надстройкой над текстовым представлением.
Именно основателем не станет, т.к. все вакантные места таких отцов уже разобраны :)
Например, давно есть NI LabVIEW. Совсем без букв, конечно, не обойтись, но для многих задач можно вообще ни строчки кода руками не написать.
Например, давно есть NI LabVIEW. Совсем без букв, конечно, не обойтись, но для многих задач можно вообще ни строчки кода руками не написать.
Вы слишком категоричны. Я пятнадцать лет программирую на LabVIEW. Автоматизация производства и машинное зрение. Это язык визуальный, и для меня — основной язык разработки. Смею вас заверить — без букв там не обходится, и переменным надо давать имена и всё такое. При этом я владею также С, С++ и С#. Более того, начинать изучение программирования надо именно с текстового языка. Знаю инженеров (как LabVIEW, так и ПЛК), вообще не владеющих текстовыми языками — программистами их назвать не могу. Я не в в том смысле, что они "глупые" — совсем нет, но мыслительный процесс их несколько своеобразен. Особенно когда им таки приходется что-то сделать в текстовом виде, ну, скажем программируя промышленный робот. Программирование на классическом текстовом языке заставляет голову работать в правильном направлении. Не знаю почему так, но это так.
Да, моя утопическая фантазия об интерфейсе IDE в стиле голливудского «Особого мнения» действительно была слишком провокационной.
Фантазия отнюдь не утопическая, я тоже считаю, что за визуальным програмированием будущее, но это очень далёкое будущее. Тут много факторов — современные средства разработки ПО к этому не готовы, взаимодействие человека и компьютера не очень развито, попытки сделать реальный интерфейс в стиле "особого мнения" выглядят красиво, но на самом деле нефункциональны, огромное количество существующего текстового кода, отсутствие каких бы то ни было стандартов на визуальный язык, бешеная стоимость средств разработки (LabVIEW c парой пакетов и подпиской упирается в десятку тысяч и отнюдь не рублей) и т.д. Сами посмотрите — доля того же LabVIEW, если взять рейтинг Tiobe — 0,3%. Подождите лет этак сто, может сто пятьдесят — пара-тройка поколений программистов сменится и ситуация начнёт меняться. Я так думаю, переломный момент наступит тогда, когда сама IDE будет написана на графическом языке. Ну а пока что среда LabVIEW сама по себе написана на старом добром С++.
Понимаю, что сатира, но на что — не очень, потому что не слежу за ruby-сообществами. Пошёл на reddit:
На сайте lobste.rs заметили, что это ответ на статью использование знака «больше» в программах. Который показывает, что уровень дискуссии о конвенциях в программировании всё ниже и ниже.
- Первый довод основывается на ложном предположении, что все терминалы высотой 24 строки.
- «Раз для меня это сложно, этого нужно избегать».
- «Раз это не требуется, давайте и не делать» — если что-то можно не делать, это не значит, что нужно не делать.
- Про доводы от «любого, кто тренировал новичка» и строки 1, 39: довод от авторитета, «если этого не знаешь, ты никто».
- Эта статья и демонстрирует субъективные доводы, которые подаются как истина, и показывает, как далеко мы ушли от научности, с которой когда-то было связано программирование.
На сайте lobste.rs заметили, что это ответ на статью использование знака «больше» в программах. Который показывает, что уровень дискуссии о конвенциях в программировании всё ниже и ниже.
Не лучший выбор для песочницы, ИМХО.
Имхо — все сугубо индивидуально. Это равносильно тому, что сказать: не пишите код больше n-строк на файл, ибо его можно не заметить\надо перелистывать
А мне почему-то вспомнилось то, что есть на скриншоте: не пишите строки больше 80 символов (и красная черта).
Тоже уже многие мониторы позволяют обходить эту особенность, но ведь ограничение рассчитано на небольшие мониторы и для того, чтобы меньше глаза "пригали" со строки на строку.
Нравится, как в PSR-2 описаны рекомендации по длине строки: "желательно" не больше 80 символов.
Тоже уже многие мониторы позволяют обходить эту особенность, но ведь ограничение рассчитано на небольшие мониторы и для того, чтобы меньше глаза "пригали" со строки на строку.
Нравится, как в PSR-2 описаны рекомендации по длине строки: "желательно" не больше 80 символов.
45-я строка ниже края экрана
Зависит от размера экрана и его ориентации же
Насколько мне известно, нет языка программирования, действительно требующего располагать какой-либо код на 45-й строке.
Более того, насколько мне известно, нет языка программирования, который требовал бы писать какой-либо код на какой-либо строке. Так что, товарищи, начинайте писать строки с 300-й. Так будет интереснее.
Был язык программирования, который заставлял даже вручную нумеровать эти строки. GOTO 10 (я начинал с десятой, закладывая риск в десять дополнительных строк).
… и нумеровал тоже через 10, чтобы потом если что можно было код вставить
так это же бейсик! Я тоже так делал. В 1995 году у меня был советский компьютер БК-0010-01 (на гиктаймсе), в нём при входе сразу включался интерпретатор бейсика (а ещё был ещё один язык Фокал, в котором тоже нужно было ставить номера строк). И там обычно строки нумеровались десятками — 10, 20, 30… Это нужно было как раз для того, чтобы добавить строки между уже добавленными строками.
В "хороших" Бейсиках была команда RENUM.
Чем-то напомнило О вреде огурцов.
Sign up to leave a comment.
Не пишите код на 45-й строке