Здравствуйте, Abyx, Вы писали:
A>у большинства из присутствующих здесь есть опыт обучения самого себя, в школьном/студенческом возрасте, и последующей профессиональной разработки. A>причем те, у кого это успешный опыт, умеют представление о том как и чему надо учить себя, чтобы стать профессионалом.
Теоретически, а в реальности этот опыт кроме как на себя распространить и не получается. Например не ясно откуда берется "понимание".
"Мне понятно" значит и другим понятно ? Преподавателю(тренеру, лидеру) надо избавляться от этого подхода и искать вполне конкретный якорь который мешает решить задачу.
Re[21]: Джон Кармак о науке и искусстве разработки ПО
Здравствуйте, LaptevVV, Вы писали:
A>>у большинства из присутствующих здесь есть опыт обучения самого себя, в школьном/студенческом возрасте, и последующей профессиональной разработки. A>>причем те, у кого это успешный опыт, умеют представление о том как и чему надо учить себя, чтобы стать профессионалом. LVV>Это НАИВНЫЙ взгляд на проблемы обучения. LVV>Тем более, что САМОобучение — это не обучение профи... Это — любительство.
Самообучение, как и самолечение, получается у единиц и в простых случаях. У остальных это от осложнений до летальных исходов.
Re[23]: Джон Кармак о науке и искусстве разработки ПО
Здравствуйте, LaptevVV, Вы писали:
LVV>Дык студентов банально меньше стало. В этом годе вообще закрыли только бюджетные места. LVV>И как раз отсутствие экспериментов приводит к печальной ситуации. Нынешних школьников учить методами 10-летней давности невозможно. LVV>Хотя бы потому, что 99% в школе о программировании даже не слышали, не говоря уже об изучении.
Студентов стало БОЛЬШЕ. В общей массе. В каждом из вузов — в среднем меньше. Это потому, что ИТ-специалистов начинают готовить чуть ли не гуманитарные вузы не говоря о курсах "за углом".
При этом число людей которые интересовались программированием как было, так и осталось. Т.е. соотношение технари-гуманитарии не меняется. Фокус в том, что оно всегда константа, во все времена во всех народах.
Re[10]: Джон Кармак о науке и искусстве разработки ПО
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, LaptevVV, Вы писали: LVV>>Мы, оттолкнувшись от основной идеи пошли дальше — делаем обучающую среду. Чтобы именно учить, и оценивать деятельность студентов. S>Забейте в дискуссии на язык и способ представления — поток негатива здесь перекроет все потенциальные бенефиты.
Спасибо на добром слове. S>Расскажите лучше поподробнее о том, как вы делаете "оценивание деятельности студентов". S>Скажем, почему вы отказались от олимпиадного подхода, т.е. тестирования программы как чёрного ящика?
Не отказались. Первый шаг проверки — это именно выполнение. S>Зачем вы хотите контролировать процесс написания решения, а не только результат?
Если выполнение проходит, то надо структуру программы все равно смотреть.
Сейчас это делает препод.
Почему надо обязательно смотреть струткуру. Например, задание — написать быструю сортировку.
Студень вместо реализации пишет вызов стандартной функции. Такая прога гарантировано все тесты.
Но задание-то не выполнено! S>Если вас интересует каноническое решение — то почему вы отказались от текстового сравнения с образцом?
Сейчас мы приступаем к реализации полного цикла лаб для первоначально обучения программированию — от простых линейных алгоритмов до функций.
Каждая лаба — это задание по теме, всего 20 вариантов. Задания специально делали однотипные, но разные.
Это дало возможность состряпать нечто вроде каркаса-шаблона с параметрами для результирующей программы одного варианта.
На место параметров подставляется конкретный вариант.
Таким образом, у всех студентов проги должны быть весьма похожи. И похожи на каркас-шаблон (который мы им не покажем... ).
Остается определить метрику схожести-различия, чтобы на основании получаемого измерения схожести-различия принимать решение о качестве работы студента.
Для текстового представления такую метрику подобрать сложнее. Символы — слишком координаты этой функции многих переменных.
Расстояние Левенштейна — не предлагать...
Например, имена во всех прогах будут, естественно, разные. А вот лексема — одна. Поэтому на основании лексем строить модель оценивания удобнее.
Например, сравнение с образцом. А образец — тот самый каркас-шаблон, созданный преподом.
Если прога устроена как дерево узлов, то узлов просто гораздо меньше. И для каждого узла известны его семантические составляющие.
Во-вторых появляется регулярная структура, по которой можно строить модель сравнения. S>Как именно "профессор" описывает задачи, чтобы среда потом им обучала?
Лаба готовится непосредственно в среде.
В узле-комментарии можно лепить все, что можно в RTF.
B прямо в этом доке вставляется модуль-программа. Если в ней все определено, то ее можно выполнить.
Опять же параметры не полностью определенной проги задаются узлом-комментарием.
Мы сейчас делаем простой скриптовый язык, чтобы задавать параметры. Несколько вариантов уже в качестве курсовых — писали студенты 2 курса.
Сейчас уточняем непосредственно в среде — делая доки прямо в ней.
И интерпретатор подобных узлов комментариев.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[22]: Джон Кармак о науке и искусстве разработки ПО
Здравствуйте, netch80, Вы писали:
N>И что, получается? Для всех сразу? N>Мне вот кажется, что большинству надо вначале дать набить шишки от непродуманной реализации, чтобы они поняли, что они не так делают. N>А научить этому заранее — получится далеко не для каждого.
Уже давно изобретено — обучать отталкиваясь от задач. Это есть практически в любой области, но в программировании это все еще Next Generation и обучают здесь дедовскими методами — синтаксис, синтаксис, синтаксис, еще синтаксис, снова синтаксис, обратно синтаксис, опять синтаксис и напоследок тоже синтаксис, а на закуску классика : факториал, фибоначчи, массивы и их сортировка.
В итоге Синклер первые три года, по его словам, не знал куда приспособить виртуальные методы
Re[7]: Джон Кармак о науке и искусстве разработки ПО
Здравствуйте, LaptevVV, Вы писали:
LVV>Предварительно: среда программирования с семантическим редактором. Программа в редакторе набирается не как текст, а сразу операторами. LVV>Оператор — это узел в семантическом дереве. Со всеми необходимыми составляющими. Например, узел — оператор присваивания включает имя левой переменной и присваиваемое выражение. То есть программа сразу в редакторе строится как дерево специального вида. LVV>И в чистом текстовом виде пока даже не сохраняется.
Такой подход был реализован еще в 79 году, в ZX Spectrum 16K/48K (а потом от него отказались в 128K).
Здравствуйте, LaptevVV, Вы писали:
LVV>Но у нас пока множественный возврат разрешен. LVV>Посмотрим, понаблюдаем, соберем статистику — и потом решим окончательно.
Уж коль ты сторонник минимального синтаксиса, то у запрета множественного возврата есть одна фича такого плана — можно избавиться от оператора return.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
гораздо интереснее послушать его выступление на недавнем квейкконе в оригинале. Джон на удивление хорошо (и дико долго) говорит и очень
интересные вещи рассказывает. интересно, как он готовится к таким выступлениям. видел интервью Тима Суини (это как бы конкурент Кармака) —
к сожалению, Тим слишком нервничает, когда говорит, хотя тоже много чего интересного рассказывает.
А Джон — зажог! Как смешно, он признался, что сраная темнота в Думе 3 и невозможность иметь одновременно фонарь и оружие были сделаны
им намеренно, в целях оптимизации ) (чтоб не слишком уж много теней было)
Of course, the code must be complete enough to compile and link.
Re[8]: Джон Кармак о науке и искусстве разработки ПО
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, LaptevVV, Вы писали:
LVV>>Это НАИВНЫЙ взгляд на проблемы обучения. LVV>>Тем более, что САМОобучение — это не обучение профи... Это — любительство.
I>Самообучение, как и самолечение, получается у единиц и в простых случаях.
б0льшая часть людей этим не занимается — им нужно чтобы разжевали в рот положили.
лучшие специалисты, которых я знаю — самоучки.
более того, по моему убеждению, человека в вузе нельзя ничему научить — можно только помочь научиться.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[9]: Джон Кармак о науке и искусстве разработки ПО
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, netch80, Вы писали:
N>>И что, получается? Для всех сразу? N>>Мне вот кажется, что большинству надо вначале дать набить шишки от непродуманной реализации, чтобы они поняли, что они не так делают. N>>А научить этому заранее — получится далеко не для каждого.
I>Уже давно изобретено — обучать отталкиваясь от задач. Это есть практически в любой области, но в программировании это все еще Next Generation и обучают здесь дедовскими методами — синтаксис, синтаксис, синтаксис, еще синтаксис, снова синтаксис, обратно синтаксис, опять синтаксис и напоследок тоже синтаксис, а на закуску классика : факториал, фибоначчи, массивы и их сортировка.
Вот! Именно то, от чего мы пытаемся уйти.
Синтаксис — дело вторичное — у нас 3 разных синтаксиса в среде, да еще русско-английских. И синтаксических ошибок нет — одни семантические. И программа набирается сразу семантическими единицами — операторами. А не посимвольно, да еще на английском. I>В итоге Синклер первые три года, по его словам, не знал куда приспособить виртуальные методы
Да, это нетривиальный момент, не сразу доходит при нынешнем обучении.
Поэтому и тут упор на семантику нужен — что мы и пытаемся сделать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[10]: Джон Кармак о науке и искусстве разработки ПО
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Философ, Вы писали:
Ф>>И много вы знаете преподавателей, которые что-нибудь пилят? Ф>>ПУСТЬ ПИЛЯТ!
M>Ладно бы он для себя пилил, так ведь он студентов портит.
Это вы откуда такой вывод сделали? Исходя из вашего опыта обучения?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[11]: Джон Кармак о науке и искусстве разработки ПО
> Ф>>И много вы знаете преподавателей, которые что-нибудь пилят? > Ф>>ПУСТЬ ПИЛЯТ! > > M>Ладно бы он для себя пилил, так ведь он студентов портит. > Это вы откуда такой вывод сделали? Исходя из вашего опыта обучения?
Ненависть к преподавателям остается на всю жизнь Ребята еще в каменном веке, пишут код в ноутпаде и даже о группировках блоков кода ничего не слышали
Posted via RSDN NNTP Server 2.1 beta
Забанен на рсдн за применение слова "Маргинал"
Re[9]: Джон Кармак о науке и искусстве разработки ПО
LVV>1. Язык должен быть минимален насколько возможно.
До существования процедур программы писались просто одной сплошной непрерывной функцией, с переходами внутри. Как только размеры этих программ выросли настолько что с ними стало сложно управляться, пришлось повысить уровень абстракции. Возможность обозначить одним адресом или словом, какой-то блок кода — это был прорыв. Так вошло в историю процедурное программирование. Но как только процедур стало очень много, пришлось снова повышать уровень абстракции. Интерфейс, класс, контракт — это всё на один уровень абстракции выше, и позволяет одним словом (именем класса например) обозначить группу данных и методов работы с ними. Затем всё забуксовало. Отчасти из-за того что иерархии классов формально позволяют справляться с возрастающей сложностью программ. На деле количество человеко-часов растёт существенно нелинейно с ростом сложности (в попугаях), так что очевидно что не очень-то позволяют, но лучших средств пока нету. Следующее повышение уровня абстракции это или иерархический DSL, типа того что сейчас пилят в Н2, или автоматическая верификация программ, или что-то ещё. Но это будет не минимальный язык, а язык в котором минимальной конструкцией (примерно одним словом, как было в случаях с процедурами и классами) можно описать уровень абстракции выше всех существующих.
Кстати сейчас, наверное, ежедневно появляются новые языки программирования, которые совершенно "не взлетают". А в 70-е годы создавалось не в пример меньше, но взлетали один за другим. Причина та же — современные языки по большей части повторение существующего группирования данных/методов, с вариациями синтаксиса. А нужно что-то большее.
LVV>2. Среда программирования должна мгновенно бить по рукам, если что не так. Уже при создании кода.
"Что не так" бывают разные. Синтаксис вроде всё что претендует на звание "IDE" проверяют в обязательном порядке. Кроме того вашу задачу для языков C#, VB.NET, JavaScript можно решить просто сделав аддон к решарперу, и складывая в архив полное AST программы каждый раз когда компиляция проходит успешно и программа запускается на выполнение. Так можно отследить и то как студент шёл к решению задачи и какие косяки допускал.
Re[2]: Джон Кармак о науке и искусстве разработки ПО
Здравствуйте, hi_octane, Вы писали:
_>До существования процедур программы писались просто одной сплошной непрерывной функцией, с переходами внутри.
Блоки-подпрограммы были даже в ассемблере.
_>Возможность обозначить одним адресом или словом, какой-то блок кода — это был прорыв
Не было такого прорыва. Подобная возможность появилась одновременно с возможностью писать машинный код в мнемониках и с символьными метками.
_>. Так вошло в историю процедурное программирование.
Структурное программирование это немножко про другое. Это про то чтобы явно выделить структуру программы с изоляцией пересечения границ этой изоляции. И отказ от goto.
_> Но как только процедур стало очень много, пришлось снова повышать уровень абстракции. Интерфейс, класс, контракт — это всё на один уровень абстракции выше
Интерфейс ака контракт это тоже из другой оперы, это элемент дизайна, и он есть не только в ООП, но даже и в ассемблере. И изначально появились вовсе не классы, а модули (см. Паскаль, Модулу). А объекты совсем по иной причине появились, и позже модулей.
Вобщем, ты все очень сильно примитивизируешь, подгоняя факты под теорию.
_>А в 70-е годы создавалось не в пример меньше, но взлетали один за другим.
Ты заблуждаешься. Попробуй найти/посчитать конкретные цифры.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
_>>До существования процедур программы писались просто одной сплошной непрерывной функцией, с переходами внутри. AVK>Блоки-подпрограммы были даже в ассемблере.
Ассемблер — это уже достаточно поздняя инновация.
_>>Возможность обозначить одним адресом или словом, какой-то блок кода — это был прорыв AVK>Не было такого прорыва. Подобная возможность появилась одновременно с возможностью писать машинный код в мнемониках и с символьными метками.
Заблуждаешься. Средство "отложить" контекст в виде адреса исполнения и потом вернуться к отложенному — это ещё первые архитектуры 50-х годов, задолго до того, как стала окупаться машинная интерпретация автокода (предок ассемблера). Разумеется, выглядело оно по современным меркам диковато (хотя и сейчас в RISC'ах подходы ближе к древним образцам, из-за экономии операций).
_>>. Так вошло в историю процедурное программирование. AVK>Структурное программирование это немножко про другое.
Ты действительно не увидел, что слово было "процедурное", а не "структурное"?
Или решил потроллить?
_>> Но как только процедур стало очень много, пришлось снова повышать уровень абстракции. Интерфейс, класс, контракт — это всё на один уровень абстракции выше AVK>Интерфейс ака контракт это тоже из другой оперы, это элемент дизайна, и он есть не только в ООП, но даже и в ассемблере.
Это сейчас можно говорить "интерфейс aka контракт". Раньше между ними не было ничего общего. Понятие "контракт" в виде отдельных "предусловий", "постусловий", "инвариантов" оформилось только в 60-х и стандартизировало, AFAIK, Дейкстрой.
AVK> И изначально появились вовсе не классы, а модули (см. Паскаль, Модулу).
"Изначально" были подпрограммы и элементарные команды. Модули выполняют другие задачи, для которых сокрытие реализации — не самое главное.
AVK>Вобщем, ты все очень сильно примитивизируешь, подгоняя факты под теорию.
_>>А в 70-е годы создавалось не в пример меньше, но взлетали один за другим. AVK>Ты заблуждаешься. Попробуй найти/посчитать конкретные цифры.
Тут единственное, с чем согласен. Именно создание новых языков в 70-80-е было модным и было огромное количество "стартапов", которые не ушли дальше пары статей.
) (чтоб не слишком уж много теней было)
