Что вы так привязались к этим цифрам? Чего они вам покоя не дают?
В моем исходном сообщении фраза «1.0.0 по semver'у» была в качестве примера, а не строгого определения. Ключевой вопрос в том как посчитать длительность создания продукта? т. е. временной интервал от начала работы над продуктом и до появления первой законченной версии версии программы, которую пользователь может взять установить и пользоваться.
И я сказал, что, на мой взгляд, второй из этих дат должна быть дата стабильного релиза, а не дата завершения прототипа, проведения большоего бенчмарка или чего-то еще. Как ее определить? Этот вопрос как правило требует отдельного расмотрения в каждом отдельном случае.
Да, возможно с версией git'a 1.0.0 я и погорячился. Скорее всего там не использовалось сематическое весионирование. Но для такого софта как git стабильной версией, как правило, считается та версия продукта, которая уже где-то внедрена в продакшен, на которую какой-то пользователь готов «поставить» свои деньги, кусочек своего бизнеса, репутации и т. п. Т. е. это как минимум 16 июня 2005 когда был первый релиз linux'a под git'ом. Очевидно, где-то в эти же дни должен был быть релиз очередной версии самого git'a.
В любом случае, это говорит о том что git создавался больше чем 1 день (или 10 дней, кому что ближе).
О каких продуктах идет речь? Можно пример? а лучше несколько :-)
И что такое значительно число людей в вашем понимании?
Реализная версия говорит не только о том, что в ней не должно быть критических багов, а также о том что автор уверен в выбранном им подходе и как минимум ключевой функционал программы реализован.
Если некоторое количество людей пользуется продуктом до релиза — это фактически не говорит ни чего о готовности программы. Автор может найти какой-нибудь фатальный недостаток и все переделать или вообще разочароваться в идее и свернуть разработку. Но после релиза уже появляются определенные обязательства и гарантии, которые дает автор. То что не все производители добросовестно к этому относятся это уже совсем другой вопрос.
Скорее всего меня сейчас дико заминусуют, но я все же скажу.
Скорее всего "… и нет". Но эта история похоже сильно разукрашена. Иначе так можно говорить про каждый удачный прототип, еще и созданный по идеям уже существующих программ того же класса. Как-то нечестно получается по отношению к другим программам и их разработчикам.
Для меня, время создания продукта (и в том числе git'а) — это время выхода первой стабильной версии (1.0.0 по semver'у). Судя по зеркалу git'a на github'e (https://github.com/git/git) первый сохранившийся коммит в git был 3 апреля 2005 года, а релиз 1.0.0 — 21 декабря 2005. Похоже 10 дней немного растянулись, не говоря уже про 1.
C тех пор у MS уже 2 руководителя сменилось и тенденции изменений с приходом последнего весьма положительные: в open source вышел .net и много чего еще.
Или вы хотите сказать что MS хочет под себя изменить весь open source? :-)
Про 1-3 метода, свойства и т. п., мне кажется, это перебор. Минимальная сложность решения задачи эквивалентна сложности самой задачи и не всегда можно 1 цельный логический объект разбить на кучу маленьких идеальных объектов по 1-3 метода. Если у тебя 5 связанных свойств в объекте, то методов для работы с ними скорее всего будет еще больше, а при попытке разбить этот объект на более мелкие прийдется как минимум это состояние в 5 полей пробрасывать между мелкими объектами, что возможно еще и к нарушению инкапсуляции приведет.
Видимо, из двух зол выбираем меньшее. Когда память заканчивается еще хуже, чем задержки на IPC.
Плюс к этому, скорее всего в 1 момент времени активный IPC будет идти далеко не у всех плагинов одновременно, а только у нескольких, с которыми сейчас идет непосредственная работа.
По поводу 64-битной студии, похоже это уже несбыточная мечта. Там COM, там, говорят, в никоторых местах возвращаются 32-битные указатели в public API. Стойкое нежелание разработчиков VS это только подтверждает. Похоже, проще написать новую IDE аля Visual Studio Code, чем переписывать текущую. Так что в ближайшие 2-5 лет, по-моему ожидаются массовые миграции на Visual Studio Code и Rider
Вряд ли в общем случае получится локальную функцию заинлайнить (например: реккурсия). Но скорее всего можно будет сэкономить на аллокации замыкающего класса и сгенерировать функцию принимающую структуру с параметрами.
Посмотрите например вот это или можете сами поискать доклады Константина Осипова он архитектор этой БД и уже есть достаточно много записей его докладов, где он достаточно подробно и на понятном языке рассказывает как устроен tarantool, для каких задач оптимизирован и какие есть плюсы и минусы у этой БД.
У MS и так уже VC++, C#, VB.NET, TypeScript. Зачем им еще 1 язык тянуть? К тому же к Nemerle будет сложно в разумные сроки прикрутить поддержу IDE, чтобы он смог хоть как-то соперничать с C#+VS+R#. А скоро еще и Rider появится, который будет быстрее, удобнее, красивее и… ну вы поняли. Так что скорее всего без поддержки JetBrains Nemerle не выжить в dotNet-среде. А у них уже есть R# и Rider(ну почти есть). А так как целевая аудитория Nemerle — это те же C# программисты, то получается JetBrains нужно будет делать еще 1 IDE, чтобы она конкурировала с другими своими продуктами? Согласистесь это было бы странно для компании, которая зарабатывает деньги на разработке IDE.
В общем, пациент скорее мертв, чем жив. Хотя, конечно печально, что ситуация стала такой. Язык достаточно итресный и мог бы сильно упростить/ускорить разработку больших продуктов, но без IDE…
Нет ничего проще, чем делегировать проблему «на уровень выше» тому кто использует класс, инструмент, абстракцию и т. д., а там профессионалы разберутся. Вот с null-ом, кажется большинство здравомыслящих людей ошибку поняло и согласилось, что нужно исправлять, а с наследованием, видимо, история только начинается.
В агитируете за прагматичный подход, а мне кажется, что даже в приведенной вами аналогии стабильность лучше.
Вы предлагаете наращивать квалификацию и дисциплину рабочего и это хорошо, но может быть все-таки в данном случае лучше закупить более дорогое, но безопасное оборудование? Ведь оба подхода решают проблему, но стабильность в долгосрочном периоде лучше.
В моем исходном сообщении фраза «1.0.0 по semver'у» была в качестве примера, а не строгого определения. Ключевой вопрос в том как посчитать длительность создания продукта? т. е. временной интервал от начала работы над продуктом и до появления первой законченной версии версии программы, которую пользователь может взять установить и пользоваться.
И я сказал, что, на мой взгляд, второй из этих дат должна быть дата стабильного релиза, а не дата завершения прототипа, проведения большоего бенчмарка или чего-то еще. Как ее определить? Этот вопрос как правило требует отдельного расмотрения в каждом отдельном случае.
Да, возможно с версией git'a 1.0.0 я и погорячился. Скорее всего там не использовалось сематическое весионирование. Но для такого софта как git стабильной версией, как правило, считается та версия продукта, которая уже где-то внедрена в продакшен, на которую какой-то пользователь готов «поставить» свои деньги, кусочек своего бизнеса, репутации и т. п. Т. е. это как минимум 16 июня 2005 когда был первый релиз linux'a под git'ом. Очевидно, где-то в эти же дни должен был быть релиз очередной версии самого git'a.
В любом случае, это говорит о том что git создавался больше чем 1 день (или 10 дней, кому что ближе).
И что такое значительно число людей в вашем понимании?
Реализная версия говорит не только о том, что в ней не должно быть критических багов, а также о том что автор уверен в выбранном им подходе и как минимум ключевой функционал программы реализован.
Если некоторое количество людей пользуется продуктом до релиза — это фактически не говорит ни чего о готовности программы. Автор может найти какой-нибудь фатальный недостаток и все переделать или вообще разочароваться в идее и свернуть разработку. Но после релиза уже появляются определенные обязательства и гарантии, которые дает автор. То что не все производители добросовестно к этому относятся это уже совсем другой вопрос.
Скорее всего "… и нет". Но эта история похоже сильно разукрашена. Иначе так можно говорить про каждый удачный прототип, еще и созданный по идеям уже существующих программ того же класса. Как-то нечестно получается по отношению к другим программам и их разработчикам.
Для меня, время создания продукта (и в том числе git'а) — это время выхода первой стабильной версии (1.0.0 по semver'у). Судя по зеркалу git'a на github'e (https://github.com/git/git) первый сохранившийся коммит в git был 3 апреля 2005 года, а релиз 1.0.0 — 21 декабря 2005. Похоже 10 дней немного растянулись, не говоря уже про 1.
C тех пор у MS уже 2 руководителя сменилось и тенденции изменений с приходом последнего весьма положительные: в open source вышел .net и много чего еще.
Или вы хотите сказать что MS хочет под себя изменить весь open source? :-)
Плюс к этому, скорее всего в 1 момент времени активный IPC будет идти далеко не у всех плагинов одновременно, а только у нескольких, с которыми сейчас идет непосредственная работа.
По поводу 64-битной студии, похоже это уже несбыточная мечта. Там COM, там, говорят, в никоторых местах возвращаются 32-битные указатели в public API. Стойкое нежелание разработчиков VS это только подтверждает. Похоже, проще написать новую IDE аля Visual Studio Code, чем переписывать текущую. Так что в ближайшие 2-5 лет, по-моему ожидаются массовые миграции на Visual Studio Code и Rider
В общем, пациент скорее мертв, чем жив. Хотя, конечно печально, что ситуация стала такой. Язык достаточно итресный и мог бы сильно упростить/ускорить разработку больших продуктов, но без IDE…
В агитируете за прагматичный подход, а мне кажется, что даже в приведенной вами аналогии стабильность лучше.
Вы предлагаете наращивать квалификацию и дисциплину рабочего и это хорошо, но может быть все-таки в данном случае лучше закупить более дорогое, но безопасное оборудование? Ведь оба подхода решают проблему, но стабильность в долгосрочном периоде лучше.