Из-за непринятия разработчиками и менеджментом возможности существования гетерогенной системы, построенной на разных языках программирования, теряется возможность выбора подходящих инструментов для решения актуальных задач.
Ну откуда такие страшные мысли? Чего такого нельзя сделать на одном языке, но автор считает, можно сделать на другом? Откуда такое полнейшее непонимание сути понятия алгоритм?
Выбор языка — это экономическая задача. И хотя часто её решают на основе моды, это ни разу не отодвигает экономику с законного первого места. А аргументы из серии «а на модном языке я такое могу!!!» только подкрепляют уверенность в безумстве следующих за модой.
Статья из надёрганных чужих мыслей. Автор — простейший компилятор, без малейшей обработки смыслов.
Но война «за или против» микросервисов подталкивает многих участвовать в обсуждении этого пустопорожнего текста. То есть читаемость получаем из-за спорности темы, а не из-за хоть сколько-нибудь полезной информации.
Ну и по теме сервисов и прочего — тут надо уметь. А если не уметь — да, получается боль. Но крупный бизнес не видит в этом проблемы, ведь его расходы на ИТ практически не меняются, ну а то, что какие-то сроки сдвигаются в заоблачную даль, так это для крупного бизнеса самое обычное явление. Поэтому так и будут резвиться, не умеючи и не понимая смысла.
Кодогенерация страдает кучей недостатков. Применяемая узко (как в статье) даёт лишнюю нагрузку на разработчиков — обучение, сопровождение стороннего проекта-генератора, далеко не очевидное сокращение усилий на создание целевых классов, а доля в реальных затратах — никакая, но ради неё столько возни. Применять широко вообще нельзя, потому что сложность сразу убьёт затею.
Ну и немного ещё по статье — те же сеттеры генерируются IDE, какие-то необычности внутри так и так нужно писать вручную, а пропускать через генерацию — увеличивать шанс появления ошибок. Даже просто переключение меду проектами ради одного нового класса займёт больше времени, чем по быстрому накидать этот самый класс с дополнениями, которые мог бы делать генератор.
Вижу только узкую нишу для подобных решений, что-то вроде генерации сразу нескольких аналогичных классов для разных частей проекта, тогда действительно можно один раз накидать схему, а потом из неё получится много всего. Но это редкая операция, поэтому затраты на изучение и поддержание проекта Xtend выглядят не окупающимися, разве что для удовольствия разработчиков поковыряться в чём-то новом.
В конце концов, если уж используется Spring Boot, который по сути есть банальный шаблонизатор, то можно было бы эти же самые шаблоны генерировать (и не только «эти же самые»), хотя и здесь опять польза не гарантирована.
А свойство делимости не имеет никакого отношения к задаче?
Автор выделили вот такое свойство языка:
это система опирающаяся на логику предикатов и встроенные процедуры автоматического доказательства теорем
И доказал теорему «отображаемости» приведённого набора аксиом и правил на поставленную задачу.
Правда смысл доказательства большинство вряд ли поняли, это да…
Наверно автору стоило какие-то более жизненные и простые примеры давать, что бы заинтересовать тех, кто в доказательство теорем не умеет. Правда тогда пролог будет обычным языком программирования и к нему сразу начнутся претензии про «нет того, нет этого, а это вообще мне не нравится». Поэтому может и не надо упрощать.
Подскажите пожалуйста, вы вашей статье упоминается несколько довольно дорогих приборов, вроде спектрометра, где вы их взяли? Мне интересно, можно ли что-то подобное где-то временно арендовать? Хотя возможно вы их с работы получили, тогда наверно ответ не нужен (мне-то не с работы надо).
Вот она, «интеллектуальная илитка». А разве можно вешать на меня ошейник, если нет такого закона, где говорится, что ошейник вешать можно? Вот такие вопросы волнуют данное сообщество. Вот был бы закон — пожалуйста, вешайте, но ведь нет же закона. Непорядок! А ещё расскажите, как меня датчики сканировать будут, ведь интересно же, и познавательно!
Хотя нужно признать, «илитка» достаточно умна для вычисления оптимального варианта поведения в ситуации, когда невыполнение приказа угрожает небольшим штрафом. Ну конечно — нужно выполнить приказ, это разумно и выгодно.
Но необразованные американские негры на порядок стратегически грамотнее. Они знают последствия выполнения приказов. А местные не могут понять, что московские власти банально проплатили очередную пиар акцию по разводу хомячков — задай вопрос, твой голос важен для нас! Хомяк задаёт и ждёт ответа. Долго ждёт. Попутно приказы выполняет. Настоящая интеллектуальная илитка!
Корректно реализованная схема с независимыми серверами обеспечивает тайну голосования всегда, если владельцами обоих серверов не были сознательно предприняты меры к её устранению.
Ваш сервер регистрирует всех, кого попало. Он доверяет некой гос.системе. Я (работая в госах соответствующим начальником) пишу бота, который голосует за всё население. Корректно реализованный сервис избирает меня президентом. Круто.
И так по всем пунктам, где может поучаствовать заинтересованное лицо. Начиная сразу с «корректности реализации», которая нужна совсем не тем, кто будет реализовывать эту корректность.
Все технические ухищрения ничто, если у всех нет полной информации. Но кто-то вот до сих пор верит, что если всё скрывать, то можно… А что можно? Получить денег за разработку? Это да, точно можно. А что потом? Ну написать блог, ладно. А потом те, кто заказывал музыку, приказывают установить приложение для выписывания штрафов (и это только начало).
Не, я в клетку не хочу. Ну а если вы там сторожем, это не значит, что вам будет много лучше. Используют и выкинут. Либо есть вариант «выслужиться», но для большинства это хуже клетки. Так что ваш выкрик не к месту.
А вопросами безопасности чужого оборудования пусть занимается хозяин оборудования. И это не вы. Но почему-то за дядю впрягаетесь.
Таким образом, ПАК «Эльбрус» можно использовать там, где необходима и критична защита от «врага»
В ситуации, когда эрэфия по сути враждебна абсолютно всему (включая собственное население), у «доверенной» железяки нет места, кроме работы на эту саму эрэфию, то есть на власть, которая враг всему, ну и которой хочется защититься от всех. А разработчики, как обычно, вне политики, а потому играются в свои мелкие игрушки типа «дадут больше денег» или «запилю прикольную штучку».
Пример игрушек — автор всерьёз заявляет, что падение производительности на 30% неприемлемо, даже если при этом будут решены все остальные «неважные» вопросы, такие как наличие пользователей и вообще продажи. Ну в каком каменном веке он застрял? Размен «идеальности» (в его воображении) на отсутствие перспектив вообще — это он считает правильным. Хотя как может быть иначе, если «мы вне политики», то есть не интересуемся вообще ничем, кроме занимательных железных побрякушек.
И далее занимательный призыв:
компания будет рада рассмотреть кандидатуры программистов и разработчиков с разными компетенциями
Предлагают поработать на повышение защищённости железяки от народа, вероятно. Ну или на выжимание 1% производительности в ущерб всему на свете. И ничего другого там быть не может — место для очень замкнутых в себе технарей, не думающих о своём собственном будущем. Вот такие они, узкие во всех смыслах специалисты.
Можно было бы поговорить о реальных технических перспективах, но в отрыве от потребностей страны (а не кучки ворюг) не вижу смысла. Выше предлагали интересный вариант «создать VPS хостинг», но как он уляжется на нишу «закрыть от врагов»? Да никак. По деньгам — неэффективно. По развитию — просто незачем. Единственный вариант возможен, если кто-то из разработчиков, имеющий доступ к начальству, захочет поиграться с виртуалками и навяжет такой проект начальству. Но в итоге ведь опять всё будет работать лишь на личное удовольствие навязавшего, а не на реально полезный VPS.
Так что Эльбрус умер. И не надо более накачивать его адреналином. Пусть существует в роли игрушки для очень маленькой группы разработчиков. Если вдруг что-то изменится в обществе — они смогут как-то поделиться знаниями с пользой для всех. А если не изменится — смерть будет зафиксирована очень скоро, хотя труп по прежнему будут накачивать наркотой, но даже с точки зрения иллюзии престижа скоро всем будет просто смешно наблюдать такие потуги.
Да, и даже тесты производительности автор привёл с чужих слов каких-то энтузиастов, непонятно что мерявших и непонятно каким образом (и кривущие — две одинаковые таблицы под разными заголовками). То есть сам не знает, о чём нам рассказывает, ссылается на «специалистов», ага.
Да, можно это назвать командой. Но мы же о её роли говорим. Поэтому я бы назвал роль этой команды так — механизм. Который покупают и продают. Ничуть не лучше, чем аренда помещения под этот механизм, или покупка сервера, или столов, или канцелярии. Поэтому роль команды = роли стульев в офисе.
Можно верить во что-то другое, но объективная реальность именно такая — стулья, и ничего более.
Мне бы не хотелось этого, но я просто не могу отрицать объективную реальность, потому что отрицать её глупо и бессмысленно.
Дело в том, что альтернатива, во первых (а это ошибки), неявно, а во вторых, для очень ограниченного количества действий, расшивает указанную вами проблему. Из этого следует, что каждый раз программист будет думать, долго и без гарантий правильности. В итоге будут все те же ошибки, что и с обычными потоками, плюс дополнительно проблемы из-за специфики псевдо-потоков. В сумме = хуже.
Ну и помимо «общечеловеческих ценностей» есть ещё и неблокирующее IO API. И что мешает просто взять и его использовать? Не наступая на грабли с новыми псевдо-потоками. Ведь вы именно на асинхронное IO упираете, доказывая ценность псевдо-потоков. И вот оно, асинхронное IO, и так есть, и давно используется, ну и без приставки псевдо.
Потоки загружают ядра. Если убрать переключение потоков — ядра будут недогружены. Кооперация гарантирует, что переключение во многих случаях работать перестанет из-за множества проблем на стороне писателей в кооперативном стиле.
Но и вам вопрос — а в чём преимущества кооперации потоков?
В упомянутом API нет необходимости в коллбэках. Там достаточно уметь опрашивать каналы в цикле.
В целом стремление впихнуть в абстракцию потока миллионы экземпляров точно так же чревато адской неэффективностью. Даже если памяти на псевдо-поток будет тратиться поменьше, дальнейшая обработка никак из штанов выпрыгнуть не сможет, ну и вся затея будет иметь смысл в очень и очень ограниченных нишах. Могу себе представить разве что какой-то самый примитивный роутер, распихивающий потенциально очень большие флуктуации на входе по вот таким недо-потокам, которые в итоге будут служить лишь цели усложнения архитектурного шаблона «очередь» (и памяти потреблять, разумеется, больше, чем оптимизированная очередь в памяти).
Хотя возможно вы можете представить какое-то более разумное применение для сабжа?
Спасибо, почитал. Не смотря на откровенно быдляцкий язык автора той статьи, понять его вполне можно. Суть в расшивании проблемы stack overflow при кооперативном переключении (включая неявное) на другие псевдо-потоки. Хотя неявное переключение, как пишет автор, реализовали очень ограничено (но от его стиля изложения веет полнейшим трешем, поэтому непонятно, кто здесь виноват — пошлость автора или всё же ограничения со стороны разработчиков JVM).
Но тем не менее всё так же непонятно, с чего автор обсуждаемой здесь статьи (уже не по вашей ссылке) считает, что в подобной реализации возможно какое-то другое вытеснение псевдо-потоков кроме кооперативного. Судя по данным по вашей ссылке никакого другого подхода там быть не может (кроме кооперации и неявного переключения в некоторых избранных местах, в виде нативных вызовов, которые и реализуют переключение). Может автору тоже стоит познакомиться с материалом по ссылке.
функция команды в большой степени заключается в том, чтобы говорить, что делать
Это называется «экспертиза». Она покупается у людей с названиями типа «консультант», «эксперт» и тому подобное. Если таких людей ищут годами, значит либо не там ищут, либо не так ищут. Потому что эксперты в большинстве областей присутствуют массово, иначе эти области бы просто загнулись.
Ещё есть линейный менеджмент, который увязывает в единое целое экспертов и остальных наёмных работников. Это тоже экспертиза, но в области управления. И её точно так же много на рынке. Хотя если ориентироваться исключительно на звёзд, тогда действительно может показаться, что людей мало.
Не знаю, что конкретно сочинили в Java15, но «переключиться на другой таск» означает ровно всё то же самое, что и переключиться на другой поток, а значит нет главного — никаких отличий от старого.
Хотя опять же есть асинхронное IO. Если мне нужно «переключаться на другой таск», то я сам укажу программе где и как я хочу переключиться, просто использовав что-то вроде пакета nio. Соответственно — зачем мне нововведение, где что-то действует неконтролируемым образом?
По сути вопрос о внутреннем устройстве нововведения. Если оно известно — можно что-то обсуждать. Если нет — просто нечем обосновывать ценность нововведения. Мне неизвестно, думал автор статьи пояснит, но он отмалчивается. Значит придётся ждать более вменяемых описаний.
Ну откуда такие страшные мысли? Чего такого нельзя сделать на одном языке, но автор считает, можно сделать на другом? Откуда такое полнейшее непонимание сути понятия алгоритм?
Выбор языка — это экономическая задача. И хотя часто её решают на основе моды, это ни разу не отодвигает экономику с законного первого места. А аргументы из серии «а на модном языке я такое могу!!!» только подкрепляют уверенность в безумстве следующих за модой.
Но война «за или против» микросервисов подталкивает многих участвовать в обсуждении этого пустопорожнего текста. То есть читаемость получаем из-за спорности темы, а не из-за хоть сколько-нибудь полезной информации.
Ну и по теме сервисов и прочего — тут надо уметь. А если не уметь — да, получается боль. Но крупный бизнес не видит в этом проблемы, ведь его расходы на ИТ практически не меняются, ну а то, что какие-то сроки сдвигаются в заоблачную даль, так это для крупного бизнеса самое обычное явление. Поэтому так и будут резвиться, не умеючи и не понимая смысла.
Ну и немного ещё по статье — те же сеттеры генерируются IDE, какие-то необычности внутри так и так нужно писать вручную, а пропускать через генерацию — увеличивать шанс появления ошибок. Даже просто переключение меду проектами ради одного нового класса займёт больше времени, чем по быстрому накидать этот самый класс с дополнениями, которые мог бы делать генератор.
Вижу только узкую нишу для подобных решений, что-то вроде генерации сразу нескольких аналогичных классов для разных частей проекта, тогда действительно можно один раз накидать схему, а потом из неё получится много всего. Но это редкая операция, поэтому затраты на изучение и поддержание проекта Xtend выглядят не окупающимися, разве что для удовольствия разработчиков поковыряться в чём-то новом.
В конце концов, если уж используется Spring Boot, который по сути есть банальный шаблонизатор, то можно было бы эти же самые шаблоны генерировать (и не только «эти же самые»), хотя и здесь опять польза не гарантирована.
Автор выделили вот такое свойство языка:
И доказал теорему «отображаемости» приведённого набора аксиом и правил на поставленную задачу.
Правда смысл доказательства большинство вряд ли поняли, это да…
Наверно автору стоило какие-то более жизненные и простые примеры давать, что бы заинтересовать тех, кто в доказательство теорем не умеет. Правда тогда пролог будет обычным языком программирования и к нему сразу начнутся претензии про «нет того, нет этого, а это вообще мне не нравится». Поэтому может и не надо упрощать.
Вот она, «интеллектуальная илитка». А разве можно вешать на меня ошейник, если нет такого закона, где говорится, что ошейник вешать можно? Вот такие вопросы волнуют данное сообщество. Вот был бы закон — пожалуйста, вешайте, но ведь нет же закона. Непорядок! А ещё расскажите, как меня датчики сканировать будут, ведь интересно же, и познавательно!
Хотя нужно признать, «илитка» достаточно умна для вычисления оптимального варианта поведения в ситуации, когда невыполнение приказа угрожает небольшим штрафом. Ну конечно — нужно выполнить приказ, это разумно и выгодно.
Но необразованные американские негры на порядок стратегически грамотнее. Они знают последствия выполнения приказов. А местные не могут понять, что московские власти банально проплатили очередную пиар акцию по разводу хомячков — задай вопрос, твой голос важен для нас! Хомяк задаёт и ждёт ответа. Долго ждёт. Попутно приказы выполняет. Настоящая интеллектуальная илитка!
Ваш сервер регистрирует всех, кого попало. Он доверяет некой гос.системе. Я (работая в госах соответствующим начальником) пишу бота, который голосует за всё население. Корректно реализованный сервис избирает меня президентом. Круто.
И так по всем пунктам, где может поучаствовать заинтересованное лицо. Начиная сразу с «корректности реализации», которая нужна совсем не тем, кто будет реализовывать эту корректность.
Все технические ухищрения ничто, если у всех нет полной информации. Но кто-то вот до сих пор верит, что если всё скрывать, то можно… А что можно? Получить денег за разработку? Это да, точно можно. А что потом? Ну написать блог, ладно. А потом те, кто заказывал музыку, приказывают установить приложение для выписывания штрафов (и это только начало).
Не, я в клетку не хочу. Ну а если вы там сторожем, это не значит, что вам будет много лучше. Используют и выкинут. Либо есть вариант «выслужиться», но для большинства это хуже клетки. Так что ваш выкрик не к месту.
А вопросами безопасности чужого оборудования пусть занимается хозяин оборудования. И это не вы. Но почему-то за дядю впрягаетесь.
Вот такой вывод автора этому свидетельство:
В ситуации, когда эрэфия по сути враждебна абсолютно всему (включая собственное население), у «доверенной» железяки нет места, кроме работы на эту саму эрэфию, то есть на власть, которая враг всему, ну и которой хочется защититься от всех. А разработчики, как обычно, вне политики, а потому играются в свои мелкие игрушки типа «дадут больше денег» или «запилю прикольную штучку».
Пример игрушек — автор всерьёз заявляет, что падение производительности на 30% неприемлемо, даже если при этом будут решены все остальные «неважные» вопросы, такие как наличие пользователей и вообще продажи. Ну в каком каменном веке он застрял? Размен «идеальности» (в его воображении) на отсутствие перспектив вообще — это он считает правильным. Хотя как может быть иначе, если «мы вне политики», то есть не интересуемся вообще ничем, кроме занимательных железных побрякушек.
И далее занимательный призыв:
Предлагают поработать на повышение защищённости железяки от народа, вероятно. Ну или на выжимание 1% производительности в ущерб всему на свете. И ничего другого там быть не может — место для очень замкнутых в себе технарей, не думающих о своём собственном будущем. Вот такие они, узкие во всех смыслах специалисты.
Можно было бы поговорить о реальных технических перспективах, но в отрыве от потребностей страны (а не кучки ворюг) не вижу смысла. Выше предлагали интересный вариант «создать VPS хостинг», но как он уляжется на нишу «закрыть от врагов»? Да никак. По деньгам — неэффективно. По развитию — просто незачем. Единственный вариант возможен, если кто-то из разработчиков, имеющий доступ к начальству, захочет поиграться с виртуалками и навяжет такой проект начальству. Но в итоге ведь опять всё будет работать лишь на личное удовольствие навязавшего, а не на реально полезный VPS.
Так что Эльбрус умер. И не надо более накачивать его адреналином. Пусть существует в роли игрушки для очень маленькой группы разработчиков. Если вдруг что-то изменится в обществе — они смогут как-то поделиться знаниями с пользой для всех. А если не изменится — смерть будет зафиксирована очень скоро, хотя труп по прежнему будут накачивать наркотой, но даже с точки зрения иллюзии престижа скоро всем будет просто смешно наблюдать такие потуги.
Да, и даже тесты производительности автор привёл с чужих слов каких-то энтузиастов, непонятно что мерявших и непонятно каким образом (и кривущие — две одинаковые таблицы под разными заголовками). То есть сам не знает, о чём нам рассказывает, ссылается на «специалистов», ага.
Можно верить во что-то другое, но объективная реальность именно такая — стулья, и ничего более.
Мне бы не хотелось этого, но я просто не могу отрицать объективную реальность, потому что отрицать её глупо и бессмысленно.
Дело в том, что альтернатива, во первых (а это ошибки), неявно, а во вторых, для очень ограниченного количества действий, расшивает указанную вами проблему. Из этого следует, что каждый раз программист будет думать, долго и без гарантий правильности. В итоге будут все те же ошибки, что и с обычными потоками, плюс дополнительно проблемы из-за специфики псевдо-потоков. В сумме = хуже.
Ну и помимо «общечеловеческих ценностей» есть ещё и неблокирующее IO API. И что мешает просто взять и его использовать? Не наступая на грабли с новыми псевдо-потоками. Ведь вы именно на асинхронное IO упираете, доказывая ценность псевдо-потоков. И вот оно, асинхронное IO, и так есть, и давно используется, ну и без приставки псевдо.
Хотя да, общие слова — это наше всё. Так что я обязательно поставлю галку «зачтено» в виртуальном журнале против ваших ников.
Ну и так, напоследок:
И два:
Что по вашему проще?
Потоки загружают ядра. Если убрать переключение потоков — ядра будут недогружены. Кооперация гарантирует, что переключение во многих случаях работать перестанет из-за множества проблем на стороне писателей в кооперативном стиле.
Но и вам вопрос — а в чём преимущества кооперации потоков?
В целом стремление впихнуть в абстракцию потока миллионы экземпляров точно так же чревато адской неэффективностью. Даже если памяти на псевдо-поток будет тратиться поменьше, дальнейшая обработка никак из штанов выпрыгнуть не сможет, ну и вся затея будет иметь смысл в очень и очень ограниченных нишах. Могу себе представить разве что какой-то самый примитивный роутер, распихивающий потенциально очень большие флуктуации на входе по вот таким недо-потокам, которые в итоге будут служить лишь цели усложнения архитектурного шаблона «очередь» (и памяти потреблять, разумеется, больше, чем оптимизированная очередь в памяти).
Хотя возможно вы можете представить какое-то более разумное применение для сабжа?
Но тем не менее всё так же непонятно, с чего автор обсуждаемой здесь статьи (уже не по вашей ссылке) считает, что в подобной реализации возможно какое-то другое вытеснение псевдо-потоков кроме кооперативного. Судя по данным по вашей ссылке никакого другого подхода там быть не может (кроме кооперации и неявного переключения в некоторых избранных местах, в виде нативных вызовов, которые и реализуют переключение). Может автору тоже стоит познакомиться с материалом по ссылке.
Это называется «экспертиза». Она покупается у людей с названиями типа «консультант», «эксперт» и тому подобное. Если таких людей ищут годами, значит либо не там ищут, либо не так ищут. Потому что эксперты в большинстве областей присутствуют массово, иначе эти области бы просто загнулись.
Ещё есть линейный менеджмент, который увязывает в единое целое экспертов и остальных наёмных работников. Это тоже экспертиза, но в области управления. И её точно так же много на рынке. Хотя если ориентироваться исключительно на звёзд, тогда действительно может показаться, что людей мало.
Не знаю, что конкретно сочинили в Java15, но «переключиться на другой таск» означает ровно всё то же самое, что и переключиться на другой поток, а значит нет главного — никаких отличий от старого.
Хотя опять же есть асинхронное IO. Если мне нужно «переключаться на другой таск», то я сам укажу программе где и как я хочу переключиться, просто использовав что-то вроде пакета nio. Соответственно — зачем мне нововведение, где что-то действует неконтролируемым образом?
По сути вопрос о внутреннем устройстве нововведения. Если оно известно — можно что-то обсуждать. Если нет — просто нечем обосновывать ценность нововведения. Мне неизвестно, думал автор статьи пояснит, но он отмалчивается. Значит придётся ждать более вменяемых описаний.
Ради чего расширяется набор базовых библиотек???
А если допустить что-то другое? Что будет с вашей рекомендацией?
Все рассуждалки на тему «что важнее» указывают лишь на то, что лично рассуждающий для себя считает важным.