Здравствуйте, mini_root_2, Вы писали:
__>Здравствуйте, mkizub, Вы писали:
M>>http://www.rsdn.ru/Forum/message/2520182.aspx M>>http://www.symade.org/ M>>http://www.symade.com/
__>Ну хорошо если отбросить философствование на тему "Писать самому семантические деревья это круто потому что......", то по сути предлагается писать программы на очередном языке еше более высокого уровня (который в принципе можно обпилить под себя), который потом неким таинственным (или не очень) образом может превращаться во что угодно: в исходники на другом языке, в байт код и т.д.
Я не знаю, можно ли лисп считать языком высокого уровня.
Лисп — это язык мета-программирования. Можно работать на любом уровне, который вы описали через конструкции лиспа.
SOP в этом смысле — полная аналогия лиспа.
__>В результате получаем холявный DSL и пр. радость... __>Сразу высплывает несколько моментов: __>1. Допустим Вы сделали свой собственный DSL идеально описывающий вашу предметную область, __>(кстати а можно ли считать квази-DSL'ем просто библиотеку где классы названы соответствующим образом (Поставщик, Продажа и т.д.) + перегружены все операторы?) __>а потом вам вдруг потребовалось прикрутить что-то стороннее, какие варинаты?:
Приведите пример постороннего, я не въехал.
__> — использовать как есть — но тогда нарущится концепция "нашего маленького самопального языка". __> — сваять обертку — это будет покруче чем строительство комунизма, я там одним глазом посмотрел простенький и маленький пример (типа сделай DSL своими кривыми ручками) — "всего" >500 строк кода (поправьте если ошибаюсь) — если на каждый чих ваять по пол тыщи строк то где же экономия от DSL, если же появяться некие общепринятые стандартные DSL и подогнанные под них фреймворки, то мы вернемся к тому же что имеем сейчас только на более высоком уровне (ведь найдутся люди которых и они не устроят)
СОП не есть DSL программирование. Он включает в себя как создание DSL, так и расширение уже имеющихся.
__>2. В чем прниципиальная новизна? Ведь созданный DSL все равно так или иначе будет ложиться __>на одну из существущих парадигм программирования (ООП, ФП и д.р.).
В СОП нет ничего принципиально нового. Как нет ничего принципиально нового в ООП. И инкапсуляция, и полиморфизм, и наследование — всё это было и раньше.
__>3. Сугубо практические моменты: __> — реальная применимость (где? зачем? в чем преимущество?)
Да везде. __> — наличе библиотек (или возможность цеплять сторонние)
Библиотек чего? Библиотек семантических понятий? Их ещё нет. __> — наличие среды разработки
Пишется. __> — наличие литературы
Напишите
Полностью предполагается написать
а) Среду разработки. Вот она сейчас и пишется, SymADE.
б) Библиотеки семантических понятий.
в) Расширяемой VM построенной на принципах SOP — то есть не байткод, а опять же дерево.
__>В этом плане у скалы есть свои недостатки, но есть и достоинства которые позволяют применить ее уже сейчас. __>P.S. Хотя возможно в будущем из этого что-нибудь да получится, только вот расчитывать на очередную серебрянную пулю я бы не стал...
Все говорят про серебрянную пулю, хотя там прямым текстом написано "это не панацея".
Здравствуйте, Курилка, Вы писали:
К>Всё это напоминает статью Спольски про закон дырявых абстракций, только вот что именно ты предлагаешь? К>Уровни абстракций, DSL и т.п. — это всё прикольно, но что нового в этом твоём СОП и чем оно спасёт отца российской демократии?
Да ничего там нового нет.
И серебрянной пули там нет.
Там идеология программирования, такая-же как ООП, например.
Здравствуйте, aka50, Вы писали:
A>Я почитал статью и мне теперь понятно о чем ты. Ты не просто язык "лучший в мире", ты новую vm задумал, которая порвет аки тузик грелку все .net, erlang и прочие jvm... Красота, но извини, я давно в комунизм не верю. У меня сложилось стойкое ощущение, что то, что сейчас делают эксперты и проектировщики предлагается реализовать в виде некого... хмм... ну в общем рантайма, который разом решает все проблемы. Данный вывод из статьи я сделал фактически на приведенных ниже цитатах (остальное, можно и не читать)
То есть вопрос упёрся в веру?
А во что ты веришь?
И блин, там по русски написано — "это не панацея".
Будет множество проблем, и о тех, что ты пишет — тоже будут.
Шо ж вы из меня идиота строите, шо ж вы за меня домысливаете, что я предлагаю чудодейственное средство, от которого всем будет хорошо — и в этом же меня обвиняете?!
Чем дальше — тем сложнее.
Это так всегда было и всегда будет.
Просто сейчас программирование уже упёрлось в потолок. MS вбухнул в Висту миллиарды долларов, писал её на несколько лет дольше, и сделать в разы меньше, чем обещал.
Они же не со зла. Программирование упёрлось в свой потолок. Нужна следующая технология.
Она не будет панацеей, но она позволит решать те задачи, которые сейчас уже невозможно решить.
A>Это, извините банальный orm и с проблемами оного можно ознакомиться простым поиском по этому форуму по слову hibernate или даже как более продвинутого собрата LINQ, и сразу станет понятно, что это ни разу не решение _всех_ проблем и думать о том, _как_ именно будет меппиться объект нужно (для серьезных приложений в 1млн строк кода) до начала программирования, а не после.
А я разве говорю, что не надо будет думать об этом? Где? Я сказал, что программиста, который использует работу другого программиста — не должно волновать как он её сделал. Что в этом нового, в моих словах? Ты, пользуя библиотечные классы — сильно задумываешься об их внутренних устройстве?
A>По этому я допускаю, что ты хорошо разбираешься в vm, ее проблемах (и проблемах jvm в частности), но вот в проблемах больших проектов и проектирования вообще — извини, похоже не очень.
Здравствуйте, mkizub, Вы писали:
M>Там идеология программирования, такая-же как ООП, например.
ОК, тогда поясни, в чём суть идеологии.
Для меня ООП — "всё есть объекты с состояниями/операциями плюс (возможно) инкапсуляция/наследование/полиморфизм".
Что есть СОП? Или это как "неуловимый Джо"?
Слово "семантика" не является идеей
Здравствуйте, deniok, Вы писали:
D>Э, а примерчик можно? Например, я знаю, как записать алгоритм быстрой сортировки на нескольких языках. Как его записать в виде семантического дерева?
Да так-же. Как во всех тех языках. Компилятор всё равно парсит текст в дерево. Вот так и записывать.
D>
D>Немедленным следствием такого подхода становится возможность выбирать более удобный (в том числе и субъективно, для конкретного программиста) способ отображения кода. Например, одни больше привыкли писать
D>if (a > 0) x = a; else x = 0;
D>а другим более привычна запись
D>if a > 0 then x := a else x := 0 end
D>Дык беда не в конкретном синтаксисе if. Беда в том, что в разных языках if имеет разную семантику! Обязателен или нет else? Является ли вся конструкция if выражением возвращающем значение? Длолжно быть условие строго булевым, или допуcтимы неявные приведения от целых?
D>Любая семантика должна выражаться через синтаксис. И я не представляю, как задать формальный синтаксис суперязыка который ты описываешь. Потому что, если не задавать его строго, то всё потонет в куче мелких нестыковок.
Для семантически разных if-ов можно заводить разные семантические понятия. IfThenElse, IfThenMaybeElse и так далее.
Среда разработки тебе скажет — а тут else выражение должно быть обязательно.
Компилятор тебе скажет — а тут выражение должно быть bool.
Ты хочешь if который тебе будет авто-приводить тип условия к bool?
Напиши свой IfElseAuto extends IfElse, и при преобразовании к стандартным узлам приводи тип, или выдавай ошибку.
На самом деле этот пример с if чисто условный, потому как такой проблемы нет. Я же работаю с деревом, и она у меня не возникла.
Делается if который возвращает значение, имеет опциональный else и требует bool в качестве условия. Авто-преобразования
типов к bool задаются отдельно, не для конкретно if, а вообще в правилах данного проекта.
Преобразование значения возвращаемого if-ом к void делается тоже автоматически, на основе всё тех-же правил.
Мне вот понадобилось ввести отдельный "макро-if", который требует не просто bool выражения, а чтоб оно было
константным во время компиляции. Ну ввёл, ну работает, макросы помогает замечательно писать. Нестыковок не нашёл
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
A>>По этому я допускаю, что ты хорошо разбираешься в vm, ее проблемах (и проблемах jvm в частности), но вот в проблемах больших проектов и проектирования вообще — извини, похоже не очень.
M>И какие ты видишь там основные проблемы?
Отвечу от себя — пардигмы, языки и т.п. — это всё круто, но вот для действительно больших проектов имхо элементарный человеческий фактор играет большую роль. Тупо, если у вас хоть суперинструмент, но если у вас ПМ — дятел, то проект сам собой не родится, а если у руля толковые люди, то они не будут использовать видеомагнитофон, чтоб гвозди забивать
Здравствуйте, mini_root_2, Вы писали:
M>>Большой проект — это всегда смесь противоречивых требований. И надёжно должно быть, M>>и работать быстро, и писать программу надо быстро и дёшево. Эти требования можно M>>разрешить только разделяя программу на разные уровни — внешний (где скрипты рулят), M>>внутренний (где требования промежуточные), ядро (где нужно быстро и надёжно, но M>>которое не такого большого размера, и можно его писать долго и дорого). M>>Писать эти разные части на разных языках — замечательно выходит. M>>Проблемы начинаются, когда эти разные языки пытаются соединить вместе. M>>А у них рантайм разный. И всё, приплыли. Передача данных и управления между M>>разными слоями становится настолько сложной и тормознутой, что это перечёркивает M>>все преимущества разделения проекта на разные части. И мы опять у разбитого корыта.
__>А если воспользоваться связкой Java+Groovy, Java+Scala — ведь они по сути будут __>исполняться в рамках одной JVM, поэтому никаких проблем с взаимодействием быть не должно __>(для груви можно вообще явно сформировать переменные из явы, а кроме того никто не отменял синглтон).
Посмотри на код, генерируемый Scala и ужаснись.
Или вот, пусть мне нужны параметры типов в рантайме. Чтоб я мог написать
List<String> ls = ...;
String[] arr = ls.toArray();
а не
String[] arr = ls.toArray(new String[ls.size()]);
Пусть я использую высокоуровневый язык Foovy, который работает поверх JVM, и который
генерирует код с поддержкой аргументов типов в рантайме. Он как их поддерживает?
Передаёт скрытый аргумент конструктору объекта или методу (параметризированному).
В своём собственным формате передаёт. Вот у Kiev-а есть kiev.stdlib.TypeInfo
для этого. И у Foovy будет foovy.utils.TypeInfo.
А теперь, чтоб это всё заработало вместе. Чтоб явовский List можно было использовать
интероперабельно с Foovy-вским или Kiev-ским. И чтоб Foovy-вский лист можно
было использовать в Kiev-ском коде.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, deniok, Вы писали:
D>>За языком лежит семантическая модель рантайма. От этого никуда не денешься.
M>Модель рантайма тоже можно сделать расширяемой.
Модель рантайма даёт гарантии сохранения своих базовых инвариантов. Как только инварианты поплыли, получаем C++, где гарантии целостности — не более чем джентельменское соглашение.
D>>Языки существуют, чтобы порождать исполняемые программы. Если мы имеем низкоуровневую native модель (стек+heap+статическая память+допустимая явная адресация+OS processes+OS threads), то сколько бы мы ни дизайнили язык — выйдет C++. Более абстрактные модели должны что-то явно запрещать, иначе допустимые хаки на более низкий уровень разрушат целостность абстракций.
M>Похоже, но не совсем так. M>Следующий уровень не может полностью опираться на предыдущий уровень, и быть при этом эффективным. M>Ему нужен предущий уровень, плюс ещё немножко ещё более глубого уровня. И это "плюс ещё немножко" должно быть добавлено к предыдущему уровню.
ИМХО, это просто подъём низкоуровневых граблей. Причём если в языке низкого уровня ты с самого начала понимаешь, что несёшь ответственность за ресурсы, то в высокоуровневом просто задачи другие и стиль работы другой.
M>Если ты напишешь на С GC для JVM, то явовский код, конечно, будет работать. M>Но С-шный код не сможет работать с памятью выделенной явовским кодом, которая контролируется GC. M>Потому как GC сделает heap compaction, и все С-шные ссылки будут показывать в небо. M>Если не добавить поддержку GC в С — то работать нэйтивным функциям будет чрезвачайно тяжело. M>Аналогично, для написания эффективной явовской программы ей нужны низкоуровневые хаки. M>Немного. В соответствии с известным законом 20/80 — 20% кода выполняются 80% времени. M>Вот для этого "ядра" нам нужны низкоуровневые операции. То-же использование ссылки M>вместо массив+индек может съекономить один регистр, и его не надо будет таскать между стеком и процессором, M>и это ускорит выполнение итерации по массиву в разы.
ИМХО — 2 языка и интероп. Потому что иначе опять пойдёт memory leak.
M>Вот одна из задач, которые нужно было решать при написании библиотеки для JVM для мобилок. M>Поступает буффер картинки (битмап), например в RGB888, его надо преобразовать в буффер для экрана M>в формате RGB565. Буффер — явовский массив. Входных форматов десяток. Промежуточных трансформаций M>(добавить/убрать alpha, поменять порядок байт и пр.) тоже достаточно. Если сгенерировать код M>на каждый вариант преобразования — он килобайт 100 займёт, сколько и вся остальная библиотека. M>Тогда пишем код на яве, который чуть более сложен, чем просто копирование байтов. M>Работает ужасно медленно — постоянные проверки на null и границы массива, и это на Thumb M>инструкиях, всё в регистры не влазит — короче тормоз. M>Хорошо, переписали на С — и из-за плясок вокруг GC (и зарегестрировать ссылку, и все ссылки M>volatile, потому как GC может массив подвинуть в памяти в любой момент) — тормозит M>так-же жутко, как и код на яве.
M>Если бы в С добавили поддержку GC, или убрали из явы проверку (только в этом месте) на границы M>и нуль — заработало бы в разы быстрее. А эта операция меряется всеми бенчмарками, сделаешь M>медленно — мобилку не купят, фирма разорится.
В NET, вроде, для этих целей есть возможность сделать pin объекту.
Это как раз даёт третье решение — не на уровне языков, а на уровне реализации интеропа. При передаче ссылки в C она должна pinиться, а при возврате распиниваться. Как в NET точно сделано — не знаю.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, mkizub, Вы писали:
M>>Там идеология программирования, такая-же как ООП, например.
К>ОК, тогда поясни, в чём суть идеологии. К>Для меня ООП — "всё есть объекты с состояниями/операциями плюс (возможно) инкапсуляция/наследование/полиморфизм". К>Что есть СОП? Или это как "неуловимый Джо"? К>Слово "семантика" не является идеей
Расширяемость языка (и создание DSL) как в Lisp, удобство программирования превосходящие WYSIWYG редакторы и современные IDE.
Возможность программировать ближе к человеческим понятиям.
Запись
Logger.getLogger("FooBar").log(WARNING, "Message")
это трансляция на язык программирования пожеланя разработчика "каким-то образом сообщить такое-то предупреждение".
Вся фишка в том, что предлагается так и писать
trace WARNING "Message"
и отдельно написать плагин к компилятору (точнее — среде разработки), который будет это пожелание trace трансформировать
в понятия более низкого уровня, вроде "вызвать функцию такую-то с такими-то аргументами".
Программист не будет переводить задачу не с человеческого описания на конкретный язык с конкретными библиотеками.
Один будет формировать понятия предметной области и либо расширять существующий язык, либо писать отдельный язык.
А другой будет обеспечивать работу первого — заниматься низкоуровневыми деталями.
Это разделение позволит ещё больше структурировать программу. Как сейчас одни пишут библиотеки, а другие их
пользуют, так и предлагается делать, только библиотеки эти будут библиотеками значений, концепций.
Если тебе не нравится пример с trace как слишком простой — вот ещё два примера.
1. Написан отдельный DSL язык для рендерера/редактора SymADE. Позволяет удобно себя редактировать.
Написан быстро, и легко расширяется, так как текстового синтаксиса не имеет.
2. Написано расширения к Java (точнее — к Kiev, который сам расширение явы), для данного
конкретного проекта (SymADE) для работы с деревьями. Позволяет забыть все сложности
добавления и удаления узлов, автоматически отслеживает целостность дерева, вызывает нужные
коллбэки и прочее. Генерирует кучу кода (раза в два превышающую основной код) из простых
аннотаций к декларациям классов.
При этом я вижу то-же, что и раньше,
foo.name = new Ident("name");
а это автоматор преобразовывается в getter/setter вызовы автоматически сгенерированных методов,
которые всю работу по верификации данного кода (включая рантайм) и делают.
Во всём этом нет ничего нового, всё это уже было. И Lisp уже был, и IDE уже были.
Только их вместе не было.
Здравствуйте, mkizub, Вы писали:
M>Посмотри на код, генерируемый Scala и ужаснись. M>Или вот, пусть мне нужны параметры типов в рантайме. Чтоб я мог написать M>List<String> ls = ...; M>String[] arr = ls.toArray(); M>а не M>String[] arr = ls.toArray(new String[ls.size()]);
M>Пусть я использую высокоуровневый язык Foovy, который работает поверх JVM, и который M>генерирует код с поддержкой аргументов типов в рантайме. Он как их поддерживает? M>Передаёт скрытый аргумент конструктору объекта или методу (параметризированному). M>В своём собственным формате передаёт. Вот у Kiev-а есть kiev.stdlib.TypeInfo M>для этого. И у Foovy будет foovy.utils.TypeInfo. M>А теперь, чтоб это всё заработало вместе. Чтоб явовский List можно было использовать M>интероперабельно с Foovy-вским или Kiev-ским. И чтоб Foovy-вский лист можно M>было использовать в Kiev-ском коде.
M>Ага.
Вообще-то в уровневой модели, врехние уровни эксплуатируют нижние а не наооборот (Java->Groovy), во вторых кто мешает не пользоваться динамической типизацией и писать
все по человечески? Кроме того разве Groovy и Scala не позволяют наследовать классы или реализовывать интерфесы Java (например для организации callback'ов, если уж совсем приспичит)? Разве что-нибудь мешает использовать коллекции Java (конечно там ФП-шных извращений, ну да не больно и хотелось...)?
Или при использовании стнадартных жабовских библиотек он туда тоже чего-нибудь передает
в скрытом виде?
P.S. Доберусь до дома — попробую наваять примерчик.
Здравствуйте, Курилка, Вы писали:
A>>>По этому я допускаю, что ты хорошо разбираешься в vm, ее проблемах (и проблемах jvm в частности), но вот в проблемах больших проектов и проектирования вообще — извини, похоже не очень.
M>>И какие ты видишь там основные проблемы?
К>Отвечу от себя — пардигмы, языки и т.п. — это всё круто, но вот для действительно больших проектов имхо элементарный человеческий фактор играет большую роль. Тупо, если у вас хоть суперинструмент, но если у вас ПМ — дятел, то проект сам собой не родится, а если у руля толковые люди, то они не будут использовать видеомагнитофон, чтоб гвозди забивать
Совершенно согласен.
Не панацея. Всех проблем за нас не решит. Не претендую.
Но имея соответствующий инструмент, хороший программист сможет написать такую-же по сложности программу, как 100 индусов.
Хорошая новость хорошим программистам — получать они будут больше денег.
Плохая новость плохим программистам — или они будут работать над своим профессиональным ростом, или пусть идут в дворники.
Шутка.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
A>>Красота, но извини, я давно в комунизм не верю. У меня сложилось стойкое ощущение, что то, что сейчас делают эксперты и проектировщики предлагается реализовать в виде некого... хмм... ну в общем рантайма, который разом решает все проблемы.
M>То есть вопрос упёрся в веру? M>А во что ты веришь?
В здравый смысл и в разнообразие мира. А так же в отсутствие универсальных решений.
M>И блин, там по русски написано — "это не панацея".
Угу, но вся остальная статья противоречит этой мысли... M>Будет множество проблем, и о тех, что ты пишет — тоже будут.
Они и сейчас есть. Что измениться? Сейчас тоже есть "семантика" слова "таблица", но к сожалению ее очень по разному воспринимают oracle, mssql и berkleydb. И никуда ты от этого не денешься (ну если конечно не победит всех ms и тогда будет один только mssql, но тогда и СОП не нужен, достаточно будет .net-а)
M>Чем дальше — тем сложнее. M>Программирование упёрлось в свой потолок. Нужна следующая технология.
Уперлось оно в потолок возможностей человека, а не технологий... На текущий момент сложности систем таковы, что начинают превышать возможности человека, а следовательно никакие костыли в виде некоей новой парадигмы не помогут.
M>А я разве говорю, что не надо будет думать об этом? Где? Я сказал, что программиста, который использует работу другого программиста — не должно волновать M>как он её сделал. Что в этом нового, в моих словах?
Вот именно, что проблема в orm в том, что надо постоянно держать в голове _как_ то или иное действие выполняет orm. Именно _как_.
M> Ты, пользуя библиотечные классы — сильно задумываешься об их внутренних устройстве? обязательно! В том и состоит ценность меня, как профессионала — я знаю (иногда правда приблизительно) как работает любая технология, которую я использую. Иначе я не смогу правильно спроектировать нормальную систему.
A>>По этому я допускаю, что ты хорошо разбираешься в vm, ее проблемах (и проблемах jvm в частности), но вот в проблемах больших проектов и проектирования вообще — извини, похоже не очень. M>И какие ты видишь там основные проблемы?
Проектирование и взаимодействие.
Например твоя мысль:
Передача данных и управления между
разными слоями становится настолько сложной и тормознутой, что это перечёркивает
все преимущества разделения проекта на разные части. И мы опять у разбитого корыта.
Она отлично иллюстрирует мою мысль: при проектировании и программировании нужно думать обо всех уровнях сразу, а не
программиста, который использует работу другого программиста — не должно волновать как он её сделал.
Ибо когда так думают, тогда и начинается тот ужас, о котором ты говоришь.
[cut]
M>Во всём этом нет ничего нового, всё это уже было. И Lisp уже был, и IDE уже были. M>Только их вместе не было.
DSL вижу, идеи — не вижу.
По поводу DSL тут были похожие идеи — про языковоорентированное программирование.
А то что можно графику использовать дак это понятно, только на практике текст имхо много гибче и универсальней.
Здравствуйте, deniok, Вы писали:
M>>Вот одна из задач, которые нужно было решать при написании библиотеки для JVM для мобилок. M>>Поступает буффер картинки (битмап), например в RGB888, его надо преобразовать в буффер для экрана M>>в формате RGB565. Буффер — явовский массив. Входных форматов десяток. Промежуточных трансформаций M>>(добавить/убрать alpha, поменять порядок байт и пр.) тоже достаточно. Если сгенерировать код M>>на каждый вариант преобразования — он килобайт 100 займёт, сколько и вся остальная библиотека. M>>Тогда пишем код на яве, который чуть более сложен, чем просто копирование байтов. M>>Работает ужасно медленно — постоянные проверки на null и границы массива, и это на Thumb M>>инструкиях, всё в регистры не влазит — короче тормоз. M>>Хорошо, переписали на С — и из-за плясок вокруг GC (и зарегестрировать ссылку, и все ссылки M>>volatile, потому как GC может массив подвинуть в памяти в любой момент) — тормозит M>>так-же жутко, как и код на яве.
M>>Если бы в С добавили поддержку GC, или убрали из явы проверку (только в этом месте) на границы M>>и нуль — заработало бы в разы быстрее. А эта операция меряется всеми бенчмарками, сделаешь M>>медленно — мобилку не купят, фирма разорится.
D>В NET, вроде, для этих целей есть возможность сделать pin объекту. D>Это как раз даёт третье решение — не на уровне языков, а на уровне реализации интеропа. При передаче ссылки в C она должна pinиться, а при возврате распиниваться. Как в NET точно сделано — не знаю.
Не получается. GC который tolerate неперемещаемые объекты в хипе — в разы хуже работает, из-за короткоживущих объектов.
Это уже оверхед на всю программу, которая, по идее, не должна страдать из-за этого куска кода.
Нужен явовский код, который выделяет буфер под картинку должен использовать другой кусок хипа, где
объекты не перемещаются. Или компилятор С, который будет генерировать стековые карты, для GC.
То есть высокоуровневому языку нужен доступ к более низко-уровневым фичам платформы,
или низкоуровневый язык должен озаботится проблемами более высокоуровневого.
Вот другая задача.
По явовским правам доступа к private и package-private членам класса доступа извне нет.
А нам нужно было. Ну, мы же JVM писали, нам нужно было позарез. Это же наши классы,
и классы в другом package тоже были наши, мы их пользователям не показывали.
А доступиться не могли.
В SOP эта проблема решается элементарно и красиво — вводится ещё одно право доступа,
какой-нибудь privilaged, или system-library-public. А вместо этого были написаны
тонны кода и пляски с бубном в build скриптах, чтоб они вначале генерировали стабовские
классы где эти члены были public, потом компилировались библиотеки, и потом стабовские
классы подменялись стандартными.
Можно долго смеятся, но именно эти проблемы и были у нас самыми больными при написании
кода. Чего только стоила куча скриптов, которые строили проект. А из-за этих плясок
с построением было невозможно использовать Eclipse или что-то аналогичное. А из-за
этого производительность работы падала в разы, не говоря уже о том, что новые программисты
тратили минимум год, чтоб научится этим билдом пользоваться и разобраться с кодом без IDE.
Такие мелкие и частные проблемы потянули такие сложности в разработке
SymADE для этого пишется. Чтоб программист сосредоточился над задачей, а не вынужден
был плясять с бубном вокруг частных проблем.
Здравствуйте, aka50, Вы писали:
A>>>Красота, но извини, я давно в комунизм не верю. У меня сложилось стойкое ощущение, что то, что сейчас делают эксперты и проектировщики предлагается реализовать в виде некого... хмм... ну в общем рантайма, который разом решает все проблемы.
M>>То есть вопрос упёрся в веру? M>>А во что ты веришь? A>В здравый смысл и в разнообразие мира. А так же в отсутствие универсальных решений.
В 15 веке математики изобрели способ записи буквами и операциями. И если до того умножение и деление учили в университетах, и максимальным достижением было решение квадратных и кубических уравнений, то потом мы поимели просто колоссальное развитие всей науки. Конечно, запись формул — это не панацея, к этому ещё нужен человек. Но ведь факт — простое изменение синтаксиса привело к таким значительным результатам.
M>>И блин, там по русски написано — "это не панацея". A>Угу, но вся остальная статья противоречит этой мысли... M>>Будет множество проблем, и о тех, что ты пишет — тоже будут. A>Они и сейчас есть. Что измениться? Сейчас тоже есть "семантика" слова "таблица", но к сожалению ее очень по разному воспринимают oracle, mssql и berkleydb. И никуда ты от этого не денешься (ну если конечно не победит всех ms и тогда будет один только mssql, но тогда и СОП не нужен, достаточно будет .net-а)
M>>Чем дальше — тем сложнее. M>>Программирование упёрлось в свой потолок. Нужна следующая технология. A>Уперлось оно в потолок возможностей человека, а не технологий... На текущий момент сложности систем таковы, что начинают превышать возможности человека, а следовательно никакие костыли в виде некоей новой парадигмы не помогут.
Так человек есть составная часть этих технологий. Если бы не человек, с его ограниченностью в этом месте — мы бы до сих пор писали в машинных кодах. Технология кодирования в машинных кодах ведь себя до сих пор не исчерпала, не считая человеческого фактора.
M>>А я разве говорю, что не надо будет думать об этом? Где? Я сказал, что программиста, который использует работу другого программиста — не должно волновать M>>как он её сделал. Что в этом нового, в моих словах? A>Вот именно, что проблема в orm в том, что надо постоянно держать в голове _как_ то или иное действие выполняет orm. Именно _как_.
M>> Ты, пользуя библиотечные классы — сильно задумываешься об их внутренних устройстве? A> обязательно! В том и состоит ценность меня, как профессионала — я знаю (иногда правда приблизительно) как работает любая технология, которую я использую. Иначе я не смогу правильно спроектировать нормальную систему.
Ты знаешь приблизительно как оно на следующем уровне. А на ещё более низком? А какой алгоритм оптимизации использует компилятор кода собирающий оракловскую базу данных — ты знаешь?
А как используются регистровые файлы и предсказание ветвлений в CPU исполняющему оракловскую базу данных — ты лично много об этом знаешь, и как часто задумываешься при написании
SQL коммад? Ведь ты же используешь эти технологии, ты используешь память и CPU — но имеешь ли ты в виду все эти тонкости набирая свой SQL код?
A>>>По этому я допускаю, что ты хорошо разбираешься в vm, ее проблемах (и проблемах jvm в частности), но вот в проблемах больших проектов и проектирования вообще — извини, похоже не очень. M>>И какие ты видишь там основные проблемы? A>Проектирование и взаимодействие. A>Например твоя мысль: A>
A>Передача данных и управления между
A>разными слоями становится настолько сложной и тормознутой, что это перечёркивает
A>все преимущества разделения проекта на разные части. И мы опять у разбитого корыта.
A>Она отлично иллюстрирует мою мысль: при проектировании и программировании нужно думать обо всех уровнях сразу, а не A>
A>программиста, который использует работу другого программиста — не должно волновать как он её сделал.
A>Ибо когда так думают, тогда и начинается тот ужас, о котором ты говоришь.
"Не должно" в идеале, конечно. И не всегда. Когда мы пишем ядро нашей программы — конечно волнует более низкий уровень.
А когда основной код — то волнует только ядро, а не ещё более низкий уровень. И желательно, чтоб и ядро не волновало.
Вот, пусть архитекторов волнует, а кодописателей не волнует. В идеале.
Здравствуйте, Курилка, Вы писали:
M>>Во всём этом нет ничего нового, всё это уже было. И Lisp уже был, и IDE уже были. M>>Только их вместе не было.
К>DSL вижу, идеи — не вижу. К>По поводу DSL тут были похожие идеи — про языковоорентированное программирование.
Да, JetBrains реализует очень похожую идею. Только они не идут в реализации до конца.
Они выходной код генерируют как текст (явовский), и опять попадают в узкое горлышко.
Конечно, там ниже всегда будет узкое место, всё равно прийдётся в конечном итоге
генерировать машинные комманды.
Идея SOP в том, чтоб убрать промежуточные узкие места.
Чтоб не надо было извращаться генерируя явовский код.
Чтоб не надо было извращаться над JIT компилятором, который по байткоду пытается понять, что ж там
было в исходном коде написано, а то иначе оптимизация не удаётся.
К>А то что можно графику использовать дак это понятно, только на практике текст имхо много гибче и универсальней.
У меня есть спецификация узла для loops,
ForStat {
Stat init;
Expr cond;
Block body;
Expr iter;
Label lblcnt;
Label lblbrk;
}
и мне к нему надо специфициоровать Control/Data Flow. Я это делаю как
@dflow(out="lblbrk") private static class DFI {
@dflow(in="this:in") ASTNode init;
@dflow(in="init", links="iter") ENode cond;
@dflow(in="cond:true") ENode body;
@dflow(in="body") Label lblcnt;
@dflow(in="lblcnt") ENode iter;
@dflow(in="cond:false") Label lblbrk;
}
Как ты думаешь, что удобнее было-бы, нарисовать стрелочками граф, или разбираться в этом коде?
А у него ещё нет проверки на правильность строк в аннотациях, если что — в рантайме баги вылазят
Первое, что сделаю, когда редактор стрелки научится рисовать — перепишу все эти control flow
красиво.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
M>В 15 веке математики изобрели способ записи буквами и операциями. И если до того умножение и деление учили в университетах, и максимальным достижением было решение квадратных и кубических уравнений, то потом мы поимели просто колоссальное развитие всей науки. Конечно, запись формул — это не панацея, к этому ещё нужен человек. Но ведь факт — простое изменение синтаксиса привело к таким значительным результатам.
Естественно, потому, что семантика понятия "3 коровы" очень сложно без синтаксиса объясняется... ты же предлагаешь работать с чистой семантикой и кто-то ( к стати кто?) должен под эту семантику еще и что писать (ifelse ifMaybeElse, а кто-то это обзовет ifAMozhetINet).
A>>Уперлось оно в потолок возможностей человека, а не технологий... На текущий момент сложности систем таковы, что начинают превышать возможности человека, а следовательно никакие костыли в виде некоей новой парадигмы не помогут. M>Так человек есть составная часть этих технологий. Если бы не человек, с его ограниченностью в этом месте — мы бы до сих пор писали в машинных кодах. Технология кодирования в машинных кодах ведь себя до сих пор не исчерпала, не считая человеческого фактора.
Нет, он не является частью этих технологий. Проблема в объеме знаний и понятий, которыми требуется оперировать человеку. При чем это практически константа. По этому решается эта проблема повышением абстракций, но чем выше абстракция, тем сложнее вернуться на более низкий уровень. Но чем толще этот уровень абстракций, тем более сложной становится система и все больше возникает ньюансов ( а как известно, в них собственно и проблема). Т.е. я утверждаю, что человечество добралось до потолка абстракций, которые оно в силах понимать и которыми способно оперировать.
асм -> абстрации на уровне регистров и адресов: при росте программы человек не в состоянии охватить ее всю, т.к. слишком много абстракций типа регистр нужно держать в голове (в том числе и то, как работает процессор и где какие штрафы лепит p4 за неправильный доступ к памяти)
с -> абстакция от железа на уровне функций: с ростом софта увеличивается кол-во функций, следовательно начинается проблема с пониманием взаимосвязей этих функций, т.к. они не связаны между собой (ооп стиль с контекстами не смотрим пока), при этом мы все еще можем думать на уровне регистров (модификатор register)
С++ -> объекты. но надо рулить временем их жизни, когда кол-во объектов превышает определенный порог, система останавливается в развитии (мы все еще думаем о памяти, но уже мало о регистрах и еще меньше о штрафах процессора)
jvm -> виртуальная машина: абстрагируемся от управления объектами, но опять же при достижении определенной сложности взаимосвязей между объектами развивать все тяжелее. При этом за такую гибкость мы платим абстракцией вообще от процессора как такового. Он нас больше не особо волнует, это уже задача компилятора или/и jit-а
Дальше абстрагироваться не от чего, можно только сахарить язык (вводить разные dsl-и которые консолидируют объекты в более крупные сущности, но! мы начинаем терять эффективность, т.к. для создания эффективного приложения даже программируя на некоем dsl-е все равно _нужно_ представлять как это работает на нижнем уровне)
Т.е. в общем проблема разработки софта — в его комплексности. Например любой софт на прорядок сложнее чем последняя Audi (в ней вроде около 300тыс деталей), но любой сложный проект легко переплюнет по кол-ву объектов и форм взаимодейтсвий этих объектов. И при этом Audi нынешняя не идет не в какое сравнение с ауди предыдущих моделей. Т.е. это еще раз иллюстрирует то, что при достижении некого порога кол-ва объектов, проект становится трудноуправляемым, т.к. не существует одного человека осознающего картину в целом до мельчайших деталей (ровно как нет и надежного способа консолидации нескольких мозгов в один, работающих с разделяемыми знаниями, т.е. опять же получаем проблему интеропа (оно же взаимодействие в команде и документация).
M>Ты знаешь приблизительно как оно на следующем уровне. А на ещё более низком? А какой алгоритм оптимизации использует компилятор кода собирающий оракловскую базу данных — ты знаешь? M>А как используются регистровые файлы и предсказание ветвлений в CPU исполняющему оракловскую базу данных — ты лично много об этом знаешь, и как часто задумываешься при написании M>SQL коммад? Ведь ты же используешь эти технологии, ты используешь память и CPU — но имеешь ли ты в виду все эти тонкости набирая свой SQL код?
Это проблема слабости человека, точнее в кол-ве объектов которыми он оперирует. Ибо кол-во этих объектов растет в геометрической прогрессии... Но на самом деле любой профессиональный ораклист знает (и программист orm-а тоже вынужден многое из этого знать, и архитектор тоже):
1. Как работает оптимизатор
2. Как устроенов хранилище данных, что такое tablespace, extent, block и как это все взаимосвязано
3. Он отлично представляет себе как работают блокировки, кеширование и что такое roundtrip
4. В конце концов сколько у меня процессоров (например parallel requests)
Как видишь, довольно глубоко, но если начинать складывать в кучку все эти объекты, то получим некую величину которую человек осознать не в силах, вот собственно и есть предел сложности. При этом работая с бд мы и так работаем практически с объектами предметной области (счет, платеж, клиент) т.е. выше собственно абстрагироваться некуда (ну если только сделать одну большую кнопку "шоб работало" и оно само догадалось что мы хотим).
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Курилка, Вы писали:
M>Первое, что сделаю, когда редактор стрелки научится рисовать — перепишу все эти control flow M>красиво.
нуну... текст тем и отличается, что позволяет разобраться, а вот визуальное представление
во первых элементарно менее компактно (т.к. требует разместить все в одном месте, иначе ты либо потеряешь конкретику, либо стрелки будут уезжать за экран что не способствуем лучшему пониманию кода)
во вторых требует дополнительного кодирования (например цветами и формой) чтобы можно было ориентироваться
M>Вот другая задача. M>По явовским правам доступа к private и package-private членам класса доступа извне нет. M>А нам нужно было. Ну, мы же JVM писали, нам нужно было позарез. Это же наши классы, M>и классы в другом package тоже были наши, мы их пользователям не показывали. M>А доступиться не могли. M>В SOP эта проблема решается элементарно и красиво — вводится ещё одно право доступа, M>какой-нибудь privilaged, или system-library-public. А вместо этого были написаны M>тонны кода и пляски с бубном в build скриптах, чтоб они вначале генерировали стабовские M>классы где эти члены были public, потом компилировались библиотеки, и потом стабовские M>классы подменялись стандартными.
Кстати, в Хаскелле и вообще в языках с dependent type, это можно сделать с помощью системы типов, не теряя изоляции инвариантов. Как раз вчера lomeo у меня в журнале об этом писал.
Здравствуйте, aka50, Вы писали:
A>Т.е. в общем проблема разработки софта — в его комплексности. Например любой софт на прорядок сложнее чем последняя Audi (в ней вроде около 300тыс деталей), но любой сложный проект легко переплюнет по кол-ву объектов и форм взаимодейтсвий этих объектов. И при этом Audi нынешняя не идет не в какое сравнение с ауди предыдущих моделей. Т.е. это еще раз иллюстрирует то, что при достижении некого порога кол-ва объектов, проект становится трудноуправляемым, т.к. не существует одного человека осознающего картину в целом до мельчайших деталей (ровно как нет и надежного способа консолидации нескольких мозгов в один, работающих с разделяемыми знаниями, т.е. опять же получаем проблему интеропа (оно же взаимодействие в команде и документация).
Полностью согласен — повышение уровня абстракций это путь в никуда, хотя другого нет.
Этот путь позволяет одержать тактическую победу, но в конечном счете оборачивается усложнением системы понятий которыми вынужден оперировать человек при этом ресурсы человека не меняются.
Если так подумать то программисты 50-x были в общем то счастливми людьми — все просто и понятно, при то что их было мало и задачи перед ними стояли весьма серьезные.
А сейчас даже в провинциальном проекте средних размеров приходится использовать огромное количество различных технологий, баз данных, фреймворков. Причем у автора каждого из них есть свои тараканы в голове и зачастую даже непонятно как это все объединиить (учитывая замечательную ситуацию с документацией для ряда проектов). При этом надо думать над тем чтобы это все крутилось под win/lin и не потребляло слишком много памяти + перманентный дедлайн.
Товарищ тут все толкует про семантику, по сути все это многообразие предлагается завернуть в еще одну обертку. В действительности сейчас достаточно полное и хорошее описание предметной области можно получить с помощью того же ООП, но это не никак не решает проблемму зоопарка.
обязательно! В том и состоит ценность меня, как профессионала — я знаю (иногда правда приблизительно) как работает любая технология, которую я использую. Иначе я не смогу правильно спроектировать нормальную систему.
