Деление класса - это сложный вопрос - тут много групповой психологии играет роль.
Нои плюсы есть - тут очень хорошо надо подумать над наиболее грамотным подходом
На мой вгзляд все три подхода имеют право на жизнь:
Разделение не класса на группы, а детей на разные классы - это попрактикуется уже давно. Типа гуманитарный класс, математический класс, класс углублённого изучения иностранного языка, класс дебилов - это, в общем-то, шута - но она неизбежная! Аналогично возможно разделение на разные школы - что ещё эффективнее и менее психологически проблемно!
Создание широкого спектра факультативов - особенно по всем предметам, по которым есть олимпиады, необязательные экзамены в школах и обязательные специализированные экзамены в ВУЗах и Коледжах. Но дети сами вольны выбирать что им интересно. Но увы - это всегда за допплату (впрочем углублённые школы и классы обычно тоже не бесплатны) - но это уже другой вопрос.
На самом деле, можно и более явно поделить детей на группы (но не ранее средней школы), как это практикуется "на западе" - когда у детей есть как общие уроки, так и раздельные (но это не совсем факультатив - их посещение обязательно - но выбор какие посещать всегда индивидуальный (но экзамены будут реальными) - просто нужно набрать некое минимальное количество - даже может быть условно по бесплатной схеме (в рамках основной схемы обучения, необязательно полностью бесплатной) - сверх уже факультатив за доплату - здесь уже если и будут экзамены, то чисто информативные - не на что не влияющие, хотя.... можно комбинированную схему когда к минимальной выбранной части ребёнок плюсует дополнительные предметы - уже за доплату - но тоже с реальными экзаменами - но общий бал в конце четверти/года должна выводить по итоговым балам всех экзаменов - так что в сумме с большего числа сданных предметов можно набрать больше, чем только по минимальной части - если с какими-то выбранными предметами будет всё не очень хорошо).
И я за то, чтобы освободить детей от всякой ерунды - и не углублять их в то, что им не интересно (но да в младшей и средней школе надо стараться заинтересовывать разными сферами - это не простая задача и решать её можно не только не столько широким спектром вдалбливаемых уроков).
Ну а факультативы хороши как для расширения кругозора, так и для натаскивания по проседающим предметам (а-ля репетиторство), так и для углубления в тематику для сдачи профильных необязательных экзаменов (или обязательных при поступлении в индивидуально выбираемые ВУЗы и Колледжи).
И да - факультативы не обязательно должны быть очными - сейчас в мире интернет-технологий школьное онлайн обучение тоже очень востребовано и эффективно! Этим не стоит пренебрегать.
И ещё - я, вот категорически против, чтобы в школах не в профильных классах углублялись в предметы, по которым нет обязательных экзаменов!
Как и против "обязательной" навязывания всякой необязательной для жизни шелухи - но если есть модель выбора предметов - то школьники может сам выбрать эти предметы, коли к другим душа не лежит - и просто проспать" их - ничего серьёзно там всё-равно спрашивать не будут - и спокойно потом, после 9-го класса, идти в ПТУ, ну или в "бригаду" - кому что ближе (армейский призыв то позже, а проф. армейское образование - это уже профильное военное училище)
Моё мнение разностороннее обучение в школе - это всё-таки уже не есть хорошо - нужно быстрее переходить к более узкой специализации. Но для этого надо ещё в младших классах успеть втиснуть в гибкие молодые мозги как можно больше важных общих знаний (и это не так просто - над этим ещё надо поработать - тут нужны как технически нововведения, так и психологические и негидрофизические новации) - и начинать учиться им нужно пораньше - хотя бы с 3-4-х лет (да детство тоже целиком отнимать не стоит, но ужать нужно) и учится в школе подольше (оставив ВУЗы и Колледжи действительно для тех кто хочет углубляться в какие-то серьёзные профессии или идти в науку; впрочем бездарей после 9-го класса тоже особо задерживать не стоит, но я не считаю, что нужно стремиться, чтобы их было много - в отличии, наверное от ряда "умников" в администрации правительства - считающих, что лучше больше глупого населения, чем умного - так ими управлять проще).
Отчасти в защиту информатики скажу так - что наряду с математикой и русским языком - это должно быть основополагающим предметов в школе (я бы ещё и про физкультуру не забывал бы) - в современном мире эта тройка (физкульт - это отдельная тема) будет являться основополагающим базисом жизнедеятельности любого человека! И в т.ч. без основ информатики в современном обществе не обойтись будет так же как и без математики. Чем бы человек не стал заниматься: литературой, физикой, химией, биологией, юриспруденцией, психологией, медициной... (не говоря уже о рабочих и строительных специальностях, ну разве что дворникам не особо нужно - но их же роботы заменят, даже логистам (а-ля грузчикам не повредит - но их тоже роботы заменят)); даже если само программирование и не понадобится - то развитие интеллекта которое оно даёт - будет очень полезным, ну а навыке работы с компьютерами будут нужны всем! А уж потребность в программистах и прочих айтишниках пока будет расти в геометрической прогрессии! И благодаря им потом почти всех заменят роботы - но это уже другая тема!
Но я так же замечу, что предлагаемое мной ранее разделение специализации подразумевает и ранее выделение направления по информатики - как углублённо изучаемое как в отдельных специализированных школах, так и в отдельных профильных классах - что должны быть практически в каждой городской школе (разве что в сельских школах с этим будут сложности - но тут можно сразу предлагать удалённое обучение - в мире интернет технологий это уже не проблема). Для тех школьников, кто действительно будет хотеть более глубоко развивать себя как айтишник, участвовать в олимпиадах по информатике и выбирать информатику как экзамен по выбору и устраиваться в соответствующие ВУЗы и колледжи - вот тут можно и Си в старших классах изучать (но не C++ - это форменное издевательство над людьми - его изучение это должен быть осознанный выбор каждого, например в ВУЗах на очень профильных факультетах не для всех). Вот таких классах можно учить и софт писать.
А классах же другой направленности информатику тоже надо преподавать - но в другом ключе - скорее в плане работы со специализированным софтом - но так как практически любой вид софта будущего скорее всего будет иметь возможность алгоритмического подхода - то его тоже надо изучать, и программы писать тоже - лишним не будет - но тут нужны более простые ЯП. А до старших классов вообще всё должно быть в игровой форме!
Такого моё мнение! Просьба необоснованно не минусовать - как тут уже делали с моими комментариями!
Мне кажется это большая ошибка фантастов прошлого! Но... может просто мы ещё не дожили до того "ещё далёкого" будущего - но, моё мнение, что в нём индивидуальные летательные аппараты будут выглядеть совершенно иначе, а не как это уродство и как это предполагало большинство фантастов прошлого и настоящего!
Например, я скорее поверю в эпоху возрождения аэростатов (в т.ч. маленьких) чем в винтовую или реактивную летательную технику (или на антигравах) - если научатся делать воздушные шары невзрывоопасными и устойчивыми к сильным ветрам (но шансы этого крайне не велики на Земле, хотя на Марсе или Венере, Титане - куда выше).
Ну или "полёт" будет посредством каких-то электромагнитных процессов!
Но куда выше шансы в том, что люди вообще практически потеряют потребность индивидуально перемещать свои тела - и царствовать будет виртуальная реальность и аватары/суррогаты! А перемещения скорее будут в трубах и больше под землей (ну или в космосе)!
Вот она "Правильная" вики, распространяющая только "Правильные" мысли для "Правильной" аудитории от "Правильных" авторов - для "Правильной" страны, "Правильно" доступная в этой стране, "Правильно" независимо от мнения и санкций других!
Эдакий "Правильный" аналог "Большой советской энциклопедии" и газете "Правда" в одном "Правильном" флаконе!
Вопрос только, а "Правильно" ли её вообще читать?
Ответ: ну как ничего другого не станет - то сами сделаете свой "Правильный" выбор! Хотя свой "Правильный" выбор россияне уже "Правильно" будут делать несколько раньше - этой "Правильной" весной в этот "Правильный" год!
Хотя господин Преображенский (М. Булгаков) уже всё давно ПРАВИЛЬНО сказал на тему чтения "советских газет"
На мой взгляд все эти аэротакси и одноместные коптеры не более чем игрушка для богатых - как спорткары или спортивные самолёты - ограниченно потешить свой самолюбие в локализованной тихой местности, и похвастаться перед друзьями - на этом всё!
И будущего, кроме как коллекционного или как хобби, у них нет!
Хотя "не требующего сертификации пилота от Федерального управления гражданской авиации США" звучит очень дерзко - хотя и ложка дёгтя всё-равно есть: "создатели потребуют от всех будущих пилотов пройти комплексную лётную подготовку компании. От владельцев Helix также потребуют летать только в незагруженных районах и держаться подальше от аэропортов. Кроме того, покупатели должны быть старше 18 лет, весить менее 100 кг и иметь рост до 196 см" - так что круг потребителей сужается (хотя не очень сильно) - но не думаю, что это приведёт к массовому применению (даже при снижении цены $190 в несколько раз). И рано или поздно аукнется чем-нибудь не хорошим!
Беспилотные коптеры тоже ранее не были повсеместно запрещены - а сейчас запретов даже на них всё больше и больше!
Но да - я тут очень большой скептик, это лишь моё мнение!
Согласен, что в языке можно сделать какую-то конструкцию, которая реализует этот паттерн и позволяет записывать асинхронные запросы в цепочки.
Несомненно, асинхронность - важнейший атрибут сегодняшнего программирования. У меня всегда были какие-то неясные мысли чтобы этому как-то учить младшекурсников или даже школьников. Пока дальше метода .AsParallel дело не доходило.
Дело не просто в поддержке асинхронных цепочек вызовов - дело в красоте и простоте их описания, и, разумеется, надёжности получаемого кода.
Что на PascalABC.NET что на C# это выглядит, на мой взгляд, коряво, надёжность тоже требует особого подхода со стороны программиста, и применение некоторых специальных техник, отличных от синхронной модели. А я ратую за то, чтобы декларация асинхронного исходного кода был практически не отличима от синхронной. Более того - окончательное решение о применении распараллеливания должен принимать не программист (хотя я тут утрирую - конечно "последнее слово" всегда должно быть на стороне программиста - но это уже совсем явные указания для редких случаев), а компилятор-среда исполнения-рекомпилятор - именно исходя из реальной эксплуатации (если не делать ставку на динамическую рекомпиляцию, можно даже сразу генерировать несколько версий итогового кода, выбирая между разными версиями уже динамически, в зависимости от текущих условий выполнения) - и исходный код должен, условно (к этому надо стремиться), равнозначно компилироваться как параллельный, так и синхронный код - с асимптотически нулевыми лишними издержками (если бы его изначально вручную проектировали под каждую такую модель).
Вот тогда можно и студентов и даже школьников сразу натаскивать на асинхронное программирование! Не ломая им мозг!
Как раз за счет хороших конструкций языка программирования будущего этот код можно сделать особо простым и записывать в виде цепочек методов или ввести еще какой-то синтаксис типа ваших разделителей | , вытягивая всё это в пайпы
Вот это я и пропагандирую. Актуальные ЯП (за исключением узко специализированных как Elixir и, отчасти, современные версии некоторых функциональных и логических ЯП) мало адаптированы именно на асинхронное программирование. Даже такие современные ЯП как Kotlin или Go синтаксически не далеко ушли от синхронной модели. Несмотря на то, что на серверах уже сотни ядер и распараллеливание рулит уже более 10 лет. Но, видимо пока хватает модели задач/обещаний и деления на, условно, изолированные потоки обслуживания внешних запросов. Большой революции в распараллеливании пока не случилось. Вот придут сотни ядер на десктопы (про серверы я умолчу) - вот тогда распараллеливание станет куда более актуальным - ибо десктопные задачи не процессные и тут именно надо оптимизировать практически однопоточный код.
Впрочем. на десктопы сотни ядер может и не придут (я не про проф. рабочие станции) - т.к. есть чётка тенденция вынесения всех процессов в облака и на сервера (впрочем и для проф. рабочих станций) или даже гетерогенное распределение по сети исполнителей. Но на серверах (всё-таки, умолчать про них не удалось) будет концентрироваться условно однопоточный поток инструкций (прошу прощения за тавтологию), который так же будет большое желание разнести по десяткам и сотням ядер (или вообще по разным компьютерам в сети) - и задача целенаправленного исходного асинхронного программирования будет актуальна как никогда!
Впрочем - не только в асинхронном программировании дело. А вообще - в новых концепциях программирования, в т.ч. с применением AI генеративных моделей. Простое программирование на чётких инструкциях процессору в будущем, скорее, удел системного программирования (да и то, всё более и более ограниченного). Будущее за декларативным программированием - в какой форме я не знаю, логические языки уже изжили себя, функциональное программирование в чистом виде сложно в освоении и отладке (но его подходы хороши симбиозе с другими парадигмами), возможно что-то типа SQL (или LINQ) в новой расширенной форме может стать тем граалем программирования будущего!
Я выше привёл пример кода на несуществующем ЯП - это моё концептуальное виденье языка программирования будущего. Я привёл лишь малу часть его возможностей, и в не самой упрощённой форме (чтобы было больше понимания), да и сам ЯП далёк до совершенства - это всё пока очень черновой синтаксис, постоянно меняющийся в деталях. Но я просто хотел показать концептуально иной подход - чем классические ЯП. Показав простоту и мощь, почти недоступную текущим языкам, и намекнув - что новые ЯП нужно развивать не по лекалам двадцати, и тем более, пятидесяти-летней давности, а смотреть в будущее, и привносить что-то революционно новое, удобное, полезное и мощное в фактическом применении! И тут надо развивать не только сам синтаксис (и не тащить в него устаревшие концепции), но и компилятор, и исполнительную среду, и IDE, и различный вспомогательный инструментарий, и документацию!
И в школе/институте тогда уже учить такому ЯП, который будет и прост в освоении, и актуален и силён в практическом применении!
Но это явно не первый ЯП для изучения. Начинать надо в младшей школе с графических систем программирования, потом переходить на простейшие текстовые - командные ЯП, и лишь потом уже ближе к старшим классам - на более серьёзные практичные ЯП.
Кстати, "|->" у меня это универсальная инструкциях объединения нескольких "параллельных" цепочек команд, и в общем случае не обязательно подразумевает параллельное исполнение (ключевой там является команда "Parallel", принимающая поток этих цепочек) - синтаксис у этого ЯП очень гибкий, и в целом достаточно простой (но требует некоторого освоения небольшого числа ключевых концепций, порой далёких от классических ЯП, например у него очень мало ключевых слов - в основном это только операторы, зато очень много команд и аннотаций - максимальный уровень унификации синтаксиса).
P.S.
На всякий случай замечу, что хоть выше пример идёт про консоль ввода вывода - это просто пример, и на месте консоли и команд чтения записи может быть всё что угодно! Более того, концепция такого ЯП подразумевает абсолютизацию потока - практически всё есть Поток (хоть данные, хоть инструкции - команды) - поэтому корректнее работать с Поток с основе универсальных команд - в данном случае вместо "ReadLine" и "WriteLine" это будут команды "Consume" и "Send" или их аналоги в виде операторов "<<<" и ">>>" соответственно (в этих командах подразумевается работа с Потоком порциями, и что формат порции для потоков консоли уже настроен как ограниченный некоторым разделителем строки - что, безусловно, можно настроить как для исходного Потока так и для некоторого Прокси-потока - если он будет задан посредником представления доступа к исходному Потоку). Такой подход ещё более унифицирует, абстрагирует и, в то же время, упрощает код работы с данными и любыми Потоками, какой бы природы и реализации они ни были. Но любой поток может быть конкретизирован вспомогательными командами - как данном случае "ReadLine" и "WriteLine"
Вы представляете что такое шахта "очень глубокая", в мегаполисе где коммуникации и прочее метро? это не просто дырка в земле, а водоотведение например, периодическая покраска-ремонт...а таких точек надо оочень много
Прекрасно представляю ибо метрострой "моя область".
Метро линии они занимают мизерные доли процента терриории по площади, а уж по объёму.... чисто какая-то "статистическая погрешность"
Коммуникации и так любят постоянно перекладывать - тоже мне проблема!
Всё это незначительная ерунда - особенно в век будущей автоматизации - когда большую часть работ как раз и будут выполнять автономные машины!
Более того - то же метро - скорее всего будет либо заброшено, либо переоборудовано в такую же ж/д сеть - которую я и так тоже прогнозирую в "чуть более отдалённой" перспективе так же полностью убирать под землю! А коммуникации как раз удобно будет тянуть, условно, вдоль таких тоннелей!
Но это всё-таки будущее. А в более насущном "настоящем" где-то на вторую половину XXI века и начало XXII (ранее то всё-равно такой проект никто не начнёт) много рыть в глубину не нужно - это начальная стадия - так что рыть можно неглубоко - метров на 20 - т.е. где-то 4 уровня глубь, а больше в ширину и длину! Ну и столько же наземная часть - лет на 100 хватит!
На машинах никто в такие Офисные центры не ездит, это анрил, я работал год центре москвы и ниразу не рискнул туда сунутся на авто, в тот момент когда я туда приходил на метро там была мертвая
И пока не начать мой проект так эта мёртвая пробка никуда априори не денется - разве что запретят вообще на личном транспорте ездить всем "кому не следует" (очень лимитированный список).
пробка вокруг и ни единого пустого двора-парковки
Плохо меня читали - капсулы как раз не будут стоять на этих парковка - это только погрузка/разгрузка
достаточное количество подъездных путей для подъехать-уехать чтобы пробок не было
Вот на этом действительно надо будет сосредоточить основной инженерный акцент. В старом капитальном фонде могут быть сложности - но ничего и их со временем перестроят. В итоге если всё будет забито - капсулы подвезут как можно ближе и высадят как в такси - это неличный транспорт (хотя с личными автономными капсулами по сути всё то же самое) - высадили - и тут же уехали сами искать куда запарковаться в другом месте! Совсем другой подход и кучу проблем долой!
Ага, если все 1000 будут выгружатся ровно 30 секунд, а не болтая по телефону
Не придирайтесь - накрайняк ввиду временные лимиты на погрузку/разгрузку - превышение - прогрессивные штрафы! Это всё мелочи! Тем более погрузка/разгрузка не будет идти в одну очередь - а это будет параллельный многоканальный процесс - периодический сбой нескольких точек не заблокирует весь процесс!
С разгрузкой/погрузкой хоть автобусов хоть метро всё не особо лучше в часы пик!
что значит везде? в любой точке города десятки капсул? просто лежат?
Условно говоря да - и я не вижу в этом проблему. Под точкой можно считать сектор в среднем с доступным ожиданием по городу не более 15 минут (за городом конечно в раза в 3 более - но это максимальное время; при наличии свободных капсул) - ещё раз повторю капсулы как и такси вызываются всё-таки заранее!
сколько будет стоить одна капсула? сколько будет стоить транспортировка 1 пассажира в такой штуке чтобы оно хотябы в ноль работало?
На это мне сложно ответить. Но цель, конечно, оптимизация расходов - так что это будет явно дешевле среднестатистического автомобиля (если считать вообще все, особенно для крупных городов), особенно когда сеть разрвьётся и обычный автотранспорт начнут вытеснять обложив непомерными побоорами - но личную капсулу же никто не отмеял - купите и владейте!
Да и сами капсулы тоже могут быть разные - 1-местные, 4-х местные, повышенной комфортности, представительские, грузовые.... как личные, так и общественные - тарифы буду разные! Главное - это унифицировать внешние габариты - но явно потребуется несколько стандартов, как и стоит проработать сцепку нескольких капсул в единый состав!
Лично моё мнение - в нынешних ценах стоимость одноместной простой капсулы вполне можно уложить в $5тыс (при массовом производстве от млн штук в год; это при условии существенного снижения стоимости электробатарей), 4-х местной в $8тыс. Ну а представительские могут и $100тыс легко стоить! Ну пусть даже после наладки выпуска в 100тыс в год одноместная капсула буде стоить в оптовой закупке от 1000 штук $10тыс - ерунда вопрос. А вот какой-нибудь smart-two будет стоить $40тыс так ему ещё искусственно цену подымут обложив всякими доп поборами!
Надо учесть что от такой капсулы много не требуется - скорости автономного хода и его запас - небольшие, безопасность самая базовая! Внутренняя отделка простая - антивандальная!
Если говорить об аренде - то я думаю тут лучше вести учёт за километраж автономного хода + фиксинг за пользование станций погрузки/разгрузки + подачу капсулы
Условно в нынешних деньгах 4цента за километр в городе + доллар подача + доллар за каждую автоматизированную погрузку разгрузку; если вдруг будет требоваться ожидание условно 4 цента за час (если место ожидание не имеет повышенного коэффициента за спрос).
Это всё при условии снижения стоимости электроэнергии (транспорта и производства и вообще всего) почти до экономически незначительной величины - но это уже другая тема! Как и выстраивание практически всего производства (от добычи полезных ископаемых до послепродажного обслуживания) почти 100% полностью автономного цикла - почти без участия людей! Но это тоже другая тема!
Да - метро и автобус в таком сравнении будут дешевле - но не намного коли надо будет ехать с 3-мя пересадками! А комфорта в них куда меньше! И транспортный коллапс у них уже не загорами!
Ну или можно купить абонемент (для простой одноместной капсулы): $1000 в месяц полный анлим на город! Или $200/мес: на любые городские 2 поездки в каждый будний день + ещё 4 в резерве в любой день (всё сверх лимита - за отдельную плату)! $300/мес: 4 поездки в день + 8 в резерве!
Но, всё-таки цель - сделать проезд на простых общественных капсулах бесплатным! Но не всё сразу! Это уже победивший коммунизм! Ну или победивший капитализм - который уничтожит 98% от 100ярд лишнего населения через век другой и будет жить в своё наслаждение полностью обслуживаемый роботами! Но это уже другая тема!
я не представляю каким магическим образом вы избавитесь от пробок
У меня вот такое личное видение решения - если у Вас есть решение лучше предложите сами и обоснуйте не хуже как это делаю я!
Альтернативу я уже обозначил: удалённая работа! Ну и расселение крупных городов - но это всё тоже отдельные темы!
Да и вообще - кто-то прогнозирует прирост до 100 ярдов населения в следующем веке (40ярд как минимум), а я вот наоборот ожидаю убыль - по крайней мере в развитых странах - хотя... может до 10 ярдов подрастём ещё - но в крупных городах плотность населения пока да - будет продолжать расти!
Хотя нас ждут ещё глубины космоса и колонизация других планет - куда вывозить лишнее население тоже есть - но и это уже другая тема!
ИМХО, любой ЯП недалёкого будущего (или актуального настоящего) должен быть асинхронным - и предлагать эту модель программирования как основную
Причём писать так (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% должна ожидать их полного выполнения.
Ниже могла бы быть ещё одна цепочка - независящая от предыдущих - она бы могла бы быть независимо и распараллелена!
Вот это программирование будущего! А не какой-то там паскаль или си шарп!
А как вы представляете себе логистику пустых капсул и избавление от очередей в точке назначения?
В чем подвох в вопросе?
Логистика пустых капсул автономная - в часы пик постоянная ротация и самостоятельный поиск ближайшего нового клиента; в остальное время - (большинство капсул) самостоятельно отправляются (или наоборот) в места хранения - места рассчитываются по загруженности транспортной сети, но в целом располагаться места хранения могут где угодно, а не только там где трафик максимальный (где как раз будет сложнее и дороже всего хранить), удобнее всего хранить под землёй - капсулы небольшие - много места не займут и в глубину можно их располагать очень глубоко и набивать как угодно "штабелями" - на удобстве людей ведь это не скажется - а автоматике всё-равно как долго и неудобно она будет утрамбовывать эти капсулы и в каком порядке их потом извлекать!
С очередями в точках назначения/отправления как в точках ж/д станций всё чуть сложнее - нарядил удастся полностью от них избавиться - но тут всё зависит от двух факторов:
а) Совершенства погрузо/разгрузочного механизма - тут схем много может быть, скорее всего поначалу он будет не совершенен и очереди могут быть большими, но это уже просто инженерная задача - решаемая со временем б) Для автотранспорта можно без особого снижения комфорта строить многоярусные и многолинейные системы погрузки - т.е. многоканальные - и система сама будет распределять по каналам; Плюс т.к. есть автономный ход - то опять же систем сама может решать к какому промежуточному узлу отправлять автомобиль - не всегда это может быть ближайший; Другое дело это точки вне ж/д сети - но тут всё тоже не сложно - вместо постоянных парковок - будут места посадки/высдки - капсулы будут подъезжать и сразу уезжать! Много места тоже не надо!
В остальном - затраты времени на очереди на погрузку/разгрузку будут компенсироваться высокими скоростями транспортировки! А без этого проблемы очередей погрузки/разгрузки с общественным транспортом + пробки - всё-равно будут куда выше!
вот представляете, в офисный центр приезжает утром 1000 работников к 9 утра...на капсулах каждый выгружается из неё в течении 30 секунд
посчитайте сколько времени займет выгрузка всех пассажиров одновременно...успеют ли все на работу и куда единомоментно деть 1000 капсул если вспомнить что вокруг еще 10 таких офисных центров
Тоже мне проблема:
1000 человек по 30 сек - скажем на "парковке" на 30 машин (скорее всего цифры и человек и мест парковки будут выше - всё-таки на один м2 в крупных городах в бизнес-кварталах и плотность работников выше, и парковки можно в несколько ярусов организовать, но не суть) итого в 30 сек обслужится 30 человек - а на 1000 уйдёт от 16 минут - это ни о чём! Автоматика сама сможет и время так рассчитать, чтобы больших ожиданий на погрузку/разгрузку не было - в крупных офисах ещё и время начала рабочего дня можно сдвигать для разных работников.
Вы думаете с общественным транспортом нет такой проблемы - она есть - просто она в другом виде - перекладывается на просчёт времени выхода сотрудника из дома - ему раньше надо выходить - чем больше трафик в общественном транспорте - так как, условно, в первый же автобус он навряд ли влезет, как и во второй, и с метро та же проблема в крупных городах! Так ещё и автобус в пробке легко задержится минут на 40, а если ещё и снегопад, наводнении, аварии на дорогах.... если основная сеть ж/д - то это всё для неё не так актуально!
Это целые капсульные пробки и огромные буферы-хранилища для пустых капсул плюс ожидание доставки пустой капсулы когда не час-пик
Как написал выше - с логистикой пустых капсул всё проще чем с автобусами и уж тем более частным транспортом! А насчёт доставки не в час пик - не проблема тоже - резервы будут храниться везде, часть будет курсировать - тут как с такси - вызывайте заранее - когда только собираетесь на выход - за 5-10 минуту 100% приедет капсула в городе - за городом, безусловно сложнее - но там и заказать можно ещё раньше - навряд ли иные возможности будут быстрее, разве что личный транспорт - если нужен - покупайте - такую же универсальную капсулу и храните её сами! Так же довезёт Вас тем же самым образом - а потом самостоятельно отправится на хранение - либо условно домой (коли не далеко - имеет в виду любая своя стоянка), либо в любое общее хранилище - само собой весь "общественный" сервис за доп оплату в данном случае! Но учтите - в такой модели бесплатных общественных парковок даже во дворах уже не будет! Хотя недорогие подземные многоуровневые паркинги вполне могут быть - так что это навряд ли прям большая проблема!
Это красиво в мечтах звучит, а по факту автобус и метро кое как с такой нагрузкой то справляются, куда уж об индивидуальных железках даже с размерами метр на метр говорить
Ещё раз повторюсь - рост человеческого трафика при применении автобусного и личного транспорта тоже ни к чему хорошему не приведёт - на мой взгляд моё решение куда более перспективное - чем пробки в метро или автобусов на выделенных полосах и при погрузке/разгрузке
Ну а на последок - я всё-таки думаю что в будущем удалённая работа (в т.ч. с применением VR технологий и автаров/суррогатов) станет куда более популярной, чем во времена пандемии - и человеческий трафик не то что не будет бурно расти - а наоборот будет постепенно снижаться! Но и тут у моей модели есть свои преимущества - всё-таки скорости транспортировки и удобства куда выше, чем общественный и даже чем личный транспорт!
Не строго... магистратуру уже стали отменять - 5-6 лет в России будут учить Бакалавров - пока ещё не везде но тенденция начинается - в России давно хотят отменить болонскую систему - видимо цель одна чтобы российские выпускники не котировались на западе - и им приходилось заново до обучаться за валюту в уже в иностранных государствах - что по идеи должно сильно снизить интеллектуальную трудовую миграцию из страны - как на деле будет не знаю - по идеи действительно умные студенты ещё на первых курсах должны прочухать этот нае...он и постараться перейти в иностранный вуз ещё задолго до окончания обучения - но да - это будет всё-равно сложнее, чем ранее! Ну а родителям нужно ещё лучше готовить будущее своих детей и стараться сразу их пристраивать в иностранные учебные заведения - ну если они конечно не долбо... патриоты и не видят будущее своих гениальных чад в оборонных КБ России!
В вагоны безусловно влезает больше пассажиров чем в автомобили, но:
Не все хотя чувствовать себя селёдкой в банке в час пик
Делать кучу пересадок тоже не очень комфортно (точки А и Б) не всегда возле станций.
Вагоны делают очень много затрат времени на посадку/высадку на каждой остановке, а ещё и петляют далеко не прямыми маршрутами!
Если не забивать "вагон" до предела (хотя это большой вопрос как обеспечить в час пик) - то в нём размещается не так уж и много пассажиров. Можно сравнить какой трафик везёт, скажем автобус и за то же время на том же участке перевезут автомобили. И это ещё при том, что полосы дорожного движения будут расходоваться не эффективно из-за выделения полосы автобусу. Безусловно - если сравнить поезд, то тут уже преимущество будет не таким очевидным (но автомобили всё равно победят, если пробок не будет - а вот пробки надо устранять повышением скорости перемещения и общей организации трафика; а пробки из людей уже начинаются и в общественном транспорте - а вот тут уже их решать практически нереально)
На всех остановках сделать стоянку для автономных такси практически нереально. Конечно можно оптимизировать так чтобы машины подъезжали к приходу вагонов - но всё-равно на них будет такой гигантский спрос из вышедших пассажиров (а ведь ещё будут и перхавшие) - что это будет жуткая "каша мала"
Нет, всё же эффективнее сажать пассажира в точке А (отправления) и высаживать его уже в точке Б (финального назначения, или промежуточной точке - если таковая есть на пути следования) в автономную капсулу (это может быть либо арендуемая капсула что предпочтительнее для большинства, либо своя личная - что будет предпочтительно для обеспеченного населения). А основное движение делать по единой сети железной дороги перемещая по ней эти капсулы на очень больших скоростях - и если и нужны будут пересадки, то они буду автоматизированными (но в идеале это должна быть ж/д сеть без пересадок с автоматическим быстрым перемещением меду отдельными ветвями). Сами капсулы (в своей массе) должны быть очень компактными преимущественно одноместными м микробгажником (Но и 4-х местные могут быть, как и с грузовым отсеком) и небольшим автономным запасом хода. Поэтому, не будут занимать много места в транспортной сети. Поэтому, дороги для них (как ж/д так и обычные) можно строить многоярусные - что ещё больше повысит их трафик.
Более того, я вот подумал, что для такого транспорта ещё нужно развивать и сеть питания - а-ля "макавто "- чтобы быстро (заказывая заранее) получать еду прям внутрь и есть в дороге (управлять то не надо; а если не есть - то можно работать или развлекаться прямо в капсуле). Но останется ещё один нюанс - который так же нужно оптимизировать - быстрый доступ к туалетам из таких капсул (я конечно а то, чтобы не делать эти дела внутри, а выходить - хотя и над этим тоже можно в будущем подумать - в космосе уже есть технические решения) - можно сделать специальную сеть туалетов с быстрым доступом прямо из капсулы, чтобы затраты времени были в среднем минут 5-10 - всё это время капсула ожидает пассажира условно "за углом".
Аналогично, той же сетью будут автоматизировано перемещаться и почти все грузы!
Вот такое у меня виденье! Никакой вагон такого уровня комфорта и объёма трафика не сможет предоставить! И, вероятно, будет применяться расширенная приоритезация трафика!
Это перспектива на несколько сот лет вперёд. Ну а потом, люди, вероятно, всё больше и больше перестанут перемещаться самостоятельно (вообще перемещать своё тело). Но это уже совсем другая история!
На Python у многих игр внутренние скрипты написаны. Так же на Python пишутся скрипты для обработке игровых файлов из вне. И книжки есть для обучения Python на примере игр
Это метро для машин - и тут до меня уже его воплощает в жизнь Илон Маск.
А я лишь довожу идею до совершенства - и предлагаю её как ключевую для развития транспорта недалёкого будущего (конечно, подземные тоннели это чуть более отдалённое будущее - чем надземная ж/д сеть - но я верю, что рано или поздно к этому всё придёт; телепортация - это пока фантастика).
Если у кого есть обоснованные идеи транспорта лучше - готов выслушать - излагайте!
P.S.
Безусловно - в где-то после XXII века помимо транспорта появятся принципиальные альтернативы (я не про телепортацию), что попросту сократят потребность в постоянном переносе живой массы. Например виртуальная реальность или суррогаты/аватары - но я всё-таки говорю об альтернативах более классическому транспорту, который точно будет ещё актуален сотни а может и тысячи лет (безусловно эволюционируя или даже со временем революционируя - хотя вот во что?)
Дорого - пока строится руками и не носит массовый характер. Я же за говорю о 100% автоматизации этого процесса + применение новых материалов (я намекаю на легко производимые путём печати, в т.ч. прямо на месте применения) - тут целый ворох новых технологий быть должен. Поэтому это не прогноз на ближайшие десятилетия - но то, к чему следует стремиться к концу уже следующего века.
А пока я, безусловно, за наземную транспортную сеть - но рельсовую - точнее с жёсткой сцепкой. А уже потом она сможет постепенно уходить под землю вместе остальными дорогами. Просто надземная земля к тому времени будет уж очень дорогой и очень востребованной для других целей!
Кстати, не особо дорого (опять же при автоматизации процесса) строить подземные тоннели открытым способом - т.е. копая сверху - так можно уходить вглубь до 3-х уровней (один уровень это чуть менее 5 метров высотой, хотя я бы увеличил минимум до 6). Но открытый способ годится только при доступности поля деятельности снаружи.
Вы правы, всё обсуждение ЯП для школы явно не опирается на ФГОС - поэтому это скорее обсуждение на тему как оно должно быть, а не как есть сейчас, и как выкручиваться преподавателям информатики в школах сейчас. Мне удалось застать более ранние времена (до ЕГЭ), когда свободы в обучении информатике было куда больше, и ещё повезло с преподавателями (даже в средней школе учительша физики, что вела и информатику - хорошо вела оба предмета). И сам тоже преподавал, позже, информатику, свободно и с практической стороны.
Поэтому я ратую за кардинальный пересмотр школьной программы по информатике. И начинать изучать её нужно чуть ли не с начальных классов - ну с 5-го то уж точно, хотя я бы с 3-го уже начал, сейчас дети куда более подкованные в работе с компьютерами, есть школы - где начинают работу с компьютерами на каждом уроке уже с первых классов (хотя информатика появляется конечно позже)!
Просто для вся программа информатики должна выстраиваться поэтапно - как минимум 3-4 этапа с 3(5) по 11(а лучше по 12 класс, при 12 летнем же обучении - а не при 10 летнем как в некоторых классах, где в школу идут с 7 лет и пропускают 4-ый класс). И на каждом этапе нужно учить по-разному и в разных средах:
Малышам скорее подойдут графические системы программирования а-ля Scratch и иже с ним (хотя тут считаю надо выбирать что-то на русском языке - даже для школ с иностранным уклоном с первых классов - так деткам будет проще), Начинать изучать программирование в раннем возрасте нужно с ярких простых визуальных систем в игровой форме с готовой мощной мультимедийной начинкой. Без углубления в теорию алгоритмов - всё "на пальцах"
Для школьников чуть постарше подойдёт что-то типа Кумир (хотя сам Кумир мне не понравился) - нужен простой текстовый ЯП опять же крайне желательно на русском языке (но с поддержкой и латинского синтаксиса), с очень хорошо продуманной простой IDE, графической средой и мощной библиотекой классов. Тут надо продолжать игровую форму - но уже ближе к реальному программированию - должен быть плавный переход от визуального программирования к текстовому - но всё ещё с обширным использованием готовых решений, которые будут расширяться и дорабатываться. Вот тут уже стоит начинать потихоньку давать теорию алгоритмов, булево алгебру и т.п. И да - видимо это должна быть задачей именно преподавателей информатики, а не математики (хотя преподаватели могут легко совмещать в средней школе эти профессии, особенно с их "любовью" работать на две ставки)
Ближе к 9-ым классам нужно уже переходить к чему-то более серьёзному - но с ФГОС я полностью не согласен. Даже если выбирать тут Python в качестве ЯП для изучения программирования. Тут программа обучения уже может сильно расходится в зависимости от углублённости школы (или класса) - одно дело гуманитарное углубление, другое - уклоном в информатику. Так же тут должны активно продвигаться факультативные занятия по информатике, где можно как изучать что-то более практическое, чем чисто теорию алгоритмов, например какое-то инструментальное ПО, или WEB-дизайн. Так и наоборот - что-то более интересное - программирование игр на готовых движках (конечно не с нуля). Но не на факультативах нужен какой-то простой ЯП для удобства разбора теории алгоритмов, без широкой подборки библиотек. Но с простым синтаксисом без побочных эффектов, и, как я считаю, без строгой типизации. Но при этом, похожий на профессиональные ЯП - чтобы переучиваться с него потом было не сложно.
Это уж старшие классы (10-12 в моей модели). Вот тут уже можно переходить на популярные ЯП. И углубляться в теорию написания практических программ. Но только не C/C++/Rust и т.п. - для школьников даже углублённых в информатику школ - это слишком сложно (хотя на факультативах - можно). Хотя я бы в основной программе всё-таки тут стал давать уже теорию СУБД (и на практике у меня так и было).
Ещё одно важное замечание. В России Информатика в ЕГЭ это экзамен по выбору (хоть я и считаю что это должен быть обязательный экзамен для будущих поколений). Пока я считаю, что все предметы с необязательными экзаменами на нужно требовать изучать в основной программе так глубоко, чтобы этого было достаточно для сдачи таких экзаменов для всех школ (или классов), где этот предмет не является основным / углублённым для изучения априори. То есть, ту же информатику "не надо" изучать на в стандартной школьной программе так, чтобы ученики сразу могли сдавать такой экзамен в обычной школе и в обычном классе. Безусловно вся необходимая теория должна быть в учебниках, и как минимум упомянута преподавателем (в старших классах), но всё же для успешной сдачи такого экзамена нужно ученику приложить и не мало своих усилий. Вот тут обязательно должны быть факультативные занятия (в той же школе, и в другой - по партнёрской программе, НУ ИЛИ ШКОЛА ОФИЦИАЛЬНО ДОЛЖНА ИМЕТЬ СТАТУС, КАК НЕ СПОСОБНАЯ ПОДГОТОВИТЬ К СДАЧЕ ТАКОГО ЭКЗАМЕНА - и этот недостаток должны стремиться устранить). Вот с факультативом уже должны быть высокие шансы сдать экзамен ЕГЭ по информатике. Но опять же - если это не углублённый класс/школа - то 100% гарантий высоких балов никто не обязан давать - это необязательный экзамен, так что тут школьник пусть сам оценивает свои силы.
Но! Как выше заметил - обычные школы не обязаны на обычных уроках подробно разбирать экзаменационную программу - но это не лишь отсутствие обязанности - если школа и преподаватель информатики сможет и захочет (а класс будет готов воспринимать) - то они могут и углубляться в то, чтобы многие ученики рассмотрели сдачу такого экзамена по выбору (хотя факультативы никто не отменяет). Но всё же - в старших классах рядовых школ куда важнее практическое обучение информатике, чем теоретическое (для экзамена) - это больше понадобится большинству после школы (не все же пойдут учиться на программистов, а уметь работать с ключевыми программами и системами надо всем). Но это пока так. Ещё лет 20-30 - и программирование будет востребовано куда более широко! Но тогда и экзамен по информатике надо делать в школе обязательным!
Вот такое моё мнение. Человека, прошедшего через правильное обучение информатике (в обычных школах), и самого преподававшего информатику в школе в старших классах
Но это всего лишь мечты.... увы в России это всё несбыточно в ближайшей перспективе! Ну учат в школах Питону - и на том спасибо!
P.S.
Кстати, небольшой офтопик, помимо того, что я разрабатываю ЯП Kotlin для .NET я ещё и разрабатываю C# на русском (проект RUSlyn) - что, считаю, будет интересной альтернативой для обучения в школе. Но прошу не начинать холивор насчёт того, что программировать надо только на латинице - для школьников это спорный вопрос, но даже я буду на стороне тех, кто ратует строго за латиницу - во такой вот я противоречивый в этом плане!
вот-вот. Если он выглядит как "массив", крякает как массив, плавает как "массив" - значит это не утка, а "массив"! И не важно что там за ним стоит во внутренностях
Деление класса - это сложный вопрос - тут много групповой психологии играет роль.
Нои плюсы есть - тут очень хорошо надо подумать над наиболее грамотным подходом
На мой вгзляд все три подхода имеют право на жизнь:
Разделение не класса на группы, а детей на разные классы - это попрактикуется уже давно. Типа гуманитарный класс, математический класс, класс углублённого изучения иностранного языка, класс дебилов - это, в общем-то, шута - но она неизбежная! Аналогично возможно разделение на разные школы - что ещё эффективнее и менее психологически проблемно!
Создание широкого спектра факультативов - особенно по всем предметам, по которым есть олимпиады, необязательные экзамены в школах и обязательные специализированные экзамены в ВУЗах и Коледжах. Но дети сами вольны выбирать что им интересно. Но увы - это всегда за допплату (впрочем углублённые школы и классы обычно тоже не бесплатны) - но это уже другой вопрос.
На самом деле, можно и более явно поделить детей на группы (но не ранее средней школы), как это практикуется "на западе" - когда у детей есть как общие уроки, так и раздельные (но это не совсем факультатив - их посещение обязательно - но выбор какие посещать всегда индивидуальный (но экзамены будут реальными) - просто нужно набрать некое минимальное количество - даже может быть условно по бесплатной схеме (в рамках основной схемы обучения, необязательно полностью бесплатной) - сверх уже факультатив за доплату - здесь уже если и будут экзамены, то чисто информативные - не на что не влияющие, хотя.... можно комбинированную схему когда к минимальной выбранной части ребёнок плюсует дополнительные предметы - уже за доплату - но тоже с реальными экзаменами - но общий бал в конце четверти/года должна выводить по итоговым балам всех экзаменов - так что в сумме с большего числа сданных предметов можно набрать больше, чем только по минимальной части - если с какими-то выбранными предметами будет всё не очень хорошо).
И я за то, чтобы освободить детей от всякой ерунды - и не углублять их в то, что им не интересно (но да в младшей и средней школе надо стараться заинтересовывать разными сферами - это не простая задача и решать её можно не только не столько широким спектром вдалбливаемых уроков).
Ну а факультативы хороши как для расширения кругозора, так и для натаскивания по проседающим предметам (а-ля репетиторство), так и для углубления в тематику для сдачи профильных необязательных экзаменов (или обязательных при поступлении в индивидуально выбираемые ВУЗы и Колледжи).
И да - факультативы не обязательно должны быть очными - сейчас в мире интернет-технологий школьное онлайн обучение тоже очень востребовано и эффективно! Этим не стоит пренебрегать.
И ещё - я, вот категорически против, чтобы в школах не в профильных классах углублялись в предметы, по которым нет обязательных экзаменов!
Как и против "обязательной" навязывания всякой необязательной для жизни шелухи - но если есть модель выбора предметов - то школьники может сам выбрать эти предметы, коли к другим душа не лежит - и просто проспать" их - ничего серьёзно там всё-равно спрашивать не будут - и спокойно потом, после 9-го класса, идти в ПТУ, ну или в "бригаду" - кому что ближе (армейский призыв то позже, а проф. армейское образование - это уже профильное военное училище)
Ничего про "правильность" той вики не писал - если что!
Моё мнение разностороннее обучение в школе - это всё-таки уже не есть хорошо - нужно быстрее переходить к более узкой специализации. Но для этого надо ещё в младших классах успеть втиснуть в гибкие молодые мозги как можно больше важных общих знаний (и это не так просто - над этим ещё надо поработать - тут нужны как технически нововведения, так и психологические и негидрофизические новации) - и начинать учиться им нужно пораньше - хотя бы с 3-4-х лет (да детство тоже целиком отнимать не стоит, но ужать нужно) и учится в школе подольше (оставив ВУЗы и Колледжи действительно для тех кто хочет углубляться в какие-то серьёзные профессии или идти в науку; впрочем бездарей после 9-го класса тоже особо задерживать не стоит, но я не считаю, что нужно стремиться, чтобы их было много - в отличии, наверное от ряда "умников" в администрации правительства - считающих, что лучше больше глупого населения, чем умного - так ими управлять проще).
Отчасти в защиту информатики скажу так - что наряду с математикой и русским языком - это должно быть основополагающим предметов в школе (я бы ещё и про физкультуру не забывал бы) - в современном мире эта тройка (физкульт - это отдельная тема) будет являться основополагающим базисом жизнедеятельности любого человека! И в т.ч. без основ информатики в современном обществе не обойтись будет так же как и без математики. Чем бы человек не стал заниматься: литературой, физикой, химией, биологией, юриспруденцией, психологией, медициной... (не говоря уже о рабочих и строительных специальностях, ну разве что дворникам не особо нужно - но их же роботы заменят, даже логистам (а-ля грузчикам не повредит - но их тоже роботы заменят)); даже если само программирование и не понадобится - то развитие интеллекта которое оно даёт - будет очень полезным, ну а навыке работы с компьютерами будут нужны всем! А уж потребность в программистах и прочих айтишниках пока будет расти в геометрической прогрессии! И благодаря им потом почти всех заменят роботы - но это уже другая тема!
Но я так же замечу, что предлагаемое мной ранее разделение специализации подразумевает и ранее выделение направления по информатики - как углублённо изучаемое как в отдельных специализированных школах, так и в отдельных профильных классах - что должны быть практически в каждой городской школе (разве что в сельских школах с этим будут сложности - но тут можно сразу предлагать удалённое обучение - в мире интернет технологий это уже не проблема). Для тех школьников, кто действительно будет хотеть более глубоко развивать себя как айтишник, участвовать в олимпиадах по информатике и выбирать информатику как экзамен по выбору и устраиваться в соответствующие ВУЗы и колледжи - вот тут можно и Си в старших классах изучать (но не C++ - это форменное издевательство над людьми - его изучение это должен быть осознанный выбор каждого, например в ВУЗах на очень профильных факультетах не для всех). Вот таких классах можно учить и софт писать.
А классах же другой направленности информатику тоже надо преподавать - но в другом ключе - скорее в плане работы со специализированным софтом - но так как практически любой вид софта будущего скорее всего будет иметь возможность алгоритмического подхода - то его тоже надо изучать, и программы писать тоже - лишним не будет - но тут нужны более простые ЯП. А до старших классов вообще всё должно быть в игровой форме!
Такого моё мнение! Просьба необоснованно не минусовать - как тут уже делали с моими комментариями!
Мне кажется это большая ошибка фантастов прошлого! Но... может просто мы ещё не дожили до того "ещё далёкого" будущего - но, моё мнение, что в нём индивидуальные летательные аппараты будут выглядеть совершенно иначе, а не как это уродство и как это предполагало большинство фантастов прошлого и настоящего!
Например, я скорее поверю в эпоху возрождения аэростатов (в т.ч. маленьких) чем в винтовую или реактивную летательную технику (или на антигравах) - если научатся делать воздушные шары невзрывоопасными и устойчивыми к сильным ветрам (но шансы этого крайне не велики на Земле, хотя на Марсе или Венере, Титане - куда выше).
Ну или "полёт" будет посредством каких-то электромагнитных процессов!
Но куда выше шансы в том, что люди вообще практически потеряют потребность индивидуально перемещать свои тела - и царствовать будет виртуальная реальность и аватары/суррогаты! А перемещения скорее будут в трубах и больше под землей (ну или в космосе)!
Вот она "Правильная" вики, распространяющая только "Правильные" мысли для "Правильной" аудитории от "Правильных" авторов - для "Правильной" страны, "Правильно" доступная в этой стране, "Правильно" независимо от мнения и санкций других!
Эдакий "Правильный" аналог "Большой советской энциклопедии" и газете "Правда" в одном "Правильном" флаконе!
Вопрос только, а "Правильно" ли её вообще читать?
Ответ: ну как ничего другого не станет - то сами сделаете свой "Правильный" выбор! Хотя свой "Правильный" выбор россияне уже "Правильно" будут делать несколько раньше - этой "Правильной" весной в этот "Правильный" год!
Хотя господин Преображенский (М. Булгаков) уже всё давно ПРАВИЛЬНО сказал на тему чтения "советских газет"
На мой взгляд все эти аэротакси и одноместные коптеры не более чем игрушка для богатых - как спорткары или спортивные самолёты - ограниченно потешить свой самолюбие в локализованной тихой местности, и похвастаться перед друзьями - на этом всё!
И будущего, кроме как коллекционного или как хобби, у них нет!
Хотя "не требующего сертификации пилота от Федерального управления гражданской авиации США" звучит очень дерзко - хотя и ложка дёгтя всё-равно есть: "создатели потребуют от всех будущих пилотов пройти комплексную лётную подготовку компании. От владельцев Helix также потребуют летать только в незагруженных районах и держаться подальше от аэропортов. Кроме того, покупатели должны быть старше 18 лет, весить менее 100 кг и иметь рост до 196 см" - так что круг потребителей сужается (хотя не очень сильно) - но не думаю, что это приведёт к массовому применению (даже при снижении цены $190 в несколько раз). И рано или поздно аукнется чем-нибудь не хорошим!
Беспилотные коптеры тоже ранее не были повсеместно запрещены - а сейчас запретов даже на них всё больше и больше!
Но да - я тут очень большой скептик, это лишь моё мнение!
Дело не просто в поддержке асинхронных цепочек вызовов - дело в красоте и простоте их описания, и, разумеется, надёжности получаемого кода.
Что на PascalABC.NET что на C# это выглядит, на мой взгляд, коряво, надёжность тоже требует особого подхода со стороны программиста, и применение некоторых специальных техник, отличных от синхронной модели. А я ратую за то, чтобы декларация асинхронного исходного кода был практически не отличима от синхронной. Более того - окончательное решение о применении распараллеливания должен принимать не программист (хотя я тут утрирую - конечно "последнее слово" всегда должно быть на стороне программиста - но это уже совсем явные указания для редких случаев), а компилятор-среда исполнения-рекомпилятор - именно исходя из реальной эксплуатации (если не делать ставку на динамическую рекомпиляцию, можно даже сразу генерировать несколько версий итогового кода, выбирая между разными версиями уже динамически, в зависимости от текущих условий выполнения) - и исходный код должен, условно (к этому надо стремиться), равнозначно компилироваться как параллельный, так и синхронный код - с асимптотически нулевыми лишними издержками (если бы его изначально вручную проектировали под каждую такую модель).
Вот тогда можно и студентов и даже школьников сразу натаскивать на асинхронное программирование! Не ломая им мозг!
Вот это я и пропагандирую. Актуальные ЯП (за исключением узко специализированных как Elixir и, отчасти, современные версии некоторых функциональных и логических ЯП) мало адаптированы именно на асинхронное программирование. Даже такие современные ЯП как Kotlin или Go синтаксически не далеко ушли от синхронной модели. Несмотря на то, что на серверах уже сотни ядер и распараллеливание рулит уже более 10 лет. Но, видимо пока хватает модели задач/обещаний и деления на, условно, изолированные потоки обслуживания внешних запросов. Большой революции в распараллеливании пока не случилось. Вот придут сотни ядер на десктопы (про серверы я умолчу) - вот тогда распараллеливание станет куда более актуальным - ибо десктопные задачи не процессные и тут именно надо оптимизировать практически однопоточный код.
Впрочем. на десктопы сотни ядер может и не придут (я не про проф. рабочие станции) - т.к. есть чётка тенденция вынесения всех процессов в облака и на сервера (впрочем и для проф. рабочих станций) или даже гетерогенное распределение по сети исполнителей. Но на серверах (всё-таки, умолчать про них не удалось) будет концентрироваться условно однопоточный поток инструкций (прошу прощения за тавтологию), который так же будет большое желание разнести по десяткам и сотням ядер (или вообще по разным компьютерам в сети) - и задача целенаправленного исходного асинхронного программирования будет актуальна как никогда!
Впрочем - не только в асинхронном программировании дело. А вообще - в новых концепциях программирования, в т.ч. с применением AI генеративных моделей. Простое программирование на чётких инструкциях процессору в будущем, скорее, удел системного программирования (да и то, всё более и более ограниченного). Будущее за декларативным программированием - в какой форме я не знаю, логические языки уже изжили себя, функциональное программирование в чистом виде сложно в освоении и отладке (но его подходы хороши симбиозе с другими парадигмами), возможно что-то типа SQL (или LINQ) в новой расширенной форме может стать тем граалем программирования будущего!
Я выше привёл пример кода на несуществующем ЯП - это моё концептуальное виденье языка программирования будущего. Я привёл лишь малу часть его возможностей, и в не самой упрощённой форме (чтобы было больше понимания), да и сам ЯП далёк до совершенства - это всё пока очень черновой синтаксис, постоянно меняющийся в деталях. Но я просто хотел показать концептуально иной подход - чем классические ЯП. Показав простоту и мощь, почти недоступную текущим языкам, и намекнув - что новые ЯП нужно развивать не по лекалам двадцати, и тем более, пятидесяти-летней давности, а смотреть в будущее, и привносить что-то революционно новое, удобное, полезное и мощное в фактическом применении! И тут надо развивать не только сам синтаксис (и не тащить в него устаревшие концепции), но и компилятор, и исполнительную среду, и IDE, и различный вспомогательный инструментарий, и документацию!
И в школе/институте тогда уже учить такому ЯП, который будет и прост в освоении, и актуален и силён в практическом применении!
Но это явно не первый ЯП для изучения. Начинать надо в младшей школе с графических систем программирования, потом переходить на простейшие текстовые - командные ЯП, и лишь потом уже ближе к старшим классам - на более серьёзные практичные ЯП.
Кстати, "|->" у меня это универсальная инструкциях объединения нескольких "параллельных" цепочек команд, и в общем случае не обязательно подразумевает параллельное исполнение (ключевой там является команда "Parallel", принимающая поток этих цепочек) - синтаксис у этого ЯП очень гибкий, и в целом достаточно простой (но требует некоторого освоения небольшого числа ключевых концепций, порой далёких от классических ЯП, например у него очень мало ключевых слов - в основном это только операторы, зато очень много команд и аннотаций - максимальный уровень унификации синтаксиса).
P.S.
На всякий случай замечу, что хоть выше пример идёт про консоль ввода вывода - это просто пример, и на месте консоли и команд чтения записи может быть всё что угодно! Более того, концепция такого ЯП подразумевает абсолютизацию потока - практически всё есть Поток (хоть данные, хоть инструкции - команды) - поэтому корректнее работать с Поток с основе универсальных команд - в данном случае вместо "ReadLine" и "WriteLine" это будут команды "Consume" и "Send" или их аналоги в виде операторов "<<<" и ">>>" соответственно (в этих командах подразумевается работа с Потоком порциями, и что формат порции для потоков консоли уже настроен как ограниченный некоторым разделителем строки - что, безусловно, можно настроить как для исходного Потока так и для некоторого Прокси-потока - если он будет задан посредником представления доступа к исходному Потоку). Такой подход ещё более унифицирует, абстрагирует и, в то же время, упрощает код работы с данными и любыми Потоками, какой бы природы и реализации они ни были. Но любой поток может быть конкретизирован вспомогательными командами - как данном случае "ReadLine" и "WriteLine"
Прекрасно представляю ибо метрострой "моя область".
Метро линии они занимают мизерные доли процента терриории по площади, а уж по объёму.... чисто какая-то "статистическая погрешность"
Коммуникации и так любят постоянно перекладывать - тоже мне проблема!
Всё это незначительная ерунда - особенно в век будущей автоматизации - когда большую часть работ как раз и будут выполнять автономные машины!
Более того - то же метро - скорее всего будет либо заброшено, либо переоборудовано в такую же ж/д сеть - которую я и так тоже прогнозирую в "чуть более отдалённой" перспективе так же полностью убирать под землю! А коммуникации как раз удобно будет тянуть, условно, вдоль таких тоннелей!
Но это всё-таки будущее. А в более насущном "настоящем" где-то на вторую половину XXI века и начало XXII (ранее то всё-равно такой проект никто не начнёт) много рыть в глубину не нужно - это начальная стадия - так что рыть можно неглубоко - метров на 20 - т.е. где-то 4 уровня глубь, а больше в ширину и длину! Ну и столько же наземная часть - лет на 100 хватит!
И пока не начать мой проект так эта мёртвая пробка никуда априори не денется - разве что запретят вообще на личном транспорте ездить всем "кому не следует" (очень лимитированный список).
Плохо меня читали - капсулы как раз не будут стоять на этих парковка - это только погрузка/разгрузка
Вот на этом действительно надо будет сосредоточить основной инженерный акцент. В старом капитальном фонде могут быть сложности - но ничего и их со временем перестроят. В итоге если всё будет забито - капсулы подвезут как можно ближе и высадят как в такси - это неличный транспорт (хотя с личными автономными капсулами по сути всё то же самое) - высадили - и тут же уехали сами искать куда запарковаться в другом месте! Совсем другой подход и кучу проблем долой!
Не придирайтесь - накрайняк ввиду временные лимиты на погрузку/разгрузку - превышение - прогрессивные штрафы! Это всё мелочи! Тем более погрузка/разгрузка не будет идти в одну очередь - а это будет параллельный многоканальный процесс - периодический сбой нескольких точек не заблокирует весь процесс!
С разгрузкой/погрузкой хоть автобусов хоть метро всё не особо лучше в часы пик!
Условно говоря да - и я не вижу в этом проблему. Под точкой можно считать сектор в среднем с доступным ожиданием по городу не более 15 минут (за городом конечно в раза в 3 более - но это максимальное время; при наличии свободных капсул) - ещё раз повторю капсулы как и такси вызываются всё-таки заранее!
На это мне сложно ответить. Но цель, конечно, оптимизация расходов - так что это будет явно дешевле среднестатистического автомобиля (если считать вообще все, особенно для крупных городов), особенно когда сеть разрвьётся и обычный автотранспорт начнут вытеснять обложив непомерными побоорами - но личную капсулу же никто не отмеял - купите и владейте!
Да и сами капсулы тоже могут быть разные - 1-местные, 4-х местные, повышенной комфортности, представительские, грузовые.... как личные, так и общественные - тарифы буду разные! Главное - это унифицировать внешние габариты - но явно потребуется несколько стандартов, как и стоит проработать сцепку нескольких капсул в единый состав!
Лично моё мнение - в нынешних ценах стоимость одноместной простой капсулы вполне можно уложить в $5тыс (при массовом производстве от млн штук в год; это при условии существенного снижения стоимости электробатарей), 4-х местной в $8тыс. Ну а представительские могут и $100тыс легко стоить! Ну пусть даже после наладки выпуска в 100тыс в год одноместная капсула буде стоить в оптовой закупке от 1000 штук $10тыс - ерунда вопрос. А вот какой-нибудь smart-two будет стоить $40тыс так ему ещё искусственно цену подымут обложив всякими доп поборами!
Надо учесть что от такой капсулы много не требуется - скорости автономного хода и его запас - небольшие, безопасность самая базовая! Внутренняя отделка простая - антивандальная!
Если говорить об аренде - то я думаю тут лучше вести учёт за километраж автономного хода + фиксинг за пользование станций погрузки/разгрузки + подачу капсулы
Условно в нынешних деньгах 4цента за километр в городе + доллар подача + доллар за каждую автоматизированную погрузку разгрузку; если вдруг будет требоваться ожидание условно 4 цента за час (если место ожидание не имеет повышенного коэффициента за спрос).
Это всё при условии снижения стоимости электроэнергии (транспорта и производства и вообще всего) почти до экономически незначительной величины - но это уже другая тема! Как и выстраивание практически всего производства (от добычи полезных ископаемых до послепродажного обслуживания) почти 100% полностью автономного цикла - почти без участия людей! Но это тоже другая тема!
Да - метро и автобус в таком сравнении будут дешевле - но не намного коли надо будет ехать с 3-мя пересадками! А комфорта в них куда меньше! И транспортный коллапс у них уже не загорами!
Ну или можно купить абонемент (для простой одноместной капсулы): $1000 в месяц полный анлим на город! Или $200/мес: на любые городские 2 поездки в каждый будний день + ещё 4 в резерве в любой день (всё сверх лимита - за отдельную плату)!
$300/мес: 4 поездки в день + 8 в резерве!
Но, всё-таки цель - сделать проезд на простых общественных капсулах бесплатным! Но не всё сразу! Это уже победивший коммунизм! Ну или победивший капитализм - который уничтожит 98% от 100ярд лишнего населения через век другой и будет жить в своё наслаждение полностью обслуживаемый роботами! Но это уже другая тема!
У меня вот такое личное видение решения - если у Вас есть решение лучше предложите сами и обоснуйте не хуже как это делаю я!
Альтернативу я уже обозначил: удалённая работа! Ну и расселение крупных городов - но это всё тоже отдельные темы!
Да и вообще - кто-то прогнозирует прирост до 100 ярдов населения в следующем веке (40ярд как минимум), а я вот наоборот ожидаю убыль - по крайней мере в развитых странах - хотя... может до 10 ярдов подрастём ещё - но в крупных городах плотность населения пока да - будет продолжать расти!
Хотя нас ждут ещё глубины космоса и колонизация других планет - куда вывозить лишнее население тоже есть - но и это уже другая тема!
ИМХО, любой ЯП недалёкого будущего (или актуального настоящего) должен быть асинхронным - и предлагать эту модель программирования как основную
Причём писать так (C#)
поэтому вот так будет практичнее
Но это как-то многословно, да и к тому же это у .NET тут фейковая асинхронность консоли - блокирующая основной поток
А вот так было бы куда красивее
Суть в том, чтобы сразу на стадии архитектуры кода разделять обработку на возможно параллельные потоки - и даже для ввода вывода даже в консоли.
Может показаться сложнее чем a = input("Введите a:") но проку куда выше
Кстати, код выше (с параллельной обработкой) "правильнее было бы вообще упростить" (без выделения четвёртого потока)
Смысл тут в том, что оба источника (и "ParallelConsole" и возвращаемый "GetAnyParallelSource()" помечены как приоритетно параллельные - т.е. обращение к ним может быть распараллелено компилятором без указания от программиста (хотя программист всегда может хунтами этим управлять вручную - запрещая или явно разрешая или явно требуя, т.к. для компилятора по умолчанию это лишь возможность неявного распараллеливания).
А код то ниже полностью написан в синхронном стиле. Но в виде 3-х отдельных цепочек обработки
Но компилятор может сам принять решение какие цепочки распараллелить - причём если имеется поддержка динамической рекомпиляции или хотя бы сбор статистики использования для компиляции следующего ручного билда - то это решение может ещё и пересматриваться по результату эксплуатации прошлого билда.
Две цепочки тут полностью независимы (возможными побочными эффектами пренебрегаем - её анализ либо на совести компилятора либо программиста - указать её наличие - но это не бест практик - наличие побочки - тем более когда явно имеем пометку источников как приоритетно параллельные).
Третья цепочка имеет явную зависимость от двух других так что 100% должна ожидать их полного выполнения.
Ниже могла бы быть ещё одна цепочка - независящая от предыдущих - она бы могла бы быть независимо и распараллелена!
Вот это программирование будущего! А не какой-то там паскаль или си шарп!
В чем подвох в вопросе?
Логистика пустых капсул автономная - в часы пик постоянная ротация и самостоятельный поиск ближайшего нового клиента; в остальное время - (большинство капсул) самостоятельно отправляются (или наоборот) в места хранения - места рассчитываются по загруженности транспортной сети, но в целом располагаться места хранения могут где угодно, а не только там где трафик максимальный (где как раз будет сложнее и дороже всего хранить), удобнее всего хранить под землёй - капсулы небольшие - много места не займут и в глубину можно их располагать очень глубоко и набивать как угодно "штабелями" - на удобстве людей ведь это не скажется - а автоматике всё-равно как долго и неудобно она будет утрамбовывать эти капсулы и в каком порядке их потом извлекать!
С очередями в точках назначения/отправления как в точках ж/д станций всё чуть сложнее - нарядил удастся полностью от них избавиться - но тут всё зависит от двух факторов:
а) Совершенства погрузо/разгрузочного механизма - тут схем много может быть, скорее всего поначалу он будет не совершенен и очереди могут быть большими, но это уже просто инженерная задача - решаемая со временем
б) Для автотранспорта можно без особого снижения комфорта строить многоярусные и многолинейные системы погрузки - т.е. многоканальные - и система сама будет распределять по каналам; Плюс т.к. есть автономный ход - то опять же систем сама может решать к какому промежуточному узлу отправлять автомобиль - не всегда это может быть ближайший;
Другое дело это точки вне ж/д сети - но тут всё тоже не сложно - вместо постоянных парковок - будут места посадки/высдки - капсулы будут подъезжать и сразу уезжать! Много места тоже не надо!
В остальном - затраты времени на очереди на погрузку/разгрузку будут компенсироваться высокими скоростями транспортировки! А без этого проблемы очередей погрузки/разгрузки с общественным транспортом + пробки - всё-равно будут куда выше!
Тоже мне проблема:
1000 человек по 30 сек - скажем на "парковке" на 30 машин (скорее всего цифры и человек и мест парковки будут выше - всё-таки на один м2 в крупных городах в бизнес-кварталах и плотность работников выше, и парковки можно в несколько ярусов организовать, но не суть) итого в 30 сек обслужится 30 человек - а на 1000 уйдёт от 16 минут - это ни о чём! Автоматика сама сможет и время так рассчитать, чтобы больших ожиданий на погрузку/разгрузку не было - в крупных офисах ещё и время начала рабочего дня можно сдвигать для разных работников.
Вы думаете с общественным транспортом нет такой проблемы - она есть - просто она в другом виде - перекладывается на просчёт времени выхода сотрудника из дома - ему раньше надо выходить - чем больше трафик в общественном транспорте - так как, условно, в первый же автобус он навряд ли влезет, как и во второй, и с метро та же проблема в крупных городах! Так ещё и автобус в пробке легко задержится минут на 40, а если ещё и снегопад, наводнении, аварии на дорогах.... если основная сеть ж/д - то это всё для неё не так актуально!
Как написал выше - с логистикой пустых капсул всё проще чем с автобусами и уж тем более частным транспортом! А насчёт доставки не в час пик - не проблема тоже - резервы будут храниться везде, часть будет курсировать - тут как с такси - вызывайте заранее - когда только собираетесь на выход - за 5-10 минуту 100% приедет капсула в городе - за городом, безусловно сложнее - но там и заказать можно ещё раньше - навряд ли иные возможности будут быстрее, разве что личный транспорт - если нужен - покупайте - такую же универсальную капсулу и храните её сами! Так же довезёт Вас тем же самым образом - а потом самостоятельно отправится на хранение - либо условно домой (коли не далеко - имеет в виду любая своя стоянка), либо в любое общее хранилище - само собой весь "общественный" сервис за доп оплату в данном случае! Но учтите - в такой модели бесплатных общественных парковок даже во дворах уже не будет! Хотя недорогие подземные многоуровневые паркинги вполне могут быть - так что это навряд ли прям большая проблема!
Ещё раз повторюсь - рост человеческого трафика при применении автобусного и личного транспорта тоже ни к чему хорошему не приведёт - на мой взгляд моё решение куда более перспективное - чем пробки в метро или автобусов на выделенных полосах и при погрузке/разгрузке
Ну а на последок - я всё-таки думаю что в будущем удалённая работа (в т.ч. с применением VR технологий и автаров/суррогатов) станет куда более популярной, чем во времена пандемии - и человеческий трафик не то что не будет бурно расти - а наоборот будет постепенно снижаться! Но и тут у моей модели есть свои преимущества - всё-таки скорости транспортировки и удобства куда выше, чем общественный и даже чем личный транспорт!
Не строго... магистратуру уже стали отменять - 5-6 лет в России будут учить Бакалавров - пока ещё не везде но тенденция начинается - в России давно хотят отменить болонскую систему - видимо цель одна чтобы российские выпускники не котировались на западе - и им приходилось заново до обучаться за валюту в уже в иностранных государствах - что по идеи должно сильно снизить интеллектуальную трудовую миграцию из страны - как на деле будет не знаю - по идеи действительно умные студенты ещё на первых курсах должны прочухать этот нае...он и постараться перейти в иностранный вуз ещё задолго до окончания обучения - но да - это будет всё-равно сложнее, чем ранее! Ну а родителям нужно ещё лучше готовить будущее своих детей и стараться сразу их пристраивать в иностранные учебные заведения - ну если они конечно не долбо... патриоты и не видят будущее своих гениальных чад в оборонных КБ России!
ИМХО - преподавать в скором времени будет искусственный интеллект - люди нужны будут лишь как кураторы учеников и как надзиратели над машинами
вот я выше об этом и говорю
В вагоны безусловно влезает больше пассажиров чем в автомобили, но:
Не все хотя чувствовать себя селёдкой в банке в час пик
Делать кучу пересадок тоже не очень комфортно (точки А и Б) не всегда возле станций.
Вагоны делают очень много затрат времени на посадку/высадку на каждой остановке, а ещё и петляют далеко не прямыми маршрутами!
Если не забивать "вагон" до предела (хотя это большой вопрос как обеспечить в час пик) - то в нём размещается не так уж и много пассажиров. Можно сравнить какой трафик везёт, скажем автобус и за то же время на том же участке перевезут автомобили. И это ещё при том, что полосы дорожного движения будут расходоваться не эффективно из-за выделения полосы автобусу. Безусловно - если сравнить поезд, то тут уже преимущество будет не таким очевидным (но автомобили всё равно победят, если пробок не будет - а вот пробки надо устранять повышением скорости перемещения и общей организации трафика; а пробки из людей уже начинаются и в общественном транспорте - а вот тут уже их решать практически нереально)
На всех остановках сделать стоянку для автономных такси практически нереально. Конечно можно оптимизировать так чтобы машины подъезжали к приходу вагонов - но всё-равно на них будет такой гигантский спрос из вышедших пассажиров (а ведь ещё будут и перхавшие) - что это будет жуткая "каша мала"
Нет, всё же эффективнее сажать пассажира в точке А (отправления) и высаживать его уже в точке Б (финального назначения, или промежуточной точке - если таковая есть на пути следования) в автономную капсулу (это может быть либо арендуемая капсула что предпочтительнее для большинства, либо своя личная - что будет предпочтительно для обеспеченного населения). А основное движение делать по единой сети железной дороги перемещая по ней эти капсулы на очень больших скоростях - и если и нужны будут пересадки, то они буду автоматизированными (но в идеале это должна быть ж/д сеть без пересадок с автоматическим быстрым перемещением меду отдельными ветвями). Сами капсулы (в своей массе) должны быть очень компактными преимущественно одноместными м микробгажником (Но и 4-х местные могут быть, как и с грузовым отсеком) и небольшим автономным запасом хода. Поэтому, не будут занимать много места в транспортной сети. Поэтому, дороги для них (как ж/д так и обычные) можно строить многоярусные - что ещё больше повысит их трафик.
Более того, я вот подумал, что для такого транспорта ещё нужно развивать и сеть питания - а-ля "макавто "- чтобы быстро (заказывая заранее) получать еду прям внутрь и есть в дороге (управлять то не надо; а если не есть - то можно работать или развлекаться прямо в капсуле). Но останется ещё один нюанс - который так же нужно оптимизировать - быстрый доступ к туалетам из таких капсул (я конечно а то, чтобы не делать эти дела внутри, а выходить - хотя и над этим тоже можно в будущем подумать - в космосе уже есть технические решения) - можно сделать специальную сеть туалетов с быстрым доступом прямо из капсулы, чтобы затраты времени были в среднем минут 5-10 - всё это время капсула ожидает пассажира условно "за углом".
Аналогично, той же сетью будут автоматизировано перемещаться и почти все грузы!
Вот такое у меня виденье! Никакой вагон такого уровня комфорта и объёма трафика не сможет предоставить! И, вероятно, будет применяться расширенная приоритезация трафика!
Это перспектива на несколько сот лет вперёд. Ну а потом, люди, вероятно, всё больше и больше перестанут перемещаться самостоятельно (вообще перемещать своё тело). Но это уже совсем другая история!
На Python у многих игр внутренние скрипты написаны. Так же на Python пишутся скрипты для обработке игровых файлов из вне. И книжки есть для обучения Python на примере игр
Что, у нас до сих пор ЕГЭ в MS Office - а как же импортозамещение? Или я что-то не понял
Нет. Я его совершенствую!
Это метро для машин - и тут до меня уже его воплощает в жизнь Илон Маск.
А я лишь довожу идею до совершенства - и предлагаю её как ключевую для развития транспорта недалёкого будущего (конечно, подземные тоннели это чуть более отдалённое будущее - чем надземная ж/д сеть - но я верю, что рано или поздно к этому всё придёт; телепортация - это пока фантастика).
Если у кого есть обоснованные идеи транспорта лучше - готов выслушать - излагайте!
P.S.
Безусловно - в где-то после XXII века помимо транспорта появятся принципиальные альтернативы (я не про телепортацию), что попросту сократят потребность в постоянном переносе живой массы. Например виртуальная реальность или суррогаты/аватары - но я всё-таки говорю об альтернативах более классическому транспорту, который точно будет ещё актуален сотни а может и тысячи лет (безусловно эволюционируя или даже со временем революционируя - хотя вот во что?)
Дорого - пока строится руками и не носит массовый характер. Я же за говорю о 100% автоматизации этого процесса + применение новых материалов (я намекаю на легко производимые путём печати, в т.ч. прямо на месте применения) - тут целый ворох новых технологий быть должен. Поэтому это не прогноз на ближайшие десятилетия - но то, к чему следует стремиться к концу уже следующего века.
А пока я, безусловно, за наземную транспортную сеть - но рельсовую - точнее с жёсткой сцепкой. А уже потом она сможет постепенно уходить под землю вместе остальными дорогами. Просто надземная земля к тому времени будет уж очень дорогой и очень востребованной для других целей!
Кстати, не особо дорого (опять же при автоматизации процесса) строить подземные тоннели открытым способом - т.е. копая сверху - так можно уходить вглубь до 3-х уровней (один уровень это чуть менее 5 метров высотой, хотя я бы увеличил минимум до 6). Но открытый способ годится только при доступности поля деятельности снаружи.
Вы правы, всё обсуждение ЯП для школы явно не опирается на ФГОС - поэтому это скорее обсуждение на тему как оно должно быть, а не как есть сейчас, и как выкручиваться преподавателям информатики в школах сейчас. Мне удалось застать более ранние времена (до ЕГЭ), когда свободы в обучении информатике было куда больше, и ещё повезло с преподавателями (даже в средней школе учительша физики, что вела и информатику - хорошо вела оба предмета). И сам тоже преподавал, позже, информатику, свободно и с практической стороны.
Поэтому я ратую за кардинальный пересмотр школьной программы по информатике. И начинать изучать её нужно чуть ли не с начальных классов - ну с 5-го то уж точно, хотя я бы с 3-го уже начал, сейчас дети куда более подкованные в работе с компьютерами, есть школы - где начинают работу с компьютерами на каждом уроке уже с первых классов (хотя информатика появляется конечно позже)!
Просто для вся программа информатики должна выстраиваться поэтапно - как минимум 3-4 этапа с 3(5) по 11(а лучше по 12 класс, при 12 летнем же обучении - а не при 10 летнем как в некоторых классах, где в школу идут с 7 лет и пропускают 4-ый класс). И на каждом этапе нужно учить по-разному и в разных средах:
Малышам скорее подойдут графические системы программирования а-ля Scratch и иже с ним (хотя тут считаю надо выбирать что-то на русском языке - даже для школ с иностранным уклоном с первых классов - так деткам будет проще), Начинать изучать программирование в раннем возрасте нужно с ярких простых визуальных систем в игровой форме с готовой мощной мультимедийной начинкой. Без углубления в теорию алгоритмов - всё "на пальцах"
Для школьников чуть постарше подойдёт что-то типа Кумир (хотя сам Кумир мне не понравился) - нужен простой текстовый ЯП опять же крайне желательно на русском языке (но с поддержкой и латинского синтаксиса), с очень хорошо продуманной простой IDE, графической средой и мощной библиотекой классов. Тут надо продолжать игровую форму - но уже ближе к реальному программированию - должен быть плавный переход от визуального программирования к текстовому - но всё ещё с обширным использованием готовых решений, которые будут расширяться и дорабатываться.
Вот тут уже стоит начинать потихоньку давать теорию алгоритмов, булево алгебру и т.п. И да - видимо это должна быть задачей именно преподавателей информатики, а не математики (хотя преподаватели могут легко совмещать в средней школе эти профессии, особенно с их "любовью" работать на две ставки)
Ближе к 9-ым классам нужно уже переходить к чему-то более серьёзному - но с ФГОС я полностью не согласен. Даже если выбирать тут Python в качестве ЯП для изучения программирования. Тут программа обучения уже может сильно расходится в зависимости от углублённости школы (или класса) - одно дело гуманитарное углубление, другое - уклоном в информатику. Так же тут должны активно продвигаться факультативные занятия по информатике, где можно как изучать что-то более практическое, чем чисто теорию алгоритмов, например какое-то инструментальное ПО, или WEB-дизайн. Так и наоборот - что-то более интересное - программирование игр на готовых движках (конечно не с нуля). Но не на факультативах нужен какой-то простой ЯП для удобства разбора теории алгоритмов, без широкой подборки библиотек. Но с простым синтаксисом без побочных эффектов, и, как я считаю, без строгой типизации. Но при этом, похожий на профессиональные ЯП - чтобы переучиваться с него потом было не сложно.
Это уж старшие классы (10-12 в моей модели). Вот тут уже можно переходить на популярные ЯП. И углубляться в теорию написания практических программ. Но только не C/C++/Rust и т.п. - для школьников даже углублённых в информатику школ - это слишком сложно (хотя на факультативах - можно). Хотя я бы в основной программе всё-таки тут стал давать уже теорию СУБД (и на практике у меня так и было).
Ещё одно важное замечание. В России Информатика в ЕГЭ это экзамен по выбору (хоть я и считаю что это должен быть обязательный экзамен для будущих поколений). Пока я считаю, что все предметы с необязательными экзаменами на нужно требовать изучать в основной программе так глубоко, чтобы этого было достаточно для сдачи таких экзаменов для всех школ (или классов), где этот предмет не является основным / углублённым для изучения априори. То есть, ту же информатику "не надо" изучать на в стандартной школьной программе так, чтобы ученики сразу могли сдавать такой экзамен в обычной школе и в обычном классе. Безусловно вся необходимая теория должна быть в учебниках, и как минимум упомянута преподавателем (в старших классах), но всё же для успешной сдачи такого экзамена нужно ученику приложить и не мало своих усилий. Вот тут обязательно должны быть факультативные занятия (в той же школе, и в другой - по партнёрской программе, НУ ИЛИ ШКОЛА ОФИЦИАЛЬНО ДОЛЖНА ИМЕТЬ СТАТУС, КАК НЕ СПОСОБНАЯ ПОДГОТОВИТЬ К СДАЧЕ ТАКОГО ЭКЗАМЕНА - и этот недостаток должны стремиться устранить). Вот с факультативом уже должны быть высокие шансы сдать экзамен ЕГЭ по информатике. Но опять же - если это не углублённый класс/школа - то 100% гарантий высоких балов никто не обязан давать - это необязательный экзамен, так что тут школьник пусть сам оценивает свои силы.
Но! Как выше заметил - обычные школы не обязаны на обычных уроках подробно разбирать экзаменационную программу - но это не лишь отсутствие обязанности - если школа и преподаватель информатики сможет и захочет (а класс будет готов воспринимать) - то они могут и углубляться в то, чтобы многие ученики рассмотрели сдачу такого экзамена по выбору (хотя факультативы никто не отменяет). Но всё же - в старших классах рядовых школ куда важнее практическое обучение информатике, чем теоретическое (для экзамена) - это больше понадобится большинству после школы (не все же пойдут учиться на программистов, а уметь работать с ключевыми программами и системами надо всем). Но это пока так. Ещё лет 20-30 - и программирование будет востребовано куда более широко! Но тогда и экзамен по информатике надо делать в школе обязательным!
Вот такое моё мнение. Человека, прошедшего через правильное обучение информатике (в обычных школах), и самого преподававшего информатику в школе в старших классах
Но это всего лишь мечты.... увы в России это всё несбыточно в ближайшей перспективе! Ну учат в школах Питону - и на том спасибо!
P.S.
Кстати, небольшой офтопик, помимо того, что я разрабатываю ЯП Kotlin для .NET я ещё и разрабатываю C# на русском (проект RUSlyn) - что, считаю, будет интересной альтернативой для обучения в школе. Но прошу не начинать холивор насчёт того, что программировать надо только на латинице - для школьников это спорный вопрос, но даже я буду на стороне тех, кто ратует строго за латиницу - во такой вот я противоречивый в этом плане!
вот-вот. Если он выглядит как "массив", крякает как массив, плавает как "массив" - значит это не утка, а "массив"! И не важно что там за ним стоит во внутренностях