Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>В ИИ эпоху язык с микроменеджментом вокруг каждого пук-сереньк обречен.
S>Звучит как приговор для чистого Си.
И для Си в том числе.
K>>Простой язык без микроменеджмента в каждом операторе и поддержкой доказательств с помощью ИИ.
S>У вас уже есть статистика, подтверждающая, что с приходом ИИ в проектах на чистом Си стало меньше багов и уязвимостей. Ведь есть же, да?
А куда вы так спешите? Языки очень инерционные, в С++ уже сколько лет с умишком собираются чтобы рефлексию добавить? ИИ появился всего пару лет назад, люди еще не успели собраться с мыслями.
Очевидно же что в конечном итоге победит язык который сможет как можно больше переложить на ИИ наиболее эффективным способом.
Руст и прочие языки в которых программист вынужден управлять временем жизни каждой переменной уже не нужны. Они еще будут куда-то двигаться по инерции, но по факту это мертворожденные технологии.
Re[5]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
S>>Звучит как приговор для чистого Си.
K>И для Си в том числе.
Ну вот Си и закапывают, в том числе и посредством Rust-а.
S>>У вас уже есть статистика, подтверждающая, что с приходом ИИ в проектах на чистом Си стало меньше багов и уязвимостей. Ведь есть же, да?
K>А куда вы так спешите?
Я не спешу, просто интересно, на чем делать проекты пока это щастливое будущее с заглавной буквы Ща еще не наступило. И так, чтобы не "собирать корки по утрам".
K>Очевидно же что в конечном итоге победит язык который сможет как можно больше переложить на ИИ наиболее эффективным способом.
Вам, может быть, и очевидно. Впрочем, альтернативно одаренным много чего очевидно, плохо только, когда вы субстанцию из своей головы на просторы интернета выплескиваете. Тот же ИИ как раз на ваших испражнениях и обучается, что не позволяет так уж сильно на него надеятся.
K>Руст и прочие языки в которых программист вынужден управлять временем жизни каждой переменной уже не нужны.
Да, да. Языки с GC уже лет семьдесят доказывают, что еще чуть чуть и они перестанут тормозить.
Только вот сюрприз, в тех же С++, Rust и Ada не нужно управлять временем жизни каждой переменной вручную. Но зачем тов.Kluev об этом задумываться, если можно просто очередную порцию бреда высрать на публику.
Re[6]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>>>Да и вообще писал ли ты на чистом Си что-то сложнее HelloWorld-а? Аё>>Писал часть модуля для продакшена- платформо-зависимый нативный кусочек, который вызывался из ооп-го апплета. Правил код прошивки девайса
S>Т.е. не писал.
Перечитай ещё раз написанное мной. Потом ещё раз, внимательно.
Аё>>>>С++ был прекрасен на заре (Си с классами + шаблоны), пока из него не наворотили всемогутора-из-костылей.
S>>>Тёмчик опять затрындел о том, в чем не разбирается. Аё>>Я писал на плюсах- тогда никто не жаловался, даже наоборот.
S>Судить о современном С++ на основании хз какого опыта 20-летней давности, ну такое себе. Тёмчик еще раз доказал, что он Тёмчик.
Ну так "современный C++" это всемогутор мз костылей.
S>>>a) это не ответ на вопрос о том, какого этого самого тебе до переписывания sudo на Rust? Аё>>Мне не нравится, когда неосиляторы лезут своими кривыми грязными ручонками и ломают то, что уже работает.
S>На твоей работе это как-то сказалось?
Что ты докопался до моей работы? Да я пользуюсь sudo, причём не только по работе.
S>В самом sudo они что-то поломали?
Да, они поломали часть фич.
S>Эти ребята делают свой sudo-rs и другие ребята думают, что sudo-rs дает им больший коэффициент спокойного сна.
Лишь бы следующим шагом не подменили нормалтный судо на калечный.
Аё>>Отрезают фичи по ниасилили
S>Что из того, что они "ниасилили" сказывается на твоей работе?
Мне, как польщователю линух со стажем, не нравится что лезут кривыми ручонками неосиляторы
Аё>>глючит больше == ломают
S>Что в sudo-rs глючит?
Фичи, которые это криворукие смузихлёбы ниасиоили === поломали.
Re[7]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Артём, Вы писали:
S>>>>Да и вообще писал ли ты на чистом Си что-то сложнее HelloWorld-а? Аё>>>Писал часть модуля для продакшена- платформо-зависимый нативный кусочек, который вызывался из ооп-го апплета. Правил код прошивки девайса
S>>Т.е. не писал. Аё>Перечитай ещё раз написанное мной. Потом ещё раз, внимательно.
Прочитал. Там написано, что опыта разработки чего-то серьезнее HelloWorld-а на чистом Си у тебя нет.
S>>Судить о современном С++ на основании хз какого опыта 20-летней давности, ну такое себе. Тёмчик еще раз доказал, что он Тёмчик. Аё>Ну так "современный C++" это всемогутор мз костылей.
Ну так и Тёмчик все тот же Тёмчик.
А тем, кому не шашечки, а ехать, просто пользуются современным C++ и делают на нем то, что раньше было невозможно.
S>>На твоей работе это как-то сказалось? Аё>Что ты докопался до моей работы? Да я пользуюсь sudo, причём не только по работе.
Так говори предметнее.
S>>В самом sudo они что-то поломали? Аё>Да, они поломали часть фич.
Что из того, что они поломали, тебе нужно?
S>>Что в sudo-rs глючит? Аё>Фичи, которые это криворукие смузихлёбы ниасиоили === поломали.
Глючит -- это когда работает неправильно. А когда что-то выбросили, это уж точно не "глючит".
Можно было бы попросить тебя не тупить и не подменять понятия, но ты же Тёмчик.
Re[6]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Ну вот Си и закапывают, в том числе и посредством Rust-а.
Все до ИИ языки закопают со временем. Как паровые машины. И руст одним из первых.
S>Я не спешу, просто интересно, на чем делать проекты пока это щастливое будущее с заглавной буквы Ща еще не наступило. И так, чтобы не "собирать корки по утрам".
Вам совет дать или это вопрос риторический?
K>>Очевидно же что в конечном итоге победит язык который сможет как можно больше переложить на ИИ наиболее эффективным способом.
S>Вам, может быть, и очевидно. Впрочем, альтернативно одаренным много чего очевидно, плохо только, когда вы субстанцию из своей головы на просторы интернета выплескиваете. Тот же ИИ как раз на ваших испражнениях и обучается, что не позволяет так уж сильно на него надеятся.
Кто вам мешает обучать на своих?
K>>Руст и прочие языки в которых программист вынужден управлять временем жизни каждой переменной уже не нужны.
S>Да, да. Языки с GC уже лет семьдесят доказывают, что еще чуть чуть и они перестанут тормозить.
Это все узколобое сектантство. Во многих задачах языки с GC уже быстрее языков с ручным управлением.
S>Только вот сюрприз, в тех же С++, Rust и Ada не нужно управлять временем жизни каждой переменной вручную. Но зачем тов.Kluev об этом задумываться, если можно просто очередную порцию бреда высрать на публику.
Эти сказки вы рассказывайте восторженным неофитам. С++ вам дает только голенький указатель, а управляете вы им с помощью костылей из stl которая частью языка не является.
Re[7]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>Все до ИИ языки закопают со временем.
"Это все узколобое сектантство." (c) некто Kluev
S>>Я не спешу, просто интересно, на чем делать проекты пока это щастливое будущее с заглавной буквы Ща еще не наступило. И так, чтобы не "собирать корки по утрам".
K>Вам совет дать или это вопрос риторический?
У вас кто-то спрашивал совета? И даже в более общем смысле: вашего мнения здесь кто-то спрашивал? Это вы зачем-то здесь объявились со своим ИИ-мессианством.
K>>>Руст и прочие языки в которых программист вынужден управлять временем жизни каждой переменной уже не нужны.
S>>Да, да. Языки с GC уже лет семьдесят доказывают, что еще чуть чуть и они перестанут тормозить.
K>Это все узколобое сектантство. Во многих задачах языки с GC уже быстрее языков с ручным управлением.
И хвала всевышнему, куча народа имеет возможность зарабатывать на жизнь программизмом не заботясь о вопросах управления памятью и пр. Вопрос в том, что делать с другими задачами, где нужна не только скорость, но и предсказуемость, и контроль за потреблением ресурсов. С простым ответом: не использовать там языки с GC. Так происходит на протяжении полувека, и так же будет происходить и дальше.
S>>Только вот сюрприз, в тех же С++, Rust и Ada не нужно управлять временем жизни каждой переменной вручную. Но зачем тов.Kluev об этом задумываться, если можно просто очередную порцию бреда высрать на публику.
K>Эти сказки вы рассказывайте восторженным неофитам. С++ вам дает только голенький указатель,
Для неасиляторов вопрос: покажите мне здесь хоть один голенький указатель. Ну и ручное управление памятью заодно.
#include <iostream>
class A {
public:
void f() { std::cout << "A::f()" << std::endl; }
};
class B {
public:
void f() { std::cout << "B::f()" << std::endl; }
};
class C {
A _a;
B _b;
public:
void f() {
std::cout << "C::f()" << std::endl;
_a.f();
_b.f();
}
};
int main()
{
C c;
c.f();
}
K> а управляете вы им с помощью костылей из stl которая частью языка не является.
У стандарта C++ на этот счет прямо противоположное мнение.
Re[8]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
K>>Все до ИИ языки закопают со временем.
S>"Это все узколобое сектантство." (c) некто Kluev
Это прогноз.
S>У вас кто-то спрашивал совета? И даже в более общем смысле: вашего мнения здесь кто-то спрашивал? Это вы зачем-то здесь объявились со своим ИИ-мессианством.
А вашего кто спрашивал? не видел чтобы вас кто-то звал в тред.
K>>Это все узколобое сектантство. Во многих задачах языки с GC уже быстрее языков с ручным управлением.
S>И хвала всевышнему, куча народа имеет возможность зарабатывать на жизнь программизмом не заботясь о вопросах управления памятью и пр. Вопрос в том, что делать с другими задачами, где нужна не только скорость, но и предсказуемость, и контроль за потреблением ресурсов. С простым ответом: не использовать там языки с GC. Так происходит на протяжении полувека, и так же будет происходить и дальше.
Это ваше большое заблуждение, что GC сделали ради упрощения языка специально для неосиляторов. Без GC и JIT не будет работать компонентная модель, не будут работать некоторые lock free алогритмы основанные на том, что простое присваивание позволяет забыть указатель (В с++ не реализуемо) и другие вещи. Многие вещи которые можно сделать например на C# в языке C++ просто не реализуемы.
S>>>Только вот сюрприз, в тех же С++, Rust и Ada не нужно управлять временем жизни каждой переменной вручную. Но зачем тов.Kluev об этом задумываться, если можно просто очередную порцию бреда высрать на публику.
S>Для неасиляторов вопрос: покажите мне здесь хоть один голенький указатель. Ну и ручное управление памятью заодно. S>
#include <iostream>
S>}
К любой переменной вашего примера примените оператор & и у вас будет голый указатель. Более того сам язык другие и не поддерживает.
K>> а управляете вы им с помощью костылей из stl которая частью языка не является.
S>У стандарта C++ на этот счет прямо противоположное мнение.
стандарт языка С++ определяет сам язык и стандартную библиотеку. Очевидно же, что стандартная библиотека частью языка не является. Компилятор за исключением классов type_info, std::initializer_list<T>, std::exception вобще не знает о ее существовании.
Re[9]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
S>>У вас кто-то спрашивал совета? И даже в более общем смысле: вашего мнения здесь кто-то спрашивал? Это вы зачем-то здесь объявились со своим ИИ-мессианством.
K>А вашего кто спрашивал? не видел чтобы вас кто-то звал в тред.
Так я и не спрашиваю дать ли кому-то совет. А пытаюсь выяснить у ТСа что именно так поломали в sudo-rs, что отразилось на ТСе. И какое вообще ТС-у дело до того, на каком языке sudo реализован.
S>>И хвала всевышнему, куча народа имеет возможность зарабатывать на жизнь программизмом не заботясь о вопросах управления памятью и пр. Вопрос в том, что делать с другими задачами, где нужна не только скорость, но и предсказуемость, и контроль за потреблением ресурсов. С простым ответом: не использовать там языки с GC. Так происходит на протяжении полувека, и так же будет происходить и дальше.
K>Это ваше большое заблуждение, что GC сделали ради упрощения языка специально для неосиляторов.
А теперь, пожалуйста, найдите в моих словах что-либо о ниасиляторстве.
S>>Для неасиляторов вопрос: покажите мне здесь хоть один голенький указатель. Ну и ручное управление памятью заодно.
K>К любой переменной вашего примера примените оператор & и у вас будет голый указатель.
Еще раз вопрос: покажите здесь хоть один голенький указатель и управление памятью.
А то ведь получается, что работающая программа на C++ без указателей и без ручного управления временем жизни переменных есть, тогда как вы утверждали, все все это неизбежно.
K>>> а управляете вы им с помощью костылей из stl которая частью языка не является.
S>>У стандарта C++ на этот счет прямо противоположное мнение.
K>стандарт языка С++ определяет сам язык и стандартную библиотеку. Очевидно же, что стандартная библиотека частью языка не является.
Ну да, в стандарте на язык програмирования описано то, что частью языка не является. Очевидно же (это сарказм, если что).
Re[10]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
K>>К любой переменной вашего примера примените оператор & и у вас будет голый указатель.
S>Еще раз вопрос: покажите здесь хоть один голенький указатель и управление памятью.
Так вот же они родимые:
std::cout << "A::f()" << std::endl;
Или по вашему const char[] не голенький указатель?
S>А то ведь получается, что работающая программа на C++ без указателей и без ручного управления временем жизни переменных есть, тогда как вы утверждали, все все это неизбежно.
А деструктор вам компилятор написал? В деструкторе вы и управляете временем жизни, решая как и каким способом удалять обьект. Так что без ручного управления никуда.
K>>>> а управляете вы им с помощью костылей из stl которая частью языка не является.
S>>>У стандарта C++ на этот счет прямо противоположное мнение.
K>>стандарт языка С++ определяет сам язык и стандартную библиотеку. Очевидно же, что стандартная библиотека частью языка не является.
S>Ну да, в стандарте на язык програмирования описано то, что частью языка не является. Очевидно же (это сарказм, если что).
Естественно что библиотека не является частью языка т.к. написана на нем самом. То что нельзя редуцировать используя другие конструкции языка это и есть язык.
Re[11]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
S>>Еще раз вопрос: покажите здесь хоть один голенький указатель и управление памятью.
K>Так вот же они родимые: K>
std::cout << "A::f()" << std::endl;
K>Или по вашему const char[] не голенький указатель?
Нет, это const char[7].
S>>А то ведь получается, что работающая программа на C++ без указателей и без ручного управления временем жизни переменных есть, тогда как вы утверждали, все все это неизбежно.
K>А деструктор вам компилятор написал?
Да.
K>В деструкторе вы и управляете временем жизни, решая как и каким способом удалять обьект.
Покажите пальцем, а то программа есть, а ручного управления нет.
S>>Ну да, в стандарте на язык програмирования описано то, что частью языка не является. Очевидно же (это сарказм, если что).
K>Естественно что библиотека не является частью языка
Именно поэтому она описана в стандарте языка, ясно-понятно.
Re[12]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Kluev, Вы писали:
S>>>Еще раз вопрос: покажите здесь хоть один голенький указатель и управление памятью.
K>>Так вот же они родимые: K>>
std::cout << "A::f()" << std::endl;
K>>Или по вашему const char[] не голенький указатель?
S>Нет, это const char[7].
Это и есть голенький указатель на строку в сегменте данных.
S>>>А то ведь получается, что работающая программа на C++ без указателей и без ручного управления временем жизни переменных есть, тогда как вы утверждали, все все это неизбежно.
Естесвенно. Если рассмотреть эту программу в целом то мы обязательно найдем ручной самописный код в деструкторе или еще где который вручную освобождает память. Какая разница кем это написано вами или авторами стандартной библиотеки? Чтобы не было ручного управления памятью вам нужно использовать только статическую или автоматическую память. Но вы используете iostream, а он выделяет динамическую память как минимум на буффер:
> ucrtbased.dll!free(void * block) Line 19 C++
msvcp140d.dll!std::_Crt_new_delete::operator delete(void * _Ptr) Line 47 C++
msvcp140d.dll!std::locale::`scalar deleting destructor'(unsigned int) C++
msvcp140d.dll!std::basic_streambuf<wchar_t,std::char_traits<wchar_t>>::~basic_streambuf<wchar_t,std::char_traits<wchar_t>>() Line 68 C++
msvcp140d.dll!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>>::~basic_filebuf<wchar_t,std::char_traits<wchar_t>>() Line 183 C++
msvcp140d.dll!std::`dynamic atexit destructor for 'wfout''() C++
ucrtbased.dll!_execute_onexit_table::__l2::<lambda>() Line 206 C++
ucrtbased.dll!__crt_seh_guarded_call<int>::operator()<void <lambda>(void),int <lambda>(void) &,void <lambda>(void)>(__acrt_lock_and_call::__l2::void <lambda>(void) && setup, _execute_onexit_table::__l2::int <lambda>(void) & action, __acrt_lock_and_call::__l2::void <lambda>(void) && cleanup) Line 204 C++
ucrtbased.dll!__acrt_lock_and_call<int <lambda>(void)>(const __acrt_lock_id lock_id, _execute_onexit_table::__l2::int <lambda>(void) && action) Line 980 C++
ucrtbased.dll!_execute_onexit_table(_onexit_table_t * table) Line 231 C++
msvcp140d.dll!__scrt_dllmain_uninitialize_c() Line 398 C++
msvcp140d.dll!dllmain_crt_process_detach(const bool is_terminating) Line 182 C++
msvcp140d.dll!dllmain_crt_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 220 C++
msvcp140d.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 293 C++
msvcp140d.dll!_DllMainCRTStartup(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 335 C++
ntdll.dll!00007ffefd7e9a1d() Unknown
ntdll.dll!00007ffefd82f1ca() Unknown
ntdll.dll!00007ffefd82ef7d() Unknown
kernel32.dll!00007ffefd6de3eb() Unknown
ucrtbased.dll!exit_or_terminate_process(const unsigned int return_code) Line 144 C++
ucrtbased.dll!common_exit(const int return_code, const _crt_exit_cleanup_mode cleanup_mode, const _crt_exit_return_mode return_mode) Line 282 C++
ucrtbased.dll!exit(int return_code) Line 294 C++
ConsolePP.exe!__scrt_common_main_seh() Line 295 C++
ConsolePP.exe!__scrt_common_main() Line 331 C++
ConsolePP.exe!mainCRTStartup(void * __formal) Line 17 C++
S>>>Ну да, в стандарте на язык програмирования описано то, что частью языка не является. Очевидно же (это сарказм, если что).
K>>Естественно что библиотека не является частью языка
S>Именно поэтому она описана в стандарте языка, ясно-понятно.
То что библиотека где-то описана не делает ее языком. просто потому, что это разные вещи по определению.
Re[13]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>>>Так вот же они родимые: K>>>
std::cout << "A::f()" << std::endl;
K>>>Или по вашему const char[] не голенький указатель?
S>>Нет, это const char[7]. K>Это и есть голенький указатель на строку в сегменте данных.
Когда кажется, что вы уже достигли дна, то вы старательно начинаете копать.
Давайте вам поможем взять новую глубину и возьмем простой пример на C#:
using System;
public class HelloWorld
{
public static void Main(string[] args)
{
Console.WriteLine ("Hello, World");
}
}
Полагаете, использованный здесь строковый литерал не будет затем использован как "голенький указатель на строку в сегменте данных"?
Может он где-то в libastral окажется?
S>>>>А то ведь получается, что работающая программа на C++ без указателей и без ручного управления временем жизни переменных есть, тогда как вы утверждали, все все это неизбежно.
K>Естесвенно. Если рассмотреть эту программу в целом то мы обязательно найдем ручной самописный код в деструкторе
У вас вся программа в целом перед глазами. Ну найдите ручной самописный код в деструкторе.
K>Какая разница кем это написано вами или авторами стандартной библиотеки?
Громадная.
S>>>>Ну да, в стандарте на язык програмирования описано то, что частью языка не является. Очевидно же (это сарказм, если что).
K>>>Естественно что библиотека не является частью языка
S>>Именно поэтому она описана в стандарте языка, ясно-понятно.
K>То что библиотека где-то описана не делает ее языком. просто потому, что это разные вещи по определению.
А я и не утверждал, что "библиотека есть язык". Всего лишь говорю, что существующие стандарты C++ недвусмысленно опровергают ваш высер тезис:
stl которая частью языка не является
Так как вы любите пробивать дно, то попробуйте рассказать, как сделать средствами языка std::launder, например.
Или std::source_location.
Или как компилятору не знать про std::memory_order.
Или как компилятор узнает, что std::malloc начинает life-time для объекта.
Re[14]: #огда коту нечего делать- он пишет sudo на Rust
S>>>Нет, это const char[7]. K>>Это и есть голенький указатель на строку в сегменте данных.
S>Когда кажется, что вы уже достигли дна, то вы старательно начинаете копать.
S>Давайте вам поможем взять новую глубину и возьмем простой пример на C#: S>
S>Полагаете, использованный здесь строковый литерал не будет затем использован как "голенький указатель на строку в сегменте данных"? S>Может он где-то в libastral окажется?
Здесь строковый литерал превратится в объект string и управлять временем жизни этого обьекта программисту не придется.
Т.е. этот char[7] может спокойно принадлежать к любому классу памяти. И после этого вы не утверждаете, что это не голенький указатель? Может быть он не голый в терминологии С++ т.к. имеет модификаторы const и т.п но вы должны понимать что собеседники совершенно не обязаны знать нюансы плюсовой терминологии.
K>>Какая разница кем это написано вами или авторами стандартной библиотеки?
S>Громадная.
И в чем громадная? стандартная библиотека это такой же ручной самописный код котороый может содержать баги и например не освобождать память где требуется вызывая утечку памяти. 100%-й гарантии нет.
S>Так как вы любите пробивать дно, то попробуйте рассказать, как сделать средствами языка std::launder, например. S>Или std::source_location. S>Или как компилятору не знать про std::memory_order. S>Или как компилятор узнает, что std::malloc начинает life-time для объекта.
когда средствами языка нельзя будет сделать например vector тогда обращайтесь. то что нельзя сделать средствами языка является частью языка по определению, а то что делается средствами языка — отдельная библиотечная функциональность которая языком не является. В компиляторах даже опция есть. собирать программу без стандартных библиотек.
Re[8]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>И хвала всевышнему, куча народа имеет возможность зарабатывать на жизнь программизмом не заботясь о вопросах управления памятью и пр. Вопрос в том, что делать с другими задачами, где нужна не только скорость, но и предсказуемость, и контроль за потреблением ресурсов. С простым ответом: не использовать там языки с GC. Так происходит на протяжении полувека, и так же будет происходить и дальше.
Попытаюсь немного убавить градус вашей дискуссии.
А что ты думаешь об эрланге? Я прочитал пару книг по нему и еще по эликсиру. Выглядит очень и очень интересно (я тут запоздал лет на 15). Они заявляют о "мягком режиме реального времени" в языке со сборкой мусора. Ты ведь увлекался ФП. Какие мысли по эрлангу? Понимаю, что язык нишевый и узкоспециализированный.
И кстати, заодно. А что ты думаешь о современных тенденциях в проектировании C++? Не слишком усложняют язык? Я видел многих, кто его использует, максимум, как С++11 с мелкими элементами из C++17, не более. Не отпугивает, что С++ все усложняют и усложняют? К чему это может привести? Не пора ли провести ревизию?
Re[15]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>Здесь строковый литерал превратится в объект string и управлять временем жизни этого обьекта программисту не придется.
Покажите мне, где в моем примере на C++ программисту нужно управлять временем жизни задействованных в коде литералов.
Ответьте номально хотя бы на один из поставленных ранее вопросов, продемонстрируйте, наконец, подтверждение вашим словам "программист вынужден управлять временем жизни каждой переменной".
K>>>Какая разница кем это написано вами или авторами стандартной библиотеки?
S>>Громадная.
K>И в чем громадная?
Хотя бы в том, что часть стандартной библиотеки может быть написана на совсем другом языке.
K>когда средствами языка нельзя будет сделать например vector тогда обращайтесь. то что нельзя сделать средствами языка является частью языка по определению, а то что делается средствами языка — отдельная библиотечная функциональность которая языком не является. В компиляторах даже опция есть. собирать программу без стандартных библиотек.
Бла-бла-бла-бла.
Разговорчивый вы мой, ни одно из ваших словесных испражнений не может перебить того факта, что есть официальный стандарт языка C++, в котором описана и его стандартная библиотека. И нет официальных документов, которые бы описывали язык C++ отдельно как некий язык, частью которого не была бы STL.
Продолжите и дальше демонстрировать свое альтернативное восприятие реальности?
Re[9]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, dsorokin, Вы писали:
D>А что ты думаешь об эрланге?
Интересный нишевый язык. ИМХО, диссертация Джо Армстронга, в которой он описывал свой подход к разработке ПО в присутствии программных ошибок, обязательна к прочтению. Хотя бы для знакомства с принципом fail-fast. Еще неплохо бы прочитать историю Erlang-а от него же для History of Programming Languages.
D>Ты ведь увлекался ФП.
Не особо. Скажем так, попробовал познакомится когда вокруг ФП начинался хайп во второй половине 2000-х. Но не то, чтобы как-то сильно преуспел.
D>Какие мысли по эрлангу?
Наверное, он очень хорош там, где может применяться. Но меня смущает то, что он динамический. Таки чем дальше, тем больше ценю статическую типизацию. Плюс чисто по синтаксису мне больше симпатичен Elixir.
D>И кстати, заодно. А что ты думаешь о современных тенденциях в проектировании C++?
Неоднократно говорил в разных местах и повторю еще раз: у меня есть ощущение, что раньше С++ проектировали люди, гораздо более умные, чем я, но так, чтобы С++ могли пользоваться даже такие как я. Сейчас же C++ развивают люди, гораздо более умные, чем я, но они делают это самих себя. А проблема в том, что они недостаточно умны для этого.
Как говорится, сделать сложно не сложно, сложно сделать просто. Вот сделать просто и не получается.
Другое дело, а можно ли вообще как-то иначе, если поддерживать хорошую совместимость с предыдущими стандартами и в условиях широкой диверсификации языка/библиотек... Т.е. может быть я ругаю, а лучше в принципе не сделать.
D>Не слишком усложняют язык?
Мне не очень понятно, как обучать абсолютных новичков современному C++.
Я-то ладно, потихоньку новое осваиваю. Медленно, со скрипом, но у меня хотя бы есть роскошь делать это итерационно, по чуть-чуть.
А вот как взять вчерашнего PHP-шника или Python-иста, которые может быть когда-то Си видели краем глаза во студенчестве, и обучить современному С++ с шаблонами, концептами и пр. Вот это загадка.
Еще один момент: мне не нравятся некоторые принятые решения. Например, то, что сделали с deducing this. Или предлагаемый сейчас синтаксис для рефлексии с оператором "баян" (т.е. [:|||:]). ИМХО, у кого-то в комитете нет ни чувства стиля, ни чувства меры.
D>Я видел многих, кто его использует, максимум, как С++11 с мелкими элементами из C++17, не более.
Тут есть еще и такой парадокс, что в реальности нужно оглядываться на то, какой стандарт и в какой степени поддерживается компилятором. ИМХО, сейчас делать что-то реально кросс-платформенное на C++20 все еще стремно, на C++17 гораздо безопаснее, а на C++14 еще безопаснее.
Т.е. вроде как на бумаге у нас, у С++ников, есть уже и C++23. На практике же многие ограничены С++17, а некоторые и более древними стандартами.
D>Не отпугивает, что С++ все усложняют и усложняют?
И еще один парадокс: C++ становится все сложнее, а пользоваться им -- все проще.
Прошу заметить, я не говорю, что С++ становится безопаснее. Но вот писать на C++ с каждым новым стандартом становится все проще и приятнее. И делать удается то, что раньше казалось фантастикой.
Наблюдение из практики: когда приходится возвращаться со свежих стандартов на более старые (скажем, после С++20 вернуться на C++17, или после C++17 вернуться на C++14), то начинается ломка от того, что ставшие привычными вещи оказываются недоступны. Например, в C++17 нет operator<=>, а в C++14 нет structured binding.
D>К чему это может привести?
ХЗ, не хочу пытаться предсказать будущее.
D>Не пора ли провести ревизию?
Я вынужден согласиться с той точкой зрения, что если С++ не устраивает, то спокойно можно выбрать другой современный (или не очень) язык. Хороший выбор среди управляемых языков с GC: C#, Java, Kotlin, Go + Scala/OCaml/Haskell для любителей хардкора. Даже среди нативных языков без GC к экзотической Ada уже добавился хайповый Rust.
Мне бы хотелось видеть какой-то cpp2 (вроде того, что делает Саттер): новый язык на тех же идеях и с таким близким синтаксисом, который бы позволял слегка переделать существующие C++ные исходники. Но это был бы именно что другой язык, без попытки сохранить обратную совместимость.
Нужен ли он -- отдельный вопрос. Судя по Carbon-у от Google, кому-то что-то подобное нужно.
Re[10]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, so5team, Вы писали:
S>Я вынужден согласиться с той точкой зрения, что если С++ не устраивает, то спокойно можно выбрать другой современный (или не очень) язык. Хороший выбор среди управляемых языков с GC: C#, Java, Kotlin, Go + Scala/OCaml/Haskell
Java это новый COBOL- это legacy, которые везде в бизнес-приложениях. Почему ты не упомянул Typescript? Ведь можно сколько угодно отпираться, но веб это де-факто UI уже лет 15 как, когда не хочешь геморрой с поддержкой зоопарка платформ. По производительности- хром подтянулся и железо подтянулось.
Re[9]: #огда коту нечего делать- он пишет sudo на Rust
Здравствуйте, Kluev, Вы писали:
K>Без GC и JIT не будет работать компонентная модель, не будут работать некоторые lock free алогритмы основанные на том, что простое присваивание позволяет забыть указатель (В с++ не реализуемо) и другие вещи.
Тут стало интересно
K>Многие вещи которые можно сделать например на C# в языке C++ просто не реализуемы.
Здравствуйте, Kluev, Вы писали:
K>А деструктор вам компилятор написал? В деструкторе вы и управляете временем жизни, решая как и каким способом удалять обьект. Так что без ручного управления никуда.
Здравствуйте, Kluev, Вы писали:
K>И в чем громадная? стандартная библиотека это такой же ручной самописный код котороый может содержать баги и например не освобождать память где требуется вызывая утечку памяти. 100%-й гарантии нет.
Весь C# — это тоже акой же ручной самописный код котороый может содержать баги и например не освобождать память где требуется вызывая утечку памяти. 100%-й гарантии нет.
K>когда средствами языка нельзя будет сделать например vector тогда обращайтесь. то что нельзя сделать средствами языка является частью языка по определению, а то что делается средствами языка — отдельная библиотечная функциональность которая языком не является.
