сейчас уже неясно. Раньше любое переписывание проекта на новый язык — это был тупиковый путь. Но с использованием ИИ подобные задачи должны решаться проще. В любом случае пусть попробуют. 1 человек — не такие большие затраты.
Вера это не наш удел. Но вероятность того, что с помощью ИИ можно оптимизировать компиляторы того же C# в С++ вполне реально.
Native AOT развиваются, многие библиотеки подтягивают совместимость.
Возможно стоило бы расширить C# для создания объектов на стеке. Структуры к сожалению многого не поддерживают.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Pzz, Вы писали:
Pzz>Пипец какой. Ну т.е. содержательно, собралось как-то — ну и ладушки. Pzz>Как один инженер может за один месац понять хоть что-то в миллионе строк кода?
Pzz>Слабоумие и отвага...
Видимо им этот C++ как гвоздь в заднице — спецов мало, стоят дорого, обучать долго и дорого. И без него никак
Здравствуйте, Shmj, Вы писали:
Pzz>>Слабоумие и отвага...
S>Видимо им этот C++ как гвоздь в заднице — спецов мало, стоят дорого, обучать долго и дорого. И без него никак
Ну, я бы мелочи переписал, откровенно проблемные места переписал, а что работает, оставил бы и поддерживал. Для нового кода старался бы C++ не брать.
В конце концов, их любимый Rust вполне сочетается, насколько я в курсе, внутри одной программы с C++.
А так вот махом взять и переписать всё, со скоростью миллион строк кода на один человеко-месяц — это верный способ получить тонны кода, в котором старые проблемы в среднем сохранятся, появятся доселе невиданные новые, и в котором НИКТО НИЧЕГО НЕ ПОНИМАЕТ. IMHO, это ужас-ужас и кошмар.
Здравствуйте, Pzz, Вы писали:
Pzz>А так вот махом взять и переписать всё, со скоростью миллион строк кода на один человеко-месяц — это верный способ получить тонны кода, в котором старые проблемы в среднем сохранятся, появятся доселе невиданные новые, и в котором НИКТО НИЧЕГО НЕ ПОНИМАЕТ. IMHO, это ужас-ужас и кошмар.
Боюсь что так и будет. Причина — язык это целая философия, а не просто инструкции.
Здравствуйте, Shmj, Вы писали:
Pzz>>В конце концов, их любимый Rust вполне сочетается, насколько я в курсе, внутри одной программы с C++.
S>Это как? Нету сочетания — только стандартный FFI, с таким же успехом можете с Delphi сочетать...
Ну вот да, через FFI. Но насколько я понимаю, Rust сочетсяется с C через FFI в любую сторону. Т.е., можно в программу на Rust вставить запчасть на C, можно наоборот. Иди, попробуй в программу на C кусок на Haskell вставь. Или на Питоне даже, но так, чтобы работало нормально. У Питона тоже есть FFI.
Здравствуйте, Shmj, Вы писали:
Pzz>>А так вот махом взять и переписать всё, со скоростью миллион строк кода на один человеко-месяц — это верный способ получить тонны кода, в котором старые проблемы в среднем сохранятся, появятся доселе невиданные новые, и в котором НИКТО НИЧЕГО НЕ ПОНИМАЕТ. IMHO, это ужас-ужас и кошмар.
S>Боюсь что так и будет. Причина — язык это целая философия, а не просто инструкции.
И заметь, специфически-плюсовые проблемы, типа неаккуратного обращения с памятью, так может и поймают. Но собственно, если сравнимое количество ресурсов и усилий потратить на статический анализ C++ (давайте назовём это переписыванием с C++ на C++ ), то полагаю, сравнимое количество ошибок и будет найдено и устранено.
А вот логические ошибки, они никуда не денутся. Кроме того, совсем не факт, что ИИ перепишет алгоритмы, сохранив эквиавалентность исходного и переписанного алгоритма, т.е. тут тоже может понадобавлять ошибок. Которые вылезут в corner cases, совсем не факт, что покрытых тестами.
В общем, если они получили на это развлечение грант от Пентагона или АНБ, ну, молодцы, хороший бизнес. А если за свои, ну, такое себе.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну вот да, через FFI. Но насколько я понимаю, Rust сочетсяется с C через FFI в любую сторону. Т.е., можно в программу на Rust вставить запчасть на C, можно наоборот. Иди, попробуй в программу на C кусок на Haskell вставь. Или на Питоне даже, но так, чтобы работало нормально. У Питона тоже есть FFI.
Здравствуйте, Shmj, Вы писали:
Pzz>>Ну вот да, через FFI. Но насколько я понимаю, Rust сочетсяется с C через FFI в любую сторону. Т.е., можно в программу на Rust вставить запчасть на C, можно наоборот. Иди, попробуй в программу на C кусок на Haskell вставь. Или на Питоне даже, но так, чтобы работало нормально. У Питона тоже есть FFI.
S>Можно: https://wiki.haskell.org/Foreign_Function_Interface
S>FFI — это одно из немногого, о чем человечество смогло договориться.
То, что из Хаскеля можно вызвать Си, нет никаких сомнений. Иначе он ни слова напечатать бы не мог.
А вот в другую сторону — там возникают всякие интересные проблемы с рантайном. И это совсем не то же самое, что FFI.
Например, на Go можно написать C-callable библиотеку (и динамическую и статическую). Но две такие штуки в одном процессе ужиться не могут (я, правда, давно на это нарывался, может с тех пор что-то и починили). Проблема в том, что два гошных рантайма в одном процессе не могут поделить tread-local storage, они как-то очень хитро на него садятся, и мешают друг другу.
Здравствуйте, Shmj, Вы писали:
S>Если бы в Rust добавили полноценное ООП — тогда бы было интересно.
не понимаю какого ООП вам там не хватает? Трейты — фактически абстрактные классы. Указатели есть. Пример на С++ который трудно/невозможно написать на Rust в студию.
Здравствуйте, sergii.p, Вы писали: SP>не понимаю какого ООП вам там не хватает? Трейты — фактически абстрактные классы. Указатели есть. Пример на С++ который трудно/невозможно написать на Rust в студию.
Ну вот пример:
С++
Скрытый текст
#include <iostream>
#include <memory>
class Base1 {
public:
virtual ~Base1() = default;
virtual void fun1() const {
std::cout << "fun1=" << a << std::endl;
}
virtual void fun2() const {
std::cout << "fun2=" << a << std::endl;
}
virtual void fun3() const {
std::cout << "fun3=" << a << std::endl;
}
virtual void fun4() const {
std::cout << "fun4=" << a << std::endl;
}
private:
int a = 0;
};
class V1 : public Base1 {
public:
void fun1() const override {
std::cout << "_fun1=" << a << std::endl;
}
private:
int a = 1;
};
class V2 : public V1 {
public:
void fun2() const override {
std::cout << "__fun2=" << a << std::endl;
}
private:
int a = 2;
};
class V3 final : public V2 {
public:
void fun3() const override {
std::cout << "___fun2=" << a << std::endl;
}
private:
int a = 3;
};
int main() {
const auto v3 = std::make_unique<V3>();
v3->fun1();
v3->fun2();
v3->fun3();
v3->fun4();
return 0;
}
Т.е. в наследнике вы трогаете только то что отличается. Все просто 3 класса, поочередно наследуются. Это может быть как UI-виджеты так и некая система событий.
А вот Rust аналог авто-генеренный
Куча сущностей вместо трех простых записанных, намноОООго сложнее для восприятия. Т.е. теряется простота. А в последнем V3 вам еще нужно помнить что было переписано в V2 — это на малом количестве методов — а если их будут сотни?
В общем — слишком сложный для восприятия ООП-код получается. Не пригодно для промышленного использования.
Здравствуйте, Shmj, Вы писали:
S>Видимо им этот C++ как гвоздь в заднице — спецов мало, стоят дорого, обучать долго и дорого. И без него никак
У Ханта специфический опыт. Сингулярити, тулы для С для решения проблем памяти. Это накладывает отпечаток на человека, а в реальности проблемы в индусах, процессах и отсутствии тестирования нормального.