но JPEG из современной камеры настолько приличный, что можно делить фотками, а не загоняться на обработке
Для простого человека это именно так. Тот же Fujifilm сейчас носят на руках именно за их film simulations и качественный JPEG.
У меня Fuji камера X-H1. Я не профессионал (в том плане, что не получаю за снимки денег). Но снимаю в RAW. Хотя очень доволен цветом из-коробобки-в-jpeg. Причина? к сожалению даже в самом лучшем качестве JPEG имеет проблемы с резкостью. Это вполне актуально если используете фикс-линзы и потом кадрируете снимок.
Вторая причина - в JPEG идет жутчайшая потеря деталей в светах которая не поддается постобработке. Там где я живу света много, даже слишком. Поэтому RAW мне позволяет получить итоговый снимок с приемлемыми потерями в светах. JPEG - нет. Могу это сказать гарантированно т.к. снимаю в режиме JPEG + RAW.
Это всё прекрасно реализуется в сторонних библиотеках
как пример - удачи вам подружить разные библиотеки если они для той же даты разное ISO используют (подсказка, не все библиотеки позволяют задавать формат даты).
>Строгая типизация без завтипов — детская игрушка.
Ничего не объясняет. Не могли бы вы его раскрыть?
Например в моих проектах строгая типизация очень часто выручает.
Или другой пример, полгода назад переписывал java решение на rust. Так даже не самая лучшая система типов в расте позволила выявить и убрать целый пласт проблем изначальной системы.
Я про это и писал. Ровно про это. Разные сущности, а поверх — еще классы. Ради ничего.
Знаете, я только рад, что в программировании изобрели ООП, хотя это и не самый лучший подход.
Почему? Нет ничего идеального. Все эти попытки что-то изобрести, они двигают вперед программирование. И это прекрасно. Это эволюция и наблюдать за ней - удовольствие.
Также это прекрасно, что есть возможность выбора и смотреть на проблему с разных сторон. Например одну и ту же задачу/проблему можно совершенно по разному решать на разных языках и наоборот - один вариант решения бывает физически невозможно реализовать на каком-то конкретном языке.
Со своей стороны я разделяю языки на те, что приносят удовольствие и те, что приносят деньги. И то, что это (в моем случае) не пересекающиеся области не сильно меня смущает.
Заслуга ООП хотя бы в том, что оно показало, что, в итоге этот подход не решает поставленных перед собой задач.
Точно также Erlang показал, что каким бы математически выверенным не был язык - это тоже не панацея. Правда где-то посередине. И я не верю, что какой-то один язык сможет нащупать и реализовать эту золотую середину так, что остальные языки окажутся неудел.
Да и Elixir сам так и говорит, что в их понимании Map - это key-value data-structure.
Если же говорить о каком-нибудь другом языке, то у них map и структура могут быть разными сущностями.
Ваша статья после ваших комментариев преобретает немного другой вид - ощущение, что вы не про "развитие" языков говорите, а хотите чтобы все языки стали похожи на ваш единственный и любимый.
Вы сами себе противоречите: если тесты упали (это ваше предположение, высказанное в предыдущем комментарии) — то проблемное место в коде понятно.
Нет, не противорчу. Кроме "тесты упали" я еще написал "Тестовые сценарии корректные. Визуально код корректный".
Другими словами да, тест упал. Но из кода не очень понятно почему именно он упал. Бывает и такое. И в этом случае наступает время отладки в том или ином виде.
Никогда не поверю, что имея на руках только структуры "списки, мапы, примитивы" всегда все будет по коду без необходимости в том или ином виде отладочной информации.
Рисковый вы человек. Мне, как семейному, ближе стабильность и понимание того, что случись что с компанией где я сейчас работаю - смогу быстро найти другую не сильно изменяя стеку/технологиям.
Поэтому мне лично нужно больше одной компании, внезапно.
идеальное нативное представление языка именно такое: списки, мапы и примитивы. Всё.
Для этого даже ругательство придумано - PHP-стиль :) когда по коду передаётся прсто мапа и удачи предсказать какая у нее будет структура, и когда и кем значения по каким ключам меняется.
Без нормальных структур это боль, а не программирование. Хотя я отчасти согласен - ООП в его академическос понимании создаёт проблем больше, чем их решает.
Кроме джава перечислены "маргинальные" языки. Не в плохом смысле. Просто на этих языках сделано относительно мало проектов. Хотя те, что сделаны безусловно вызывают уважение.
А джава. Из-за требования сохранить совместимость с байт кодом у них дженерики, к примеру, получились ущербными.
Да и туллинга нет официального. То что есть, писаны с боку энтузиастами. И выстрадано кучей неудачных вариантов/поколений.
Для простого человека это именно так. Тот же Fujifilm сейчас носят на руках именно за их film simulations и качественный JPEG.
У меня Fuji камера X-H1. Я не профессионал (в том плане, что не получаю за снимки денег). Но снимаю в RAW. Хотя очень доволен цветом из-коробобки-в-jpeg. Причина? к сожалению даже в самом лучшем качестве JPEG имеет проблемы с резкостью. Это вполне актуально если используете фикс-линзы и потом кадрируете снимок.
Вторая причина - в JPEG идет жутчайшая потеря деталей в светах которая не поддается постобработке. Там где я живу света много, даже слишком. Поэтому RAW мне позволяет получить итоговый снимок с приемлемыми потерями в светах. JPEG - нет. Могу это сказать гарантированно т.к. снимаю в режиме JPEG + RAW.
(1) учитывая, что этот софт практически никто не ставит так себе идея
(2) проприетарный поддерживать намного дороже. кроме него нужно еще и софт см. п. 1 писать
Скорее причины - на момент прихода DNG у нас уже был свой формат, нет смысла переползать на новый. И своя рубашка ближе к телу.
Добро пожаловать в чужный мир костылей.
Зато вполне жизненный. Не всегда возможно контролировать всех клиентов.
как пример - удачи вам подружить разные библиотеки если они для той же даты разное ISO используют (подсказка, не все библиотеки позволяют задавать формат даты).
Команда одна, да. Раст знают еще не очень хорошо, правда.
Это порт, для потребителей сервиса снаружи ничего не меняется.
На расте он по кодовой базе именно стал существенно меньше прям сильно существенно. Не в 10, но раз в 5-6 точно (заинтересовал посчитать точнее).
По потреблению памяти под нагрузкой - разница в 12 раз.
Разница по занятому процессорному времени в 2.5 раза.
Скорость старта с 30 сек, до 300мс.
Как может быть дело не в языке если:
Один запрещает прямую работу с памятью, другой позволяет мат операции над указателями
Один разрешает совместную работу с любыми структурами в мультипотоке, другой разрешает только использование thread-safe типов
Один разрешает null значения, другой запрещает
Один разрешает складывать метры с яблоками, другой - нет
От разработчика зависит, конечно, но очень странно слышать, что дело не в языке.
Если дело не в языке, то зачем вы так топите за один язык и принижаете другие?
Выручает в каком именно смысле? Значит это просто какая-то нишевая дичь, извините.
Проще писать код, меньше лишних рантаймовых проверок.
По нашей статистике на раст проекте меньше заводятся дефекты и почти нет реопен дефектов.
В джава типизация не расширяема, по сути. Обьекты это заменяют.
Ваш тезис :
>Строгая типизация без завтипов — детская игрушка.
Ничего не объясняет. Не могли бы вы его раскрыть?
Например в моих проектах строгая типизация очень часто выручает.
Или другой пример, полгода назад переписывал java решение на rust. Так даже не самая лучшая система типов в расте позволила выявить и убрать целый пласт проблем изначальной системы.
Вынужден не согласиться с вами.
Дайте определение термину - простота.
Может быть это размер спецификации языка? Количество задействованных ключевых слов? Или количество структур данных?
Причины почему Erlang используется в сетевых приложениях "получи-передай" не в простоте, а в гарантиях дающие его компилятором и средой исполнения.
Гарантиях, что данные в структурах не мутируют, гарантии, что память будет очищена автоматически, гарантии, что систему типов не обмануть и так далее.
Назвать Erlang простым - ну такое. Любители Python и JavaScript с вами бы поспорили :)
Знаете, я только рад, что в программировании изобрели ООП, хотя это и не самый лучший подход.
Почему? Нет ничего идеального. Все эти попытки что-то изобрести, они двигают вперед программирование. И это прекрасно. Это эволюция и наблюдать за ней - удовольствие.
Также это прекрасно, что есть возможность выбора и смотреть на проблему с разных сторон. Например одну и ту же задачу/проблему можно совершенно по разному решать на разных языках и наоборот - один вариант решения бывает физически невозможно реализовать на каком-то конкретном языке.
Со своей стороны я разделяю языки на те, что приносят удовольствие и те, что приносят деньги. И то, что это (в моем случае) не пересекающиеся области не сильно меня смущает.
Заслуга ООП хотя бы в том, что оно показало, что, в итоге этот подход не решает поставленных перед собой задач.
Точно также Erlang показал, что каким бы математически выверенным не был язык - это тоже не панацея. Правда где-то посередине. И я не верю, что какой-то один язык сможет нащупать и реализовать эту золотую середину так, что остальные языки окажутся неудел.
Но наблюдать за всем этим - очень интересно!
Поздравляю, вы изобрели структуру :)
Да и Elixir сам так и говорит, что в их понимании Map - это key-value data-structure.
Если же говорить о каком-нибудь другом языке, то у них map и структура могут быть разными сущностями.
Ваша статья после ваших комментариев преобретает немного другой вид - ощущение, что вы не про "развитие" языков говорите, а хотите чтобы все языки стали похожи на ваш единственный и любимый.
Буду рад если это мне только показалось.
дело не в том, что я хочу поменять что-то в мапе, а в том, что структура этой мапы не специфицирована.
При чем здесь Go?
Нет, не противорчу. Кроме "тесты упали" я еще написал "Тестовые сценарии корректные. Визуально код корректный".
Другими словами да, тест упал. Но из кода не очень понятно почему именно он упал. Бывает и такое. И в этом случае наступает время отладки в том или ином виде.
Никогда не поверю, что имея на руках только структуры "списки, мапы, примитивы" всегда все будет по коду без необходимости в том или ином виде отладочной информации.
Рисковый вы человек. Мне, как семейному, ближе стабильность и понимание того, что случись что с компанией где я сейчас работаю - смогу быстро найти другую не сильно изменяя стеку/технологиям.
Поэтому мне лично нужно больше одной компании, внезапно.
Для этого даже ругательство придумано - PHP-стиль :) когда по коду передаётся прсто мапа и удачи предсказать какая у нее будет структура, и когда и кем значения по каким ключам меняется.
Без нормальных структур это боль, а не программирование. Хотя я отчасти согласен - ООП в его академическос понимании создаёт проблем больше, чем их решает.
Кроме джава перечислены "маргинальные" языки. Не в плохом смысле. Просто на этих языках сделано относительно мало проектов. Хотя те, что сделаны безусловно вызывают уважение.
А джава. Из-за требования сохранить совместимость с байт кодом у них дженерики, к примеру, получились ущербными.
Да и туллинга нет официального. То что есть, писаны с боку энтузиастами. И выстрадано кучей неудачных вариантов/поколений.
Чудный мир сферических коней.
Рад, что хоть у кого есть возможность писать на erlang и имеет идеальные всепокрывающие тесты.
Завидую. За 25 лет в ИТ ни разу такого не видел.