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

ВВ>Опять же допустимость вызова == наличие соответствующего члена, к примеру, а не соответствие определенному контракту. Это не только выглядит, но это и есть утиная типизация. На ваш твой взгляд тот факт, что в существующих реализациях это делает компилятор позволяет говорить о статической типизации? А ведь в сущности это чистая динамика только в компайл-тайме.

Возможно я не совсем корректно выразился, но имелось ввиду, что ошибки, связанные с несоответствием типов, в С++ проявляются на этапе компиляции, в отличии от Objective C, где большинсто из них попадают в рантайм — например невозможно создать массив объектов определённого типа (аналог std::vector), чтоб о добавлении "неправильных" объектов сообщал компилятор.

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

ВВ>Да нету в Ocaml никакой утиной типизации. То, что ты называешь утиной типизацией, это просто структурные типы. ИМХО это разные все же вещи.

Так и в C++ ее тоже нет, но и там и там есть то что основному определению утиной типизации удовлетворяет.

FR>>Ну и в версии языка 3.12 которая должна скоро выйти введены явно полиморфные типы которые по сути вводят аналог С++ шаблонов для обычных функций.

ВВ>Полиморфные типы? Не знаю таких Знаю полиморфные варианты — но они откровенно weakly typed.

Явно полиморфные типы. Точнее "Explicit polymorphic type annotations" тут http://caml.inria.fr/pub/distrib/ocaml-3.12/ocaml-3.12-refman.pdf
пункт 7.12. Это как раз тот самый тип <’a.> что делал полиморфными объекты, теперь его можно объявлять явно, что по сути вводит шаблоны в язык и
дает способ ручного разрешения неопределенности для rank-n polymorphism.

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

24>Возможно я не совсем корректно выразился, но имелось ввиду, что ошибки, связанные с несоответствием типов, в С++ проявляются на этапе компиляции, в отличии от Objective C, где большинсто из них попадают в рантайм — например невозможно создать массив объектов определённого типа (аналог std::vector), чтоб о добавлении "неправильных" объектов сообщал компилятор.

NSArray просто принципиально полиморфен, так сказать, но можно описать свой, который будет вполне себе статически типизированным.

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

ВВ>Да как сказать. Если кода много, а разработчик о С++ особо не думал, то вполне можно повозиться.
ВВ>Но, честно говоря, я уже давно этими вещами не занимался, может, я и преувеличиваю проблемы.

Угу преувеличиваешь.

ВВ>>>А большего — это явно выделенный безопасный сабсет языка с GC, блекджеком и шлюхами? Что-то мне начинает казаться, что описанный тобой язык давно существует и называется C++\CLI
FR>>Блин я тут мечтаю о прекрасной лани, ну на худой конец и лось сгодится, а ты мне вместо одногорбого верблюда впариваешь двугорбого да еще прихрамывающего, тьфу

ВВ>Неужели тебя не привлекает написать шаблоно-генерик для класса, который будет контролироваться GC?

Если уж брать верблюда, то лучшего, а это OСaml, тем более с новой версии на нем тоже можно писать шаблонный код контролируемый GC

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

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

Objective C хорош для подвязки GUI, но на этом его красота заканчивается.

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

24>>Возможно я не совсем корректно выразился, но имелось ввиду, что ошибки, связанные с несоответствием типов, в С++ проявляются на этапе компиляции, в отличии от Objective C, где большинсто из них попадают в рантайм — например невозможно создать массив объектов определённого типа (аналог std::vector), чтоб о добавлении "неправильных" объектов сообщал компилятор.
ВВ>NSArray просто принципиально полиморфен, так сказать, но можно описать свой, который будет вполне себе статически типизированным.
Контейнеров значений в принципе ты не сделаешь в ObjectiveC.

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

ВВ>но можно описать свой, который будет вполне себе статически типизированным.

Каким образом? Только чтоб один раз написать, а потом использовать с любым типом, а не для каждого типа писать полностью контейнер.

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

24>>>Возможно я не совсем корректно выразился, но имелось ввиду, что ошибки, связанные с несоответствием типов, в С++ проявляются на этапе компиляции, в отличии от Objective C, где большинсто из них попадают в рантайм — например невозможно создать массив объектов определённого типа (аналог std::vector), чтоб о добавлении "неправильных" объектов сообщал компилятор.
ВВ>>NSArray просто принципиально полиморфен, так сказать, но можно описать свой, который будет вполне себе статически типизированным.
C>Контейнеров значений в принципе ты не сделаешь в ObjectiveC.

Не понял, что мешает?

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

24>Каким образом? Только чтоб один раз написать, а потом использовать с любым типом, а не для каждого типа писать полностью контейнер.

Так, конечно, без шаблонов сделать нельзя.

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

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

Сдается мне, что ты путаешь типобезопасность со статической типизацией. Руби тоже нетипобезопасный по твоему?

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

FR>Есть реальная потребность в нативном языке который с одной стороны не был бы так примитивен как си, с другой
FR>не был так переусложнен как C++. Плюс язык должен быть гораздо более безопасным чем C/C++.

Если посмотреть на то что есть общее у Ржавчины и Гоги, то это:
1. Типобезопасность (т.е. не гораздо более чем, а просто типобезопасным).
2. ~LL(1) синтаксис (т.е. простота парсинга).
3. Нэйтивность (т.е. компилируемость в исполняемый код).
4. Модульность.
5. Фичи многопоточного программирования (новый трэнд ).
6. Статическая типизация.

FR>Потребность сейчас стала более острой, так как, развеялись иллюзии что управляемые платформы (java net) смогут
FR>покрыть все потребности прикладного программирования.

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

"Иллюзии" как раз усиливаются.

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

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

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

FR>Хорошим вариантом такого языка был бы конечно D, но долгострой похоже его уже погубил

Похоже что чем дальше, тем срок вызревания языков будет все больше и больше. Так что Ди еще ребенок по нынешним временам.

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

FR>Си не выбирал так как не вижу его преимуществ кроме простоты перед C++.

Это офигительное преимущество!

FR>Но полно задач для которых один язык на котором удобно работать как на низком так и на высоком
FR>уровне будет лучше. Сейчас такой язык (в мейнстриме) один C++, но к сожалению он слишком переусложнен
FR>и небезопасен.

Может такой язык и есть, но это точно не С++.

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

FR>Это параллельный мир
FR>Ну если сравнить даже последние версии дельфи с замыканиями и т. п. с тем же D не впечатляет.

Ди?

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

FR>Есть реальная потребность в нативном языке который с одной стороны не был бы так примитивен как си, с другой
FR>не был так переусложнен как C++. Плюс язык должен быть гораздо более безопасным чем C/C++.
Всякое новое — хорошо забытое строе.
Компонентный паскаль в БлэкБоксе — как раз то, что описано...

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

FR>>>C++, но к сожалению он слишком переусложнен
CC>>Чем же? На С++ можно писать как на "C с классами". "Переусложнённые" фичи ж никто не принуждает использовать.
FR>Во первых даже на "C с классами" есть немало не очевидных мест, те же виртуальные деструкторы,
А что с ними не очевидно то?
Ну и потом классы ещё не означают обязательное использование виртуальных функций. Да и нужны они далеко не всегда.

FR>конструкторы копирования и т. п.
Тоже в общем то простая штука, если не накрутить с архитектурой.

FR> Ну и во вторых я вообще не вижу смысла в "C с классами" при написании библиотек
И тем не менее он есть.

FR>для других языков, тут гораздо полезнее именно RAII шаблоны и т. п.
Дык тот же RAII на "C с классами" реализуется на ура.

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

ВВ>Вот, высокоэффективный прикладной язык. Остановимся на этом. А что может повысить эффективность? Например, прямая работа с памятью. И тут же по швам трещит вся безопасность.
ВВ>ИМХО высокоэффективный и высокобезопасный — это оксюморон.

Мне кажется имеет смысл начать с того, что определиться с терминологией.

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

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

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

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

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

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

ВВ>А что за проблема-то такая "таскать .NET"? Кстати, в Виста .NET тоже был.

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

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

VD>Если посмотреть на то что есть общее у Ржавчины и Гоги, то это:
VD>1. Типобезопасность (т.е. не гораздо более чем, а просто типобезопасным).
VD>2. ~LL(1) синтаксис (т.е. простота парсинга).
VD>3. Нэйтивность (т.е. компилируемость в исполняемый код).
VD>4. Модульность.
VD>5. Фичи многопоточного программирования (новый трэнд ).
VD>6. Статическая типизация.

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

бред полнейший. просто в 80-е ява ввела моду на использование байт-кода. никаких принципиальных изменений он не даёт, всё то же прекрасно работает хоть с ним, хоть без него. а байт-код использовался для реализации и паскаля, и смолтока, и бейсика — вы просто не знаете историю ФП

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

G>Сейчас вообще не проблема, размеры дистрибутивов для .NET4 стали неприлично маленькими.
G>Что-то в районе 40 мб для большого фреймворка и 20 с мелочью для Client Profile.

А куда делись сотни метров W??-ов (WPF, WWF, ...)?

И какие проблемы в наше время даже 2 гига скачать? Я вот периодически покачиваю фильмы в HD-форматах. И ничего так.