Comments 67
Это вы еще в шоколаде. Мне пришлось вначале за свои деньги (правда заработанные в универе) покупать платы для лаб, а потом за счет моей конторы в которой я работаю. Зато теперь каждый год — договор о безвозмездной передаче новых плат и там всякой обвески делаем для универа.
Зато мой курс, самый оборудованный — платы раздал на руки студентам, и поэтому удаленно точно также, как и не удаленно, все транслирую им через университетскую систему (все сделано с умом — удобно), потом каждого прошу показать, что они делают… и каждому поясняю ошибки — 15 человек нормально, 20 уже конечно тяжеловато, но обычно, человек 5 нет всегда. Так что 15 — успеваю каждого проверить.
Рабочая программа — да, но так нужно, иначе как понять, что вы даете и собираетесь дать и зачем это нужно. Она обычно один раз в год обновляется.
По поводу посещаемости — и активности, у меня системы кармы + в электронном университете всякие значки есть, можно выписывать особо отличившимся. В любом случае, кому это не надо — зачет и экзамен не сдадут. (А кто не сдает, там бывает родители звонят(не знаю, как телефон находят), и по разному бывает, например, говорят, что у них никто в роде до этого высшего образования не получал и мол это единственный, кто в люди может выбиться. Я обычно конечно посылаю — система электронная, экзамен сдаешь прямо в системе — ей никак теперь не наплакать, но иногда кафедра сама просит, чтобы пересдавали ребята, так как иначе будет минус кафедре при аттестации, мол все предметы на 5, а этот как то не задался...)
Лабы сдают через гит в *.adoc формате — в универ только на знакомство ездил на первую лекцию.
Вроде нормально получается, конечно очно все лучше, но и удаленно нормально.
Я на рабочую программу и не жаловался, документ понятный, нужный, пусть и объёмный. Это как раз очень порадовало, что программа — фактически единственная "бумажка".
Про посещаемость да, но всё же оставлять всё на самодисциплину неправильно. Не всем хватает мотивации, и если правильно "помочь" организоваться, то результаты будут лучше. Не поделитесь опытом, за что поднимаете и понижаете карму? Работает как элемент геймификации или наоборот школьного журнала?
Ну а истории про то, как просят кому-то что-то поставить и у меня появились. Я боялся, что их будет даже больше, но пока всё в рамках разумного. Родители к счастью ещё ни разу не звонили.
Работает как элемент геймификации или наоборот школьного журнала?
Есть и элемент игры, например, даю примеры — надо найти ошибку, кто нашел, тому значок. Либо кто-то показывает свою работу — нужно указать на то, что можно в ней улучшить, сделать оптимальнее, кто больше всех предложений дал — тому значок. Иногда на скорость даю делать одно и то же задание, например.
Как минимум со значками проще допуститься до зачета и экзамена, но еще я разыгрываю всякие небольшие призы, типа Набор ручек от моей конторы, головоломок, сувениров ну и так далее за наибольшее количество значков.
Еще каждому на следующую лекцию даю задание по небольшой презентации на какую-нибудь связанную тему, которую прошли только очень вскользь. И каждый из учеников должен за семестр доложиться перед всеми так, чтобы его поняли, 15 минут на каждой лекции этому посвящаем. Например, вскользь сказал им про конвейер, что микроконтроллер выполняет команды используя 4 ступенчатый конвейер, немного сказал что это значит, а на дом дал сделать презентацию и подробно описать принц работы конвейера. Вот один из студентов это и докалывает.
Не поделитесь опытом, за что поднимаете и понижаете карму?
Например, Лабораторная не сдана вовремя — карма -1.
Проверяем задание, нечего показать (ничего не делает) — карма -1.
Не сделал презентацию, которую должен был сделать — карма -1
Посещение оно само отмечается при удаленной лекции — 2 раза пропустил, карма -1.
Ну и так далее, "-10" — карма слита, и можно даже не стараться зачет сдавать.
Плюсов обычно в карму нет.
Плюсов обычно в карму нет.Прямо как на хабре)
Ручки и мёрч от компании это интересно. Видимо ваш работодатель возлагает какие-то надежды на выпускников? К себе работать зовёте?
Я планировал и всё ещё хочу так делать, но пока не получается. В этом году знакомство с группой началось с вопроса от них, можно ли на стажировку, так что может быть удача наконец-то улыбнётся.
Ручки и мёрч от компании это интересно. Видимо ваш работодатель возлагает какие-то надежды на выпускников? К себе работать зовёте?
Да так и есть, вначале на стажировку 2 года — пока они в магистратуре учатся. У меня 4 курс бакалавриата, я как раз там выбираю 2-3 на стажировку, а с неё уже как получится.
Простите, в каком ВУЗе Вы преподаете? Мне чтоб знать куда детей отправлять ))
А пробовали спросить студентов прошедших курс два года назад, как у них сложилось с программированием и что они помнят из курса?
Нет. После экзамена с ними не общался. Очной связи с ними нет, других предметов я не веду, но есть групповая почта. Они сейчас должны были закончить бакалавратуру, то есть фактически выпустились, но попробую. Ну и ближе к концу года можно подобное закинуть группе прошлого года. Действительно было бы интересно узнать результаты и отношение спустя два года.
Вопрос не мне, но я могу по своему опыту ответить. Для аттестации кафедры каждые 3 года вроде бы, делается опрос выпускников — определенный процент выпустившихся должен работать по специальности, у них делают официальный опрос: На сколько вам пригодились знания, полученные по специальности, какие конкретно предметы. Даже приезжала из Европы тетенька опрашивала пару моих бывших студентов. Кого опрашивала — у тех порядок с программированием. Но точный процент сказать трудно. Думаю, что как минимум половина выпустившихся дружат с программированием в той или иной степени.
Другой вопросы, что прошлый выпуск, например, был всего 8 человек. Остальные 12 или даже 14 были отсеяны за 4 года. А в Магистратуру идут уже вообще единицы, по-моему из 8 только 2 пошли.
На мой взгляд — вы большой молодец! Всегда приятно видеть преподавателя, который знает, чему учит, и болеет за свое дело!
Нужен промежуточный контроль успеваемости. То есть не просто того факта, что люди учатся, а того, насколько они понимают программу. Я сводил всё к выполнению одной работы и отчёту в конце семестра, из-за этого терял тех, кто что-то не уловил на середине. Это можно было понять гораздо быстрее. Кто-то спросит, какие-то вопросы всплывают в личном общении на практике, но кто-то молчит.
Я поэтому даю несколько домашек в течении семестра, с дедлайнами (прошляпил дедлайн — максимальные баллы медленно сгорают).
Так сразу пропадает соблазн отложить все на последнюю неделю, вынуждает что-то делать в течении семестра.
И по нескольким домашкам потом провожу "защиты" один на один, чтобы можно было какие-то вопросы поднять.
Так нагрузки на меня несколько больше, больше проверять приходится — но это я частично решил тестами, по крайней мере корректную работу кода вручную проверять уже не надо.
А курсовой проект предлагаю по желанию (вместо домашек) уже во втором семестре, для тех, кто ощущает себя в силах.
Я пробовал решить это предложением писать вопросы в любое время, а не во время пар, надеясь, что смогу помочь тогда, когда они реально пишут код. Но нет, это сработало только для 2-3 человек. Остальным помочь не смог.
Я в принципе стараюсь сразу донести до всех мысль — пишите вопросы в любое время, отвечу так быстро, как смогу — но первые месяца два-три все равно пишут редко. Слишком непривычно, что преподаватель отвечает.
Возможно, если создать групповой чат в телеге или дискорде каком-нибудь, будут спрашивать более охотно.
А почему именно D? Ну, допустим с с/с++ всё действительно сложновато, но тогда можно и rust. Чем D, будучи языком с GC, превзошел Java/C#/Go? А если забивать на работу с памятью, то почему не тот же python? Почему в вузах так любят языки, которые никому никогда не пригодятся?
Один из ответов может выглядеть так: университет — это место, где дают фундаментальные знания, и возможно D как раз подходит под какую-то из задач в каком-нибудь курсе.
Например, ООП, шаблонное метапрограммирование, какое-то понятие о суперкомпиляции можно давать на примере D.
Плюс есть определённая доводы к тому, что студенты не нагуглят решения, а попытаются сделать домашки самостоятельно.
Существенная доля ответов есть в статье, но постараюсь ответить подробнее.
Лично мне D просто нравится. Я продуктивнее пишу на D, чем на C++, Perl или JS, и похоже это не только субъективное восприятие, а свойство языка. Почему именно на этой кафедре решили преподавать именно этот язык, история сложная и для меня до сих пор целиком не известная.
Я понимаю, что GC делает язык похожим на другие языки со сборщиком мусора, но это иллюзия. В D гораздо больше из мира C++ и Rust, чем из C# или Java. Банально сравните производительность, граммотный D на голову обходит любые VM языки или тот же Go. В задачах, когда из процессора действительно нужно выжать всё, D не уступает и часто лидирует в сравнении с C и Rust. И это очень важно понять, что удобство не всегда достаётся ценой производительности.
В вузе надо учиться программировать и изучать концепции, а не практиковаться в чём-то одном. Вуз не должен выпускать программистов на Go, он должен выпускать образованных людей. После D вы сможете относительно просто перейти и на C++, и на C# и на Go, а вот обратное не верно. Этот язык богат на подходы, при этом прост в изучении основ. Кроме того кругозор позволяет видеть абстракции, а не конкретные синтаксические конструкции. На примере D хорошо объяснять программирование контрактное, функциональное, многопоточное, метапрограммирование. Как вы сможете донести саму идею zero cost (бесплатных) абстракций на примере Java, где их фактически не существует? А ведь это важная идея, которую продвигает тот же Rust.
И да, если бы я оценивал свой уровень владения Rust достаточным, то я бы предложил преподавать его. Имхо, в нём одна интересная мысль, но она действительно стоит того. Вот только я знаю D, а не Rust. Ну и кстати, в D тоже появляется анализ времени жизни и зарождается borrow checker. И если они доведут его до кондиции, решив все проблемы удобства и совместимости, то лет через 6 мы увидим его в C++, поверьте.
Лично мне D просто нравится. Я продуктивнее пишу на D, чем на C++, Perl или JS, и похоже это не только субъективное восприятие, а свойство языка. Почему именно на этой кафедре решили преподавать именно этот язык, история сложная и для меня до сих пор целиком не известная.
Я понимаю, что GC делает язык похожим на другие языки со сборщиком мусора, но это иллюзия. В D гораздо больше из мира C++ и Rust, чем из C# или Java. Банально сравните производительность, граммотный D на голову обходит любые VM языки или тот же Go. В задачах, когда из процессора действительно нужно выжать всё, D не уступает и часто лидирует в сравнении с C и Rust. И это очень важно понять, что удобство не всегда достаётся ценой производительности.
В вузе надо учиться программировать и изучать концепции, а не практиковаться в чём-то одном. Вуз не должен выпускать программистов на Go, он должен выпускать образованных людей. После D вы сможете относительно просто перейти и на C++, и на C# и на Go, а вот обратное не верно. Этот язык богат на подходы, при этом прост в изучении основ. Кроме того кругозор позволяет видеть абстракции, а не конкретные синтаксические конструкции. На примере D хорошо объяснять программирование контрактное, функциональное, многопоточное, метапрограммирование. Как вы сможете донести саму идею zero cost (бесплатных) абстракций на примере Java, где их фактически не существует? А ведь это важная идея, которую продвигает тот же Rust.
И да, если бы я оценивал свой уровень владения Rust достаточным, то я бы предложил преподавать его. Имхо, в нём одна интересная мысль, но она действительно стоит того. Вот только я знаю D, а не Rust. Ну и кстати, в D тоже появляется анализ времени жизни и зарождается borrow checker. И если они доведут его до кондиции, решив все проблемы удобства и совместимости, то лет через 6 мы увидим его в C++, поверьте.
В задачах, когда из процессора действительно нужно выжать всё, D не уступает и часто лидирует в сравнении с C и Rustкажется, это даже чисто теоретически невозможно, а в этом замечательном докладе вы можете ознакомиться с причинами.
В вузе надо учиться программировать и изучать концепции, а не практиковаться в чём-то одномДа, вы правы. Однако «изучить концепцию и полезный навык» всегда будет лучше чем просто «изучить концепцию». По той же самой причине я критикую преподавание pascal/basic — они может и подходят для обучения, но почти бесполезны как навыки. А еще, изучение практических навыков в вузе нужно для того, чтобы выпускники не оказывались оторваны от реальности.
Как вы сможете донести саму идею zero cost (бесплатных) абстракций на примере Java, где их фактически не существует?А как можно изучать управление памятью на примере языка с GC? Универсальной технологии тут нет и не будет. Студентам чисто IT специальностей имеет смысл дать сразу несколько ЯП (например алгоритмы/структуры данных на си/плюсах, немного асма, архитектуру/паттерны на java, предметное типа обработки изображений/ML — python), а вот для инженеров непрограммерских специальностей наверно стоит советовать что-то более распространенное в индустрии. Скажем, радиотехникам python ну вот совсем не упал, D впрочем тоже.
кажется, это даже чисто теоретически невозможно
Если Вы о сборщике мусора (по ссылке по крайней мере про него), то в D можно его не использовать. Хоть обширная часть стандартной библиотеки и написана с его применением, но все же никто не мешает программировать без этого, и более того, доступен специальный атрибут @nogc, который заставит компилятор ругаться каждый раз когда происходит выделение памяти через GC.
То есть формально D в настоящее время — это универсальный инструмент и для низкого уровня, и для абстрактной логики, поэтому неудивительно что автор использует его для обучения концепциям программирования.
Так что не вижу ни теоретической, ни практической невозможности, тем более что код генерируется одними и теми же бэкендами (GCC и LLVM)
Ручное управление памятью в D есть, и это отвечает на оба ваших вопроса. Ничего не мешает вообще использовать только C подмножество, будет всё то же самое, но удобнее за счёт фич этапа компиляции.
А к докладу Антона Полухина, который вы скинули, я бы хотел добавить, что любое управление памятью имеет накладные расходы. malloc требует дополнительного места под размер, имеет избыточное потребление для маленьких объектах на многих реализациях, и вообще не быстр, иначе не появились бы альтернативы и ручные аллокаторы. Любое выделение памяти не бесплатно, любой контроль за используемой памятью, GC, счётчик ссылок или дерево владения из Qt, вносит накладные расходы. Тот же Rust при всеобъемлющем контроле за временем жизни всё равно предлагает счётчик ссылок для динамики. А есть ситуации, когда RC медленнее, чем GC.
Поэтому важны настоящие zero cost абстракции, которые позволят вообще не выделять память, коих в D хватает. Например ленивые диапазоны (моя статья на хабре). После выхода C++20 выглядит банально, вот только как Ranges туда попали? Eric Niebler напрямую ссылался на D в объяснениях. И я считаю такие вещи важнее, чем встроенный в язык GC.
А к докладу Антона Полухина, который вы скинули, я бы хотел добавить, что любое управление памятью имеет накладные расходы. malloc требует дополнительного места под размер, имеет избыточное потребление для маленьких объектах на многих реализациях, и вообще не быстр, иначе не появились бы альтернативы и ручные аллокаторы. Любое выделение памяти не бесплатно, любой контроль за используемой памятью, GC, счётчик ссылок или дерево владения из Qt, вносит накладные расходы. Тот же Rust при всеобъемлющем контроле за временем жизни всё равно предлагает счётчик ссылок для динамики. А есть ситуации, когда RC медленнее, чем GC.
Поэтому важны настоящие zero cost абстракции, которые позволят вообще не выделять память, коих в D хватает. Например ленивые диапазоны (моя статья на хабре). После выхода C++20 выглядит банально, вот только как Ranges туда попали? Eric Niebler напрямую ссылался на D в объяснениях. И я считаю такие вещи важнее, чем встроенный в язык GC.
я бы хотел добавить, что любое управление памятью имеет накладные расходы. malloc… и вообще не быстрвсе эффективные оптимизации аллокации уже реализованы в malloc. Оптимизировать дальше можно лишь за счет существенного увеличения объемов потребляемой памяти.
иначе не появились бы альтернативы и ручные аллокаторыальтернативные аллокаторы это не всегда про быстродействие и не всегда про выделение памяти из кучи. Чаще всего — про осознанный размен потребления памяти на проценты быстродействия.
Тот же Rust при всеобъемлющем контроле за временем жизни всё равно предлагает счётчик ссылок для динамикину вы будете его использовать только там, где без него совсем никак — в случаях раздельного владения объектом между потоками. В таких ситуациях и GC без атомиков не справится.
все эффективные оптимизации аллокации уже реализованы в malloc.Все эффективные оптимизации на общий случай реализованы в malloc. Всегда есть частный случай, который может быть быстрее. Тот же malloc не располагает кучей данных, которые есть у GC — априорное знание о размерах объектов, например.
ну вы будете его использовать только там, где без него совсем никак — в случаях раздельного владения объектом между потокамиИ RC нужен не только для многопоточности. Растовский rc::Rc наоборот не атомарен и должен использоваться только в одном потоке. Общее владение ресурсом так или иначе приводит к счётчику ссылок, сборке мусора или ошибкам и утечкам. Выбирайте. Здорово, когда можно не выбирать и использовать только одиночное эксклюзивное владение, но это же не всегда возможно даже в Rust.
Все эффективные оптимизации на общий случай реализованы в malloc. Всегда есть частный случай, который может быть быстрее.ну у вас программа же не из единого частного случая состоит, там аллокатор настолько же общего назначения. Знание размера типа может помочь убрать пару из аллокации/деаллокации совсем, но едва ли ускорит саму аллокацию. Вы же не будете инстанцировать аллоцирующий метод для каждого из потенциальных размеров данных?
Растовский rc::Rc наоборот не атомарен и должен использоваться только в одном потокеда, перепутал с Arc. Обычный Rc во-первых сравнительно редко используется*, а во-вторых, его накладные расходы минимальны и уж точно не выше таковых у GC.
* Лично я за свою карьеру на плюсах использовал неатомарный refcounting единожды. Возможно, в расте его используют почаще — чтобы обойти некоторые ограничение borrow checker'а без unsafe, но думаю всё равно редко
Обычный Rc во-первых сравнительно редко используется*, а во-вторых, его накладные расходы минимальны и уж точно не выше таковых у GC.
Ну, не совсем. Счётчики сильных и слабых ссылок — это +2 машинных слова к каждой аллокации в Rc. Кэш из-за них страдает, особенно, если данные маленькие лежат. Уничтожение одной структуры в Rc может привести по цепочке к уничтожению Rc, которые тот объект держал, и глубина вложенности может быть произвольной. Деструктор Rc работает на том же потоке, что и остальная часть программы, так что пока деструктор обходит граф объектов, программа ничего полезного не делает. Клонирование, опять-таки, хоть и дешёвое, но всё же дороже просто копирования указателя.
Это всё проблемы, которых лишён хороший сборщик мусора. Вдобавок он ещё и может нормально циклы владеющих ссылок разрулить, которые при помощи Rc нужно разбивать руками с использованием слабых ссылок.
во-первых, как я уже сказал, Rc почти никогда не нужен, поэтому его влияние на производительность минимально даже если бы оверхед был значительным.
Счётчики сильных и слабых ссылок — это +2 машинных слова к каждой аллокации в Rc. Кэш из-за них страдает, особенно, если данные маленькие лежат.для функционирования GC нужно в каждой аллокации размещать объект со всеми ссылками. В общем случае это куда больше двух машинных слов.
Уничтожение одной структуры в Rc может привести по цепочке к уничтожению Rc, которые тот объект держал, и глубина вложенности может быть произвольной. Деструктор Rc работает на том же потоке, что и остальная часть программы, так что пока деструктор обходит граф объектов, программа ничего полезного не делает.значит когда на многоядерной машинке одно ядро чистит свои ресурсы, то это «программа ничего не делает», а во время stop the world вот прямо таки блещет производительностью. Ах, да, бывают же многопоточные GC без stop the world, которые работают… на атомарном рефкаунтинге.
Клонирование, опять-таки, хоть и дешёвое, но всё же дороже просто копирования указателя.в большинстве случаев это мув.
Это всё проблемы, которых лишён хороший сборщик мусораэто все проблемы, которых сборщик мусора не только не лишен, а которые в нем гиперболизированы
Вы куда то далеко от темы топика уехали.
Раст настолько «не такой как все», что его учить в универе просто вредно.
Разве что в конце обучения на спецкурсе наравне с Лентой Тьюринга и Брейнфаком.
Раст настолько «не такой как все», что его учить в универе просто вредно.
Разве что в конце обучения на спецкурсе наравне с Лентой Тьюринга и Брейнфаком.
От темы и правда ушли, тут GC, ниже GUI, но вы попали в больное место, не могу молчать.
Rust, Машина Тьюринга и Brainfuck — те вещи, знакомство с которыми я считаю необходимыми для современного образованного программиста. Rust, чтобы увидеть, как бывает всё не так и это здорово. Машина Тьюринга вместе с задачей останова просто для понимания пределов программирования. Меня поражает как мало людей не понимают, что нельзя в общем случае написать программу, которая идеально проинспектирует другую программу. А Brainfuck для демонстрации абсолютно чистого программирования, кода самого в себе. Его простота и полнота завораживает и заставляет относиться к компьютеру по-другому.
И всё это не важно в каком порядке и когда. Rust разве что только после становления хотя бы как начинающего программиста. Чтобы видеть контраст, нужно видеть фон.
Rust, Машина Тьюринга и Brainfuck — те вещи, знакомство с которыми я считаю необходимыми для современного образованного программиста. Rust, чтобы увидеть, как бывает всё не так и это здорово. Машина Тьюринга вместе с задачей останова просто для понимания пределов программирования. Меня поражает как мало людей не понимают, что нельзя в общем случае написать программу, которая идеально проинспектирует другую программу. А Brainfuck для демонстрации абсолютно чистого программирования, кода самого в себе. Его простота и полнота завораживает и заставляет относиться к компьютеру по-другому.
И всё это не важно в каком порядке и когда. Rust разве что только после становления хотя бы как начинающего программиста. Чтобы видеть контраст, нужно видеть фон.
кажется, это даже чисто теоретически невозможно, а в этом замечательном докладе вы можете ознакомиться с причинами.
этом замечательном докладе
Что-то я не разделяю ваших восторгов.
Самое интересное в программировании, на мой взгляд, это кодирование пользовательского интерфейса. Для С++ используются такие фреймворки, как Qt, wxWidgets, Win32++, WTL / ATL и т.п.
Программированию интерфейсу, как таковому, уделяется слишком мало внимания. Соответственно, как только сталкиваешься с реальной задачей, так сразу возникает куча проблем на ровном месте. Как сделать то, это и другое. Общий подход, что позволяет делать официальный фреймворк, то и делай, все остальное от лукавого. Подход, почти как в «1С» – ешьте, что дают и, смотрите, не обляпайтесь.
Но ведь С++ это фундаментальный язык, поэтому с ограничениями фрейморков можно согласиться, только если это высокоуровневые платформы, типа Qt и wxWidgets. Но WTL, скажем, это почти уровень WinAPI, так что его ограничения трудно принять.
Возьмем, например, парадигму MDI. Не знаю, с какого бодуна, наверное, еще со времен Windows-3.1, но существует запрет, на уровне системных dll, использования локального меню в дочерних MDI-окнах. Вот народ и изгаляется. Создает контекстное меню, кнопочное меню, командные бары и панели, панельное меню и даже html-окна с меню в виде ссылок. Хорошей иллюстрацией этого служат разные версии продуктов 1С77-1С8х.
Что толку в новом языке, если он будет поддерживать подобные ограничения.
Хорошо, идем дальше. Вот язык D демонстрирует работу в консольных окнах. Замечательно! Но нам надо оконный интерфейс, запускаемый в консоли. При этом происходит мигание консольного окна перед созданием GUI. В С++ проблема решается разными точками входа. Вместо консольного main() используется графическая WinMain() и все хорошо, пока это возможно. Но возьмем, для примера, консольный опенсорный видеоплейер FFPlay.c. Замечательная программа, но использует окна из SDL фреймворка, а те просто не работают, по определению, с WinMain(), только с main(). Соответственно, с графическим окном видеоплейера болтается рядом консольное окно, которое нам, в принципе, не нужно. Да, его можно удалить с помощью вызова FreeConsole(), но мигание останется, что выглядит очень непрофессионально.
Те же эксперименты с видеоплейером FFPlay.c, в программе с графическим пользовательским интерфейсом, ненавязчиво подводят нас к GUI-шной мультипоточности. И опять, хороших примеров подобной связки в Интернете нет. А если использовать адаптированный код работы с потоками мастера Multi-SDI из WTL, то упираемся в ограничение данной модели мультипоточности, связанной с невозможностью реструктуризировать Си код в код С++ (проще говоря, переписать FFPlay.c в виде классов).
После долгой возни со всеми описанными проблемами их, в конечном счете, можно решить на приемлемом уровне. Но это все как бы достаточно стандартные вещи, а не какие-то там изобретения, но народ почему-то к интерфейсу пользователя относится по остаточному принципу. Есть, хорошо, нет – обойдемся. Но, то что простительно для концепции «1С» не слишком подходит к С++ или там другим новомодным языкам программирования.
И последний момент, которой не способствует особому интересу к «D», как к «C++ сделанному правильно». Это опенсорс. Когда будет приемлемый опенсорс на «D», тогда и посмотрим.
Программированию интерфейсу, как таковому, уделяется слишком мало внимания. Соответственно, как только сталкиваешься с реальной задачей, так сразу возникает куча проблем на ровном месте. Как сделать то, это и другое. Общий подход, что позволяет делать официальный фреймворк, то и делай, все остальное от лукавого. Подход, почти как в «1С» – ешьте, что дают и, смотрите, не обляпайтесь.
Но ведь С++ это фундаментальный язык, поэтому с ограничениями фрейморков можно согласиться, только если это высокоуровневые платформы, типа Qt и wxWidgets. Но WTL, скажем, это почти уровень WinAPI, так что его ограничения трудно принять.
Возьмем, например, парадигму MDI. Не знаю, с какого бодуна, наверное, еще со времен Windows-3.1, но существует запрет, на уровне системных dll, использования локального меню в дочерних MDI-окнах. Вот народ и изгаляется. Создает контекстное меню, кнопочное меню, командные бары и панели, панельное меню и даже html-окна с меню в виде ссылок. Хорошей иллюстрацией этого служат разные версии продуктов 1С77-1С8х.
Что толку в новом языке, если он будет поддерживать подобные ограничения.
Хорошо, идем дальше. Вот язык D демонстрирует работу в консольных окнах. Замечательно! Но нам надо оконный интерфейс, запускаемый в консоли. При этом происходит мигание консольного окна перед созданием GUI. В С++ проблема решается разными точками входа. Вместо консольного main() используется графическая WinMain() и все хорошо, пока это возможно. Но возьмем, для примера, консольный опенсорный видеоплейер FFPlay.c. Замечательная программа, но использует окна из SDL фреймворка, а те просто не работают, по определению, с WinMain(), только с main(). Соответственно, с графическим окном видеоплейера болтается рядом консольное окно, которое нам, в принципе, не нужно. Да, его можно удалить с помощью вызова FreeConsole(), но мигание останется, что выглядит очень непрофессионально.
Те же эксперименты с видеоплейером FFPlay.c, в программе с графическим пользовательским интерфейсом, ненавязчиво подводят нас к GUI-шной мультипоточности. И опять, хороших примеров подобной связки в Интернете нет. А если использовать адаптированный код работы с потоками мастера Multi-SDI из WTL, то упираемся в ограничение данной модели мультипоточности, связанной с невозможностью реструктуризировать Си код в код С++ (проще говоря, переписать FFPlay.c в виде классов).
После долгой возни со всеми описанными проблемами их, в конечном счете, можно решить на приемлемом уровне. Но это все как бы достаточно стандартные вещи, а не какие-то там изобретения, но народ почему-то к интерфейсу пользователя относится по остаточному принципу. Есть, хорошо, нет – обойдемся. Но, то что простительно для концепции «1С» не слишком подходит к С++ или там другим новомодным языкам программирования.
И последний момент, которой не способствует особому интересу к «D», как к «C++ сделанному правильно». Это опенсорс. Когда будет приемлемый опенсорс на «D», тогда и посмотрим.
У D действительно не так много библиотек как у C/C++. Но любые С либы можно использовать в D т.к. этот язык ABI совместим с С, а чтобы импортировать C функцию достаточно одной строки: extern© int brk(void* address), все теперь вы можете использовать brk в своем D коде. D также имеет хорошую совместимость с С++ (читайте их туториал).
Что касается опенсорсных библиотек, веб фреймворк vibe.d и mir-algorithm приходят на ум. У D около 1.8к пользовательских библиотек, не говоря об очень большой стандартной библиотеке. D используют в проде, движок к игре Quantum Break был написан на D, высокопроизводительная файловая система от Weka.io написана на D и много еще чего, что мне просто лень тут перечислять. Зайдите на D сайт и посмотрите. В Мюнхене например он довольно популярен и тут есть 3 большие компании, которые используют его в проде. Тут же и проводятся митапы по D. Несомненно, это не очень популярный язык и найти с ним работу крайне сложно. Но ведь у вас цель не работу искать, а расширять собственный кругозор ;)
Что касается опенсорсных библиотек, веб фреймворк vibe.d и mir-algorithm приходят на ум. У D около 1.8к пользовательских библиотек, не говоря об очень большой стандартной библиотеке. D используют в проде, движок к игре Quantum Break был написан на D, высокопроизводительная файловая система от Weka.io написана на D и много еще чего, что мне просто лень тут перечислять. Зайдите на D сайт и посмотрите. В Мюнхене например он довольно популярен и тут есть 3 большие компании, которые используют его в проде. Тут же и проводятся митапы по D. Несомненно, это не очень популярный язык и найти с ним работу крайне сложно. Но ведь у вас цель не работу искать, а расширять собственный кругозор ;)
У D действительно не так много библиотек как у C/C++. Но любые С либы можно использовать в D т.к. этот язык ABI совместим с С
А зачем? Я не хочу Си, я хочу С++. Для меня это идеальный язык программирования. Зачем мне «умножать сущности без необходимости»?
Что касается опенсорсных библиотек, веб фреймворк vibe.d и mir-algorithm приходят на ум. У D около 1.8к пользовательских библиотек, не говоря об очень большой стандартной библиотеке.
Вы меня сможете заинтересовать, если покажите пример опесорса, типа «2С» (достаточно одного только интерфейса, без содержательной части), но сделанного красиво и удобно. Главные требования: MDI, закладки (табы) окон, грид (форма списка), поддерживающий группы элементов, как в 1С77 и согласованный с деревом (TreeView), удобные настраиваемые панели инструментов, а также полноценные локальные меню в дочерних окнах, поддержка ГУИ-шной мультипоточности и т.п.
Вы сами только что ответили «Я не хочу Си, я хочу С++.». Я не смогу вас убедить.
Я лишь прокомментирую «Зачем мне «умножать сущности без необходимости»?». Это надо делать, чтобы быть профессионалом. Недостаточно знать один язык, надо знать около 5 языков. И это не мои слова, а слова Страуструпа. У D есть много интересных решений, которые сделают вас лучшим специалистом, особенно, если вы пишете код на С/С++.
Я лишь прокомментирую «Зачем мне «умножать сущности без необходимости»?». Это надо делать, чтобы быть профессионалом. Недостаточно знать один язык, надо знать около 5 языков. И это не мои слова, а слова Страуструпа. У D есть много интересных решений, которые сделают вас лучшим специалистом, особенно, если вы пишете код на С/С++.
Вы сами только что ответили «Я не хочу Си, я хочу С++.». Все дальнейшие разговоры непродуктивны, как и непродуктивны выши комментарии к данному посту.
Претензия ко всем туториалам, для начинающих, это увлечение консольными приложениями в ущерб оконным. Зачем ломиться в открытую дверь? С консольным программированием нет проблем, когда примеров учебного кода порядка 99%. Если бы ваш любимый «D» дал бы примеры нетривиального подхода к программированию пользовательского интерфейса, то это было бы интересно всем, кому уже надоела консоль.
Я лишь прокомментирую «Зачем мне «умножать сущности без необходимости»?». Это надо делать, чтобы быть профессионалом. Недостаточно знать один язык, надо знать около 5 языков.
А кто вас сказал, что я не знаю «5 языков»? Пожалуйста, Ассемблер (MASM-32) (можете посмотреть мои статьи на erfaren.narod.ru ), Object Professional (Pascal), Adobe Action Script (AS3) ( scholium.webservis.ru ), Visual FoxPro 9 и C++ (с фреймворками), наконец. Кстати, кормит меня 1С и VFP-9.
А С++ это язык для удовольствия.
У D есть много интересных решений, которые сделают вас лучшим специалистом, особенно, если вы пишете код на С++.
Интересного есть много где. Мои задачи мне поможет решить С++ / WTL, а не «D». А курс «Программирование пользовательского интерфейса на С++ / WTL / ATL» в университете, не исключено я буду вести лично, благо образование позволяет.
А курс «Программирование пользовательского интерфейса на С++ / WTL / ATL» в университете, не исключено я буду вести личноОбязательно напишите про то, что у вас получится, с удовольствием почитаю про ваш опыт. Серьёзно, без подколок и сарказма. Разнообразие это очень хорошо.
А кто вас сказал, что я не знаю «5 языков»? Пожалуйста, Ассемблер (MASM-32) (можете посмотреть мои статьи на erfaren.narod.ru ), Object Professional (Pascal), Adobe Action Script (AS3) ( scholium.webservis.ru ), Visual FoxPro 9 и C++ (с фреймворками), наконец. Кстати, кормит меня 1С и VFP-9.Могу только пособолезновать такому жизненному пути (
Не зная даже названия ЯП....(Object Professional)
Могу только пособолезновать такому жизненному пути (
Сейчас актуальны искусственный интеллект и 3d-моделирование. Вы занимаетесь этими вещами? Нет? Тогда тоже сочувствую. Какие такие собственные преимущества вы имеете в виду?
Не зная даже названия ЯП....(Object Professional)
О! Это очень прикольная штука на заре заката MS-DOS. DOS уже уходил в небытие и фирмы спешно продавали исходный код своих программ за символические деньги (до этого библиотека распространялась только в бинарниках). Мы купили эти исходники и я даже успел наваять одну серьезную программу. Object Professional поддерживала работу резидентных программ и доступ к расширенной памяти, что во времена MS-DOS было очень актуально. Получалось очень круто по тем временам, но вскоре пришла Windows 95/98 и DOS стал постепенно отмирать.
А так еще приходилось иметь дело с VB.NET, интересная система, но .NET, как и COM не стали слишком уж популярными.
Object Professional это не язык программирования, а библиотека от TurboPower Software
По ссылке можно скачать исходники — поностальгировать, которые они при закрытии выложили в открытый доступ (но не Object Professional).
ЯП же называется Object Pascal от Борланд, есть коллизия с версией от Эппл. Появился в версии Turbo Pascal 5.5
По ссылке можно скачать исходники — поностальгировать, которые они при закрытии выложили в открытый доступ (но не Object Professional).
ЯП же называется Object Pascal от Борланд, есть коллизия с версией от Эппл. Появился в версии Turbo Pascal 5.5
Object Professional это не язык программирования, а библиотека от TurboPower Software
По ссылке можно скачать исходники, которые они при закрытии выложили в открытый доступ (но не Object Professional).
Я же в скобках указал Pascal. Понятно, что речь шла о библиотеке, которая до этого распространялась только в бинаринках. Но мы купили именно Object Professional, v. 1.02. Даже книги были.
Кроме этого мы еще купили исходники стандартной библиотеки Си (до 1995 года еще), типа код функций printf и т.п., но меня разочаровало отсутствие там исходного кода для работы с графикой.
ЯП же называется Object Pascal от Борланд, есть коллизия с версией от Эппл.
В литературе, которая шла с исходниками, речь была только о паскале. Может и были какие-то нюансы, но я их не заметил, хотя успел написать серьезную программу, с использованием кода Object Professional, v. 1.02.
erfaren.narod.ru
Автора подобного безобразия надо от преподавания GUI гнать поганой метлой.
движок к игре Quantum Break был написан на D
Не совсем: движок игры написан на C++, а D использовался вместо скриптового языка для быстрого прототипирования: код на D компилировался в DLL, и можно было вносить изменения, даже не перезапуская игру.
Это на ваш взгляд, а для меня нет хуже задачи, чем GUI. Занимался им на Qt и на Flash. Я верю, что вам и многим другим нравится, но на нём свет клином не сошёлся.
Про опенсорс согласен, хотелось бы больше. Не хватает какой-то библиотеки, которая подняла бы D своей популярностью. Я надеялся, что vibe.d станет ею, но разочаровался — удобно, но не быстро, не хватает какой-то изюминки.
Про опенсорс согласен, хотелось бы больше. Не хватает какой-то библиотеки, которая подняла бы D своей популярностью. Я надеялся, что vibe.d станет ею, но разочаровался — удобно, но не быстро, не хватает какой-то изюминки.
Это на ваш взгляд, а для меня нет хуже задачи, чем GUI. Занимался им на Qt и на Flash. Я верю, что вам и многим другим нравится, но на нём свет клином не сошёлся.
Вполне верю, но у вас просто не было амбициозной задачи, требующей хорошего интерфейса. Вот, я только что написал в соседней реплике: «Для примера, сделайте аналог интерфейса пользователя (но более современно выглядящий) для учетной платформы 1С77. Не надо движков баз данных, макетирования отчетов, запросов и т.п. Сложно это или просто? С учетом любых доступных систем программирования и опенсорса. Можно посмотреть в сторону опенсорса «2С», но там ужасная реализация GUI на MFC. Если сделаете, цены вам не будет. А все остальное мы уже «припердолим» сами :) .»
Про опенсорс согласен, хотелось бы больше. Не хватает какой-то библиотеки, которая подняла бы D своей популярностью. Я надеялся, что vibe.d станет ею, но разочаровался — удобно, но не быстро, не хватает какой-то изюминки.
Как по мне, то С++ с существующими фреймворками вполне хорош! Поэтому лично у меня нет потребности в другом языке программирования. Я много чего перепробовал, но остановился на С++ / WTL ( возможно еще ATL). Все остальное – опенсорс, которого более, чем достаточно, успевай только осваивать. Super!
Вы мне предлагаете поспорить о вкусах. Я знаком с проблемами и сложностями проектирования GUI, не интересно. Не знаю будет ли это хорошим примером, но интересна ли вам проблема числа 10958? Или доказательства/опровержения существования и единственности решения системы уравнений Навье-Стокса? И в то, и в другое я закапывался и мне это нравится, но я не ожидаю, что понравится всем, даже если потратят столько же времени. Фломастеры разные, пусть все занимаются своим делом. У меня интерфейсы вызывают непреодолимую тоску и вовсе не из-за простоты или рутины.
Про C++ не спорю, это мой основной рабочий инструмент для прода в нише совершенно противоположенной вашей — разработка серверных библиотек. По совершенно объективным причинам я не лезу туда с D. А вот инструментарий для себя и других я пишу на D, и все это устраивает, потому что быстро пишется и быстро работает.
Острой необходимости в замене C++ нет, иначе бы она уже была, но это не значит, что нужно останавливаться на нём.
Про C++ не спорю, это мой основной рабочий инструмент для прода в нише совершенно противоположенной вашей — разработка серверных библиотек. По совершенно объективным причинам я не лезу туда с D. А вот инструментарий для себя и других я пишу на D, и все это устраивает, потому что быстро пишется и быстро работает.
Острой необходимости в замене C++ нет, иначе бы она уже была, но это не значит, что нужно останавливаться на нём.
Вы мне предлагаете поспорить о вкусах. Я знаком с проблемами и сложностями проектирования GUI, не интересно.
Ну, на нет и суда нет. Верю, что вам не интересно, плохо не это, плохо то, что это никому не интересно. Книги на эту тему всего лишь пережевывание MSDN. Однако мне интересно, поэтому, хотя бы одна книга, написанная на данную тему, увлеченным автором должна быть. Поэтому, как накоплю достаточно практического опыта, так и опубликую свой опус. А потом посмотрим, заинтересуется ею хоть кто-нибудь.
Не знаю будет ли это хорошим примером, но интересна ли вам проблема числа 10958?
Не интересна! Когда я был маленьким, море подобных задач публиковалось в журнале «Наука и Жизнь». Тогда это было хоть немного интересно. А сейчас…
Вот смотрите, я придумал новый алгоритм внешней сортировки «естественным слиянием» ( emery-emerald.narod.ru/Cpp/2E1562.html ), который использует частичный порядок даже в произвольных последовательностях. Самое интересное, что случайная последовательность обладает частичным порядком больше минимального, который теоретически равен 2! А именно, после обсуждения на форуме математиков dxdy.ru, удалось доказать, что средняя длина упорядоченной подпоследовательности L для равномерно распределенной случайной последовательности данных равна: L = 2e – 3 = 2.436563656918.
Поэтому, если хотите решить задачу числа 10958, обратитесь на этот форум, очень вероятно, что вам помогут. Недавно я там обсуждал тему, связанную с распознаванием встроенных субтитров обучающих видео: «Как группировать бинарные матрицы по степени их похожести?» ( dxdy.ru/topic142232.html ). В результате нашел подходящий алгоритм решения, не связанный с OpenCV.
Или доказательства/опровержения существования и единственности решения системы уравнений Навье-Стокса?
Это вы собираетесь доказать экспериментально, с помощью компьютерного моделирования?
Почему же экспериментально, вполне теоретически. Сейчас уже нет, но ещё недавно вполне неплохо был погружён в теоретические изыскания. Так как для хобби сложновато, а в работе не пользуюсь, безнадёжно отстал. Никогда не считал, что это задача мне по силам (если она вообще кому-то по силам), но интересно же. Там весёлая история, как и с P=NP, практики исходят из существования единственного решения, как и P!=NP, а теоретики не уверены — одна из задач тысячелетия.
Никогда не считал, что это задача мне по силам (если она вообще кому-то по силам), но интересно же.
Ну, если вам нравится теоретическая физика, то давайте обсудим что-нибудь попроще.
Вот школьная задачка, на квадратные уравнения (которые мы проходили в пятом классе). Нужно найти ошибку в рассуждениях. Правда, содержимое будет из квантовой механики, но это для маскировки :).
Общее уравнение Шредингера (УрШ) можно рассматривать как квадратное уравнение относительно постоянной Планка h. Решаем его, получаем формально два корня. Но постоянная Планка то одна, поэтому либо дискриминант квадратного уравнения равен нулю, либо у постоянной Планка есть второе фундаментальное значение. Оба случая интересны. В первом варианте получаем из одного уравнения два, что упрощает решение и анализ УрШа. А, во втором, делаем научное «открытие», постоянная Планка имеет два разных значения. Ура, товарищи! Куда обращаться за Нобелевской Премией? :)
Не понимаю к чему это. В квантовой физике я понимаю примерно ничего, проблема наличия решения уравнений Навье-Стокса лежит исключительно в области математики, никак не касаясь физики. Давайте не уходить в оффтопик. Я изначально писал про уравнения исключительно как специфическую область интересов, которую не все разделяют.
Мы вроде сошлись на том, что мне интересно одно, вам другое и оба не видим в этом факте беды. Вы сокрушаетесь, что ваша любимая тема непопулярна, чтож бывает. Вы хотите создать курс программирования GUI? Ничего не имею против, поспособствовать тоже особо ничем не могу. Мне лично не кажется, что такая узкая тема как «Программирование пользовательского интерфейса на С++ / WTL / ATL» не совсем хороша для базового курса, но в магистратуре профильных заведений может найтись место.
Мы вроде сошлись на том, что мне интересно одно, вам другое и оба не видим в этом факте беды. Вы сокрушаетесь, что ваша любимая тема непопулярна, чтож бывает. Вы хотите создать курс программирования GUI? Ничего не имею против, поспособствовать тоже особо ничем не могу. Мне лично не кажется, что такая узкая тема как «Программирование пользовательского интерфейса на С++ / WTL / ATL» не совсем хороша для базового курса, но в магистратуре профильных заведений может найтись место.
Не понимаю к чему это. В квантовой физике я понимаю примерно ничего, проблема наличия решения уравнений Навье-Стокса лежит исключительно в области математики, никак не касаясь физики. Давайте не уходить в оффтопик.
Там квантовая механика, дана, как я написал, «для маскировки». По сути, чтобы напугать, а не в силу особой необходимости. Поэтому проблема чисто математическая, а не физическая. Физики там не больше, чем в уравнении жидкости в трехмерном пространстве, то бишь, Навье-Стокса. Модель имеет физические истоки, но стала чисто математической. Так и в указанной задачке для пятого класса. Для ее решения достаточно школьных знаний, возможно советских времен, а не российских. Странно, немного, что проблему Навье-Стокса вы понимаете лучше, чем эту достаточно простую задачу.
Однако могу вас утешить, впервые я обратился за разъяснениями к своему физику-семинаристу, в первом ВУЗе, ученику Капицы. Он любил задалбливать нас трехмерными интегралами из гидродинамики, но по этой задачке сказал, что здесь должна быть ошибка, но где, ищи сам. Потом, обратился к одной даме физику, случайно оказавшейся напарницей по автобусу. Она тоже не смогла ответить по существу. И только студент мехмата второго курса, который оказался моим напарником по комнате в общежитии МГУ, ответил четко и правильно, причем быстрее, чем я даже успел сформулировать эту задачу. Даже раздосадовало немного, что все оказалось так просто.
Понимаете, с точки зрения математики тут парадокса нет. Вы предложили рассматривать как квадратное уравнение, а то есть зафиксировать момент времени t и координаты r. Может быть один корень, может два. Последствия и того, и другого начинаются в физической интерпретации. Как и области определений, из которой очень быстро может следовать бессмысленность второго корня в силу отрицательности или ненулевой мнимой части. Тут же подразумевается вещественное время и координаты, но комплексные функции. Ограничения на h нужно тоже задать и смотреть. А пока мы просто решаем уравнение, проблем нет.
Раз вы видите парадокс и знаете его решение, значит вы рассматриваете модель подробнее, чем простое квадратное уравнение, а значит нужно разбираться с используемыми функциями, их областями определений, значений и тд.
Ну а истории про то, как ученик Капицы не смог решить, отсылки про советские и российские времена, и общий тон вопроса придают очень неприятные оттенки задаче и задающему.
P.S. Квадратные уравнения, это 8 класс российской и 7 класс советской школы, никак не 5. Куда же нас унесло, хорошо же общались про D и GUI.
Раз вы видите парадокс и знаете его решение, значит вы рассматриваете модель подробнее, чем простое квадратное уравнение, а значит нужно разбираться с используемыми функциями, их областями определений, значений и тд.
Ну а истории про то, как ученик Капицы не смог решить, отсылки про советские и российские времена, и общий тон вопроса придают очень неприятные оттенки задаче и задающему.
P.S. Квадратные уравнения, это 8 класс российской и 7 класс советской школы, никак не 5. Куда же нас унесло, хорошо же общались про D и GUI.
Кстати, есть интересное направление — программирование научных вычислений. Вполне себе университетские задачи по линейному программированию итп.
И тут есть две проблемы:
— главная, на мой взгляд — что мат.вычисления в переводе на «обычный» ЯП становятся нечитаемыми и это приводит в т.ч к ошибкам,
— вторая — уже для проф.области — это скорость, параллелизация, кластеризация
Я даже переводил статью по этой теме.
Впрочем, Д там был в отстающих — в плюсе конечно перегрузка операторов, но вот в остальном — слабо.
И тут есть две проблемы:
— главная, на мой взгляд — что мат.вычисления в переводе на «обычный» ЯП становятся нечитаемыми и это приводит в т.ч к ошибкам,
— вторая — уже для проф.области — это скорость, параллелизация, кластеризация
Я даже переводил статью по этой теме.
Впрочем, Д там был в отстающих — в плюсе конечно перегрузка операторов, но вот в остальном — слабо.
Прошу прощения, если я вас обидел, или задел какие-то чувства. Цели у меня такой не было. Однако я ценю ваш заинтересованный ответ.
Насчет 5-го или 7-го класса спорить не буду, но ощущения знакомства с квадратными уравнениями у меня очень ранние.
Насчет, «куда же нас занесло», это нормально. По основной теме как бы уже все сказано, добавить особо нечего, поэтому либо «а поговорить» либо подождать публикации другой, более соответствующей статьи.
По задачке, «физической интерпретации» особо никакой нет. Речь идет просто об избыточном корне квадратного уравнения. У нас в школе их называли «паразитными». Скажем так, уравнение Шредингера может быть записано без паразитных корней для постоянной Планка, присутствующей в первой степени. Но это будет не одно уравнение, а несколько. Путем математических преобразований из нескольких уравнений получено одно, соответственно добавился лишний корень для h (типа, из х = 1 получаем x^2 = 1 и избыточный корень х = –1). При этом избыточные корни отсекаются за счет краевых условий, поэтому подобная форма УрШ вполне всех устраивает.
Однако если для данного уравнения Шредингера известно решение для пси-функции, то подставив его в выражение для h (в виде формального решения квадратного уравнения), то мы получим первое значение для известной постоянной Планка, в виде константы, а второе в виде некой функции. И так будет всегда. Т.е., второе значение для h никогда не будет константой, только функцией. Понятно, что подобная функция (причем, всегда разная для разных начальных условий) не может являться решением и явно представляет из себя паразитное значение.
Как видите, особого физического смысла здесь нет, уравнение подобного типа в физике может встречаться и в других моделях, анализ, по сути, чисто математический.
Насчет 5-го или 7-го класса спорить не буду, но ощущения знакомства с квадратными уравнениями у меня очень ранние.
Насчет, «куда же нас занесло», это нормально. По основной теме как бы уже все сказано, добавить особо нечего, поэтому либо «а поговорить» либо подождать публикации другой, более соответствующей статьи.
По задачке, «физической интерпретации» особо никакой нет. Речь идет просто об избыточном корне квадратного уравнения. У нас в школе их называли «паразитными». Скажем так, уравнение Шредингера может быть записано без паразитных корней для постоянной Планка, присутствующей в первой степени. Но это будет не одно уравнение, а несколько. Путем математических преобразований из нескольких уравнений получено одно, соответственно добавился лишний корень для h (типа, из х = 1 получаем x^2 = 1 и избыточный корень х = –1). При этом избыточные корни отсекаются за счет краевых условий, поэтому подобная форма УрШ вполне всех устраивает.
Однако если для данного уравнения Шредингера известно решение для пси-функции, то подставив его в выражение для h (в виде формального решения квадратного уравнения), то мы получим первое значение для известной постоянной Планка, в виде константы, а второе в виде некой функции. И так будет всегда. Т.е., второе значение для h никогда не будет константой, только функцией. Понятно, что подобная функция (причем, всегда разная для разных начальных условий) не может являться решением и явно представляет из себя паразитное значение.
Как видите, особого физического смысла здесь нет, уравнение подобного типа в физике может встречаться и в других моделях, анализ, по сути, чисто математический.
А какое отношение этот опус имеет к университетскому программированию?
Впрочем из GUI на D лично я собирал еще в 2014г демки с разными библиотеками — DWT, GtkD, DFL, TkD. Недавно — с DlangUI
Это все опенсорс, включая компилятор и стандартную библиотеку.
P.S.Лично я не считаю D хорошим первым языком для обучения. Слишком сложен, требует бэкграунда. Вторым, — вполне (особенно в тех местах, где «учат» С++).
Впрочем из GUI на D лично я собирал еще в 2014г демки с разными библиотеками — DWT, GtkD, DFL, TkD. Недавно — с DlangUI
Это все опенсорс, включая компилятор и стандартную библиотеку.
P.S.Лично я не считаю D хорошим первым языком для обучения. Слишком сложен, требует бэкграунда. Вторым, — вполне (особенно в тех местах, где «учат» С++).
Вы считаете, что C++ лучше в качестве первого языка? Или я не правильно понял про места, где учат C++? Я считаю что D гораздо лучше в качестве первого, возможно даже лучший из мне известных.
1й — бейсик или паскаль или аналоги, где не надо рассказывать для хелловорлда про файлы, модули, импорты, проекты, компилятор/линкер итп
С++ сложнее чем Д, так что еще хуже для 1го.
Главное, не зацикливаться на 1м языке, а после понимания простых основ — подпрограмм, циклов, двигаться вперед. Это уже может быть и Питон и Д и Шарп и Ява и С++(но сначала С)
С++ сложнее чем Д, так что еще хуже для 1го.
Главное, не зацикливаться на 1м языке, а после понимания простых основ — подпрограмм, циклов, двигаться вперед. Это уже может быть и Питон и Д и Шарп и Ява и С++(но сначала С)
А какое отношение этот опус имеет к университетскому программированию?
А что университетское программирование это типа учебного, т.е., ненастоящего программирования? Чтобы, придя на предприятие, сказали: «Забудьте все то, чему вас учили!»?
А так, мое мнение, программистам надо давать отдельный курс, вроде: «Программирование пользовательского интерфейса на С++ / WTL / ATL», вплоть до программирования собственных контролов, типа форм списков. Вообще, почти все стандартные контролы Windows требует «напильника», чтобы довести их до ума. Те же закладки для MDI-окон, вроде не сложно, но хороших примеров нет, а то, что есть, имеет явно избыточный вес.
Впрочем из GUI на D лично я собирал еще в 2014г демки с разными библиотеками — DWT, GtkD, DFL. Недавно — с DlangUI
Это все опенсорс, включая компилятор и стандартную библиотеку.
Не интересно GUI вообще, интересно иметь легкий рабочий вариант. Для примера, сделайте аналог интерфейса пользователя (но более современно выглядящий) для учетной платформы 1С77. Не надо движков баз данных, макетирования отчетов, запросов и т.п. Сложно это или просто? С учетом любых доступных систем программирования и опенсорса. Можно посмотреть в сторону опенсорса «2С», но там ужасная реализация GUI на MFC. Если сделаете, цены вам не будет. А все остальное мы уже «припердолим» сами :).
А так, мое мнение, программистам надо давать отдельный курс, вроде: «Программирование пользовательского интерфейса на С++ / WTL / ATL»
Мне кажется, что это ещё хуже.
Я сам предпочитаю десктопные приложения повсеместному уходу в веб, но надо быть реалистом: на WTL/ATL сейчас очень мало что пишут (а уж начинать проект с прицелом на эти технологии так вообще почти никто не будет). Да и кроссплатформенность сейчас более актуальна.
Мне кажется, что вы зацикливаетесь на устаревшей технологии с которой любите (или вынуждены) иметь дело и экстраполируете это на всю индустрию. Если уж писать гуй на С++, то лучше Qt взять что ли.
Я сам предпочитаю десктопные приложения повсеместному уходу в веб, но надо быть реалистом: на WTL/ATL сейчас очень мало что пишут (а уж начинать проект с прицелом на эти технологии так вообще почти никто не будет). Да и кроссплатформенность сейчас более актуальна.
Я могу себе позволить не обращать внимания на моду. Да и выражение такое есть, если хотите добиться успеха, идите туда, где никого нет. Этот принцип меня вполне устраивает.
Что касается кроссплатформенности, то проще переписать программу с нуля, чем сразу поддерживать «коня и трепетную лань». Тем более что необходимости осваивать другие платформы, пока нет.
Мне кажется, что вы зацикливаетесь на устаревшей технологии с которой любите (или вынуждены) иметь дело и экстраполируете это на всю индустрию. Если уж писать гуй на С++, то лучше Qt взять что ли.
Я работал с Qt, он мне нравится, но он очень большой для моих целей. Потом взял систему попроще, wxWidgets, тоже милая вещь, но тоже великовата для меня. Потом нашел WTL и это оказалось то, что мне нужно. Есть еще легкий опенсорсный Win32++, как заменитель MFC, однако WTL мне импонирует больше.
Я могу себе позволить не обращать внимания на моду. Да и выражение такое есть, если хотите добиться успеха, идите туда, где никого нет.
Это замечательно, но мы, вроде как, об обучении говорим? И выше как раз было о том, что университетские знания не должны быть бесполезными для "реального программирования". Так вот WTL подавляющему большинству не пригодится.
Что касается кроссплатформенности, то проще переписать программу с нуля, чем сразу поддерживать «коня и трепетную лань».
Весьма спорно, особенно в контексте всей программы. Иметь специфический для платформы UI зачастую оправдано, а вот ядро/бэкенд лучше написать один раз — это и поддерживать будет проще.
Я работал с Qt, он мне нравится, но он очень большой для моих целей.
Любопытно было бы услышать подробности. В чём выражается это "очень большой"? В микроконтроллер не влезает? Или просто занимает на пару мегабайт больше, чем хотелось бы?
Это замечательно, но мы, вроде как, об обучении говорим? И выше как раз было о том, что университетские знания не должны быть бесполезными для «реального программирования». Так вот WTL подавляющему большинству не пригодится.
Т.е., выходит я занимаюсь «не реальным программированием»? Меня же никто не принуждает, сам пришел к необходимости освоения WTL, значит, потребность была немного более чем абстрактный интерес.
Кстати, вы же изучение Qt или wxWidgets не отрицаете, видите в этом пользу. А WTL это тоже самое, только легковесное. Разве программист обязан делать только монструозные программы? Тем более что один и тот же результат, что для Qt, что для WTL можно получить сопоставимыми усилиями. Разница только в объеме конечной программы.
Более того, можно вообще поставить задачу создания интерфейсного контейнера, как я его называю, в виде некоего мастера. Допустим, вам дали задачу перенести данные из одной системы (формата) в другую. Вы быстренько наваяли какой-нибудь sql-скрипт с элементами пред и постобработки, вручную завели исходные параметры, выполнили, получили результат. Завтра другие данные и параметры, вы вручную меняете их и снова получаете результат. И так каждый раз. У меня лично подобных программ по разовой конвертации данных сотни, если не тысячи.
Вот сидишь и думаешь, нафига козе баян? А так берешь наш мастер по генерации произвольного интерфейсного контейнера, в автоматическом режиме генеришь код, добавляешь туда содержательную часть и у вас получается программа вполне товарного вида, от которой пользователи будут просто пищать. А усилий минимум. Профит? Вполне!
Или возьмем ту же программу 1С77. Ее все не любят, она давно морально устарела, но часто – густо более предпочтительна, чем 1С82 или 1С83. Она на порядок дешевле, непритязательна к ресурсам, легко поддерживается и программируется, поэтому для учета на средних предприятий, особенно в случае таких непризнанных республик, как ЛНР / ДНР просто идеальное решение.
Но почему бы не пойти дальше и не сгенерировать интерфейсный контейнер а-ля 1С77, только на более современном уровне, в т.ч., для 64-х битных платформ. В качестве движка базы данных можно взять опенсорсный SQLite, навигацию по данным делать с помощью MMF, а поддержку отчетов использовать на первых порах опенсорсную.
В общем, проблем с содержательной частью у меня не было, прототипы работали вполне успешно. Однако проблемы возникли на уровне интерфейса, поскольку стандартный Windows интерфейс оказалось для всех нелюбимым дитем, соответственно, чтобы сделать конфетку надо хорошо повозиться (так как мастера генератора интерфейсных контейнеров пока нет).
Кстати, бизнес логику удобно вынести на уровень плагинов, так чтобы каждый мог добавлять в программу нужный модуль. Отсюда мы плавно переходим к модульному учету, который вполне востребован на разных уровнях, на всех предприятиях. Речь не идет об альтернативе для корпоративных пользователей, только для малых и средних предприятий, коими 1С просто тупо перестала заниматься.
И после этого фразы типа: «Так вот WTL подавляющему большинству не пригодится» выглядят несколько наивно :). Хотя, по сути, вы правы, всем не нужно. Народу нужен результат, а результат должны дать программисты, а они вправе желать облегчить себе генерацию шаблонного кода. А спрос для подобных программ я лично у себя в ЛНР (и не только) всегда найду. Вот почему я кровно заинтересован решить проблему пользовательского интерфейса на приемлемом для себя уровне.
ядро/бэкенд лучше написать один раз — это и поддерживать будет проще
Пересборкой своих и чужих программ приходится заниматься постоянно. Я бы даже назвал это методом освоения и совершенствования программирования. Поэтому насчет «один раз» весьма спорно, если вы конечно не гений программирования.
Любопытно было бы услышать подробности. В чём выражается это «очень большой»? В микроконтроллер не влезает? Или просто занимает на пару мегабайт больше, чем хотелось бы?
Естественно, дело не объеме выходного кода, хотя если размер можно уменьшить на порядок, без потери качества, то почему бы этого не сделать? Скорее речь идет о понимании используемого опенсорса. Qt объемный в смысле освоения, но если следовать в парадигме стиля программирования Qt, то проблем как бы не возникает. Нюансы появляются, когда что-то хочешь сделать по своему, что не является стандартным для Qt. Можно это сделать? Конечно можно! Только надо знать как.
Поэтому вопрос в данном случае чисто прагматический. Да, Qt очень мощный и там можно делать все. Особенно мне нравится, что он поддерживает SQLite на уровне встроенного драйвера, а также контрол «форма списка» или грид. Это лучший опенсорсный грид, который я видел. Тем не менее, у меня и здесь есть собственные нюансы. Во-первых, SQLite мне нужен только для создания и поддержки индексов, а для юзания базы данных (типа sdf – simple data format) я хочу использовать технологию MMF (отличнейшая вещь, у меня даже статья на codeproject.com есть на эту тему). А по гриду я хочу иметь универсальный контрол, общий и для формы списка и для формы элемента (диалога) и для печатной / табличной форм. А экспериментировать с этим лучше в «чистой» системе, т.е., не такой сложной как Qt, поэтому WTL – идеальное решение.
Самое интересное в программировании, на мой взгляд, это кодирование пользовательского интерфейса.
Да вы, наверное, шутите! Это самое мерзкое и геморное, что есть в программировании!
Да вы, наверное, шутите! Это самое мерзкое и геморное, что есть в программировании!
Да нет, не шучу! Но я вполне понимаю вашу неприязнь к GUI, а вы мою любовь к пользовательскому интерфейсу оценить не в состоянии :).
Ну справедливости ради, многим новичкам реализовывать какие-то синтетические штуки в консоли и правда кажется унылым. А с GUI можно даже что-то условно-полезное для себя соорудить: делфи с набрасыванием компонентов на форму не зря большую популярность получил. Хотя сейчас даже в плане пользовательского интерфейса, вероятно, уже другие ориентиры: веб, мобильные приложения и т.д.
Вы правы. Я думал, как включить минимальный GUI в курс, чтобы поднять интерес. Не стал, потому что для этого нужно убрать что-нибудь другое. GUI сложнее консоли, у него больше состояний, так или иначе он базируется на событиях и нужна инверсия контроля. В этом году я ещё не делал нового обзора gui библиотек на D, есть небольшой шанс, что я всё же внесу интерфейс в курс.
Очень хотел бы внести ещё и компиляцию в webassembly с библиотекой для вёрстки прямо из кода, но инструментарий был сыроват и сложноват. Это бы позволило писать под привычное окружение — браузер.
Очень хотел бы внести ещё и компиляцию в webassembly с библиотекой для вёрстки прямо из кода, но инструментарий был сыроват и сложноват. Это бы позволило писать под привычное окружение — браузер.
так или иначе он базируется на событиях и нужна инверсия контроля
Это само по себе очень важная концепция, которую, как я думаю, надо преподавать. Уж для GUI или ещё для чего — не важно.
В моём курсе она встроена в работу с сетью и события подключений и новых данных для чтения. Так проще пройти путь от блокирующихся операций на низкоуровневых сокетах, через активное ожидание неблокирующихся, к событийному циклу, инверсии и колбекам. Ну, а дальше только корутины. Пока что эта цепочка мне кажется полезнее интерактивных кнопочек.
Я, помнится, в детстве игрался с Visual Basic 6.0.
Можно сделать что-то полезное для себя. Но как сделаешь это полезное, возникает ("Блин! Ещё сковородка!") проблема, как для этого полезного адекватный GUI набросать, и какой он — адекватный GUI.
И начинаешь пробовать… и так, и этак, вот тут не умещается, а тут — концептуально не то… Обычно это занятие так утомляло, что весь проект забрасывался.
Позже я стал предпочитать творить простые DSL, но это было позже.
Вот например, писал я калькулятор для векторов, и гадал как сделать ввод и вывод. Кончилось тем, что нет ни чего лучше, чем xi+yj+zk в строковом поле.
Очень интересно! Респект!
«Нужен промежуточный контроль успеваемости».
О, да! По причине наличия этого контроля ИМХО наша школа эффективнее ВУЗов.
«Нужен промежуточный контроль успеваемости».
О, да! По причине наличия этого контроля ИМХО наша школа эффективнее ВУЗов.
Sign up to leave a comment.
Как я студентам язык D преподавал