LINUX.ORG.RU

Стандартный набор OCaml'щика ;)


0

0

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

Небольшая экскурсия (начиная с самого верхнего окна):
- Topcameleon --- графическая интерактивная система (toplevel);
- Doc box --- браузер документации, сгенерированной ocamldoc;
- OCamlCVS --- GUI к CVS;
- Cameleon --- самое главное окно (не считая конечно XEmacs ;)) ---
IDE, которая совмещает кучу разных утилит (например OCamlCVS) +
расширяется через плагины (например общается c XEmacs через
gnuclient);
- XEmacs --- самая главная тулза! ;)))

За кадром остались:
- Zoggy --- построитель графического интерфейса (с использованием
LablGTK);
- DBForge --- генератор кода для доступа к нескольким видам СУБД,
посредством задания схемы (реализован еще не полностью);
- Epeire --- GUI к OCaml debugger;
- MLChat --- графический чат для разработчиков;
- Omom --- графический генератор Makefile'ов;
- Report --- графический описатель/генератор кода для доступа к XML
документам.

Все перечисленные тулзы цепляются к Cameleon с помощью плагинов.

Все это крутится под: Debian Woody R3.0 + IceWM без всяких излишеств
;)) (типа Gkrellm, обоев, и прочих погремушек-свистулек).

Ну теперь, можете пинать... :)))

>>> Просмотр (1024x768, 54 Kb)



Проверено: maxcom

<Но проблем у fprintf я не знаю (не надо про sprintf, ладно?).>
Проблема одна -- отсутствие контроля типов.

<И все-таки - давайте на досуге померяем fprinf vs ostream?>
Давайте померяем.

AC
()
Ответ на: комментарий от AC

А типов в С почти нет:) Конечно, fprintf требует некоей _минимальной_ аккуратности. И то - в 90% случаев gcc выдает warnings на плохие параметры в fprints. Я не знаю, стОило ли его этому учить, но фича есть.

svu ★★★★★
()

Ну у вас и трэд тут образовался!

Резюмируем:

"В итоге, резюме -- если _полностью_ _АДМИНИСТРАТИВНО_ (sic! поскольку соответствующих языковых средств нет) запретить использование class methods и class variables, то проблема ПЭ действительно сходит на нет, поскольку поскольку _неявно_ изменить среду становится невозможным."

Я с Вами полностью согласен. Точка.

Лично для меня и для тех кто занимается реальными enterprise программами это достаточно. Сегодня я вне дискуссии.

P.S. Признаю, что ссылка на мои опусы была правильной. Вот только "закладывать" меня не надо было. А то могут подумать, что я делал себе скандальную рекламу на весьма болезненном самолюбии господина Cоснова.

NikS
()
Ответ на: комментарий от svu

svu (*) (2002-10-17 15:40:48.985):
давайте на досуге померяем fprinf vs ostream?
Я мерил.

Разультат, как и следовало ожидать (если знаешь, как потоки реализованы),
таков - потоки БЫСТРЕЕ, чем fprinf в 2-3 раза, особенно при сложном
форматировании.

P.S.
Терпеть не могу ЦеПП! Но потоки - быстрее. Связано это с тем, что потоки
форматируются компилятором inline, а fprintf - функция, со стеком с переменным
числом аргументов, с рантайм парзением форматной строки... В принципе,
наверное, можно реализовать такой же compiletime механизм, но это уже будет
противоречить стандарту.

Die-Hard ★★★★★
()
Ответ на: комментарий от AC

2AC (*) (2002-10-17 15:46:28.085):
> <Но проблем у fprintf я не знаю (не надо про sprintf, ладно?).>
> Проблема одна -- отсутствие контроля типов.
Ну, тут-то, как раз, проблем нет - почти все современные компиляторы
сыплют варнинги при несоответствии аргументов форматной строке.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

Да, это интересно. Спасибо. Я, правда, все равно хочу попробовать поиграться. Значит, с тех пор, как мы мерили, компиляторы и stl стали лучше. Мы-то еще на борландовском 5.1... Кстати, стек с переменным числом аргументов - ерунда, дешево. А вот парсенье - это да...

svu ★★★★★
()

А вообще задрали вы тут все с вашими объектами и бинами, геттерами и сеттерами. Вот Кобол у нас нынче объектно-ориентированный. И что? Хоть кто-нибудь объекты использует? Нет, ибо они и в xyz не впились. Тем не менее (даже если судить по любимому НикСом дайсу) Кобол держит устойчивый сектор рынка и будет держать. Гы! И никакие побочные эффекты не изменят этого соотношения сил.

anonymous
()
Ответ на: комментарий от NikS

<Вот только "закладывать" меня не надо было. А то могут подумать, что я делал себе скандальную рекламу на весьма болезненном самолюбии>

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

AC
()
Ответ на: комментарий от AC

Официальный протест: Я еще раз настаиваю на нераспространении имиджа господина NikS на все сообщество любителей языка Java.

svu ★★★★★
()
Ответ на: комментарий от AC

Ну, и это тоже не повод. Мне, может, тоже многие изделия IBM нравятся (например, jikes). И сколько кода от IBM лежит в основе xml.apache.org? Так что я и тут протестую.

Не нужно распространять черты характера индивидуума на социум (даже виртуальный), к которому он принадлежит. Такая экстраполяция показывает экстаполирующего с невыгодной стороны:)

svu ★★★★★
()

Позновато, но я все-таки хрюкну.

Хрен там рассуждать про какие - то ПЭ и синглетоны в яве? Академически, не академически... Про JNI приходилось слышать? А пользоваться? После JNI все побочные эффекты похожи на детскую игру в крысу. Причем, заметьте, без JNI явы ПРОСТО НЕ БУДЕТ. Или будет, но в каких-то особо экологически чистых местах, больше похожих на питомник молодняка в зоопарке или институтские кафедры.

Эстеты...

Ле хаим, community

Полуденный Бес

anonymous
()
Ответ на: комментарий от AC

>> а еще и любитель IBM

;))) Неофициальный русский сайт поддержки Eclipse (с примерами моих кодов)

http://javasoft.hotmail.ru

Официально будет открыт 28 Oct 2002 (как вернусь из командировки)

Там будет раздел "лженаука" или (более мягко) "скептицизм" в котором будут использованы материалы из данного трэда (например, ликвидация ПЭ в Java, proof-of-concept Java, практика vs. софистика)

Еще раз спасибо всем, а особенно господину AC ;), за дискуссию.

NikS
()
Ответ на: комментарий от anonymous

Вот это номер! Какое такое JNI? Я делал море жабских проектов. JNI понадобился в 1.5 из них. Инфраструктура жабы сегодня такова, что можно делать ВСЕ (в рамках занятой ею нишы рынка - это существенно), не прибегая к "нативному" коду. Большие application servers/development environments люди делают без строчки нативного кода. А Вы - "питомник"... Нет, Java прекрасно живет без JNI в ПРОМЫШЛЕННЫХ условниях. Единственный источник "нативности" в 90(99?)% проектов - JDK/JRE.

svu ★★★★★
()
Ответ на: комментарий от svu

>> Какое такое JNI?

JNI в J2EE не используется - Вы правы. Примеры Ses, EntityBMP, Entity CMP, Entity CMP2, JMS EJB можно будет качнуть - там нет JNI. JNI2 я описал в предыдущей книге (в приложении).

NikS, http://javasphere.hotmail.ru

NikS
()

Используется или нет - вопрос другой. В общем случае - используется.
Были тут рассуждения о "волевом решении" вопросов, но это из другой оперы. И так понятно, что писать правильно - хорошо, а неправильно - плохо.
Причем, обратите внимание, что JNI - не технология "над языком", а САМ ЯЗЫК. И пока она существует, все рассуждения о "правильности" или "неправильности" явы как ОО языка - это несерьезно.

Полуденный Бес

anonymous
()

2 svu

"Большие application servers/development environments люди делают без строчки нативного кода. А Вы - "питомник"... Нет, Java прекрасно живет без JNI в ПРОМЫШЛЕННЫХ условниях. Единственный источник "нативности" в 90(99?)% проектов - JDK/JRE." - неверно.

Доказываю:
JDBC драйвер к Oracle, шустрый такой, OCI который использует.

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

Если выкинуть из явы ВСЕ, что построено на JNI, то остается настолько мало, что можно аккуратно метелкой в угол и забыть.


Полуденный Бес

anonymous
()
Ответ на: комментарий от anonymous

>> JDBC драйвер к Oracle,

Это проблемы уважаемой фирмы Oracle.

IBM DB2 V8.1 использует новый драйвер 4 типа. (Типы 2 и 3 оставили для совместимости.)

4 тип используют также MySQL, PostrgeSQL и Informix (ныне IBM) (там нет нативного кода в *.so - к счастью нет, ибо в IBM DB2 v7.2 была путаница.)

P.S. Я не сотрудник IBM, я работаю "for IBM", но это я знаю точно - рекомендуется 4 тип без *.so. Сам тестировал - работает начиная с beta2 хорошо.

NikS, http://javasphere.hotmail.ru

NikS
()
Ответ на: комментарий от anonymous

Да, часть языка. Но если она используется в считанных проектах (и даже в них, обычно, - в одном-двух классах) - стОит ли на ее основе считать Жаву не ОО? По-вашему, любой язык, допускающий C-binding - не ОО? Я, кстати, не знаю, умел ли smaltalk подключать что-нибудь "нативное". К сожалению, нынешнее hardware - не ОО. И асм. И язык С. И любой язык, который хочет быть расширяемым за пределы базовой библиотеки [классов] - должен в этом месте создать брешь в ОО. Это жисть. И то, что внешним языком для Жабы выбран С (а не какой-нибудь ОО С++) - это прекрасно. Это традиция, проверенная временем. Приличный байндинг, как показывает история, должен выразаться на C. Короче, в этом месте я не вижу проблемы. Ни идеологической, ни технологической.

Кстати, нужно объяснять, почему JNI "над языком" был бы ничуть не лучше (а в чем-то и хуже)?

svu ★★★★★
()
Ответ на: комментарий от anonymous

Народ _прекрасно_ обходится драйверами 4-го типа. Даже MS дает такие драйверы к MSSQL 2000 (уж они-то явно могли позволить себе "нативность"). Какие другие, аналогичные примеры? Единственный реальный серьезный пример, который я знаю - это реализация Java COMM API. Еще есть IBM SWT. Больше проектов общего назначения общего назначения(не берем работу с контроллерами всяких устройств и другую около-железную деятельность). Statement оставлен: Сегодня Enterpize level Java свободно обходится без JNI.

svu ★★★★★
()
Ответ на: комментарий от anonymous

Да, забыл сказать - у того же Оракла есть драйвера 4-го типа.

svu ★★★★★
()
Ответ на: комментарий от svu

>> умел ли smaltalk подключать что-нибудь "нативное"

Да.

Оставшаяся "в наследство" (legacy) версия Smalltalk IBM/OTI VAST 6.0 умеет подключать C (*.so и *.dll) и ...COBOL.

Кстати "административный запрет" - это хороший пример правильного императивного подхода. Например, DB2 PSM->SQC->C цепочка. Или CSP 4GL в IBM VisualGen.

NikS
()

2 NickS

"Это проблемы уважаемой фирмы Oracle." - а почему, собственно, проблемы? Не вижу проблем.
Я привел этот пример как доказательство того, что в больших проектах очень часто используется JNI, явно или неявно. Без какой - либо оценки этого пути, констатировал факт, так сказать.

2 svu

Я не критиковал ни яву, ни JNI, ни уровень вcтраивания JNI. На яве пишу постоянно и считаю ее очень удачным языком прикладного программирования. Нет у меня желания ее критиковать. JNI приходится использовать на "все сто", специфика такая, и вполне удовлетворен существованием такой возможности. Однако, если быть объективным, то JNI превращает яву из ОО непонятно во что.

Своми постингами я хотел выразить несложную мысль о том, что "за деревьями леса не видно", если говорить об идеологии и концепции. Что там говорить о побочных эффектах, недостатках или достоинствах public элементов, если для меня в JNI они ВСЕ public? Можно считать это проблемой, можно не считать. Мы ж программеры, что захотим, то и наворотим, в конце концов. Постоянная Планка и температура денатурации белка над написанием кода не довлеет. Сплошной солипсизм...

Кстати, если говорить о "стройности концепции" навскидку, то почему для класса java.lang.String операция сложения перегружена? На каком основании?

Так что тут не до академических изысков.

Полуденный Бес

anonymous
()

Я где тут реплики Луговского-"Антихриста", раз OCAML обсуждается? Или AC - это сокращение от AntiChrist?

anonymous
()
Ответ на: комментарий от anonymous

Ну, да. C-binding позволяет делать с любым языком все, что угодно (особенно с учетом inline assembler:). Но подобные вещи принято прощать ОО языкам, применяемым в реальной жизни ("академиков" просьба не беспокоиться).

Про String - "Сколько можно припоминать? Я уже приносил свои извинения!" Это место СТРАННОЕ в Жабе. "Но должно же быть хоть одно странное место".

Академические изыски - вещь полезная. Чтобы напоминать программистам, пашущим землю, что есть еще и небо. И без "академиков" умрет computer science. А без нее и IT не жить. Спасибо им.

svu ★★★★★
()
Ответ на: комментарий от svu

>> И без "академиков" умрет computer science

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

anonymous
()
Ответ на: комментарий от anonymous

<что, наоборот, без тех, кто зарабатывает деньги и с них платит налоги, помрут паразитирующие ученые.>

Ну, так уж прям и паразитирующие. Нет, понятно, что с одной стороны, в computer science тусуется хренова туча людей, занимающихся достаточно бесполезными вещами, а с другой стороны, enterprise-программистам, то есть, по сути, "практическим" инженерам, "достижения" computer science вовсе не нужны, поскольку все технологии для них делаются в корпоративном секторе такими же инженерами. Но, так сказать, enterprise'ы разные бывают, и не всем для счастья достаточно corba с ejb...

AC
()
Ответ на: комментарий от anonymous

>> помрут паразитирующие ученые.

Не помню я у А.Холаба такого. Помню только рассказ, про то, как сам Ален отнес свою книгу на рецензию к теоретику от computer science.

>>> по сути, "практическим" инженерам, "достижения" computer science вовсе не нужны >>>

Как "практик" полностью согласен. Еще раз хочу поблагодарить Вас за идеи.

NikS, http://javasphere.hotmail.ru

NikS
()
Ответ на: комментарий от NikS

Ребята, вы чего? "Практик", отрицающий пользу "академиков" - это Иван, родства не помнящий. Тем более, связанный с IBM (sorry, NikS, похоже, Вам эта связь в этом треде уже печень выела:). "Практикам" не нужны _последние_ достижения. Но завтра они перестают быть последними - тут "практики" ими начинают жить.

Тост - "За единение всех слоев". "Практики" нужны "академикам" как кормильцы (и как "критерий истины"). "Академики" нужны для движения. Чтобы все это дело в болото не превратилось.

ЗЫ Насколько я знаю, бюджет Microsoft Research совсем не маленький...

svu ★★★★★
()

>> Насколько я знаю, бюджет Microsoft Research совсем не маленький...

Господин В.Луговский aka Mauhuur Вам еще и про байки F# расскажет! ;-)

У IBM Research не знаю маленький ли бюджет на новые языки (я не сотрудник IBM), но думаю, что тоже не маленький. Самое "академическое", что они давали сюда на "аутсорсинг" - это Веб-сервисы, что, от академической науки и темы моего дисера весьма далеко.

Насчет Пролога в OTI тоже ничего не знаю, не был я в Ecole de Mines de Nantes, а в NCSU (Triangle Park) кроме Java ничего и не требуется.

NikS
()
Ответ на: комментарий от anonymous

2anonymous (*) (2002-10-18 15:54:59.342):
> ... помрут паразитирующие ученые. Хреново им будет, как сейчас Акимову, Шипову и прочим
> торсионщикам.
Вопрос - а че, им сейчас действительно хреново? Последний раз, как я с Шиповым
сталкивался (около 1994 года), он весьма неплохо себя чувствовал. Мне казалось,
время подобных паразитов в России еще не прошло...

По существу - IMHO, ты подменил по ходу дискуссии понятия. В приведенной тобой фразе
> без тех, кто зарабатывает деньги и с них платит налоги, помрут паразитирующие ученые.
имеется в виду, что ученые, не производя сами реальной (добавленной) стоимости,
живут на деньги налогоплательщиков, производящих (так или иначе) реальные
(материальные) ценности. Ты же этих ученых мешаешь в одну кучу с действительными
"паразитами" типа Геннадия Шипова.

Кстати, сам Шипов вполне отдает (отдавал?) себе отчет в паразитической сущности
своей деятельности, оправдывая ее слоганом "Деньги не пахнут!". Он изо всей торсионной
гвардии - единственный человек, совершенно сознательно использующий рекламу в целях
зарабатывания денег. А то, что он при этом попутно развивает свою устаревшую лет 30 назад
теорию - его дело; право, он честно свои бабки перед телевизором отработал...

Die-Hard ★★★★★
()
Ответ на: комментарий от NikS

Не знаю как IBM Research, а вот когда IBM понадобился migration toolkit после покупки Informix, то в рекордные сроки всю трансляцию все же на OCaml написали... Причем без вопросов.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.