Комментарии 46
Вопросы образования меня мало волнуют, так что отвечу только по поводу ниши PascalABC.NET в экосистеме .NET
Попутно отмечу, что C# не единственный представитель .NET. В последнее время наблюдаю рост популярности F# например. В энтерпрайз его тащат не часто, но опенсорс и какие-то локальные вещи на нём вполне себе живы
И так, PascalABC.NET(pabc) для меня это в первую очередь инструмент, которым очень легко собрать кучу имеющихся в .NET библиотек (как стандартных, так и внешних) и собрать какое-то клиентское приложение, будь то CLI тулза или desktop-приложение. Как правило, это получается намного лаконичнее и читабельнее, чем на том же C#. Все компоненты приложения, которые можно вынести в библиотеку и где-то переиспользовать -- лучше писать на C# и подключать к pabc
Система модулей привносит в .NET иной подход к работе с компонентами программы. При чём модуль в ряде случаев тоже можно переиспользовать между проектами и он является неким легковесным аналогом dll
В вопросах генерации CIL pabc иногда разрешает больше, чем C#. Взять те же именованные индексаторы
Мультипарадигменный подход позволяет не перегружать код лишними абстракциями там, где это не требуется. Актуально для скриптовых, тестовых и небольших приложений
Ряд небольших фишек, облегчающих написание кода. Некритично, но довольно неприятно, когда встречаешь их отсутствие в других языках
Таким образом, pabc в среде .NET это не про объёмные библиотечные проекты, это про легкоподдерживаемые клиентские программы
Когда-то был Delphi.NET и Prism Oxygene - но всё это быстро померло - ибо нахрен никому оказалось не нужно. Хотя у меня книжка Delphi.NET Ксавье Пачеко (отличная книга) до сих пор лежит на столе (правда в виде подставки для монитора) - тогда много возникало .NET редакций разные ЯП - сейчас, по сути они все мертвы - выжил только оригинал C# - и я, считаю, что это печально! C# слишком много унаследовал от C++ того, что мне не нравится - но C# хороший ЯП, хоть в последнее время не всем нравилось как бурно он развивался! Но отсутствие в среде .NET у него конкурентов - это не хорошо, как я считаю - слишком уж монополизированной получается разработка под .NET - в целом, очень хорошей платформы!
Вот у JVM есть некоторые альтернативы в лице Scala, Kotlin и некоторых менее известных ЯП. И это хорошо.
Когда сдох Delphi.NET я очень грустил, и хотел делать уже свою версию - но потом понял, что это тоже будет труп. Хотя для обучения программированию в школах Pascal на платформе .NET был бы не плох. Но.... есть же Python - вроде бы ещё лучше для школьников (которые переходят с более "примитивных" графических ЯП для детей). Так что в чём потребность в PascalABC.NET мне не ясна вовсе. Особенно когда есть Kotlin с похожим и более лаконичный синтаксисом (Rust не рассматриваю - это другая область).
Вот лично я делаю Kotlin для платформы .NET - и считаю, что потребность в таком диалекте может быть не на много ниже чем в Native Kotlin - небольшая, но свою нишу найдёт - выехав на популярности Kotlin и широких возможностях платформы .NET
А уж если разрабатывать новые ЯП - то это уже должно быть что-то революционное, удобное и надёжное - лучше, чем есть среди основных ЯП TOP10
Что до текстового ЯП для школьников средних классов - то Pascal, на мой взгляд, тут уже устарел как учебный язык - но действительно хорошей альтернативы ему я не видел - всё-таки даже Python и Kotlin тут больше для старшеклассников и студентов годятся. Но и PascalABC.NET будет для них слишком сложен и коряв, а главное - для младших и средних классов нужна очень красивая и затягивающая мультимедийная оболочка и умная среда разработки - вот об этом нужно думать в первую очередь.
Ну и тут можно спорить "о первенстве курицы и яйца" (хотя кто знает, тот знает, что яйцо классе пернатых было первым) - но лично моё мнение в нынешних реалиях обучение программированию надо начинать ЯП без строгой типизации - и не грузить детей особенностями устройства памяти - это вполне можно оставить до старших классов или даже до ВУЗов. И без этих знаний можно вполне успешно программировать, а грузить этим мозг детей не гуманно - наоборот лучше потом более серьёзно этому всему обучать, когда мозги уже готовы будут это всё воспринимать с уклоном в оптимизацию!
А чем Го не альтернатива Паскаля для школьников? Очень похожие языки.
Мерзкий язык - для обучения не годится - хуже чем Python. Простите за резкость - от синтаксиса GoLang меня воротит - но это субъективное мнение - нелаконичный и необтёсанный он. Как минимум я плохо перевариваю ЯП где форматирование текста не имеет свободной формы! И, думаю, детям это тоже будет очень неудобно! Как и путаница в присваиваниях "=" и ":=", а уж проблема проверки на nil - меня вообще выворачивает!
Однако же в подмножестве языка в рамках школьной программы (т.е. если не изучать горутины, дженерики, интерфейсы и функции высшего порядка) он похож на Паскаль и все отличия лишь в некоторых особенностях синтаксиса.
А Паскаль отличный язык для обучения - явное определение переменных, строгая типизация, никаких классов и объектов (что для школы плюс, а не минус). Но Паскаль уже почти нигде не используется и странно учить детей умирающему языку, а Го современный и востребованный язык. Поэтому он мне кажется интересным вариантом.
А так все языки имеют свои недостатки и уродства от которых воротит. Даже не знаю, есть ли язык, который не имеет недостатков в моих глазах? Ну разве что Coq. Вот Coq совершенный идеал, вообще не могу придраться ни к чему! Ну разве что один недостаток - учить детей в школах Coq было бы абсолютным безумием.
Ну, это мнение конечно. Вы наверное имеете в виду динамическую типизацию.
Я вот напротив считаю, что начинать сколько-нибудь последовательно учить программированию лучше с языков со статической типизацией, в которых компилятор тебе не даст писать многие неправильные программы.
Как насчёт JavaScript для обучения? Ц-подобный синтаксис и основные конструкции, что позволяет в дальнейшем как развиваться во фронте, так и перекатиться в бэк или мобилки. Язык популярный, информации по нему прорва, всегда есть кого спросить.
Но, наверно, придётся разработать какую-то особую школьную IDE.
Kotlin лучше продуман, чем JavaScript, у которого тоже косяки в дизайне есть, и его сложно изучать в отрыве от других технологий. И с практической стороны далее Kotlin более универсален - т.к. компилируется в разные платформы. Но я, всё-таки, считаю Kotlin сложноватым для обучения в школе (разве что в старших классах, если школьники уже освоили более простой ЯП, а вот какой - это ещё та дилемма - тут лучше применять ЯП без строгой типизации - но это лишь моё мнение; и без кучи неочевидных нюансов синтаксиса и выполнения кода).
Но это не значит, что JavaScript изучать не надо - это очень мощный и популярный ЯП, просто не годится он для обучения в школьной программе.
В своё время для этой цели Turbo pascal как и Basic были хороши - но те время уже прошли - и сейчас нужно искать более удачное решение - даже Python сейчаc лучше подойдёт чем эти старички или JavaScript. Но и Python не без недостатков :-(
Кстати в старших школьных классах на Kotlin, C#, Python, Lua - можно даже попытаться проводить обучение в игровой форме (в более младших классах тоже можно так - но на других ЯП и платформах) - т.е. заинтересовать детей разработкой или доработкой игр на каких-то готовых игровых движках (сам эти увлекался, правда уже в студенческие годы, хотя и сейчас не брезгую иногда поковырять игровые алгоритмы). Конечно, навряд ли в рамках школьной программы - но на факультативных занятиях можно. В рамках школьной программы я бы всё-таки в старших классах давал бы основы работы с СУБД - т.е. в первую очередь ANSI SQL (он не такой уж сложный в своё базисе) и, с учётом того, что какое-то программирование уже должно к старших классам уже быть освоено - написание визуальных программ для СУБД - ну вот так мне преподавали в старших классах информатику, и так я уже сам успел немного преподавать информатику в старших классах - так что я знаю о чём говорю! В ходу тогда был Delphi - и его визуальная компонентная база была очень легка в использовании! Но сейчас я бы Delphi уже не стал рекомендовать - мир изменился и в ходу уже другие подходы в разработке приложений, но не скажу, что этот процесс стал проще (хотя и усложнился не сильно если изучать с нуля, но вот переучиваться со старых подходов тяжеловато) - уверен, что в будущем это всё снова изменится и упростится ещё сильнее, чем было раньше (но визуальное программирование в том виде уже уйдёт в прошлое)!
Кроме СУБД в старших классах можно попробовать и в WEB дизайн или вооще во Frontend в целом выстраивать школьную программу. И так делают сейчас - но это опять же, скорее факультатив - слишком сложный стек для школьников, но очень востребованный - но осилят не все. Хотя если сосредоточится на дизайне без (или почти без) программирования - т.е. на только HTML/XAML + стили - то что-то можно делать, вот только без программированию тут далеко не уедешь - а начнёшь тащить программный код - и всё станет слишком сложно для детей! Если что Kotlin'овский Jetpack Compose - тоже сложная штука для школы.
Вопросы образования меня мало волнуют, так что отвечу только по поводу ниши PascalABC.NET в экосистеме .NET
Попутно отмечу, что C# не единственный представитель .NET. В последнее время наблюдаю рост популярности F# например. В энтерпрайз его тащат не часто, но опенсорс и какие-то локальные вещи на нём вполне себе живы
И так, PascalABC.NET(pabc) для меня это в первую очередь инструмент, которым очень легко собрать кучу имеющихся в .NET библиотек (как стандартных, так и внешних) и собрать какое-то клиентское приложение, будь то CLI тулза или desktop-приложение. Как правило, это получается намного лаконичнее и читабельнее, чем на том же C#. Все компоненты приложения, которые можно вынести в библиотеку и где-то переиспользовать -- лучше писать на C# и подключать к pabc
Система модулей привносит в .NET иной подход к работе с компонентами программы. При чём модуль в ряде случаев тоже можно переиспользовать между проектами и он является неким легковесным аналогом dll
В вопросах генерации CIL pabc иногда разрешает больше, чем C#. Взять те же именованные индексаторы
Мультипарадигменный подход позволяет не перегружать код лишними абстракциями там, где это не требуется. Актуально для скриптовых, тестовых и небольших приложений
Ряд небольших фишек, облегчающих написание кода. Некритично, но довольно неприятно, когда встречаешь их отсутствие в других языках
Таким образом, pabc в среде .NET это не про объёмные библиотечные проекты, это про легкоподдерживаемые клиентские программы
Есть, например, Оберон, он не устарел.
Ох уж эти ценители стюардесс
Если серьёзно, то когда-то давно ~25 лет назад Pascal был моим вторым языком программирования после года с basiс и каким-то учебником. И тогда мне требовалось полгода, чтобы на Pascal сделать что-то интересное и красивое.
Может быть, PascalABC и вправду чем-то хорош как учебный язык. Но я как преподаватель не хочу связываться с подобными учебными языками: ученики может и поймут какие-то концепции лучше, но в большинстве своём никогда в своей жизни ни для какой своей потребности им не воспользуются. То есть обучение пройдёт только ради обучения.
А Вы уверены что то с чем вы связались сейчас (кстати с чем? может раст?) - завтра будет кому-то нужно?
В моём случае речь о питоне.
Так что завтра — точно. Через пять лет — не факт, но это и не важно: если 5 лет не пользоваться языком, то всё забудется.
Ну, то есть одна из моих личных мысленных KPI при обучении программированию: доля школьников, которые в пределах года после обучения смогли решить какую-то свою задачу при помощи программирования.
Ценность Питона слегка преувеличена (в глобальном смысле для мира программирования). Для low-level лучше уж учить C++, а для High Level - Kotlin или C#.
У питона, безусловно, есть свои проблемы.
Но в смысле универсального доступа к "достижениям человечества" у питона немного альтернатив. У Kotlin и C# есть свои ниши, не вполне универсальные.
ИМХО, у обучения C++ как первому языку программирования должна быть какая-то внятная мотивация. Условно, если хочется школьником взять всеросс по информатике, то от C++ не уйдёшь. Плюсы — сложный язык с очень сложным взаимодействием с библиотеками.
Я думаю, что для решения своей задачи можно применить любой известный язык. А в коммерческом программировании любой из современных языков теперешним школьникам, скорее всего, не пригодится. Цель обучения в школе – правильно поставить мозги, а не надеяться на непосредственную применимость материала.
Питон – неплохой язык для начального обучения, но не надо испытывать слишком много иллюзий.
Ну вот через N лет после окончания ВУЗа (на кафедре основной язык - паскаль=>Delphi) потребовалось "для себя" быстро написать десктоп-программку. Выбрал Lazarus.
PascalABC.NET вполне можно применять как рабочий инструмент, если адекватно оценивать какое место он занимает в экосистеме .NET
Классический и турбо паскаль был хорош для обучения своими маленькими размерами, позволявшими изучить за год язык целиком. А тут уж напихали всякого добра из C++/C# и stdlib, так что объём материала стал очень большой, и тогда непонятно, почему бы сразу не изучить C++.
Учебному языку не нужен синтаксический сахар. А в качестве профессионального языка паскаль, к сожалению, давно умер.
Да не умер он, живёт :) В desktop windows корпоративных приложениях.
Вот новая версия в ноябре вышла:
https://www.embarcadero.com/en/products/rad-studio/whats-new-in-12-athens
Скорее мёртв чем жив как и VB6 - используется в основном только для поддержки старого ПО.
А RAD Studio это не только Pascal но и C++ (а от Pascal for .NET они уже давно отказались)
Но тут всё скорее на компонентную базу завязано, идущую в комплекте со студией (и в первую очередь визуальных для баз данных; ибо тут всё давно устарело - нет никакого WPF, Avalonia UI, Jetpack Compose, Swift UI и вообще с кроссплатформенностью GUI тут всё не очень хорошо - хоть она и официально есть; плохо всё и с кастомизацией GUI )
FMX - идущая в комплекте куда мощнее WPF и Avalonia вместе взятых. В частности при работе с кастомизацией. Просто вы не знаете как это сейчас там работает. И нет, это не "куча шкурок". Это CSS подобный способ создания представления любого контрола, только с использованием дизайнера. Да, дизайнер для дизайна компонентов.
в качестве профессионального языка паскаль, к сожалению, давно умер.
Расскажите это Кристиану Гислеру. И авторам других популярных программ, которые до сих пор пишутся на диалектах Паскаля.
Интересно, а в каком смысле язык программирования рассматривается как профессиональный язык. Есть много разных профессий, и многие используют программирование. Значит ли, что они делают это непрофессионально?
Вот допустим - научный работник. Профессионал - очевидно. Написал вычислительную программу на языке программирования. Это - непрофессиональное применение языка?
Я под профессиональным применением понимаю ориентацию на действующий рынок труда.
Научный работник ориентирован на рынок труда программистов? Очевидно, нет.
Я вот профессионально программирую, а на работу езжу на своей машине. Становится она от этого ориентированной на профессиональный труд водителя? Очевидно, нет. Плохая у меня машина для профессионального водительского применения, производительность/стоимость неважная. Но мне нравится, потому что удобная. Так и тут.
Тут вот какая проблема. Сейчас в качестве учебного языка программирования в школе предлагается как раз язык Питон, напичканный синтаксическим сахаром.
Еще одна проблема - это то, что многие профессиональные программисты различают только два вида программирования: учебное и профессиональное. А мир гораздо богаче.
Я лично не считаю питон идеальным языком для обучения программированию. Хотя у него есть много плюсов в этом качестве, например, динамическая типизация, сборка мусора, интерпретатор и прочие облегчающие жизнь вещи.
Я б, например, лисп использовал для обучения, причём лисп-1, где нет разницы между обычным и функциональным значением символа. Но и лого тоже выглядит неплохо, хотя его синтаксис и переусложнён для его семантики.
Статья слабая на мой взгляд. Если уж писать о PascalABC.NET на Хабре, то можно было бы более выразительные примеры привести. Которые есть и на сайте в примерах PascalABC.NET и в Телеграм-канале, и на канале youtube.
Мы когда создавали PascalABC.NET 15 лет назад, то конечно Паскаль был очень популярен в обучении. Но уже тот Паскаль устаревал катастрофически. Уже даже школьники не хотели на нем писать.
Поэтому вначале за основу был взят C# как один из лучших языков сегодня по языковым концепциям. Собственно, PascalABC.NET всегда - в каждый момент времени рассматривался как язык для обучения современному программированию.
И да - он не про использование в энтерпрайз приложениях - он - про лучшие языковые концепции и библиотечные функции современных языков.
По статье - я бы рекомендовал автору лучше её оформить - везде имена функций писать с большой буквы и не делать такие ужасные отступы между колом и основным текстом (не знаю, можно ли это на Хабре).
По факту: мы про обучение знаем всё, поэтому можем с уверенностью сказать, что старые представления об обучении программированию сейчас мало годятся. Мы сталкиваемся с профессионалами, которые говорят - этому сложно учить, надо школьников учить в красивых средах с красивыми окошками. Но - нет, мир обучения программированию драматически изменился за эти годы, как и мир ИТ. Школьники абсолютно свободно понимают лямбды - и быстрее чем профессиональный программист. Цепочки методов в стиле Arr(1..10).Where(x -> x.IsOdd).Select(x -> x * x).Print воспринимаются абсолютно свободно и сочетаются с алгоритмическим кодом в разных пропорциях. Совершенно естественно воспринимается использование словарей в задачах. Некоторые преподаватели, готовящие школьников к ЕГЭ, активно используют весь этот LINQ для сокращения кода на компьютерном экзамене - тут я не всегда с ними согласен - краткость - далеко не всегда хорошо.
Тут еще нужно понимать, что PascalABC.NET плохо понимается многими, причем по-разному. Кто-то видит в нем игрушечный учебный язык для базового обучения младшеклассников, и тогда применение всех этих автоклассов, кортежей и перегрузки операций раздражает со словами "понапихали". Кто то видит в нем чистый язык Паскаль и раздражается любым новым конструкциям - в том числе автовыводу типов, описанию переменных внутри блока и попытке вообще отказаться от begin-end.
PascalABC.NET - это конечно процентов на 30 - классический Паскаль, всё остальное - концепции современных языков программирования. По-существу, это - новый язык, и с этим трудно смириться.
Но правы те. кто пишет, что время его уходит. Сейчас в российских школах с упорством, достойным лучшего применения, пытаются вычеркнуть Паскаль и перейти на Питон. Действительно, Питон при всех его недостатках лучше старого Паскаля - так уж точно. Но как писали здесь - имеет свои родовые травмы. Мешающие кстати говоря обучению. Но - питонизация школьного образования - необратимый процесс :) А ценность Питона, как уже писали здесь, "слегка преувеличена".
В отношении обучения мне нравится Котлин - несомненно - компактный выразительный код во многих случаях, и по языковым концепциям очень хорош. Но до школ вряд ли дойдёт. Школы вообще умудрились ограничить в последнем их ФГОС список допустимых языков, на которых можно учить.
Начал писать свокй коммент по этой теме, и понял, что в формат комментария не укладываюсь.
Так что ловите мнение школьного учителя информатики по вопросу выбора языка (и про ситуацию с изучением информатики в школах - в целом): https://habr.com/ru/articles/783900/
Ох ты, крутая статья, хорошо структурированная и написанная на одном дыхании.
Да, с проблемами школьной информатики знаком - озвучивали их многие школьные учителя.
Здесь ей-богу проблема выбора языка программирования отходит на второй план - тут бы учебник нормальный и ФГОС бы тоже нормальный.
ЕГЭ по информатике у нас в ВУЗе тоже достаточно мало значит. Основная масса детей, которые готовились только к ЕГЭ, сдавали его на Питоне "не приходя в сознание" и сразу его забыли после сдачи. Переучивать с этой методики изучения языка программирования для сдачи ЕГЭ приходится с кровью.
a:= ReadReal('a =');
Это выдаёт игрушечный язык, заточенный под чисто учебные задачи. В проде это ни разу не пригодится.
Странный вывод. По такому же принципу можно сказать, что такой код в проде тоже не пригодится и тогда вообще все Паскали "игрушечные"
var a: real;
write('a= ');
read(a);По факту, это удобное средство для совсем небольших утилит и для тестовых целей. Не вижу в этом ничего плохого
Я хочу сказать, что смешивать ввод и вывод в одной функции это шорткат чисто для студенческих лаб, где такой паттерн встречается постоянно. А приучать юных программистов к таким функциям - плохой стиль. Лучше сразу выстраивать правильные абстракции и разделять мух от котлет.
Это прямо конечно выдаёт игрушечный язык:a = input("Введите a:")
Повсюду - игрушечные языки ))
В проде - не нужно - не пользуемся
ИМХО, любой ЯП недалёкого будущего (или актуального настоящего) должен быть асинхронным - и предлагать эту модель программирования как основную
Причём писать так (C#)
var s = Console.In.ReadLineAsync().Result; //К "сожалению" так нельзя на C# s = await Console.In.ReadLineAsync() ну потому что тогда нет смысла в асинхронности
Console.WriteLine(s);поэтому вот так будет практичнее
var s = Console.In.ReadLineAsync().ContinueWith(
(Task<string> t)=>Console.Out.WriteLineAsync(t.Result),
TaskContinuationOptions.ExecuteSynchronously
);
//тут всё-равно блокируется поток до выполнения всей конструкуии
//кстати без опции TaskContinuationOptions.ExecuteSynchronously вообще не срабатывает продолжениеНо это как-то многословно, да и к тому же это у .NET тут фейковая асинхронность консоли - блокирующая основной поток
А вот так было бы куда красивее
using System.AsyncConsole
ReadLine -> WriteLine(it)
//а если нужно в несколько раздельных потоков
var src = GetAnyAsyncSource() //некий поток-источник
var r1 = default src.ReadLine //тут не вызова команды ReadLine но есть определение типа результата и резервирование памяти
var r2 = default System.AsyncConsole.ReadLine
using System.AsyncConsole
Parallel
|-> ReadLine -> WriteLine("1:"+it) -> r2 //Первый поток
|-> r1 = src.ReadLine -> WriteLine("2:"+it) //Второй поток
|-> WaitAll -> ?(r1!=r2) -> //некая обработка (третий поток - стартует после завершения предыдущих двух)
// и тут какой-то код, который идёт параллельно всему блоку параллельной обработки выше - т.е. 4-тый потокСуть в том, чтобы сразу на стадии архитектуры кода разделять обработку на возможно параллельные потоки - и даже для ввода вывода даже в консоли.
Может показаться сложнее чем a = input("Введите a:") но проку куда выше
Кстати, код выше (с параллельной обработкой) "правильнее было бы вообще упростить" (без выделения четвёртого потока)
var src = GetAnyParallelSource() //некий поток-источник,
//который уже заранее помечен как приоритетно параллельный
using System.ParallelConsole //Гипотетическая параллельная консоль (иметь такую в ядровой библиотеке смысла нет, но сделать можно)
ReadLine -> WriteLine("1:"+it) -> out var r2 //out var - переменная будет доступна вне цепочки (по сути можно опустить "out" т.к. чисто локальные переменные цепочки можно вводить просто как local и_далее_идентификатор)
src.ReadLine -> WriteLine("2:"+it) -> out var r1
?(r1!=r2) -> //некая обработка Смысл тут в том, что оба источника (и "ParallelConsole" и возвращаемый "GetAnyParallelSource()" помечены как приоритетно параллельные - т.е. обращение к ним может быть распараллелено компилятором без указания от программиста (хотя программист всегда может хунтами этим управлять вручную - запрещая или явно разрешая или явно требуя, т.к. для компилятора по умолчанию это лишь возможность неявного распараллеливания).
А код то ниже полностью написан в синхронном стиле. Но в виде 3-х отдельных цепочек обработки
Но компилятор может сам принять решение какие цепочки распараллелить - причём если имеется поддержка динамической рекомпиляции или хотя бы сбор статистики использования для компиляции следующего ручного билда - то это решение может ещё и пересматриваться по результату эксплуатации прошлого билда.
Две цепочки тут полностью независимы (возможными побочными эффектами пренебрегаем - её анализ либо на совести компилятора либо программиста - указать её наличие - но это не бест практик - наличие побочки - тем более когда явно имеем пометку источников как приоритетно параллельные).
Третья цепочка имеет явную зависимость от двух других так что 100% должна ожидать их полного выполнения.
Ниже могла бы быть ещё одна цепочка - независящая от предыдущих - она бы могла бы быть независимо и распараллелена!
Вот это программирование будущего! А не какой-то там паскаль или си шарп!
Попробовал на PascalABC.NET - работает )
##
uses System.Threading.Tasks, System;
Console.In.ReadLineAsync.ContinueWith(
procedure(t: Task<string>) -> Console.Out.WriteLineAsync(t.Result),
TaskContinuationOptions.ExecuteSynchronously
)Согласен, что в языке можно сделать какую-то конструкцию, которая реализует этот паттерн и позволяет записывать асинхронные запросы в цепочки.
Несомненно, асинхронность - важнейший атрибут сегодняшнего программирования. У меня всегда были какие-то неясные мысли чтобы этому как-то учить младшекурсников или даже школьников. Пока дальше метода .AsParallel дело не доходило.
Со школьниками особо интересно и заманчиво. Как раз за счет хороших конструкций языка программирования будущего этот код можно сделать особо простым и записывать в виде цепочек методов или ввести еще какой-то синтаксис типа ваших разделителей | , вытягивая всё это в пайпы. У нас - богатый опыт обучения школьников Linq - они очень хорошо в него вгрызаются, и все эти лямбды идут легче лёгкого. Так что это бы пошло - я знаю, как и где. Более того - мы устраиваем конференции для учителей - это вполне можно было рассказать и в этой аудитории. Всегда есть прогрессивные учителя, которые гонятся не только за показателями ЕГЭ.
Труд конечно это большой. Даже реализация async - await для компилятора со всеми частными случаями - нетривиальная задача. А это ещё и поверх.
Но очень заманчиво. Если бы такой язык будущего, да еще и для обучения - я бы был двумя руками за.
Согласен, что в языке можно сделать какую-то конструкцию, которая реализует этот паттерн и позволяет записывать асинхронные запросы в цепочки.
Несомненно, асинхронность - важнейший атрибут сегодняшнего программирования. У меня всегда были какие-то неясные мысли чтобы этому как-то учить младшекурсников или даже школьников. Пока дальше метода .AsParallel дело не доходило.
Дело не просто в поддержке асинхронных цепочек вызовов - дело в красоте и простоте их описания, и, разумеется, надёжности получаемого кода.
Что на PascalABC.NET что на C# это выглядит, на мой взгляд, коряво, надёжность тоже требует особого подхода со стороны программиста, и применение некоторых специальных техник, отличных от синхронной модели. А я ратую за то, чтобы декларация асинхронного исходного кода был практически не отличима от синхронной. Более того - окончательное решение о применении распараллеливания должен принимать не программист (хотя я тут утрирую - конечно "последнее слово" всегда должно быть на стороне программиста - но это уже совсем явные указания для редких случаев), а компилятор-среда исполнения-рекомпилятор - именно исходя из реальной эксплуатации (если не делать ставку на динамическую рекомпиляцию, можно даже сразу генерировать несколько версий итогового кода, выбирая между разными версиями уже динамически, в зависимости от текущих условий выполнения) - и исходный код должен, условно (к этому надо стремиться), равнозначно компилироваться как параллельный, так и синхронный код - с асимптотически нулевыми лишними издержками (если бы его изначально вручную проектировали под каждую такую модель).
Вот тогда можно и студентов и даже школьников сразу натаскивать на асинхронное программирование! Не ломая им мозг!
Как раз за счет хороших конструкций языка программирования будущего этот код можно сделать особо простым и записывать в виде цепочек методов или ввести еще какой-то синтаксис типа ваших разделителей | , вытягивая всё это в пайпы
Вот это я и пропагандирую. Актуальные ЯП (за исключением узко специализированных как Elixir и, отчасти, современные версии некоторых функциональных и логических ЯП) мало адаптированы именно на асинхронное программирование. Даже такие современные ЯП как Kotlin или Go синтаксически не далеко ушли от синхронной модели. Несмотря на то, что на серверах уже сотни ядер и распараллеливание рулит уже более 10 лет. Но, видимо пока хватает модели задач/обещаний и деления на, условно, изолированные потоки обслуживания внешних запросов. Большой революции в распараллеливании пока не случилось. Вот придут сотни ядер на десктопы (про серверы я умолчу) - вот тогда распараллеливание станет куда более актуальным - ибо десктопные задачи не процессные и тут именно надо оптимизировать практически однопоточный код.
Впрочем. на десктопы сотни ядер может и не придут (я не про проф. рабочие станции) - т.к. есть чётка тенденция вынесения всех процессов в облака и на сервера (впрочем и для проф. рабочих станций) или даже гетерогенное распределение по сети исполнителей. Но на серверах (всё-таки, умолчать про них не удалось) будет концентрироваться условно однопоточный поток инструкций (прошу прощения за тавтологию), который так же будет большое желание разнести по десяткам и сотням ядер (или вообще по разным компьютерам в сети) - и задача целенаправленного исходного асинхронного программирования будет актуальна как никогда!
Впрочем - не только в асинхронном программировании дело. А вообще - в новых концепциях программирования, в т.ч. с применением AI генеративных моделей. Простое программирование на чётких инструкциях процессору в будущем, скорее, удел системного программирования (да и то, всё более и более ограниченного). Будущее за декларативным программированием - в какой форме я не знаю, логические языки уже изжили себя, функциональное программирование в чистом виде сложно в освоении и отладке (но его подходы хороши симбиозе с другими парадигмами), возможно что-то типа SQL (или LINQ) в новой расширенной форме может стать тем граалем программирования будущего!
Я выше привёл пример кода на несуществующем ЯП - это моё концептуальное виденье языка программирования будущего. Я привёл лишь малу часть его возможностей, и в не самой упрощённой форме (чтобы было больше понимания), да и сам ЯП далёк до совершенства - это всё пока очень черновой синтаксис, постоянно меняющийся в деталях. Но я просто хотел показать концептуально иной подход - чем классические ЯП. Показав простоту и мощь, почти недоступную текущим языкам, и намекнув - что новые ЯП нужно развивать не по лекалам двадцати, и тем более, пятидесяти-летней давности, а смотреть в будущее, и привносить что-то революционно новое, удобное, полезное и мощное в фактическом применении! И тут надо развивать не только сам синтаксис (и не тащить в него устаревшие концепции), но и компилятор, и исполнительную среду, и IDE, и различный вспомогательный инструментарий, и документацию!
И в школе/институте тогда уже учить такому ЯП, который будет и прост в освоении, и актуален и силён в практическом применении!
Но это явно не первый ЯП для изучения. Начинать надо в младшей школе с графических систем программирования, потом переходить на простейшие текстовые - командные ЯП, и лишь потом уже ближе к старшим классам - на более серьёзные практичные ЯП.
Кстати, "|->" у меня это универсальная инструкциях объединения нескольких "параллельных" цепочек команд, и в общем случае не обязательно подразумевает параллельное исполнение (ключевой там является команда "Parallel", принимающая поток этих цепочек) - синтаксис у этого ЯП очень гибкий, и в целом достаточно простой (но требует некоторого освоения небольшого числа ключевых концепций, порой далёких от классических ЯП, например у него очень мало ключевых слов - в основном это только операторы, зато очень много команд и аннотаций - максимальный уровень унификации синтаксиса).
P.S.
На всякий случай замечу, что хоть выше пример идёт про консоль ввода вывода - это просто пример, и на месте консоли и команд чтения записи может быть всё что угодно! Более того, концепция такого ЯП подразумевает абсолютизацию потока - практически всё есть Поток (хоть данные, хоть инструкции - команды) - поэтому корректнее работать с Поток с основе универсальных команд - в данном случае вместо "ReadLine" и "WriteLine" это будут команды "Consume" и "Send" или их аналоги в виде операторов "<<<" и ">>>" соответственно (в этих командах подразумевается работа с Потоком порциями, и что формат порции для потоков консоли уже настроен как ограниченный некоторым разделителем строки - что, безусловно, можно настроить как для исходного Потока так и для некоторого Прокси-потока - если он будет задан посредником представления доступа к исходному Потоку). Такой подход ещё более унифицирует, абстрагирует и, в то же время, упрощает код работы с данными и любыми Потоками, какой бы природы и реализации они ни были. Но любой поток может быть конкретизирован вспомогательными командами - как данном случае "ReadLine" и "WriteLine"
Понимаю. Вопрос - в модели реализации таких конструкций. Я в асинхронном программировании не разбираюсь глубоко. На мой взгляд, путь один - такая модель возможно появится вначале в каком-то промышленном языке и уже потом - в других языках - попроще как синтаксический сахар. Или этому будут предшествовать научные публикации, которые будут показывать полноту и корректность - как было с технологией LINQ. И уже потом дело дойдет до языков, на которых можно учить. А возможно проблема просто сложна, и никто не придумает такую модель в ближайшее время.
То что вы пишете про декларативные языки и новые концепции типа AI - это больше похоже на какой-то DSL-язык. Не думаю, что декларативные языки полностью вытеснят обычные на поле универсальных языков в сколько нибудь обозримом поле. Я скорее думаю, что языки разного уровня будут дружить друг с другом, и их можно будет комбинировать в одной программе.
А школа и институт - это всегда отражение того, что существует в профессиональном программировании. И приходит туда всё позже и в изменённом виде. За неким исключением - например, курс по функциональному программированию в университетах распространен, в промышленном программировании - есть только какие-то его элементы.
И еще школа уж по крайней мере - это не про профессиональное программирование. Здесь в обучении - своя логика, как и в любой другой области. И когда профессиональные программисты агрессивно советуют в некоторых соседних топиках, как надо учить школьников программированию, ни разу этим не занимавшись, это называется "профессиональная деформация". И выбор инструментов тут всегда за учителем. Ему учить, а не советчикам.
На мой взгляд, путь один - такая модель возможно появится вначале в каком-то промышленном языке и уже потом - в других языках - попроще как синтаксический сахар.
Не всегда так - зачастую революционные вещи появляется в, так называемых, академических ЯП или в каких-то совсем любительских ЯП - а потом уже, после обкатки, перебираются на более распространённые языки программирования - причём не сразу - тут тоже есть как более прогрессивно развивающиеся ЯП, как, например, C# и более консервативные , как, например Java - последние уже тянут фишки после обкатки на более прогрессивных (но это не всегда всё именно так)
То что вы пишете про декларативные языки и новые концепции типа AI - это больше похоже на какой-то DSL-язык.
Да вполне так может казаться. Но я всё-таки говорю о ЯП широкого профиля. Всё-таки за декларативной моделью стоит обычная кодогенерация (в промежуточный ЯП - даже набор ЯП где га верхнем уровне будет впролне себе классический ЯП - это необходимо как для упрощения процесса, так для его разбиения на отдельные части-модули - где далее уже будут трудиться другие решения, оптимизированные под свои задачи, так и для более высокого уровня совместимости с разными платформами и библиотека, так для эффективного анализа и отладки создаваемого кода) , основанная на статистике и генеративных AI алгоритмах.
Да и код, который я привожу в примерах, всё-таки, всё ещё очень близок к классическим ЯП - да я говорю, что он декларативный - но на вид он не далеко ушёл от императивного ОО программирования с функциональными фишками (а фишками АОП)!
Не думаю, что декларативные языки полностью вытеснят обычные на поле универсальных языков в сколько нибудь обозримом поле
Я этого и не говорю. Во-первых, это очень длительный процесс. Во-вторы, как выше заметил - всё-таки после декларативного ЯП на выходе будет более классический код - и так будет очень долго (выше описал почему). В-третьих, "всегда" будут области, где эффективнее и надёжнее писать на каком-то классическом ЯП. Но тут лишь вопрос в соотношении, изменении этого соотношения во времени 100..1000...1000000 лет...
к. Не думаю, что декларативные языки полностью вытеснят обычные на поле универсальных языков в сколько нибудь обозримом поле
Я учил информатике в школе. И мне кажется, у декларативного ЯП больше шансов стать более удобным для обучения, чем у классических ЯП (но не берусь утверждать что тот синтаксис, что предлагаю я для этого подойдёт - но у меня это просто пример, возможны и другие реализации идеи в будущем). Просто ребёнку проще что-то утверждать: запрашивать, задавать и требовать - чем вникать в тонкости инструкций обработки процессором. В этом сила декларативного подхода. Поэтому, скажем, школьнику проще освоить (я про базовый уровень) SQL язык, чем, скажем, Питон. Но... если начать углубляться в реляционную алгебру - то вот тут уже нужен, как минимум, багаж знаний о теории множеств - а это уже как минимум старшая школа (а скорее уже ВУЗ). Но я пробовал на старшеклассниках - в принципе усваивают! Но им до этого информатику практически не преподавали - тем более программирование.
Но начинать учить детей нужно с куда более раннего возраста и с куда более простыми системами "программирования" (графическими в первую очередь), а потом детям, скорее будет интересно продолжать программирование в области игр. СУБД - это только для старшекласников.... но кто знает - может со временем можно и в средней школе замутить!
По изначальному комментарию было сложно понять к чему именно претензия
Понимать разницу ввода и вывода безусловно необходимо, но я не вижу проблемы в смешении в простых случаях, если понимаешь что делаешь. Не такой уж это и редкий случай, когда чёткое разделение избыточно
А приучать юных программистов к таким функциям - плохой стиль
Если Вы тут видите какой-то сугубо преподавательский момент, то ничего не могу сказать. Как я писал выше в комментариях, вопросы обучения меня мало волнуют
Паттерн "приглашение к вводу" и затем ввод собственно очень распространен у школьников и как верно заметили - у студентов. В простых программах.
Но прошу заметить - это тоже прод. Только это - прод для школьников. У них - свой прод. И свои паттерны. Относиться к ним с ненавистью - зачем? Это реально помогает повторяющиеся куски кода писать коротко.
Что же касается студентов, то мы с ними пишем так:
uses NUnitABC;
uses MyFuncs;
const eps = 1e-10;
[Test, Combinatorial]
procedure Test4([Values(1,3,5,7)] a: real;
[RangeAttribute(1,200)] b: real);
begin
Assert.AreEqual(Hypot(a, b), Sqrt(a * a + b * b), eps);
end;
begin
end.Затем - запуск модульных тестов из IDE. И вводить ничего не надо.
Pascal. В середине 80 -х мне мне потребовался измерительный комплекс для проведения испытаний. Пошёл коллегам по выч. технике. Он загорелись идеей и на ДВК-2 состряпали мне систему с АЦП и шестью каналам : датчик расхода, термопара, тяга, и два датчика давления. Пошёл к программистам и тут случилось фиаско: они работали только на Фортране и понятия не имели как это запрограммировать. Друг из МАИ дал мне небольшую брошюру по Паскалю и дискету. На дискете был тот самый виртовский паскаль для RT-11SJ. Компилятор позволял в тексте делать ассемблеровские вставки. Короче программное обеспечение написал сам. Осциллограммы ушли в прошлое, а подался в программисты Pascal => C => C++ => C#
Основные отличия PascalABC.NET