AI
Тут предлагаю оценивать по размеру экосистемы расширений ))) https://marketplace.atlassian.com/addons/app/jira по порядку величины
Size: a a a
Типы в языках программирования, моделирования, представления знаний и жизни
384 membersпожаловаться на группу
2019 August 26
VK
И вообще, "интеграция через базу данных" всегда оказывается компактнее и чище, чем "интеграция через API". Единственный минус - сама схема становится контрактом, её можно сменить на новую, но не получится использовать обе одновременно, тогда как в случае API "вот работает новый API, а вот пока поддерживается старый, через 100500 костылей, но всё же".
MG
@val_krylov Если API в виде GraphQL или чём-то похожем, где ещё и есть исторические слепки? Не будет ли это лучше?
AI
В Eclipse сообществе часто у плагинов контакт через EMF (доработанный ООП с расширениями)
MG
@val_krylov Интересное подтверждение того, что кложуристы правы с "data is the king, в топку ваши фреймы". REST или ООП делают ненужные обёртки вокруг того, что на самом деле требуеются.
AL
tower of interpreters )
Ну да. Но я очень бы хотел видеть там язык программирования, а не язык математики в типах.
В языке математики (и отчасти физики) все переменные для пущей генерализации (и рукописной краткости, но это второе) обозначаются буквами греческого и иногда более редких алфавитов. В программировании они обозначаются смысловыми именами, достаточно длинными идентификаторами, где эти имена концептуальны, а не просто мнемоники. Обозначать просто буквами — моветон, если это не буква прямо из учебника физики или математики (то есть намоленная разными смыслами буква).
И вот я хотел бы как-то получить систему типов, которая имела бы смысл объектов мира, а не смысл математических объектов. Грубо говоря, тип типов Possible World чтобы был "из коробки" (я бы против отдельного механизма модальности, ибо модальность — это просто выражение факта отнесения к типу).
А потом, конечно, eDSL для каждого domain, как же без этого.
В языке математики (и отчасти физики) все переменные для пущей генерализации (и рукописной краткости, но это второе) обозначаются буквами греческого и иногда более редких алфавитов. В программировании они обозначаются смысловыми именами, достаточно длинными идентификаторами, где эти имена концептуальны, а не просто мнемоники. Обозначать просто буквами — моветон, если это не буква прямо из учебника физики или математики (то есть намоленная разными смыслами буква).
И вот я хотел бы как-то получить систему типов, которая имела бы смысл объектов мира, а не смысл математических объектов. Грубо говоря, тип типов Possible World чтобы был "из коробки" (я бы против отдельного механизма модальности, ибо модальность — это просто выражение факта отнесения к типу).
А потом, конечно, eDSL для каждого domain, как же без этого.
к
> Обозначать просто буквами — моветон
да не всегда, это моветон если речь идет про какой-то домен, но если пишется какой-то абстрактный код для абстрактных действий, то имя зачастую и не придумаешь никакое, и оно и не нужно, нужен только его тип и использование
да не всегда, это моветон если речь идет про какой-то домен, но если пишется какой-то абстрактный код для абстрактных действий, то имя зачастую и не придумаешь никакое, и оно и не нужно, нужен только его тип и использование
ON
Ну да. Но я очень бы хотел видеть там язык программирования, а не язык математики в типах.
В языке математики (и отчасти физики) все переменные для пущей генерализации (и рукописной краткости, но это второе) обозначаются буквами греческого и иногда более редких алфавитов. В программировании они обозначаются смысловыми именами, достаточно длинными идентификаторами, где эти имена концептуальны, а не просто мнемоники. Обозначать просто буквами — моветон, если это не буква прямо из учебника физики или математики (то есть намоленная разными смыслами буква).
И вот я хотел бы как-то получить систему типов, которая имела бы смысл объектов мира, а не смысл математических объектов. Грубо говоря, тип типов Possible World чтобы был "из коробки" (я бы против отдельного механизма модальности, ибо модальность — это просто выражение факта отнесения к типу).
А потом, конечно, eDSL для каждого domain, как же без этого.
В языке математики (и отчасти физики) все переменные для пущей генерализации (и рукописной краткости, но это второе) обозначаются буквами греческого и иногда более редких алфавитов. В программировании они обозначаются смысловыми именами, достаточно длинными идентификаторами, где эти имена концептуальны, а не просто мнемоники. Обозначать просто буквами — моветон, если это не буква прямо из учебника физики или математики (то есть намоленная разными смыслами буква).
И вот я хотел бы как-то получить систему типов, которая имела бы смысл объектов мира, а не смысл математических объектов. Грубо говоря, тип типов Possible World чтобы был "из коробки" (я бы против отдельного механизма модальности, ибо модальность — это просто выражение факта отнесения к типу).
А потом, конечно, eDSL для каждого domain, как же без этого.
да, примерно понимаю, согласен. при этом я "интерпретаторы" использую в двух смыслах, один - алгоритмический, второй - вверх-вниз по оси абстракций (пачка атомов - транзистор - фрагмент_усилителя_низких_частот итд)
M
//И вот я хотел бы как-то получить систему типов, которая имела бы смысл объектов мира, а не смысл математических объектов.//
Я вообще сомневаюсь в том, что всем одинаково понятен этот тезис.
Извините за странный вопрос: а есть еще желающие как-то получить систему типов, которая .... ?
Я вообще сомневаюсь в том, что всем одинаково понятен этот тезис.
Извините за странный вопрос: а есть еще желающие как-то получить систему типов, которая .... ?
ON
@val_krylov Интересное подтверждение того, что кложуристы правы с "data is the king, в топку ваши фреймы". REST или ООП делают ненужные обёртки вокруг того, что на самом деле требуеются.
data is the king в том смысле что инкапсуляция может помешать рассмотреть пачку атомов как транзистор, даже если рядом есть концепт усилителя и того куска усилителя которым он является
к
Maxim
//И вот я хотел бы как-то получить систему типов, которая имела бы смысл объектов мира, а не смысл математических объектов.//
Я вообще сомневаюсь в том, что всем одинаково понятен этот тезис.
Извините за странный вопрос: а есть еще желающие как-то получить систему типов, которая .... ?
Я вообще сомневаюсь в том, что всем одинаково понятен этот тезис.
Извините за странный вопрос: а есть еще желающие как-то получить систему типов, которая .... ?
не очень понятно что это значит в общем-то
к
количество описывающих функций на каждый объект бесконечно
ON
> Обозначать просто буквами — моветон
да не всегда, это моветон если речь идет про какой-то домен, но если пишется какой-то абстрактный код для абстрактных действий, то имя зачастую и не придумаешь никакое, и оно и не нужно, нужен только его тип и использование
да не всегда, это моветон если речь идет про какой-то домен, но если пишется какой-то абстрактный код для абстрактных действий, то имя зачастую и не придумаешь никакое, и оно и не нужно, нужен только его тип и использование
(имхо) это часто симптом отсутствия термина/концепта, например, есть ф-я (a,b)=>a*b, и без слова "множитель" их особо и не назовешь
ON
количество описывающих функций на каждый объект бесконечно
...тк нету общей онтологии. могу предположить, что @ailevenchuk говорит об инструментарии для построения этих самых описывающих функций
к
при этом
если уж все называть, но лучше даже и этого
(a, b) => a * b выглядит куда читабельнее, чем(leftFactor, rightFactor) =>
product = leftFactor * rightFactor
productесли уж все называть, но лучше даже и этого
(leftFactor, rightFactor) => leftFactor * rightFactorVK
Вот этот пункт нужно бы развернуть. Это очень похоже на тот вопрос, который я задавал в самом начале: как на GPL мы планируем описывать мир (включая possible worlds), какая система типов для этого требуется.
Ну, а затем eDSL на базе этого хост GPL — микротеории же.
Как вариант — это надстройка "миромоделирования" над каким-то GPL, а потом eDSL для разных domains с использованием этой надстройки.
Так что я вроде как согласен с такой конструкцией, но проблема та же, что в случае eDSL — stand-alone GPL "на ассемблер" против метапрограммирования над уже имеющимся GPL (скажем, над Julia).
Ну, или можно говорить о "двухуровневых eDSL" — языковых гирляндах, языковых компиляторных цепочках (виртуальных виртуальных машинах — как только эта идея уже не называлась!).
Ну, а затем eDSL на базе этого хост GPL — микротеории же.
Как вариант — это надстройка "миромоделирования" над каким-то GPL, а потом eDSL для разных domains с использованием этой надстройки.
Так что я вроде как согласен с такой конструкцией, но проблема та же, что в случае eDSL — stand-alone GPL "на ассемблер" против метапрограммирования над уже имеющимся GPL (скажем, над Julia).
Ну, или можно говорить о "двухуровневых eDSL" — языковых гирляндах, языковых компиляторных цепочках (виртуальных виртуальных машинах — как только эта идея уже не называлась!).
Julia - сам по себе нишевый DSL для числодробильни, несмотря на все попытки "дорасти" до GPL, так что лишь добавляет хрупкости любой конструкции на базе, не вижу смысла в "карточных домиках"
ON
при этом
если уж все называть, но лучше даже и этого
(a, b) => a * b выглядит куда читабельнее, чем(leftFactor, rightFactor) =>
product = leftFactor * rightFactor
productесли уж все называть, но лучше даже и этого
(leftFactor, rightFactor) => leftFactor * rightFactor...потому что значимый и достаточный символ тут «*», а остальные да, мало приносят. а вот если ф-я выглядит как (a,b)=>a_b, и мы не знаем, что такое «_», то можно и подписать. или комментарий сделать
M
Ну да. Но я очень бы хотел видеть там язык программирования, а не язык математики в типах.
В языке математики (и отчасти физики) все переменные для пущей генерализации (и рукописной краткости, но это второе) обозначаются буквами греческого и иногда более редких алфавитов. В программировании они обозначаются смысловыми именами, достаточно длинными идентификаторами, где эти имена концептуальны, а не просто мнемоники. Обозначать просто буквами — моветон, если это не буква прямо из учебника физики или математики (то есть намоленная разными смыслами буква).
И вот я хотел бы как-то получить систему типов, которая имела бы смысл объектов мира, а не смысл математических объектов. Грубо говоря, тип типов Possible World чтобы был "из коробки" (я бы против отдельного механизма модальности, ибо модальность — это просто выражение факта отнесения к типу).
А потом, конечно, eDSL для каждого domain, как же без этого.
В языке математики (и отчасти физики) все переменные для пущей генерализации (и рукописной краткости, но это второе) обозначаются буквами греческого и иногда более редких алфавитов. В программировании они обозначаются смысловыми именами, достаточно длинными идентификаторами, где эти имена концептуальны, а не просто мнемоники. Обозначать просто буквами — моветон, если это не буква прямо из учебника физики или математики (то есть намоленная разными смыслами буква).
И вот я хотел бы как-то получить систему типов, которая имела бы смысл объектов мира, а не смысл математических объектов. Грубо говоря, тип типов Possible World чтобы был "из коробки" (я бы против отдельного механизма модальности, ибо модальность — это просто выражение факта отнесения к типу).
А потом, конечно, eDSL для каждого domain, как же без этого.
Тезис:
//И вот я хотел бы как-то получить систему типов, которая имела бы смысл объектов мира, а не смысл математических объектов.//
Я вообще сомневаюсь в том, что всем одинаково понятен этот тезис.
Извините за странный вопрос: а есть еще желающие как-то получить систему типов, которая .... ?
//И вот я хотел бы как-то получить систему типов, которая имела бы смысл объектов мира, а не смысл математических объектов.//
Я вообще сомневаюсь в том, что всем одинаково понятен этот тезис.
Извините за странный вопрос: а есть еще желающие как-то получить систему типов, которая .... ?
AL
при этом
если уж все называть, но лучше даже и этого
(a, b) => a * b выглядит куда читабельнее, чем(leftFactor, rightFactor) =>
product = leftFactor * rightFactor
productесли уж все называть, но лучше даже и этого
(leftFactor, rightFactor) => leftFactor * rightFactorМне не нравится сам факт, что используется пример из математики (ну, или физики, который затем привычно сведётся к примеру из математики), а не из описания какой-то инженерной или менеджерской предметной области.
Понятность примерно того же самого не для умножения, а для какой-нибудь нефтефильтрации на НПЗ или поставки реквизита на съемку 6 эпизода 13 сезона сериала #235 была бы минимальна.
А так пример, конечно, тривиален. Тээривэиаэлеэн — пишем вместо намоленных сокращений полные имена типов и получается длинней и хуже. Но если нет сокращений? Зачастую нет и самих понятий, их придумать нужно.
Понятность примерно того же самого не для умножения, а для какой-нибудь нефтефильтрации на НПЗ или поставки реквизита на съемку 6 эпизода 13 сезона сериала #235 была бы минимальна.
А так пример, конечно, тривиален. Тээривэиаэлеэн — пишем вместо намоленных сокращений полные имена типов и получается длинней и хуже. Но если нет сокращений? Зачастую нет и самих понятий, их придумать нужно.