Здравствуйте, LaptevVV, Вы писали:

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

Контейнер — только одна из многих абстракций используемых в программировании.
Поэтому принципиальный вопрос в том, будет эта абстракция описываться извне, или она будет задана фиксированной. К этому и имеет отношение свойства контейнера — если абстракция задана внутри среды программирования, то она имеет фиксированный набор аттрибутов/свойств. Если извне (то есть программист может сам добавлять новые абстракции) — то как быть с "похожими" абстракциями заданными разными программистами (или разными версиями той-же абстрации, например, к понятию контейнера добавился аттрибут фиксированности размера).

LVV>Чтоб не надо было набирать посимвольно.

Что набирать? Если не хочется набирать в виде текста — то это структурный редактор, то есть MPS, SymADE и пр.
Но учтите, что так редактировать удобно только декларативную часть программы, а выражения и типы — намного удобнее именно "посимвольно" (если не использовать совсем уж сложные методики, которые я сейчас разрабатываю).

LVV>Причем — это не макросы, хочется совсем из компилятора убрать лексический и семантический анализ и переместить его в редактор. На выходе которого — семантическое дерево программы.

А хранить в виде текста? Тогда лексер/парсер/анализатор всё равно в виде какого-то модуля должны быть, тогда его просто в редакторе и компиляторе использовать как "библиотеку".

Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, mkizub, Вы писали:

LVV>Не. Контейнер — это контейнер. По определению контейнер — набор однотипных элементов. Если посмотреть на стльные контейнеры, то все они имеют, в общем-то одинаковый набор операций. Разница — только в реализации.

Тут главное не перебощить с абстракциями, а иначе ведь можно доабстрагироваться до машины тьюринга,
на которой конечно же можно программировать, но только именно из-за высочайшего уровня абстракции
это весьма нетривиально

Разница в реализациях — это часто именно удобство использования в разных ситуациях.
Бездумная унификация, без учета реальной задачи, как раз только мешает.

Здравствуйте, bkat, Вы писали:

B>Тут главное не перебощить с абстракциями, а иначе ведь можно доабстрагироваться до машины тьюринга,
B>на которой конечно же можно программировать, но только именно из-за высочайшего уровня абстракции
B>это весьма нетривиально

Ну можно и 2 комбинаторами S и K обойтись, будет ещё более жёстко.

B>Разница в реализациях — это часто именно удобство использования в разных ситуациях.
B>Бездумная унификация, без учета реальной задачи, как раз только мешает.

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

Здравствуйте, Курилка, Вы писали:

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

Я так и не понял, в итоге каких рассуждений нам понадобился базис.
Кстати, ты в каком базисе думаешь?

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Курилка, Вы писали:

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

M>Я так и не понял, в итоге каких рассуждений нам понадобился базис.
Т.е. ты можешь дать вариант построения оной системы без базиса? Продемонстрируй?

M>Кстати, ты в каком базисе думаешь?
Мышление ты относишь к формализованной системе?

Здравствуйте, Курилка, Вы писали:
M>>Я так и не понял, в итоге каких рассуждений нам понадобился базис.
К>Т.е. ты можешь дать вариант построения оной системы без базиса? Продемонстрируй?

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

Вы, Курилка, пойдете снизу вверх, от математики, от какой-либо математической модели, которая доказуемо "равномощна" машине тьюринга или лямбда-исчислению и будете на ее основе строить новые понятия.

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

Здравствуйте, Mr.Cat, Вы писали:

MC>Мне кажется, у Вас различные подходы к построению систем программирования.

MC>Вы, Курилка, пойдете снизу вверх, от математики, от какой-либо математической модели, которая доказуемо "равномощна" машине тьюринга или лямбда-исчислению и будете на ее основе строить новые понятия.

Совсем не обязательно начинать проектировать уже напрямую в терминах целевого базиса, я лишь говорил о том, что такой базис у нас в любом случае будет (как минимум код x86 или другой платформы).

Здравствуйте, Mr.Cat, Вы писали:

MC>mkizub, видимо, пойдет сверху вниз. Он сперва обдумает то, что он хочет получить в итоге, а потом будет искать математический аппарат, позволяющий описать желаемое.

А искать будет из уже существующих или каждый раз будет изобретаться велосипед?

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

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

Здравствуйте, Mr.Cat, Вы писали:

MC>mkizub, видимо, пойдет сверху вниз. Он сперва обдумает то, что он хочет получить в итоге, а потом будет искать математический аппарат, позволяющий описать желаемое.


Приблизительно так я создал логический движок (наподобие пролога) для решения своих задач, получив, в результате, возможность объединить процедурную и логическую парадигмы программирования.

Здравствуйте, Аноним, Вы писали:

А>А искать будет из уже существующих или каждый раз будет изобретаться велосипед?

Какой дикий примитив. Или только из существующих, или каждый раз изобретать свой.
Это всё последствия "логического" мышления.

А>Как убежденный практик, могу смело заверить, что большинство реальных проблем,
А>которые реально сильно затрудняют получение хорошего продукта в заданное время и бюджет,
А>вообще не имеют никакого отношения к тому, что обсуждается в диссере и работах большинства
А>теоретиков от программирования.

Как убеждённый практик, рекомендую вначале отойти от чёрно-белого типа мышления, и тогда
вы сможете увидеть, что эти реальные проблемы имеют прямое отношение к обсуждаемому
в диссертации.

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

Вот ещё образчик чёрно-белого мышления. Люди полностью должны быть устранены, и никак иначе.
Вариант, когда компьютер на 90% или на 50% автоматизирует работу — не рассматривается в принципе.

Здравствуйте, mkizub, Вы писали:

M>Вот ещё образчик чёрно-белого мышления. Люди полностью должны быть устранены, и никак иначе.
M>Вариант, когда компьютер на 90% или на 50% автоматизирует работу — не рассматривается в принципе.

То была ирония в чистом виде.
На проектах, в которых больше 2-х людей проблемы совсем иные.
Ты почитай хотя бы статистику причин, по которым проекты проваливались.
Львинная доля — это проблемы коммуникации 2-х индивидумов
и различные проявления этой проблемы в виде нереальных сроков
или требований, которые кто-то написал, но их пол команды просто проигнорировала.

Еще не видел не одного проекта, который бы провалился из-за неправильно выбранного инструмента,
или из-за того, что у программера нету абстрактного вектора и он типа мучается с конкретной реализацией.

Но вера в формализм, который все решит, будет жить всегда.
Я лично не против таких работ, но и на скепсис тоже имею право.

Здравствуйте, Аноним, Вы писали:

А>На проектах, в которых больше 2-х людей проблемы совсем иные.
А>Ты почитай хотя бы статистику причин, по которым проекты проваливались.
А>Львинная доля — это проблемы коммуникации 2-х индивидумов
А>и различные проявления этой проблемы в виде нереальных сроков
А>или требований, которые кто-то написал, но их пол команды просто проигнорировала.

Ну, это не проблемы 2-х людей. Это проблемы комманды из 10, из 100 человек.
И чем больше комманда — тем больше эти проблемы.
А если компьютер сможет автоматизировать ещё большую часть работы программиста — комманда станет меньше, для выполнения той-же работы. И те проблемы, о которых вы говорите — уменьшаться, значительно уменьшатся.

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

Я видел кучу проектов, провалившихся из-за неправильного инструмента или неправильного им пользования.
Вроде кода написанного на С++ вместо С, для мобильной платформы, которая просто не вмещает в себя все эти классы и инстанциированные темплейты.
Или вроде кода написанного на С++ вместо Java/.NET, где проблемы с ручным управлением памятью не позволяют отладить приложение.
Или вроде кода написанного на Java, в местах где нужен реал-тайм или расходы на JIT-компилятор неприемлемы, а без JIT-а неприемлема скорость работы.
Но работа над этими проектами продолжалась и продолжалась, до тех пор, пока их либо не переписывали на соотвествующем инструменте, либо пока финансирование проекта не закрывалось. А в статистике они, конечно, выглядят как проблемы менеджмента, который не сумел организовать работу, чтоб закончить её в срок и не превысить бюджет. Ага.

А>Но вера в формализм, который все решит, будет жить всегда.

Это к Курилке, а не к обсуждаемой работе

А>Я лично не против таких работ, но и на скепсис тоже имею право.

Скепсис это очень хорошо, но анализировать причины и следствия можно тщательнЕе.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Аноним, Вы писали:

А>>Но вера в формализм, который все решит, будет жить всегда.

M>Это к Курилке, а не к обсуждаемой работе

Интересные у тебя фантазии

Здравствуйте, mkizub, Вы писали:

M>Я видел кучу проектов, провалившихся из-за неправильного инструмента или неправильного им пользования.
M>Вроде кода написанного на С++ вместо С, для мобильной платформы, которая просто не вмещает в себя все эти классы и инстанциированные темплейты.

Такое бывает, но все же гораздо реже, чем проблемы коммуникации.
Впрочем и в твоем случае это тоже наверняка было просто волевое решение
одного человека, без нормальной feasibility фазы,
т.е. в итоге опять отсутвие нормальной коммуникации между членами команды.

В твоем подходе такие проблемы совсем не исключаются.
Появляется еще одна степень свободы, а значит еще больше возможностей
не договориться или принять неверные решения не согласовав с другими членами команды.
Источних основных проблем при разработке сложных систем есть и будет человек
и это останется независимо от формализмов.

Здравствуйте, Аноним, Вы писали:

А>В твоем подходе такие проблемы совсем не исключаются.
А>Появляется еще одна степень свободы, а значит еще больше возможностей
А>не договориться или принять неверные решения не согласовав с другими членами команды.
А>Источних основных проблем при разработке сложных систем есть и будет человек
А>и это останется независимо от формализмов.

В конечном итоге все проблемы сводятся к человеку, что совсем не означает, что не надо работать над улучшением инструментов, которыми он пользуется.
А дополнительная степень свободы — это не только дополнительная возможность совершить ошибку, но и дополнительная возможность исправить ошибку.
Мы же не запрещаем себе пользоваться ножом или огнём, хотя они потенциально опасны.
Только что же вы писали, что не верите, что формализм решит проблемы. И тут на тебе — давайте загоним программиста в узкие рамки, уберём у него возможности кроме тех, которые мы выбрали — и тогда будет типа лучше. Не уберёт это проблему человеческого фактора, потому как этот человеческий фактор и будет решать какие возможности дать программисту, а какие не дать.

Здравствуйте, mkizub, Вы писали:

Со всем согласен.
Просто я, как практик, не верю в серебрянные пули.
Ну будет еще один метод. Как созреет, до промышленного уровня,
посмотрим на него, поиграемся, и пополним яшик с доступными инструментами еще одним молотком

Здравствуйте, mkizub!

M>Представь себе понятие "контейнер" и "итератор". В современных языках программирования — это нечто крайне конкретное. В яве это Iteratable и Iterator интерфейсы. Если javac их встретил — он понял, что это контейнер и по нему можно итерировать специальной конструкцией языка. В C# это IEnumerable и так далее.
M>А есть в языках программирование понятие контейнера и итератора как таковое, не привязанное к конкретной реализации?
M>Сейчас — нету.

Да было это уже всё... и контейнеры и потоки как часть языка... И умные языки были и рисовалки блок-схем... Вон щас модно функции как first-class objects пихать куда надо и не надо... Не выходит как-то Неизменно приходили к тому, что приходилось жертвовать всем ради универсальности, затем эта универсальность становилась никому не нужна и все использовали свои обёртки/самописные велосипеды. Могу поискать оды ассемблеру как языку для неподготовленных специалистов, что позволит решать мегаглобальные задачи не заморачиваясь кодингом машкодов...

Не стоит засорять высокоуровневый язык абстракциями узких сценариев.

В шарпе и в яве нет конкретных реализаций чего-то. Конкретные реализации живут на уровне платформы. А в языках есть синтаксический сахар для использования отдельных абстракций типа "перебираемое". Больше требовать глупо. Оно того не стоит — прикручивать поддержку множества платформ к одному языку.

Можно ещё раз понаступать на те же грабли — всегда пжалста