Здравствуйте, Воронков Василий, Вы писали:

C>>Это уродец для задач общего назначения. Причины:
C>>1) Нет типобезопасности.
ВВ>Сдается мне, что ты путаешь типобезопасность со статической типизацией. Руби тоже нетипобезопасный по твоему?
Не придирайся к словам, я имел в виду статическую типизацию. Но, кстати, Objective C ещё и нетипобезопасен.

Здравствуйте, BlackEric, Вы писали:

BE>Ага. Только Mono из всех линуксовых дистрибов кроме Novell пытаются вытравить.

Чушь это. Даже если Моно будет ставиться отдельно от этого он не исчезнет.

Его реальные проблемы — это не полная библиотека, отставание в фичах и (пожалуй, главное) отставание в производительности.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>NSArray просто принципиально полиморфен, так сказать, но можно описать свой, который будет вполне себе статически типизированным.
C>>Контейнеров значений в принципе ты не сделаешь в ObjectiveC.
ВВ>Не понял, что мешает?
Объекты Objective-C не имеют семантики value-объектов. Так что в контейнер значений их можно разве что только грязными хаками положить.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Как так? По всем признакам на Джаве, JRE запускается и все такое. Может, там не все на Джаве, конечно. Тут не знаю, не проверял.

Не он нэйтивный (С++ кажется). Ява там для разных примочек. Скрипты, например.

Здравствуйте, Mystic, Вы писали:

M>Не, некоторые вещи писать тяжело. Во-первых, напрягает постоянно вставлять unsafe. Плюс часто генерируется ужасный код.

И много раз в жизни ты unsafe вставлял?
Я вот раза три. И все в тестах.

Здравствуйте, VladD2, Вы писали:

VD>Меня интересуют термины:
VD>* Системный.
VD>* Эффективный.
VD>* Высокоуровневый.

VD>Прямая манипуляция памятью (наплевательское отношение на типы) — это ситемно, эффекитвно, высокоуровнево?

Я здесь не вижу строгой дизьюнкции. К примеру, высокоуровневый язык может включать в себя некоторый явно выделенный сабсет, который предоставляет низкоуровневые средства — та же прямая работа с памятью. Я тут проблемы в общем-то не вижу. Даже в C# без всяких ансейфов можно память попортить, как говорится, было бы желание.

VD>А автоматическое управление памятью — это обязательно не системно и не эффективно?

В ряде случаев — да, неэффективно.
Ты будешь смеяться, но одна из вещей, которые мне нравились в CLI, это возможность явно сказать, как я хочу создать объект — если расширить это, то программист просто будет указывать, в каком хипе объект создается (и в хипе ли вообще). И волки сыты, и овцы целы. Нет?

VD>А поддержка ФП — это не сисемно, и не эффективно?

ФП тут вообще ортогонально.

VD>Что за системные задачи предполагается решать на языке, если это не написание ОС?

Написание ОС (необязательно ядра) — очень хороший пример такой задачи. Любые задачи, где требуется эффективность — от кодеков до виртуальных машин. Кто во что горазд.

Здравствуйте, VladD2, Вы писали:

ВВ>>Как так? По всем признакам на Джаве, JRE запускается и все такое. Может, там не все на Джаве, конечно. Тут не знаю, не проверял.
VD>Не он нэйтивный (С++ кажется). Ява там для разных примочек. Скрипты, например.

Ну вот, а он для меня был практически иконой "прямого" десктопа на Джаве. Эх, теперь один Эклипс остается. Он-то не на С++, надеюсь?

Здравствуйте, Mystic, Вы писали:

M>Ну уж точно код вроде этого
M>

            System.Drawing.Color Color = System.Drawing.Color.Black;
M>            if (Color == System.Drawing.Color.Black)
M>                System.Console.WriteLine("Catastrophic execution");
M>

M>Не будет скомпилирован как
M>

M>;            System.Drawing.Color Color = System.Drawing.Color.Black;
M>0000005c  lea         rcx,[rsp+40h] 
M>00000061  call        FFFFFFFFF5A8CBF0 
M>00000066  mov         qword ptr [rsp+000000D0h],rax 
...
M>

Юморист, блин. Ты так не шути. Пупки у людей лопнут. Для начала научись получать реальный асм в релизе и без отладки. Тогда он будет выглядеть совсем по другому.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

ВВ>>Но, кстати, тут бы определиться — шаблоны и статическая типизация вообще не очень дружат.

LCR>Что-то новенькое...

Они конечно дружат. Но в том виде как они сделаны в С++ в результате дружбы получается бардак.

Здравствуйте, VladD2, Вы писали:

VD>А автоматическое управление памятью — это обязательно не системно и не эффективно?
Да. Впрочем, как раз Ржавчина может и будет жить — там каждый поток получает свою арену для GC.

VD>А поддержка ФП — это не сисемно, и не эффективно?
Обычно более-менее сильный ФП требует наличие GC, что см. выше.

VD>Что за системные задачи предполагается решать на языке, если это не написание ОС?
Написание браузера. Написание быстрого HTTP-сервера или там MapReduce-какой. Потребностей много.

Здравствуйте, VladD2, Вы писали:

VD>А куда делись сотни метров W??-ов (WPF, WWF, ...)?
VD>И какие проблемы в наше время даже 2 гига скачать? Я вот периодически покачиваю фильмы в HD-форматах. И ничего так.
На Андроиде и iPhone всего 256Мб памяти, к примеру. Совсем много туда не засунешь.

Здравствуйте, Курилка, Вы писали:

К>LtU сообщает о языке Rust, разрабатываемым Mozilla (среди контрибьюторов небезызвестный Brendan Eich), позиционируемым как системный язык программирования с интересным набором фич.
К>Снова стало модным придумывать новые языки? (в голову почти сразу приходит ещё свежий гугловский Go)

Интересная ссылка. Ну, а создание "системных языков с простым синтаксисом и поддержкой многопоточности" пожалуй уже тенденция.

На мой взгляд бредовая тенденция. Люди понимают, что им не нужен С++ и С, но еще не понимаю, а что же им реально нужно.

На мой взгляд на рынке не нужны новые системные языки. Нужно брать языки которые пробили себе дорогу в "несистемном" мире и адаптировать их к тем потребностями которые подразумеваются под термином "системность". Уверен, что этот термин многие понимают по разному.

Отличной работой по "системизации" низкоуровневого языка является Сигулярити и СингШарп. Мне кажется такие языки как Шарп, ОКамл, Скала, Хаскель и Немерле спокойно можно "системизировать".

Вот только раньше я понимал термин "системные язык" как язык для написания ОС. Но в ближайшее время новых ОС похоже не привидится. Даже новая ОС Андройд — это старый добрый (а для кого не очень) Линукс. Перспективные работы по написанию ОС как раз ведутся на управляемых языках (и их адаптациях).

Так что народ снова делает мухослонопатамов. Если кому-то нужен упрощенный С++, то берите Ди. Если что его можно доработать. Это все равно проще чем клепать свои поделки.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>бред полнейший.

На этом можно и закончить эту познавательную беседу.

BZ>просто в 80-е ява ввела моду на использование байт-кода.

Если ты помнишь, Ява вообще родилась как попытка сановских товарищей создать свой "идеальный С++" для разработки каких-то там проектов.

BZ>никаких принципиальных изменений он не даёт, всё то же прекрасно работает хоть с ним, хоть без него.

Новых идей там наверно вовсе не было. Но в том виде нигде этого еще не было. Типобезопаность и автоматическое управление памятью были больше в динамических языках. Идеи создать большую универсальную стандартную библиотеку и та был новинкой для компилируемых языков.

Конечно были разные маргинальные направления и язки, но они не были доступны массам. Массы же жили С++-ом, С-ями, Дельфями, ну еще быть может Обжектив-С-ями (немного).

BZ> а байт-код использовался для реализации и паскаля,

Да байткод тут не самое важное. Это часть иделогии бинарной переносимости. Но на мой взгляд это был больше рекламмный ход нежели очень нужная идея.

BZ>и смолтока, и бейсика — вы просто не знаете историю ФП

Не хуже тебя знаю. Расписать тебе что в упомянутых языках не вписывается в упомянутые концепции? Думаю, не надо. Ты и сам прекрасно знаешь.

Кстати, первое упоминание о дотнете во внешних источниках было очень забавным (на сегодня). Там речь шла о новой версии COM+ и ВБ. А в итоге получилась Ява.

Здравствуйте, VladD2, Вы писали:

BZ>>просто в 80-е ява ввела моду на использование байт-кода.
VD>Если ты помнишь, Ява вообще родилась как попытка сановских товарищей создать свой "идеальный С++" для разработки каких-то там проектов.
Это ты плохо помнишь. Ява родилась как высокоуровневый кроссплатформенный язык для встраиваемых приложений (в основном для приставок к телевизорам). Идеальный С++ они делать не собирались.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я здесь не вижу строгой дизьюнкции. К примеру, высокоуровневый язык может включать в себя некоторый явно выделенный сабсет, который предоставляет низкоуровневые средства — та же прямая работа с памятью. Я тут проблемы в общем-то не вижу. Даже в C# без всяких ансейфов можно память попортить, как говорится, было бы желание.

А я даже не вижу зачем нужен этот низкоуровневый сабсет. Все что нужно можно оформить функциями применение который сильно оптимизировать (переписывать в эффективный код).

VD>>А автоматическое управление памятью — это обязательно не системно и не эффективно?

ВВ>В ряде случаев — да, неэффективно.

Да ну? У нас острая нехватка памяти?

ВВ>Ты будешь смеяться, но одна из вещей, которые мне нравились в CLI, это возможность явно сказать, как я хочу создать объект — если расширить это, то программист просто будет указывать, в каком хипе объект создается (и в хипе ли вообще). И волки сыты, и овцы целы. Нет?

Нет. Это все попытка поручить человеку работу машины. Лучше сосредоточиться на том, чтобы машина сама выбирала правильное место.

VD>>А поддержка ФП — это не сисемно, и не эффективно?

ВВ>ФП тут вообще ортогонально.

Да ну? А вот многие сишники считаеют, что ФП вреден для системности и производительности. (не я)

VD>>Что за системные задачи предполагается решать на языке, если это не написание ОС?

ВВ>Написание ОС (необязательно ядра) — очень хороший пример такой задачи.

А что за ОС-то на них хотят писать?

ВВ> Любые задачи, где требуется эффективность — от кодеков до виртуальных машин. Кто во что горазд.

Вот это полнейшая чушь. Нет в этих задачах ничего чтобы нельзя было решить без ручного манипулирования байтами в памяти. Потом задач таких мало, и задачи эти даже на С решаются вполне не плохо.

Вот тут кое-кто спорил о том что С мол плох по сравнению с С++. Ага плохо, если его рассатривать как универсальный современный язык. Но С — это ассемблер современности. Он как раз для манипуляции байтами и предназначен. Не надо на нем сложную логику не связанную с манипуляцией памятью писать и все будет ОК.

А для сложной логики языки уже созданы.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну вот, а он для меня был практически иконой "прямого" десктопа на Джаве. Эх, теперь один Эклипс остается. Он-то не на С++, надеюсь?

Нет. Эклпис чисто явский. Хотя движок графики у него вроде бы тоже С-ишный (IBM писал для скоросоти).

И, кстати, на мой взгляд Эклипс намного качественнее и расширяемее нежели ОпенОфис.

Здравствуйте, Cyberax, Вы писали:

VD>>А автоматическое управление памятью — это обязательно не системно и не эффективно?
C>Да. Впрочем, как раз Ржавчина может и будет жить — там каждый поток получает свою арену для GC.

А как же Сингулярити работает?

VD>>Что за системные задачи предполагается решать на языке, если это не написание ОС?
C>Написание браузера. Написание быстрого HTTP-сервера или там MapReduce-какой. Потребностей много.

И вот же блин незадача, как раз в тесте HTTP-сервера Сингулярити порвала Линукс и Винду :о).

Писать браузеры на управляемых языка очень даже можно. Один хрен они теперь нужны только для представления ХТМЛ-я в виде ОО-медели. Что же до эффективности, то когда я смотрю на то как тормозит и жрет память ФайрФокс (вот сейчас 250 метров памяти и постоянные подтормаживания), то невольно возникает мысль "почему его на явае или дотете не переписали?".

Здравствуйте, Cyberax, Вы писали:

VD>>И какие проблемы в наше время даже 2 гига скачать? Я вот периодически покачиваю фильмы в HD-форматах. И ничего так.
C>На Андроиде и iPhone всего 256Мб памяти, к примеру. Совсем много туда не засунешь.

Наверно по этому на андройде Ява-апи такой широкий?

Я тебе напомню, что когда появлялась Ява на писюках было по 32 Мб памяти. Так что 256 это не так плохо, если вспомнить, что это все же телефон.

К тому же тенденция то видна. Сейчас уже лучшие сабаководы ставят 288 Мб. А скоро и гиг будут пихать.

Ну, и давай заметим, что языки эти новомодные создаются далеко не для писательства софта для телефонов. Там как раз скорее ява с дотентом будет.

Что у нас там осталось? Ах, да! Микроконтроллеры! Слушаю ваш рассказ о них .

Здравствуйте, Cyberax, Вы писали:

C>Это ты плохо помнишь. Ява родилась как высокоуровневый кроссплатформенный язык для встраиваемых приложений (в основном для приставок к телевизорам). Идеальный С++ они делать не собирались.

Не. Я вроде бы хорошо помню. Но это замечание очень в жилу в контексте твоего вот этого замечания

Автор: Cyberax
Дата: 10.07.10

.

Здравствуйте, VladD2, Вы писали:

VD>А я даже не вижу зачем нужен этот низкоуровневый сабсет. Все что нужно можно оформить функциями применение который сильно оптимизировать (переписывать в эффективный код).

Не понял, какое применение оформить функциями?

VD>>>А автоматическое управление памятью — это обязательно не системно и не эффективно?
ВВ>>В ряде случаев — да, неэффективно.
VD>Да ну? У нас острая нехватка памяти?

Дело не только в количестве, в том, что GC-онли языки полностью изолируют программиста от всяких деталей работы с памятью. И да, иногда это неприемлимо. Mark and sweep может спокойно так захлебнуться в ситуациях, когда есть много корней, так зачем себе жизнь усложнять? А главное — ради чего, собственно, делается это GC-онли? От чего пытаются предостеречь? delete вызвать? От детерминированного уничтожения ресурсов вот никто не умер.

ВВ>>Ты будешь смеяться, но одна из вещей, которые мне нравились в CLI, это возможность явно сказать, как я хочу создать объект — если расширить это, то программист просто будет указывать, в каком хипе объект создается (и в хипе ли вообще). И волки сыты, и овцы целы. Нет?
VD>Нет. Это все попытка поручить человеку работу машины. Лучше сосредоточиться на том, чтобы машина сама выбирала правильное место.

А кто будет сосредотачиваться? И почему машина за меня должна решать такие вещи? И как она их будет решать?

VD>>>А поддержка ФП — это не сисемно, и не эффективно?
ВВ>>ФП тут вообще ортогонально.
VD>Да ну? А вот многие сишники считаеют, что ФП вреден для системности и производительности. (не я)

Ну скажем так, если ты дашь емкое и полное определение того, что такое ФП, то тут появится какой-то предмет для разговора. Для меня ФП это "первоклассные функции и декларативность", а это слишком общая формулировка для того, чтобы выносить какие-то решения. Вон в С первоклассные функции получше, чем в шарпе, и это как бы совсем ему не мешает.

VD>>>Что за системные задачи предполагается решать на языке, если это не написание ОС?
ВВ>>Написание ОС (необязательно ядра) — очень хороший пример такой задачи.
VD>А что за ОС-то на них хотят писать?

Да хотя бы те, что есть. Их ведь тоже надо писать.

ВВ>> Любые задачи, где требуется эффективность — от кодеков до виртуальных машин. Кто во что горазд.
VD>Вот это полнейшая чушь. Нет в этих задачах ничего чтобы нельзя было решить без ручного манипулирования байтами в памяти. Потом задач таких мало, и задачи эти даже на С решаются вполне не плохо.

Ну и? Ну решаются на С, да. Тут речь о том, что вполне может быть язык, с одной стороны более современный и удобный, чем С, с другой — справляющийся с такими задачами по крайней мере не хуже.