Одним из главных недостатков, который отмечают пользователи, является изменение отображения диффов (различий в коде перед коммитом)
Имеется в виду перечень файлов или дифф в конкретном файле? Для первого случая я просто помещаю окно немодального коммита в тот же бок, где у меня окно projects. Если хватает места для просмотров файла проекта, то хватит и для просмотра перечня изменённых файлов. Во втором случае двойной клик по файлу в немодальном окне коммита открывает дифф прямо в редакторе кода.
При этом с немодальный интерфейсом удобно как раз фокусироваться на коммите. Даже если я в итоге не хочу ничего быстро подправить перед коммитом, мне же его надо ещё как следует проверить и/или написать commit message. А иногда в процессе просмотра диффа у меня возникают различные вопросы относительно кода - и тут его помогает исследовать то, что я всё так же нахожусь в таком же интерфейсе редактора, как и при кодировании, а не в каком-то обрубке, который не позволяет делать очень многие вещи.
Я упоминаю Python, потому что отвечаю на ответ в комментарию, где упоминался Python. А Java я упоминаю потому, что у меня в этой области есть огромная экспертиза. А то, что и для C++ надо так же грузить стандартную библиотеку вместо использования готовой ещё больше подтверждает тезис автора изначального комментария, который я тут пытаюсь защитить, а именно:
тяжелая среда исполнения. Для JS она уже встроена в любой браузер и время ее загрузки через сеть - ноль, и время активации до рабочего состояния тоже чаще всего ноль. А для того же питона - надо притащить 5-10 мб, а затем сколько то подождать компиляции и запуска
Это не сериализация/десериализация. Это просто банальная передача параметров между Wasm-модулем и JS API. Иногда эту передачу можно сделать почти бесшовной, иногда подходы к организации данных в JS, Wasm и гостевом языке настолько принципиально отличаются, что приходится либо что-то "переупаковывать" с соответствующими накладными расходами, либо прямо в гостевом языке городить какой-то страшнейший огород, сводящий на нет все преимущества от возможности писать на этом самом гостевом языке. Например, во всяких C++ библиотеках часто строки идут в памяти либо в виде wchar_t*, либо даже char* в UTF-8. В JS строка хранится не в хипе, а в виде специального встроенного объекта, хранящего строку в UTF-16. Чтобы, например, нарисовать текст в canvas, приходится делать копирование (возможно даже с преобрвазованием UTF-8->UTF-16) там, где в случае чистого JS его можно было бы избежать. Другой пример - это передача JS-объектов между JS и Wasm-модулем - там надо организовывать некие таблицы соответствия, отображающие JS-объекты на хип Wasm.
И для Python-приложения, и для "обычного" WASM-приложения нужно загрузить бинарники. Для JavaScript-"приложения" нужно загрузить бандлы с JavaScript-кодом
Проблема в том, что в JS есть "стандартная библиотека" - всякие Array, Date, Math, Map и т.д., и вся эта стандартная библиотека зашита прямо в браузер. Поэтому для JS надо грузить только сам код, реализующий логику. В случае c Python или Java - у них своя стандартная библиотека, реализация которой (даже в каком-то очень усечённом варианте) может весить несколько мегабайт, даже десятки мегабайт, и которую надо грузить по сети, помимо кода собственно приложения. Сам по себе Wasm не реализует ничего, похожего, например, на java.util.ArrayList.
Не вижу, почему компиляторы, оптимизирующие выполнение для пути без исключений, не могут точно так же оптимизировать его для кода возврата S_OK.
Потому что компилятор вообще никак не оптимизирует "выполнене пути без исключений". Компилятор (грубо говоря, на самом деле это не совсем так, но это нюансы работы оптимизаторов) генерирует код для try и всего, что внутри, как будто этого try нет. Он просто для всех try пишет в сегмент данных дополнительную метаинформацию: интервалы адресов в коде и сопоставленный им адрес, куда делается переход для обработки исключения. Потом при выбросе исключений подключается рантайм, который ходит по стеку, находит адреса возвратов в нём (для этого так же может потребоваться дополнительная разметка call site-ов, но это опять же, данные) и дальше смотрит, есть ли в таблице try информация об этих адресах. Если он таковую находит, то делает (грубо говоря) простой jump в адрес обработчика.
С исключениями проблемы начинаются, когда на них начинают писать логику (не аварийная ситуация, а ситуации типа вместо проверки существования файла – обращаемся к нему и бросаем exception, если его нет).
it depends. Если путь к файлу задан юзером, то очевидным решением будет явная проверка наличия этого файла. Если же это какой-то ресурс приложения, или какой-то файл (например, кэш), который ранее создало само приложение где-нибудь в $HOME/.cache и по идее никто не должен был его удалять (если только это зачем-то не сделал юзер, ну или не поломалась ФС), то вполне валидно бросить исключение. Ну и обработать ошибку уже несколькими уровнями выше.
Конечно, решаемо. Мы как раз и собирали весь этот ад Maven, пока пару лет назад не смигрировали на Gradle. И это был глоток свежего воздуха. Там где раньше были обильно расставлены костыли и нагорожена куча бойлерплейта, сейчас короткие и ясные декларативные описания. Там, где приходилось сражаться с ограничениями инструмента, сейчас просто берёшь и используешь его.
Кстати, для генерации исходников у мавена таки из коробки имеется отдельная фаза.
Да-да, как и плагин. Но тут, конечно, не совсем в тему мой коммент. Просто если проект держат на Maven, то собственно Maven его достаточно редко собирают, ибо каждый раз ждать 5 минут просто чтобы запустить и проверить изменения - это невиданная расточительность. Так вот, мы всегда полагались на то, что IDEA как-то спарсит pom.xml и как-то свой проект сконфигурирует, а потом собирать идеей, т.к. она умеет в инкремениальную сборку, и там, где Maven работал несколько минут, IDEA умудрялась за пару секунд пересобирать. Ну и, конечно, туда не входил protobuf. Поэтому когда кто-то накоммитил изменений в proto-файлы, приходилось брать вручную запускать какие-то goal-ы каких-то проектов. Ну и т.к. это было не одно место, была целая россыпь run configuration на все случаи жизни - что запустить, если при очередном pull проект сломался. Это уж не говоря о том, что при переключении между feature branch и master приходилось всё то же самое проделывать. C gradle в принципе иначе поступают - там собирают всегда им, а не делегируют IDE, и он сам хорошо умеет в инкрементальную компиляцию и способен проект собрать за 2 секунды. Так что как только мы переехали на gradle, необходимость в каких-либо манипуляцих отпала - можно просто запустить проект оттуда, где вы сейчас находитесь, и он гарантированно запустится.
Кстати, ещё забыл. Проект частично на Kotlin, частично на Java, причём есть модули, где есть код и на Kotlin и на Java. Я помню, нужно было отдельно настраивать оба компилятора так, чтобы они правильно совместно работали, т.е. писать кучу бойлерплейта. С Gradle всё не так - нужно всего лишь подключить плагин Java и плагин Kotlin и оно всё само.
Ну а что поделать, если на практике реально возникла ситуация, когда стандартных фаз не хватает? Вот возник кейс, о котором создатели Maven просто не подумали. Приходится шаманить с порядком применения mojo внутри одной фазы, чтобы всё сошлось. И "почесать своё эго" вообще не при чём. По моему опыту, если делаешь типовой Java проект со Spring/Hibernate/что-то такое, собираешь это в war, то Maven отлично работает. А если проект: собрать из (почти) одних сорцов десктопное приложение в виде fat jar, Android-приложение, iOS приложение с помощью Graal Native Image и веб-приложение с помощью какого-нибудь транслятора Java->JS/WebAssembly, да ещё сервер рядом с ними положить в докер-образ вместе с нативными либами, то использование Maven превращается в АД. Кстати, да, часть исходников при этом генерится с помощью какого-нибудь ANTLR, а другая часть - Protobuf.
И, кстати, у организации тасок в граф есть ещё пара преимуществ. Во-первых, так проще сделать инкрементальную сборку. Тогда просто таски не зависят друг от друга напрямую, а output одной таски направляется в input другой. Во-вторых, граф тасок проще распараллелить.
Нет. Разница между Maven и Gradle не в императивности. Кто юзал gradle правильно, и так не писал императивных штук в скриптах, а переносил их в плагины. Разница в том, что плагин в Maven - это по сути одна таска, а в Gradle плагин способен конфигурировать проект целиком - например, подсовывать зависимости, таски, модифицировать имеющиеся и т.д. Это очень полезно, когда в проекте есть модули, имеющие некоторый общий функционал. Например, у нас в проекте мы предоставляем пользователям писать скрипты для нашего приложения на TypeScript, при этом есть некоторые модули, которые экспортируют части этого скриптового API. Для них нужны определённые действия, плюс определённые зависимости. Причём, действия - это не просто одна таска. Например, хочется запускать валидатор сгенерированных d.ts файлов, для чего нужен node.js плагин. Почему не написать свой mojo, который бы запускал node.js? Ну потому что такой плагин уже есть и не хочется его велосипедить. До переезда на Gradle мы просто тащили из модуля в модуль определённый бойлерплейт (который ещё изредка менялся и приходилось его апдейтить в каждом модуле, где он есть). В Gradle это выглядит как-то так:
plugins { id "tsApiProvider" }
Кроме того, в Gradle в принципе очень многие вещи сделаны грамотнее:
вместо прибитого гвоздям набора фаз есть граф тасок
концепция конфигураций намного гибче скоупов в maven; идущие из коробки с java плагином конфигурации лучше отражают реалии многомодульных проектов (api/implementation)
продумана инкрементальность на уровне тасок, можно чётко определять для каждой таски, откуда она получает данные на вход, куда пишет вывод.
gradle любят ругать за отсутствие документации. Так вот, для Maven она в тысячи раз хуже. Есть только базовая инструкция, как написать плагин (mojo), но как сделать продвинутые вещи (например, динамически порезолвить зависимость) можно узнать, только залезая в код каких-нибудь плагинов, которые делают более-менее то же самое.
Нет. Разбивка текста на лексему или разбор на AST - это даже не вершина айсберга компиляции, это подтаявший лёд на этой самой вершине.
IDE не будет долго "индексировать" проект, подсветка синтаксиса и большая часть информации для автокомплита будут доступны сразу.
Нет. См. пункт 1.
Не будет споров а-ля "табы vs пробелы", в файл попадет лишь дерево.
А так же исчезнет куча полезного форматирования, применимого в конкретном случае, которое позволяет сделать код более понимаемым.
Если совсем упороться, то, наверно, можно даже настроить IDE так, чтобы писать на другом языке. Например, код был на Java, а ты себе показываешь его на котлине. Просто где-то в IDE пометить, чтобы в файл сохранялось джавовое AST. Здесь я не уверен, просто как мысль, что можно ещё сделать, если отказаться от оков текста.
Языки отличаются друг от друга гораздо больше, чем просто "набором символов, входящих в лексему". И даже больше, чем типами узлов в AST. Задача перевести программу с одного языка на другой практически невыполнима в общем случае.
IDE может хранить в этих бинарях свои данные для ускорения каких-то процессов отображения и автокомплита. Правда, файлы могут сильно разрастись.
Как раз 5, 6 идея только с виду та же. В старых цивах можно было жульничать. Помню, как в третьей можно было настроить танчиков, по железным дорогам в один ход подтянуть к городам противника и следующим же ходом вынести. В 4 добавили такую штуку что при объявлении войны танчики за границу противника отправлялись и надо было снова их к городам подтягивать. В 5 сделали гексагональную карту, так что направления стали более равноправными (потому что в случае квадратных клеток перемещение по диагонали примерно в 1.41 раз быстрее) и сделали невозможность ставить два юнита на клетку. И это чуть ли не революция, потому что не даёт жульничать, местность начинает интереснее влиять на стратегию. Ещё в 5-й наконец подтянули различные формы правления, так что иногда за маленкую демократическую страну оказывалось играть выгоднее, чем за огромную авторитарную. Жаль, в 6-й этот баланс немного потеряли - стало снова выгодно тупо отстраивать побольше городов, без того, чтобы тщательно продумывать их стратегию развития (несмотря на введённые районы, которые должны только были стратегии развития городов только способствовать). Короче, после 3-й цивилизации каждая игра могла предложить что-то новое и заставляла полностью пересмотреть подходы к стратегии игры.
Вы мне сейчас приписываете какие-то утверждения, которых я не делал. Я не говорю, что верю в "подобные исследования". Я только заметил, что не всегда можно верить своим глазам и здравому смыслу. Что не исключает вероятности кривости тех или иных исследования. Как раз в постулатах квантовой механики (не понимаю, при чём тут кварки, я про них не говорил) я не сомневаюсь, ибо я вначале 10 лет учился в школе, а потом ещё 5 - на физмате, и за это время успел усвоить научную картину мира, к которой человечество шло долгие века, методом проб и ошибок, положив на это кучу ресурсов. Это при том, что с точки зрения органов чувств и "житейской" логики вся квантовая механика - это дичайшая муть.
Автор же комментария, на который я ответил, ведёт себя как такой невежда, который на физмате не учился, услышал о волновой функции и кинулся критиковать, потому что это не соответствует показаниям его органов чувств.
Что касается лично моего опыта (на основании которого, конечно, нельзя делать общих выводов, претендующих на научность) я вижу, что дама написала статью и словила кучу сексистских комментариев. Я при этом ничего не утверждаю о качестве её статьи, о достоверности содержимого - недостаточно компетентен в вопросе, чтобы судить. Я говорю именно о реакции комментаторов.
не уйдет на три года в отпуск по уходу за ребенком
Во-первых, уйти в отпуск по уходу за ребёнком может и папа. Во-вторых, как раз в IT я очень часто наблюдаю, что женщины с маленьким ребёнком работают - деньги лишними не бывают (особенно для семьи с ребёнком), а сидеть дома скучно, так что многие уже через 3-6 месяцев просятся хотя бы на полставки на удалёнку, и, надо сказать, хорошо справляются с работой.
Зависит от. Некоторые мужчины так же достаточно остро реагируют на ревью. Ну и потом, не факт, что такая реакция не имеет иных причину - например, девушка, окружённая суровыми мужиками (некоторые из которых, возможно, действительно делают сексистские выпадки), испытывает определённые проблемы с самооценкой и потому нервничает.
Считаю, что к женщинам давно уже относятся абсолютно одинаково и согласно с их реальными знаниями и умениями.
Не соглашусь. Мы с вами находимся в некотором информационном пузыре, где это, возможно, действительно так, но вовсем не факт, что так в обществе везде. Хотя бывает, что мы настолько привыкли к некоторой предвзятости по отношению к женщинам, что даже не замечаем некоторой гендерной предвзятости, считая себя образцом толератности.
С другой стороны, я совсем не думаю, что все эти инициативы со стороны компаний и посты в интернете действительно как-то помогут. Скорее, наоборот, вызовут только негативную реакцию. Вот как быть - не могу подсказать, ибо сам не знаю. Возможно, рыночек порешает - сейчас много где в мире назревает нехватка рабочей силы, и мигрантами затыкать вечно не получится (потому что страны, откуда мигрируют, либо в процессе, либо совсем скоро начнут демографический переход).
Я с одной стороны не согласен с тезисом "мужской и женский мозг ничем не отличаются". С другой, да, они отличаются. Но, ИМХО, как раз успех в той или иной деятельности зависит от такого чудовищного количества факторов, что лишь один из них (а именно те или иные гормоны) непонятно как вписывается в общую картину. И самое главное - а где научные исследования про совместимость того или иного гормонального фона с работой программистом?
Да! (ваш уровень аргументации мне нравится, что ж буду пользоваться тем же приемом)
А тут и аргументировать нечего. Нет возможности научно доказать пригодность того или иного языка для решения тех или иных задач. Я думаю, бОльшая часть программистского сообщества согласится, что Rust - это более низкоуровневая штука, на которой какие-нибудь компиляторы можно писать. А вот писать то, для чего обычно используют JS, т.е. веб-морды для всяческих онлайн-сервисов, на Rust намного сложнее. Но фанатам Rust, конечно, так не кажется, и нет никаких надёжных способов их в этом убедить.
Примеров конечно же не будет приведено в качестве аргумента?
Java: на сервере и в Android из коробки; Graal Native Image - легковесные утилиты, быстро стартующие сервисы, iOS-приложения; Google Closure Compiler, TeaVM - компиляция в JS и в WebAssembly (кстати, значительной разницы в перфомансе между JS и WASM таргетами не наблюдается)
Kotlin: из коробки на сервере, Android, iOS, JS и WebAssembly (опять же, в веб Kotlin прекрасно работал через Kotlin/JS, ещё задолго до появления WASM)
Python - из коробки на сервере; Brython - рантайм для браузера (опять же, через JS).
при том, что если вы сможете запустить модель из браузера и получить ту же производительность, что и если вы запустите из питона используя cuda
CUDA работает на видеокарте. На CPU есть ли какой-то смысл запускать AI-модели (ну кроме чисто учебных)? Во сколько раз просядет производительность? Точнее, на сколько порядков? WebAssembly как-то умеет работать на GPU?
Имеется в виду перечень файлов или дифф в конкретном файле? Для первого случая я просто помещаю окно немодального коммита в тот же бок, где у меня окно projects. Если хватает места для просмотров файла проекта, то хватит и для просмотра перечня изменённых файлов. Во втором случае двойной клик по файлу в немодальном окне коммита открывает дифф прямо в редакторе кода.
При этом с немодальный интерфейсом удобно как раз фокусироваться на коммите. Даже если я в итоге не хочу ничего быстро подправить перед коммитом, мне же его надо ещё как следует проверить и/или написать commit message. А иногда в процессе просмотра диффа у меня возникают различные вопросы относительно кода - и тут его помогает исследовать то, что я всё так же нахожусь в таком же интерфейсе редактора, как и при кодировании, а не в каком-то обрубке, который не позволяет делать очень многие вещи.
Я упоминаю Python, потому что отвечаю на ответ в комментарию, где упоминался Python. А Java я упоминаю потому, что у меня в этой области есть огромная экспертиза. А то, что и для C++ надо так же грузить стандартную библиотеку вместо использования готовой ещё больше подтверждает тезис автора изначального комментария, который я тут пытаюсь защитить, а именно:
Это не сериализация/десериализация. Это просто банальная передача параметров между Wasm-модулем и JS API. Иногда эту передачу можно сделать почти бесшовной, иногда подходы к организации данных в JS, Wasm и гостевом языке настолько принципиально отличаются, что приходится либо что-то "переупаковывать" с соответствующими накладными расходами, либо прямо в гостевом языке городить какой-то страшнейший огород, сводящий на нет все преимущества от возможности писать на этом самом гостевом языке. Например, во всяких C++ библиотеках часто строки идут в памяти либо в виде
wchar_t*,либо дажеchar*в UTF-8. В JS строка хранится не в хипе, а в виде специального встроенного объекта, хранящего строку в UTF-16. Чтобы, например, нарисовать текст в canvas, приходится делать копирование (возможно даже с преобрвазованием UTF-8->UTF-16) там, где в случае чистого JS его можно было бы избежать. Другой пример - это передача JS-объектов между JS и Wasm-модулем - там надо организовывать некие таблицы соответствия, отображающие JS-объекты на хип Wasm.Проблема в том, что в JS есть "стандартная библиотека" - всякие
Array,Date,Math,Mapи т.д., и вся эта стандартная библиотека зашита прямо в браузер. Поэтому для JS надо грузить только сам код, реализующий логику. В случае c Python или Java - у них своя стандартная библиотека, реализация которой (даже в каком-то очень усечённом варианте) может весить несколько мегабайт, даже десятки мегабайт, и которую надо грузить по сети, помимо кода собственно приложения. Сам по себе Wasm не реализует ничего, похожего, например, наjava.util.ArrayList.Потому что компилятор вообще никак не оптимизирует "выполнене пути без исключений". Компилятор (грубо говоря, на самом деле это не совсем так, но это нюансы работы оптимизаторов) генерирует код для try и всего, что внутри, как будто этого try нет. Он просто для всех try пишет в сегмент данных дополнительную метаинформацию: интервалы адресов в коде и сопоставленный им адрес, куда делается переход для обработки исключения. Потом при выбросе исключений подключается рантайм, который ходит по стеку, находит адреса возвратов в нём (для этого так же может потребоваться дополнительная разметка call site-ов, но это опять же, данные) и дальше смотрит, есть ли в таблице try информация об этих адресах. Если он таковую находит, то делает (грубо говоря) простой jump в адрес обработчика.
it depends. Если путь к файлу задан юзером, то очевидным решением будет явная проверка наличия этого файла. Если же это какой-то ресурс приложения, или какой-то файл (например, кэш), который ранее создало само приложение где-нибудь в
$HOME/.cacheи по идее никто не должен был его удалять (если только это зачем-то не сделал юзер, ну или не поломалась ФС), то вполне валидно бросить исключение. Ну и обработать ошибку уже несколькими уровнями выше.Конечно, решаемо. Мы как раз и собирали весь этот ад Maven, пока пару лет назад не смигрировали на Gradle. И это был глоток свежего воздуха. Там где раньше были обильно расставлены костыли и нагорожена куча бойлерплейта, сейчас короткие и ясные декларативные описания. Там, где приходилось сражаться с ограничениями инструмента, сейчас просто берёшь и используешь его.
Да-да, как и плагин. Но тут, конечно, не совсем в тему мой коммент. Просто если проект держат на Maven, то собственно Maven его достаточно редко собирают, ибо каждый раз ждать 5 минут просто чтобы запустить и проверить изменения - это невиданная расточительность. Так вот, мы всегда полагались на то, что IDEA как-то спарсит pom.xml и как-то свой проект сконфигурирует, а потом собирать идеей, т.к. она умеет в инкремениальную сборку, и там, где Maven работал несколько минут, IDEA умудрялась за пару секунд пересобирать. Ну и, конечно, туда не входил protobuf. Поэтому когда кто-то накоммитил изменений в proto-файлы, приходилось брать вручную запускать какие-то goal-ы каких-то проектов. Ну и т.к. это было не одно место, была целая россыпь run configuration на все случаи жизни - что запустить, если при очередном pull проект сломался. Это уж не говоря о том, что при переключении между feature branch и master приходилось всё то же самое проделывать. C gradle в принципе иначе поступают - там собирают всегда им, а не делегируют IDE, и он сам хорошо умеет в инкрементальную компиляцию и способен проект собрать за 2 секунды. Так что как только мы переехали на gradle, необходимость в каких-либо манипуляцих отпала - можно просто запустить проект оттуда, где вы сейчас находитесь, и он гарантированно запустится.
Кстати, ещё забыл. Проект частично на Kotlin, частично на Java, причём есть модули, где есть код и на Kotlin и на Java. Я помню, нужно было отдельно настраивать оба компилятора так, чтобы они правильно совместно работали, т.е. писать кучу бойлерплейта. С Gradle всё не так - нужно всего лишь подключить плагин Java и плагин Kotlin и оно всё само.
Ну а что поделать, если на практике реально возникла ситуация, когда стандартных фаз не хватает? Вот возник кейс, о котором создатели Maven просто не подумали. Приходится шаманить с порядком применения mojo внутри одной фазы, чтобы всё сошлось. И "почесать своё эго" вообще не при чём. По моему опыту, если делаешь типовой Java проект со Spring/Hibernate/что-то такое, собираешь это в war, то Maven отлично работает. А если проект: собрать из (почти) одних сорцов десктопное приложение в виде fat jar, Android-приложение, iOS приложение с помощью Graal Native Image и веб-приложение с помощью какого-нибудь транслятора Java->JS/WebAssembly, да ещё сервер рядом с ними положить в докер-образ вместе с нативными либами, то использование Maven превращается в АД. Кстати, да, часть исходников при этом генерится с помощью какого-нибудь ANTLR, а другая часть - Protobuf.
И, кстати, у организации тасок в граф есть ещё пара преимуществ. Во-первых, так проще сделать инкрементальную сборку. Тогда просто таски не зависят друг от друга напрямую, а output одной таски направляется в input другой. Во-вторых, граф тасок проще распараллелить.
Нет. Разница между Maven и Gradle не в императивности. Кто юзал gradle правильно, и так не писал императивных штук в скриптах, а переносил их в плагины. Разница в том, что плагин в Maven - это по сути одна таска, а в Gradle плагин способен конфигурировать проект целиком - например, подсовывать зависимости, таски, модифицировать имеющиеся и т.д. Это очень полезно, когда в проекте есть модули, имеющие некоторый общий функционал. Например, у нас в проекте мы предоставляем пользователям писать скрипты для нашего приложения на TypeScript, при этом есть некоторые модули, которые экспортируют части этого скриптового API. Для них нужны определённые действия, плюс определённые зависимости. Причём, действия - это не просто одна таска. Например, хочется запускать валидатор сгенерированных
d.tsфайлов, для чего нужен node.js плагин. Почему не написать свой mojo, который бы запускал node.js? Ну потому что такой плагин уже есть и не хочется его велосипедить. До переезда на Gradle мы просто тащили из модуля в модуль определённый бойлерплейт (который ещё изредка менялся и приходилось его апдейтить в каждом модуле, где он есть). В Gradle это выглядит как-то так:plugins {id "tsApiProvider"
}
Кроме того, в Gradle в принципе очень многие вещи сделаны грамотнее:
вместо прибитого гвоздям набора фаз есть граф тасок
концепция конфигураций намного гибче скоупов в maven; идущие из коробки с java плагином конфигурации лучше отражают реалии многомодульных проектов (api/implementation)
продумана инкрементальность на уровне тасок, можно чётко определять для каждой таски, откуда она получает данные на вход, куда пишет вывод.
gradle любят ругать за отсутствие документации. Так вот, для Maven она в тысячи раз хуже. Есть только базовая инструкция, как написать плагин (mojo), но как сделать продвинутые вещи (например, динамически порезолвить зависимость) можно узнать, только залезая в код каких-нибудь плагинов, которые делают более-менее то же самое.
Нет. Разбивка текста на лексему или разбор на AST - это даже не вершина айсберга компиляции, это подтаявший лёд на этой самой вершине.
Нет. См. пункт 1.
А так же исчезнет куча полезного форматирования, применимого в конкретном случае, которое позволяет сделать код более понимаемым.
Языки отличаются друг от друга гораздо больше, чем просто "набором символов, входящих в лексему". И даже больше, чем типами узлов в AST. Задача перевести программу с одного языка на другой практически невыполнима в общем случае.
А зачем? IDE и так хранит эти данные в индексах.
Как раз 5, 6 идея только с виду та же. В старых цивах можно было жульничать. Помню, как в третьей можно было настроить танчиков, по железным дорогам в один ход подтянуть к городам противника и следующим же ходом вынести. В 4 добавили такую штуку что при объявлении войны танчики за границу противника отправлялись и надо было снова их к городам подтягивать. В 5 сделали гексагональную карту, так что направления стали более равноправными (потому что в случае квадратных клеток перемещение по диагонали примерно в 1.41 раз быстрее) и сделали невозможность ставить два юнита на клетку. И это чуть ли не революция, потому что не даёт жульничать, местность начинает интереснее влиять на стратегию. Ещё в 5-й наконец подтянули различные формы правления, так что иногда за маленкую демократическую страну оказывалось играть выгоднее, чем за огромную авторитарную. Жаль, в 6-й этот баланс немного потеряли - стало снова выгодно тупо отстраивать побольше городов, без того, чтобы тщательно продумывать их стратегию развития (несмотря на введённые районы, которые должны только были стратегии развития городов только способствовать). Короче, после 3-й цивилизации каждая игра могла предложить что-то новое и заставляла полностью пересмотреть подходы к стратегии игры.
А как же
IntStream?Вы мне сейчас приписываете какие-то утверждения, которых я не делал. Я не говорю, что верю в "подобные исследования". Я только заметил, что не всегда можно верить своим глазам и здравому смыслу. Что не исключает вероятности кривости тех или иных исследования. Как раз в постулатах квантовой механики (не понимаю, при чём тут кварки, я про них не говорил) я не сомневаюсь, ибо я вначале 10 лет учился в школе, а потом ещё 5 - на физмате, и за это время успел усвоить научную картину мира, к которой человечество шло долгие века, методом проб и ошибок, положив на это кучу ресурсов. Это при том, что с точки зрения органов чувств и "житейской" логики вся квантовая механика - это дичайшая муть.
Автор же комментария, на который я ответил, ведёт себя как такой невежда, который на физмате не учился, услышал о волновой функции и кинулся критиковать, потому что это не соответствует показаниям его органов чувств.
Что касается лично моего опыта (на основании которого, конечно, нельзя делать общих выводов, претендующих на научность) я вижу, что дама написала статью и словила кучу сексистских комментариев. Я при этом ничего не утверждаю о качестве её статьи, о достоверности содержимого - недостаточно компетентен в вопросе, чтобы судить. Я говорю именно о реакции комментаторов.
Во-первых, уйти в отпуск по уходу за ребёнком может и папа. Во-вторых, как раз в IT я очень часто наблюдаю, что женщины с маленьким ребёнком работают - деньги лишними не бывают (особенно для семьи с ребёнком), а сидеть дома скучно, так что многие уже через 3-6 месяцев просятся хотя бы на полставки на удалёнку, и, надо сказать, хорошо справляются с работой.
Зависит от. Некоторые мужчины так же достаточно остро реагируют на ревью. Ну и потом, не факт, что такая реакция не имеет иных причину - например, девушка, окружённая суровыми мужиками (некоторые из которых, возможно, действительно делают сексистские выпадки), испытывает определённые проблемы с самооценкой и потому нервничает.
Согласно моим глазам, ушам, памяти и здравому смыслу нет ничего абсурднее квантовой механики.
Не соглашусь. Мы с вами находимся в некотором информационном пузыре, где это, возможно, действительно так, но вовсем не факт, что так в обществе везде. Хотя бывает, что мы настолько привыкли к некоторой предвзятости по отношению к женщинам, что даже не замечаем некоторой гендерной предвзятости, считая себя образцом толератности.
С другой стороны, я совсем не думаю, что все эти инициативы со стороны компаний и посты в интернете действительно как-то помогут. Скорее, наоборот, вызовут только негативную реакцию. Вот как быть - не могу подсказать, ибо сам не знаю. Возможно, рыночек порешает - сейчас много где в мире назревает нехватка рабочей силы, и мигрантами затыкать вечно не получится (потому что страны, откуда мигрируют, либо в процессе, либо совсем скоро начнут демографический переход).
Я с одной стороны не согласен с тезисом "мужской и женский мозг ничем не отличаются". С другой, да, они отличаются. Но, ИМХО, как раз успех в той или иной деятельности зависит от такого чудовищного количества факторов, что лишь один из них (а именно те или иные гормоны) непонятно как вписывается в общую картину. И самое главное - а где научные исследования про совместимость того или иного гормонального фона с работой программистом?
А никто не говорит про объединение. Старые добрые потоки в пуле
А вы пробовали вместо потока на каждый файл банально запускать задачи в thread pool?
А тут и аргументировать нечего. Нет возможности научно доказать пригодность того или иного языка для решения тех или иных задач. Я думаю, бОльшая часть программистского сообщества согласится, что Rust - это более низкоуровневая штука, на которой какие-нибудь компиляторы можно писать. А вот писать то, для чего обычно используют JS, т.е. веб-морды для всяческих онлайн-сервисов, на Rust намного сложнее. Но фанатам Rust, конечно, так не кажется, и нет никаких надёжных способов их в этом убедить.
Java: на сервере и в Android из коробки; Graal Native Image - легковесные утилиты, быстро стартующие сервисы, iOS-приложения; Google Closure Compiler, TeaVM - компиляция в JS и в WebAssembly (кстати, значительной разницы в перфомансе между JS и WASM таргетами не наблюдается)
Kotlin: из коробки на сервере, Android, iOS, JS и WebAssembly (опять же, в веб Kotlin прекрасно работал через Kotlin/JS, ещё задолго до появления WASM)
Python - из коробки на сервере; Brython - рантайм для браузера (опять же, через JS).
CUDA работает на видеокарте. На CPU есть ли какой-то смысл запускать AI-модели (ну кроме чисто учебных)? Во сколько раз просядет производительность? Точнее, на сколько порядков? WebAssembly как-то умеет работать на GPU?