Re[16]: Оберон круче всех!
От: vdimas Россия  
Дата: 25.07.12 19:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

V>>Ну попроси кого-нить из коллег объяснить, делов-то... Того же Вольфхаунда. Он хоть и вредный, но соображающий.


AVK>Он то как раз понимает, что в мейнстриме адекватной замены АлгТД+ПМ нет.


Речь не о том, что он понимает прямо сейчас, а том, что он почитает и поймет про CPS-трансформацию, затем покажет, каким именно образом исчезает АлгТД при CPS-трансформации.
Re[13]: Оберон круче всех!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.07.12 19:42
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Я ошибся, во втором статическом методе надо вместо "Stream stream" поставить "String str".


Тогда непонятно самое интересное, как выбирается нужный метод при вызове.

ARK> Плюс основная операция обработки одна. Поэтому я предложил превратить сразу потоки и строки в объект и дальше везде работать с ним.


Что значит превратить потоки и строки в объект? Каким образом?

ARK>Если значение "в трех ипостасях" будет использоваться не в одном месте, то в этих нескольких местах перед использованием будет преобразование из Stream или String в объект?


Нет. Будет ответный алгоритм, зависящий от типа значения. Т.е. нужна все та же динамическая диспетчеризация. И вот как ее обеспечивать в ситуации, когда список значений дискриминанта фиксирован на стадии компиляции, как раз и есть самое интересное. АлгТД интересны не сами по себе, а в комплекте с ПМ.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[17]: Оберон круче всех!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.07.12 19:51
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Речь не о том, что он понимает прямо сейчас, а том, что он почитает и поймет про CPS-трансформацию, затем покажет, каким именно образом исчезает АлгТД при CPS-трансформации.


Если ты про замену виртуальных методов на ФВП, то это не CPS-трансформация, это просто замена ООПного полиморфизма на функциональный. Мы же вроде как про ООП тут беседуем.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[11]: Оберон круче всех!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.07.12 19:51
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Я имел в виду именно виртуальный метод "операция формирования запроса".


Не годится. Вызывающе чрезмерная связность. На каждого консьюмера в AST методов не надобавляешься.

ARK> Если алгоритмов несколько — выносим их в общий интерфейс.


Ага. Т.е. в итоге получаем классический визитор. Браво! В чем проблема такого подхода пояснять?

ARK>+1. Да, все верно. Для реализации этого всего необходима инкапсуляция. Такое вот у меня возникло (возможно очевидное и примитивное) предположение на вопрос "причем тут инкапсуляция".


Не, vdimas утверждает, что АлгТД нарушает компиляцию. В этом, собственно, и был единственный вопрос всей ветки с моим участием.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[14]: Оберон круче всех!
От: AlexRK  
Дата: 25.07.12 20:03
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Что значит превратить потоки и строки в объект? Каким образом?

AVK>Нет. Будет ответный алгоритм, зависящий от типа значения. Т.е. нужна все та же динамическая диспетчеризация. И вот как ее обеспечивать в ситуации, когда список значений дискриминанта фиксирован на стадии компиляции, как раз и есть самое интересное. АлгТД интересны не сами по себе, а в комплекте с ПМ.

Понятно. Я неверно истолковал ваше высказывание "Строка парсится, стрим выкачивается в память, объект используется как есть" как означающее, что строка и стрим соответствующими алгоритмами приводятся к объекту, который используется, как есть. Получается, что все эти значения потребляются совершенно разными алгоритмами. Поэтому мое изначальное предположение о ненужности АТД неверно.
Re[41]: Оберон круче всех!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.07.12 20:08
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Просто в Хаскеле нет продложений. Ниасилили.


В Хаскеле нет continuation monad? Жжешь.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[15]: Оберон круче всех!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.07.12 20:10
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>Получается, что все эти значения потребляются совершенно разными алгоритмами.


Не совсем так. Алгоритм один, но отличающийся немного для значений разных типов. Т.е. в каком то месте нужно сделать ветвление по дискриминанту, а потом продолжить дальше обобщенную обработку.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[14]: Оберон круче всех!
От: grosborn  
Дата: 26.07.12 08:08
Оценка: +1 -1
> Вот вся суть твоих сообщений. Ты нахватался обрывочных знаний, но как дело доходит до конкретики и применения, то начинаются сплошные разводы на воде. Я тебя с Шериданом не просто так сравнил.

Всегда возникают трудности, когда нужно перейти от обсуждения коня в вакууме к конкретному коню. Конкретных много разных, какого выбрать? Задача была поставлена несколько размыто. Так же можно было бы уточнить стоимость приведения типов, стоимость выполнения операций, сценарии. Может быть действительно тут вариант с предварительным или ленивым приведением типов подошел бы. Ан нет, все нечетко, но код вынь да полож, а мы будем посмеяться зная то что не знает другая сторона.
Posted via RSDN NNTP Server 2.1 beta
Забанен на рсдн за применение слова "Маргинал"
Re[39]: Оберон круче всех!
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.07.12 08:10
Оценка: +1
Здравствуйте, vdimas, Вы писали:
V>Т.е. мы всё это время таки сравнивали язык и среду исполнения с IDE?
V>Жесть. )))

Ну, я не знаю, что и с чем сравнивали вы. Это же ваш был аргумент :
Да врде автодополнение есть, с переводом ключевых слов в ерхний регистр, но с какими-то ополнениями не из коробки. "Подсветка" там через синтаксис самого языка (ключевые слова большими буквами).
Ну и по собственным ощущениям, хоть и не слишком много пришлось на Паскале когда-то пошпилить, но этому языку, в отличие от, например, C/C# подсветка синтаксиса и даром не сдалась. Как раз выделения ключевых слов было достаточно, что под TP, что под Дельфи. Ну и еще, там же не текстовый документ, а гипертекстовый. Ты можешь раскрашивать исходник вообще как хочешь, превращая исходник в некий полноценный справочник-документ по коду.

А потом в результате разговора внезапно оказалось, что раскраски синтаксиса там нету потому, что

Операция SetTextColor над GDI довольно дорогая, внутри инициализируются специальные Pen и Brush для глифов шрифта. Причем (если помнишь) исходный цвет округляется по тем временам до ближайшего цвета из палитры. А палитры тогда были практически всегда индексные, то бишь "округление" цвета на самом деле шло через линейный перебор всех вхождений в палитру и подбор наиболее близкого цвета. А операция нахождения абсоютной цветовой разницы для каждого вхождения из палитры — тоже дорогая. И т.д. и т.п. В общем, я много возился с GDI/MFC даже уже на пнях, так вот, до появления 200MHz компов вывод на экран вылизывался как ничто другое.

Ну разве это не здорово? То есть на раскраску вручную ресурсы у них были, а вот на семантическую раскраску их уже остро не хватало. Постарайтесь поменьше противоречить собственным утверждениям, хотя бы в пределах одной ветки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Оберон круче всех!
От: vdimas Россия  
Дата: 26.07.12 09:46
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

AVK>Если ты про замену виртуальных методов на ФВП, то это не CPS-трансформация,


1. Это CPS-трансформация прямо по определению.
2. Идентично заменяются оба варианта, что на визиторе, что на АлгТД, то бишь конкретно виртуальные методы не при чем.
3. Фокус не на самой CPS-трансформации, а в пост-эффекте. Конкретно здесь не надо будет вводить дополнительный абстрактный тип для представления узла AST, т.к. теперь в узле хранится замыкание, контекст которого унутре оперирует конкретным типом.

AVK>это просто замена ООПного полиморфизма на функциональный.


Так же как замена функционального полиморфизма на основе АлгТД на функциональный же полиморфизм на основе функционального типа (который тоже всегда абстрактный). Т.е. вся разница в том, что пользовательский тип надо объявлять и обслуживать, а абстрактные функциональные типы даны изкаробки. (Камешек в сторону связанности)

Помнишь за что пеняют делегаты в дотнете? Что они нифига не являются абстрактными функциональными типамм, в отличие от функциональных типов ФП-языков. Поэтому-то были введены все эти Func<>, Action<> и т.д., чтобы как то организовать некое обобщение сигнатур функциональных типов, которое присутствовало бы в случае их абстрактности изкаробки


AVK>Мы же вроде как про ООП тут беседуем.




Дык, boost::lambda, которые я использую для точно такого же в С++, называются как функциональщина, выглядят как функциональщина, а откроешь — унутрях сплошное ООП. Аналогично анонимные делегаты в дотнете.

ИМХО, это банально удобно, когда в языке есть возможность заменять интерфейсы с одним методом на парадигму "функтор". В С++ особенно хорошо видно, что это всё-таки обычный объект, т.к., в отличие от донета, он требует такого же внимания как и другие объекты, из-за особенностей размещения (стек/куча) и контроля времени его жизни.
Re[8]: Оберон круче всех!
От: vdimas Россия  
Дата: 26.07.12 10:23
Оценка: -1 :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Это ты vdimas спроси. Он тут нам рассказывает, что АлгТД с ООП несовместимы.


Я еще ничего не рассказывал. Тебе вообще рассказывать смысла нет, ты сам пишешь посты в 3 строчки и у других далее 3-х строк не читаешь... Превратили, блин, форум в бесконечный IRC чат.

И не надо меня перевирать, я сказал (дословно) что оно не взлетело и не взлетит в ближайшее время. И подразумевалось (см исходный пост) два утверждения, а не одно:
1. В мейнстриме в ближайшие много лет будет таки ООП.
2. Зависимые типы, АлгТД и т.д. (смотри приведенный оппонентом список) в мейстриме в ближайшие годы тоже не взлетят.

Конкретно почему не взлетит АлгТД и паттерн-матчинг в ООП-мейнстриме? Потому что паттерн матчинг умеет намного больше, чем ты хотел добиться от меня в примере. Стоит открыть этот "ящик Пандоры" и оттуда полезет... полезут всякие св-ва и флаги, искуственные сигнатуры конструкторов и т.д. и т.п. — все это полезет в публичные интерфейсы только ради попользовать их в конструкции паттерн-матчинга. И дизайн будет тяготеть всё больше и больше к хаскелевскому типу, когда все кишки объектов наружу. Вот почему моё ИМХО вспомнило об инкапсуляции.

Еще момент. Посмотри на АлгТД в Немерле. Это инвалид, а не АлгТД. Потому что у него ограничение на реализацию в виде ref-типов. А такая техника реализации — это тормоза на ровном месте для самых популярных сценариев, хотя бы возьми Nullable. Стал бы производитель CLR всерьез думать о том, чтобы Nullable делать ref-типом? Да не в жисть... Модные разговоры о модном ФП на форумах это одно, а св-ва платформы — малость другое, нужен трезвый подход.

Далее. Представим возможность реализации АлгТД в виде value-типов. Такую реализацию можно посмотреть прямо сейчас, скормив IIOP.Net описание какого-нить размеченного объединения в CORBA IDL. Будет хорошо видно что там, где фП-языки используют типобезопасность и нивелируют лишние проверки в паттерн-матчинге, там безопасный (с т.з. ООП) интерфейс размеченного объединения должен будет при каждом доступе к вариантам проверять дискриминатор, даже если мы уже находимся в правильной ветке паттерн-матчинга. Т.е. опять получилась профанация и тормоза. Ну и до кучи сюда стоит помнить о совместимости разных языков на CLR.

Ес-но можно будет сделать полноценные АлгТД прямо в дотнете в каком-нить функциональном языке, но эффективно это будет только на неинкапсулированном представлении, открытом как internal внутри модуля. То бишь вопрос интероперабельности с остальными языками под вопросом. И даже вопрос интероперабельности языка с самим собой при попытке сделать модульнуй, как принято в CLR, его дизайн.


AVK>В некоторых задачах — очень частая. Мои пример — из DSL для импорта данных.


Для твоей задачи никакой паттерн-матчинг не нужен, достаточно некоего синтаксического сахарка, о котором уже давно говорят, что-то типа такого:
switch(node.GetType()) {
  case typeof(TextNode): ...
  case typeof(ObjectNode): ...
}
Re[42]: Оберон круче всех!
От: vdimas Россия  
Дата: 26.07.12 10:36
Оценка:
Здравствуйте, AndrewVK, Вы писали:

V>>Просто в Хаскеле нет продложений. Ниасилили.

AVK>В Хаскеле нет continuation monad? Жжешь.

В исходной семантике — call/cc, вызываемой из произвольного места в коде? Нет, конечно.

Это малость не то, что настоящие продолжения. Вместо текущего контекста вычисления захватывается только явно поданные вычисления/монады.


В исходной семантике можно сделать полный форк текущего контекста вычислений внутри любых сколь угодно вложенных вызовов... и в каждом контексте будет свой, грубо говоря, return, корректно выполняющийся по своей копии стека вычислений. Поэтому речь и идет о том, что при нейтивном исполнение (не на интерпретаторе) полноценные продолжения требуют форкать так же состояние нейтивного стека.
Re[40]: Оберон круче всех!
От: vdimas Россия  
Дата: 26.07.12 11:05
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну разве это не здорово?


Нет, терять контекст всегда нездорово.

S>То есть на раскраску вручную ресурсы у них были, а вот на семантическую раскраску их уже остро не хватало.


Дык, ты опять путаешь Оберон и некий BlackBox. Причем, нимало не смущаясь, покритиковав в одном предложении BlackBox, даже не закончив еще этого предложения, тут же делаешь выводы насчет Оберона как такового. Жаль, что я не могу здесь написать, что я думаю о такой мммм... "манере" ведения беседы.

От себя могу лишь предполагать, почему так: BlackBox сделана в традициях Оберона. А гипертекстовость взялась от того, чтобы одновременно писать документацию и код.


S>Постарайтесь поменьше противоречить собственным утверждениям, хотя бы в пределах одной ветки.


Это не противоречие, а результат твоей искуственной мешанины Оберона как такового и BlackBox-а в частности. И даже в пределах одной подветки, прикинь, могут упоминаться сразу несколько вещей.
Re[41]: Оберон круче всех!
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.07.12 12:48
Оценка:
Здравствуйте, vdimas, Вы писали:

S>>То есть на раскраску вручную ресурсы у них были, а вот на семантическую раскраску их уже остро не хватало.

V>Дык, ты опять путаешь Оберон и некий BlackBox.
Ну, распутайте. В чём тут секрет?

V>От себя могу лишь предполагать, почему так: BlackBox сделана в традициях Оберона. А гипертекстовость взялась от того, чтобы одновременно писать документацию и код.

Ок, мы вернулись к тому, с чего начали.
Гипертекстовость как способ раскраски кода — сосёт.
Семантическая раскраска — рулит.
Отсутствие необходимости семантической раскраски паскалеподобных языков, я надеюсь, мы развеяли к этому моменту? Или вы опять начнёте юлить и уводить разговор в сторону?

Ок, теперь продолжим про документацию. Вот у нас есть перед глазами три "традиции" документирования:
1. Оберон с его гипертекстом (кстати, его придумали не в BlackBox, а пораньше)
2. Джава с его javadoc
3. С# c его XML Documentation Comments.
В третьем случае документация официально становится частью языка. Это пример того, как надо дизайнить язык. И пример того, как язык влияет на возможности IDE.

S>>Постарайтесь поменьше противоречить собственным утверждениям, хотя бы в пределах одной ветки.

V>Это не противоречие, а результат твоей искуственной мешанины Оберона как такового и BlackBox-а в частности.
Ну, давайте уберём мешанину.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Оберон круче всех!
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.07.12 15:27
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А что мешает в императивном языке использовать тот же const?

V>В С++ модификатор const прекрасно распространяется, обслуживается и гарантируется...
модификатор const в языке C++ — фикция.
Он не даёт нам никаких гарантий, т.к. всегда можно привести int к const int. То, что я не могу изменить этот инт, не означает, что никто не может.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[42]: Оберон круче всех!
От: vdimas Россия  
Дата: 26.07.12 15:39
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

V>>От себя могу лишь предполагать, почему так: BlackBox сделана в традициях Оберона. А гипертекстовость взялась от того, чтобы одновременно писать документацию и код.

S>Ок, мы вернулись к тому, с чего начали.
S>Гипертекстовость как способ раскраски кода — сосёт.
S>Семантическая раскраска — рулит.

S>Отсутствие необходимости семантической раскраски паскалеподобных языков, я надеюсь, мы развеяли к этому моменту?


Вряд ли можно развеять моё утверждение о том, что для таких языков полноцветная раскраска НЕ принципиальна. С ИМХО не поспоришь.

S>Или вы опять начнёте юлить и уводить разговор в сторону?


Мне-то ачем юлить? Я лишь отвергаю попытки приписать мне лишнее. Твоё мнение, насчет необходимости раскраски я услышал. Но не считаю, что из этого следует, что сама среда Оберон г-но из-за того, что в некоей BlackBox недостаточно покрасили текст. Я тебе уже раз 10 напоминал о некоректности такой "лоики". ИМХО, это ты пытаешься перевести разговор каждый раз, когда заслуживаешь подобные замечания.


S>Ок, теперь продолжим про документацию. Вот у нас есть перед глазами три "традиции" документирования:

S>1. Оберон с его гипертекстом (кстати, его придумали не в BlackBox, а пораньше)
S>2. Джава с его javadoc

Характерно, что для С++ никакого такого javadoc нету, но Doxygen является стандартом де-факто.

S>3. С# c его XML Documentation Comments.

S>В третьем случае документация официально становится частью языка.

Да ладно, в официальной части языка можно мало чего. Зато с помощью всяких расширений третьесторонних генерилок документации уже можно что-то делать.

S>Это пример того, как надо дизайнить язык. И пример того, как язык влияет на возможности IDE.


В любом случае, автогенеренная дока идет через комменты во всех языках, так что натягивать автодоку в комментах на язык — это спорт по прыжкам в сторону. Пример Doxygen/С++ показывает это во всей красе.
Re[43]: Оберон круче всех!
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.07.12 06:43
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Вряд ли можно развеять моё утверждение о том, что для таких языков полноцветная раскраска НЕ принципиальна. С ИМХО не поспоришь.

С неаргументированным ИМХО — запросто. Ваши аргументы про ненужность сводились к намёкам на семантическую однозначность Оберона по сравнению с "другими языками". Оказалось, что
а) в Обероне полно конструкций, в которых семантику из чистого синтаксиса извлечь затруднительно
б) в остальных Паскалеподобных языках раскраска синтаксиса применяется примерно с 1990 года.

S>>Ок, теперь продолжим про документацию. Вот у нас есть перед глазами три "традиции" документирования:

S>>1. Оберон с его гипертекстом (кстати, его придумали не в BlackBox, а пораньше)
S>>2. Джава с его javadoc

V>Характерно, что для С++ никакого такого javadoc нету, но Doxygen является стандартом де-факто.

С точки зрения языка, это решение эквивалентно Джавовскому.

V>Да ладно, в официальной части языка можно мало чего. Зато с помощью всяких расширений третьесторонних генерилок документации уже можно что-то делать.

Я бы не сказал, что этого мало. Генерилки заботятся об оформлении. Это как раз правильное разделение обязанностей — программист описывает семантику, а стили и представление предоставляет внешний тул. Нет никакой ручной раскраски.

V>В любом случае, автогенеренная дока идет через комменты во всех языках, так что натягивать автодоку в комментах на язык — это спорт по прыжкам в сторону.

Я бы не сказал про все языки. К некоторым языкам (в т.ч. фортрану и С++) прикрутили внешние инструменты типа doxygen. В некоторых (Java, C#, VB.Net) есть общепринятые стандарты, заданные разработчиками. Для некоторых — ничего нет.
И только Обероновцы придумали бред с гипертекстом.

V>Пример Doxygen/С++ показывает это во всей красе.

Пример Doxygen показывает, что
1. Для документации в языке гипертекст нафиг не упал
2. Пример Java вдохновил команду QT на разработку своего аналога. Пример Оберона не смог никого вдохновить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[44]: Оберон круче всех!
От: vdimas Россия  
Дата: 27.07.12 09:13
Оценка:
Здравствуйте, Sinclair, Вы писали:

V>>Вряд ли можно развеять моё утверждение о том, что для таких языков полноцветная раскраска НЕ принципиальна. С ИМХО не поспоришь.

S>С неаргументированным ИМХО — запросто.

Гм, ну ок, ниже приведу попунктно, почему так.

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

S>а) в Обероне полно конструкций, в которых семантику из чистого синтаксиса извлечь затруднительно

Возможно... Но справедливости ради, пример с WITH — это спекуляции чистой воды. Случай 2-х вложенных WITH ничем не отличается по-сути от случая когда один WITH в методе объекта. И там и там 2 уровня вложенности контекстов объектов. Но для второго случая ты предлагаешь красить мемберы объекта разными цветами, а что же делать в случае 2-х вложенных WITH? Или еще пример, в этих языках есть возможность определять локальные процедуры, которые могут оперировать контекстом вышестоящей процедуры. Как там различать самые локальные переменные от несамых локальных? )))

По опыту С++, мне комфортно, когда выделены цветом:
— ключевые слова
— макроопределения
— enum
— типы
— ф-ии/методы
— строки.

Т.е. даже всего того, что было предложено еще оппонентами для раскраски, типа локальных/нелокальных переменных, статических/нестатических методов и т.п. мне не надо, потому что: засоряет вид, локальность/мемберность переменных разруливается в обязательном порядке через name conventions, а вызов статического мембера с вызовом экземплярного в С++ перепутать сложно.

А теперь берем паскалеподобные языки:
— макроопределений нет
— enum нет
— в языке сложно спутать идентификаторы типов с идентификаторами процедур.

Теперь вычти второй список из первого. Что в остатке? Раскраска строк? )))
Теперь аргументировано?

S>б) в остальных Паскалеподобных языках раскраска синтаксиса применяется примерно с 1990 года.


Исходный Оберон — разработка 80-х, начала 90-х годов.

V>>Характерно, что для С++ никакого такого javadoc нету, но Doxygen является стандартом де-факто.

S>С точки зрения языка, это решение эквивалентно Джавовскому.

Ну вот оно и откровенное юление. Ты же прекрасно понял о чем я, разве нет? С точки зрения стандарта языка Doxygen не существует. Только это и принципиально. Вместо того, чтобы прибивать гвоздями на заседаниях комитета всякую хрень к языку, этот момент был отдан на откуп третьесторонним разработчикам. Было очень много вариантов генерации доки для С++ во все времена (я за 20 лет их видел десятки), но вот устаканился Doxygen и буквально единицы коммерческих, которые мало кто пользует.

Но ты посмотри, колгда это всё устаканилось — уже в 2000-х годах.


V>>Да ладно, в официальной части языка можно мало чего. Зато с помощью всяких расширений третьесторонних генерилок документации уже можно что-то делать.

S>Я бы не сказал, что этого мало. Генерилки заботятся об оформлении. Это как раз правильное разделение обязанностей — программист описывает семантику, а стили и представление предоставляет внешний тул. Нет никакой ручной раскраски.

Я не о раскрасках, а о тагах в дотнетном XML-doc. Третьестороннии генерилки расширяют исходный набор тагов чуть ли не вдвое. Вот тебе кривизна попыток устаканить этот набор через стандарт во всей красе. Достаточно было дать референсный независимый тул, как поступили в Java.

V>>В любом случае, автогенеренная дока идет через комменты во всех языках, так что натягивать автодоку в комментах на язык — это спорт по прыжкам в сторону.

S>Я бы не сказал про все языки. К некоторым языкам (в т.ч. фортрану и С++) прикрутили внешние инструменты типа doxygen. В некоторых (Java, C#, VB.Net) есть общепринятые стандарты, заданные разработчиками. Для некоторых — ничего нет.

Ты только что повторил мой аргумент, который показывает, что разницы НЕТ, будь оно прописано в стандарте, разработчиками ли языка задано, или постепенно устаканилось через рост популярности третьесторонних генерилок. В общем, предлагаю этот момент "убогости Оберона" тоже считать закрытым... Уж очень с натяжкой выходит...


S>И только Обероновцы придумали бред с гипертекстом.


А мне гипертекстовые ссылки прямо из кода нравятся.
По работе часто приходится штудировать доку, описанную в "плоском" PDF, без гипертекстовых ссылок... А документы под тысячу страниц... После MSDN хочется поставить всех к стенке и выпустить пару длинных очередей из какого-нить крупнокалиберного девайса.

V>>Пример Doxygen/С++ показывает это во всей красе.

S>Пример Doxygen показывает, что
S>1. Для документации в языке гипертекст нафиг не упал
S>2. Пример Java вдохновил команду QT на разработку своего аналога. Пример Оберона не смог никого вдохновить.

Агащаз. Разработчики Сингулярити прямо ссылаются на проект SPIN на Modula-3, который был попыткой повторить Оберон в том же самом духе.
Re[22]: Оберон круче всех!
От: vdimas Россия  
Дата: 27.07.12 09:27
Оценка:
Здравствуйте, Sinclair, Вы писали:
V>>В С++ модификатор const прекрасно распространяется, обслуживается и гарантируется...
S>модификатор const в языке C++ — фикция.
S>Он не даёт нам никаких гарантий, т.к. всегда можно привести int к const int.

Важно, что ср-вами языка нельзя сделать наоборот для случая ссылок/указателей на это значение, т.е. нельзя const int & привести к int &. Когда берется копия значения (как ты показал), там вообще проблемы нет.

S>То, что я не могу изменить этот инт, не означает, что никто не может.


Дык, твой аргумнет известный, я же его и привел:

Мешает дыра через приведение в стиле С или всякие const_cast, но ведь можно представить такой же точно язык, где этих дыр нет?


Именно этот момент меня в С++ и раздражает, бо реально const_cast и приведение в стиле С для того же самого — это косяк в дизайне, спокойно лечится выпрямлением кода. Т.е. запросто можно убрать эти конструкции из языка и он ни капли не пострадает.

И вообще, речь была не столько о С++, сколько о том, можно ли вообще сделать императивные языки столь же безопасными, как функциональные. Модификатор const и предложенный модификатор clean позволяют организовать ссылочную прозрачность в нужных местах для императивного языка. Надо лишь, чтобы эта гарантия соблюдалась.

Тогда останется всего один момент в плане типобезопасности, требующий решения — это нулевые ссылки (указатели). В функциональных языках безопасность этого момента решается через некий АлгТД навроде Maybe и обязательно ветвление по нему на ПМ. Для императивных языков требуется придумать нечто аналогичное, встроенное в семантику языка.
Re[45]: Оберон круче всех!
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.07.12 12:11
Оценка:
Здравствуйте, vdimas, Вы писали:

V>По опыту С++, мне комфортно, когда выделены цветом:

V>- ключевые слова
V>- макроопределения
V>- enum
V>- типы
V>- ф-ии/методы
V>- строки.

V>Т.е. даже всего того, что было предложено еще оппонентами для раскраски, типа локальных/нелокальных переменных, статических/нестатических методов и т.п. мне не надо, потому что: засоряет вид, локальность/мемберность переменных разруливается в обязательном порядке через name conventions, а вызов статического мембера с вызовом экземплярного в С++ перепутать сложно.

Я, простите, не буду доверять вашему опыту в том, чего вам "не надо", пока вы не поработаете в среде, где всё это есть. Человек, так уж он устроен, быстро привыкает к хорошему.
В Турбопаскале 5 не было вообще никакой раскраски. В 6.0 добавили двухцветную раскраску уровня "ключевые слова vs всё остальное". В 7.0 сделали полноценную раскраску практически всего синтаксиса. Это мы говорим о промежутке буквально в несколько лет.
И, да, заметим — у ТурбоПаскаля и Борланд Паскаля была масса фанатов. Его делали Хейльсберг и Канн — парни, которые знают, чего требовать от компилятора и IDE.
А ваши тщания разрулить неопределённости синтаксиса через naming conventions и code style помогут ой как не везде. Раскраска синтаксиса помогает читать код, и её преимущество — в том, что она помогает читать любой код. А не только написанный по тем гайдлайнам, которые установили для себя лично вы.

V>А теперь берем паскалеподобные языки:

V>- макроопределений нет
V>- enum нет
Как это? Куда дели enum?
RTFM:
http://www.modula2.org/reference/enumerations.php
http://www.delphibasics.co.uk/Article.asp?Name=Sets
То, что в Обероне их нет — это, мягко говоря, не от большого ума. Трудно найти человека, который был бы от этого "улучшения" в восторге. Даже фанаты языка жалеют об их отсутствии.
V>- в языке сложно спутать идентификаторы типов с идентификаторами процедур.

V>Теперь вычти второй список из первого. Что в остатке? Раскраска строк? )))

V>Теперь аргументировано?
Почти. Но можно лучше — например, не допускать ляпов типа "отсутствия енумов в паскалеподобных языках".
V>Исходный Оберон — разработка 80-х, начала 90-х годов.
Ну, так в исходном Паскале тоже ничего не было. Однако в 80х, начале 90х для него таки сделали IDE.

V>Ну вот оно и откровенное юление. Ты же прекрасно понял о чем я, разве нет? С точки зрения стандарта языка Doxygen не существует.

Как и javadoc.

V>Только это и принципиально. Вместо того, чтобы прибивать гвоздями на заседаниях комитета всякую хрень к языку, этот момент был отдан на откуп третьесторонним разработчикам. Было очень много вариантов генерации доки для С++ во все времена (я за 20 лет их видел десятки), но вот устаканился Doxygen и буквально единицы коммерческих, которые мало кто пользует.

А вот Java и C# стандартизовали один стандарт. Благодаря этому, разработчикам не надо метаться в выборе движка.

V>Но ты посмотри, колгда это всё устаканилось — уже в 2000-х годах.

Конечно. А если бы формат комментов включили в ранние стандарты, или хотя бы в референс реализацию, то устаканилось бы это уже в 90х.

V>Я не о раскрасках, а о тагах в дотнетном XML-doc. Третьестороннии генерилки расширяют исходный набор тагов чуть ли не вдвое. Вот тебе кривизна попыток устаканить этот набор через стандарт во всей красе. Достаточно было дать референсный независимый тул, как поступили в Java.

Откуда кривизна? Стандарт намеренно сделан расширяемым. Показать место, где это обеспечено, или сами найдёте?
При этом основные семантические теги приняты без разногласий. А оформительские особенности (все эти <threadsafety>, <note>, etc.) — up to 3rd party.

V>Ты только что повторил мой аргумент, который показывает, что разницы НЕТ, будь оно прописано в стандарте, разработчиками ли языка задано, или постепенно устаканилось через рост популярности третьесторонних генерилок.

Конечно же есть. Разница — ровно такая же, как между поддержкой строк в языке и "возможностью наплодить свои классы строк". Стандарт даёт возможность разработчикам пользоваться языком и интероперировать, а в бесстандартных языках типа С++ имеется зоопарк плохо совместимых между собой "платформ" — Qt, MFC, и так далее.

В общем, предлагаю этот момент "убогости Оберона" тоже считать закрытым... Уж очень с натяжкой выходит...
Да без проблем.

V>А мне гипертекстовые ссылки прямо из кода нравятся.

Гипертекстовые ссылки из кода бывают двух типов:
1. В коде, Go to definition — поддерживаются вменяемыми IDE безо всякой ручной раскраски. В Delphi — Ctrl+Click, в VS, емнип, клавиатурная комбинация.
2. Произвольные, из комментариев — поддерживаются вменяемыми IDE безо всякой ручной раскраски.

V>По работе часто приходится штудировать доку, описанную в "плоском" PDF, без гипертекстовых ссылок... А документы под тысячу страниц... После MSDN хочется поставить всех к стенке и выпустить пару длинных очередей из какого-нить крупнокалиберного девайса.

Оберон бы вас точно так же не спас. Если авторы доки не воспользовались средствами, встроенными в PDF (вы же знали, что в нём прекрасно работают ссылки — ещё с тех времён, когда Adobe хотела заменить им HTML для вёрстки в вебе?), то средствами, встроенными в Оберон они бы тоже пренебрегли.

V>Агащаз. Разработчики Сингулярити прямо ссылаются на проект SPIN на Modula-3, который был попыткой повторить Оберон в том же самом духе.

Это они в контексте гипертекстовых исходников ссылаются, или вы опять пытаетесь контекст подменить?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.