Прощу прощения за долгий ответ, но вот только дошли руки. Я думаю, что возможность иметь адаптированное отображения для кода — это прекрасно и мы точно к этому придём. Причём было бы прикольно иметь различные срезы — для SRE, DBA, инженеров по безопасности, продактов и бизнес и системных аналитиков. Это чуть более высокий уровень чем тот, про который вы пишите, но кажется такие представления могли бы решить много проблем. Довольно часто из кода можно восстановить изначальную постановку задачи и то, каким именно образом она была решения. А имея всё это, можно записать решение в более подходящем для восприятия виде. Я уверен, что так и будет.
Но ведь тоже касается и написания. Если мне нужно решить задачу и у меня есть алгоритм, которым я хочу решить эту задачу, то кажется самое простое что я могу сделать — это описать ограничения задачи и сам алгоритм. На русском/английском используя математические термины или термины предметной области — это не важно. Если есть модель, которая хорошо воспринимает естественные и формальные языки, то так ли важно в какой именно код она преобразует написанное мной? Важно чтобы она смогла передать мне все условия и ограничения своего решения, но ведь для этого даже не обязательно показывать сгенерированный код. Достаточно описать это в лаконичной понятной форме, как это делает Wolfram M.
Таким образом, мой тезис про то, что читать важнее чем писать, он скорее про то, что сейчас следует ориентироваться на то, что человек не будет писать код. Точно также как мы сейчас редко пишем на низкоуровневых языках, написание кода на высокоуровневых языках станет нишевой историей. Потому что написание кода на любом языке — это снижение уровня абстракции, приземление на конкретный синтаксис, паттерны и библиотеки. Думаю это функцию вполне по силам делегировать моделям и сконцентрироваться на задаче "что делать", а не "как записать" то, реализацию чего уже придумали.
--
Не знаю, ответил ли я на исходный вопрос, но в любом случае, спасибо за него, навёл на мысли )
Спасибо за развернутый ответ, сейчас мне стало понятнее и я попробую ответить.
Для описанного вами автокомплита я бы предпочел
FROM users
SELECT email, age ;
Но создатели SQL как раз приоритизировали понимание запроса человеком и исходный вариант гораздо ближе к человеческому "select email and age from users where ... " что, я полагаю, явилось причиной появления языка в том виде, в котором мы его знаем теперь. Размышление на эту тему подталкивает меня к тому, что понятность с точки зрения IDE и понятность для человека имеют большую дистанцию чем, скажем, понятность для модели и для человека. Для человека критично важно видеть итоговые структуры, которые возникают на выходе программы и желательно иметь максимально простой способ понять почему именно возникают именно такие структуры. Думаю, это и предопределило декларативность практически всех языков преобразования данных. В той же JSONata в простейших случаях мы сразу описываем ту структуру которую ждем на выходе.
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания. При этом, конечно, по возможности надо способствовать корректному написанию. В этом смысле, как только в branchline вызреют сложные типы данных (json schema вполне может быть использована для их задания), то программа на нём будет проверять корректность ещё на этапе анализа. И автокомплит по типам будет поддержан в LSP. Но до полноценной поддержки типов надо дожить )
Не совсем понял. А что такое autocomplete friendly для языка? Если рассматривать отдельно от легкой воспринимаемости для моделей, то для меня это что-то типа настроек для монако. Но тогда во-первых, на базовом уровне автокомплит есть и работает в плейграунде, а во-вторых, не понятно как это может стереть грань. И я не уверен, что такую цель нужно ставить именно перед языком, а не перед его редактором, например. Но, возможно, я как-то не так понял что вы имели в виду, буду признателен за уточнение.
Ниша узкая, это правда. Но например, если мы непременно хотим иметь возможность менять скрипт на лету и при этом иметь нечто более специализированное чем python, то у нас не так много опций — JSONiq, JSONata, JOLT, JSLT и ещё что-то редкое. У всего этого есть минусы, а если мы добавим полноценную отладку и экзотику типа вывода контрактов, то я даже не знаю подходящих альтернатив.
Но Branchline — это прежде всего эксперимент в рамках другого эксперимента. По-настоящем, как мне кажется, его можно раскрыть только если будет реализация платформы.
Видимо придирка к «распределение… описывается», я бы сказал «данные распределены вдоль прямой», но я ни разу не переводчик. Ну и в целом «алгоритмы данных предполагают» звучит довольно необычно :-)
Но как быть простому смертному? Простому, нормальному парню, который в гробу видал все эти технологии. Парню, который не торчит от новой операционки, или сраного гаджета.
Как вариант — смириться с недостатком мозгов и найти менее требовательную профессию. В депутаты можно пойти, ограничительные законы писать. Заодно можно с легкостью отыграться на этих мерзких «ботанах».
Размазывать сопли о прокуренную жилетку хабра — не вариант. А то так и будет — «жизнь заставила быть программистом», а хочется «тискать девочек во дворах» и прочее нытье. Следуйте моде: nodejs, mongodb — читать много не надо и девочкам в клубах будет что рассказать.
Как правило, такие туториалы предназначаются для самого начального уровня, чтобы можно было быстро вовлечь человека. Рассматривать здесь вопросы настройки продакшена совершенно не к месту. К тому же из начала статьи понятно, что текст от новичка к совсем новичку.
Про respond_to никто не забывает. Полезная штука. Но, к сожалению, тоже не универсальная.
Презентеры — это уже немного про другое, в любом случае, возникает вопрос о том, как хранить эти самые презентеры, чтобы удержать контроль над кодом.
Раз уж заговорили про презентеры, то вот — blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/
Rails way, Rails wayем, а то что реально решает проблемы, пропускать не стоит.
А разгадка одна — желание сделать код как можно более легким для поддержания. CanCan — норм, когда речь идет о простых вещах. Сложные контроллеры порождают кучу условных фильтров, мусорных спецификаций (типа блоков respond_to) и соотношение неполезного кода к полезному становится не в пользу последнего. Некоторых людей это раздражает.
Использовать такое разделение с самого начала проекта, конечно, спорное решение. Особенно, когда непонятно, появятся такие сущности или нет. Но, например, автор статьи несколько месяцев назад подал идею разнести отдачу html и js по разным контроллерам. А именно, js-ответы вынести в API. Совсем не типично для Rails Way, но результат на практике мне очень нравится.
А в целом — присоединяюсь к комментатору ниже, написавшему про Engines. Особенно с Rails 3.1+
Да, да. Аджайл — это дисциплина (а, RUP видимо — вершина безалаберностью). Всегда казалось, что аджайл — это гибкость, свобода. Жертвуем строгостью процесса, ради более эффективной работы. Individuals and interactions over processes and tools и все такое.
Но, проповедники налегают. В общем, комментарии выше вскрывают проблемы в полной мере, почти нечего добавить.
Развернутый ответ на этот вопрос заслуживает отдельного топика. Почему-то его задают чаще всего (вместе с «а что будете делать, если на вас наедут?» :-)
Если кратко, будем бороться комплексно: продуманное управление репутацией пользователя, ручной модерацией, будем давать слово бизнесу и будем учить его работать с такими отзывами.
К сожалению, это не самая тяжелая задача, которую нам предстоит решить.
Тогда надо работать над тем, чтобы поход к руководителю не был неприятной, стрессовой ситуацией. Уходить от «жалоб» и «попрощайничества» к чему-то более конструктивному.
Прощу прощения за долгий ответ, но вот только дошли руки. Я думаю, что возможность иметь адаптированное отображения для кода — это прекрасно и мы точно к этому придём. Причём было бы прикольно иметь различные срезы — для SRE, DBA, инженеров по безопасности, продактов и бизнес и системных аналитиков. Это чуть более высокий уровень чем тот, про который вы пишите, но кажется такие представления могли бы решить много проблем. Довольно часто из кода можно восстановить изначальную постановку задачи и то, каким именно образом она была решения. А имея всё это, можно записать решение в более подходящем для восприятия виде. Я уверен, что так и будет.
Но ведь тоже касается и написания. Если мне нужно решить задачу и у меня есть алгоритм, которым я хочу решить эту задачу, то кажется самое простое что я могу сделать — это описать ограничения задачи и сам алгоритм. На русском/английском используя математические термины или термины предметной области — это не важно. Если есть модель, которая хорошо воспринимает естественные и формальные языки, то так ли важно в какой именно код она преобразует написанное мной? Важно чтобы она смогла передать мне все условия и ограничения своего решения, но ведь для этого даже не обязательно показывать сгенерированный код. Достаточно описать это в лаконичной понятной форме, как это делает Wolfram M.
Таким образом, мой тезис про то, что читать важнее чем писать, он скорее про то, что сейчас следует ориентироваться на то, что человек не будет писать код. Точно также как мы сейчас редко пишем на низкоуровневых языках, написание кода на высокоуровневых языках станет нишевой историей. Потому что написание кода на любом языке — это снижение уровня абстракции, приземление на конкретный синтаксис, паттерны и библиотеки. Думаю это функцию вполне по силам делегировать моделям и сконцентрироваться на задаче "что делать", а не "как записать" то, реализацию чего уже придумали.
--
Не знаю, ответил ли я на исходный вопрос, но в любом случае, спасибо за него, навёл на мысли )
Спасибо за развернутый ответ, сейчас мне стало понятнее и я попробую ответить.
Для описанного вами автокомплита я бы предпочел
Но создатели SQL как раз приоритизировали понимание запроса человеком и исходный вариант гораздо ближе к человеческому "select email and age from users where ... " что, я полагаю, явилось причиной появления языка в том виде, в котором мы его знаем теперь.
Размышление на эту тему подталкивает меня к тому, что понятность с точки зрения IDE и понятность для человека имеют большую дистанцию чем, скажем, понятность для модели и для человека. Для человека критично важно видеть итоговые структуры, которые возникают на выходе программы и желательно иметь максимально простой способ понять почему именно возникают именно такие структуры. Думаю, это и предопределило декларативность практически всех языков преобразования данных. В той же JSONata в простейших случаях мы сразу описываем ту структуру которую ждем на выходе.
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания. При этом, конечно, по возможности надо способствовать корректному написанию. В этом смысле, как только в branchline вызреют сложные типы данных (json schema вполне может быть использована для их задания), то программа на нём будет проверять корректность ещё на этапе анализа. И автокомплит по типам будет поддержан в LSP. Но до полноценной поддержки типов надо дожить )
Не совсем понял. А что такое autocomplete friendly для языка? Если рассматривать отдельно от легкой воспринимаемости для моделей, то для меня это что-то типа настроек для монако. Но тогда во-первых, на базовом уровне автокомплит есть и работает в плейграунде, а во-вторых, не понятно как это может стереть грань. И я не уверен, что такую цель нужно ставить именно перед языком, а не перед его редактором, например.
Но, возможно, я как-то не так понял что вы имели в виду, буду признателен за уточнение.
О, не знал о таком проекте, выглядит очень круто, спасибо за наводку!
Спасибо :-)
Ниша узкая, это правда. Но например, если мы непременно хотим иметь возможность менять скрипт на лету и при этом иметь нечто более специализированное чем python, то у нас не так много опций — JSONiq, JSONata, JOLT, JSLT и ещё что-то редкое. У всего этого есть минусы, а если мы добавим полноценную отладку и экзотику типа вывода контрактов, то я даже не знаю подходящих альтернатив.
Но Branchline — это прежде всего эксперимент в рамках другого эксперимента. По-настоящем, как мне кажется, его можно раскрыть только если будет реализация платформы.
В любом случае спасибо за труд!
Как вариант — смириться с недостатком мозгов и найти менее требовательную профессию. В депутаты можно пойти, ограничительные законы писать. Заодно можно с легкостью отыграться на этих мерзких «ботанах».
Размазывать сопли о прокуренную жилетку хабра — не вариант. А то так и будет — «жизнь заставила быть программистом», а хочется «тискать девочек во дворах» и прочее нытье. Следуйте моде: nodejs, mongodb — читать много не надо и девочкам в клубах будет что рассказать.
P.S. Заранее прощу прощения за убитое время.
Презентеры — это уже немного про другое, в любом случае, возникает вопрос о том, как хранить эти самые презентеры, чтобы удержать контроль над кодом.
Раз уж заговорили про презентеры, то вот — blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/
Rails way, Rails wayем, а то что реально решает проблемы, пропускать не стоит.
Использовать такое разделение с самого начала проекта, конечно, спорное решение. Особенно, когда непонятно, появятся такие сущности или нет. Но, например, автор статьи несколько месяцев назад подал идею разнести отдачу html и js по разным контроллерам. А именно, js-ответы вынести в API. Совсем не типично для Rails Way, но результат на практике мне очень нравится.
А в целом — присоединяюсь к комментатору ниже, написавшему про Engines. Особенно с Rails 3.1+
Но, проповедники налегают. В общем, комментарии выше вскрывают проблемы в полной мере, почти нечего добавить.
Если кратко, будем бороться комплексно: продуманное управление репутацией пользователя, ручной модерацией, будем давать слово бизнесу и будем учить его работать с такими отзывами.
К сожалению, это не самая тяжелая задача, которую нам предстоит решить.