Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
M>Поэтому и не мэйнстрим, а маргинальный язык, хотя труда в него вложили немеряно, вплоть до M>аппаратных лисповских машин.
Очень смешно.
M>Собственно, лисп и надо брать за начальную точку расширяемого языка. Только убрать текст.
Можно вопрос, сколько времени ты писал на лиспе? Я около 5-ти лет, пока работал в emacs (правда лисп там
самый наверное убогий из всех возможных). Так вот смею тебя заверить "проблема синтаксиса" — это миф.
Проблема "сложности" лиспа в его излишней гибкости.
Нормальный язык должен включать набор инструментов для реализации определенных задач и выбор этого языка или платформы,
как инструмента, определяется задачей. Если язык излишне гибкий выбор уже становиться достаточно сложный, т.к. вместо
одного большого рубильника менеджеру предлагается выбрать из кучи мелких выключателей (при чем не всегда очевидны взаимосвязи
этих выключателей).
Cравни:
Haskell: [ (x, y) | x<-[0,1,2,3], y <- [0,1,2,3], x < y]
Python: [(x, y) for x in [0,1,2,3] for y in [0,1,2,3] if x < y]
Scala: for( x <- 0::1::2::3::Nil; y <- 0::1::2::3::Nil if x < y) yield (x,y)
Lisp: (comprehension (cons x y)
((x '(0 1 2 3)) (y '(0 1 2 3)))
((< x y)))
А теперь вопрос: где гибче синтаксис и язык и где лучше понимаемость кода? И самое интересное: почему в самом гибком языке нужно явно указывать, что это у нас comprehension?
Re[4]: Ваше отношение к языку Scala
От:
Аноним
Дата:
07.06.07 08:13
Оценка:
Здравствуйте, mkizub, Вы писали:
C>>А как твой Kiev поживает, кстати?
M>http://www.symade.org
У вас там на первой странице опечатка.
SymADE is an open-source project developed under CPL (Common Piblic Licence).
Здравствуйте, mkizub, Вы писали:
M>Ты хочешь привести всё к одному знаменателю. Либо только текст, либо только диаграмы. M>Не надо этого. Можно и то и другое. Рисовать flow control удобнее стрелками. Да, с цветами — типа чёрным безусловные переходы, красным — если выражение true и синим — если false. M>А другие вещи лучше выразить текстом. Желательно тоже расцвеченым. Ты же не возражаешь против colorer-ов? А некоторые вещи удобнее как математика, формулами рисовать.
Одним из постулатов ФП как раз зувучит мысль о том, что управление потоком управления есть не правльный стиль программирования. Что вместо того чтобы думать о программе как о потоке упрвления, лучше думать о ней как о наборе рекурсивных вызовов.
Думаю, что выражать рекурсию стрелочками занятие неблагодарное. Как с этим быть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>1. Знаете ли вы что такое Scala?
Играюсь уже несколько месяцев. VD>2. Если знаете, то как к ней относетесь?
В принципе понравилась, но не дай Бог она и дальше будет засахариваться различными
оторванными от жизни ФП фичами, тогда можно будет сразу в морг (причины см. ниже).Там есть приятные моменты, но ее главное достоинство (для меня на данный момент) — простота встраивания в java приложение и возможность использовать уже написанные на java библиотеки. По сути ее эквивалентность java в данном вопросе, хотя вызов некоротрых вещей написанных на scala из явы занятие не для слабонервных — посмотрите как называются классы эмулируеющие функции, так что если планируется использовать библиотеку написанную на scala из java — лучше сразу отказаться от всяких извращений (или во всяком случае спрятать их внутри), есть серьезное
подозрения в этом случае также лучше отказаться от коллекций scala. Пока на мой взгляд
ее можно применять или отдельно или для скриптинга ява приложений (сразу оговорюсь что насчет скорости ничего сказать не могу (хэллоу ворлд на двухядернеке не тормозит . VD>3. Не думаете ли вы применить Scala-у в своих разработках?
Думаю — в качестве замены xslt+расширения на яве (выглядит страшно), там возможно не сложней будет обработка xml, но зато никаких проблем с расширениями. VD>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
В порядке убыванию важности:
1. Будует ли она полноценной заменой xslt? Я видел их документацию, но как обычно бывает
в самый последний чего-то начинает не хватать, вообщем пока не попробуешь не узнаешь...
2. Отсутвие нормальной литератруры (ScalaByExmaple и пр. не в счет), некоторые вещи просто
вгоняют в ступор, например пытался написать небольшей пример — обертку над JDBC — банальный класс DataBase (open,close,commit,rollback,executeFor[A] и т.д.), так вот с удивлением обнаружил что String и int приводяться к java.lang.Object, а double, boolean — нет (через asInsntaceOf) — получается банальная ошибка компиляции типа found/required. Возможно для авторов это все очевидно, но не все такие умные..
3. Отсутсвие поддержки со стороны используемой IDE (Netbeans), я конечно понимаю что реальные пацаны пишут в vim, ну так они и дальше могут продолжать пЫсать. Даже если это
поддержка будет, непонятно как отлаживать код исполняемый встроенной скалой (если он не соотвествует по структуре проекту IDE).
4. Субъектвные:
a)Отсутвие документации на русском, читать англоязычную как-то насобачился еще когда осваивал яву, но времени и сил на это уходит больше. Щас пришел к тому что если выбор — читать эписталярный шедевр на аглицком или смотреть исходники с примерами (с комментариями из трех слов ) — выбираю второе.
b)Отсутвие времени на работе — проект с xslt уже подходит к стадии беты и попытки развернуть его щас ни к чему хорошему не приведут.
c)Отсутвие времени дома — скажем спасибо нашем высшему образованию (скорей бы что ли оно загнулось, по крайней в сегодняшнем виде от него нет никакого толку, просьба госудраственников не кидаться помидорами — хотели субъективное — получите!)
d)Лень.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
К>>>Знаешь, а прикольная идея как раз эдакий "рубильник" встроить в сам язык, чтоб можно было бы регулировать соотношение гибкость/жёсткость в ту сторону, которую нужно, причём, чтоб это было универсальным подходом, как сама расширяемость того же лиспа.
A>>Идея может и хорошая, но есть кучка минусов: A>>1. Рушится стройная концепция языка, т.к. разработчик вынужден кроме реализации собственно языка производить еще и тонкую настройку "рубильников" A>>2. Разработчик языка должен предусмотреть интероперабельность различных "рубильников", результаты такого подхода мы можем все наблюдать в java 1.4 vs 1.5 A>>3. Если этих рубильников в языке будет много, начнется "dll-hell" и реализовать пп2 будет еще сложнее
A>>По этому и получаем: либо красивый язык, но включающий все и сразу с определенными ограничениями (принятыми разработчиками исходя из задач языка или иных мотивов) или получаем lisp где в общем-то не сложная и распространенная конструкция list coprehension превращается в доп библиотеку...
M>Так не в один язык надо встраивать, а сделать как в .NET — высокоуровневые языки и низкоуровневые языки. M>Большую часть кода (80%) писать на высокоуровневом. Ядро (20%) писать на низкоуровневом.
Я почитал статью и мне теперь понятно о чем ты. Ты не просто язык "лучший в мире", ты новую vm задумал, которая порвет аки тузик грелку все .net, erlang и прочие jvm... Красота, но извини, я давно в комунизм не верю. У меня сложилось стойкое ощущение, что то, что сейчас делают эксперты и проектировщики предлагается реализовать в виде некого... хмм... ну в общем рантайма, который разом решает все проблемы. Данный вывод из статьи я сделал фактически на приведенных ниже цитатах (остальное, можно и не читать)
СОП (Семантически Ориентированное Программирование) — новая парадигма, в которой предлагается программировать непосредственно в семантических (смысл, значение) понятиях. Работу программистов часто сравнивают с переводом текста с одного языка на другой. Семантически Ориентированное Программирование можно сравнить с написанием автоматического переводчика с языка на котором удобно формулировать программу на понятный компьютеру язык, и в дальнейшем специалист (может быть далёкий от программирования) сможет писать программу в удобной ему форме, полностью отвечающей предметной области.
СОП не накладывает никаких ограничений на парадигму программирования – можно писать программы и с процедурной, и в функциональной и в логической парадигме. СОП нейтрален по отношению к ним, ведь сама среда разработки оперирует понятиями концепций, семантических значениях. И как программист выберет набор понятий, в которых он пишет программу – в такой и будет написана программа. В этом смысле (функционального ли программирования, процедурного ли) описание набора семантических понятий ничем не отличается от создания специализированного DSL (domain-specific language) языка.
Однако, надо заметить, что отдельно взятая среда разработки программ основанная на СОП не является панацеей. Он позволяет программировать в любой парадигме, создавать новые и добавлять расширения в имеющиеся языки программирования – но не может гарантировать, что созданные программы будут эффективно исполнятся на целевой платформе. Например, реализация ленивых (lazy) вычислений для виртуальной машины Java (JVM) будет крайне неэффективной – чрезмерно требовательной к ресурсам и медленной в исполнении, просто в силу архитектуры JVM. Это одна из причин, по которым полная реализация СОП парадигмы предполагает не только создание среды разработки программ, но и среды исполнения (runtime, VM) основанной на тех-же принципах, гибко настраиваемой под конкретные нужды отдельных программных проектов. Ещё одной причиной желательности создания новой виртуальной среды исполнения программ является необходимость использовать потенциальные преимущества новых аппаратных платформ ближайшего будущего, но об этом чуть позже.
Вот это семантически эквивалентно понятию silver bullet, которого как известно не существует — полная реализация СОП парадигмы предполагает не только создание среды разработки программ, но и среды исполнения (runtime, VM) основанной на тех-же принципах, гибко настраиваемой под конкретные нужды отдельных программных проектов
Вот это вообще фантазии и некий конь. В статье нет ни одной строчки (или я не увидел?) что подразумевается под этими мифическими "понятиями": предлагается программировать непосредственно в семантических (смысл, значение) понятиях
Далее, приведенные рассуждения о меппинга в бд говорит об отсутсвии опыта работы хоть с каким-то ORM в более менее серьзеном проекте и меня, как проектировщика, немного веселит своей наивностью.
Книга { название, аннотация }
[SQLTable: ТаблицаКниг]
class Book {
[SQLField: индекс, primary key] id : int
[SQLField: название, not null, 80 chars] title : string
[SQLField: аннотация, maybe null, long varchar] annotation : long string
private dirty : bool
}
Это, извините банальный orm и с проблемами оного можно ознакомиться простым поиском по этому форуму по слову hibernate или даже как более продвинутого собрата LINQ, и сразу станет понятно, что это ни разу не решение _всех_ проблем и думать о том, _как_ именно будет меппиться объект нужно (для серьезных приложений в 1млн строк кода) до начала программирования, а не после.
По этому я допускаю, что ты хорошо разбираешься в vm, ее проблемах (и проблемах jvm в частности), но вот в проблемах больших проектов и проектирования вообще — извини, похоже не очень.
Здравствуйте, mkizub, Вы писали:
C>>А как твой Kiev поживает, кстати? M>http://www.symade.org M>Сегодня статью про него послал на RSDN, скоро, наверное, напечатают.
M>>>Встречный вопрос. А зачем вам этот опрос? C>>Товарищ VladD2 — фанат другого нераспространенного, но крутого языка M>Nemerle?
Да.
M>Согласен, крутой язык. Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании M>дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки.
Текст — очень удобная форма представления дерева. Нужно просто действия над текстом переводить в действия над деревом — та же IDEA так и делает.
Здравствуйте, mkizub, Вы писали:
M>http://www.rsdn.ru/Forum/message/2520182.aspx
Прикольно — рсдн противится, ссылка не работает, выдаёт форму логина в обоих фреймах, причём логин/пароль не срабатывает, хотя на др. сообщениях рсдн всё корректно
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mkizub, Вы писали:
VD>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>Несогласие с базовой концепцией, тормознутость.
VD>А можно пояснить в чем заключается несогласие?
Наличие решений сделанных дизайнерами языка. Сам факт их наличия.
M>>Встречный вопрос. А зачем вам этот опрос?
VD>Скала очень перспективный язык, но нужен ли он ява-комьюнити? И если не нужен, то очень интересует аргументация.
Я бы сказал — он очень хороший язык. Но не перспективный. Это общая закономерность — в конце развития
технологии появляются наиболее яркие и соверненные её проявления.
Что до Scala для явы — то это не очень интересно, потому как Scala пытается впихнуть в яву невпихуемое.
Scala намного лучше будет выглядеть на .NET или LLVM, а на яве это будет сплошная борьба с JVM.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, mkizub, Вы писали:
M>>>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
К>>А вот это — сферический конь в вакууме. К>>Смысл использования имеющихся инструментов, как раз в использовании проверенных выборов, чтоб не заморачиваться на подробности малозначительные вещи, не интересные для решения нужной задачи. Скажем, использовать GC вместо ручного управления памятью и т.п.
M>Отсутствие принятия выбора дизайна означает, что если программисту надо — он будет использовать GC, если не надо — не будет. Если надо — часть программы с использованием GC, а часть на ручном управлении. M>Ты опять думаешь в терминах, когда за тебя выбирают — выберут тебе низкоуровневый язык или высокоуровневый.
За языком лежит семантическая модель рантайма. От этого никуда не денешься. Языки существуют, чтобы порождать исполняемые программы. Если мы имеем низкоуровневую native модель (стек+heap+статическая память+допустимая явная адресация+OS processes+OS threads), то сколько бы мы ни дизайнили язык — выйдет C++. Более абстрактные модели должны что-то явно запрещать, иначе допустимые хаки на более низкий уровень разрушат целостность абстракций.
Собственно в современных практических высокоуровневых язках эта проблема решается стандартно: запрещаем всё низкоуровневое + есть библиотеки интеропа с C (в самом C аналогично решён вопрос ассемблера ). Лучшего механизма, ИМХО, не придумать.
Ну хорошо если отбросить философствование на тему "Писать самому семантические деревья это круто потому что......", то по сути предлагается писать программы на очередном языке еше более высокого уровня (который в принципе можно обпилить под себя), который потом неким таинственным (или не очень) образом может превращаться во что угодно: в исходники на другом языке, в байт код и т.д.
В результате получаем холявный DSL и пр. радость...
Сразу высплывает несколько моментов:
1. Допустим Вы сделали свой собственный DSL идеально описывающий вашу предметную область,
(кстати а можно ли считать квази-DSL'ем просто библиотеку где классы названы соответствующим образом (Поставщик, Продажа и т.д.) + перегружены все операторы?)
а потом вам вдруг потребовалось прикрутить что-то стороннее, какие варинаты?:
— использовать как есть — но тогда нарущится концепция "нашего маленького самопального языка".
— сваять обертку — это будет покруче чем строительство комунизма, я там одним глазом посмотрел простенький и маленький пример (типа сделай DSL своими кривыми ручками) — "всего" >500 строк кода (поправьте если ошибаюсь) — если на каждый чих ваять по пол тыщи строк то где же экономия от DSL, если же появяться некие общепринятые стандартные DSL и подогнанные под них фреймворки, то мы вернемся к тому же что имеем сейчас только на более высоком уровне (ведь найдутся люди которых и они не устроят)
2. В чем прниципиальная новизна? Ведь созданный DSL все равно так или иначе будет ложиться
на одну из существущих парадигм программирования (ООП, ФП и д.р.).
3. Сугубо практические моменты:
— реальная применимость (где? зачем? в чем преимущество?)
— наличе библиотек (или возможность цеплять сторонние)
— наличие среды разработки
— наличие литературы
В этом плане у скалы есть свои недостатки, но есть и достоинства которые позволяют применить ее уже сейчас.
P.S. Хотя возможно в будущем из этого что-нибудь да получится, только вот расчитывать на очередную серебрянную пулю я бы не стал...
Здравствуйте, mkizub, Вы писали:
M>Так высказаны уже. Я же ссылки давал. Вот ссылка на статью, которую сейчас дорабатываю для RSDN. M>http://www.symade.org/SOP_and_SymADE.doc
Такой «точкой», на которой держатся все современные технологии программирования является текстовое представление кода. Точнее, все компиляторы или WYSIWYG редакторы работают с так называемым «внутренним представлением» кода, синтаксическим деревом узлов, каждое из которых содержит удобное для компьютера представление о синтаксических конструкциях. То есть компиляторы работают так
Текст программы -> Синтаксическое дерево -> Машинный код.
СОП предлагает изменить эту схему, и писать программу непосредственно в виде дерева узлов, соответствующих семантике (смысловым понятиям, конкретным предметным значениям), а отображение (возможно текстовое, возможно графическое) будет строится автоматически на основе семантического дерева. То есть СОП предлагает работать так
Текстовое и графическое отображение <-> Семантическое дерево -> Машинный код.
Э, а примерчик можно? Например, я знаю, как записать алгоритм быстрой сортировки на нескольких языках. Как его записать в виде семантического дерева?
Немедленным следствием такого подхода становится возможность выбирать более удобный (в том числе и субъективно, для конкретного программиста) способ отображения кода. Например, одни больше привыкли писать
if (a > 0) x = a; else x = 0;
а другим более привычна запись
if a > 0 then x := a else x := 0 end
Дык беда не в конкретном синтаксисе if. Беда в том, что в разных языках if имеет разную семантику! Обязателен или нет else? Является ли вся конструкция if выражением возвращающем значение? Длолжно быть условие строго булевым, или допуcтимы неявные приведения от целых?
Любая семантика должна выражаться через синтаксис. И я не представляю, как задать формальный синтаксис суперязыка который ты описываешь. Потому что, если не задавать его строго, то всё потонет в куче мелких нестыковок.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
A>>По этому я допускаю, что ты хорошо разбираешься в vm, ее проблемах (и проблемах jvm в частности), но вот в проблемах больших проектов и проектирования вообще — извини, похоже не очень.
M>И какие ты видишь там основные проблемы?
Отвечу от себя — пардигмы, языки и т.п. — это всё круто, но вот для действительно больших проектов имхо элементарный человеческий фактор играет большую роль. Тупо, если у вас хоть суперинструмент, но если у вас ПМ — дятел, то проект сам собой не родится, а если у руля толковые люди, то они не будут использовать видеомагнитофон, чтоб гвозди забивать
Здравствуйте, mkizub, Вы писали:
M>Я бы сказал — он очень хороший язык. Но не перспективный. Это общая закономерность — в конце развития M>технологии появляются наиболее яркие и соверненные её проявления.
Как много нового можно узнать на форумах. Вот оказывается уже подходит конце развития каой-то там технологии.
M>Что до Scala для явы — то это не очень интересно, потому как Scala пытается впихнуть в яву невпихуемое. M>Scala намного лучше будет выглядеть на .NET или LLVM, а на яве это будет сплошная борьба с JVM.
Не вижу огромной разницы. Но если нужно .NET, то Немреле и есть такой варинат. Более того там ЯОП уже реализовано (макросами).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Просьба к модераторам не переносить тему в другие форумы, так как интересно мнение исключительно "явных" людей. Если будет равиваться флэйм, то просьба отрезать и грохать эти ответвления, а не переносить всю тему.
VD>Вопросы, собственно, прсоты:
VD>1. Знаете ли вы что такое Scala?
С около года наверное уже в ней ковыряюсь (последнее время особенно плотно)... Уже начал иногда понимать код VD>2. Если знаете, то как к ней относетесь?
Очень положительно. При определенных недостатках в целом внятный язык. Плюсы по мере важности
1. Вывод типов
2. Функции как объекты и "функциональность" вообще (т.е. scala-library в функциональном стиле)
3. Расширяемый синтаксис (scala-dbc как пример)
4. Встороенная поддержка xml (хотя возможно и не стоило ее внедрять в язык, ибо если посмотреть _как_ работает парсер чтобы разобрать xml это или scala код, то у меня кроме как "хак" других слов нет)
VD>3. Не думаете ли вы применить Scala-у в своих разработках?
Пока рассматриваю как замену ibatis и xml/xslt процессорам и dao слой. Возможно где-то (в "домашних" проектиках) буду использовать как движек бизнес-логики. Еще внимательно слежу за liftweb. Интересна поддержка cldc и актеров адаптируют под cldc. Т.е. вполне возможно, что в некоторых местах можно получить что-то аналогичное erlang актерам на embedded платформах, но без необходимости тащить erlang vm.
VD>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
На данный момент останавливающим фактором являются (по мере убывания):
1. Остуствие поддержки в Idea. (та что есть — под 7-ку и с моей точки зрения не правильная, ибо использует свой parser/lexer вместо использования возможностей компилятора, как сделано в eclipse плагине). Маленьким проектам и мне лично это не критично, но вот для большого проекта — это проблема.
2. Мало документации "для чайников". Сейчас все приходится либо экспериментально либо из высоконаучных работ выковыривать. Но надо отметить, в списках рассылки сложные случаи объясняют без проблем. Но факт — отсутствие такой документации останавливает внедрение. (Одерски пишет книгу, но когда она точно будет — не известно)
3. Часто меняющийся синтаксис. Т.е. конечно хорошо, что старый все еще продолжает работать (хотя и не весь, например синтаксис кортежей не совместим), но немного напрягает. Ну и сам компилятор еще недостаточно stable. Приходится сидеть на current. Хотя я понимаю, что у любого растущего проекта — это нормально.
4. Сложная система типов. (это и хорошо и плохо, но чтобы их использовать нужно очень хорошо понимать как они работают)
Здравствуйте, VladD2, Вы писали:
VD>Просьба к модераторам не переносить тему в другие форумы, так как интересно мнение исключительно "явных" людей. Если будет равиваться флэйм, то просьба отрезать и грохать эти ответвления, а не переносить всю тему.
VD>Вопросы, собственно, прсоты:
VD>1. Знаете ли вы что такое Scala?
Да VD>2. Если знаете, то как к ней относетесь?
Положительно — лучше пусть будет, чем не будет — от меня не убудет VD>3. Не думаете ли вы применить Scala-у в своих разработках?
Нет VD>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
Несогласие с базовой концепцией, тормознутость.
A>Haskell: [ (x, y) | x<-[0,1,2,3], y <- [0,1,2,3], x < y]
A>Python: [(x, y) for x in [0,1,2,3] for y in [0,1,2,3] if x < y]
A>Scala: for( x <- 0::1::2::3::Nil; y <- 0::1::2::3::Nil if x < y) yield (x,y)
A>Lisp: (comprehension (cons x y)
A> ((x '(0 1 2 3)) (y '(0 1 2 3)))
A> ((< x y)))
A>
A>А теперь вопрос: где гибче синтаксис и язык и где лучше понимаемость кода? И самое интересное: почему в самом гибком языке нужно явно указывать, что это у нас comprehension?
Все же не совсем соглашусь с тобой. Если взять только твои примеры, то кажется, что ты прав. Ведь действительно во всех перечисленных примерах на разных языках кроме Лиспа comprehension встроен в язык и имеет более краткий и внятный синтаксис. Лисп же реализует компрешеншон макросом и начинают вылезать неприятности. К тому же приходится использовать цитирование, что так же ухудшает восприятие. Последнем гвоздем в крышку (как сказал твой аппонент) яляются скобки, коих явно многовато (от них рябит в глазах). Несомненно и то, что возможность создать подобные кострукции средствами самого языка — это просто супер-мега-возможность!
Но! Ниже я приведу пример который полностью разваливает твою позицию:
$[(x, y) | x in [0,1,2,3], y in [0,1,2,3], x < y]
(эх, жаль Явщики нихрена не поймут ни в твоих, ни в моих примерах )
Что это за язык? Думаю все догадались . Это конечно же Немреле.
Лучше чем в Лиспе? По-моему, несомненно. Хуже чем в Хаскеле? Ни чуть! (опять же, по-моему).
Гибче ли Лисп? А вот ни чуть. Приведенный пример — это использование макроса. List comprehensions в Nemerle реализован, как и в Лиспе, макросом. Только при этом Nemerle не отказыается от полноценного синтаксиса и имеет большую базу (основной язык который по стути похож на Яву и Шарп).
Какой вывод можно сделать из моих слов?
Дело все же не в гибкости. Просто раньше добиться гибкости Лиспа в других языках было невозможно.
Так что проблемы Лиспа все же в очень большой степени упираются в его убогий синтаксис и в некоторые другие дизайнерские решения. Ну, и конечно в хреновый маркетинг и никудышное обучение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Так высказаны уже. Я же ссылки давал. Вот ссылка на статью, которую сейчас дорабатываю для RSDN. M>http://www.symade.org/SOP_and_SymADE.doc
Где что высказано?
Статья какая-то "никакая", без конкретных законченных предметов, позволяющих понять, в чём суть и как это всё работать будет.
Опять повторюсь — если есть что-то, что хочешь сказать, то говори толком, а так говорить аля "вы все фигнёй занимаетесь" большого ума не надо.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, deniok, Вы писали:
D>>Э, а примерчик можно? Например, я знаю, как записать алгоритм быстрой сортировки на нескольких языках. Как его записать в виде семантического дерева?
M>Да так-же. Как во всех тех языках. Компилятор всё равно парсит текст в дерево. Вот так и записывать.
Я думаю, что в случае Хаскелля и C это будут разные деревья. В Хаскелле это как раз декларативное описание того, что нужно получить, а в C — полновесный набор инструкций, что откуда брать и что куда записывать. И, кстати, компиляторы чистых функциональных и императивных языков работают сильно различным образом.
K>И почему это работает в обоих случаях? K>Если в первом я понимаю -- мы функции высшего порядка foreach передаем анонимную функцию как параметр. А что происходит во втором случае?
То же самое. Скобки при вызове методов — опциональны (точнее, это получается инфиксная запись). А фигурные кавычки {} просто обозначают блок кода, как и в Java.
Здравствуйте, mkizub, Вы писали:
VD>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>Несогласие с базовой концепцией, тормознутость.
А как твой Kiev поживает, кстати?
M>Встречный вопрос. А зачем вам этот опрос?
Товарищ VladD2 — фанат другого нераспространенного, но крутого языка
Здравствуйте, Cyberax, Вы писали:
VD>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>Несогласие с базовой концепцией, тормознутость. C>А как твой Kiev поживает, кстати?
http://www.symade.org
Сегодня статью про него послал на RSDN, скоро, наверное, напечатают.
M>>Встречный вопрос. А зачем вам этот опрос? C>Товарищ VladD2 — фанат другого нераспространенного, но крутого языка
Nemerle?
Согласен, крутой язык. Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании
дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки.
Шажок Scala, шажок Nemerle, шажок XL. Как по мне, это похоже это на перепрыгивание пропасти в два прыжка.
Но я только рад этим языкам. Чем быстрее ими начнут пользоваться, тем быстрее поймут их принципиальную ограниченность.
Здравствуйте, mkizub, Вы писали:
M>Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании M>дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки. M>Шажок Scala, шажок Nemerle, шажок XL. Как по мне, это похоже это на перепрыгивание пропасти в два прыжка. M>Но я только рад этим языкам. Чем быстрее ими начнут пользоваться, тем быстрее поймут их принципиальную ограниченность.
Можно по подробнее? В чем проблема? В чем решение?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
Может тогда стоит глянуть на lisp и не изобретать лисапед?
Здравствуйте, mkizub, Вы писали:
M>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
А вот это — сферический конь в вакууме.
Смысл использования имеющихся инструментов, как раз в использовании проверенных выборов, чтоб не заморачиваться на подробности малозначительные вещи, не интересные для решения нужной задачи. Скажем, использовать GC вместо ручного управления памятью и т.п.
Это как с теми же макросами — давать писать их всем подряд, конечно, забавно, только вот на практике не есть очень умный вариант. Свободы программисту должно быть достаточно чтоб решать поставленную перед ним задачу, но не более — излишняя свобода лишь порождает лишние проблемы, отвлекает и т.п.
Другое дело, что непонятно как найти нужную долю этой свободы и как её чётко ограничить
Ну и должны быть разные "уровни" программистов с разными разрешениями.
Всё, естественно, имхо
Здравствуйте, mkizub, Вы писали:
M>Ну возьми те-же скриптовые языки. Как на них удобно писать маленькие программы. Ни типов объявлять, M>ни о скорости заботиться. А попробуй написать на скриптовом языке большую программу — очень M>скоро начнётся такая борьба с вылазящими изо всех щелей ошибками связанными с типами, что M>проект застынет на месте.
Если ты по поводу динамической типизации, то есть ощущение, что ты неправ
Контрпример — код ПО для свича AXD301, пару лет назад вроде там было что-то типа 2 миллионов строк на Erlang — язык динамичней некуда.
M>[cut] И всё, приплыли. Передача данных и управления между M>разными слоями становится настолько сложной и тормознутой, что это перечёркивает M>все преимущества разделения проекта на разные части. И мы опять у разбитого корыта.
Всё это напоминает статью Спольски про закон дырявых абстракций, только вот что именно ты предлагаешь?
Уровни абстракций, DSL и т.п. — это всё прикольно, но что нового в этом твоём СОП и чем оно спасёт отца российской демократии?
Здравствуйте, 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 тут были похожие идеи — про языковоорентированное программирование.
А то что можно графику использовать дак это понятно, только на практике текст имхо много гибче и универсальней.
Здравствуйте, aka50, Вы писали:
A>Т.е. в общем проблема разработки софта — в его комплексности. Например любой софт на прорядок сложнее чем последняя Audi (в ней вроде около 300тыс деталей), но любой сложный проект легко переплюнет по кол-ву объектов и форм взаимодейтсвий этих объектов. И при этом Audi нынешняя не идет не в какое сравнение с ауди предыдущих моделей. Т.е. это еще раз иллюстрирует то, что при достижении некого порога кол-ва объектов, проект становится трудноуправляемым, т.к. не существует одного человека осознающего картину в целом до мельчайших деталей (ровно как нет и надежного способа консолидации нескольких мозгов в один, работающих с разделяемыми знаниями, т.е. опять же получаем проблему интеропа (оно же взаимодействие в команде и документация).
Полностью согласен — повышение уровня абстракций это путь в никуда, хотя другого нет.
Этот путь позволяет одержать тактическую победу, но в конечном счете оборачивается усложнением системы понятий которыми вынужден оперировать человек при этом ресурсы человека не меняются.
Если так подумать то программисты 50-x были в общем то счастливми людьми — все просто и понятно, при то что их было мало и задачи перед ними стояли весьма серьезные.
А сейчас даже в провинциальном проекте средних размеров приходится использовать огромное количество различных технологий, баз данных, фреймворков. Причем у автора каждого из них есть свои тараканы в голове и зачастую даже непонятно как это все объединиить (учитывая замечательную ситуацию с документацией для ряда проектов). При этом надо думать над тем чтобы это все крутилось под win/lin и не потребляло слишком много памяти + перманентный дедлайн.
Товарищ тут все толкует про семантику, по сути все это многообразие предлагается завернуть в еще одну обертку. В действительности сейчас достаточно полное и хорошее описание предметной области можно получить с помощью того же ООП, но это не никак не решает проблемму зоопарка.
Здравствуйте, aka50, Вы писали:
A>Как видишь, довольно глубоко, но если начинать складывать в кучку все эти объекты, то получим некую величину которую человек осознать не в силах, вот собственно и есть предел сложности. При этом работая с бд мы и так работаем практически с объектами предметной области (счет, платеж, клиент) т.е. выше собственно абстрагироваться некуда (ну если только сделать одну большую кнопку "шоб работало" и оно само догадалось что мы хотим).
Совершенно верно. Каждый следующий уровень абстракции отрезает у нас возможность полного, оптимального использования системы.
Это один из постулатов кибернетики — для эффективного управления системой, управляющая система должна быть сложнее управляемой, чтоб иметь возможность постоить полную модель и выбрать оптимальный способ изменения управляемой системы. А если управляющая система будет более сложной, чем управляемая — то как управлять управителем? Только бесконечно сложная система может эффективно управлять своими под-системами. Грубо говоря — Бог. А мы вынуждены каждый раз уменьшать сложность управляющей системы, чтоб в результате просто иметь возможность управлять, пусть и не максимально эффективно.
Именно в этом месте SOP предлагает — нет, не сделать нас богами и дать возможность максимально эффективно управлять ресурсами — он предлагает убрать (насколько возможно) узкие места между уровнями, переходами верхних абстракций на нижние. Раньше было одно такое узкое место, сейчас их уже два — текстовый код программы и байткод. Неформально изложенное пожелание "отобразить список книг" должно быть переведено на язык программирования в синтаксических терминах конкретного языка. А теперь уже скомпилированный в байткод код программы надо перевести в нэйтивный код процессора. Пример с JIT компилятором в яве ты же читал в статье? Большая часть его сложности — в попытке угадать из байткода — что же на самом деле писал программист. Чтоб хоть как-то облегчить ему задачу — в явовском компиляторе напроч вырубили оптимизацию.
SOP предлагает всю информацию сверху (от архитектора проекта) донизу (скомпилированного кода) передавать в едином формате с минимумом потери информации. В виде дерева.
Конечно, это не решает проблему полностью, полностью её решает лишь Бог. Но просто за счёт убирания узких мест мы получаем возможность программировать настолько хорошо, насколько это позволяет сложность системы, а не настолько, насколько пропустит байткод или фиксированный синтаксис.
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, mkizub, Вы писали:
M>>Посмотри на код, генерируемый Scala и ужаснись. A>Покажи... вот честно, интересно... а то пока только пугаешь (есть там конечно кривости, но как это сделать иначе я тоже не сильно представляю)
M>>Или вот, пусть мне нужны параметры типов в рантайме. Чтоб я мог написать M>>List<String> ls = ...; M>>String[] arr = ls.toArray(); M>>а не M>>String[] arr = ls.toArray(new String[ls.size()]);
A>Вообще-то разработчику vm должно быть стыдно, если он не знает почему именно требуется объект массива
Устыди. Я не понял где мне стыдится. Я знаю, что он требуется в яве. А в моем комплиторе он не требуется.
A>на scala это решается безо всяких прыжков:
A>
scala>> val ls = 1 :: 2 :: Nil
A>ls: List[Int] = List(1, 2)
scala>> ls.toArray
A>unnamed1: Array[Int] = [I@4854f6 << обрати внимание, что тут именно нейтив массив, а не boxed
A>
A>Код в самой скала самый обычный: A>
A>override def toArray[B >: A]: Array[B] = {
A> val result = new Array[B](size)
A> copyToArray(result, 0)
A> result
A>}
A>
A>Другой вопрос, когда мы хотим что-то такое, но это уже спасибо блин erasure... A>
A>class MyType[T] {
A> def oops = new T()
A>}
A>
Я же сказал — в рантайме. А рантайме типы нужны. А ты опять про erasure.
Я не знаю, как в Scala сделан List[Int].toArray, но он не может этого делать
без инлайнинга или передачи спрятанных параметров в метод. Чудес не бывает.
Откуда-то метод toArray должен узнать тип массива. И поскольку в Scala эти
типы отрезаются компилятором — то только один из предложенных вариантов — хранить
в самом List (передача параметра во время создания списка) и передавать
параметр во время вызова toArray. Других вариантов просто нет.
Здравствуйте, deniok, Вы писали:
D>>>Э, а примерчик можно? Например, я знаю, как записать алгоритм быстрой сортировки на нескольких языках. Как его записать в виде семантического дерева?
M>>Да так-же. Как во всех тех языках. Компилятор всё равно парсит текст в дерево. Вот так и записывать.
D>Я думаю, что в случае Хаскелля и C это будут разные деревья. В Хаскелле это как раз декларативное описание того, что нужно получить, а в C — полновесный набор инструкций, что откуда брать и что куда записывать. И, кстати, компиляторы чистых функциональных и императивных языков работают сильно различным образом.
Совершенно верно. Это будут две разные семантически программы. Поэтому и в виде дерева семантических узлов этот алгоритм сортировки будет записан по разному для разных языков
(наборов семантики, онтологии).
Но плюс к тому, его ещё можно просто записать новое семантическое понятие для сортировки как
node Sort {
attribute Expr container;
}
и рисовать это как
sort list
а в виде дерева (приведу в виде XML дампа)
<node type="Sort">
<container>
<node type="VarRef">
<name>list</name>
</node>
</container>
</node>
А при трансляции это будет разворачиваться плагином в дерево узлов соответствующее хаскелевской семантике, или С-шной семантике, в зависимости от наших пожеланий.
Разумеется, вводить новый узел только для сортировки будет не очень умно в обычной ситуации, но если вдруг надо будет написать проект, который будет сортировать
списки в каждой строчке программы — то почему нет?
Здравствуйте, mini_root_2, Вы писали:
__>Здравствуйте, mkizub, Вы писали:
M>>Сейчас эта проблема ещё не очень остро стоит. Лет через 10 она будет стоять во весь рост, потому как тупо наращивать количество транзисторов в CPU уже нельзя будет. Надо будет делать сложные процессоры. В том числе перепрограммируемые, с изменяемыми коммандами, распределением вычислений по ядрам и многое другое. Представляешь, насколько узким местом станет фиксированный байткод, если программист уже пишет на Scala или Nemerle, и процессор адаптируемый — а байткод фиксированный.
__>Так ведь VM тоже эволюционируют. Как можно наращивать мощу сохраняя при этом обратную совместимость видно на примере семейства x86, а ведь та же JVM это по сути программный (не железный) процессор, который к тому же добавляет еще один уровень автоматизации под конкретное железо на этапе JIT'a. __>Другое дело что байт код по определению не должен зависить от железа (на одном проце какая-то инструкция есть, а на другом нет), поэтому тупо добавлять новомодные фичи наверное не стоит. __>Поразмышляв немного над SOP пришел к следующему выводу: по сути предлагается поднять уровень абстракции самого байт кода (в роли байт кода семнатические приблуды SOP, которые потом преобразуются во что угодно (как в JIT)). В приницпе звучит интересно, но вот проблемы там будут те же самые + добавяться некоторые другие: __> — кто будет определять как какой узел семантического дерева во что преобразовать?
Нэйтивный компилятор.
Каждый нэйтивный компилятор будет иметь свой набор семантических узлов, непосредственно им поддерживаемых.
Плюс каждый семантческий узел может иметь в своём описании fallback преобразование (не обязательно одно). Если нэйтивный компилятор не поддерживает данную семантику напрямую — он может использовать fallback правила преобразования для узла. Чаще всего такими fallback преобразованиями будут, конечно, библиотечные методы. То есть нэйтивный компилятор будет ещё и знать, что для запуска данного приложения нужна такая-то библиотека.
Как пример — J2ME CLDC 1.0, в котором нет float переменных, а в CLDC 1.1 они есть.
При SOP подходе программа бы просто содержала операции над float значениями, и они либо выполнялись непосредственно на CLDC 1.1, либо при установке мидлета телефон автоматически ещё бы устанавливал библиотеку эмуляции плавающей точки, либо говорил — "данная операция на этом устройстве невозможна".
Кроме того, программисты для телефонов могли бы себе определить новый тип данных, который бы имел fallback сратегии для платформ с float (где этот код исполнялся бы более эффективно) и для платформ только с int (где часть битов в int была-бы зарезервирована для небольшой дробной части).
Сам нэйтивный процессор не должен быть монолитным. Скажем, для мобилок — он частично может исполнятся на сервере и передавать пред-компилированные данные (то есть байткод+информация по оптимизации) в телефон, где простой bytecode-to-native транслятор преобразовывал программу уже непосредственно в нэйтивный код ARM, x86, C166 и прочих процессоров мобильного зоопарка.
__> — а если у меня собственное дерево, мне что самому надо будет делать маппинг подо все платформы?
Да, для всех платформ, где ты его хочешь исполнять. Но если у тебя своё дерево — зачем-то же ты его сделал? Скажем, ты сделал дерево для аппаратных lisp машин. Ты его только на этом target и собирался ведь исполнять, да? Тебе его совсем нет необходимости маппировать на x86 набор инструкций.
__> — а как на счет переносимости по бинарникам? (не придется ли каждый раз запускать всю цепочку преобразования сампольного DSL в машинный код?)
Как хочешь. Можешь запускать эту цепочку каждый раз. Можешь пред-компилировать в native код при инсталляции, можешь предкомпилировать в промежуточный код, который каждый раз компилировать в нэйтивный JIT компилятором.
__>И кто-то еще говорит что Scala тормозит... __>Кастати никаких проблем с интеропом коллекций между жабой и встроеной скалой нет, в случае если это коллекции жабы (разве что не получится пользоваться ФП-фичами).
Здравствуйте, mkizub, Вы писали:
M>Да, JetBrains реализует очень похожую идею. Только они не идут в реализации до конца. M>Они выходной код генерируют как текст (явовский), и опять попадают в узкое горлышко. M>Конечно, там ниже всегда будет узкое место, всё равно прийдётся в конечном итоге M>генерировать машинные комманды.
И в чем же узость подхода с генерациепй Явовского кода?
Если у них и есть проблема, то она совсем в другом. Они отказались от нормального текстового представления, что резко усложняет работу с такой системой.
M>Идея SOP в том, чтоб убрать промежуточные узкие места.
Офигительная идея! Тенет не просто на новую парадигму, а прямо таки на прорыв в IT.
Самому то не смешно? Какая разница во что преобразуется более высокоуровневый язык если в итоге мы получаем машинный код?
Лично я даже предпочту генерацию промежуточного кода на высокоуровневом ЯП, так как его можно отлаживать. Ведь кодга ты делашь ДСЛ, расширяешь язык или делаешь фрэймворк, то нужно отлаживать то что ты делаешь. Если у тебя генерируется машинный код, то отлаживать его будет чретовски сложно. А если промежуточный код на Яве (да на чем угодно), то его моно легко отладить и найти ошибку в генераторе или логике.
M>Чтоб не надо было извращаться генерируя явовский код.
Это только в твоих устах извращение. Причем пахнет это фанатизмом — бездумным отрицанием.
M>Чтоб не надо было извращаться над JIT компилятором, который по байткоду пытается понять, что ж там M>было в исходном коде написано, а то иначе оптимизация не удаётся.
Ясно. Как я и предполагал изачально тебе не нравится сама Ява, ее архитектура. Отталкиваясь от этого ты и пыташся критиковать, то что на ней основано.
Откровенно говоря меня не интересует твое отношеие к Яве. А нового ты так ничего и не предложил. Взял чужую идею язков-ориентированного программирования (а.к.а. DSL-подход), дал ему свое название, накрутил откровенного балшита, добавил требования обязательной компиляции в машинный код и выдаешь за свою идею. Извини, но мы тут не мальчики и прекрасно разбираеся в данном вопросе. Эта идея стара как мир.
К>>А то что можно графику использовать дак это понятно, только на практике текст имхо много гибче и универсальней.
M>У меня есть спецификация узла для loops, M>ForStat { M> Stat init; M> Expr cond; M> Block body; M> Expr iter; M> Label lblcnt; M> Label lblbrk; M>} M>и мне к нему надо специфициоровать Control/Data Flow. Я это делаю как M> @dflow(out="lblbrk") private static class DFI { M> @dflow(in="this:in") ASTNode init; M> @dflow(in="init", links="iter") ENode cond; M> @dflow(in="cond:true") ENode body; M> @dflow(in="body") Label lblcnt; M> @dflow(in="lblcnt") ENode iter; M> @dflow(in="cond:false") Label lblbrk; M> } M>Как ты думаешь, что удобнее было-бы, нарисовать стрелочками граф, или разбираться в этом коде?
Удобнее было бы написать читабельную строчку кода. Вот как выглядит описание цикла for в Nemerle:
macro @for (init, cond, change, body)
syntax ("for", "(", Optional (init), ";", Optional (cond), ";",
Optional (change), ")", body)
{
M>А у него ещё нет проверки на правильность строк в аннотациях, если что — в рантайме баги вылазят
А зачем строки использовать? Использую AST.
M>Первое, что сделаю, когда редактор стрелки научится рисовать — перепишу все эти control flow M>красиво.
Ты бы лучше подумал над тем, что изобретение колес не лучшее занятие для 21-го века. Сэкономил бы массу времени.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Там много проблем. Самая простая — отсутствие goto. Без него нарисовать эффективную state machine практически невозможно.
Хм. Может для Явы это и проблема, но на Немерле я без единого готу любой ДКА накропаю.
ОК, но почему бы тогда не взять дотнет и C#? Или не гнерировтаь байткод явы? Все же было бы проще.
VD>>Если у них и есть проблема, то она совсем в другом. Они отказались от нормального текстового представления, что резко усложняет работу с такой системой.
M>В чём-то усложняет, в чём-то облегчает.
Главное что во многом усложняем жизнь пользователей. Как такой код в форум запостить? А как в SVN положить?
M>>>Идея SOP в том, чтоб убрать промежуточные узкие места.
VD>>Офигительная идея! Тенет не просто на новую парадигму, а прямо таки на прорыв в IT. VD>>Самому то не смешно? Какая разница во что преобразуется более высокоуровневый язык если в итоге мы получаем машинный код?
M>Я почитал дальше, и мне стало грустно. M>Иди ты нафиг.
То что тебе стало грустно — это как раз нормально. На мой взгляд, ты занимашся совершенно бессмысленной фигней. А вот хамить не надо.
Влез в тему в которй твои игрушки никого не трогали, развел флуд на 100 сообщений, и еще тех кто с тобой не согласен посылашь куда по дальше. Иди лучше сам отсюда, пока не забанили.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это теоретизирование. Я вот никаких проблем от испоьзования макросов не вижу. Это же не макросы С?! Нужно решить проблему решаемую макросом — используешь макрос. Не нужно — не испоьзуешь. А так можно все что угодно превратить в проблему если использовать не по месту.
Влад, я все понимаю, но я пишу на java, в проекте у меня около 30 библиотек. И я рад, что это библиотеки, где достаточно читать объекты и методы. Все достаточно прозрачно и понятно (ну исключая кодогенерацию) А теперь представь, если они все будут макросами (использующих всякую короткую нотацию). Я слабо представляю какие надо иметь мозги чтобы это все понимать. Т.е. я это к тому, что макросы должны решать какую-то общеизвестную задачу (ну там orm или sql или di) но никак не пихаться где попало. Читать такой код (особенно без ide с полностью поднятым и компилируемым проектом) — застрелишься. Основная проблема в макросах (ИМХО) — это наличные скрытой семантики не видной в коде. Макрос работает _над_ аст, которого я естественно в коде не вижу, т.е. понять, что именно происходит — проблематично (именно для случая кучи макросовых библиотек).
ЗЫ: опыт с макросами и их потенциальными проблемами я еще из лиспа вывел. И не в синтаксисе дело (в лиспе даже более читабельно) а именно в мешанине и скрытой семантике.
A>>Но когда они будут в scala, я не откажусь (тем более что уже это обсуждают). Хотя мне пока хватает scala-вского синтаксического сахара и мошьной системы типов. VD>Очень по Майкрософтовски, пока у нас чего-то нет, то оно лишнее или даже зло, а как появляется, то класная фича, и мы от не не откажемся.
Не я не отказываюсь... я против тотальной пропаганды оных. Это как шаблоны в С++. Когда с умом — хорошо, когда везде и всюду, да еще и без соотвествующей квалификации — атас (мы же рассматриваем возможность применения в мейнстриме , а не только среди отдельных гуру (гуру еще стать надо), ибо что может сделать сила языка в мейнстриме показал С++).
Просьба к модераторам не переносить тему в другие форумы, так как интересно мнение исключительно "явных" людей. Если будет равиваться флэйм, то просьба отрезать и грохать эти ответвления, а не переносить всю тему.
Вопросы, собственно, прсоты:
1. Знаете ли вы что такое Scala?
2. Если знаете, то как к ней относетесь?
3. Не думаете ли вы применить Scala-у в своих разработках?
4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mini_root_2, Вы писали:
__>Здравствуйте, VladD2, Вы писали:
__>так вот с удивлением обнаружил что String и int приводяться к java.lang.Object, а double, boolean — нет (через asInsntaceOf) — получается банальная ошибка компиляции типа found/required. Возможно для авторов это все очевидно, но не все такие умные..
Хорошо возможно это я ступил, тогда подскажите мне как можно например сделать что-то такое
import java.sql._;
class DataBase
{
....
def executeFor[A](_sql: String): A =
{
......
A macth
{
case ..... => r.getString(1).asInstanceOf[A];
case ..... => r.getInt(1).asInstanceOf[A];
};
......
}
....
};
Не компилируется...
Какой вообще формат у case можеть быть в различных случаях? Я видел: case x: String, case </element> и др. Но общей сути так и не понял. В ScalaReferences написано что-то типа case e1 => p1 — ну и что такое e1, и каким оно может быть в разных ситуациях?
Поэтому я указал среди основных претензии отсуствие нормальной литературы...
Здравствуйте, aka50, Вы писали:
A>1. Остуствие поддержки в Idea. (та что есть — под 7-ку и с моей точки зрения не правильная, ибо использует свой parser/lexer вместо использования возможностей компилятора, как сделано в eclipse плагине). Маленьким проектам и мне лично это не критично, но вот для большого проекта — это проблема.
Или посмотреть как это реализованно в scala-dbc. Там запросы имеют вид
select (
"age" is smallint,
"name" is clob,
"salary" is int )
from ("persons" naturalJoin "employees")
where (
"gender" == "M" and
("city" == "lausanne" or "city" == "geneva"))
orderBy "age"
Вариант, приведенный тобой работать не будет, т.к. информация о типе стирается, а значит в рантайме A грубо говоря AnyRef (аналог Object)
__>Какой вообще формат у case можеть быть в различных случаях? Я видел: case x: String, case </element> и др. Но общей сути так и не понял. В ScalaReferences написано что-то типа case e1 => p1 — ну и что такое e1, и каким оно может быть в разных ситуациях?
case может иметь несколько видов (при чем части выражения, например vc или v могут опускаться, если нет необходимости работать с сами заматченым объектом, а например только с параметрами ca1, ca2)
case vc: CaseClass(ca1, ca2) — где параметры конструктора исползовавшиеся при конструировании case классов (специальный вид классов)
case v: ClassName — фактически оптимизированный instanceOf с последующим преведением и присвоением val v = matchVal.asInstanceOf[ClassName]
scala> class U(val v: int) {}
scala> val m=new U(1)
m: U = U@5a936b
scala> m match { case l: U => println("" + l + " " + m) }
line6$object$$iw$$iw$U@5a936b line6$object$$iw$$iw$U@5a936b
Есть еще конструкции с экстраторами и анонимными фукнциями.
Но основное надо помнить: информации о типах нет (erasure как в java) по этому весь match работает только над объектами и константами.
Здравствуйте, aka50, Вы писали:
A>Или посмотреть как это реализованно в scala-dbc. Там запросы имеют вид A>
A>select (
A> "age" is smallint,
A> "name" is clob,
A> "salary" is int )
A>from ("persons" naturalJoin "employees")
A>where (
A> "gender" == "M" and
A> ("city" == "lausanne" or "city" == "geneva"))
A>orderBy "age"
A>
Интересно, надо будет посмотреть исходники. А насколько реально построить на scala собственный мини DSL? А с учетом
того что скала еще и в яву встраивается можно будет пракически нахаляву получить движок для бизнес правил. Блин, ручки уже начинают чесаться...
Здравствуйте, mini_root_2, Вы писали:
__>Интересно, надо будет посмотреть исходники. А насколько реально построить на scala собственный мини DSL? А с учетом __>того что скала еще и в яву встраивается можно будет пракически нахаляву получить движок для бизнес правил. Блин, ручки уже начинают чесаться...
Конечно не все так радужно (т.е. до макросов далековато), но в целом жить можно. Правда в рассылке недавно активно обсуждали синтаксис макросов, но пока не понятно, что же все таки решили... Небольшое описание создания DSL на scala можно тут почитать: http://phoenix.labri.fr/DSPD/final/dubochet2006zytyg.pdf
Здравствуйте, mkizub, Вы писали:
VD>>3. Не думаете ли вы применить Scala-у в своих разработках? M>Нет
И не удивительно VD>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>Несогласие с базовой концепцией, тормознутость.
Тормознутость компилятора или получаемого кода?
Здравствуйте, aka50, Вы писали:
VD>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>Несогласие с базовой концепцией, тормознутость. A>Тормознутость компилятора или получаемого кода?
У меня не было достаточно больших проектов, чтоб оценить степень тормознутости компилятора.
Кода, конечно.
Он и без JVM был-бы накладный, а на яве, с её невозможностью низкоуровневого программирования — и подавно.
Конечно, для определённой ниши приложений (серверных) скорости Scala хватит с головой.
Но поскольку у меня есть решения получше (где надо удобно — там пусть будут тормоза, где надо быстро — там
будет без накладных расходов), то решения разработчиков Scala меня лишь удручают. Как я написал Мартину —
yet another good language.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
VD>>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>>Несогласие с базовой концепцией, тормознутость. M>Он и без JVM был-бы накладный, а на яве, с её невозможностью низкоуровневого программирования — и подавно. M>[skip] решения разработчиков Scala меня лишь удручают.
Очень интересно, хотелось бы подробностей (то, что я успел посмотреть мне пока не показалось чем-то сильно страшным).
M>Как я написал Мартину — yet another good language.
А можно ссылочку, где это обсуждалось (если конечно это в рассылке есть)?
Здравствуйте, aka50, Вы писали:
VD>>>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>>>Несогласие с базовой концепцией, тормознутость. M>>Он и без JVM был-бы накладный, а на яве, с её невозможностью низкоуровневого программирования — и подавно. M>>[skip] решения разработчиков Scala меня лишь удручают. A>Очень интересно, хотелось бы подробностей (то, что я успел посмотреть мне пока не показалось чем-то сильно страшным).
1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно.
Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.
Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает
площать в метрах квадратных.
2. Делать из методов объекты — это удобно, иногда, но это жуткий оверхед.
3. Лепить во все места view-s — это удобно для code reuse, но это жуткий оверхед.
Вообще, создатели языков вынуждены делать выборы, которые определяют область использования языка.
В C++ выбрали полную обратную совместимость с С, и принцип — пока ты фичу не пользуешь, она не должна
давать оверхеда в твоём коде. Это привело к тому, что С++ скоро сдохнет, вытесненный конкурентами,
которые себе такой груз на спину не взвалили. В яве сделали выбор в пользу параноидальной защищённости
и верифицируемости кода всегда. Получили тормоз, даже когда исполняется trusted приложение, даже
если оно пытается переложить работу на нэйтив код — всё равно тормоз. И так далее.
Создатели языков вынуждены делать этот выбор, и всегда найдутся проекты, в которых именно этот
выбор станет ножом в сердце. А я знаю, как создать среду для разработки и исполнения программ, где
этот выбор будут делать не создатели языка, а архитектор данного конкретного проекта. Об этом я Мартину
и написал, и обозвал Scala "ещё одним", пусть хорошим, но банальным языком программирования.
M>>Как я написал Мартину — yet another good language. A>А можно ссылочку, где это обсуждалось (если конечно это в рассылке есть)?
Это было личное письмо, простой e-mail. И он на него не ответил, может даже просто в спам упало.
Здравствуйте, Cyberax, Вы писали:
M>>Согласен, крутой язык. Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании M>>дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки. C>Текст — очень удобная форма представления дерева. Нужно просто действия над текстом переводить в действия над деревом — та же IDEA так и делает.
C>Так что тут несогласен.
Мы, видимо, о разном говорим. Вот напечатают статью и будет ветка обсуждения — там обсудим.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
VD>>>>>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>>>>>Несогласие с базовой концепцией, тормознутость. M>>>Он и без JVM был-бы накладный, а на яве, с её невозможностью низкоуровневого программирования — и подавно. M>>>[skip] решения разработчиков Scala меня лишь удручают. A>>Очень интересно, хотелось бы подробностей (то, что я успел посмотреть мне пока не показалось чем-то сильно страшным).
M>1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно.
Тип (наиболее близок к typeclass): набор сигнатур и констант которые должны быть в классах данного типа.
А что по твоему должно быть типом? (не забывай еще, что нужно поддерживать раздельную компиляцию).
M>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые. M>Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает M>площать в метрах квадратных.
Это сделано из соображений совместимости с jvm. И собственно, а что это будет за объект, который имеет size сразу и в kg и в sqm (при чем не преобразуемых, т.к. методы разных сущностей)?
M>2. Делать из методов объекты — это удобно, иногда, но это жуткий оверхед.
Это ты о чем? Методы как методы, только когда мы хотим передать метод куда-то, тогда да, рожается объект... Ну и анонимные функции тоже превращаются в объекты.
object test {
class A {
def myMethod() = println("hello")
def myAnotherMethod() = println("hello")
}
class B(a: A) {
def myTest() = (1 :: 2 :: Nil) map (_ + 1)
def mySuper() = a.myAnotherMethod _
}
}
target
|-- test$.class
|-- test$A.class
|-- test$B$$anonfun$0.class
|-- test$B$$anonfun$1.class
|-- test$B.class
`-- test.class
$ javap test\$A
Compiled from "methods.scala"
public class test$A extends java.lang.Object implements scala.ScalaObject{
public test$A();
public void myAnotherMethod();
public void myMethod();
public int $tag();
}
$ javap test\$B
Compiled from "methods.scala"
public class test$B extends java.lang.Object implements scala.ScalaObject{
public final test$A test$B$$a;
public test$B(test$A);
public scala.Function0 mySuper();
public scala.List myTest();
public int $tag();
}
$ javap test\$B\$\$anonfun\$0
Compiled from "methods.scala"
public final class test$B$$anonfun$0 extends java.lang.Object implements scala.Function1,scala.ScalaObject,java.io.Serializable{
public test$B $outer;
public test$B$$anonfun$0(test$B);
public final java.lang.Object apply(java.lang.Object);
public test$B test$B$$anonfun$$$outer();
public final int apply(int);
public int $tag();
public scala.Function1 andThen(scala.Function1);
public scala.Function1 compose(scala.Function1);
public java.lang.String toString();
}
M>3. Лепить во все места view-s — это удобно для code reuse, но это жуткий оверхед.
Не вижу оверхеда. Тот же код, что вынесен во view будет просто писаться руками. Учитывая, что view обычно разботают на границе компонент, это не страшно...
Ну и собственно "жуткий оверхед" — это сколько в цифрах? В java повсеместно используются анонимные классы и ничего... здесь фактически тоже самое...
M>Вообще, создатели языков вынуждены делать выборы, которые определяют область использования языка.
Не совсем. Scala — одна из задач, это совместимость с java. Отсюда и определенные ограничения.
Здравствуйте, mkizub, немного не понял претензий:
M>1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно. M>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые. M>Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает M>площать в метрах квадратных.
Тип описывается так же, как и в Жаве. То, что ты можешь его не указывать и он сам выведется из использования, всего лишь синтаксичекий сахар... Так что
Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.
Утверждение правильное, но Скала этого и не нарушает. M>2. Делать из методов объекты — это удобно, иногда, но это жуткий оверхед.
Эээ... Объекты делаются из анонимных функций, это, наверное, следствие ограничений виртуальной машини. А вот про методы такого не слышал M>3. Лепить во все места view-s — это удобно для code reuse, но это жуткий оверхед.
Можно и без видов программировать, ничего особенного в них нет...
<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Ayreon — The Dream Sequencer
Здравствуйте, Аноним, Вы писали:
А>У вас там на первой странице опечатка. А>SymADE is an open-source project developed under CPL (Common Piblic Licence).
Здравствуйте, Gajdalager, Вы писали:
G>Здравствуйте, mkizub, немного не понял претензий:
G>Тип описывается так же, как и в Жаве. То, что ты можешь его не указывать и он сам выведется из использования, всего лишь синтаксичекий сахар... Так что G>
G>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.
G>Утверждение правильное, но Скала этого и не нарушает.
Скала, к сожалению, не даст так просто сделать mixin из разных интерфейсов. Будет ругаться на несовместимость типов:
trait KiloSizes {
trait kg;
def getSize():kg = new kg {val v=1}
}
trait ItemSizes {
trait sht;
def getSize():sht = new sht {val v=2}
}
trait AllSizes extends KiloSizes with ItemSizes {}
<console>:6: error: error overriding method getSize in trait KiloSizes of type ()AllSizes.this.kg;
method getSize in trait ItemSizes of type ()AllSizes.this.sht needs `override' modifier
trait AllSizes extends KiloSizes with ItemSizes {}
^
trait AllSizes extends KiloSizes with ItemSizes {
override def getSize: kg = super[KiloSizes].getSize()
}
:6: error: error overriding method getSize in trait ItemSizes of type ()AllSizes.this.sht;
method getSize has incompatible type ()AllSizes.this.kg
trait AllSizes extends KiloSizes with ItemSizes { override def getSize: kg = super[KiloSizes].getSize() }
^
trait AllSizes extends KiloSizes with ItemSizes {
override def getSize: kg = super[KiloSizes].getSize();
override def getSize: sht = super[ItemSizes].getSize
}
:6: error: method getSize is defined twice
trait AllSizes extends KiloSizes with ItemSizes {
override def getSize: kg = super[KiloSizes].getSize();
override def getSize: sht = super[ItemSizes].getSize
}
Здравствуйте, Gajdalager, Вы писали:
G>Здравствуйте, mkizub, немного не понял претензий:
M>>1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно. M>>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые. M>>Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает M>>площать в метрах квадратных. G>Тип описывается так же, как и в Жаве. То, что ты можешь его не указывать и он сам выведется из использования, всего лишь синтаксичекий сахар... Так что G>
G>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.
G>Утверждение правильное, но Скала этого и не нарушает.
Что значит не нарушает?! Разве это не скомпилируется?
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Gajdalager, Вы писали:
G>>Здравствуйте, mkizub, немного не понял претензий:
M>>>1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно. M>>>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые. M>>>Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает M>>>площать в метрах квадратных. G>>Тип описывается так же, как и в Жаве. То, что ты можешь его не указывать и он сам выведется из использования, всего лишь синтаксичекий сахар... Так что G>>
G>>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые.
G>>Утверждение правильное, но Скала этого и не нарушает.
M>Что значит не нарушает?! Разве это не скомпилируется?
M>object test { M> trait KiloSize { M> def getSize() : int; M> } M> trait ItemSize { M> def getSize() : int; M> } M> def getSize() : int = 10; M> def main(args: Array[String]) : unit = M> { M> test.asInstanceOf[KiloSize].getSize(); M> test.asInstanceOf[ItemSize].getSize(); M> } M>}
M>разве test семантически имеет getSize() в килограммах или в штуках? Может он в метрах его имеет.
Упс. Вопрос снят. Просто Scala не проконтролировала, что test как singleton тип не может быть
унаследован никаким новым типом, и следовательно надо выдавать ошибку компиляции на asInstanceOf[KiloSize]
В рантайме оно прекрасно выдала ошибку кастинга.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Gajdalager, Вы писали:
M>Что значит не нарушает?! Разве это не скомпилируется?
M>object test { M> trait KiloSize { M> def getSize() : int; M> } M> trait ItemSize { M> def getSize() : int; M> } M> def getSize() : int = 10; M> def main(args: Array[String]) : unit = M> { M> test.asInstanceOf[KiloSize].getSize(); M> test.asInstanceOf[ItemSize].getSize(); M> } M>}
M>разве test семантически имеет getSize() в килограммах или в штуках? Может он в метрах его имеет.
Угу... А запускать пробовал?
C:\Program Files\scala\bin>scala test
java.lang.ClassCastException: test$
at test$.main(Test.scala:11)
at test.main(Test.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at scala.tools.nsc.ObjectRunner$.run(ObjectRunner.scala:75)
at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:106)
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
C:\Program Files\scala\bin>
Почти аналогичный код на Жаве:
public class TestJava
{
public int getSize()
{
return 10;
}
public static void main(String[] args) {
TestJava object = new TestJava();
((KiloSize)object).getSize();
((ItemSize)object).getSize();
}
}
interface KiloSize
{
public int getSize();
}
interface ItemSize
{
public int getSize();
}
Exception in thread "main" java.lang.ClassCastException: TestJava
at TestJava.main(TestJava.java:42)
<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Ayreon — Out Of The White Hole
Здравствуйте, mkizub, Вы писали:
M>Что значит не нарушает?! Разве это не скомпилируется?
Конечно, ведь ты используешь явное приведение. Это аналогично void *p; (MyClass *)p->upps.
M> test.asInstanceOf[KiloSize].getSize(); M> test.asInstanceOf[ItemSize].getSize();
M>разве test семантически имеет getSize() в килограммах или в штуках? Может он в метрах его имеет.
Извини, но это ерунда какая-то. При чем тут вообще килограммы и штуки, если объект test всего лишь декларирует трейты,
но не имеет к ним никакого отношения (разве что как outer). Я често вообще не понял, чего ты вообще хотел добиться этим кодом, эмулировать питон? scala вообще-то строго и статически типизированный язык с выводом типов...
Правильнее было бы (правда это уже не python-like, но уже и не грубое приведение типа непонятно к чему):
object test {
trait KiloSize {
def getSize() : int;
}
trait ItemSize {
def getSize() : int;
}
def getSize() : int = 10;
def sz[T](a: => T) = a match {
case k: KiloSize => k.getSize()
case i: ItemSize => i.getSize()
case t: test.this.type => t.getSize()
case _ => throw new Error("What is this?")
}
def main(args: Array[String]) = {
println(sz(this))
println(sz(new KiloSize { override def getSize(): int = 20 }))
println(sz(new ItemSize { override def getSize(): int = 30 }))
println(sz(1))
}
}
scala -cp target test
10
20
30
java.lang.Error: What is this?
at test$.sz(methods.scala:26)
at test$.main(methods.scala:33)
...
Здравствуйте, aka50, Вы писали:
A>Правильнее было бы (правда это уже не python-like, но уже и не грубое приведение типа непонятно к чему):
А если еще подумать, то можно вообще вот так
object test {
trait WithSize {
val getSize: ()=> int
}
trait KiloSize {
def kilos() : int;
}
trait ItemSize {
def items() : int;
}
class KiloEntity extends WithSize {
val getSize = mySize.kilos _
val mySize = new KiloSize { override def kilos() = 1 }
}
class ItemEntity extends WithSize {
val getSize = myItems.items _
val myItems = new ItemSize { override def items() = 2 }
}
def size(sizeable: WithSize) {
println(sizeable.getSize())
}
def main(args: Array[String]) = {
val k = new KiloEntity
size(k)
val i = new ItemEntity
size(i)
}
}
Здравствуйте, mkizub, Вы писали:
VD>>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные. M>Несогласие с базовой концепцией, тормознутость.
А можно пояснить в чем заключается несогласие?
M>Встречный вопрос. А зачем вам этот опрос?
Скала очень перспективный язык, но нужен ли он ява-комьюнити? И если не нужен, то очень интересует аргументация.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
M>1. Тип описывается сигнатурой всех методов. Это, по моему, просто не правильно. M>Если у меня есть два класса (интерфейса) с методом getSize(), то это не значит, что они одинаковые. M>Эти методы могут быть семантически разные. Скажем, один возвращает количество в штуках, а другой возвращает M>площать в метрах квадратных.
Возможно. Не знаю...
M>2. Делать из методов объекты — это удобно, иногда, но это жуткий оверхед.
100% заблуждаешся. К тому же объекты скорее всго делаются не из методов, а из замыканий. Их по другому сделать очень не просто.
M>3. Лепить во все места view-s — это удобно для code reuse, но это жуткий оверхед.
В чем тут оверхэд? К тому же вроде бы от view отказались в новой верси. Или я что-то путую?
M>Вообще, создатели языков вынуждены делать выборы, которые определяют область использования языка. M>В C++ выбрали полную обратную совместимость с С,
Не полную, а приемлемую.
M> и принцип — пока ты фичу не пользуешь, она не должна M>давать оверхеда в твоём коде.
Пока ты не используешь замыкания ты точно так же не получашь оверхэд. Да и оверхэд там минимльный. Так что все тоже самое.
Да и гулпо сравнивать Скалу с С++. С++ дпотопный язык, с морем граблей и без автоматического управления памятью. Писать на нем во много аз сложнее чем даже на Яве. Со Скалой его вообще сравнивать нельзя. Это как сравнивать телегу с вездеходом.
Мнея интересует сравнение с Явой. Потому на этом форуме и задал ворос. Понятно, что Ява в следствии дизайна имеет некоторый оверхэд по сравнению с С/С++, но все же он приемлем для многих применений. Скала вроде бы не сильно его увеличивает. Или я ошибаюсь?
M> Это привело к тому, что С++ скоро сдохнет, вытесненный конкурентами,
Думаю, нас он переживет.
M>которые себе такой груз на спину не взвалили. В яве сделали выбор в пользу параноидальной защищённости M>и верифицируемости кода всегда. Получили тормоз, даже когда исполняется trusted приложение, даже M>если оно пытается переложить работу на нэйтив код — всё равно тормоз. И так далее.
Спор по поводу скорости Явы меня не интересует. Меня интересует сравнение с Явой (языком).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, aka50, Вы писали:
A>Правда в рассылке недавно активно обсуждали синтаксис макросов, но пока не понятно, что же все таки решили... Небольшое описание создания DSL на scala можно тут почитать: http://phoenix.labri.fr/DSPD/final/dubochet2006zytyg.pdf
Прикольно. Если дело пойдет так и дальше, то Скала и Немрле будут почти близнецами .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mkizub, Вы писали:
M>>Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании M>>дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки. M>>Шажок Scala, шажок Nemerle, шажок XL. Как по мне, это похоже это на перепрыгивание пропасти в два прыжка. M>>Но я только рад этим языкам. Чем быстрее ими начнут пользоваться, тем быстрее поймут их принципиальную ограниченность.
VD>Можно по подробнее? В чем проблема? В чем решение?
Здравствуйте, VladD2, Вы писали:
VD>Да и гулпо сравнивать Скалу с С++. С++ дпотопный язык, с морем граблей и без автоматического управления памятью. Писать на нем во много аз сложнее чем даже на Яве. Со Скалой его вообще сравнивать нельзя. Это как сравнивать телегу с вездеходом.
VD>Мнея интересует сравнение с Явой. Потому на этом форуме и задал ворос. Понятно, что Ява в следствии дизайна имеет некоторый оверхэд по сравнению с С/С++, но все же он приемлем для многих применений. Скала вроде бы не сильно его увеличивает. Или я ошибаюсь?
Я не сравниваю Scala с С++.
Я пишу о том, что разработчик языка делает выбор, исходя из своих собственных представлений о том, как правильно, хорошо, как надо.
И потом про это книжки пишет, почему я выбрал так, а не иначе.
А загогулина в том, что автор другого языка сделал прямо противоположный выбор, и тоже правильный, тоже обоснованный.
Тоже книжки пишет, почему его выбор правильный.
Это трудно понять с первого раза, но решение проблемы "какой язык лучше" не в спорах о том, чей выбор правильней.
Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
Здравствуйте, aka50, Вы писали:
M>>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке. A>Может тогда стоит глянуть на lisp и не изобретать лисапед?
А в лиспе тоже есть недостаток. Маленький такой, но удаленький.
Он неудобен для чтения, и, следовательно, понимания написанного.
Поэтому и не мэйнстрим, а маргинальный язык, хотя труда в него вложили немеряно, вплоть до
аппаратных лисповских машин.
Собственно, лисп и надо брать за начальную точку расширяемого языка. Только убрать текст.
Dylan часто обзывают лиспом с удобным синтаксисом. Всё равно не получил распространения,
хотя, скорее, по историческим причинам (apple финансировала, а потом забила на него).
Ну и производительность тоже была гвоздём в гроб как Lisp-а так и Dylan-а и прочих.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, mkizub, Вы писали:
M>>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
К>А вот это — сферический конь в вакууме. К>Смысл использования имеющихся инструментов, как раз в использовании проверенных выборов, чтоб не заморачиваться на подробности малозначительные вещи, не интересные для решения нужной задачи. Скажем, использовать GC вместо ручного управления памятью и т.п.
Отсутствие принятия выбора дизайна означает, что если программисту надо — он будет использовать GC, если не надо — не будет. Если надо — часть программы с использованием GC, а часть на ручном управлении.
Ты опять думаешь в терминах, когда за тебя выбирают — выберут тебе низкоуровневый язык или высокоуровневый.
К>Это как с теми же макросами — давать писать их всем подряд, конечно, забавно, только вот на практике не есть очень умный вариант. Свободы программисту должно быть достаточно чтоб решать поставленную перед ним задачу, но не более — излишняя свобода лишь порождает лишние проблемы, отвлекает и т.п.
Ты ведь считаешь себя умнее других, да?
Кто ты такой, чтоб решать — давать другим в руки макросы, или не давать? Ты папа им?
Выбирать использовать или не использовать макросы должен дизайнер проекта. Он знает для чего этот проект, на каких машинах, какие требования к надёжности и прочее.
Это его работа такая — выбрать инструменты и дизайн под конкретную задачу.
А сейчас его работу пытаются делать создатели языка. Вот они и создают сферический язык в вакууме.
К>Другое дело, что непонятно как найти нужную долю этой свободы и как её чётко ограничить
Действительно, такая маленькая проблема
К>Ну и должны быть разные "уровни" программистов с разными разрешениями.
Здравствуйте, mkizub, Вы писали:
M>Отсутствие принятия выбора дизайна означает, что если программисту надо — он будет использовать GC, если не надо — не будет. Если надо — часть
программы с использованием GC, а часть на ручном управлении.
О том и говорится, только суть в том, что это разные, отделённые логически части и для каждой используется свой набор средств и смешивать их на мой взгляд очень чревато.
M>Ты опять думаешь в терминах, когда за тебя выбирают — выберут тебе низкоуровневый язык или высокоуровневый.
Т.е. ты как мегапсихолог, знаешь в каких терминах я думаю и о чём?
Несколько самонадеянно, не считаешь?
M>Ты ведь считаешь себя умнее других, да?
Да куда мне
До тебя ещё расти и расти, как посмотрю.
M>Кто ты такой, чтоб решать — давать другим в руки макросы, или не давать? Ты папа им?
Кто тебе сказал, что это должен решать я? Будет решать тот человек, в чьи обязанности это входит.
M>Это его работа такая — выбрать инструменты и дизайн под конкретную задачу. M>А сейчас его работу пытаются делать создатели языка. Вот они и создают сферический язык в вакууме.
Посмею огорчить тебя — языки эти работают и выполняют задачи, для которой они созданы, в отличие от.
К>>Другое дело, что непонятно как найти нужную долю этой свободы и как её чётко ограничить M>Действительно, такая маленькая проблема
Я вот не пойму — тебе сказать чтоль по сути нечего и ты переходишь на сарказм?
Если есть идеи — высказывай, покая лично я ничего в твоих высказываниях не вижу (хотя, возможно, это особенности моего взгляда, но способность объяснять со стороны также очень важна для понимания)
Здравствуйте, aka50, Вы писали:
A>Нормальный язык должен включать набор инструментов для реализации определенных задач и выбор этого языка или платформы, A>как инструмента, определяется задачей. Если язык излишне гибкий выбор уже становиться достаточно сложный, т.к. вместо A>одного большого рубильника менеджеру предлагается выбрать из кучи мелких выключателей (при чем не всегда очевидны взаимосвязи A>этих выключателей).
Знаешь, а прикольная идея как раз эдакий "рубильник" встроить в сам язык, чтоб можно было бы регулировать соотношение гибкость/жёсткость в ту сторону, которую нужно, причём, чтоб это было универсальным подходом, как сама расширяемость того же лиспа.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, mkizub, Вы писали:
M>>Отсутствие принятия выбора дизайна означает, что если программисту надо — он будет использовать GC, если не надо — не будет. Если надо — часть К>программы с использованием GC, а часть на ручном управлении. К>О том и говорится, только суть в том, что это разные, отделённые логически части и для каждой используется свой набор средств и смешивать их на мой взгляд очень чревато.
Конечно чревато. Но надо.
Любой достаточно сложный проект имеет ядро, где нужно низкоуровневое программирование, и которое занием в среднем 20% кода.
А остальная часть занимается более высоким уровнем.
Их смешивать чревато, но приходится.
Я 5 лет профессионально занимался разработкой JVM. Вот там одна часть должна выделять память руками, а другая через GC.
И всё это должно работать вместе.
M>>Ты опять думаешь в терминах, когда за тебя выбирают — выберут тебе низкоуровневый язык или высокоуровневый. К>Т.е. ты как мегапсихолог, знаешь в каких терминах я думаю и о чём? К>Несколько самонадеянно, не считаешь?
Что самонадеяно? Я разве сказал что-то, чего ты не говорил?
M>>Ты ведь считаешь себя умнее других, да? К>Да куда мне К>До тебя ещё расти и расти, как посмотрю.
Конечно. Ты же знаешь как надо писать и как правильно писать. Это так легко сказать — не смешивайте разные
языки. А покажи хоть один большой проект, где они не смешаны.
M>>Кто ты такой, чтоб решать — давать другим в руки макросы, или не давать? Ты папа им? К>Кто тебе сказал, что это должен решать я? Будет решать тот человек, в чьи обязанности это входит.
Не может. Архитектор проекта по написанию JVM и рад-бы, да те, кто писал С уже решили, что GC
не нужен, а те, кто писал Java решили, что он нужен. Вот позарез нужно для кода, генерируемого
С-шным компилятором генерировать stack maps, чтоб GC этими картами пользовался. А нэту такого
компилятора. А писать ещё и компилятор на С — это слишком накладно для проекта.
M>>Это его работа такая — выбрать инструменты и дизайн под конкретную задачу. M>>А сейчас его работу пытаются делать создатели языка. Вот они и создают сферический язык в вакууме. К>Посмею огорчить тебя — языки эти работают и выполняют задачи, для которой они созданы, в отличие от.
Я говорю не "для которых они созданы", а "которые нужны для этого проекта". Небо и земля.
У тебя есть язык, созданный для написания VM?
К>>>Другое дело, что непонятно как найти нужную долю этой свободы и как её чётко ограничить M>>Действительно, такая маленькая проблема К>Я вот не пойму — тебе сказать чтоль по сути нечего и ты переходишь на сарказм? К>Если есть идеи — высказывай, покая лично я ничего в твоих высказываниях не вижу (хотя, возможно, это особенности моего взгляда, но способность объяснять со стороны также очень важна для понимания)
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, aka50, Вы писали:
К>Знаешь, а прикольная идея как раз эдакий "рубильник" встроить в сам язык, чтоб можно было бы регулировать соотношение гибкость/жёсткость в ту сторону, которую нужно, причём, чтоб это было универсальным подходом, как сама расширяемость того же лиспа.
Идея может и хорошая, но есть кучка минусов:
1. Рушится стройная концепция языка, т.к. разработчик вынужден кроме реализации собственно языка производить еще и тонкую настройку "рубильников"
2. Разработчик языка должен предусмотреть интероперабельность различных "рубильников", результаты такого подхода мы можем все наблюдать в java 1.4 vs 1.5
3. Если этих рубильников в языке будет много, начнется "dll-hell" и реализовать пп2 будет еще сложнее
По этому и получаем: либо красивый язык, но включающий все и сразу с определенными ограничениями (принятыми разработчиками исходя из задач языка или иных мотивов) или получаем lisp где в общем-то не сложная и распространенная конструкция list coprehension превращается в доп библиотеку...
Здравствуйте, aka50, Вы писали:
M>>Поэтому и не мэйнстрим, а маргинальный язык, хотя труда в него вложили немеряно, вплоть до M>>аппаратных лисповских машин. A> Очень смешно.
M>>Собственно, лисп и надо брать за начальную точку расширяемого языка. Только убрать текст. A>Можно вопрос, сколько времени ты писал на лиспе? Я около 5-ти лет, пока работал в emacs (правда лисп там A>самый наверное убогий из всех возможных). Так вот смею тебя заверить "проблема синтаксиса" — это миф. A>Проблема "сложности" лиспа в его излишней гибкости.
Я на нём пытался писать несколько раз.
Не поборол скобок.
Этот "миф" я проверил на собственном опыте.
Я знаю, что некоторые люди могут на нём писать — но этих людей 5% от программистов. Статистика придумана
на основе реального использования лиспа, а не голословных утверждений, что эта проблема — миф.
A>Нормальный язык должен включать набор инструментов для реализации определенных задач и выбор этого языка или платформы, A>как инструмента, определяется задачей. Если язык излишне гибкий выбор уже становиться достаточно сложный, т.к. вместо A>одного большого рубильника менеджеру предлагается выбрать из кучи мелких выключателей (при чем не всегда очевидны взаимосвязи A>этих выключателей). A>Cравни: A>
A>Haskell: [ (x, y) | x<-[0,1,2,3], y <- [0,1,2,3], x < y]
A>Python: [(x, y) for x in [0,1,2,3] for y in [0,1,2,3] if x < y]
A>Scala: for( x <- 0::1::2::3::Nil; y <- 0::1::2::3::Nil if x < y) yield (x,y)
A>Lisp: (comprehension (cons x y)
A> ((x '(0 1 2 3)) (y '(0 1 2 3)))
A> ((< x y)))
A>
A>А теперь вопрос: где гибче синтаксис и язык и где лучше понимаемость кода? И самое интересное: почему в самом гибком языке нужно явно указывать, что это у нас comprehension?
Вот и должен один программист работать в понятиях, где неважна конкретная реализация, конкретный рубильник.
А другой программист должен это понятие реализовать, выразить в низкоуровневых операциях. И первый не должен беспокоиться как сделать работу за второго.
Что до твоего вопроса — так везде синтаксис и понимаемость приблизительно на одном уровне.
И она не имеет никакого отношения к реальным проектам в миллионы строк кода.
Там совсем другие проблемы. Совсем.
Здравствуйте, deniok, Вы писали:
M>>>>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
К>>>А вот это — сферический конь в вакууме. К>>>Смысл использования имеющихся инструментов, как раз в использовании проверенных выборов, чтоб не заморачиваться на подробности малозначительные вещи, не интересные для решения нужной задачи. Скажем, использовать GC вместо ручного управления памятью и т.п.
M>>Отсутствие принятия выбора дизайна означает, что если программисту надо — он будет использовать GC, если не надо — не будет. Если надо — часть программы с использованием GC, а часть на ручном управлении. M>>Ты опять думаешь в терминах, когда за тебя выбирают — выберут тебе низкоуровневый язык или высокоуровневый.
D>За языком лежит семантическая модель рантайма. От этого никуда не денешься.
Модель рантайма тоже можно сделать расширяемой.
D>Языки существуют, чтобы порождать исполняемые программы. Если мы имеем низкоуровневую native модель (стек+heap+статическая память+допустимая явная адресация+OS processes+OS threads), то сколько бы мы ни дизайнили язык — выйдет C++. Более абстрактные модели должны что-то явно запрещать, иначе допустимые хаки на более низкий уровень разрушат целостность абстракций.
Похоже, но не совсем так.
Следующий уровень не может полностью опираться на предыдущий уровень, и быть при этом эффективным.
Ему нужен предущий уровень, плюс ещё немножко ещё более глубого уровня. И это "плюс ещё немножко" должно быть добавлено к предыдущему уровню.
Если ты напишешь на С GC для JVM, то явовский код, конечно, будет работать.
Но С-шный код не сможет работать с памятью выделенной явовским кодом, которая контролируется GC.
Потому как GC сделает heap compaction, и все С-шные ссылки будут показывать в небо.
Если не добавить поддержку GC в С — то работать нэйтивным функциям будет чрезвачайно тяжело.
Аналогично, для написания эффективной явовской программы ей нужны низкоуровневые хаки.
Немного. В соответствии с известным законом 20/80 — 20% кода выполняются 80% времени.
Вот для этого "ядра" нам нужны низкоуровневые операции. То-же использование ссылки
вместо массив+индек может съекономить один регистр, и его не надо будет таскать между стеком и процессором,
и это ускорит выполнение итерации по массиву в разы.
Вот одна из задач, которые нужно было решать при написании библиотеки для JVM для мобилок.
Поступает буффер картинки (битмап), например в RGB888, его надо преобразовать в буффер для экрана
в формате RGB565. Буффер — явовский массив. Входных форматов десяток. Промежуточных трансформаций
(добавить/убрать alpha, поменять порядок байт и пр.) тоже достаточно. Если сгенерировать код
на каждый вариант преобразования — он килобайт 100 займёт, сколько и вся остальная библиотека.
Тогда пишем код на яве, который чуть более сложен, чем просто копирование байтов.
Работает ужасно медленно — постоянные проверки на null и границы массива, и это на Thumb
инструкиях, всё в регистры не влазит — короче тормоз.
Хорошо, переписали на С — и из-за плясок вокруг GC (и зарегестрировать ссылку, и все ссылки
volatile, потому как GC может массив подвинуть в памяти в любой момент) — тормозит
так-же жутко, как и код на яве.
Если бы в С добавили поддержку GC, или убрали из явы проверку (только в этом месте) на границы
и нуль — заработало бы в разы быстрее. А эта операция меряется всеми бенчмарками, сделаешь
медленно — мобилку не купят, фирма разорится.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, aka50, Вы писали:
M>Я на нём пытался писать несколько раз. M>Не поборол скобок. Этот "миф" я проверил на собственном опыте.
Ага. "Не читал, но осуждаю". Желающий решить проблемы, их решает, не желающий — находит отговорки.
А скобки борются легко и не принужденно — на первом этапе редактором (например в emacs я себе выставил им бледно серый цвет), а после пары месяцев уже редактор будет не нужен.
M>Я знаю, что некоторые люди могут на нём писать — но этих людей 5% от программистов. Статистика придумана на основе реального использования лиспа, а не голословных утверждений, что эта проблема — миф.
Пока голословны твои утверждения. В отличии от тебя, я
1. Не претендую на мессию с серебряной пулей в зубах без достаточных знаний других "пуль"
2. Я стараюсь долго щупать что-то, прежде чем выносить вердикт, а не ориентируюсь на какие-то "статистики" (статистики я потом читаю, чтобы не вносить предвзятость в первоначальное впечатление)
A>>А теперь вопрос: где гибче синтаксис и язык и где лучше понимаемость кода? И самое интересное: почему в самом гибком языке нужно явно указывать, что это у нас comprehension?
M>Вот и должен один программист работать в понятиях, где неважна конкретная реализация, конкретный рубильник. M>А другой программист должен это понятие реализовать, выразить в низкоуровневых операциях. И первый не должен беспокоиться как сделать работу за второго.
Это утопия. ORM — хороший пример идеи "мы не зависим от БД". Или ты считаешь, что пишущие orm-ы заблудшие овечки?
M>Что до твоего вопроса — так везде синтаксис и понимаемость приблизительно на одном уровне.
жаль что ты не понял что именно я хотел показать...
M>И она не имеет никакого отношения к реальным проектам в миллионы строк кода. M>Там совсем другие проблемы. Совсем.
Присоединюсь к вопросу Курилки, какие? (именно в свете рубильников и рантаймов)
Здравствуйте, aka50, Вы писали:
К>>Знаешь, а прикольная идея как раз эдакий "рубильник" встроить в сам язык, чтоб можно было бы регулировать соотношение гибкость/жёсткость в ту сторону, которую нужно, причём, чтоб это было универсальным подходом, как сама расширяемость того же лиспа.
A>Идея может и хорошая, но есть кучка минусов: A>1. Рушится стройная концепция языка, т.к. разработчик вынужден кроме реализации собственно языка производить еще и тонкую настройку "рубильников" A>2. Разработчик языка должен предусмотреть интероперабельность различных "рубильников", результаты такого подхода мы можем все наблюдать в java 1.4 vs 1.5 A>3. Если этих рубильников в языке будет много, начнется "dll-hell" и реализовать пп2 будет еще сложнее
A>По этому и получаем: либо красивый язык, но включающий все и сразу с определенными ограничениями (принятыми разработчиками исходя из задач языка или иных мотивов) или получаем lisp где в общем-то не сложная и распространенная конструкция list coprehension превращается в доп библиотеку...
Так не в один язык надо встраивать, а сделать как в .NET — высокоуровневые языки и низкоуровневые языки.
Большую часть кода (80%) писать на высокоуровневом. Ядро (20%) писать на низкоуровневом.
Здравствуйте, Курилка, Вы писали:
M>>Там совсем другие проблемы. Совсем. К>Предметно-то сказать можешь?
Ну возьми те-же скриптовые языки. Как на них удобно писать маленькие программы. Ни типов объявлять,
ни о скорости заботиться. А попробуй написать на скриптовом языке большую программу — очень
скоро начнётся такая борьба с вылазящими изо всех щелей ошибками связанными с типами, что
проект застынет на месте.
Или эту эпопею с Java. Все-ж бросились, как она вышла, писать на ней web browser.
И Sun, и Netscape. И написали. Да только оно так тормозило и столько ресурсов ело,
что забили на эти проекты. А бросились их писать из-за того, что этот С/С++ достал
своими ошибками с указателями, переполнением буферов и ручным управлением памятью
(которая и текла и баги выдавала при удалении живых объектов — одновременно).
Большой проект — это всегда смесь противоречивых требований. И надёжно должно быть,
и работать быстро, и писать программу надо быстро и дёшево. Эти требования можно
разрешить только разделяя программу на разные уровни — внешний (где скрипты рулят),
внутренний (где требования промежуточные), ядро (где нужно быстро и надёжно, но
которое не такого большого размера, и можно его писать долго и дорого).
Писать эти разные части на разных языках — замечательно выходит.
Проблемы начинаются, когда эти разные языки пытаются соединить вместе.
А у них рантайм разный. И всё, приплыли. Передача данных и управления между
разными слоями становится настолько сложной и тормознутой, что это перечёркивает
все преимущества разделения проекта на разные части. И мы опять у разбитого корыта.
Здравствуйте, mkizub, Вы писали:
M>Большой проект — это всегда смесь противоречивых требований. И надёжно должно быть, M>и работать быстро, и писать программу надо быстро и дёшево. Эти требования можно M>разрешить только разделяя программу на разные уровни — внешний (где скрипты рулят), M>внутренний (где требования промежуточные), ядро (где нужно быстро и надёжно, но M>которое не такого большого размера, и можно его писать долго и дорого). M>Писать эти разные части на разных языках — замечательно выходит. M>Проблемы начинаются, когда эти разные языки пытаются соединить вместе. M>А у них рантайм разный. И всё, приплыли. Передача данных и управления между M>разными слоями становится настолько сложной и тормознутой, что это перечёркивает M>все преимущества разделения проекта на разные части. И мы опять у разбитого корыта.
А если воспользоваться связкой Java+Groovy, Java+Scala — ведь они по сути будут
исполняться в рамках одной JVM, поэтому никаких проблем с взаимодействием быть не должно
(для груви можно вообще явно сформировать переменные из явы, а кроме того никто не отменял синглтон).
Здравствуйте, 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 выражения, а чтоб оно было
константным во время компиляции. Ну ввёл, ну работает, макросы помогает замечательно писать. Нестыковок не нашёл
Здравствуйте, 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 индусов.
Хорошая новость хорошим программистам — получать они будут больше денег.
Плохая новость плохим программистам — или они будут работать над своим профессиональным ростом, или пусть идут в дворники.
Шутка.
Здравствуйте, 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 у меня в журнале об этом писал.
Здравствуйте, mkizub, Вы писали:
M>Посмотри на код, генерируемый Scala и ужаснись.
Покажи... вот честно, интересно... а то пока только пугаешь (есть там конечно кривости, но как это сделать иначе я тоже не сильно представляю)
M>Или вот, пусть мне нужны параметры типов в рантайме. Чтоб я мог написать M>List<String> ls = ...; M>String[] arr = ls.toArray(); M>а не M>String[] arr = ls.toArray(new String[ls.size()]);
Вообще-то разработчику vm должно быть стыдно, если он не знает почему именно требуется объект массива
на scala это решается безо всяких прыжков:
scala> val ls = 1 :: 2 :: Nil
ls: List[Int] = List(1, 2)
scala> ls.toArray
unnamed1: Array[Int] = [I@4854f6 << обрати внимание, что тут именно нейтив массив, а не boxed
Код в самой скала самый обычный:
override def toArray[B >: A]: Array[B] = {
val result = new Array[B](size)
copyToArray(result, 0)
result
}
Другой вопрос, когда мы хотим что-то такое, но это уже спасибо блин erasure...
Здравствуйте, Курилка, Вы писали:
M>>http://www.rsdn.ru/Forum/message/2520182.aspx К>Прикольно — рсдн противится, ссылка не работает, выдаёт форму логина в обоих фреймах, причём логин/пароль не срабатывает, хотя на др. сообщениях рсдн всё корректно
Все верно. Ссылка ведет в приватный форум.
Туда есть доступ только у команды.
У mkizub есть доступ только к этой теме в форуме.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Курилка, Вы писали:
M>>>http://www.rsdn.ru/Forum/message/2520182.aspx К>>Прикольно — рсдн противится, ссылка не работает, выдаёт форму логина в обоих фреймах, причём логин/пароль не срабатывает, хотя на др. сообщениях рсдн всё корректно WH>Все верно. Ссылка ведет в приватный форум. WH>Туда есть доступ только у команды. WH>У mkizub есть доступ только к этой теме в форуме.
Здравствуйте, aka50, Вы писали:
M>>Первое, что сделаю, когда редактор стрелки научится рисовать — перепишу все эти control flow M>>красиво.
A>нуну... текст тем и отличается, что позволяет разобраться, а вот визуальное представление A>во первых элементарно менее компактно (т.к. требует разместить все в одном месте, иначе ты либо потеряешь конкретику, либо стрелки будут уезжать за экран что не способствуем лучшему пониманию кода) A>во вторых требует дополнительного кодирования (например цветами и формой) чтобы можно было ориентироваться
A>Как пример для анализа: http://kernelmapper.osdn.com/map.php Мне лично удобнее использовать grep + ide, чем пытатся в этой куче что-то найти
Ты хочешь привести всё к одному знаменателю. Либо только текст, либо только диаграмы.
Не надо этого. Можно и то и другое. Рисовать flow control удобнее стрелками. Да, с цветами — типа чёрным безусловные переходы, красным — если выражение true и синим — если false.
А другие вещи лучше выразить текстом. Желательно тоже расцвеченым. Ты же не возражаешь против colorer-ов? А некоторые вещи удобнее как математика, формулами рисовать.
Здравствуйте, mkizub, Вы писали:
M>Но плюс к тому, его ещё можно просто записать новое семантическое понятие для сортировки как M>node Sort { M> attribute Expr container; M>} M>и рисовать это как M>sort list M>а в виде дерева (приведу в виде XML дампа) M><node type="Sort"> M> <container> M> <node type="VarRef"> M> <name>list</name> M> </node> M> </container> M></node>
M>А при трансляции это будет разворачиваться плагином в дерево узлов соответствующее хаскелевской семантике, или С-шной семантике, в зависимости от наших пожеланий.
Вот тут начинаю не понимать. Это какой-то очень-очень умный плагин. Который, получив только что введённое семантическое понятие Sort, описанное к тому же далеко не исчерпывающей семантикой (тут же нет формально описанного требования, что мы хотим получить отсортированный контейнер), разворачивается, по твоим словам, в дерево узлов, соответствующих семантике сортировки. В такой записи, ИМХО, это не что иное, как указание программисту на конкретном языке написать (или использовать существующий) код сортировки, и не более того.
Здравствуйте, deniok, Вы писали:
D>Вот тут начинаю не понимать. Это какой-то очень-очень умный плагин. Который, получив только что введённое семантическое понятие Sort, описанное к тому же далеко не исчерпывающей семантикой (тут же нет формально описанного требования, что мы хотим получить отсортированный контейнер), разворачивается, по твоим словам, в дерево узлов, соответствующих семантике сортировки. В такой записи, ИМХО, это не что иное, как указание программисту на конкретном языке написать (или использовать существующий) код сортировки, и не более того.
Мы вводим в SOP семантический узел. Как он реализован — это другой вопрос. В этом одно из преимуществ SOP.
Если у нас операция сортировки прямо поддерживатся виртуальной машиной — то на этом практически всё. Если нет — надо определять Sort через другие семантические узлы, в конечном итоге пока не дойдём до "нэйтивных" операций.
Конечно, Sort мало кто поддерживает. А вот операция rotate bits некоторыми процессорами поддерживается напрямую. Или операция с deciaml числами. Или векторные инструкции. Или строковые операции на x86 и т.д.
Вот пишет программист на Java 3D игрушку. А в байткоде операции для векторных вычислений нет. Компилятор должен развернуть операцию по сложению двух векторов в последовательность скалярных операций. А потом JIT компилятор должен догадаться, что это на самом деле векторное сложение, и задействовать SIMD инструкции. Байткод — это тоже текст. Это бутылочное горлышко. И точно такое-же бутылочное горлышко — это текстовое представление языка программирования, фиксированный синтаксис.
Сейчас эта проблема ещё не очень остро стоит. Лет через 10 она будет стоять во весь рост, потому как тупо наращивать количество транзисторов в CPU уже нельзя будет. Надо будет делать сложные процессоры. В том числе перепрограммируемые, с изменяемыми коммандами, распределением вычислений по ядрам и многое другое. Представляешь, насколько узким местом станет фиксированный байткод, если программист уже пишет на Scala или Nemerle, и процессор адаптируемый — а байткод фиксированный.
Здравствуйте, mkizub, Вы писали:
M>Сейчас эта проблема ещё не очень остро стоит. Лет через 10 она будет стоять во весь рост, потому как тупо наращивать количество транзисторов в CPU уже нельзя будет. Надо будет делать сложные процессоры. В том числе перепрограммируемые, с изменяемыми коммандами, распределением вычислений по ядрам и многое другое. Представляешь, насколько узким местом станет фиксированный байткод, если программист уже пишет на Scala или Nemerle, и процессор адаптируемый — а байткод фиксированный.
Так ведь VM тоже эволюционируют. Как можно наращивать мощу сохраняя при этом обратную совместимость видно на примере семейства x86, а ведь та же JVM это по сути программный (не железный) процессор, который к тому же добавляет еще один уровень автоматизации под конкретное железо на этапе JIT'a.
Другое дело что байт код по определению не должен зависить от железа (на одном проце какая-то инструкция есть, а на другом нет), поэтому тупо добавлять новомодные фичи наверное не стоит.
Поразмышляв немного над SOP пришел к следующему выводу: по сути предлагается поднять уровень абстракции самого байт кода (в роли байт кода семнатические приблуды SOP, которые потом преобразуются во что угодно (как в JIT)). В приницпе звучит интересно, но вот проблемы там будут те же самые + добавяться некоторые другие:
— кто будет определять как какой узел семантического дерева во что преобразовать?
— а если у меня собственное дерево, мне что самому надо будет делать маппинг подо все платформы?
— а как на счет переносимости по бинарникам? (не придется ли каждый раз запускать всю цепочку преобразования сампольного DSL в машинный код?)
И кто-то еще говорит что Scala тормозит...
Кастати никаких проблем с интеропом коллекций между жабой и встроеной скалой нет, в случае если это коллекции жабы (разве что не получится пользоваться ФП-фичами).
У Interpeter есть замечательный метод bind, типа:
i.bind("list",list.getClassName(),list);
И можно пользоваться list'ом как уже готовой переменной, одно огорчает Interpreter выполняет код только по одной строке, в ближайшее время планирую помучится с ScritpRunner'ом (или как он там называется). С груви вообще никаких проблем.
Кроме того из встроенной скалы замечательно видны все внешние классы жабы, так можно наладить взаимодействие через static, типа
public class Main
{
public static LinkedList<String> list = new LinkedList<String>();
....
public static void main(String[] _args)
{
....
list.add("Hello world!!");
i.interpet("Console.println(embededscala.Main.list.get(0))");
....
}
}
P.S. Единственное что удручает так это тормоза, поэтому возможно проще будет компилить все
заранее (при запуске), а потом дергать уже готовые классы, реализующие некий заранее известный жаба-интерфейс. Как сделать пока не знаю...
Re[18]: Ваше отношение к языку Scala
От:
Аноним
Дата:
10.06.07 13:30
Оценка:
Здравствуйте, mkizub, Вы писали:
M>Вся фишка в том, что предлагается так и писать M>trace WARNING "Message" M>и отдельно написать плагин к компилятору (точнее — среде разработки), который будет это пожелание trace трансформировать M>в понятия более низкого уровня, вроде "вызвать функцию такую-то с такими-то аргументами".
А как программа узнает, что trace значит "оттрэйсит в лог" и в какой лог, BAR или FOO, а не "вывести фигуру на экран"?
M>Программист не будет переводить задачу не с человеческого описания на конкретный язык с конкретными библиотеками. M>Один будет формировать понятия предметной области и либо расширять существующий язык, либо писать отдельный язык. M>А другой будет обеспечивать работу первого — заниматься низкоуровневыми деталями. M>Это разделение позволит ещё больше структурировать программу. Как сейчас одни пишут библиотеки, а другие их M>пользуют, так и предлагается делать, только библиотеки эти будут библиотеками значений, концепций.
Так ведь по сути есть уже похожий язык. SQL. Попробуйте переведите на русский SELECT users FROM U_Table. Пользователи могут так и писать "ВЫБЕРИ МНЕ Пользователь ИЗ U_Table У КОТОРЫХ число_сообщений>100". Чем не устраивает?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, mkizub, Вы писали:
M>>Вся фишка в том, что предлагается так и писать M>>trace WARNING "Message" M>>и отдельно написать плагин к компилятору (точнее — среде разработки), который будет это пожелание trace трансформировать M>>в понятия более низкого уровня, вроде "вызвать функцию такую-то с такими-то аргументами".
А>А как программа узнает, что trace значит "оттрэйсит в лог" и в какой лог, BAR или FOO, а не "вывести фигуру на экран"?
Видимо, из настроек проекта, больше неоткуда.
M>>Программист не будет переводить задачу не с человеческого описания на конкретный язык с конкретными библиотеками. M>>Один будет формировать понятия предметной области и либо расширять существующий язык, либо писать отдельный язык. M>>А другой будет обеспечивать работу первого — заниматься низкоуровневыми деталями. M>>Это разделение позволит ещё больше структурировать программу. Как сейчас одни пишут библиотеки, а другие их M>>пользуют, так и предлагается делать, только библиотеки эти будут библиотеками значений, концепций.
А>Так ведь по сути есть уже похожий язык. SQL. Попробуйте переведите на русский SELECT users FROM U_Table. Пользователи могут так и писать "ВЫБЕРИ МНЕ Пользователь ИЗ U_Table У КОТОРЫХ число_сообщений>100". Чем не устраивает?
Меня SQL вполне устраивает. Хороший язык для своих целей. Вот давайте в этом направлении и двигать
Здравствуйте, mkizub, Вы писали:
VD>>Мнея интересует сравнение с Явой. Потому на этом форуме и задал ворос. Понятно, что Ява в следствии дизайна имеет некоторый оверхэд по сравнению с С/С++, но все же он приемлем для многих применений. Скала вроде бы не сильно его увеличивает. Или я ошибаюсь?
M>Я не сравниваю Scala с С++. M>Я пишу о том, что разработчик языка делает выбор, исходя из своих собственных представлений о том, как правильно, хорошо, как надо. M>И потом про это книжки пишет, почему я выбрал так, а не иначе. M>А загогулина в том, что автор другого языка сделал прямо противоположный выбор, и тоже правильный, тоже обоснованный. M>Тоже книжки пишет, почему его выбор правильный.
M>Это трудно понять с первого раза, но решение проблемы "какой язык лучше" не в спорах о том, чей выбор правильней. M>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
Извини, ты сказал много слов, но закоченного смысла я в них уловить не смог.
Я увидил в твоей критике немой вопрос "почему Скала не С++". Ответ очевиден, потому что это развите Явы.
Я не заметил ни одного дизайнерского выбора авторов Скалы которое шло бы в разрез путем Явы. Да, это не С++-путь, но ведь этого никто и не ждет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Книга { название, аннотация }
[SQLTable: ТаблицаКниг]
class Book {
[SQLField: индекс, primary key] id : int
[SQLField: название, not null, 80 chars] title : string
[SQLField: аннотация, maybe null, long varchar] annotation : long string
private dirty : bool
}
Я мог реализовать в C# (с чуть более строгим синтаксисом) уще несколько лет назад BLToolkit сделаный IT именно это и делал. Единственное, что такая реализация требует много услий. Но потом ее использование уже будет простым.
На Немерле я могу реализовать подобную ведь макросом, так что никакой рантайм-поддержки и моря кода не потребуется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Вот и должен один программист работать в понятиях, где неважна конкретная реализация, конкретный рубильник. M>А другой программист должен это понятие реализовать, выразить в низкоуровневых операциях. И первый не должен беспокоиться как сделать работу за второго.
Замечательно, но Лисп и Немерле как раз предоставлюят такие возможности в виде макроподсистемы. А что же предлагаешь ты?
Чем твой СОМ (или как там его?) отличается от тех же маросов?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Книга { название, аннотация }
VD>[SQLTable: ТаблицаКниг]
VD>class Book {
VD> [SQLField: индекс, primary key] id : int
VD> [SQLField: название, not null, 80 chars] title : string
VD> [SQLField: аннотация, maybe null, long varchar] annotation : long string
VD> private dirty : bool
VD> }
VD>
Там в другом фишка — это не генерация кода, это его изображение, одно для дазайнера и другое для программиста.
Ты можешь один и тот-же код отображать в редакторе программы по разному. В Nemerle ты этого принципиально не можешь — он в себе подобный рендерер кода не имеет.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mkizub, Вы писали:
M>>Вот и должен один программист работать в понятиях, где неважна конкретная реализация, конкретный рубильник. M>>А другой программист должен это понятие реализовать, выразить в низкоуровневых операциях. И первый не должен беспокоиться как сделать работу за второго.
VD>Замечательно, но Лисп и Немерле как раз предоставлюят такие возможности в виде макроподсистемы. А что же предлагаешь ты? VD>Чем твой СОМ (или как там его?) отличается от тех же маросов?
Влад, остановись и подумай. Ещё раз. Внимательней.
Код
[SQLTable: ТаблицаКниг]
class Book {
[SQLField: индекс, primary key] id : int
[SQLField: название, not null, 80 chars] title : string
[SQLField: аннотация, maybe null, long varchar] annotation : long string
private dirty : bool
}
не сгенерирован автоматически из кода
Книга { название, аннотация }
Это никакого отношения к макросам не имеет. Это больше похоже на folding в редакторе, когда блок кода сворачивается в {...}
Только тут не просто сворачивание кода, а отображение самой существенной его части, так как хочет видеть архитектор программы.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mkizub, Вы писали:
M>>Да, JetBrains реализует очень похожую идею. Только они не идут в реализации до конца. M>>Они выходной код генерируют как текст (явовский), и опять попадают в узкое горлышко. M>>Конечно, там ниже всегда будет узкое место, всё равно прийдётся в конечном итоге M>>генерировать машинные комманды.
VD>И в чем же узость подхода с генерациепй Явовского кода?
Там много проблем. Самая простая — отсутствие goto. Без него нарисовать эффективную state machine практически невозможно.
VD>Если у них и есть проблема, то она совсем в другом. Они отказались от нормального текстового представления, что резко усложняет работу с такой системой.
В чём-то усложняет, в чём-то облегчает.
M>>Идея SOP в том, чтоб убрать промежуточные узкие места.
VD>Офигительная идея! Тенет не просто на новую парадигму, а прямо таки на прорыв в IT. VD>Самому то не смешно? Какая разница во что преобразуется более высокоуровневый язык если в итоге мы получаем машинный код?
Я почитал дальше, и мне стало грустно.
Иди ты нафиг.
Здравствуйте, mkizub, Вы писали:
M>А при трансляции это будет разворачиваться плагином в дерево узлов соответствующее хаскелевской семантике, или С-шной семантике, в зависимости от наших пожеланий. M>Разумеется, вводить новый узел только для сортировки будет не очень умно в обычной ситуации, но если вдруг надо будет написать проект, который будет сортировать M>списки в каждой строчке программы — то почему нет?
1. Во что в С++ развернутся функции с паттерн-матчингом?
2. Во что в Хаскеле развернутся перегруженные фукнции?
Ты вообще, знаком с Хаскелем? Ты представлящь насолько это другой язык?
Все что ты сможешь сделать — это создать 10 парсеров для разных синтаксисов одного и того же (по семантике) языка, и создать 10 же прети-принтеров, которые будут преобразовывать твое АСТ в разный синтаксис. Один из принтеров будет графическим.
Толку от этого будет 0.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>>>Но лет несколько назад я понял, что следующая технология будет заключаться в редактировании M>>>дерева семантических узлов, а при сохранении текстовости языка — это только промежуточные к ней шажки. M>>>Шажок Scala, шажок Nemerle, шажок XL. Как по мне, это похоже это на перепрыгивание пропасти в два прыжка. M>>>Но я только рад этим языкам. Чем быстрее ими начнут пользоваться, тем быстрее поймут их принципиальную ограниченность.
VD>>Можно по подробнее? В чем проблема? В чем решение?
M>http://www.rsdn.ru/Forum/message/2520182.aspx M>http://www.symade.org/ M>http://www.symade.com/
Зачем мне ссылки на сайти и на совершенно пустое сообщение? Ты на ответ то можешь ответить?
В прочем, почитав твою дисскуссию я понял, что ты переизобретаель велосипед языко-ориентированногшо программирования. Да еще и далешь это так же как ДжетБрэйновцы. По мне так это бесполезная и провальная идея.
Код и дальше будут писать в тексте. А ЯОП и так неплохо развивается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Курилка, Вы писали:
M>>>http://www.rsdn.ru/Forum/message/2520182.aspx К>>Прикольно — рсдн противится, ссылка не работает, выдаёт форму логина в обоих фреймах, причём логин/пароль не срабатывает, хотя на др. сообщениях рсдн всё корректно WH>Все верно. Ссылка ведет в приватный форум. WH>Туда есть доступ только у команды. WH>У mkizub есть доступ только к этой теме в форуме.
Скажу больше. В этом собщении ничего (ровным счетом) нет. Вот его текст: OE>Здравствуйте, mkizub, Вы писали:
M>>А то ведь по новой это же самое прийдётся повторять всем, а не только рецензентам.
OE>золотые слова! может сразу в статье эти вопросы и осветить?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Там в другом фишка — это не генерация кода, это его изображение, одно для дазайнера и другое для программиста. M>Ты можешь один и тот-же код отображать в редакторе программы по разному. В Nemerle ты этого принципиально не можешь — он в себе подобный рендерер кода не имеет.
Ну, почему же не могу? Я вот в отладочных целях вывожу на экран древесное представление код. Так что потенциально это сделать можн, но не нужно. Точнее так. Можно для кода создать визуальные дизайнеры (дизайнер форм вобщем-то и есть такой дизайнер), но не стоит создавать много синтаксисов для одного языка. Написать прети-принтер чтобы он выдвал лексически разный код можно, но глупо. Создать несколько парсеров тоже можно, но тоже глупо.
В общем, я правильно понял, что вся фишка в том, что товарищь как и ДжетБрэйновцы фактически прелагает отказаться от текста в пользу внутреннего представления и графики (точнее некого представления доступного только в IDE)?
Мне кажется такой подход не перспективным. Код он и в айрике код. Его и в сорс-контрол можно положить, и по контесту заменить, и в форуме разместить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ОК, вопрос в представлении? Ну, и что мне помешает сделать дизайнер котрый отобразит данные в нужном виде?
У меня есть средства которые распарсят код в АСТ и дадут его мне. Остается только взять и отобразить его в нужном виде.
M>Это никакого отношения к макросам не имеет. Это больше похоже на folding в редакторе, когда блок кода сворачивается в {...} M>Только тут не просто сворачивание кода, а отображение самой существенной его части, так как хочет видеть архитектор программы.
Ты говоришь о разных представлениях. Я не понимаю зачем при этом отказыватться от кода. Код — это то в чем хранится программа (текст). А представления — это то, что позволяет отобразить код по разному. Зачем делать полностью новую систему если вся задача втолько в создании разных представлений?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>Расширяемость языка (и создание DSL) как в Lisp, удобство программирования превосходящие WYSIWYG редакторы и современные IDE. M>Возможность программировать ближе к человеческим понятиям.
1. Чем это отличается от языко-ориентированного программирования и DSL-подхода в частности?
2. Чем не удовлетворяют макросы? Они вроде решают эту задачу на олично.
M>Запись M>Logger.getLogger("FooBar").log(WARNING, "Message") fM>это трансляция на язык программирования пожеланя разработчика "каким-то образом сообщить такое-то предупреждение". M>Вся фишка в том, что предлагается так и писать M>trace WARNING "Message"
Хреновый пример. В том же дотете это так и будет выглядеть:
Trace.WriteLine("Message")
И опять же можно наклепать макросы (что и сделано в Немереле, но лично я ими не пользуюсь за ненадобностью).
M>и отдельно написать плагин к компилятору (точнее — среде разработки), который будет это пожелание trace трансформировать M>в понятия более низкого уровня, вроде "вызвать функцию такую-то с такими-то аргументами".
Это и делает макрос. Макрос и есть плагн к компилятру (и по совместительству к IDE).
M>Программист не будет переводить задачу не с человеческого описания на конкретный язык с конкретными библиотеками.
В общем, мне ясно одно. Ты пыташся переизобрести колесо. Макросы давно придуманы, проработаны и реализованы. Выбирай язык который их поддерживает и вперед. Никакие виртуальные машыны тут не помеха. А ты просто явно вместо того, чтобы изучить имеющийся опыт пыташся изобретать давно изобретенные вещи. Естественно, что без учета чужого опцта у тебя ничего путного пе получится. И не надо плеваться на работу тех, кто уже что-то сделал заявляя, что это тупиковый путь. Лучше разберись, что же они сделали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mkizub, Вы писали:
M>>>List<String> ls = ...; M>>>String[] arr = ls.toArray(); M>>>а не M>>>String[] arr = ls.toArray(new String[ls.size()]); M>Я знаю, что он требуется в яве. А в моем комплиторе он не требуется.
Ну это на каждом углу написано: http://www.ibm.com/developerworks/java/library/j-jtp01255.html
1. Массивы примитивный тип, в scala — это объект (c прямой поддержкой компилятора)
2. Массивы в java ковариантны, а генерики нет. java для type safety втыкает проверки в рантайме, scala все делает в compile time.
3. Вывод типа по возращаемым типам не работает.
Конкретно по toArray (что собственно ничто иное как newInstance):
Why was Array generified this way? Again, the frustrating answer is to preserve backward compatibility. To create an array of a primitive type, such as int[], you call Array.newInstance() with the TYPE field from the appropriate wrapper class (in the case of int, you would pass Integer.TYPE as the class literal). Generifying Array.newInstance() with a parameter of Class<T> instead of Class<?> would have been more type-safe for reference types, but would have made it impossible to use Array.newInstance() to create an instance of a primitive array. Perhaps in the future, an alternate version of newInstance() will be provided for reference types so you can have it both ways.
You may see a pattern beginning to emerge here -- many of the problems, or compromises, associated with generics are not issues with generics themselves, but side effects of the requirement to preserve backward compatibility with existing code.
В scala подобных проблем нет (с ковариантностяим/контрвариантностями и primitive type) т.к. все есть объект. Остается одна проблема: erasure. Если твой компилятор ее решает, значит он не совместим с java либо реализует механизм рефлекшина либо скрытые параметры у объектов. Предлагать миру новый рантайм без библиотек может только sun или ms.
К стати, что и куда будет записывать компилятор, чтобы не используя reflection родить тип 'a' в классе Succ?
object ChurchNum {
type _0[s[_], z]= z
type _1[s[_], z]= s[z]
type _2[s[_], z]= s[s[z]]
type plus[m[s[_], z], n[s[_], z], s[_], z] = n[s, m[s, z]]
type _3[s[_], z] = plus[_1, _2, s, z] // = _2[s, _1[s,z]] = s[s[_1[s,z]]]
// = s[s[s[z]]]class Zero
class Succ[a] { def makeMe: a = new a }// в скала этот код не будет работать, естественно...
type +[m[s[_], z], n[s[_], z]] = plus[m, n, Succ, Zero]
type _4 = _2 + _2
// the values van be regarded as proofs that, e.g., 4 = 2 + 2
val proof : Succ[Succ[Zero]] = new _2[Succ, Zero]
val proof_ : Succ[Succ[Succ[Zero]]] = new _3[Succ, Zero]
val proof__ : Succ[Succ[Succ[Succ[Zero]]]] = new _4
}
M>Я не знаю, как в Scala сделан List[Int].toArray, но он не может этого делать M>без инлайнинга или передачи спрятанных параметров в метод. Чудес не бывает. M>Откуда-то метод toArray должен узнать тип массива.
А чудес там и нет, фокус аналогичен работе с примитивными типами в java — boxing:
object arrays {
val ls = "1" :: "2" :: "3" :: Nil
val als = ls.toArray
}
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, aka50, Вы писали:
Ну вот пришел Влад и все испортил. Тут ветка про scala и java была... там где есть java, нет nemerle, но есть scala... любой из этих примеров может работать на jvm, а твой не может
По этому надо уже отделить эту ветку (прос СОМ) и отправить ее в философию (или в декларативное??)
А про макрсы... ну скажем так, когда их очень много — это плохо, т.к. может начаться проблема совместимости (например две команды по разному определили эти самые comprehension, и более того, синтаксические конструкции таковы, что макросы начинают конфликтовать, на уровне компиляторов это решаемо, но на уровне читаемости — это будет плохо).
Но когда они будут в scala, я не откажусь (тем более что уже это обсуждают). Хотя мне пока хватает scala-вского синтаксического сахара и мошьной системы типов.
VD>Так что проблемы Лиспа все же в очень большой степени упираются в его убогий синтаксис и в некоторые другие дизайнерские решения. Ну, и конечно в хреновый маркетинг и никудышное обучение.
Накинулись на старичка...
Здравствуйте, aka50, Вы писали:
A>А про макрсы... ну скажем так, когда их очень много — это плохо, т.к. может начаться проблема совместимости (например две команды по разному определили эти самые comprehension, и более того, синтаксические конструкции таковы, что макросы начинают конфликтовать, на уровне компиляторов это решаемо, но на уровне читаемости — это будет плохо).
Это теоретизирование. Я вот никаких проблем от испоьзования макросов не вижу. Это же не макросы С?! Нужно решить проблему решаемую макросом — используешь макрос. Не нужно — не испоьзуешь. А так можно все что угодно превратить в проблему если использовать не по месту.
A>Но когда они будут в scala, я не откажусь (тем более что уже это обсуждают). Хотя мне пока хватает scala-вского синтаксического сахара и мошьной системы типов.
Очень по Майкрософтовски, пока у нас чего-то нет, то оно лишнее или даже зло, а как появляется, то класная фича, и мы от не не откажемся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Просьба к модераторам не переносить тему в другие форумы, так как интересно мнение исключительно "явных" людей. Если будет равиваться флэйм, то просьба отрезать и грохать эти ответвления, а не переносить всю тему.
VD>Вопросы, собственно, прсоты:
VD>1. Знаете ли вы что такое Scala? VD>2. Если знаете, то как к ней относетесь? VD>3. Не думаете ли вы применить Scala-у в своих разработках? VD>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
Доброго времени!
Сорри, что подтянул такую бородатую ветку
Но, чего-то я прочел 12 страниц обсуждения... и обсуждение темы увидел только на 1-й А дальше либо флейм, либо оффтоп. Либо и то, и другое.
А мне вот интересно недавно стало -- вышел ли Scala за пределы академического интереса? Используют ли его в реальных разработках? А точнее, использует ли его конкретно кто-то из читающих этот форум?
Как бы, идеи хорошие, но как они в реальной работе, в реальных проектах?
Если используете -- то для чего?
Если нет -- пожалуйста, тоже напишите, почему, если только это не будет сообщение типа "а нам и так хорошо в своем скворешнике живется"
Здравствуйте, Kuzz, Вы писали:
K>А мне вот интересно недавно стало -- вышел ли Scala за пределы академического интереса? Используют ли его в реальных разработках? А точнее, использует ли его конкретно кто-то из читающих этот форум?
Я использовать начинаю постепенно.
Просто только сейчас для этого языка появляются нормальные тулзы для разработчиков. Несколько недель назад вышел достаточно рабочий Scala-плугин (http://plugins.intellij.net/preview/popup/?sid=370&pid=1347). Этот плугин пишется самими работниками IntelliJ в рамках развития IDEA, так что это даёт мне некоторые гарантии того, что им достаточно безопасно можно пользоваться. По уровню, пожалуй, этот плугин уже обошёл интеграцию Немерля в Студию.
Пишу простенький HTML layout engine для SWT — т.е. можно будет описывать в HTML как располагать контролы. Что-то типа очень простого HTMLayout. Case-классы для описания DOM-дерева HTML на Scala — просто вкуснятина!
Целиком мои приложения на Scala я переводить не буду, но вот отдельные "интеллектуально-ёмкие" компоненты — очень даже можно. Тем более, что Scala прекрасно интероперирует с Java.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Kuzz, Вы писали:
K>>А мне вот интересно недавно стало -- вышел ли Scala за пределы академического интереса? Используют ли его в реальных разработках? А точнее, использует ли его конкретно кто-то из читающих этот форум? C>Я использовать начинаю постепенно.
Тогда вопрос возникает -- а с чего можно начать его осваивать постепенно? Документация -- довольно не богатая.
Только на своем опыте? Конечно начну, но, естественно, постепенно Но хотелось бы что посерьезнее и побыстрее.
C>Просто только сейчас для этого языка появляются нормальные тулзы для разработчиков. Несколько недель назад вышел достаточно рабочий Scala-плугин (http://plugins.intellij.net/preview/popup/?sid=370&pid=1347). Этот плугин пишется самими работниками IntelliJ в рамках развития IDEA, так что это даёт мне некоторые гарантии того, что им достаточно безопасно можно пользоваться. По уровню, пожалуй, этот плугин уже обошёл интеграцию Немерля в Студию.
Вы пишете, используя IDEA? Мне, в силу некоторых обстоятельств, привычно и надо использовать Eclipse. По поводу работы с Java кодом нарекний нет, но за сегодня поигрался со Scala в Eclipse-- впечатление, что еще работать надо много. Хотя и сделано уже много.
Ни не Немерля со Студией, ни Скалы с Идеей не видел
Вы не пробовали плугин для Eclipse? Впечатления, замечания, сравнения может какие-то есть.
C>Пишу простенький HTML layout engine для SWT — т.е. можно будет описывать в HTML как располагать контролы. Что-то типа очень простого HTMLayout. Case-классы для описания DOM-дерева HTML на Scala — просто вкуснятина!
Щас только приглядываюсь
C>Целиком мои приложения на Scala я переводить не буду, но вот отдельные "интеллектуально-ёмкие" компоненты — очень даже можно. Тем более, что Scala прекрасно интероперирует с Java.
Я так понимаю, общее впечатление после столького времени -- положительное?
Значит смысл потратить время на изучение -- есть, это хорошо.
Здравствуйте, Kuzz, Вы писали:
C>>Я использовать начинаю постепенно. K>Тогда вопрос возникает -- а с чего можно начать его осваивать постепенно? Документация -- довольно не богатая. K>Только на своем опыте? Конечно начну, но, естественно, постепенно Но хотелось бы что посерьезнее и побыстрее.
Я прочитал спеку языка и начал сразу писать. Просто я уже немного знаю другие функциональные языки и С++, что существенно помогает.
Вот тут есть неплохой вводной цикл: http://www.codecommit.com/blog/scala/roundup-scala-for-java-refugees
K>Вы пишете, используя IDEA?
Да, причём даже приложения на SWT+JFace
K>Ни не Немерля со Студией, ни Скалы с Идеей не видел K>Вы не пробовали плугин для Eclipse? Впечатления, замечания, сравнения может какие-то есть.
Пробовал где-то месяц назад. Особо ничем не удивил, сырой он ещё. В IDEA уже лучше даже работает.
C>>Целиком мои приложения на Scala я переводить не буду, но вот отдельные "интеллектуально-ёмкие" компоненты — очень даже можно. Тем более, что Scala прекрасно интероперирует с Java. K>Я так понимаю, общее впечатление после столького времени -- положительное?
Да, как язык Scala очень приятен. Вопрос пока остаётся только в инструментах — без них язык почти что бесполезен для крупных проектов (IMHO). Текущий уровень уже позволяет начинать использовать Scala для небольших модулей.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Kuzz, Вы писали:
C>>>Я использовать начинаю постепенно. K>>Тогда вопрос возникает -- а с чего можно начать его осваивать постепенно? Документация -- довольно не богатая. K>>Только на своем опыте? Конечно начну, но, естественно, постепенно Но хотелось бы что посерьезнее и побыстрее. C>Я прочитал спеку языка и начал сразу писать. Просто я уже немного знаю другие функциональные языки и С++, что существенно помогает.
C>Вот тут есть неплохой вводной цикл: http://www.codecommit.com/blog/scala/roundup-scala-for-java-refugees
Пасибо, поглядим. С функциональными у меня -- поверхностное знакомство с Лиспом еще из универа. С++ знаем. Значит порог вхождения будет не очень высоким, судя по всему Мож пару шишек набью.
K>>Вы пишете, используя IDEA? C>Да, причём даже приложения на SWT+JFace
Нисколько не сомневаюсь, что на IDEA можно и нужно писать Я считаю, что коммерческие проекты потому и платные, что есть за что платить (IDEA, MS VS Studio + Resharper).
Но из бесплатных Eclipse как-то впереди планеты всей. А я пока могу только его и использовать, ибо ломать IDEA... даже для дома не хочу
K>>Ни не Немерля со Студией, ни Скалы с Идеей не видел K>>Вы не пробовали плугин для Eclipse? Впечатления, замечания, сравнения может какие-то есть. C>Пробовал где-то месяц назад. Особо ничем не удивил, сырой он ещё. В IDEA уже лучше даже работает.
Опять-таки, спасибо, пощупаю
C>>>Целиком мои приложения на Scala я переводить не буду, но вот отдельные "интеллектуально-ёмкие" компоненты — очень даже можно. Тем более, что Scala прекрасно интероперирует с Java. K>>Я так понимаю, общее впечатление после столького времени -- положительное? C>Да, как язык Scala очень приятен. Вопрос пока остаётся только в инструментах — без них язык почти что бесполезен для крупных проектов (IMHO). Текущий уровень уже позволяет начинать использовать Scala для небольших модулей.
Кстати, в основном, почему у меня возник этот вопрос -- документация и инструменты, а в целом, поддержка. То есть, как я вижу, стоит сегодня Scala рассматривать как:
— разминку для мозга;
— после разминки инстумент для замещения *некоторых* текущих работ и модулей на Java.
А вообще интересно, есть ли на ней крупные проекты? Так, уже ради моего, чисто личного интереса?
Здравствуйте, Cyberax, Вы писали:
C>Пишу простенький HTML layout engine для SWT — т.е. можно будет описывать в HTML как располагать контролы. Что-то типа очень простого HTMLayout. Case-классы для описания DOM-дерева HTML на Scala — просто вкуснятина!
Я с Груви по сути не знаком, но что мне сразу приходит в голову, что Groovy динамически типизирован, Scala -- статически.
И, Scala в байт-код Java компилится, что дает ей возможность использовать все преимущества JVM.
Больше пока сказать не могу -- ковыряюсь. Потихоньку заинтересовываюсь в потенциале связки Java+Scala. Мысли, мысли...
Вооот, щас чего-то в ступор впал, читая этот цикл. Объясните, пожалуйста, какая разница между:
args.foreach (arg => greeting += (arg + " "))
и
args.foreach {arg => greeting += (arg + " ")}
И почему это работает в обоих случаях?
Если в первом я понимаю -- мы функции высшего порядка foreach передаем анонимную функцию как параметр. А что происходит во втором случае?
Более того меня смутило, что будет работать даже
Здравствуйте, Kuzz, Вы писали:
K>Я с Груви по сути не знаком, но что мне сразу приходит в голову, что Groovy динамически типизирован, Scala -- статически. K>И, Scala в байт-код Java компилится, что дает ей возможность использовать все преимущества JVM.
собственно, groovy в байткод не хуже скалы компилится
да и можно статически всё типизировать при необходимости.
имхо главный минус груви на текущий момент — это проблемы с производительностью, а остальное там как минимум не хуже ruby или, скажем, javaFX
я к тому что groovy вроде как уже стабильный и популярный язык, а тут на RSDN им особо никто не интересуется... или, быть может, мне это просто показалось?
Здравствуйте, rsn81, Вы писали:
K>>>Вы пишете, используя IDEA? C>>Да, причём даже приложения на SWT+JFace R>И RCP?
Ага. Лучший способ чего-то изучить — это не использовать поддержку IDE
T>я к тому что groovy вроде как уже стабильный и популярный язык, а тут на RSDN им особо никто не интересуется... или, быть может, мне это просто показалось?
Интересуются. Но немного народу.
Re: Ваше отношение к языку Scala
От:
Аноним
Дата:
14.07.08 10:54
Оценка:
VD>1. Знаете ли вы что такое Scala?
Пару месяцев VD>2. Если знаете, то как к ней относетесь?
Тащусь
Но судя по джире, для промышленного применения слегка сыровата (можно налететь на вилы),
VD>3. Не думаете ли вы применить Scala-у в своих разработках?
Планирую в своем частном проекте VD>4. Если думали, но есть останавливающие факторы, то просьба их перечислить. Причем любые, даже сугубо субъективные.
Отсутствие нормальной IDE(хотя jetbrains обещает поддержку в восьмой версии)
Отсутствие проектов, на которых можно было бы поучится проектированию в рамках Scala
K>И почему это работает в обоих случаях? K>Если в первом я понимаю -- мы функции высшего порядка foreach передаем анонимную функцию как параметр. А что происходит во втором случае? K>Более того меня смутило, что будет работать даже K>
Пока все никак не могу понять, каким образом гибкость Скалы позволила такое написать, это пожалуй, пока единственный вопрос, который у меня возник по синтаксису.
Кстати, интересно, а как вы организуете смешанные Java+Scala проекты? (Или IDEA плугин уже это поддерживает?)
Если просто использовать написанное на Скала в Ява-проекте -- все просто -- 2 проекта, один на другой ссылается.
А в сценарии, когда надо расширять Скалой существующие места Ява-проекта, а потом их использовать каким-то образом в других частях того же Ява проекта, только нужна хитрая компиляция чем-то внешним, ant-ом например. Или может чего получше подскажете?
Здравствуйте, Kuzz, Вы писали:
K>Пока все никак не могу понять, каким образом гибкость Скалы позволила такое написать, это пожалуй, пока единственный вопрос, который у меня возник по синтаксису. K>Кстати, интересно, а как вы организуете смешанные Java+Scala проекты? (Или IDEA плугин уже это поддерживает?)
Очень просто — классы Java и Scala видят друг друга и могут без проблем использоваться совместно. Естественно, из Java недоступна часть функциональности Scala типа pattern-matching'а.
K>Если просто использовать написанное на Скала в Ява-проекте -- все просто -- 2 проекта, один на другой ссылается.
Да. Но оно пока глючит у них.
K>А в сценарии, когда надо расширять Скалой существующие места Ява-проекта, а потом их использовать каким-то образом в других частях того же Ява проекта, только нужна хитрая компиляция чем-то внешним, ant-ом например. Или может чего получше подскажете?
Я Maven использую, там всё просто.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Kuzz, Вы писали:
K>>Пока все никак не могу понять, каким образом гибкость Скалы позволила такое написать, это пожалуй, пока единственный вопрос, который у меня возник по синтаксису. K>>Кстати, интересно, а как вы организуете смешанные Java+Scala проекты? (Или IDEA плугин уже это поддерживает?) C>Очень просто — классы Java и Scala видят друг друга и могут без проблем использоваться совместно. Естественно, из Java недоступна часть функциональности Scala типа pattern-matching'а.
K>>Если просто использовать написанное на Скала в Ява-проекте -- все просто -- 2 проекта, один на другой ссылается. C>Да. Но оно пока глючит у них.
K>>А в сценарии, когда надо расширять Скалой существующие места Ява-проекта, а потом их использовать каким-то образом в других частях того же Ява проекта, только нужна хитрая компиляция чем-то внешним, ant-ом например. Или может чего получше подскажете? C>Я Maven использую, там всё просто.
Спасибо! Вот ведь... потянул за одну ниточку, вытащил клубок. Придется взглянуть на Maven
А по поводу моего вопроса по коду не можете подсказать, в чем там фишка?
K>>И почему это работает в обоих случаях? K>>Если в первом я понимаю -- мы функции высшего порядка foreach передаем анонимную функцию как параметр. А что происходит во втором случае? C>То же самое. Скобки при вызове методов — опциональны (точнее, это получается инфиксная запись). А фигурные кавычки {} просто обозначают блок кода, как и в Java.
Здравствуйте, thevery, Вы писали:
T>Здравствуйте, Kuzz, Вы писали:
T>собственно, groovy в байткод не хуже скалы компилится T>да и можно статически всё типизировать при необходимости.
Поставить тип у переменной — еще не значит сделать язык статически-типизированным
T>имхо главный минус груви на текущий момент — это проблемы с производительностью, а остальное там как минимум не хуже ruby или, скажем, javaFX
Эта проблема является одним из следствий динамической типизации. Представь, что все методы вызываются грубо говоря через рефлекшн.
Здравствуйте, l00ser, Вы писали:
L>Эта проблема является одним из следствий динамической типизации. Представь, что все методы вызываются грубо говоря через рефлекшн.
так что ждем тестов invokedynamic
а вам знакомо название "програмирование в намереньях" intention programming?
это очень похоже на то что вы описываете.
но на сколько мне известно оно загнулась у микрософта на стадии работающего прототипа
идея красивая, но "меня терзают смутные сомненья"