Вышла новая версия JNode 0.2.6

> несовместимые изменения в реализации тех же функций, например, такие, которые приводят к переполнению буфера из-за неправильной интерпретации аргументов.

Не слышал чтоб переполнение буфера из-за разного понимания библиотекой и вызывалкой.

А вообще переполенение буфера это типично С-шное, в С++ можно легко и в обязательном порядке проверять границы. Современные проблемы С++ больше на тему "указатель в куче" (эксплойт обычно к этому трудно сделать) и "missing input sanitizing" (а это и в яве запросто).

Но многие еще к сожалению на чистом С пишут...

> (кривой плагин может уронить все приложение)

Может. А зачем держать кривой плагин? Если допустим в каком-то классе вызвана абстрактная функция, то увидев такое, надо сохранятся, выходить из проги и отключать нафиг плагин. (видел я такое в бетах 3Д макса -- не падал он от этого, а говорил, еще и файл указывал и строку :-)

Или ты думаешь, что в Яве можно хромать на таком плагине дальше? Так он тебе обрушит приложение не физически, а логически, передав куда-нибудь совершенно левые данные, типа запросит отрисовать окружность размером в миллиард пикселей на экране, или в 3Д будет замусоривать все пространство миллионами случайных полигонов в разных местах пока память не кончится.

> (anonymous) Типичная жертва Sum Microsystems.

Я разве не объяснил, что речь тут не только о Java? И причем тут Sun? Управляемые языки были и раньше.

> (anonymous) Я не удивлюсь если тут мне скоро будут говорить что и велосипед возможен только в управляемых языках под управляемыми ОС :-)

Я не удивлюсь, если вы дойдете до утверждения, что интерпретируемые языки не имеют преимуществ над компилируемыми в собственный код. Так вот, байт-код, в некотором смысле, компромисс между ними.

> (tailgunner) Ерунда. Компилятор имеет всю информацию, и может положить ее в объектный файл в стандартном формате (DWARF2 - это практически оно).

Я не утверждаю, что рефлекшн не возможен в C++. Возможен, но это труднее и с ограничениями.

> (anonymous) Для плюсов рефлекшн есть в boost, есть куча разных на основе внутреннего представления gcc, кажись есть на основе dwarf ... а плакался я тут по поводу рефлекшн только потому, что нет единого стандарта, как в яве :-)

Полноценного рефлекшна для C++ я не видел.

>Я не утверждаю, что рефлекшн не возможен в C++.

"Это вообще фича интерпретируемых и управляемых языков" - твои слова?

> "Это вообще фича интерпретируемых и управляемых языков" - твои слова?

Мои. И означают они, что нормальный полноценный рефлекшн только в них.

>> "Это вообще фича интерпретируемых и управляемых языков" - твои слова?

> Мои. И означают они, что нормальный полноценный рефлекшн только в них.

...реализован. Потому что почему-то был нужен, а не потому, что только там и возможен.

> А вообще переполенение буфера это типично С-шное, в С++ можно легко и в обязательном порядке проверять границы. Современные проблемы С++ больше на тему "указатель в куче" (эксплойт обычно к этому трудно сделать) и "missing input sanitizing" (а это и в яве запросто)

Эксплойты и безопасность - отдельная тема. Речь сейчас о надежности.

В любом случае, повреждение памяти вызывающей программы возможно.
Да и как проконтролировать чем и как скомпилирован какой-то плагин?

> А зачем держать кривой плагин? Если допустим в каком-то классе вызвана абстрактная функция, то увидев такое, надо сохранятся, выходить из проги и отключать нафиг плагин.

Конечно, если кривой плагин не успел что-то испортить в памяти приложения так, что уже ничего нельзя сохранить. А ещё хуже, если сохранится битый файл.

> Но многие еще к сожалению на чистом С пишут...

Очень спорное утверждение, мягко говоря. Только давайте не разводить здесь C vs C++ - это уже где-то было.

> ...реализован. Потому что почему-то был нужен, а не потому, что только там и возможен.

А тут одному anonymous'у он в C++ понадобился. С чего вся тема про рефлекшн и пошла. Вообще-то рефлекшн для C++ хотят и пытаются сделать. Без него, например, нормальный persistence не получится. Слабо ORM а-ля Hibernate для C++?

> А тут одному anonymous'у он в C++ понадобился

Вот именно - одному анонимусу.

> Слабо ORM а-ля Hibernate для C++?

Си++ давно не претендует на роль современного Кобола - это нишу прочно заняла Ява.

> Си++ давно не претендует на роль современного Кобола - это нишу прочно заняла Ява.

По-моему, ешё не заняла.

ORM нужен далеко не только в бизнес-приложениях, а везде, где данные представленные объектами нужно хранить в реляционной базе данных.

Мдя как всегда ушли от темы. Пытаясь подытожить.

Железяки становятся не в меру быстрыми и собсно вскоре будет критично наваять что нибудь быстро качественно и не дорого. А железо и так уже бодрое. Вот тут подобные кроссплатформенные вещи и будут нужны.

Собственно писать на Java проще чем на Сях и все к этому идет. Потом будет Сява в которой из кубиков софт собитаться будет ну и т.д. (немного бреда не помешает).

Короче время - деньги товарисчи. Если рассматривать программирование как науку или искусство то в машинном коде писать надо а если как бизнес то в большинстве случаев заказчика интересуют его деньги а значит и время. То есть чем проще писать программы (в идеале студент первокурсник за 1 день и желательно даром) тем "ЛУЧШЕ".

Так что добро пожаловать вялотекущей операционке (когда ж вы до первого релиза то доберетесь).

> Я не удивлюсь, если вы дойдете до утверждения, что интерпретируемые языки не имеют преимуществ над компилируемыми в собственный код. Так вот, байт-код, в некотором смысле, компромисс между ними.

Почти что дойду. Единственное их непреходящее приемущество это то что исходник==исполнимый_файл. В байткоде оно теряется :-)

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

Поскольку набор мета фич ДАВНО стабилизировался, эти мета фичи ПОРА УЖЕ портировать под комп. языки.

> Полноценного рефлекшна для C++ я не видел.

Опиши что есть полноценный рефлекш.

wasrly

Чтобы tailgunner меня с другими анонимусами не путал, я решил зарегистрироваться.

> Эксплойты и безопасность - отдельная тема. Речь сейчас о надежности.

не я поднял вопрос об эксплойтах

> Я не утверждаю, что рефлекшн не возможен в C++. Возможен, но это труднее и с ограничениями.

Труднее это не существенно (книг страутструпа распродано 500 000 -- так что справятся все вместе), и ограничения (если они есть, скорее всего их нет) тоже не существенны.

> А ещё хуже, если сохранится битый файл.

А Великий Управляемый Код не может записать битый файл из-за ошибки в логике?

> Очень спорное утверждение, мягко говоря. Только давайте не разводить здесь C vs C++ - это уже где-то было.

Я считаю что С++ расширил С не правильно. Жду ваших претензий к плюсам (то бишь флейма) только видимо не в этой ветке.

2 dkharlamov:

> А железо и так уже бодрое. Вот тут подобные кроссплатформенные вещи и будут нужны.

С++ понятно не кроссплатформен... и вообще до Великой Явы не было ничего кроссплатформенного.

> То есть чем проще писать программы (в идеале студент первокурсник за 1 день и желательно даром) тем "ЛУЧШЕ".

Первокурсник на пхп и щас за день может наваять сайтик.

Максимум что он сможет это заместить абстрактные функции реальными.

А вот ПРАВИЛЬНО создать иерархию классов, в т.ч. абстрактных, первокурсник за день не сможет при любом языке программирования.

> Так что добро пожаловать вялотекущей операционке

Ява иногда рулит... но зачем ее исполнять в

1) kernel mode

и 2) отдельной ОС?

Меня так и не убедили что это хорошо.

2 tailgunner:

> Вот именно - одному анонимусу.

Читай первоисточник -- я сказал "рефлекшн до определенной степени нужен... хотя может совсем не так как в яве."

>> Слабо ORM а-ля Hibernate для C++?

> Си++ давно не претендует на роль современного Кобола - это нишу прочно заняла Ява.

Мое мнение -- потеснить ее пора оттуда. Естественно С++ под это не катит, нужна его приличная модификация, какая -- в сторону мета фич и облегченного синтаксиса.

ORM а-ля Hibernate будет либо для C++ либо для его модификации.

С трудом представляю себе рефлекшн на C++. Это вообще фича интерпретируемых и управляемых языков.

возможно через изврат с шаблонами (и зависимо от компилятора). Что-то вроде факториала на шаблонах, в конце раскрывается в тег, зависимый от конкретного класса. В качестве тега используется что-то вроде sizeof, что имеет разные размеры для разных классов (точную ссылку не помню, было где-то на rsdn).

Вот в D рефлекшен почти правильный получается ))

tailgunner>>Ерунда. Компилятор имеет всю информацию

upd: возможно и без особого изврата с шаблонами, cм. http://www.garret.ru/~knizhnik/cppreflection/docs/reflect.html MOP и метаклассы http://www.vollmann.com/pubs/meta/meta/meta.html

> (щас опять нам скажут что аннотации возможны только в интерпретаторе?)

в Vala есть аннотации. Интерпретатором там и не пахнет.

>Вообще-то рефлекшн для C++ хотят и пытаются сделать. Без него, например, нормальный persistence не получится. Слабо ORM а-ля Hibernate для C++?

как раз про persistence, почитай К. Книжника http://www.garret.ru/~knizhnik/cpp.html про ООБД на С++ в памяти, GOODS http://www.garret.ru/~knizhnik/goods.html. У него был интересный дисер (многобуков http://www.garret.ru/~knizhnik/dissertation.ps.gz ,или малобукв http://www.garret.ru/~knizhnik/abstract.ps.gz) про то как использовать аспекты для нормального persistence и рефлекшна. Дисер писался лет 10 назад, в 1998.

>Слабо ORM а-ля Hibernate для C++?

как каркас можно взять MOP http://www.vollmann.com/pubs/meta/meta/meta.html или подход Книжника.

Но в слове ORM мне не нравится буква R :)

В моём понимании, нормальный ORM это что-то что позволяет сделать такую вещь http://www.software-lab.de/dbui.html , но это совсем не relational DB :)

Зачем работать с объектами в сервере приложений, но в уровне хранения их сеарилизовать туда-сюда в RDBMS, если можно этого не делать? Изобрази просто поверх ООБД свой язык запросов, и 90% функционала RDBMS будет не нужно :))

> Зачем работать с объектами в сервере приложений, но в уровне хранения их сеарилизовать туда-сюда в RDBMS, если можно этого не делать?

Здравая мысль. А мне в голову не приходила :-(

Анонимус, заходи почаще!!!

Зачем вообще нужна RDBMS :

1) поддержка индексов 2) оптимизация запросов с использованием индексов 3) выполнение тригеров при вставке, обновлении, удалении (включая встроенные тригеры типа "удалить все подчиненные записи при удалении главной")

Все это можно делать и на бинарных (несериализованных) объектах.

Кстати, boost уже содержит определяемые пользователем индексы, которые можно включать в класс например для инвертирования отношений. Рефлекшн для этого не нужен :-) Очередь за триггерами :-)

Гм... все же полезно общаться и с апологетами явы... а не проявится ли проблема с разными версиями библиотек в одном процессе и хрупкостью базового класса, если мы начнем интегрировать две такие системы и делать запросы в которых обновляются таблицы из двух систем?

Сама по себе ООБД может вообще не использовать библиотек, но триггеры в каждой базе могут юзать разные версии одной библиотеки.

> Зачем вообще нужна RDBMS : > 1) поддержка индексов 2) оптимизация запросов с использованием индексов

ну и как сделать индексы - функциональные зависимости? придётся извращаться с триггерами. В то время как в своём языке запросов можно автоматически делать индексы по ФЗ.

>3) выполнение тригеров при вставке, обновлении, удалении (включая встроенные тригеры типа "удалить все подчиненные записи при удалении главной") > Все это можно делать и на бинарных (несериализованных) объектах. Рефлекшн для этого не нужен :-) Очередь за триггерами :-)

ага, а потом выяснится функции в SELECT должны работать с учётом иерархии данных\иерархии классов\ролей, накапливать итоги, кешировать результаты функций. И вместо произвольных запросов как в SQL нужны некоторые чётко очерченные, но с агрегатными данными, а изменение данных лучше делать не SQL, а методами объектов. И получается SQL почти не нужен.

> Зачем вообще нужна RDBMS :

просто RDBMS -- это ещё одна точка зрения на те же самые данные, будь они с другой стороны хоть объектами хоть многомерными кубами. Где-то эта точка зрения на данные полезна, где-то -- не очень, когда простой навигационный запрос по иерархии превращается в кучу JOIN'ов, значит, что-то тут не так.

Гибкость RDBMS в том, что можно быстро составить произвольный SELECT по разным данным. Но можно также и сломать инкапсуляцию объектов. То есть эта точка зрения на данные универсальна, но не всегда полезна и у неё есть ограничения, которые придется преодолевать громоздко, оставаясь в рамках этой модели данных (как с ролями, кешированием функций, триггерами, агрегированием данных) :))

> И получается SQL почти не нужен.

При наличии тригеров и планировщика запросов на С++ от SELECT INSERT UPDATE DELETE можно отказаться.

А как быть, если в базе уже есть много объектов My_Class, а я хочу добавить ко всем ним новое поле -- а именно индекс по существующему уже полю?

С++ совершенно неприспособлен для записи подобного намерения? А в sql есть add index

>3) выполнение тригеров при вставке, обновлении, удалении (включая встроенные тригеры типа "удалить все подчиненные записи при удалении главной")

> Все это можно делать и на бинарных (несериализованных) объектах.

> Очередь за триггерами :-)

цитирую из http://www.garret.ru/~knizhnik/abstract.ps.gz :

"<..>Реализации различных аспектов впоследствии компилируются в единый исполняемый код путем использования метаобъектного протокола, т.е. протокола, позволяющего управлять поведением объекта<..>Использование метаобъектного протокола (МОП) позволяет собрать в одном месте все аспекты, отвечающие за поведение объекта в системе: синхронизацию доступа, взаимодействие с БД, авторизацию обращений к объекту <..>управление транзакциями осуществляется на уровне МОП. Реализация базового метаобъекта подразумевает вызов каждого метода как вложенную подтранзакцию<..> Таким образом, метаобъект осуществляет полный контроль над выполнением транзакции в процессе клиента и обеспечивает необходимый приложению уровень изолированности"

вот тебе и триггеры :))

> А как быть, если в базе уже есть много объектов My_Class, а я хочу добавить ко всем ним новое поле -- а именно индекс по существующему уже полю?

в статье про МОП и в abstract.ps как раз это рассматривается, есть 2 алгоритма поведения, нужно наследование/не нужно. Нормальные ООБД умеют "добавить индекс по сущ. полю", если немного исхитриться, можно добавить индекс по ФЗ связям. Получится и кеширование заодно.

>С++ совершенно неприспособлен для записи подобного намерения? А в sql есть add index

ну напиши в своей ООБД на С++/ORM на С++ метод "добавить индекс к полю", станет С++ приспособлен.

Будет тебе add index, причем в поле можно засунуть всё что угодно (добавили поле в объект, добавили на него индекс -- функцию, хеш от параметров функции, кеширование результатов функции.). Получили индексы на функциональные зависимости. А теперь, как это будет выглядеть в SQL? :))

> а я хочу добавить ко всем ним новое поле -- а именно индекс по существующему уже полю?

индексы по ФЗ в общем случае являются аспектами. И если ядро ООБД умеет с аспектами работать, добавить их несложно ))

>планировщика запросов

тут да, тот же Книжник отводит его на уровень, зависимый от приложения, в разных случаях по разному. Если сервер приложений выполняет какую-то транзакцию, как выполнять запрос.

Если немного отвлечься от С++, и представить, что запросы -- это лениво вычисленные функции в функциональщине, то транзакции будут методы-замыкания обработки объектов. И в функциональщине этот планировщик получается почти естественным путём, как то же Software Transactional Memory.

Зарюхаю Книжника в ближайшее время. Его рефлекшн я видел, но на остальное совсем не обратил внимание.

Ты где не анонимусом тусуешься? на rsdn.ru?

> Ты где не анонимусом тусуешься?

в оффлайне )) а надо ?

>> Си++ давно не претендует на роль современного Кобола - это нишу прочно заняла Ява.

> Мое мнение -- потеснить ее пора оттуда.

Я далек от этой области... чем плоха Ява для нее? Язычок так себе, но хоть лямбды в нем собираются сделать :)

> Естественно С++ под это не катит, нужна его приличная модификация

Си++ зашел в тупик, _модифицировать_ его слишком поздно. Даже D - это отнюдь не модификация.

http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf

> Си++ зашел в тупик, _модифицировать_ его слишком поздно. Даже D - это отнюдь не модификация.

В тупик -- да.

Смотря что называть модификацией. Совместимость с С библиотеками надо оставить, семантику оставить, синтаксическую совместимость с С -- убрать и чуток новых идей добавить.

>> Ты где не анонимусом тусуешься?

> в оффлайне )) а надо ?

познавательно знаешь-ли общаться. вот tailgunner здесь бывает, я его и раньше замечал, буду пользу почерпывать его комменты читая :-) а вот ты и пропасть можешь однако

> познавательно знаешь-ли общаться.

это притом что я пока ещё трезвый. А так можно много чего нафантазировать ))

вот CRUD-это интерфейс к ORM который говорит в базу SELECT-INSERT-UPDATE-DELETE. Понятно, что этот CRUD -- это такой же аспект-кусочек MOP как для RDBMS S-I-U-D, как для ООБД управление транзакциями, сохраняемость, OQL или что там, внешний интерфейс ООБД, в общем.

а данные-то те же самые, и в сервере приложений, и в уровне хранения, и на диске/в бд, и в запущеной программе.

просто получается, что некоторые данные хорошо ложатся на "квадратные" реляционные таблицы и ORMы, а для некоторых, списков, ролей, наследования, кеширования ФЗ данные получаются "неквадратные", и вся эта ерунда вроде ORM нужна для создания метаданных приложения, во-первых, и запихивания треугольных колёс в квадратные шины, во-вторых :))

Ещё VSL завещал, что смотреть всегда надо на семантику, а не на синтаксис. То, что у нас на разных уровнях всякие подпорки вроде ORM, и разные синтаксисы -- это ещё полбеды.

Хуже, когда у нас вместо единой модели данных возникают разные островки -- тут у нас объекты, тут таблицы, тут мы пирожки заворачивали.. двоичные блобы, то есть

Тут у нас в программе в рантайме -- объекты в одном виде, тут в БД -- в другом, тут ещё где-то между сериализованные маячат в третьем.

Всё это в общем-то ерунда, если не происходит потери семантики, смысла данных и отношений между ними.

Кажется, в абстракции на уровне "данные приложения"-объекты-файлы-исполняемые объекты уровня всей системы (плагины, классы/методы с ХБК и т.п.) -- потеря происходит.

В принципе, как из АОП с МОП можно сделать ядро ООБД, так и из "системных объектов" с "файлами-объектами" с микроядром ОС, прозрачно сохранять все объекты в plist на уровне всей системы. Файлы выкинуть, иметь тегируемые унифицированные составные объекты с данными и/или поведением.

C другой стороны, всему своё место и свои границы. Вона Джоэль говорил что SQL круче XML потому что парсить не надо, всё распарсено до нас. Всё колонки в RDBMS типизированы, правда, с дырой в семантике все равно толку чуть.

А если скрестить 2 подхода, взять унифицированную обработку из RDBMS и расширяемость и целостность метаданных из ООБД -- то вот оно, щасте.

В этом, кажется, есть какая-то глубокая мысль, но я недостаточно выпил, чтобы её дальше обсуждать :((

> некоторые данные хорошо ложатся на "квадратные" реляционные таблицы и ORMы, а для некоторых, списков, ролей, наследования, кеширования ФЗ данные получаются "неквадратные"

> взять унифицированную обработку из RDBMS и расширяемость и целостность метаданных из ООБД -- то вот оно, щасте.

> В этом, кажется, есть какая-то глубокая мысль, но я недостаточно выпил, чтобы её дальше обсуждать

Вот так был снова озвучен "Третий манифест"... почти что озвучен :D

> Я далек от этой области... чем плоха Ява для нее?

Ява напрягает в основном из-за своих маркетоидных наездов по ушам, в том числе таким, как jnode. Практическое значение этой ОС равно нулю, не равен нулю только звон, и я опасаюсь, что благодаря разным вещам типа jnode звон вокруг явы может достичь бесконечности за конечное время :-)

Вот мне хотелось бы язык, чтобы он в любой предметной области позволял высказаться ИМЕННО ТАК КАК Я ХОЧУ, а не только высказать ТО что я хочу. Естественно это будет в том числе DSL framework.

Я даже до некоторой степени могу формализовать это желание... но полностью формализовать его видимо принципиально сейчас не возможно, а возможно будет когда и если психология научного поиска будет чем-то типа точной науки.

> Язычок так себе, но хоть лямбды в нем собираются сделать :)

Я для тренировки попробовал написать лямбду на яве через шаблоны.
Полноценно конечно не получилось, и я подозреваю что не получится
из-за type erasure. 

В топку надо такой язык где за каждым мелким чохом типа лямбды
приходится канючить у Sun Microsistems.

Вот в плюсах шаблоны позволяют написать лямбду. Почти полноценную.
И делать почти полноценные ленивые вычисления... Но тоже ПОЧТИ.

class JavaLambda6Test {

  static abstract class Lambda<Res,Arg> {
    abstract public Res f( Arg x );
  }

  static Double integral01( Lambda<Double,Double> f ) {
    Double res=0.0; // Великая Ява не понимает Double res=0;
    for( int i=0; i<1000; i++ )
      res+=f.f(i/1000.0);
    return res/1000;
  }

  public static void main(String[] args) {
    for( int n=0; n<10; n++ ) {
      final int nn=n; // если убрать эту строку и внизу заменить nn на просто n, Великая Ява тоже не поймет
      System.out.println( "intergral from 0 to 1 of x^" + n + " =" +
        integral01( new Lambda<Double,Double>() { public Double f(Double x){ return Math.pow(x,nn); } } )
      );
    }
  }
}


Запускать: javac JavaLambda6Test.java && java JavaLambda6Test
(83 варнинга будут на 83 русские буквы но пойдет)

"Слышу звон, да не знаю где он"

результат такой будет:

intergral from 0 to 1 of x^0 =1.0
intergral from 0 to 1 of x^1 =0.4995
intergral from 0 to 1 of x^2 =0.3328334999999999
intergral from 0 to 1 of x^3 =0.24950025
intergral from 0 to 1 of x^4 =0.19950033333330003
intergral from 0 to 1 of x^5 =0.16616708333325
intergral from 0 to 1 of x^6 =0.1423576428569761
intergral from 0 to 1 of x^7 =0.12450058333304163
intergral from 0 to 1 of x^8 =0.11061177777731108
intergral from 0 to 1 of x^9 =0.09950074999930003

> "Слышу звон, да не знаю где он"

А что, таки jnode умеет запускать управляемый код не только явы?

> Вот мне хотелось бы язык, чтобы он в любой предметной области позволял высказаться ИМЕННО ТАК КАК Я ХОЧУ, а не только высказать ТО что я хочу. Естественно это будет в том числе DSL framework.

дорога вам в Language-Oriented programming, Intentional programming. Кто-то из JetBrains (где ИДЕЮ думают ^W делают :) наваял IDE для создания DSL'ей. По инету ходила демка с роликом.

<flame on> Странно, что на Яве -- осилили за 10 лет, а на лиспе за 20+ лет -- ниасилили :)) </flame off>

>если психология научного поиска будет чем-то типа точной науки.

ага, "пойди туда, не знаю куда", поискать вокруг да около, может на какую-нибудь мысль навеет -- это формализуемо? типа "творческий свободный поиск" на какую-то тему? (наверно, если формализуемо, как-то вроде меметики)

> дорога вам в Language-Oriented programming, Intentional programming.

да.

> Кто-то из JetBrains (где ИДЕЮ думают ^W делают :) наваял IDE для создания DSL'ей.

пару лет назад видел я этот отстой, именно их прямоугольнички между которым мышой или стрелочками надо перемещаться. Это хуже даже лиспа. (почему даже? потому что изобретение 60-х годов прошлого века (!!!), а не потому что он плох)

DSL framework должен быть языком, как пример -- лисп, а не IDE, хотя IDE к нему тоже нужна.

> Странно, что на Яве -- осилили за 10 лет, а на лиспе за 20+ лет -- ниасилили :))

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

>> если психология научного поиска будет чем-то типа точной науки.

> ага, "пойди туда, не знаю куда", поискать вокруг да около, может на какую-нибудь мысль навеет -- это формализуемо? типа "творческий свободный поиск" на какую-то тему? (наверно, если формализуемо, как-то вроде меметики)

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

Психологией научного поиска я назвал _не_ науку, которая определяет "в какую сторону искать". А науку, которая... хорошо, конкретный пример:

Идеальные брюки надо было бы шить исходя из "психологии ходьбы". Т.е. те движения которые встречаются часто надо в этих брюках делать легко, и иметь также возможность совершать и нечастые движения и т.д. Однако "психология ходьбы" почти ничего не имеет общего с наукой "куда надо идти чтобы придти к <что-то там>", которая например бы гласила, что если видшь протоптанную сильно тропинку, то скорее всего в болото не попадешь, и т.д.

>> "Слышу звон, да не знаю где он"

> А что, таки jnode умеет запускать управляемый код не только явы?

А чем у.к. явы хуже других?

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

ну это же забавное изобретение -- наплодить кучу шаблонов с формами и дырками для "нужное вписать", и этот GUI назвать "среда для разработки языков". Я уже жду примеров, когда они наткнутся на какую-то сильно многомерную структуру, как они в 3D её рисовать будут. Ещё можно аватаров из SouthPark'а или Second Life пририсовать, как у них в baloon help фразы выскакивают ))

>изобретение 60-х годов прошлого века (!!!), а не потому что он плох)

>DSL framework должен быть языком, как пример -- лисп, а не IDE, хотя IDE к нему тоже нужна.

это скорее среда чем только язык.

я тут недавно перечитывал ссылки про другое изобретение 60х -- гипертекст, и как его испортили в веб. http://webplanet.ru/column/service/shepelev/2006/08/22/semanticweb.html

Перечитывал про Xanadu и AUGMENT (бывшая NLS Дуга Энгельбарта, 60х годов). В статье про purple numbers и особенно AUGMENT (оригинальной, 60х годов) расписана концепция про "среду для авторинга".

Так вот она именно среда. Как тот же emacs-среда, и plan9 -- среда :)

Многие моменты интересные: те же purple numbers как адреса и другие типы ссылок, то, что среда является настраиваемой и собираемой из частей, как Emacs, и прямая манипуляция объектами по ссылкам (предложения, параграфы, слова, и т. п.), как команды телепанического интерфейса в vim'е.

Её и сейчас интересно читать, статью Энгельбарта про NLS/AUGMENT. Emacs, кажется почти приблизился к той концепции, хотя у него было что-то среднее vim/emacs/whatever.

>> Странно, что на Яве -- осилили за 10 лет, а на лиспе за 20+ лет -- ниасилили :))

>так что флеймить тут просто не о чем

речь не о лямбдах или языке Лисп или языке С++ или языке Ява, а о платформе/среде.

Ах, какой был слон, полосатый, белый, пушистый.. ^U в смысле, гипертекст Xanadu, вот Тед Нельсон воистину православно измыслил. Но так и не допилил. (хотя его zigzag с многомерным интерфейсом -- это интересно (а также интересно, кто его осилит :))

Энгельбарт хоть что-то родил, выдал. Столлман выдал платформу-Emacs, которая после долгого допиливания 10-15 лет почти приблизилась к концепции AUGMENT.

Но про "языковую IDE" разговоры завели, что-то на коленке налабали и показали, какую это пользу даёт -- почему-то явошники, "явошным порядком" Ж))

<flame>странно, что те наглядную свистелку осилили, а эти не осилили </flame>

:))

>>> "Слышу звон, да не знаю где он"

>> А что, таки jnode умеет запускать управляемый код не только явы?

> А чем у.к. явы хуже других?

У C# например есть локальные переменные, котороые освобождаются сразу и не мусорят кучу. Но вообще спросите специалистов.

До тех пор пока jnode умеет запускать управляемый код не-явы, звон во круг jnode только добавляет шума вокруг явы.

>Не знаю тот ли ты анонимус, который еще недостаточно выпил...

тот самый. Зарегестрироваться, что ль, или подписываться начать :))

>очень легко меня понять неправильно, <..> но больше говорить на эту тему не буду.

тогда мы так и не нащупаем ту понимание той мысли, которую хотели сформулировать :))

>>"психология научного поиска будет чем-то типа точной науки."

> Однако "психология ходьбы" почти ничего не имеет общего с наукой "куда надо идти чтобы придти к <что-то там>",

а что мы хотим нащупать-то? если психологию, то это ближе к меметике и т.п., если common sense и good practices -- это мейнстрим (но можно и слона ощупывать), если что-то что работает, но не мэйнстрим -- то тут методология научного поиска, подтверждённая экспериментами :)) пробовать надо ))

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

http://ailev.livejournal.com/122433.html (У Левенчука, кстати где-то был интересный текст "как сделать *полезную* модель")

//dm

>Идеальные брюки надо было бы шить исходя из "психологии ходьбы".

идеальных брюк не бывает. Смокинг или джинсы, комбез, трико или шорты? Сколько use case'ов, столько и вариантов. Вот носят все джынсы, а у них карманы неудобные, когда за рулём, ключи могут вываливаться, на любителя в общем, которому карманы нужны не часто :) нужны карманы -- бери комбез с 20 карманами на коленках. А кому-то жизнь не мила без тёплых кальсон :))

> наукой "куда надо идти чтобы придти к <что-то там>", которая например бы гласила, что если видшь протоптанную сильно тропинку, то скорее всего в болото не попадешь,

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

> <flame>странно, что те наглядную свистелку осилили, а эти не осилили </flame>

может у тебя подкол очень тонкий, но я опять не понял: где флеймить?

> особенно AUGMENT (оригинальной, 60х годов) расписана концепция про "среду для авторинга".

1. Чувствую я пора уже просвещаться а не флеймить... впрочем еще можете поднакидать ценных ссылок.

2. Программисты вот уже лет 50 это сапожники без сапог, про что я и ставил три восклицательных знака в скобках

> Так вот она именно среда. Как тот же emacs-среда, и plan9 -- среда :)

Был бы язык и семантика -- а среду напишут. И не одну. И не под jnode, это точно.

> Но про "языковую IDE" разговоры завели, что-то на коленке налабали и показали, какую это пользу даёт -- почему-то явошники, "явошным порядком" Ж))

Может флеймить здесь?

1) Какую пользу дает было видно еще 20 лет назад, а не после того как налабали.

2) Налабали не явочники, а автор IDEA (русский кстати), который при выборе языка для IDEA ориентировался на мейнстрим, которому хочется картинки и комиксы и мозгов у которого не шибко, зато есть бабло покупать свистелки-перделки (я про США, у них там жалуются что дети не идут в программисты :-)

Он поступал совершно правильно, кстати.

И налабал в виде весьма специфическом, пригодном для явочников, которые привыкли жрать только то, что им обертке в подадут, приемы применять только прочитанные в книжках, и которые не в состоянии потребовать язык где сами могут написать лямбда функцию хотя бы как в С++, а не канючить у сана или автора ИДЕИ.

С++, если бы в нем можно было локально запрещать & и *, позволял бы создать полную копию Явы с кучей доп. возможносте.

НО: народ на jetbrains форуме часто весьма правильный тусуется.

пример (28 февраля) I have created a data language, which can be easily used to create domain-specific languages.

----

>> очень легко меня понять неправильно, <..> но больше говорить на эту тему не буду.

> тогда мы так и не нащупаем ту понимание той мысли, которую хотели сформулировать :))

нет у меня терпения еще точнее разъяснить письменно, только видимо вживую

>> Идеальные брюки надо было бы шить исходя из "психологии ходьбы".

> идеальных брюк не бывает. Смокинг или джинсы, комбез, трико или шорты? Сколько use case'ов, столько и вариантов. Вот носят все джынсы, а у них карманы неудобные, когда за рулём, ключи могут вываливаться, на любителя в общем, которому карманы нужны не часто :) нужны карманы -- бери комбез с 20 карманами на коленках. А кому-то жизнь не мила без тёплых кальсон :))

Мое мнение: язык общего назначения в отличие от штанов общего назначения возможен.

Доказывать не буду, ибо уж очень много буков :-)

>Мое мнение: язык общего назначения в отличие от штанов общего назначения возможен.

тут в соседнем топике Эсперанто помянули :)) еще и логбан логический можно вспомнить:)

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

но немного не в тему. В тему, что нужен язык не совсем "общего назначения", а в каких-то рамках, на какой-то платформе, в контексте чего-то. А не то будет интересен только "структуральнейшим лингвистам" :)

>IDEA написал русский, который "популяризовал яву"

ага, можно ещё и XDS вспомнить, которые писали-писали Обероны, а потом чтобы хоть как-то продать свои компиляторы срочно перенацелились на Яву. И тут-то им и попёрло :)

>Мое мнение: язык общего назначения в отличие от штанов общего назначения возможен.

не спорю :)

как в том анекдоте -- пожар начался, математик проснулся, увидел огнетушитель, "решение существует" :) и лег спать дальше.

собстно все претензии к лиспу, старому юниксу, "новому" plan9 и другим "костылям Рип Ван-Винкля" (c) :) в том, что они существуют "более, чем наполовину", как фольклор, анекдот, пересказываемый друг другу лет 30..50 :) после чего математик опять ложится спать дальше :)

//dm

>> особенно AUGMENT (оригинальной, 60х годов) расписана концепция про "среду для авторинга".

AUGMENT http://www.bootstrap.org/augdocs/oad-2250.htm#6 -- читал и плакалЪ, местами на Emacs похоже :)

purple numbers http://www.eekim.com/software/purple/purple.html

> 2. Программисты вот уже лет 50 это сапожники без сапог, про что я и ставил три восклицательных знака в скобках

причём рецепт "идеальных сапог" уже передаётся из уст в уста второе поколение, но его периодически забывают, и продолжают делать кроссовки :))