Здравствуйте, Mazay, Вы писали:
M>Линус довыпендривается. Вот перепишут ядро на чем-нибудь функциональном, тогда будет ему и контекст, и GC, и конкурнетность
Скажите пожалуйста, а когда наконец перепишут? Можно ли надеяться на то, что к концу июня? Извиняюсь, что влез, но от Вашего ответа зависит многое.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, CrystaX, Вы писали:
ГВ>>>Конечно, к концу июня всё будет готово. Только не известно, какого года. А так — сто пудов! CX>>Проклятье! Но скажите все же, совсем никакой надежды на текущий год нет? Боже, что же делать! Пойду, выпью валерьянки...
ГВ>Ну, до 30-го ещё далеко. Ты же знаешь, что функциональные языки (неужели немерле?!) настолько сильно поднимают производительность труда программистов, что за этот краткий период всё может случиться.
Здравствуйте, Nuzhny, Вы писали:
N>А может: "сложное — враг простого"?
Нет, не может. У сложного и простого гораздо более сложные взаимоотношения. До определенного предела сложное — друг простого, а вот потом их пути расходятся. Дело в том, что мы не можем получить простоту за бесплатно. Нам приходиться как-то перераспределять сложность. На простом языке простую программу не написать. Брейнфак, например, простой язык, но программы на нем написанные — очень сложны для восприятия.
Для того, чтобы написать простую программу нужен язык посложнее. Принцип прост и универсален. Вот есть у нас уравнения Максвелла, записанные покомпонентно — огромное, уродливое нагромаждение элементарных вещей. Чтобы это все как-то обозреть глазами за раз, нужно уже что-то знать. Векторы, например. Уже выглядит проще. Если знать дифоператоры, можно еще проще записать. С четырехвекторами и оператором Даламбера получиться еще более изящная и компактная запись, ну а со звездой Ходжа — уже лучше некуда.
Линус, по всей видимости, таких простых вещей не понимает. Если отвертка проще шуруповерта — это не значит, что завернуть 1000 шурупов проще отверткой. Как раз наоборот.
Тот же C только на то и годиться, чтобы развести грязь на сто экранов, там где в нормальном языке можно было бы обойтись и несколькими строками. Язык это очень слабый. Плюсами, разумеется, легко злоупотребить, но там уже есть кое-какие выразительные средства и можно худо-бедно писать код более понятный, чем на C. Понятно, что язык с выразительными возможностями C++ мог быть существенно проще, т.е. в данном случае мы покупаем выразительность не по самой выгодной цене, но это уже другая история.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, z00n, Вы писали:
Z>Торвальдс не устает объяснять почему ему не нравится C++ — видно сильно давят
Новых аргументов у него почти и нет. "Зависимость от контекста" может быть и в С, его вариант будет только не someProtocol->connect(), а someProtocol->vtbl->connect(someProtocol). Всё остальное — то же самое.
Всё остальное — тоже вопрос.
Я реально вижу, что на практике С++ существенно продуктивнее в открытых проектах, чем С на примере KDE и QT против GTK.
Здравствуйте, CrystaX, Вы писали:
M>>Линус довыпендривается. Вот перепишут ядро на чем-нибудь функциональном, тогда будет ему и контекст, и GC, и конкурнетность CX>Скажите пожалуйста, а когда наконец перепишут? Можно ли надеяться на то, что к концу июня? Извиняюсь, что влез, но от Вашего ответа зависит многое.
Конечно, к концу июня всё будет готово. Только не известно, какого года. А так — сто пудов!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Планирую свой летний отпуск. В ходе разработки алгоритма выяснилось. что мне надо быстро добраться из Внуково в Домодедово.
Поискал в Интернете — все советуют через Москву, дальше разные варианты. Мне это не по душе, почему нет автобуса ? Ищу дальше. И вдруг натыкаюсь на такое
/////////////////////////////////
4 Сент, 2030 at 9:58 AM
В последние годы с помощью экспрессов и городских электричек удалось создать хорошую связь не только всех трех аэропортов Москвы с центром города, но и связать между собой Внуково и Шереметьево, Шереметьево и Домодедово. Однако чтобы проехать из Внуково в Домодедово, нужно было заезжать в город и делать пересадку около Москва-Сити. При этом напрямую расстояние между двумя аэропортами намного меньше.
Несколько лет назад правительство Московского края приняло решение соединить Внуково и Домодедово скоростными поездами на магнитной подушке, способные развивать скорость до 400-450 км/ч. В качестве прототипа была взята немецкая система Трансрапид, которая хорошо зарекомендовала себя в Шанхае и в других местах. Систему адаптировали к условиям русской зимы: пути скоростного поезда, пролегающие полностью на эстакаде, были накрыты коробом, защищающим их от снега; были также сделаны специальные отверстия, уменьшающие сопротивление воздуха и шум
Здравствуйте, CrystaX, Вы писали:
M>>Линус довыпендривается. Вот перепишут ядро на чем-нибудь функциональном, тогда будет ему и контекст, и GC, и конкурнетность
CX>Скажите пожалуйста, а когда наконец перепишут? Можно ли надеяться на то, что к концу июня? Извиняюсь, что влез, но от Вашего ответа зависит многое.
and it turns out that getting good results from SHA1 really is mostly about trying to fight the compilers tendency to try to be clever.
Для меня SHA1 очень показателен оказался. Пересмотрел несколько жутких реализаций на макросах С, с ручным разворачиванием циклов, а потом тупо написал (на С++, но не суть) обычный алгоритм который их все и порвал Времена меняются, но не все мы меняемся вместе с ними.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, CrystaX, Вы писали:
ГВ>>Конечно, к концу июня всё будет готово. Только не известно, какого года. А так — сто пудов! CX>Проклятье! Но скажите все же, совсем никакой надежды на текущий год нет? Боже, что же делать! Пойду, выпью валерьянки...
Ну, до 30-го ещё далеко. Ты же знаешь, что функциональные языки настолько сильно поднимают производительность труда программистов, что за этот краткий период всё может случиться. Ведь функциональные языки — это не какой-то там гламурный новомодный недо-ассемблер Си, а Настоящее Дыхание Седой Старины, от Настоящих Мастеров, которые делали Настоящие Вещи. А с другой стороны — что для них плюс-минус десятилетие? Пыль на сапогах! В общем, прекрати суетиться.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Lorenzo_LAMAS, Вы писали:
C>>Новых аргументов у него почти и нет. "Зависимость от контекста" может быть и в С, его вариант будет только не someProtocol->connect(), а someProtocol->vtbl->connect(someProtocol). Всё остальное — то же самое. L_L>А что, Линукс в таком стиле пишут?
Местами — да.
C>>Всё остальное — тоже вопрос. C>>Я реально вижу, что на практике С++ существенно продуктивнее в открытых проектах, чем С на примере KDE и QT против GTK. L_L>А я на _моей_ практике вижу, что Линус (ИМХО) прав (хотя бы в этом частном случае) — наличие перегрузки, наличие преобразований, (есть они и в С, конечно, но не так все драматично) накрученного поиска имен и.т.п. и т.д. прибавьте еще всякие АДЛи до кучи — реально делает код неоднозначным и чтение и понимание его сложнее, чем в С.
Решается вменяемыми code style'ами. Я прекрасно вижу как LLVM, где используется вменяемое подмножество С++, намного приятнее gcc с его чистым С. Просто в ядре нет большого количества алгоритмически- и структурно-сложного кода.
D>в С++ есть локальные структуры (с методами), что еще мощнее
Слабее, вернее гораздо менее удобны, так как из них невозможен прямой доступ к окружающим локальным
переменным. Локальные же методы в gcc или паскале такой доступ дают и по удобству близки к замыканиям.
Здравствуйте, z00n, Вы писали:
Z>Торвальдс не устает объяснять почему ему не нравится C++ — видно сильно давят Z>c++ productivity
А может сразу в КСВ? Хотя вброс слабоват.
Здравствуйте, z00n, Вы писали: Z>Торвальдс не устает объяснять почему ему не нравится C++ — видно сильно давят Z>c++ productivity
Кстати, интересно было бы поглядеть на аргументы с другой стороны, в пользу С++. Не осилил всю ветку по ссылке, но они вроде на уровне "почему бы и нет".
Здравствуйте, dilmah, Вы писали: D>в С++ есть полезная фича -- локальные классы, с помощью них можно делать функции, локальные в другой функции, а также делать элегантный cleanup.
А пример (уместного использования) можно?
То, что могло бы называться "локальными функциями" поддерживается для С в гцц и, емнип, в ядре используется.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну, до 30-го ещё далеко. Ты же знаешь, что функциональные языки настолько сильно поднимают производительность труда программистов, что за этот краткий период всё может случиться. Ведь функциональные языки — это не какой-то там гламурный новомодный недо-ассемблер Си, а Настоящее Дыхание Седой Старины, от Настоящих Мастеров, которые делали Настоящие Вещи. А с другой стороны — что для них плюс-минус десятилетие? Пыль на сапогах! В общем, прекрати суетиться.
Да, Вы правы, конечно же... И все же это так трудно — расставаться с мечтой! Ведь я надеялся, верил, что еще чуть-чуть, и ядро Линукс будет переписано! И ведь это так просто — достаточно использовать Правильные Инструменты (с). Уже не раз высказывалось такое мнение. Но, видимо, нет — не судьба. Быть может, дети... Или внуки... Им достанется то прекрасное, ради достижения которого мы терпим весь этот legacy груз... Эх...
Здравствуйте, CrystaX, Вы писали:
CX>Да, Вы правы, конечно же... И все же это так трудно — расставаться с мечтой!
Ну зачем же расставаться...
CX>Ведь я надеялся, верил, что еще чуть-чуть, и ядро Линукс будет переписано! И ведь это так просто — достаточно использовать Правильные Инструменты (с). Уже не раз высказывалось такое мнение. Но, видимо, нет — не судьба. Быть может, дети... Или внуки... Им достанется то прекрасное, ради достижения которого мы терпим весь этот legacy груз... Эх...
...операционные системы на Лиспе уже давно есть, просто они не называются Юниксом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, c-smile, Вы писали:
CS>А вот можно чтобы не только функционально было, но и классно? Вместе, никак? CS>Шо, блин, за жизнь ...
Не-не-не, Дэвид Блэйн, только демократичная бесклассовая функциональщина спасёт мир!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну зачем же расставаться...
ГВ>...операционные системы на Лиспе уже давно есть, просто они не называются Юниксом.
Нет-нет, не пытайтесь меня утешить... Вы все равно не сможете... Ведь если бы... А впрочем... Нет, прочь, прочь!
Ну на самом деле это особенно и операционной системой наверное не называется.
Лисп-машиной называется. Но ещё прикол в том, что Лисп -- это не функцианальный
язык, а гибридный с возможностью написания и в функциональном стиле. Автор
стенаний видимо всё же имел в виду чистые функциональные языки.
Mr.Cat,
D>>в С++ есть полезная фича -- локальные классы, с помощью них можно делать функции, локальные в другой функции, а также делать элегантный cleanup. MC>А пример (уместного использования) можно? MC>То, что могло бы называться "локальными функциями" поддерживается для С в гцц и, емнип, в ядре используется.
Подожди, можно определять функции внутри функций?
int my_cool_fucn()
{
int a = 22;
int local_xxx()
{
return a;
}
return local_xxx();
}
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Mr.Cat,
D>>>в С++ есть полезная фича -- локальные классы, с помощью них можно делать функции, локальные в другой функции, а также делать элегантный cleanup. MC>>А пример (уместного использования) можно? MC>>То, что могло бы называться "локальными функциями" поддерживается для С в гцц и, емнип, в ядре используется.
LCR>Подожди, можно определять функции внутри функций? LCR>
LCR>int my_cool_fucn()
LCR>{
LCR> int a = 22;
LCR> int local_xxx()
LCR> {
LCR> return a;
LCR> }
LCR> return local_xxx();
LCR>}
LCR>
LCR>:wow:
Конкретно так делать некорректно, будет неопределённое поведение: локальные функции захватывающие локальные переменные лучше не возвращать. Зато их можно передавать параметром при вызове.
Здравствуйте, dilettante, Вы писали:
D>Конкретно так делать некорректно, будет неопределённое поведение: локальные функции захватывающие локальные переменные лучше не возвращать. Зато их можно передавать параметром при вызове.
Например, так:
#include <stdio.h>
void map_int(int arr[], size_t const size, int (*f)(int))
{
for (size_t i = 0; i < size; i++)
arr[i] = f(arr[i]);
}
int main()
{
size_t const s = 5;
int array[5] = {1,2,3,4,5};
map_int(array, s, ({ int lambda(int x) { return x+1; }; lambda; }));
map_int(array, s, ({ int lambda(int x) { printf("%d ",x); return x; }; lambda; }));
return 0;
}
C>Новых аргументов у него почти и нет. "Зависимость от контекста" может быть и в С, его вариант будет только не someProtocol->connect(), а someProtocol->vtbl->connect(someProtocol). Всё остальное — то же самое.
А что, Линукс в таком стиле пишут?
C>Всё остальное — тоже вопрос.
C>Я реально вижу, что на практике С++ существенно продуктивнее в открытых проектах, чем С на примере KDE и QT против GTK.
А я на _моей_ практике вижу, что Линус (ИМХО) прав (хотя бы в этом частном случае) — наличие перегрузки, наличие преобразований, (есть они и в С, конечно, но не так все драматично) накрученного поиска имен и.т.п. и т.д. прибавьте еще всякие АДЛи до кучи — реально делает код неоднозначным и чтение и понимание его сложнее, чем в С.
Of course, the code must be complete enough to compile and link.
Вы не совсем правы. Это не C, это его расширение в GCC. Так можно взять майкрософтовское расширение C++/CLI и сказать что C++ полностью динамический ^_^.
EOH>Вы не совсем правы. Это не C, это его расширение в GCC. Так можно взять майкрософтовское расширение C++/CLI и сказать что C++ полностью динамический ^_^.
Здравствуйте, z00n, Вы писали:
Z>Торвальдс не устает объяснять почему ему не нравится C++ — видно сильно давят Z>c++ productivity
Да ну, любая технология будучи использованной неправильно способна принести больше вреда чем пользы.
Я бы сказал что чувак просто не верит собственным сотрудникам, что они сособны сами отличить плохое от хорошего
Знаете, если бы у меня не было опыта программирования на C++, я бы сказал, что Линус бредит. А так говорю, что он в чем-то прав. А если еще учесть, что у Линукса и так дела идут весьма неплохо, то он вообще прав. Как говорится, лучшее — враг хорошего. Не стоит улучшать то, что и так хорошо работает.
Я бы вообще сказал, что успех Линукса — это, в какой-то мере, чудо. Я вот не могу рационально объяснить, почему весь этот оупенсорсный процесс так хорошо работает. Так что Линус трижды прав, что не стоит слишком теребить эту волшебную конструкцию.
Здравствуйте, Klapaucius, Вы писали:
K>Тот же C только на то и годиться, чтобы развести грязь на сто экранов, там где в нормальном языке можно было бы обойтись и несколькими строками. Язык это очень слабый. Плюсами, разумеется, легко злоупотребить, но там уже есть кое-какие выразительные средства и можно худо-бедно писать код более понятный, чем на C. Понятно, что язык с выразительными возможностями C++ мог быть существенно проще, т.е. в данном случае мы покупаем выразительность не по самой выгодной цене, но это уже другая история.
Приходилось как то писать кусок кроссплатформенного кода на Plain С.
Проклял и Plain С и кроссплатформенность.
Очень сильно не хватало RAII и шаблонных контейнеров.
Про кроссплатформенность вообще отдельные матюки.
Здравствуйте, Klapaucius, Вы писали:
K>Линус, по всей видимости, таких простых вещей не понимает. Если отвертка проще шуруповерта — это не значит, что завернуть 1000 шурупов проще отверткой. Как раз наоборот.
Не, он понимает. Просто ему больше нравится подход с отвёртками.
Some people seem to think that C is a real programming language, but they are sadly mistaken. It really is about writing almost-portable assembly language, and it turns out that getting good results from SHA1 really is mostly about trying to fight the compilers tendency to try to be clever.
Для ядра системы такой подход вполне применим. Ну нет почти там мест, где что-то сложное нужно.
LCR>>int my_cool_fucn()
LCR>>{
LCR>> int a = 22;
LCR>> int local_xxx()
LCR>> {
LCR>> return a;
LCR>> }
LCR>> return local_xxx();
LCR>>}
LCR>>
LCR>>
D>Конкретно так делать некорректно, будет неопределённое поведение: локальные функции захватывающие локальные переменные лучше не возвращать.
Дык функцию и нельзя вернуть (это не first-class object), максимум — её адрес. А в данном случае возвращается результат функции — копия локальной переменной, не вижу проблем.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Mr.Cat, Вы писали:
MC>Кстати, интересно было бы поглядеть на аргументы с другой стороны, в пользу С++. Не осилил всю ветку по ссылке, но они вроде на уровне "почему бы и нет".
Скорее на уровне:
— А можно ли использовать С++ в прицнипе?
— Нет, не хватает того-то, поскольку нам это не нужно (и оператор new — идиотизм).
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Чем больше колупаюсь с нашим монструозным фреймворком-выродком на С++, тем чаще подобные мысли приходят в голову.
