Здравствуйте, x-code, Вы писали:
XC>И класс CPoint содержащий два поля X и Y и пару методов, и какой нибудь CApplication в который запихана основная логика приложения — по сути своей равноправные классы. А этого быть не должно. Надо сказать, что и Ди и даже Немерле этой проблемы не решают.
Думаю, что речь шала о подсказках IDE и о том, что в неоднозначном С++ эти подсказки зачастую сбиваются или попросту не могут быть показаны в следствии отсуствия информации. Незнаю как там с Ди, но в Немрле таких проблем нет.
XC>ООП недалеко ушло от Си, просто вместо кучи функций появилась куча классов. XC>Ди — это лишь попытка что-то сделать, вряд ли на Ди перейдут с С++ (ну если только будет какой-нибудь плагин который позволит встраивать Дишные файлы в С++-ные проекты и компилировать все вместе... тогда может быть энтузиасты часть НОВОГО кода будут писать на Ди) XC>Здесь нужен КАЧЕСТВЕННО новый подход к дизайну языка, к самой концепции "языка программирования", к средствам разработки.
Есть кикие-то идеи по замене ООП и ФП на что-то другое? Или это просто слова в воздух?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Если нужен другой язык. Не конкурент С++, а язык его заменяющий. То определись что ты хочешь от этого языка. Вот когда я сформулировал свои требования, то оказалось, что ближе всего к их воплощению подошел именно Nemerle. А Ди это всего лишь клон С++ развивающий его неверные решения.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, VladD2, Вы писали:
VD>>Скорость моего кода работающего на VM значительно выше чем кода большинства программистов гордящихся тем, что они пишут на С++.
EC>Это особенно заметно на legacy C++ code — тогда люди делали массу отпимизаций, которые сейчас просто потеряли смысл и просто сбивают с толку компилятор, т.к. информация, что именно должен делать компилятор слишком детализированная и ему негде развернуться.
Не совсем так. Современные С++ компиляторы такие вещи как inline, register, volatile в большинстве случаев просто пропускают. Поэтому ваш аргумент — не более чем выдумка.
Здравствуйте, VladD2, Вы писали:
VD>CLR — это runtime для Microsoft .Net. Microsoft .Net — это реализация стандарта CLI от Microsoft. Если говорить о CLI, то потенциально, нет. Но серьезной реализацией интерпретатор не считается. В Моно тоже имеется компиляция. В прочем там есть и интерпретируемый вариант, но используется он только в тех случаях когда для платформы пока не портирован компилятор в нэйтив-код.
M>>З.Ы. В своем посте под .Net я подразумевал именно CLR, а не конкретно MS .Net. возможно из-за этого путаница возникла.
VD>И в очередной раз ошибаешся.
То, о чем вы тут говорите больше смахивает на демагогию. Нужно смотреть на реальное положение вещей — .NET это CLR и так будет всегда.
Без VM из всех ваших сверхмощных языков уйдет вся их сверхмощь — рефлекшены, дефрагментатор памяти, runtime inline и практически все то, ради чего тут загибали пальцы.
Здравствуйте, EvilChild, Вы писали:
VD>>Слышал. Какое поддержка имеет отношение к тому, что постоянно появляются новые проекты на С++?
EC>При чём здесь новые проекты?
Тогда читай внимательно о чем шла речь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, x-code, Вы писали:
XC>Здравствуйте, demi, Вы писали:
D>>>>Вот и имеем, то что имеем — монструозный, гипертрофированный, подчас не решающий достойно проблемы, и просто у@ищный (извините) C++ XC>Супер! 36 очков, и это не предел
[..skipped..] XC>Ди — это лишь попытка что-то сделать, вряд ли на Ди перейдут с С++ (ну если только будет какой-нибудь плагин который позволит встраивать Дишные файлы в С++-ные проекты и компилировать все вместе... тогда может быть энтузиасты часть НОВОГО кода будут писать на Ди) XC>Здесь нужен КАЧЕСТВЕННО новый подход к дизайну языка, к самой концепции "языка программирования", к средствам разработки.
Есть какие-то идеи? Поделитесь с нами, пожалуйста.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Disappear,
ГВ>Сдаётся мне, что по количеству слов "фобия", "кос[т]ность", "дремучее прошлое" и прочих сугубо идеологомозговедческих артефактов эта тема в ФП скоро выйдет в устойчивые лидеры. Уж по термину "Блаб" — стопудово.
Люди не хотят конструктивно рассуждать. В основном те, кто подняли тут эти термины сами же им были подвержены.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, x-code, Вы писали:
XC>>И класс CPoint содержащий два поля X и Y и пару методов, и какой нибудь CApplication в который запихана основная логика приложения — по сути своей равноправные классы. А этого быть не должно. Надо сказать, что и Ди и даже Немерле этой проблемы не решают.
VD>Думаю, что речь шала о подсказках IDE и о том, что в неоднозначном С++ эти подсказки зачастую сбиваются или попросту не могут быть показаны в следствии отсуствия информации. Незнаю как там с Ди, но в Немрле таких проблем нет.
Не совсем. Нужен качественно новый подход к написанию кода, а не подсказки. См. ответ на второй вопрос.
XC>>ООП недалеко ушло от Си, просто вместо кучи функций появилась куча классов. XC>>Ди — это лишь попытка что-то сделать, вряд ли на Ди перейдут с С++ (ну если только будет какой-нибудь плагин который позволит встраивать Дишные файлы в С++-ные проекты и компилировать все вместе... тогда может быть энтузиасты часть НОВОГО кода будут писать на Ди) XC>>Здесь нужен КАЧЕСТВЕННО новый подход к дизайну языка, к самой концепции "языка программирования", к средствам разработки.
VD>Есть кикие-то идеи по замене ООП и ФП на что-то другое? Или это просто слова в воздух?
ФП — замечательный подход, я часто жалею что ничего подобного нет в С++. Но это локальный уровень, а нужен глобальный. И в локальном уровне должны быть заложены средства коннекта с глобальным.
У меня есть только интуитивные наметки, но формализовать пока неполучается — видимо, из-за нехватки времени. Поэтому попробую как сумею, наверняка получится криво
В общих словах — я хочу чтобы IDE понимала семантику и логику программы и как-то отражала это. Чтобы была некоторая "многослойность" и "многомерность" при разработке. Чтобы программист мог выразить семантику взаимодействующих объектов как-то так, чтобы это было видно, и чтобы компилятор извлекал из этого какую-то информацию.
Возможно, "программирование на уровне паттернов".
Возможно, такие концепции как "контейнер" и "итератор" стоит ввести в язык программирования.
Как-то на более высоком уровне реализовать идею объектов и связей между ними (не методы и указатели на интерфейсы)
Сделать прямой гейт "UML-язык программирования", а не те кривые реализации которые есть сейчас.
То есть вот хочу я написать программу. Создаю проект, ввожу название, краткое описание что программа делает. У меня на экране "квадратик" с именем программы. Далее, я хочу чтобы у программы был пользовательский интерфейс, чтобы она работала как клиент и как сервер в сети и работала с БД. Я беру в "ПАЛИТРЕ ФУНКЦИОНАЛЬНОСТИ" понятие "Пользовательский интерфейс" и перетаскиваю его на квадратик программы! Это не компонент, не класс, а именно "функциональная сущность". Там нет прямого кода на ЯП, нет классов и компонентов, а есть некоторый интеллектуальный блок который "знает" что такое "UI".
Далее, я хочу конкретизировать что же мне нужен за интерфейс. Я щелкаю на появившейся секции "UI" и спускаюсь на уровень ниже. Мне становится доступна новая палитра функциональности, включающая в себя различные варианты интерфейсов, например "Возможноть MDI окон", "Возможность консольных окон", "Полноэкранный режим DirectX", "Возможность пиктограммы в трее", "Голосовой ввод", "Воспроизведение аудио".
И дальше, опускаясь по дереву уровней все ниже и ниже, я в конечном итоге заполняю различные процедуры и функции, создаю структуры, перечисления, классы, связываю входы и выходы различных компонентов... не напрягаться какой бы "адаптер" придумать чтобы связать два класса, а просто СВЯЗАТЬ их и пусть компилятор думает...
Если мне нужна строка то я даже не задумываюсь какой из 20 типов строк использовать! Я просто использую абстракцию "строка", если мне нужно конкретизировать — я конкретизирую, если не нужно — компилятор сам за меня это сделает.
Не париться с STL и прочими контейнерами, а просто работать с абстрактными наборами данных — путь компилятор решает, что выгоднее — простой массив или двусвязный список с хеш-таблицей.
VD>И все же твои аргументы весма сомнительны. Ведь интерпретатор можно сделать и для ассемблеара. Нельзя же на этом основании делать какие-то выводы о производительности в общем?
Интерпретатор ассемблера с JIT компиляцией будет быстрее просто интерпретации ассемблера в общем.
Допустим я написал реализацию CLI для .. ну допустим Solaris. И не сделал там JIT компиляцию.
И на Солярке программы будут тормозить.
Поэтому я и не согласился с твоим утверждением
VD>Я бы сказал, что байт-код тоже не существеннен. В итоге ведь все равно имеем нэйтив-код.
Потому что нейтив кода в моем гипотетическом .Solar мы не получим. Мы получим интерпретацию байткода.
Конечно? можно сказать что интерпретация тоже дает нейтив код, потому что сам интерпретатор исполняет нейтив код, и любая инструкция байткода перейдет в какую-то инструкцию нейтив кода, но это совсем не одно и то же, что интерпретатор с JIT компиляцией.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
Здравствуйте, Disappear, Вы писали:
D>То, о чем вы тут говорите больше смахивает на демагогию. Нужно смотреть на реальное положение вещей — .NET это CLR и так будет всегда.
Советую покурить MSDN или LCS/CLI-стандарты.
D>Без VM из всех ваших сверхмощных языков уйдет вся их сверхмощь — рефлекшены, дефрагментатор памяти, runtime inline и практически все то, ради чего тут загибали пальцы.
VM — это образное выражение. Считается что управляемая программа пишется для некой подразумеваемой (виртуальной) машыны. Фактически же программа выполняется реким рантаймом который и обеспечивает все нужные сервисы. Таких рантаймов на сегодня 3: GNU (почти не рабочий), Моно и .Net CLR. Последнии два вполне рабочие.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ironwit, Вы писали:
VD>>Если нужен другой язык. Не конкурент С++, а язык его заменяющий. То определись что ты хочешь от этого языка. Вот когда я сформулировал свои требования, то оказалось, что ближе всего к их воплощению подошел именно Nemerle.
I>можно о выделенном подробнее?
Это может занять слишком много времени и места. Если попытаться описать их кратко, то это ЯП поддерживающий/отвечающий требованию:
1. Статическую типизацию.
2. Компилируемый (не интерпретируемый).
3. Типобезопасность.
4. Модульность.
5. Компонентную модель (динамическая загрузка и выполнение кода из бинарных библиотек).
6. Выразительный (код должен быть относительно компактным и легко читаться).
7. Метапрограммирование (возможность встраивать DSL-и проямо в код на этом языке, и возможность
генерировать код по некоторым входным описаниям (например, обертки для таблиц БД)).
8. Мултипарадигности (поддержка ООП, ФП, МП).
9. Поддеркжка проектов большого размера.
10. Рефлексия времени выполнения.
11. Рефлексия времени компиляции.
VD>>А Ди это всего лишь клон С++ развивающий его неверные решения.
Не очень то он клон. Исползует те же идеи — да. Но это другой язык.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Проблема в том, что это могут с уверенностью сказать только продвинутые Хаскелисты. Лично я знаю только одно — Хаскель очень агрессивно использует композицию фукнций и по умолчанию он все рассматривает как композицию однопараметровых функйи. Так что казалось бы невинная запись "factorial n — 1" может превратиться в черт знает что.
В данном случае достаточно знать, что операторы имеют меньший приоритет, чем функции. Это не проблема Хаскеля. В других языках тоже надо знать о приоритетах. Каррированные функции тут совершенно не при чём.
VD>Причем в иногда это будет давать тот же результат как ты можешь интуитивно предполжить, а иногда получается такое, что ты даже выполнив код не сможешь понять, что же произошло.
Можно пример, когда карринг приводит к такому случаю?
С остальным согласен. Короткая запись ПМ на Немерле — очень здорово, в Хаскеле для этого приходится либо вторую строчку, либо case/of делать.
Здравствуйте, EvilChild, Вы писали:
EC>Этот вариант всех рвёт по компактности и изяществу.
VladD2 показал более лаконичный вариант на Nemerle. Правда, он использует локальные функции. Если тот же вариант возможен без этого ограничения, то это просто замечательно.
Кстати (вопрос к VladD2) — чем вызвано это ограничение? Не положить в байткод в общем виде?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Сдаётся мне, что по количеству слов "фобия", "кос[т]ность", "дремучее прошлое" и прочих сугубо идеологомозговедческих артефактов эта тема в ФП скоро выйдет в устойчивые лидеры. Уж по термину "Блаб" — стопудово.
А мне еще кажется, что как к защитникам D, так и к критикам в данной теме относятся слова классика:
...Ведь в вине была горечь побед,
Которым цена — лишь костыль, И, сражаясь за красоту, дурни подняли пыль.
(Крематорий, Винные Мемуары).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, igna, Вы писали: I>>Разве из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой и мощный"? S>совершенно верно. Из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой или мощный".
<paranoid mode>
Неверно. Т.к. из истинности утверждения "С++ — простой или мощный" не следует истинность утверждения "С++ — простой и мощный" о котором шла речь.
</paranoid mode>
Здравствуйте, jedi, Вы писали:
J>Я понимаю, что это все может показаться надуманным, но все-таки ... Одно дело plain-text code, который не больше чем код, а совсем другое — зверь, который во время компиляции может приконнектиться куда нужно и сдать нахрен все номера моих кредитных карточек
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, igna, Вы писали: I>>Разве из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой и мощный"? S>совершенно верно. Из ложности утверждения "C++ — сложный и слабый" следует истинность утверждения "С++ — простой или мощный".
Ремарка: исключение третьего здесь требует дополнительных обоснований.
