Исправление www_linux_org_ru, (текущая версия) :
* Преимущество разделяемых данных при обмене между потоками мнимое, поскольку современные процессоры имеют большой раздельный кеш для каждого ядра. Поэтому будем копировать данные между потоками. Отсюда, в частности, immutable.
вот эта часть с immutable, pure, с натяжкой может быть признана исследовательской частью языка (с натяжкой — т.к. результаты исследования пишет eao193 здесь, а не сами исследователи)
плюс к этому исследование на уровне детского сада — общего эффект полиморфизма нет, есть только частные случаи
но да, изучать то, что они там делают — *определенно* имеет смысл ради интересных идей
* Явная работа с указателями есть зло всегда, кроме особо системных случаев. Поэтому синтаксис должен быть построен так, чтобы обычный несистемный программист указателей не видел.
как показал опыт явы, слабые ссылки *нужны* в обычном прикладном программировании (другое дело, что синтаксис gc ссылок может быть короче и удобнее, чем ссылкок других типов)
* Шаблоны должны быть простыми и понятными, иначе ими никто не станет пользоваться, кроме некоторых любителей и сильно матёрых гуру. Но этих людей мало. Если же многие не станут пользоваться шаблонами, будет свалка.
ну да, это заусенцы с++, убранные напильником
* У большинства базовых вариантов: массивов, ассоциативных массивов (словарей), кортежей, строк и прочих комплексных чисел должна быть одна стандартная реализация. Её отсутствие или недостаточная проработанность ведёт к зоопарку (что мы уже видели даже на примере самого D1 с двумя «стандартными» библиотеками).
ммм... а разве не у *Д2* 2 стандарнтых библиотеки?
* Сборщик мусора должен быть и должен быть включён по умолчанию. Если вы такой джедай, что он вам не нужен, вы его выключаете и работаете, как хотите. При этом на вас смотрят либо как на прокажённого, либо как на святого (иногда эти понятия пересекаются). Потому что иначе память будет течь (все мы грешны). Это не значит, что сборщик мусора не может ошибаться, но исправить 1 сборщик мусора всегда проще/лучше, чем править 100500 написанных без него программ.
сборщик мусора должен быть (но без слабых ссылок память все равно будет течь и с ним)
* unittest должны быть встроены в те модули, где написан сам тестируемый код, иначе они теряются и на них все забивают. Их включение/исключение из проекта регулируется ключом компиляции...
мелкое консервативное расширение с++
Исходная версия www_linux_org_ru, :
* Преимущество разделяемых данных при обмене между потоками мнимое, поскольку современные процессоры имеют большой раздельный кеш для каждого ядра. Поэтому будем копировать данные между потоками. Отсюда, в частности, immutable.
вот эта часть с immutable, pure, с натяжкой может быть признана исследовательской частью языка (с натяжкой — т.к. результаты исследования пишет eao193 здесь, а не сами исследователи)
плюс к этому исследование на уровне детского сада — никакого эффект полизморфизма нет
но да, изучать то, что они там делают — *определенно* имеет смысл ради интересных идей
* Явная работа с указателями есть зло всегда, кроме особо системных случаев. Поэтому синтаксис должен быть построен так, чтобы обычный несистемный программист указателей не видел.
как показал опыт явы, слабые ссылки *нужны* в обычном прикладном программировании (другое дело, что синтаксис gc ссылок может быть короче и удобнее, чем ссылкок других типов)
* Шаблоны должны быть простыми и понятными, иначе ими никто не станет пользоваться, кроме некоторых любителей и сильно матёрых гуру. Но этих людей мало. Если же многие не станут пользоваться шаблонами, будет свалка.
ну да, это заусенцы с++, убранные напильником
* У большинства базовых вариантов: массивов, ассоциативных массивов (словарей), кортежей, строк и прочих комплексных чисел должна быть одна стандартная реализация. Её отсутствие или недостаточная проработанность ведёт к зоопарку (что мы уже видели даже на примере самого D1 с двумя «стандартными» библиотеками).
ммм... а разве не у *Д2* 2 стандарнтых библиотеки?
* Сборщик мусора должен быть и должен быть включён по умолчанию. Если вы такой джедай, что он вам не нужен, вы его выключаете и работаете, как хотите. При этом на вас смотрят либо как на прокажённого, либо как на святого (иногда эти понятия пересекаются). Потому что иначе память будет течь (все мы грешны). Это не значит, что сборщик мусора не может ошибаться, но исправить 1 сборщик мусора всегда проще/лучше, чем править 100500 написанных без него программ.
сборщик мусора должен быть (но без слабых ссылок память все равно будет течь и с ним)
* unittest должны быть встроены в те модули, где написан сам тестируемый код, иначе они теряются и на них все забивают. Их включение/исключение из проекта регулируется ключом компиляции...
мелкое консервативное расширение с++