Здравствуйте, Дм.Григорьев, Вы писали:
M>>С тех пор, как появились языки с multimethods, то есть диспатчингом по рантайм типу нескольких аргументов.
ДГ>Имеется в виду pattern matching? Если нет, то в чём отличие?
Имеются в виду multimethods. Они легко находятся в google. В чём смысл я уже написал — диспатчинг метода по рантайм типу нескольких аргументов.
Для примера — virtual методы делают диспатчинг по рантайм типу только одного аргумента (this).
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Имеется в виду pattern matching? Если нет, то в чём отличие?
Если кратко, то примерно так выглядит:
public class Circle extends Figure...;
public class Ball extends Figure...;
public class Triangle extends Figure;
public class Something
{
public void doSomething(Circle circle)
{
System.out.println("Circle!");
}
public void doSomething(Ball ball)
{
System.out.println("Ball!");
}
public void doSomething(Figure fig)
{
System.out.println("A figure!");
}
}
Figure fig=new Ball();
//Самое интересное здесь:new Something().doSomething(fig); //Печатает "Ball!"
Здравствуйте, Trean, Вы писали:
T>Почему бы основной толпе не писать и дальше на Java, а профессионалам (ключевые или библиотеки, логика которых наиболее лаконично может быть выражена на другом, не Java языке) не перейти на Scala, если она действительно повысит их производительность?
Для библиотек как раз почти пофиг на каком они языке.
T>И кто потом будет разгребать все то, что наваял профессионал на очередном write-only языке, когда он уйдет? Я изредка заглядываю в ветку декларативного программирования и вижу, что там за код в примерах пишут, и где столько профи найти, чтобы написать целиком большой продукт?
Там вполне понятный код, просто синтаксис обычно немного странный. Например, тот же Erlang — исключетельно простой язык, проще даже чем Java. Просто там синтаксис не С-подобный.
Кроме того, многие возможности реально улучшают читабельность. Например, pattern matching часто заменяет громоздкие и сложночитаемые visitor'ы. Да даже простой foreach в Java 1.5 помогает читать код.
XJava,
XJ>>Java — платформа, которая решает большие бизнес задачи успешно уже многие годы. XJ>>Не мудро говорить, что из-за каких-то конструкций языка, которые кому-то не нравятся, Java загнется. XJ>>Сколько было языков и сред, которые загнулись, хотя были весьма красивы.
XJ>Кстати, для Java можно писать на Ruby и Python. Вперед использовать красоту!
Написал, отправил, удалил как ошибочное. Ну его нафиг, позориться только. А ты давай конкретные примеры, как ты собираешься формализовывать язык описания семантики. Сказки рассказывать все горазды.
rsn81,
R>Обратил внимание, что в Scala подчистили маленькие несуразности, которые сейчас исправлены даже в C#, а в Java — нет. К примеру, в отношении порядка инициализации членов класса и вызова родительских конструкторов, как следствие, частичное (но оно стоит того) решение проблемы безопасной инициализации, писал об этом здесь: Re[12]: Virtual member call in constructor. Плохо?
Меня вообще бесит правило, что super должен быть в первой строчке. Из-за этого иногда приходится лепить всякие идиотские методы типа init, а конструкторы оставлять простыми заглушками.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Написал, отправил, удалил как ошибочное. Ну его нафиг, позориться только. А ты давай конкретные примеры, как ты собираешься формализовывать язык описания семантики. Сказки рассказывать все горазды.
Одну такую сказку пишет Чарльз Симони, под названием Intentional Programming. Про неё мало что известно, хотя статейки нарыть можно — http://c2.com/cgi/wiki?IntentionalProgramming
Другую пишут в JetBrains, под названием MPS. Там претензий намного меньше, но можно попробовать. http://www.jetbrains.com/mps/ Мне у них многое не нравится, в частности они так и не решили проблему с неудобством редактирования, ну и слишком у них на Java всё завязано.
Я делаю SymADE — http://www.symade.org/
Собственно, формализировать семантику не особенно нужно. Нужно сделать стандартный способ представления узлов AST дерева (только не abstract syntax tree, а abstract semantic tree). А семантику задавать через правила преобразования в набор "примитивов", неких стандартных узлов AST. Для простых преобразований сгодится и некий язык, скажем что-то вроде AspectJ. Для более сложных вещей нужно будет писать плагин к компилятору, который будет заниматься трансформацией дерева. Понятно, что дизайн компилятора будет сильно отличаться от обычного, так как в обычных слишком много самантики не задаётся правилами, а вшито в код. Но это можно сделать, в частности, так и делается в вышеприведённых примерах.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, ralfeus, Вы писали:
R>>Прошу прощения за глупый вопрос. А почему у меня напечатало Figure? C>А это из-за того, что в Java нет мультиметодов
C>Просто я показал как они бы выглядели, если бы реально были.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Мне лень искать, где и кто недавно флеймил на тему графических-диаграммных средств разработки, но от фразы "не ограничиваться текстовым синтаксисом" за версту разит этим бредом. Так что не правильно он говорит. <..> Я бы с удовольствием посмотрел на конкретные инструменты сторонников "не только текстового синтаксиса". Чиста чтобы оценить, на сколько порядков они замедлят мне мыслительный процесс.
Я уже писал. За подробностями к Тони Бьюзену. Инструмент называется Mind Map. Естестественно, что как и любой инструмент, он требует времени на изучение для эффективного использования. О кое-каких инструменах рассказывает Наполеон Хилл, но там немного из другой оперы.
Есть ещё kawa: хочешь — "схемь", но, ясное дело, с некоторым оверхедом. Можно "схемить" с типами — оверхеда намного меньше. Можно писать практически на Java в S-expr совсем без оверхеда, но с макрами и проч.
Ну и можно "скриптить" и REPL-ить — если очень надо или "для пробы"
Но это, конечно, для тех, кому это (списки-списки-списки...) подходит.
Здравствуйте, Alex EXO, Вы писали:
AE>На блоге расписал мысль несколько подробнее. AE>http://zay-note.blogspot.com/2008/01/blog-post.html
Спасибо! То, о чем смутно догадывался последние 2 года, но сам себе даже четко объяснить не мог, расписали по полкам. Особенно заинтересовала классификация в конце, раскатал по ней все компании, в которых работал: низкий старт был в "команде", которая через 3 года трансформировалась в "программистскую фабрику"; когда поднаторел и наскучило, пошел искать счастья в "орде"; не понравилось, решил, что поможет смены одной "орды" на другую — не помогло; разочаровался в "ордах", теперь ухожу в "программистскую фабрику", большие надежды, что это будет все же "команда".
Давно "не виделись"
M>Человек думает образами. Образ — это не обязательно картинка. Образ это образ. Символ, понятие. Когда компьютеру подсовывают картинку — он ещё должен понять, что там нарисовано, стол или глаз или буквы. Это называется распознаванием образов, так ведь? Вот этими образами человек и думает. Потом это передаётся в осознавание — в виде слов, кто умеет может в виде картинок и т.п.
"Положение": Абстрактная значимая детеминированная информация может обрабатываться человеком только в виде текста. Может конечно и в не текстовом виде, но только с предварительным текстовым описанием её или составляющих её частей.
M>Когда математик думает, он думает в образах интегралов, матриц и т.п. Когда врач думает, он тоже думает в образах связанных с болезнями, органами и т.п.
Эти "образы" вообще "существуют" только в сознании каждого конкретного человека. Обмениваться ими можно только "материализовав" их. В большинстве случаев для этого текст подходит наилучшим образом (за исключением технических чертежей, анатомических и прочих атласов и т.п., хотя это не противоречит "Положению"). Для описаний абстрактных действий (алгоритма в том числе) — альтернативы пока нет. Да, хочу оговориться: текст — это не только ASCII, это, грубо говоря, unicode с любыми расширениями, которые вы стандартизируете в пределах некоторого сообщества.
M>Чтоб компьютер мог автоматизировать умственную деятельность человека — он тоже должен уметь думать в образах. Что и делают компиляторы — они преобразуют текст программы в некое внутреннее представление, и в терминах этого внутреннего представления думает, то есть оптимизирует программу, переводит её на язык для CPU, чтоб тот исполнил программу.
И нафиг эта каша вместо "язык -> AST -> [маш]код"? Хотя и это справедливо не для всех реализаций.
M>Проблема нынешнего способа программирования в том, что этот набор образов (языка программирования) фиксирован.
Да ну? Любого-любого языка? И что фиксировано: синтаксис или семантика? И ни один язык не позволяет расширить их?
M>И фиксирован синтаксисом текста программы. Это звучит бредово, но так и есть — синтаксис, внешнее представление, ограничивает способ "думать" и набор понятий компьютера (компилятора).
С чего ты взял ,что это "бредово"? Ты не можешь строить дом из мед. препаратов, как и не можешь лечить людей промышленной продукцией группы А Так и с языком — ты не можешь "выйти" за его пределы, но у разных языков разные пределы. И не везде это _именно и только_ "синтаксис текста".
M>Фактически, человек точно так-же ограничен своим языком, и освоение новой профессиональной области начинается с изучения терминологии, а уже потом человек тренируется думать в этих новых терминах.
Так что в этом бредового? Или сначала изобретаем проблему чтобы затем с ней доблестно бороться?
M>Для компьютеров аналогично — поскольку мы тут про яву, то вспомни, сколько времени заняло введение новых фич в яву? Inner классы, да простейшие enum-ы... ГОДЫ. Почему так долго? Изменить один компилятор не тяжело, но кому нужны эти изменения? Нужно изменить все связанные средства программирования, от анализаторов кода и отладчиков до всех этих IDE (эклпису, идею, нетбинс и пр.). Потому как все они связаны между собой синтаксисом. У них разные внутренние представления явовской программы, а между собой они взаимодействуют по стандарту текстового синтаксиса.
И кто в этом виноват? Если бы javac был открыт и документирован вместе со своим AST-ом с самого начала и "торчал этими потрохам наружу", кто бы стал изобретать велосипеды? Или месье совершенно не знаком с gcc, который расшифровывается совсем не как GNU C compiler?
M>Способ программирования о котором я говорю — это стандартизация семантики, некоего "внутреннего представления".
И нафиг новый "булшит", если есть AST?
M>Программирование прямо в семантических понятиях, единых для всех средств программирования. Если ты себе для проекта добавляешь новое понятие — с ним смогут работать все средства программирования... Например, мы вводим в наш набор понятий новую абстракцию "перечислымый тип". Мы её описываем неким способом понятным всем нашим средствам программирования — от редактора до отладчика, всем. Но! Редактор то понимает, что это enum, а вот как его редактировать и отображать — он не знает. И это надо будет редактору описать. Если нужно, а по умолчанию он может использовать некий "универсальный" способ представления (скажем, как в lisp — всё отображается в виде списка). Компилятор будет понимать, что вот тут стоит некий enum, но он не будет знать что с ним делать. Надо ему или рассказать как enum-ы выражаются через известный ему набор понятий (скажем, как в java enum-ы компилируются в классы), либо он должен поддерживаться непосредственно target platform, и надо будет поправить backend компилятора.
А может таки не строить в песочнице "три в одном"? Зачем редактору AST, если он изменяет текст программы? А отображение/создание новой конструкции может никоим образом не соотносится с её действиями.
Да и не надо "городить" "один AST во все языки". Либо у вас все языки получатся а-ля лисп (с типизацией и проч.), либо на некоторых языках простейшие действия будут отражаться страницами текста. И это ничего не будет говорить о том, что же на самом деле будет делать компьютер.
M>Графически-диаграммные средства разработки тоже имеют к этому некое отношение. В том смысле, что отображать программу вы можете как угодно. Она в компьюрете непосредственно в его внутреннем представлении хранится, а отображение/редактирование могут быть любыми. Хочешь — текстом. Хочешь — стрелочки рисуй. Хочешь — в UML диаграммах.
Бррр, в страшном сне не приснится....
Да, и я так и не смог понять, почему дерево нельзя создавать/изменять в текстовом виде (в виде списков или с отступами — как кому нравится).
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, mkizub, Вы писали:
M>>И не ограничиваться текстовым синтаксисом. Идти в сторону человека — иначе компьютер не сможет автоматизировать его умственную деятельность. А человек не думает в текстовом синтаксисе.
ДГ>Позвольте поинтересоваться, а в каком синтаксисе, по-вашему, думает человек? Вот Вы, когда программу продумываете, в каком виде она у Вас в голове крутится?
Лично у меня — в графическом (блок схемы, activity diagrams, классовые диаграммы, диаграммы последовательностей и тому подобное).
Наиболее удобная (по моему опыту) нотация для изображения процессов — язык ДРАКОН.
Здравствуйте, Аноним, Вы писали:
А>Bruce Eckel написал вчера в своем блоге, что все эти генерики и замыкания доведут жабу до цугундера. Ничего хорошего не получится и Java умрет. Жаль.
А>Шо делать? Си-шарпать?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
