Здравствуйте, mkizub, Вы писали:
M>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
А вот это — сферический конь в вакууме.
Смысл использования имеющихся инструментов, как раз в использовании проверенных выборов, чтоб не заморачиваться на подробности малозначительные вещи, не интересные для решения нужной задачи. Скажем, использовать GC вместо ручного управления памятью и т.п.
Это как с теми же макросами — давать писать их всем подряд, конечно, забавно, только вот на практике не есть очень умный вариант. Свободы программисту должно быть достаточно чтоб решать поставленную перед ним задачу, но не более — излишняя свобода лишь порождает лишние проблемы, отвлекает и т.п.
Другое дело, что непонятно как найти нужную долю этой свободы и как её чётко ограничить
Ну и должны быть разные "уровни" программистов с разными разрешениями.
Всё, естественно, имхо
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, mkizub, Вы писали:
M>>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
К>А вот это — сферический конь в вакууме. К>Смысл использования имеющихся инструментов, как раз в использовании проверенных выборов, чтоб не заморачиваться на подробности малозначительные вещи, не интересные для решения нужной задачи. Скажем, использовать GC вместо ручного управления памятью и т.п.
Отсутствие принятия выбора дизайна означает, что если программисту надо — он будет использовать GC, если не надо — не будет. Если надо — часть программы с использованием GC, а часть на ручном управлении.
Ты опять думаешь в терминах, когда за тебя выбирают — выберут тебе низкоуровневый язык или высокоуровневый.
К>Это как с теми же макросами — давать писать их всем подряд, конечно, забавно, только вот на практике не есть очень умный вариант. Свободы программисту должно быть достаточно чтоб решать поставленную перед ним задачу, но не более — излишняя свобода лишь порождает лишние проблемы, отвлекает и т.п.
Ты ведь считаешь себя умнее других, да?
Кто ты такой, чтоб решать — давать другим в руки макросы, или не давать? Ты папа им?
Выбирать использовать или не использовать макросы должен дизайнер проекта. Он знает для чего этот проект, на каких машинах, какие требования к надёжности и прочее.
Это его работа такая — выбрать инструменты и дизайн под конкретную задачу.
А сейчас его работу пытаются делать создатели языка. Вот они и создают сферический язык в вакууме.
К>Другое дело, что непонятно как найти нужную долю этой свободы и как её чётко ограничить
Действительно, такая маленькая проблема
К>Ну и должны быть разные "уровни" программистов с разными разрешениями.
Здравствуйте, mkizub, Вы писали:
M>Отсутствие принятия выбора дизайна означает, что если программисту надо — он будет использовать GC, если не надо — не будет. Если надо — часть
программы с использованием GC, а часть на ручном управлении.
О том и говорится, только суть в том, что это разные, отделённые логически части и для каждой используется свой набор средств и смешивать их на мой взгляд очень чревато.
M>Ты опять думаешь в терминах, когда за тебя выбирают — выберут тебе низкоуровневый язык или высокоуровневый.
Т.е. ты как мегапсихолог, знаешь в каких терминах я думаю и о чём?
Несколько самонадеянно, не считаешь?
M>Ты ведь считаешь себя умнее других, да?
Да куда мне
До тебя ещё расти и расти, как посмотрю.
M>Кто ты такой, чтоб решать — давать другим в руки макросы, или не давать? Ты папа им?
Кто тебе сказал, что это должен решать я? Будет решать тот человек, в чьи обязанности это входит.
M>Это его работа такая — выбрать инструменты и дизайн под конкретную задачу. M>А сейчас его работу пытаются делать создатели языка. Вот они и создают сферический язык в вакууме.
Посмею огорчить тебя — языки эти работают и выполняют задачи, для которой они созданы, в отличие от.
К>>Другое дело, что непонятно как найти нужную долю этой свободы и как её чётко ограничить M>Действительно, такая маленькая проблема
Я вот не пойму — тебе сказать чтоль по сути нечего и ты переходишь на сарказм?
Если есть идеи — высказывай, покая лично я ничего в твоих высказываниях не вижу (хотя, возможно, это особенности моего взгляда, но способность объяснять со стороны также очень важна для понимания)
Здравствуйте, 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?
Здравствуйте, aka50, Вы писали:
A>Нормальный язык должен включать набор инструментов для реализации определенных задач и выбор этого языка или платформы, A>как инструмента, определяется задачей. Если язык излишне гибкий выбор уже становиться достаточно сложный, т.к. вместо A>одного большого рубильника менеджеру предлагается выбрать из кучи мелких выключателей (при чем не всегда очевидны взаимосвязи A>этих выключателей).
Знаешь, а прикольная идея как раз эдакий "рубильник" встроить в сам язык, чтоб можно было бы регулировать соотношение гибкость/жёсткость в ту сторону, которую нужно, причём, чтоб это было универсальным подходом, как сама расширяемость того же лиспа.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, mkizub, Вы писали:
M>>>Решение в том, чтоб вообще отказаться от принятия выборов за программистов, пишущих на этом языке.
К>>А вот это — сферический конь в вакууме. К>>Смысл использования имеющихся инструментов, как раз в использовании проверенных выборов, чтоб не заморачиваться на подробности малозначительные вещи, не интересные для решения нужной задачи. Скажем, использовать GC вместо ручного управления памятью и т.п.
M>Отсутствие принятия выбора дизайна означает, что если программисту надо — он будет использовать GC, если не надо — не будет. Если надо — часть программы с использованием GC, а часть на ручном управлении. M>Ты опять думаешь в терминах, когда за тебя выбирают — выберут тебе низкоуровневый язык или высокоуровневый.
За языком лежит семантическая модель рантайма. От этого никуда не денешься. Языки существуют, чтобы порождать исполняемые программы. Если мы имеем низкоуровневую native модель (стек+heap+статическая память+допустимая явная адресация+OS processes+OS threads), то сколько бы мы ни дизайнили язык — выйдет C++. Более абстрактные модели должны что-то явно запрещать, иначе допустимые хаки на более низкий уровень разрушат целостность абстракций.
Собственно в современных практических высокоуровневых язках эта проблема решается стандартно: запрещаем всё низкоуровневое + есть библиотеки интеропа с C (в самом C аналогично решён вопрос ассемблера ). Лучшего механизма, ИМХО, не придумать.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, 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?
Вот и должен один программист работать в понятиях, где неважна конкретная реализация, конкретный рубильник.
А другой программист должен это понятие реализовать, выразить в низкоуровневых операциях. И первый не должен беспокоиться как сделать работу за второго.
Что до твоего вопроса — так везде синтаксис и понимаемость приблизительно на одном уровне.
И она не имеет никакого отношения к реальным проектам в миллионы строк кода.
Там совсем другие проблемы. Совсем.
Здравствуйте, mkizub, Вы писали:
M>Так высказаны уже. Я же ссылки давал. Вот ссылка на статью, которую сейчас дорабатываю для RSDN. M>http://www.symade.org/SOP_and_SymADE.doc
Где что высказано?
Статья какая-то "никакая", без конкретных законченных предметов, позволяющих понять, в чём суть и как это всё работать будет.
Опять повторюсь — если есть что-то, что хочешь сказать, то говори толком, а так говорить аля "вы все фигнёй занимаетесь" большого ума не надо.
Здравствуйте, 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%) писать на низкоуровневом.
Ну хорошо если отбросить философствование на тему "Писать самому семантические деревья это круто потому что......", то по сути предлагается писать программы на очередном языке еше более высокого уровня (который в принципе можно обпилить под себя), который потом неким таинственным (или не очень) образом может превращаться во что угодно: в исходники на другом языке, в байт код и т.д.
В результате получаем холявный DSL и пр. радость...
Сразу высплывает несколько моментов:
1. Допустим Вы сделали свой собственный DSL идеально описывающий вашу предметную область,
(кстати а можно ли считать квази-DSL'ем просто библиотеку где классы названы соответствующим образом (Поставщик, Продажа и т.д.) + перегружены все операторы?)
а потом вам вдруг потребовалось прикрутить что-то стороннее, какие варинаты?:
— использовать как есть — но тогда нарущится концепция "нашего маленького самопального языка".
— сваять обертку — это будет покруче чем строительство комунизма, я там одним глазом посмотрел простенький и маленький пример (типа сделай DSL своими кривыми ручками) — "всего" >500 строк кода (поправьте если ошибаюсь) — если на каждый чих ваять по пол тыщи строк то где же экономия от DSL, если же появяться некие общепринятые стандартные DSL и подогнанные под них фреймворки, то мы вернемся к тому же что имеем сейчас только на более высоком уровне (ведь найдутся люди которых и они не устроят)
2. В чем прниципиальная новизна? Ведь созданный DSL все равно так или иначе будет ложиться
на одну из существущих парадигм программирования (ООП, ФП и д.р.).
3. Сугубо практические моменты:
— реальная применимость (где? зачем? в чем преимущество?)
— наличе библиотек (или возможность цеплять сторонние)
— наличие среды разработки
— наличие литературы
В этом плане у скалы есть свои недостатки, но есть и достоинства которые позволяют применить ее уже сейчас.
P.S. Хотя возможно в будущем из этого что-нибудь да получится, только вот расчитывать на очередную серебрянную пулю я бы не стал...
Здравствуйте, Курилка, Вы писали:
M>>Там совсем другие проблемы. Совсем. К>Предметно-то сказать можешь?
Ну возьми те-же скриптовые языки. Как на них удобно писать маленькие программы. Ни типов объявлять,
ни о скорости заботиться. А попробуй написать на скриптовом языке большую программу — очень
скоро начнётся такая борьба с вылазящими изо всех щелей ошибками связанными с типами, что
проект застынет на месте.
Или эту эпопею с Java. Все-ж бросились, как она вышла, писать на ней web browser.
И Sun, и Netscape. И написали. Да только оно так тормозило и столько ресурсов ело,
что забили на эти проекты. А бросились их писать из-за того, что этот С/С++ достал
своими ошибками с указателями, переполнением буферов и ручным управлением памятью
(которая и текла и баги выдавала при удалении живых объектов — одновременно).
Большой проект — это всегда смесь противоречивых требований. И надёжно должно быть,
и работать быстро, и писать программу надо быстро и дёшево. Эти требования можно
разрешить только разделяя программу на разные уровни — внешний (где скрипты рулят),
внутренний (где требования промежуточные), ядро (где нужно быстро и надёжно, но
которое не такого большого размера, и можно его писать долго и дорого).
Писать эти разные части на разных языках — замечательно выходит.
Проблемы начинаются, когда эти разные языки пытаются соединить вместе.
А у них рантайм разный. И всё, приплыли. Передача данных и управления между
разными слоями становится настолько сложной и тормознутой, что это перечёркивает
все преимущества разделения проекта на разные части. И мы опять у разбитого корыта.
Здравствуйте, mkizub, Вы писали:
M>Ну возьми те-же скриптовые языки. Как на них удобно писать маленькие программы. Ни типов объявлять, M>ни о скорости заботиться. А попробуй написать на скриптовом языке большую программу — очень M>скоро начнётся такая борьба с вылазящими изо всех щелей ошибками связанными с типами, что M>проект застынет на месте.
Если ты по поводу динамической типизации, то есть ощущение, что ты неправ
Контрпример — код ПО для свича AXD301, пару лет назад вроде там было что-то типа 2 миллионов строк на Erlang — язык динамичней некуда.
M>[cut] И всё, приплыли. Передача данных и управления между M>разными слоями становится настолько сложной и тормознутой, что это перечёркивает M>все преимущества разделения проекта на разные части. И мы опять у разбитого корыта.
Всё это напоминает статью Спольски про закон дырявых абстракций, только вот что именно ты предлагаешь?
Уровни абстракций, DSL и т.п. — это всё прикольно, но что нового в этом твоём СОП и чем оно спасёт отца российской демократии?
Здравствуйте, 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, Вы писали:
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>Большой проект — это всегда смесь противоречивых требований. И надёжно должно быть, M>и работать быстро, и писать программу надо быстро и дёшево. Эти требования можно M>разрешить только разделяя программу на разные уровни — внешний (где скрипты рулят), M>внутренний (где требования промежуточные), ядро (где нужно быстро и надёжно, но M>которое не такого большого размера, и можно его писать долго и дорого). M>Писать эти разные части на разных языках — замечательно выходит. M>Проблемы начинаются, когда эти разные языки пытаются соединить вместе. M>А у них рантайм разный. И всё, приплыли. Передача данных и управления между M>разными слоями становится настолько сложной и тормознутой, что это перечёркивает M>все преимущества разделения проекта на разные части. И мы опять у разбитого корыта.
А если воспользоваться связкой Java+Groovy, Java+Scala — ведь они по сути будут
исполняться в рамках одной JVM, поэтому никаких проблем с взаимодействием быть не должно
(для груви можно вообще явно сформировать переменные из явы, а кроме того никто не отменял синглтон).
Очень смешно. 
жаль что ты не понял что именно я хотел показать...
