В рамках полемики с Мемегой позволю себе процитировать известного российского логика и информатика Непейводу Н.Н. по вопросам образования и "новомодных колледжей".

"В последние два года многие вузы России столкнулись с двумя проблемами: падение на 70% уровня подготовки абитуриентов и появление на 1 курсах поколения, которое обычно называется homo informaticus. Анализируя встречающиеся в литературе характеристики homo informaticus и сравнивая их с реальным уровнем абитуриентов даже на специальности информатика в отнюдь не худшем российском университете, моджно отметить следующее.

1. До уровня homo эти особи не доросли. Они работают с компьютерами как обезьяны. Мышление их убито, они пытаются угадать желаемый ответ, как и требуется в тестах.

2. Столкновение с открытым софтом вызывает у них шок. Командная строка воспринимается как изощренная пытка: "Ты не умствуй, ты пальцем покажи, куда ткнуть мышой!"

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

4. Неумение писать.

5. Неумение искать релевантную информацию.

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

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

Добавить нечего.

я учился на МатМехе СПбГУ и вобщем преуспел в своей специалность программиста

но вот было на всех младших курсах прочтение большого количества высокободяжных абстрактных лекций с приведением нескончаемого потока в основном непонятно как применимых теорем

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


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

я недоволен!

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

M>Программирование — это искусство, оно не объяснимо, не упорядоченно и не ограниченно. Только тот, кто понимает это, может перешагнуть рамки "дозволенного" и создать настоящий шедевр.

Бобер, выдыхай !

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

C>Я просмотрел её, пропуская большинство доказательств. Сразу возник вопрос: а для чего оно всё это вообще нужно? Где есть какие-нибудь практические результаты?

Представь себе понятие "контейнер" и "итератор". В современных языках программирования — это нечто крайне конкретное. В яве это Iteratable и Iterator интерфейсы. Если javac их встретил — он понял, что это контейнер и по нему можно итерировать специальной конструкцией языка. В C# это IEnumerable и так далее.
А есть в языках программирование понятие контейнера и итератора как таковое, не привязанное к конкретной реализации?
Сейчас — нету.
Можно написать подобный компилятор (скажем, для переделывания Java в C# и пр.). У неё будет понятие "контейнер вообще" и "итератор вообще". И частные реализации этих вещей в яве и c#. Теперь мы в неё решили добавить ещё компиляцию в Ada, или решили добавить поддержку Enumeration из явы, чтоб она его тоже понимала как итератор. А ещё мы в ней захотели добавить к понятию контейнера ordered и unordered контейнеры, thread-safe и не-safe, итерирование с начала в конец и с конца в начало для ordered контейнеров и так далее.
У тебя в мозгу все эти понятия есть. А у компьютера нету. Их туда надо вводить, и если ты будешь вводить их ad-hoc, ручками каждый случай — ты уже даже с контейнерами запаришься, настолько этих понятий будет много и между ними будет куча связей. Ты когда учишь новый язык — ты же просто привязываешь понятия из этого языка к уже имеющимся у тебя понятиям из знакомых тебе языков программирования, или создаёшь у себя новое понятие, и опять-же связываешь его со знакомыми тебе. А в процессе написания кода и использования этого нового языка — ты обнаруживаешь новые и новые связи, возможности по использованию и специфике этих новых понятий. Как сказал Фейнман — "понять — это свести к привычному, плюс умение им пользоваться". То есть ты либо сводишь понятия к знакомым тебе понятиям (которыми ты уже умеешь пользоваться), либо сделать несводимое к старому — привычным, и научиться им пользоваться.

Вот там в диссертации предложен один из подходов, как создать некую "базу знаний" о "понятиях" и их "связях", и возможность используя эту базу знаний выводить новые связи между понятиями. Как в прологе выводятся новые факты из уже имеющейся базы знаний. Ты добавляешь новое понятие или новое свойство (New), связываешь его с чем-то уже там имеющимся (Old1), и компьютер автоматически получает возможность связать это новое понятие с другими понятиями (Old2, Old2), за счёт имеющихся уже у него связей между Old1 и Old2 и Old3.

Для современых технологий, с фиксированной убогой семантикой, это в общем-то не нужно. Но если ты делаешь расширяемую систему мета-программирования, вроде SymADE или MPS или IP — то это поможет превратить такую среду/IDE из просто средства создания DSL-ей в среду которая на 90% уберёт кодирование. Так же как ты сейчас не заморачиваешься низкоуровневой оптимизацией кода на ассемблере, так через надцать лет программисты не будут заморачиваться кодированием.

Вот для этого оно нужно.

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

S>я учился на МатМехе СПбГУ и вобщем преуспел в своей специалность программиста

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

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


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

S>я недоволен!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Валерий Выхованец защитил докторскую диссертацию «Синтез эффективных математических моделей дискретной обработки данных на основе алгебраической и понятийной декомпозиции предметной области».

Предлагается новая методология формализации знаний – на основе понятийного анализа – и соответствующая ей технология программирования.

http://valery.vykhovanets.ru/Texts/2006/Vykhovanets2006_6.pdf

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

А>Валерий Выхованец защитил докторскую диссертацию «Синтез эффективных математических моделей дискретной обработки данных на основе алгебраической и понятийной декомпозиции предметной области».

А>Предлагается новая методология формализации знаний – на основе понятийного анализа – и соответствующая ей технология программирования.

А>http://valery.vykhovanets.ru/Texts/2006/Vykhovanets2006_6.pdf
Труд, конечно, впечатляющий. Математики достаточно много.
Но до практической реализации вкак технологии программирования — как до Луны.
Именно потому, что это просто диссер, и фирмы о нем не узнают никогда.
Но как тенденция в направлении развития — да, стоит внимания.
Возможно, аналогичные исследования выполняются в недрах микрософта самостоятельно.

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

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

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

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

Вот, наверное, и совет принимал защиту по такому принципу, а не по сути.

LVV> А модель предметной области как онтология понятий — давно хорошо известно.

Вы не читали. Во-первых, потому что норматив на чтение — 100 страниц в день, а там 500 и научного текста, который читается медленнее.
А во-вторых, потому что в работе онтологический подход критикуется.

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

А>>> Валерий Выхованец защитил докторскую диссертацию
LVV>> конечно, впечатляющий. Математики достаточно много.
AS>Вот, наверное, и совет принимал защиту по такому принципу, а не по сути.
Ну, по сути мало кто понимает. Да и самому автору важней докторская, чем суть.
Суть нужна была таким людям, как Ершов Андрей Петрович. ИМХО, сейчас в нашей информатике таких величин нет.
Смешанные вычисления Ершова сколько лет назад были опубликованы...
JIT-компиляторы — смешная реализация смешанных вычислений...
LVV>> А модель предметной области как онтология понятий — давно хорошо известно.
AS>Вы не читали. Во-первых, потому что норматив на чтение — 100 страниц в день, а там 500 и научного текста, который читается медленнее.
Естественно, за 15 минут прочитать такой труд невозможно. Проглядел, да и то — по диагонали. На каникулах всерьез и займусь...
AS>А во-вторых, потому что в работе онтологический подход критикуется.
Между прочим, насколько я понимаю,
онтологический подход никогда не претендовал на то, чтобы именоваться парадигмой программирования.

А>Предлагается новая методология формализации знаний – на основе понятийного анализа – и соответствующая ей технология программирования.
А>http://valery.vykhovanets.ru/Texts/2006/Vykhovanets2006_6.pdf

Это нереально круто. Дело в том, что я сам занимаюсь исследованиями в этом направлении (конечно, мои исследования гораздо скромнее). И как раз эта работа поможет мне обобщить собственные мысли и создать целостную картину этой области.

Спасибо за ссылку.

Это — будущее программирования. Может быть, не конкретно это, но будущее находится где-то в этом направлении.

Конечно, практическая реализация у Выхованца подкачала, как и у многих других до него (и, видимо, после него).

Такая сногсшибательная теоретическая часть, а на выходе мы получили — понятийный… ассемблер.

Конечно, до «забытия» C# здесь как до Луны.

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

LVV>Но до практической реализации вкак технологии программирования — как до Луны.
LVV>Именно потому, что это просто диссер, и фирмы о нем не узнают никогда.
LVV>Но как тенденция в направлении развития — да, стоит внимания.
LVV>Возможно, аналогичные исследования выполняются в недрах микрософта самостоятельно.
Jetbrains MPS. Они ее ваяют уже лет пять и вроде бы нечто работающее уже есть.
Ничего принципиально нового — автор не открывает, Да DSL, да некоторые даже пользуются. Хотя, я просмотрел только практические примеры в конце диссертации. Скорее всего я что то упустил

Программирование — это искусство, оно не объяснимо, не упорядоченно и не ограниченно. Только тот, кто понимает это, может перешагнуть рамки "дозволенного" и создать настоящий шедевр.

А>Ничего принципиально нового — автор не открывает, Да DSL, да некоторые даже пользуются.

по-аналогии, афтар тут заявил про Cyc и про Nemerle:

1. Cyc (цик) — база знаний продукционного типа, базирующаяся, как и многие другие, на исчисление предикатов 1 порядка.
2. Nemerle, как и все языки программирования, не более чем язык программирования, хоть и интегрирует в себе идеи объектной и функциональной методологии.

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

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

А>Валерий Выхованец защитил докторскую диссертацию «Синтез эффективных математических моделей дискретной обработки данных на основе алгебраической и понятийной декомпозиции предметной области».
Ну... Зла на нашу фундаментальную информатику у меня уже не осталось...

А>Предлагается новая методология формализации знаний – на основе понятийного анализа – и соответствующая ей технология программирования.
А>http://valery.vykhovanets.ru/Texts/2006/Vykhovanets2006_6.pdf
Я просмотрел её, пропуская большинство доказательств. Сразу возник вопрос: а для чего оно всё это вообще нужно? Где есть какие-нибудь практические результаты?

Суть рассматриваемой темы — если по-простому — такова: на каком языке удобнее описать решение стоящей задачи, такой и будем использовать. Если таковой не обнаружится, то создадим его. Технология отличается от Domain Specific Language (DSL) тем, что удается описывать семантику произвольных языковых конструкций, опять же, на удобной для этого языке (т.е. решаем новую задачу, или выполняем семантическую рекурсию). А в подходах DSL (SymADE, Intentional Programming, JetBrains, Nemerle и др.) все, в конечном итоге, описывается на некотором фиксированном (си-подобном) языке.

Пожалуй, еще фишка в том, что используется онтология с четерьмя типами связей между понятиями: т.е. связи между понятиями не несут семантической нагрузки, а потому не зависят от решаемой задачи.

В итоге, как мне кажется, предлагается развивать выразительные возможности используемых языков. Фактически, современные языки программирования — языки Эллочки Щукиной (Ильф и Петров, 12 стульев). Можно, конечно, закрыть глаза на эту проблему, однако основной вектор развития технологий программирования направлен именно в эту сторону (язык Z спецификаций в Оксфорде, система Масима Кизуба SymADE, Intentional Programming Чарзльза Симони, meta-programming system питерских JetBrains, Nemerle и др.)

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

V>В рамках полемики с Мемегой позволю себе процитировать известного российского логика и информатика Непейводу Н.Н. по вопросам образования и "новомодных колледжей".

V>"В последние два года многие вузы России столкнулись с двумя проблемами: падение на 70% уровня подготовки абитуриентов и появление на 1 курсах поколения, которое обычно называется homo informaticus. Анализируя встречающиеся в литературе характеристики homo informaticus и сравнивая их с реальным уровнем абитуриентов даже на специальности информатика в отнюдь не худшем российском университете, моджно отметить следующее.

К сожалению, не могу ни подтвердить, ни опровергнуть эти данные, т.к. ими не обладаю. Просто потому, что живу и работаю не в России, а в Литве. Параллельно с работой в одном SW компании, читаю лекции в Вильнюсском университете. За последние 5 лет работы в универе сделал такие выводы — в абсолютных числах количество нормальных абитуриентов не уменьшилось. По-прежнему, есть очень толковые ребята, которые с радостью выбирают наиболее сложные проекты и программы. Успевают выполнить требования, которые предлагаются в универе и + еще занимаются дополнительно. НО! У нас очень увеличился набор (именно на информатику). Когда я учился, на курсе было 70 человек, из которых практически все писали программы сами. Теперь же, только на информатику принимают около 200 человек, а еще есть Software Engineering (125 человек) и биоинформатика (около 30). Так вот — из всего этого отряда, все теже 70-100 человек могут самостоятельно писать программы. Остальные — увы
Сначала пытался бороться, "пробудить искорку" в глазах тем, кому не интересно. А потом понял, что если человек не хочет, то его ничем не заставишь. Поэтому ориентируюсь на сильнейших. В конце концов, это не школа или детский сад, уже взрослые люди, и должны сами понимать что и как делать.

V>1. До уровня homo эти особи не доросли. Они работают с компьютерами как обезьяны. Мышление их убито, они пытаются угадать желаемый ответ, как и требуется в тестах.
Я бы предложил жесткий отсев после 1 курса.

V>2. Столкновение с открытым софтом вызывает у них шок. Командная строка воспринимается как изощренная пытка: "Ты не умствуй, ты пальцем покажи, куда ткнуть мышой!"
У нас раньше вообще не учили, куда "жать мышкой", предполагалось, что сами должны разобраться. Такую же идею высказал профессор Любимский, когда читал у нас лекцию (ему в 2000 г. присвоили звание почетного профессора универа, светлая память, великий человек).

V>3. Полное неумение читать и клиповое мышление. Ввиду привычки к копипасту и языку падонков, они не могут даже перепечатать без ошибок в командную строку строку из учебного пособия, а тем более модифицировать ее другими параметрами.
Опять же не все. Но если человек не читает, то это уже о многом говорит.

V>4. Неумение писать.
Да, есть такое.

V>5. Неумение искать релевантную информацию.
На 1 курсе вполне возможно.

V>Не учитывая все эти особенности, преподавать невозможно. Лишь 1-ый курс — то время, когда обезьянолюдей можно превратить хотя бы в неандертальцев. Поэтому открытый софт и только открытый софт с самого первого дня — решение в данной критической ситуации.
А вот тут есть опасность. Что означает "преподавать,учитывая все эти особенности"? Если это означает лишь снижение планки требований, то я против. Так можно дойти до того, что универ превратится в ПТУ.

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

V>Добавить нечего.

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

C>Я просмотрел её, пропуская большинство доказательств. Сразу возник вопрос: а для чего оно всё это вообще нужно? Где есть какие-нибудь практические результаты?

Представь себе понятие "контейнер" и "итератор". В современных языках программирования — это нечто крайне конкретное. В яве это Iteratable и Iterator интерфейсы. Если javac их встретил — он понял, что это контейнер и по нему можно итерировать специальной конструкцией языка. В C# это IEnumerable и так далее.
А есть в языках программирование понятие контейнера и итератора как таковое, не привязанное к конкретной реализации?
Сейчас — нету.
Можно написать подобный компилятор (скажем, для переделывания Java в C# и пр.). У неё будет понятие "контейнер вообще" и "итератор вообще". И частные реализации этих вещей в яве и c#. Теперь мы в неё решили добавить ещё компиляцию в Ada, или решили добавить поддержку Enumeration из явы, чтоб она его тоже понимала как итератор. А ещё мы в ней захотели добавить к понятию контейнера ordered и unordered контейнеры, thread-safe и не-safe, итерирование с начала в конец и с конца в начало для ordered контейнеров и так далее.
У тебя в мозгу все эти понятия есть. А у компьютера нету. Их туда надо вводить, и если ты будешь вводить их ad-hoc, ручками каждый случай — ты уже даже с контейнерами запаришься, настолько этих понятий будет много и между ними будет куча связей. Ты когда учишь новый язык — ты же просто привязываешь понятия из этого языка к уже имеющимся у тебя понятиям из знакомых тебе языков программирования, или создаёшь у себя новое понятие, и опять-же связываешь его со знакомыми тебе. А в процессе написания кода и использования этого нового языка — ты обнаруживаешь новые и новые связи, возможности по использованию и специфике этих новых понятий. Как сказал Фейнман — "понять — это свести к привычному, плюс умение им пользоваться". То есть ты либо сводишь понятия к знакомым тебе понятиям (которыми ты уже умеешь пользоваться), либо сделать несводимое к старому — привычным, и научиться им пользоваться.

Вот там в диссертации предложен один из подходов, как создать некую "базу знаний" о "понятиях" и их "связях", и возможность используя эту базу знаний выводить новые связи между понятиями. Как в прологе выводятся новые факты из уже имеющейся базы знаний. Ты добавляешь новое понятие или новое свойство (New), связываешь его с чем-то уже там имеющимся (Old1), и компьютер автоматически получает возможность связать это новое понятие с другими понятиями (Old2, Old2), за счёт имеющихся уже у него связей между Old1 и Old2 и Old3.

Для современых технологий, с фиксированной убогой семантикой, это в общем-то не нужно. Но если ты делаешь расширяемую систему мета-программирования, вроде SymADE или MPS или IP — то это поможет превратить такую среду/IDE из просто средства создания DSL-ей в среду которая на 90% уберёт кодирование. Так же как ты сейчас не заморачиваешься низкоуровневой оптимизацией кода на ассемблере, так через надцать лет программисты не будут заморачиваться кодированием.

Вот для этого оно нужно.

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

M>Представь себе понятие "контейнер" и "итератор". В современных языках программирования — это нечто крайне конкретное. В яве это Iteratable и Iterator интерфейсы. Если javac их встретил — он понял, что это контейнер и по нему можно итерировать специальной конструкцией языка. В C# это IEnumerable и так далее.
M>А есть в языках программирование понятие контейнера и итератора как таковое, не привязанное к конкретной реализации?
M>Сейчас — нету.
Ты будешь смеяться, но я как раз сейчас такой язык определяю и собираюсь реализовать...
Именно отсутствие обобщенного понятия "контейнер" не устраивает меня в частности и в Обероне тоже.
Причем, первый раз я написал об это еще в 95 году.
M>У тебя в мозгу все эти понятия есть. А у компьютера нету. Их туда надо вводить, и если ты будешь вводить их ad-hoc, ручками каждый случай — ты уже даже с контейнерами запаришься, настолько этих понятий будет много и между ними будет куча связей. Ты когда учишь новый язык — ты же просто привязываешь понятия из этого языка к уже имеющимся у тебя понятиям из знакомых тебе языков программирования, или создаёшь у себя новое понятие, и опять-же связываешь его со знакомыми тебе. А в процессе написания кода и использования этого нового языка — ты обнаруживаешь новые и новые связи, возможности по использованию и специфике этих новых понятий. Как сказал Фейнман — "понять — это свести к привычному, плюс умение им пользоваться". То есть ты либо сводишь понятия к знакомым тебе понятиям (которыми ты уже умеешь пользоваться), либо сделать несводимое к старому — привычным, и научиться им пользоваться.
СУПЕР!!!!
M>Вот там в диссертации предложен один из подходов, как создать некую "базу знаний" о "понятиях" и их "связях", и возможность используя эту базу знаний выводить новые связи между понятиями. Как в прологе выводятся новые факты из уже имеющейся базы знаний. Ты добавляешь новое понятие или новое свойство (New), связываешь его с чем-то уже там имеющимся (Old1), и компьютер автоматически получает возможность связать это новое понятие с другими понятиями (Old2, Old2), за счёт имеющихся уже у него связей между Old1 и Old2 и Old3.
Блин, очень напоминает Евриско Лената...

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

M>>А есть в языках программирование понятие контейнера и итератора как таковое, не привязанное к конкретной реализации?
M>>Сейчас — нету.
LVV>Ты будешь смеяться, но я как раз сейчас такой язык определяю и собираюсь реализовать...
LVV>Именно отсутствие обобщенного понятия "контейнер" не устраивает меня в частности и в Обероне тоже.
LVV>Причем, первый раз я написал об это еще в 95 году.

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

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

M>И как планируется реализовать это? Что вообще будет компилятор уметь делать с контейнерами, будет у них набор фиксированных свойств или они будут расширяемые. Или это будет просто аналог хаскелевского класса?
Не. Контейнер — это контейнер. По определению контейнер — набор однотипных элементов. Если посмотреть на стльные контейнеры, то все они имеют, в общем-то одинаковый набор операций. Разница — только в реализации.
Эффективность важна в промышленности, а для обучения эффективность не столь важна. Важно, что ученик узнает и усвоит типовые операции, которые с контейнерами работают.
Более того, в зависимоти от свойств контейнера можно разную реализацию иметь.
Например, написали, что контейнер имеет фиксированное число элементов и добавлять нельзя — это аналог массива.
А если можно добавлять элементы в конец (хотя бы и до заданной длины) — это аналог вектора или списка. А если контейнер внешний (сохраняемый) — то это аналог файла.
В общем, я сейчас озабочен не столько конкретными свойствами контейнера, сколько продумыванием и подходами к реализации семантического редактора. Чтоб не надо было набирать посимвольно.
Причем — это не макросы, хочется совсем из компилятора убрать лексический и семантический анализ и переместить его в редактор. На выходе которого — семантическое дерево программы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Здравствуйте, 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 пихать куда надо и не надо... Не выходит как-то Неизменно приходили к тому, что приходилось жертвовать всем ради универсальности, затем эта универсальность становилась никому не нужна и все использовали свои обёртки/самописные велосипеды. Могу поискать оды ассемблеру как языку для неподготовленных специалистов, что позволит решать мегаглобальные задачи не заморачиваясь кодингом машкодов...

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

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

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