Комментарии 829
В список самых высокооплачиваемых профессий, для тех кто не любит математику, программирование не входит:
www.businessinsider.com/high-paying-jobs-for-people-who-hate-math-2014-11
www.businessinsider.com/high-paying-jobs-for-people-who-hate-math-2014-11
Чтоб формошлёпить на мобилках последнее что нужно — это математика. Автор слишком увлёкся археологией.
А если именно программировать – то алгебра уровня старших классов школы нужна как минимум (а это немало; я в свою очередь класса с 7-го не в то русло энергию направлял и в алгебре страшные провалы, о чём сейчас порой очень жалею).
Конкретно алгебра не особо нужна, всем нужна пожалуй только алгебра логики. Остальное же от задач зависит — кому-то нужен весь матан, кому-то только матрицы, а кому-то ничего.
Я сам ни разу не программист и вкатиться не пытаюсь, но мне показалось странным что автор не понимает вот этого:
выражение типа N=N+1 и более сложные уравнения меня загоняли в легкий ступор
Это не уравнение. Это команда машине увеличить переменную N на единицу. То есть конкретно этот пример может работать как счетчик.
Мне кажется, что автору статьи сейчас нужен обычный школьный репетитор по информатике, который за месяц занятий покажет основы на примере бейсика или паскаля, и если даже после этого луч света не появится — тогда точно можно забыть про программирование как про страшный сон, а если что-то будет получаться — уже думать что делать дальше.
зачем ему бейсик и паскаль?
нужно решать задачки на java или котлин, хотя котлин без java все же сложноват. Математику(leetcode) можно делать после освоения языка. Язык осваивается в виде сделаных 5-10 проектов. В большинстве случаев достаточно изучения web сервисов. Ну либо смотреть проекты на андроиде. Для начала написать hello world, потом добавить логику потом бд дальше сходить на собеседование(устроитья не цель, но если возьмут это круто) — узнать что спрашивают и двигаться в этом направлении.
Не плохой вариант javarush как-раз чтобы голова не болела, что делать. Но полностью к собеседованию не готовит. Как варик можно курсы от jetbrains, правда только присматривался, вроде не плохие, но лично не пробовал.
нужно решать задачки на java или котлин, хотя котлин без java все же сложноват. Математику(leetcode) можно делать после освоения языка. Язык осваивается в виде сделаных 5-10 проектов. В большинстве случаев достаточно изучения web сервисов. Ну либо смотреть проекты на андроиде. Для начала написать hello world, потом добавить логику потом бд дальше сходить на собеседование(устроитья не цель, но если возьмут это круто) — узнать что спрашивают и двигаться в этом направлении.
Не плохой вариант javarush как-раз чтобы голова не болела, что делать. Но полностью к собеседованию не готовит. Как варик можно курсы от jetbrains, правда только присматривался, вроде не плохие, но лично не пробовал.
Основы программирования на паскале изучаются в школе. Думаю, обычный школьный репетитор по информатике не сможет помочь с решением задачек на java.
По моим школьным воспоминаниям, в паскале более или менее легко разобраться. Соответственно, можно быстрее попробовать себя в более осознанном программировании, чем "Hello, World!"
Сейчас в школе или паскаль, или питон обычно.
Учить java первым языком — глупая затея. С одной стороны это слишком низкоуровнево, с другой стороны много концепций приходится объяснять сразу. У меня был буквально один урок, когда школьница попросила её обучить джаве. И на том моменте, когда для чтения числа с клавиатуры нужно сделать обёртку из буфферизованного потока, а потом из ридера, я понял, что затея провальная.
И это мы ещё опускаем заклинания public static void main (но они не только в джаве, конечно). Даже на плюсах проще стартовать, имхо.
Учить java первым языком — глупая затея. С одной стороны это слишком низкоуровнево, с другой стороны много концепций приходится объяснять сразу. У меня был буквально один урок, когда школьница попросила её обучить джаве. И на том моменте, когда для чтения числа с клавиатуры нужно сделать обёртку из буфферизованного потока, а потом из ридера, я понял, что затея провальная.
И это мы ещё опускаем заклинания public static void main (но они не только в джаве, конечно). Даже на плюсах проще стартовать, имхо.
сейчас паскаль на питон заменили
Да, сам недавно узнал. В мое-то время учились основам программирования на черепашке и паскале
А черепашка тоже в python переехала. (:
Видел у К.Ю.Полякова робота для браузера с возможностью выбора языка из Python, JS, PHP, Dart, Lua. Ну и там еще прикручен редактор blockly для визуального конструирования.
Школьная алгебра нужна для того чтобы научить:
1) Точно выражать свои мысли (чтобы задача вообще была решена)
2) Оформлять их в строгой нотации (чтобы код скомпилировался)
3) Преобразовывать выражения из одной формы в другую без потери смысла (чтобы рефакторить)
Если человек не научился на алгебре раскрывать скобки у многочленов, то у него будут проблемы и в программировании.
Подробнее эту тему я раскрывал в своей статье Вот зачем нужна школьная алгебра
Даже «формошлепить» математика нужна будет. Иногда весьма интесивная… И статистика и методы оптимизации и алгебра всяческая. А ещё неплохо бы изучить физиологию восприятия и промышленный дизайн(для качественного формошлепства). Конечно дорогу осилит идущий и полюбить можно и после свадьбы, но лучше все таки по любви.
Конечно дорогу осилит идущий и полюбить можно после свадьбы...
— Знаешь, как называется любовь за деньги?
— Продакшен, как же ещё! :)
Интенсивная, но не вся. Стереометрия вам не понадобится пока вы не займётесь 3D. Интегралы/Дифференциалы же я живьём в рабочих проектах не видел.
Ну а мне встречались. И всем кто занимается графикой тоже. Ну например:
en.m.wikipedia.org/wiki/Summed-area_table
Фильтры всякие, антиалиасинг…
Всегда можно обойтись без чего либо или выучить когда понадобится, но лучше все таки знать, чтобы хорошо делать работу
en.m.wikipedia.org/wiki/Summed-area_table
Фильтры всякие, антиалиасинг…
Всегда можно обойтись без чего либо или выучить когда понадобится, но лучше все таки знать, чтобы хорошо делать работу
К слову, summed area table не содержит Интегралов/Дифференциалов нигде, кроме 2го названия: «Integral Image»
К слову это дискретный аналог интеграла или просто — дискретный интеграл.
И допускает обратную операцию дифференцирования. А еще у него есть много интересных свойств:
www.sfu.ca/math-coursenotes/Math%20158%20Course%20Notes/sec_VolumeAvgHeight.html
Добавлю еще. Метод позволяет быстро посчитать среднее значение на интервалах, что равносильно свертке с прямоугольной функцией, которая в свою очередь позволяет быстро найти приближение к свертке с гауссианом любой ширины(согласно предельной теореме) :)
И допускает обратную операцию дифференцирования. А еще у него есть много интересных свойств:
www.sfu.ca/math-coursenotes/Math%20158%20Course%20Notes/sec_VolumeAvgHeight.html
Добавлю еще. Метод позволяет быстро посчитать среднее значение на интервалах, что равносильно свертке с прямоугольной функцией, которая в свою очередь позволяет быстро найти приближение к свертке с гауссианом любой ширины(согласно предельной теореме) :)
как примеры:
Smoothed particles hydrodynamics- гидродинамика сглаженных частиц. применяется в GameDev-е для визуализации потоков жидкости и физики. Там диф-уры в частных производных в интегральной форме записи решаются.
Твердотельное моделирование (Компас-3D, SolidWorks, T-Flex etc.)- всякие огибающие и поиск точек касания- дифференциалов хоть отбавляй.
ЧПУ- если управлять «рукой» типа Куки- то там тоже дифференциальной геометрии с полярными координатами по самые помидоры. Гексапод без этой ерунды тоже ногами ровно дергать не сможет.
Smoothed particles hydrodynamics- гидродинамика сглаженных частиц. применяется в GameDev-е для визуализации потоков жидкости и физики. Там диф-уры в частных производных в интегральной форме записи решаются.
Твердотельное моделирование (Компас-3D, SolidWorks, T-Flex etc.)- всякие огибающие и поиск точек касания- дифференциалов хоть отбавляй.
ЧПУ- если управлять «рукой» типа Куки- то там тоже дифференциальной геометрии с полярными координатами по самые помидоры. Гексапод без этой ерунды тоже ногами ровно дергать не сможет.
Не все разработчики работают с 3D (по-моему, вообще — меньшая часть). Я, как iOS разработчик, и из чистой математики за пределами алгебры ничего не встречал. Самый же полезный навык — понимание алгоритмической сложности.
Периодически ради фана пишу моды для игр, математики в них на порядок больше:
Из того, что встречал/применял и что никогда не понадобилось в профессиональной деятельности: интегрирование, теория управления, мат.ожидание, собственно стереометрия, теория графов, конечные автоматы. Вот сейчас с симплекс-методом воюю… Конечные автоматы очень долго ждали своего часа, чтобы оказаться в списке «применено в том числе для рабочих задач».
В общем не хотите учить математику — идите в iOS разработку, тут вам ничего кроме геометрии не понадобится…
Периодически ради фана пишу моды для игр, математики в них на порядок больше:
Из того, что встречал/применял и что никогда не понадобилось в профессиональной деятельности: интегрирование, теория управления, мат.ожидание, собственно стереометрия, теория графов, конечные автоматы. Вот сейчас с симплекс-методом воюю… Конечные автоматы очень долго ждали своего часа, чтобы оказаться в списке «применено в том числе для рабочих задач».
В общем не хотите учить математику — идите в iOS разработку, тут вам ничего кроме геометрии не понадобится…
> Дифференциалы
Вообще любая динамика, не обязательно в играх — тупо нормальная модель динамики спроса (но в итоге её всё равно к линейной приводят)…
Вообще любая динамика, не обязательно в играх — тупо нормальная модель динамики спроса (но в итоге её всё равно к линейной приводят)…
Угу и всего этого не знает почти никто судя по интерфейсам и рынку труда.
А где там статистика может быть нужна?
Мне тоже так казалось до того как я попробовал обучить программированию своего брата. Выяснилось, что кроме умения читать книжки (о программировании) нужно ещё уметь мыслить как программист. А это навык, типа умения быстро бегать или боксировать, просто так, из воздуха не берётся. Несмотря на все наши попытки понять что такое массив и как его обрабатывать не получилось. Проблемы была в том, что братишка не мог в голове собрать как из мелких шагов на каждом этапе возникает целое решение.
Несмотря на все наши попытки понять что такое массив и как его обрабатывать не получилось.
Вариант для школьника: обычный двумерный массив — это морской бой.
Обработайте несколько матриц — одна твоя, другая противника.
Бесспорно, что математика формирует мышление хорошего программиста. Но это совершенно не означает, что бывший двоечник по математике не будет способен на плюс минус сносном уровне освоить условный реакт. В датасайнс и мл ему путь если не заказан, то будет крайне сложным, но 80% нынешнего потребительского программирования сильно проще.
Математика один из путей, допускаю, что работа историка по исследованию документов, поиску противоречий и построению непротиворечивой картины событий тоже тренирует нужный навык. У гипотетического двоечника проблемы могут возникнуть не с реактом и не с тем, чтобы прочитать кучу документации и туториалов. Ему может быть сложно понять что делает цикл for, как составить даже тривиальный алгоритм типа «переверни список», как соотносится между собой тело цикла и конечный результат работы.
Практически на все эти вопросы легко ответит хождение по коду дебагером + чтение соответствующей теории по алгоритмам. Только опять же, в 80% современной типовой работе даже на такой уровень закапываться обычно не приходится. Понятно, что с таким подходом сениором не стать, но автор вон и на путь джуна даже стать не может из-за любви к археологии.
Когда-то, будучи совершенно практическим двоечником по математике (и не только), совершая свои самые первые шаги в программировании столкнулся с тем, что на единственном доступном компьютере оператор FOR в Бейсике просто не работал (битое ПЗУ, компьютер сбрасывался при выполнении оператора). Ни знающих людей, у кого можно было бы спросить совета, ни хоть сколько-то адекватной литературы под рукой не было. Как-то не сильно остановило и не помешало ни в написании своих первых программ, ни в выборе жизненного пути. Бывают разные люди и разные истории, и со своей колокольни мне кажется, что мотивация гораздо важнее таланта и знаний.
Ну, формошлепить в долине — таки на собеседованиях это все нужно будет.
Сделать красивую анимацию на форме — математика как раз таки нужна
Этот список актуален для США.
Там на втором месте врач-педиатр, а еще есть медсестра.
Точно не для РФ и СНГ, у нас какой-нибудь педиатр — нищий.
Так что не совсем актуально в принципе.
Там на втором месте врач-педиатр, а еще есть медсестра.
Точно не для РФ и СНГ, у нас какой-нибудь педиатр — нищий.
Так что не совсем актуально в принципе.
Ой, тут смотря какая математика! Про графы все же программисты знают?! А это часть дискретной математики. Мат.логику тоже все знают. Умение определять сложность алгоритма — тоже математика. Работаешь с float — должен знать часть вычислительной математики.
Если поставить вопрос так: насколько нужен «чистый матан» (мат.анализ) программисту, то получили бы интересное исследование. Критерии сходимости рядов, разрывы функции, множества Парето, Слейтера и т.д.
Если поставить вопрос так: насколько нужен «чистый матан» (мат.анализ) программисту, то получили бы интересное исследование. Критерии сходимости рядов, разрывы функции, множества Парето, Слейтера и т.д.
Без хорошей школьной математики в программировании всегда будет. Всё-таки хорошая математическая база даёт преимущества в восприятии, написании, мышлении. В общем без математики никуда
>Неужели чтобы стать программистом без технической базы, требуется так много времени?
Да уж. Когда въедливость и желание разобраться до сути во зло. Всё что требуется на начальном этапе — понять тот уровень абстракции, где надо просто верить в магию нижних уровней и жить с ней и продолжать разбираться с верхним уровнем.
Да уж. Когда въедливость и желание разобраться до сути во зло. Всё что требуется на начальном этапе — понять тот уровень абстракции, где надо просто верить в магию нижних уровней и жить с ней и продолжать разбираться с верхним уровнем.
Точно подмечено про магию. Так же и в математике сначала просто надо принять, почему на ноль делить нельзя например, а потом уже потихоньку начинаешь понимать почему нельзя. И вполне можно остановиться на уровне где деление на ноль просто магия которую нужно принять. В программировании также, есть решения и технологии которые просто работают и можно пользовать их не вникая как там все внутри устроено.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Да, корень из отрицательных чисел тоже можно брать
Ну на 0 можно делить только 0.
Неопределенности вида «0 делить на 0» учат разрешать в стандартном курсе анализа.
Неопределенности вида «0 делить на 0» учат разрешать в стандартном курсе анализа.
А что вам мешает 5 на 0 поделить, получив вполне законную +∞?
а почему не -∞?
Тот факт, что деление на ноль — в большинстве случаев неопределенная операция (за исключением некоторых специфичных областей математики). Если очень хочется, то можно взять предел — тогда будет бесконечность:
lim_(x->0) 1/x = ∞
lim_(x->0) 1/x = ∞
НЛО прилетело и опубликовало эту надпись здесь
потому что выполняя операцию деления определенную на неком множестве чисел хочется что бы результат остался в множестве этих чисел(поле комплексных/действительных чисел). Если что это следует из словосочетания «определенную на множестве». Бесконечность не входит в это поле.
С таким же успехом можно делить 5 на апельсин и получить законное ведро гвоздей.
С таким же успехом можно делить 5 на апельсин и получить законное ведро гвоздей.
А это и не ноль, а символ бесконечно малого числа.
А на ноль делить нельзя.
А на ноль делить нельзя.
Почему сразу врали? Все зависит от набора аксиом, задающих основу. А набор аксиом может зависеть от раздела математики или от выбранной математической модели.
В арифметике на ноль делить по жизни нельзя. Когда в школе говорят о невозможности деления на ноль, внезапно, проходят не математику вообще, а именно арифметику. И потому на самом деле никак нельзя.
Когда мы выходим за рамки арифметики, то получаем несколько иной базис (как минимум появляется понятие бесконечности), и уже тогда появляется возможность делить на ноль.
С параллельными прямыми такая же неувязка. У Евклида они не пересекаются. Пока мы в рамках евклидовой геометрии, это железобетонная истина.
А кое у кого очень даже пересекаются, но это уже совсем не евклидова геометрия.
А кое у кого очень даже пересекаются
А у кого-то их даже нет. Зависит, с какой стороны глобуса живёшь :)
А кое у кого очень даже пересекаются, но это уже совсем не евклидова геометрия.
Нет же, параллельные прямые не пересекаются по определению. Ни в какой из геометрий.
Нет же, параллельные прямые не пересекаются по определению. Ни в какой из геометрий.
Для некоторых видов геометрий, определение «паралельных прямых» некорректно в принципе, например в многомерных пространствах.
по этому они или не пересекаются или не верно сформулировано ваше выражение что «никогда по определению» поскольку надо указывать подробности их параллельности
В неэвклидовой геометрии обычно ломается пятый постулат «Через любую точку, не лежащую на прямой, можно провести прямую, параллельную данной, и притом только одну». Параллельность при этом остается синонимом непересекаемости.
Или вообще параллельные прямые становятся невозможными (в сферической геометрии).
Или вообще параллельные прямые становятся невозможными (в сферической геометрии).
Пес его знает.
Естественно, что далеко не в каждой неевклидовой геометрии имеются пересекающиеся параллельные прямые, но как-то случайно наткнулся на какую-то математическую модель, описывающую что-то, мне неведомое.
Зацепился сознанием за это и запомнил именно из-за параллельных прямых.
Во-первых, они вводились там как взаимно перпендикулярные третьей прямой (и назывались при этом именно параллельными).
Во-вторых, они не пересекались ни в какой из взятых на прямой точек, но однозначно пересекались в бесконечности (именно так, пересекались в бесконечности, оно там через предел как-то выводилось).
Кстати, еще немного о делении на ноль.
За пределами арифметики не везде можно делить на ноль.
Более того, кое-где в математике вообще деление не предусмотрено как класс.
Так что математика — она такая. Какой надо базис — такой и введут. И получат пространство с нужными свойствами. И будут люди, что не в теме, ужасаться и путаться, поскольку термины в этом пространстве будут знакомыми, но означать будут сущности с совершенно другим поведением (хотя и близкие "по духу").
Параллельность при этом остается синонимом непересекаемости.
Не обязательно. Скажем, параллельность по Лобачевскому — это частный случай непересекаемости. Через точку, не лежащую на прямой, можно провести бесконечно много прямых, не пересекающих данную, две из которых будут параллельными данной по Лобачевскому.
Причём, если пространство Лобачевского "распрямить" — то всё это множество непересекающих данную прямых "схлопнется" в одну прямую, параллельную данной и по Евклиду и по Лобачевскому.
НЛО прилетело и опубликовало эту надпись здесь
А кстати, про приведённую задачу. Геометрия учит нас, что наилучшее соотношение площадь\периметр имеет квадрат, после круга, естественно. А я там квадратов пока не просматриваю.
Забор посередине все портит
там интересно получается
пусть у нас 2 продольных и n поперечных заборов. при любом n максимум площади будет при длине продольного забора равной 25. при n=2, это будет квадрат, но в задаче n=3
наилучшее соотношение площадь\периметр имеет квадрат, после круга, естественно
Ложное утверждение. Например, правильный шестиугольник лучше квадрата.
Если по условию задачи оба загона должны быть прямоугольные и одинаковой площади, то
100 = 3x + 2y, где x и у — стороны совокупной конструкции.
Отсюда у = 50 — 1,5 х.
Дальше надо максимизировать величину х*(50 — 1,5*х), она же 50*х — 1,5 *х^2.
И здесь действительно надо взять от этого выражения производную. И приравнять ее к нулю. Это, насколько помню, учат в 11 классе.
Получится 50 — 3х = 0, т.е. х = 50/3.
y = 50 — 1,5x = 50 — 1,5*(50/3) = 25.
Итак, х = 16,667 и y = 25.
100 = 3x + 2y, где x и у — стороны совокупной конструкции.
Отсюда у = 50 — 1,5 х.
Дальше надо максимизировать величину х*(50 — 1,5*х), она же 50*х — 1,5 *х^2.
И здесь действительно надо взять от этого выражения производную. И приравнять ее к нулю. Это, насколько помню, учат в 11 классе.
Получится 50 — 3х = 0, т.е. х = 50/3.
y = 50 — 1,5x = 50 — 1,5*(50/3) = 25.
Итак, х = 16,667 и y = 25.
Дальше надо максимизировать величину х*(50 — 1,5*х), она же 50*х — 1,5 *х^2.
Если не сложно с этого момента можно подробнее. Не совсем понятно что Вы делаете. Все понятно до момента 50-1,5х=y
х*(50 — 1,5*х) — это то же самое, что x*y， просто у мы выразили через х. Произведение x*y — это площадь загона, она должна быть максимальной.
Чтобы найти максимальное или минимальное значение функции f(x), надо от этой функции «взять производную». Полученное выражение обозначают f`(x). И потом надо решить уравнение f`(x) = 0, тогда получим х, при котором экстремального значения достигает исходная функция f(x).
А чтобы взять производную от 50*х — 1,5 *х^2, надо знать формулу, по которой производная от a*x^b равна a*b*x^(b-1). Получается, что производная от 50*х — это 50, а производная от 1,5 *х^2 — это 3*х. А производная от всего выражения это как раз 50 — 3*х.
Дальше остается решить уравнение 50 — 3*х = 0.
Чтобы найти максимальное или минимальное значение функции f(x), надо от этой функции «взять производную». Полученное выражение обозначают f`(x). И потом надо решить уравнение f`(x) = 0, тогда получим х, при котором экстремального значения достигает исходная функция f(x).
А чтобы взять производную от 50*х — 1,5 *х^2, надо знать формулу, по которой производная от a*x^b равна a*b*x^(b-1). Получается, что производная от 50*х — это 50, а производная от 1,5 *х^2 — это 3*х. А производная от всего выражения это как раз 50 — 3*х.
Дальше остается решить уравнение 50 — 3*х = 0.
для полной картины понимания Computer Science, мне необходимо будет заново учить алгебру, а затем и ВысшМат
Для полной картины даже этого не хватит… Я учился на ВМК, работаю в целом по специальности, и все равно — чем дальше, тем больше IT-направлений мне становятся непонятны и прямо-таки тяжелы для освоения.
Но чтобы стать средненьким программистом, этого понимания, в общем, не требуется. Базовые алгоритмы (хотя бы вслепую уметь писать сортировку) + решение задачек по предметной области (клепание форм, роутинг или куда там идёте) в общем и целом даст квалификацию на джуниора-мидла. А дальше уж посмотрите, имеет ли смысл жрать этот математический кактус… Сениору-архитектору это да, неплохо бы иметь технический склад характера + математический бекграунд.
PS: Я вот занимаюсь ИИ, так мне пришлось осваивать психологию и лингвистику. Тоже не фунт изюму…
Неужели чтобы стать программистом без технической базы, требуется так много времени?
Меня конечно вдохновляют статьи в интернете, где люди пишут, что за 1,5 года стали Java developer-ом и уехали в Германию, Канаду, США, однако оценивая свои печальный опыт я не уверен что такое возможно.
Ну, без описания начального уровня тут особо говорить не о чем. У меня был коллега, который имел опыта java разработки меньше, чем вы описываете (только курсы, де факто). Но придя на наш проект, он вполне вписался в работу, и примерно год вполне справлялся, в том числе писал например на скале. Но при этом у него, надо заметить, было примерно 10 лет опыта в другой области — 1С, т.е. скажем базы данных и SQL он знал вполне прилично. То есть, отсутствие опыта в самой разработке и языке/инструменте должно чем-то компенсироваться, как правило. Отсутствие знания математики — обычно тоже.
Германия тут кстати может упрощать дело — потому что дефицит программистов там вполне может быть больше, чем где-то в глубинке России, например, и если вы по остальным показателям проходите…
10 лет в 1с означают 10 лет опыта в написании кода в процедурном стиле, возможно написание внешних компонент на плюсах. Возможно еще что то полезное. Так что по сути ему нужно было освоить только ООП и конкретный инструментарий. Ну может еще какие хорошие практики. Не так много.
1С это ведь по сути VisualBasic с русским синтаксисом. Так что вполне язык программирования и навык качает. Пересесть с процедурного программированмя на ООП, не так и сложно. Особенно если практика ООП была в универе.
Собственно я об этом и написал. Там конечно нужно еще учитывать распространенность плохих практик программирования и еще некоторые нюансы, но в целом да, опыт 1с вполне можно, пусть и с понижающим коэффициэнтом, считать за опыт продакшен программирования. Та же работа в команде, то же умение декомпозиции задач и выделения абстракций.
Я в общем то на своем опыте такое провернул. Спустя года 3 в 1с, может чуть раньше начал изучать не привязанные к языкам вещи, читал дядюшку боба, макконела, хабр, смотрел записи конференций, читал про ООП и паттерны. А потом, после еще полутора-двух лет перешел на котлин достаточно спокойно, даже с учетом что менторить некому меня было. Оценить трудно самому себя, но где то через месяц ушел от программирования в процедурном стиле, через месяцев 4-5 пошло более менее идиоматичное ООП, с элементами ФП. При наличии более опытных товарищей думаю быстрее бы прошла адаптация.
Я в общем то на своем опыте такое провернул. Спустя года 3 в 1с, может чуть раньше начал изучать не привязанные к языкам вещи, читал дядюшку боба, макконела, хабр, смотрел записи конференций, читал про ООП и паттерны. А потом, после еще полутора-двух лет перешел на котлин достаточно спокойно, даже с учетом что менторить некому меня было. Оценить трудно самому себя, но где то через месяц ушел от программирования в процедурном стиле, через месяцев 4-5 пошло более менее идиоматичное ООП, с элементами ФП. При наличии более опытных товарищей думаю быстрее бы прошла адаптация.
НЛО прилетело и опубликовало эту надпись здесь
Да нет там ООП. Там одни обрывки от него не дающие никаких знаний ООП и навыков практического использования этой парадигмы.
Вообще то там есть ООП, просто объекты фиксированы)
ООП это всякий там полиморфизм, наследование и т.п. там этого нет от слова совсем, то что там некоторые системные объекты «какбы» работают по принципам ООП, это не означает что оно там есть… этим же нельзя пользоваться
Это все примерно так и было, только у нас нет ООП :) И освоить нужно было не так мало — еще одну СУБД MS SQL, еще два языка — груви и скалу, Apache Spark, Hive, Oozie, Hadoop. Ну таки да, опыт написания какого-то кода был, а главное был опыт SQL, который и пригодился полностью.
Такие выражения как: пределы, математическое мышление, экстремум, производные, многочлены и т.д. для меня оказались как речь на языке племени Майя.
Для 99% программ это не нужно.
Я сам не люблю и слабо понимаю математику, хотя и занимаюсь 3D графикой =)
Неужели чтобы стать программистом без технической базы, требуется так много времени?
Просто не нужно распыляться. Берите один язык и пользуйтесь им, любой.
А вот эта задача меня вообще заставила остановиться на чтении книги по CS
Какое отношение эта задача имеет к программированию? Никакого.
Качаю книгу Кернигана и Ричи «Язык С»
Вместо всяких курсов по CS и древних книг лучше обратите внимание на такую серию:
stolyarov.info/books/programming_intro
У меня, и многих моих коллег был путь снизу-вверх: от электроники к программированию.
Когда знаешь как работает железо, просто не может быть проблем с пониманием всех нюансов использования переменных/циклов/указателей.
И как Вы учили электронику без математики???
И вот на оставшийся процент и придется потратить 99% времени
.Для 99% программ это не нужно.
И вот на оставшийся процент и придется потратить 99% времени
Чтобы собирать любительские схемы из книжек и проектировать свои из готовых блоков и по готовым шаблонам расчётов, никакой особой математики не нужно. Нужен калькулятор.
Ну да, у меня был как раз. Б3-34. (1983 год) Первое что я на нем написал — это численное интегрирование дифф. уравнения методом рунге кутта 4 порядка. По странному совпадению как раз для расчета схемы.
Ни в одном учебном заведении электронику без математики не преподают.
Сначала просто математика. А потом уже электроника.
Ни в одном учебном заведении электронику без математики не преподают.
Сначала просто математика. А потом уже электроника.
Извините, но Паскаль в 2020 году это за гранью разумного.
Керниган-Ритчи — великолепны. Не знаю как для взрослых, а для школьников отлично заходит для обучения азам.
Керниган-Ритчи — великолепны. Не знаю как для взрослых, а для школьников отлично заходит для обучения азам.
.Паскаль в 2020 году это за гранью разумного
Почему? Вполне симпатичный язык для обучения. И полный по Тьюрингу естественно.
Почему? Вполне симпатичный язык для обучения.
Он депрекейтед.
У него плохой синтаксис.
Мы же не хотим чтобы школьники считали что их учат языку динозавров? Да и просто новичков не хотим учить вымершему языку.
Тем более что есть отличный Си. Живой, развивающися, на нем реально пишут продакшен софт, его синтаксис в основе примерно всего. На уровне обучения простейший. При обучении показываем немного самого простого сахара из плюсов и вообще хорошо. Страданий при обучении будет минимум.
И полный по Тьюрингу естественно.
Баш тоже Тьюринг полный. Но это же не повод его изучать первым?
Да и CSS Тьюринг полный. Это же не повод на нем писать программы?
Не знаю, мне нравится
en.m.wikipedia.org/wiki/Free_Pascal
Stable release 2 months ago
У него компактный компилятор, который легко спортировать на маленькую платформу
en.m.wikipedia.org/wiki/Free_Pascal
Stable release 2 months ago
У него компактный компилятор, который легко спортировать на маленькую платформу
Не знаю, мне нравится
github.com/Clozure/ccl/releases
released this on 20 Apr
У него компактный компилятор, который легко спортировать на маленькую платформу
PS: Дельфисты атакуют. Вы хотя бы пишите что не так. Чем вам Керниган-Ритчи и Си как первый язык для обучения основам не угодил. Уже минимум пара поколений разрабочиков на них выросли.
github.com/Clozure/ccl/releases
released this on 20 Apr
У него компактный компилятор, который легко спортировать на маленькую платформу
PS: Дельфисты атакуют. Вы хотя бы пишите что не так. Чем вам Керниган-Ритчи и Си как первый язык для обучения основам не угодил. Уже минимум пара поколений разрабочиков на них выросли.
Да меня вполне язык С устраивает, на нем и пишу, он хороший и удобный.Но Паскаль специально был написан для обучения, в нем есть некое изящество. Лично я начинал с Алгола, Фортран, APL потом Паскаль, Пролог, Лисп.
Переход с Паскаля на Си без проблем, они весьма близки идеологически. Бейсик, тот да, ужасен. Сейчас я развлекаюсь с разным ретро, вот там Паскаль иногда заходит удобнее чем Си.
Ну а на работе конечно с++ only.
PS Паскаль это эпоха, это священная корова, наезжать на неё нельзя
Переход с Паскаля на Си без проблем, они весьма близки идеологически. Бейсик, тот да, ужасен. Сейчас я развлекаюсь с разным ретро, вот там Паскаль иногда заходит удобнее чем Си.
Ну а на работе конечно с++ only.
PS Паскаль это эпоха, это священная корова, наезжать на неё нельзя
Ну да был написан для обучения. В итоге оказалось что когда теоретик делает язык для обучения получается не очень.
Учить второй очень похожий язык вторым это потеря времени. Это для нас пара недель с синтаксисом ознакомится и можно писать. Все же одинаковое у них. Для начинающих это все сложно и требует кучу времени. Я бы вторым предложил учить Питон. И уже на нем преподавать весь остальной cs.
Так совсем хорошо выйдет и с парой Си/Питон уже любой язык будет знаком и похож на что-то уже выученное. (Любители Идриса проходите мимо, не про вас речь)
Ключевое слово ретро. Не надо ретро учить первым. Потом как хобби да не вопрос. Но первым что-то живое нужно.
Учить второй очень похожий язык вторым это потеря времени. Это для нас пара недель с синтаксисом ознакомится и можно писать. Все же одинаковое у них. Для начинающих это все сложно и требует кучу времени. Я бы вторым предложил учить Питон. И уже на нем преподавать весь остальной cs.
Так совсем хорошо выйдет и с парой Си/Питон уже любой язык будет знаком и похож на что-то уже выученное. (Любители Идриса проходите мимо, не про вас речь)
с я развлекаюсь с разным ретро, вот там Паскаль
Ключевое слово ретро. Не надо ретро учить первым. Потом как хобби да не вопрос. Но первым что-то живое нужно.
Все таки Си не очень хорош как первый язык. Он слишком свободный и имеет много вариантов и стиля и собственно самого языка. Легко написать нечитаемую кашу. До сих пор нет единогласия о хорошем стиле программ на Си.
Более опытным программистам он очевидно удобней Паскаля, как минимум меньше букв в программе, но это достоинство на момент написания. Во многих областях до сих пор предпочитают весьма многословную АДА(у)
Более опытным программистам он очевидно удобней Паскаля, как минимум меньше букв в программе, но это достоинство на момент написания. Во многих областях до сих пор предпочитают весьма многословную АДА(у)
Да какие варианты? Я про классику, совсем классику. И совсем азы.
Переменные, циклы, структуры, указатели как самое сложное. И алгоритмы того же уровня. Пузырек и около того. 100 строк — предельный размер для программы. Их с любым стилем понять просто.
Свобода наоборот дает возможность поговорить с обучающимся. Почему он так сделал, а как еще можно сделать, а в чем разница? Красота же. Даже не углубляясь в тонкости в правильно написанной программе есть о чем поговорить.
Стиль это все потом. Тут что IDE сделает то и хорошо. Какой-нибудь MSVC вполне прилично все делает.
Переменные, циклы, структуры, указатели как самое сложное. И алгоритмы того же уровня. Пузырек и около того. 100 строк — предельный размер для программы. Их с любым стилем понять просто.
Свобода наоборот дает возможность поговорить с обучающимся. Почему он так сделал, а как еще можно сделать, а в чем разница? Красота же. Даже не углубляясь в тонкости в правильно написанной программе есть о чем поговорить.
Стиль это все потом. Тут что IDE сделает то и хорошо. Какой-нибудь MSVC вполне прилично все делает.
Извинит, но Си в качестве первого языка — это как учится кататься на велосипеде, используя для этого его одноколёсный вариант.
Для чего нужен первый язык — для связи бумажной алгоритмики с реальным программированием. В первом языке не должно быть свободы — он ДОЛЖЕН быть дубовым. Чтобы не отвлекаться на синтаксис, а заниматься непосредственно творчеством.
Какая радость для начинающего от возможности обратится к массиву пятью различными способами? Или написать инкрементацию тремя?
Для чего нужен первый язык — для связи бумажной алгоритмики с реальным программированием. В первом языке не должно быть свободы — он ДОЛЖЕН быть дубовым. Чтобы не отвлекаться на синтаксис, а заниматься непосредственно творчеством.
Какая радость для начинающего от возможности обратится к массиву пятью различными способами? Или написать инкрементацию тремя?
Как я уже говорил язык должен быть живым. И школьники и студенты не хотят учить что-то времен динозавров. На их логичный вопрос, а кто и что на этом языке пишет я затруднюсь ответить. Следующий вопрос а зачем мы его тогда учим тоже останется без ответа.
С Сями можно потратить полчасика на рассказ про git и помигать лампочками на ардуинке.
Вы тех же Керниган-Ритчи читали? Сначала рассказывается про один способ. Лабы, практика, вперед.
Все остальное в разделе указатели. Понимание что такое указатель приходит очень долго и очень тяжело. И чем больше примеров и того что можно пощупать в этом месте тем лучше.
С Сями можно потратить полчасика на рассказ про git и помигать лампочками на ардуинке.
Какая радость для начинающего от возможности обратится к массиву пятью различными способами? Или написать инкрементацию тремя?
Вы тех же Керниган-Ритчи читали? Сначала рассказывается про один способ. Лабы, практика, вперед.
Все остальное в разделе указатели. Понимание что такое указатель приходит очень долго и очень тяжело. И чем больше примеров и того что можно пощупать в этом месте тем лучше.
С Сями можно потратить полчасика на рассказ про git
Если речь про обучение программированию с нуля в школе, то никак вы за полчасика с гит не разберётесь.
Ветки, пуш, пулл, мердж в полчаса укладываются. Если что не так действуем по инструкции.
Тут важно что это Си. Живой, массовый и сложный проект. Учим не мертвому языку дедов, а живому на котором пишут живые проекты.
Тут важно что это Си. Живой, массовый и сложный проект. Учим не мертвому языку дедов, а живому на котором пишут живые проекты.
У вас как-то через все сообщения проскальзывает вот этот «язык дедов», «времен динозавров». Хотя, казалось бы, оперировать понятиями «модно» / «не модно» — так себе аргумент.
Quicksort, например, из 1960-х. Я так понимаю, вы его тоже будете рекомендовать не использовать? :)
Quicksort, например, из 1960-х. Я так понимаю, вы его тоже будете рекомендовать не использовать? :)
На уроке сначала рассказываете про гит/свн, а потом даёте групповой проект на семестр. Тут хочешь — не хочешь разберешься, это при сольной разработке можно себя убедить, что контроль версий не нужен.
Пффф, вы не видели глубин изобретательности, до которых могут дойти люди, поставившие себе четкую цель не использовать контроль версий.
Вы переоцениваете возможности обычных учеников. Я раньше на курсах всегда уделял час, чтобы рассказать основные команды гита. Более того, я даже сделал методичку с картинками, чтобы можно было с ее помощью дома все повторить.
Но так у меня сбежало 2 ученика. В обратной связи оставили "я даже не могу понять как сохранять проект, куда мне изучать программирование?".
Поэтому я гит даю только тем, кто умненький и не раньше второго занятия.
Понимаете, какая штука, все, о чем вы говорите — правильно. И всё это будет — но позже.
Вы мешаете в кучу язык для обучения и язык для разработки.
Язык для обучения должен быть неудобен. Он должен постоянно заставлять выкручивать мозги. Он обязан содержать минимум инструкций. Он должен научить человека программировать что угодно при помощи говна и палок.
Тут как в армии, на курсе молодого бойца: -«Любой дурак выкопает окоп лопатой. А ты сумей ножом и руками. Сумел? Потом выкопаешь чем угодно»
Не помню кто сказал что люди делятся на тех, кто программирует и тех кто нет. Те, кто программируют, могут программировать что угодно — от древней релейной логики до трассировки лучей на новейших видеокартах.
Поясню на примере: чего может быть проще перебрать массив от большего индекса к меньшему. Это если счетчик в цикле может уменьшатся. А если нет, только расти? Это для вас это проще чем элементарно, а для начинающего — интеллектуальный оргазм. Или выбрать каждый третий элемент, а приращение в цикле возможно только на единицу.
Или узнать величину файла не через запрос к системе, а через посимвольное считывание до достижения конца файла.
С точки зрения продакшена язык для обучения ужасен.
Но язык обучения не предназначен для разработки, хотя такое тоже встречается.
Вы мешаете в кучу язык для обучения и язык для разработки.
Язык для обучения должен быть неудобен. Он должен постоянно заставлять выкручивать мозги. Он обязан содержать минимум инструкций. Он должен научить человека программировать что угодно при помощи говна и палок.
Тут как в армии, на курсе молодого бойца: -«Любой дурак выкопает окоп лопатой. А ты сумей ножом и руками. Сумел? Потом выкопаешь чем угодно»
Не помню кто сказал что люди делятся на тех, кто программирует и тех кто нет. Те, кто программируют, могут программировать что угодно — от древней релейной логики до трассировки лучей на новейших видеокартах.
Поясню на примере: чего может быть проще перебрать массив от большего индекса к меньшему. Это если счетчик в цикле может уменьшатся. А если нет, только расти? Это для вас это проще чем элементарно, а для начинающего — интеллектуальный оргазм. Или выбрать каждый третий элемент, а приращение в цикле возможно только на единицу.
Или узнать величину файла не через запрос к системе, а через посимвольное считывание до достижения конца файла.
С точки зрения продакшена язык для обучения ужасен.
Но язык обучения не предназначен для разработки, хотя такое тоже встречается.
Тогда лучший язык для обучения — Brainfuck.
Впрочем, машина Тьюринга тоже сойдет.
Впрочем, машина Тьюринга тоже сойдет.
У нас (МАИ, не школа) были таки машины тьюринга, потом их связки, потом паскаль как основа курса алгоритмов, си++ как основа курса ООП, пролог, Оракловый вариант скуля как основа курса РБД.
Без глубоких заходов в IDE и библиотеки. С учтом того, что на С++ писали в Борланд билдере — правильно что без заходов.
Без глубоких заходов в IDE и библиотеки. С учтом того, что на С++ писали в Борланд билдере — правильно что без заходов.
Ассемблер-же!
Ассемблер — очень широкое понятие.
В общем случае — это просто замена кодов машинных команд некими символьными обозначениями для облегчения запоминания.
Соответственно, все упирается в умения «процессора» (то есть исполнителя команд), его набор команд. Если это исполнитель умеет делать 100500 различных действий, закодированных каждое в свою команду (например, одной командой посчитать факториал, интеграл, переместить/скопировать целый блок памяти и т.п.) — то программирование на его ассемблере получается весьма высокоуровневым.
Машина Тьюринга — это абстрактная штука, чтоб говорить о ней предметно, нужно задаться какой-то конкретной реализацией. Так что рассмотрим очень похожую машину Поста. У нее всего 6 команд и унарная система счисления. Уже банальное сложение и вычитание двух чисел на ней — небольшая головоломка, в то время как почти любой процессор, программируемый на ассемблере, умеет это делать аппаратно.
В общем случае — это просто замена кодов машинных команд некими символьными обозначениями для облегчения запоминания.
Соответственно, все упирается в умения «процессора» (то есть исполнителя команд), его набор команд. Если это исполнитель умеет делать 100500 различных действий, закодированных каждое в свою команду (например, одной командой посчитать факториал, интеграл, переместить/скопировать целый блок памяти и т.п.) — то программирование на его ассемблере получается весьма высокоуровневым.
Машина Тьюринга — это абстрактная штука, чтоб говорить о ней предметно, нужно задаться какой-то конкретной реализацией. Так что рассмотрим очень похожую машину Поста. У нее всего 6 команд и унарная система счисления. Уже банальное сложение и вычитание двух чисел на ней — небольшая головоломка, в то время как почти любой процессор, программируемый на ассемблере, умеет это делать аппаратно.
Язык для обучения должен быть неудобен. Он должен постоянно заставлять выкручивать мозги. Он обязан содержать минимум инструкций. Он должен научить человека программировать что угодно при помощи говна и палок.
Вы принципиально путаете
1) обучение на профессионального хакера (в реймондовском смысле),
2) обучение на программиста вообще,
3) обучение на не-программиста с навыком автоматизации с помощью компьютера.
Ваш подход годится для (1) и изредка для (2), в то время как на них вообще статистически не нужно тратить усилия — сами обучатся — а основные методики надо нарабатывать для (3), потому что критична массовая компьютерная неграмотность.
НЛО прилетело и опубликовало эту надпись здесь
Вы не учитываете одну важную вещь. Большинство людей, которые начинают изучать программирование (это обычно 5/7/9 класс обычной средней школы) не планируют становится программистами. И совершенно не готовы погрузиться в изучение нюансов. Поэтому главный признак, которым должен обладать первый язык — он должен давать возможность быстро сделать что-то содержательное, чтобы хоть пробудить интерес. Я по этой причине топлю за питон: простой и позволяет в 5 строк сделать очень многое: хоть график построить, хоть сервачок написать. И наличие REPL-а позволяет очень быстро проверять гипотезы, когда не знаешь, как правильно.
Да, явная типизация может помочь в обучении, но жить без неё вполне можно (тем более, что в современном питоне есть опциональные аннотации типов). А вот без быстрого старта язык непригоден для большинства.
Да, явная типизация может помочь в обучении, но жить без неё вполне можно (тем более, что в современном питоне есть опциональные аннотации типов). А вот без быстрого старта язык непригоден для большинства.
У си в качестве первого языка есть очень большой минус — это запредельное количество синтаксических конструкций на старте, смысл которых невозможно объяснить человеку, который только-только начинает изучать язык. Все эти #include <stdio>, printf/scanf, их первый параметр и амперсанд перед вторым параметром в scanf (в плане ввода-вывода, C++ немного проще). Сравните write/writeln/read/readln, доступными из коробки в паскале.
Любая магия, непонятная на старте, сильно отбивает охоту учиться, особенно у школьников, у которых нет дополнительных источников мотивации.
В своё время я, изучая книжку по Паскалю, тупо забил на работу с графикой (прочитал книжку, т.к. любил читать, но программы с использованием графики не делал), т.к. не понимал смысла нескольких строчек, необходимых для инициализации (работа с драйверами и т.п.) и лишь где-то через год, когда почитал подробнее про устройство PC, у меня вновь появился интерес к соответствующему разделу книги.
На кружке по изучению ардуинки можно использовать си, т.к. там программирование не является единственным направлением изучения (да и с вводом-выводом не приходится сталкиваться). Но для изучение именно основ программирования школьниками, си не очень подходит, т.к. способен отбить интерес прямо на старте.
Любая магия, непонятная на старте, сильно отбивает охоту учиться, особенно у школьников, у которых нет дополнительных источников мотивации.
В своё время я, изучая книжку по Паскалю, тупо забил на работу с графикой (прочитал книжку, т.к. любил читать, но программы с использованием графики не делал), т.к. не понимал смысла нескольких строчек, необходимых для инициализации (работа с драйверами и т.п.) и лишь где-то через год, когда почитал подробнее про устройство PC, у меня вновь появился интерес к соответствующему разделу книги.
На кружке по изучению ардуинки можно использовать си, т.к. там программирование не является единственным направлением изучения (да и с вводом-выводом не приходится сталкиваться). Но для изучение именно основ программирования школьниками, си не очень подходит, т.к. способен отбить интерес прямо на старте.
Сравните write/writeln/read/readln, доступными из коробки в паскале.
Сравнил.
Почему write(a, b, c), где a, b, c типа real, и в то же время write(out, a, b, c), где a, b, c типа file? Как мне различить эти конструкции? Что будет, если я вызову write(a, b, c, out)?
В C было сразу понятно — есть printf с stdout, а есть fprintf с конкретным файлом (и можно тоже указать stdout).
Почему надо было писать write(a:15:3), что это за конструкция? Почему тут особый случай и почему я не могу сделать свою функцию с таким же? (Реально хотелось, как раз как переходник для вывода результатов.)
Почему в конце программы "end.", а не "end;"?
Почему перед else нельзя ставить точку с запятой, а перед end — можно, но она ни на что не влияет?
Почему var перед программой (процедурой, функцией) и почему один на все переменные?
Почему в списке формальных параметров var вдруг начинает значить передачу по указателю (или in-out, не помню точно)? Почему не отдельное слово?
Почему такое резкое отличие между procedure и function?
Зачем возможность вызова функции или процедуры просто по их имени, без скобок? (Сравнивая с современными, Паскаль ни капельки ни ФП, чтобы это можно было оправдать.)
И ещё два десятка подобных недоумённых вопросов, но, думаю, уже достаточно.
это запредельное количество синтаксических конструкций на старте, смысл которых невозможно объяснить человеку, который только-только начинает изучать язык.
Вот для меня как учившего оба в конце 80-х — в Паскале было больше подобных непонятных конструкций, которые надо было зазубрить без понимания их причины, чем в C, и они были каждая сама по себе непонятнее.
Сам же принцип "надо добавить определённые заклинания" был понятен с первого упоминания. Люди же здороваются и прощаются, так и тут...
Вы просто натягиваете опыт C на Паскаль, из-за чего и возникает недопонимание. Забудьте C, и тогда Паскаль станет простым и логичным языком.
Почему write(a, b, c), где a, b, c типа real, и в то же время write(out, a, b, c), где a, b, c типа file? Как мне различить эти конструкции? Что будет, если я вызову write(a, b, c, out)?
Только в отличие от C, где вы в printf можете запихнуть вообще всё, что угодно, выстрелив себе в ногу, в Паскале всё строго типизировано. Вы никак не сможете передать аргументы типа file в качестве параметров, кроме первого.
Почему надо было писать write(a:15:3), что это за конструкция? Почему тут особый случай и почему я не могу сделать свою функцию с таким же?
Потому что Write в Паскале — это compile-time конструкция. Так решили авторы языка. И если бы в Паскале был C-style printf, то он бы тоже был compile-time с проверкой типов аргументов при компиляции и без возможности генерации строки форматирования в рантайме.
Почему в конце программы "end.", а не "end;"? Почему перед else нельзя ставить точку с запятой, а перед end — можно, но она ни на что не влияет?
Потому что ; в C — это признак конца выражения, а в Паскале — разделитель между выражениями в блоке. Оба подхода имеют право на жизнь.
Почему var перед программой (процедурой, функцией) и почему один на все переменные?
Не забывайте, что Паскаль — язык для обучения азам. В С можно себе выстрелить в ногу, объявив scoped-based переменную с тем же именем, что и внешняя переменная. А ещё в C можно случайно перепутать вызов функции, объявление функции и объявление переменной.
Почему в списке формальных параметров var вдруг начинает значить передачу по указателю (или in-out, не помню точно)? Почему не отдельное слово?
А хрен его знает. Видимо, чтобы не плодить ключевые слова.
Почему такое резкое отличие между procedure и function?
Скорее, больше бесит, что функция не может вернуть record. И вызов без скобок тоже бесит, да.
Забудьте C, и тогда Паскаль станет простым и логичным языком.
Сколько ещё и каких нормальных языков я должен забыть, чтобы кривости Паскаля стали "простыми и логичными"?
Большинство языков таких тараканов не держат. Хотя можно сравнить этот write/writeln, например, с C++, где на шаблонах ещё и не такое можно построить (например, у парсеров на Spirit несколько разнотипных аргументов шаблонов в любом порядке)… но там юзер уже заранее готов к подобным шуткам, в отличие от тех, кто вообще впервые учится Паскалю.
(Заметьте, я сказал и про плюсы Паскаля. Но они не сыграли в его пользу, чтобы он выжил.)
Вы никак не сможете передать аргументы типа file в качестве параметров, кроме первого.
Почему собственно? Может, я хочу, чтобы напечатало тип аргумента и основные свойства как файла (имя, режим открытия и т.п.)?
Но главное таки не это, а то, что:
1) Эти якобы функции на самом деле не функции, а похожий механизм, но разбираемый компилятором,
2) Я не могу сделать такое же своими средствами, это нерасширяемый хак компилятора.
Если бы их не оформляли в виде "типа функций", это было бы честнее. Если бы дали аналогичное средство самим, это было бы полезнее и для учёбы, и для продуктина.
Потому что Write в Паскале — это compile-time конструкция. Так решили авторы языка. И если бы в Паскале был C-style printf, то он бы тоже был compile-time с проверкой типов аргументов при компиляции и без возможности генерации строки форматирования в рантайме.
Ну так где оно? Почему недоступно? Почему я не могу сделать свой write?
Ах, "язык для обучения"… ну так язык, который пригоден только для обучения, не будет в итоге вообще использоваться для обучения.
Видимо, поэтому в Delphi в итоге сделали впараллель C-подобный подход.
Потому что; в C — это признак конца выражения, а в Паскале — разделитель между выражениями в блоке. Оба подхода имеют право на жизнь.
С таким подходом любая глупость "имеет право на жизнь", хотя бы в качестве легаси.
Но если мы думаем о побочных эффектах решения, то вариант с разделителем имеет их сильно больше, и это от языка не зависит.
То же самое относится к необязательности блоковых скобок.
Скорее, больше бесит, что функция не может вернуть record. И вызов без скобок тоже бесит, да.
Тип возврата — да, проблема (в C это тоже полу-костыль).
Что б Вы понимали в извращениях :-)
Вот с таким кодом поработать и Паскаль за счастье будет
Позиционирование здесь не прихоть разработчика, а требование языка. Каждая буковка, каждый символ должны стоять строго на своем месте. В редакторе вверху даже линеечка есть с разметкой что куда позиционировать.
Вот с таким кодом поработать и Паскаль за счастье будет
Позиционирование здесь не прихоть разработчика, а требование языка. Каждая буковка, каждый символ должны стоять строго на своем месте. В редакторе вверху даже линеечка есть с разметкой что куда позиционировать.
Каждая буковка, каждый символ должны стоять строго на своем месте.
Ну судя по строке 37 (3700, если по разметке) и дальше, не всё так жёстко? Или тут две разные разметки?
Я писал на стандартном (фиксированного формата) Фортране, и не сказал бы, что это какой-то существенный ужас. В RPG меня больше напрягает сама логика языка — что и как делается — а не его конкретное представление. Не хочу выворачивать мышление на эту логику, для моих задач не окупится :)
Это другая разметка — там уже O начинается. А код — C
Я плоховато fixed знаю (ну так скажем, на уровне чтения немного) и не помню уже что такое O-секция. Что-то связанное с выводом. Судя по всему — внешний источник для вывода с расписанными полями.
Не помню чтобы в наших старых такое встречалось.
Сама логика, особенно во FREE особо не напрягает — язык и язык. Она несколько отличается от общепринятой, но вся AS-ка отличается от привычного :-)
Что неудобно на RPG — пишу на С/С++.
У меня вот сейчас в задаче один из PGM объектов собирается и 15-ти модулей. Из которых пара SQLRPG, штуки три CPP остальные RPG
Я плоховато fixed знаю (ну так скажем, на уровне чтения немного) и не помню уже что такое O-секция. Что-то связанное с выводом. Судя по всему — внешний источник для вывода с расписанными полями.
Не помню чтобы в наших старых такое встречалось.
Сама логика, особенно во FREE особо не напрягает — язык и язык. Она несколько отличается от общепринятой, но вся AS-ка отличается от привычного :-)
Что неудобно на RPG — пишу на С/С++.
У меня вот сейчас в задаче один из PGM объектов собирается и 15-ти модулей. Из которых пара SQLRPG, штуки три CPP остальные RPG
Я из АС-ки только QSEQOFR помню, под которым мы базу на ленточки бэкапили. Для бэкапов отдельный экран был.
Давайте начнём хотя бы с того, что Паскаль появился на пару лет раньше С. И для языка, которому исполнилось уже 50 лет и который дошёл до наших дней практически в неизменном виде — это отличный результат.
Конечно, современные языки избавились от многих проблем, но вот выделить среди них хороший язык, который хорошо подходит для обучения программированию, я затрудняюсь. У всех имеются различные проблемы.
И для языка, которому исполнилось уже 50 лет и который дошёл до наших дней практически в неизменном виде — это отличный результат.
В практическом применении (которое надо с микроскопом искать) остался разве что Delphi, который очень изменился по сравнению с Паскалем 1970-го года. Поэтому нету ни "неизменного вида", ни "отличного результата": результат ужасный — язык вымер, причём завалив всю цепочку потомков (разве что Ada выжила на госзаказах).
Конечно, современные языки избавились от многих проблем, но вот выделить среди них хороший язык, который хорошо подходит для обучения программированию, я затрудняюсь. У всех имеются различные проблемы.
По сравнению с языком, который для этого уже не менее 20 лет не подходит, они все относительно неплохи. Python в этой роли разве что ленивый не предлагал. Я вот ещё смотрю на Swift.
Так совсем хорошо выйдет и с парой Си/Питон уже любой язык будет знаком и похож на что-то уже выученное.
Да они ведь во многом похожи как языки, на базовом уровне. Те же переменные, if/for/etc, функции, etc — разница в чуть другом стиле синтаксиса и явном указании типа в Си. Паскаль и иже с ним туда же.
Если говорить о разнообразии, то есть множество используемых языков, которые намного сильнее отличаются — из относительно популярных например скала/f#/лиспы/хаскель.
А вот нужно ли разнообразие при обучении программированию — зависит, думаю, от уровня. Не вижу особой проблемы начинать с паскаля в школе, кто заинтересуется изучит и другие.
Да они же во многом похожи как языки, на базовом уровне. Те же переменные, if/for/etc, функции, etc — разница в чуть другом стиле синтаксиса и явном указании типа в Си. Паскаль и иже с ним туда же.
Это приходит через годы регулярного написания кода. До этого все сложно. Питон удобнее всего чтобы обучать именно CS.
Си быстро придут к плюсам при попытках учить на них. А плюсы сложны сами по себе, даже без всего остального. Люди будут одновременно мучаться с пониманием принципа работы хешмапы и с тем как это написать.
Не надо вываливать на человека сразу все. Пусть учит все по отдельности.
из относительно популярных например скала/f#/лиспы/хаскель.
Хотя бы полгода Коммон Лиспа курсе на четвертом это хорошо и полезно. Но не раньше. Человек перед изучение должен уметь код писать. Обычный и простой код.
Мы тут про азы. На чем рассказывать про циклы с переменными и на чем первый пузырек писать.
Хотя бы полгода Коммон Лиспа курсе на четвертом это хорошо и полезно. Но не раньше. Человек перед изучение должен уметь код писать. Обычный и простой код.
Мы тут про азы. На чем рассказывать про циклы с переменными и на чем первый пузырек писать.
Есть какие-то исследования, что условный питон эффективнее для начального обучения программированию, чем условный лисп? По-моему это совершенно неочевидно. Конечно, если речь не идёт о курсах типа "дата саенс за 21 день".
Я бы с радостью посмотрел за таким А/Б экспериментом.
Берем 2 группы студентов технарей.
Считаем что они обучены простейшим вещам и ничего кроме них. Одну группу учим Хаскелю и cs на нем. Вторую Питону и cs на нем. Через год и через два года подбиваем результаты.
Вылетел 1 балл.
Попытка самоубийства 100 баллов.
Берем 2 группы студентов технарей.
Считаем что они обучены простейшим вещам и ничего кроме них. Одну группу учим Хаскелю и cs на нем. Вторую Питону и cs на нем. Через год и через два года подбиваем результаты.
Вылетел 1 балл.
Попытка самоубийства 100 баллов.
Ну а как вы себе это представляете? Берём студентов и начинаем экспериментировать с их жизнью, а если провал — ну ничего, новые через год придут?
Были какие-то исследования о том, что с функциональных языков вроде как неплохо начинать, но это всё довольно ненадёжно, и людей жалко, опыты такие проводить.
Были какие-то исследования о том, что с функциональных языков вроде как неплохо начинать, но это всё довольно ненадёжно, и людей жалко, опыты такие проводить.
Ну а как вы себе это представляете? Берём студентов и начинаем экспериментировать с их жизнью, а если провал — ну ничего, новые через год придут?
хм. а почему нет-то? вы предлагаете ровно так же экспериментировать со всеми студентами, обучая их только по одному варианту (ведь неизвестно же, что он лучший).
Нет, почему же. У нас же есть представление о том, как мир в целом устроен: чтобы убедиться, что человек умрёт, упав с десятиэтажного дома, нет необходимости физически сбрасывать людей с крыши.
При выборе языка программирования в школе/университете самый простой критерий — это смотреть, какие языки по факту востребованы на рынке, а из них уже выбирать объективно наименее навороченные. То есть можно для начала воспользоваться другими критериями, «простота обучения» не единственный из них.
Если же продвигать идею «а давайте обучать на языке X; пусть он непопулярен, зато проще для обучения», то надо сперва доказать, что он и вправду проще, потому что иначе в этой идее совсем смысла нет.
При выборе языка программирования в школе/университете самый простой критерий — это смотреть, какие языки по факту востребованы на рынке, а из них уже выбирать объективно наименее навороченные. То есть можно для начала воспользоваться другими критериями, «простота обучения» не единственный из них.
Если же продвигать идею «а давайте обучать на языке X; пусть он непопулярен, зато проще для обучения», то надо сперва доказать, что он и вправду проще, потому что иначе в этой идее совсем смысла нет.
Если же продвигать идею «а давайте обучать на языке X; пусть он непопулярен, зато проще для обучения», то надо сперва доказать, что он и вправду проще, потому что иначе в этой идее совсем смысла нет.
хм, я бы говорил не про «проще для изучения», а про «лучше для обучения».
При выборе языка программирования в школе/университете самый простой критерий — это смотреть, какие языки по факту востребованы на рынке, а из них уже выбирать объективно наименее навороченные.
в раннем возрасте — не вижу ничего плохого в специальных языках для обучения.
читать дети тоже не по «Войне и миру» учатся, для этого придумали азбуки и красочные книжки с минимумом текста.
в университете — наверное, да, тут подразумевается, что начальные навыки программирования уже есть, можно выбирать из востребованных на рынке (и почему менее навороченные?).
впрочем, не вижу ничего плохого в изучении какого-то академического языка в университете (разумеется, знакомство с «реальными» языками при этом обязательно). впрочем, многие проекты, начинавшиеся как академические, со временем находят себе применение и в «гражданской жизни».
про «лучше для обучения».
Да пусть так. Осталось выяснить, как понять, какой же лучше.
не вижу ничего плохого в специальных языках для обучения.
Я тоже. К сожалению, они по факту все вымерли, ну вот разве что Scratch есть, но это всё-таки немного другая лига.
Осталось выяснить, как понять, какой же лучше.Если брать «программирование вообще», то максимально отвязанный от железа: лисп, тикль, питон или ещё что-то выразительное, но очень медленное.
Ну вот я лично думаю, что Питон, потому что он объективно ненамного хуже «любого другого языка», и при этом очень популярен на практике. Т.е. ценой небольших гипотетических неудобств по сравнению с «языком X» студент получает бонусом готовый практический навык для работы.
Вот условно 30 лет назад такой опции не было: либо чисто учебный Бейсик, либо «туда-сюда» Паскаль, либо уже по хардкору с головой в C/С++ и иже с ними.
Вот условно 30 лет назад такой опции не было: либо чисто учебный Бейсик, либо «туда-сюда» Паскаль, либо уже по хардкору с головой в C/С++ и иже с ними.
ненамного хуже «любого другого языка», и при этом очень популярен на практике.Это да. Но именно как учебный мне больше нравится лисп, просто потому, что на нём в силу единства данных и кода можно сделать вообще всё, и это будет достаточно лаконично. Своя система типов? Своё ООП с плюшками? ФП? Рекомендательные системы? Логическое программирование? Всё это можно реализовать в сотни-тысячи строк поверх ванильного лиспа. Тикль, внебрачный сын плюсов и лиспа, кстати, всё это же поддерживает, просто там синтаксис ещё более мутный. А вот как в питоне, например, перейти от ООП на классах к ООП на прототипах я вообще не пойму.
EDIT Правда, если учить студентов ближе к индустрии, то принцип «Если на текущем ЯП тебе приходится вывихивать мозг над задачей, а на другом ЯП это три строчки, пиши на другом плюс биндинг» придётся внушать. Питон изначально разрабатывался как язык — универсальный клей, так что тут он в самую тему.
НЛО прилетело и опубликовало эту надпись здесь
Типов нет же.
Что, сегодня отменили? Вчера ещё были.
PS: да, я понимаю. Но давайте строже в деталях. Динамичность как раз достаточно мало мешает учебным задачам.
НЛО прилетело и опубликовало эту надпись здесь
Скиньте, plz. Уложу в коллекцию.
Вообще, не то, чтобы я не был согласен — я как раз считаю, что расставлять статичность по максимуму (кроме явно огороженных мест) оно полезно всегда. Но чувство — не доказательство.
НЛО прилетело и опубликовало эту надпись здесь
Даже в вашей цитате последней фразой написано, что использование термина "динамическая типизация" является стандартом :) И по факту непонимания (почти?) никогда не создаёт.
Привязывание более строгой терминологии, чтобы она покрывала все имеющиеся случаи, кажется весьма затруднительным. Например, по приведённой цитате не особо понятно, что означает "tractable syntactic method" или "static approximation [of behaviour]". Как к этому относиться в случае языка, который позволяет тьюринг-полные вычисления на уровне типов/во время компиляции? А если язык типа C# вроде бы статически типизированный (кроме "dynamic"), но с помощью reflection во время выполнения можно много чего нагородить?
Во-первых, есть, как же нет. А во-вторых, не вижу трагедии. Это тоже был один из пунктов спора Basic vs. Pascal. Я на Бейсике учился, и ничего.
НЛО прилетело и опубликовало эту надпись здесь
Типы, конечно, мышление дисциплинируют, но я даже не знаю, какой язык здесь бы подошёл хорошо. В языках типа C/Java/etc. ведь это всё равно «ненастоящие» типы, а точнее, это типы процессора, а не предметной области. В идеале тогда надо, чтобы язык требовал от юзера определения типов именно в рамках задачи.
НЛО прилетело и опубликовало эту надпись здесь
Что значит «а не»? У них только один язык за весь вузовский курс дают?
Так-то хаскель читать полезно, кто б спорил. Но в качестве первого языка, на мой взгляд, идея так себе.
Так-то хаскель читать полезно, кто б спорил. Но в качестве первого языка, на мой взгляд, идея так себе.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
так что для неподготовленного читателя тут написано «n равно n + 1».
так если человек учит программирование, особенно на нормальном языке, там в самом начале проходят операторы, и что бывают логические (типа ==) и операторы присваивания (пресловутое =)
Тут кстати на лицо проблемы проектирования которые тянутся из… языков типа си и бейсик, хотя логичней взять было паскаль для подобных конструкций
p.s. не помню кстати у себя проблем с такими выражениями
В стародавние времена для присваивания («положить») использовался знак :=
n := n + 1
Но потом решили, что и просто '=' понятно.
:)
n := n + 1
Но потом решили, что и просто '=' понятно.
:)
Добавлю, что частое заблуждение в связи с присваиванием в виде "a = b + c" что "a" это нечто, что вы бы называли функцией. Это нечто не хранит значение, а вычисляется в момент использования, используя значения из "b" и "c". Думаю это заблуждение как раз идет из школьной алгебры или физики.
Поэтому "a = a + 1" — конструкция, которая всегда вызывает вопросы "а так разве можно?".
Это заблуждение возникает поголовно у всех, с кем я занимался с "честного" нуля.
Ага. Вот что делает следующая конструкция?
if (n = n + 1) { ... }Несмотря на то, что побочное действие оператора присваивания бывает иногда полезно и удобно, оно является источником ошибок.
Выразительно и медленно совершенно не обязательно сочетается в одном языке.
Я не могу вспомнить быстрый выразительный язык.
НЛО прилетело и опубликовало эту надпись здесь
Какие критерии?
Можно начать рассматривать со Swift или Go.
В первую очередь краткость, читаемость и возможность реализовать произвольную идею из CS. Го, имхо, заточенный под индустрию язык: что в него заложено, то делается просто, а о чем не подумали авторы — то поразительно многословно.
OK. Против Swift есть претензии?
Я ещё смотрю на старых зверей типа Java и на всякие Julia.
На Свифте и на Джулии и строчки не написал, честно говоря, так что высказывать что-либо не стану. Джава язык очень многословный, с вкраплениями магии. Я её помню с версии 1,5, с тех пор она стала лучше, но некоторый вещи туда всунуты с самого начала, и даже массивное переосмысление в 1,4 не до конца помогло. Собсна, это описано в лирической части книжки Эккерта.
с вкраплениями магии
а где там магия?
Ну моё самое любимое:
1. Отсутствие беззнаковых целых. С 1.8 шаманство для их реализации проще, но всё-таки шаманство
2. Древнее развесистое дерево наследования, часть из которого deprecated, а в остальном можно запутаться. Как итог — введение стирания типов. Очень долго бегали от void* и каста к Object, а в итоге пришлось-таки сделать нечто подобное. Ну и единственный корень у дерева наследования мне не нравится, но это уже вкусовщина.
3. Невозможность просто сделать неизменяемый массив-член класса. Слово const зарезервировано, но использовать его нельзя :)
1. Отсутствие беззнаковых целых. С 1.8 шаманство для их реализации проще, но всё-таки шаманство
2. Древнее развесистое дерево наследования, часть из которого deprecated, а в остальном можно запутаться. Как итог — введение стирания типов. Очень долго бегали от void* и каста к Object, а в итоге пришлось-таки сделать нечто подобное. Ну и единственный корень у дерева наследования мне не нравится, но это уже вкусовщина.
3. Невозможность просто сделать неизменяемый массив-член класса. Слово const зарезервировано, но использовать его нельзя :)
НЛО прилетело и опубликовало эту надпись здесь
В последние годы появилось достаточно много "быстрых выразительных" языков для разных сфер применения. К предыдущему комментатору добавлю julia.
Ну, это расплывчато. И то и другое. Но я бы сказал, что если вернуться к вашей же фразе «лисп, тикль, питон или ещё что-то выразительное, но очень медленное», то найдется вполне десяток языков, которые а) достаточно выразительные (минимум как питон), но при этом б) сильно быстрее, скажем того же питона (который в общем тоже может быть быстрым, но ценой сильной потери выразительности и лаконичности).
Я не смогу это доказать, но подозреваю, что благодаря JIT компилятору многие языки на платформе Java вполне дадут питону фору в производительности (если мы не говорим о пакетах для питона, написанных на самом деле на C/C++).
Я не смогу это доказать, но подозреваю, что благодаря JIT компилятору многие языки на платформе Java вполне дадут питону фору в производительности (если мы не говорим о пакетах для питона, написанных на самом деле на C/C++).
Я не смогу это доказать, но подозреваю, что благодаря JIT компилятору многие языки на платформе Java вполне дадут питону фору в производительности
То, что это так — к гадалке не ходи — в Питоне слишком много тратится на постоянную проверку типов, лукапы по словарям методов и т.п. Так что ускорение раза в 5-10 от их исключения вполне можно предсказать. Но вот точные цифры будут катастрофически зависеть от задачи. Мои текущие это в основном общение со сложными объектами с развесистыми атрибутами… на них, может, больше 5 и не выйдет. На математике, понятно, и 1000 может быть (но её и так всю переложили на numpy с продолжателями).
читать дети тоже не по «Войне и миру» учатся, для этого придумали азбуки и красочные книжки с минимумом текста.Но читать дети учатся все-таки сразу именно на реальном языке, а не придумывают для этого специально искусственный. А азбуки и красочные книжки — это аналог «Hello World» и подобных простых учебных программ, но не другого языка.
Ну а как вы себе это представляете? Берём студентов и начинаем экспериментировать с их жизнью, а если провал — ну ничего, новые через год придут?
Так иного варианта-то нет. Так и экспериментируют, только (почти) никому не говоря, что это эксперимент. Если у вас есть маховик времени из саги про ГП — можно попробовать часть студентов учить впараллель. Но ведь его нет?
Просто начинают с относительно небольшой группы и пытаются по ней оценивать, стоит ли расширять эксперимент… (в лучшем случае)
Ну так интересантов нет. Представьте, что вы, условно, декан в университете. Зачем вам такое экспериментаторство? Смотрите, что преподаётся в хороших вузах, по каким языкам есть учебники и преподаватели (у вас), вот и утверждаете их. А если вы, условно, флагман типа MIT, там можно попытаться, но тоже не знаю, кому там подобные телодвижения интересны. Люди туда работать идут не ради того, чтобы выяснять, первокурсник лучше освоит лисп или питон.
А если вы, условно, флагман типа MIT, там можно попытаться, но тоже не знаю, кому там подобные телодвижения интересны
хорошо, что не все рассуждают так, как вы
Люди туда работать идут не ради того, чтобы выяснять, первокурсник лучше освоит лисп или питон.
нет, конечно, они приходят с убеждением «XXX лучше», спорят друг с другом, пробуют доказать верность своего подхода, пишут по этому поводу научные работы…
Ради бога. Я просто как сотрудник университета говорю, что такого рода научная работа не представляется мне особенно интересной. Если кто-то готов тратить на это свою жизнь и способен выбить грант на подобные исследования — да что мне, жалко что ли.
что такого рода научная работа не представляется мне особенно интересной.
А она и будет составлять 1% от того, что делается в нормальном университете — но она должна выполняться, иначе там так и будут преподавать Паскаль вместе с программированием для ЕС ЭВМ на перфолентах.
Не, я ж говорю, я не против. Просто объясняю вам логику любого нормального человека из университета: исследования должны привлекать гранты, людей, постдоков и цитаты. Если кому-то удастся под такое выбить финансирование и привлечь сотрудничество — так первый пожму ему руку и пожелаю удачи. Но шансы на это мне не кажутся очень высокими.
Вот вы ёрничаете, а в мире программистов для мейнфреймов(ЕС-ЭВМ, по вашему) не хватает. ;-)
ЕС-ЭВМ, по вашему
Я как раз хорошо отличаю, где ЕС ЭВМ, а где современный zSeries.
программистов не хватает. ;-)
Платить не пробовали, простите за резкость?
За деньги даже на RPG будут писать без особого плача.
Так платят… Но все умчались в стильно-модно-молодёжно, аджайл-кубернетис-девопс и прочие смузи. А серьёзные машины это типа кровавое легаси. О них на модных митапах, видимо, как-то стыдновато рассказывать.
Так платят… Но все умчались в стильно-модно-молодёжно, аджайл-кубернетис-девопс и прочие смузи. А серьёзные машины это типа кровавое легаси
Это точно. Платят. Не золотые горы, но вполне себе «по рынку».
Но тут нет модных фреймворков — нужно активно работать головой и руками.
И может придти вот такое:
Из PEX статистики работы XXXXXXXXX видно, что 33% времени и 36% ресурсов CPU тратится на выполнение QSQRPARS в программе YYYYYYYYY, т.е. парсинг статических выражений при подготовке SQL запроса.
Сократить данные ресурсозатраты практически до нуля можно путем описания параметров sql запросов через SQL Descriptor Area (SQLDA).
Поскольку NNNNNN один из наиболее активно используемых сервис модулей, необоснованное повышенное ресурсопотребление является малодопустимым. Просьба инициировать доработку YYYYYYYYY.
Причем, «описание параметров sql запросов через SQL Descriptor Area» в данном случае невозможно, поскольку запрос содержит конструкцию WHERE FIELD IN (VALUES LIST), где VALUES LIST генерируется «на лету» при каждом вызове программы. А такая вещь не параметризируется.
И вот конструкции типа
SELECT DISTINCT ELWWRD FROM ELWPF
LEFT JOIN EWFPF ON ELWWID=EWFID
WHERE EWFEWF IN (...) AND EWFTES='N'и
SELECT ELWEID, ELWSPE FROM ELWPF
WHERE ELWWRD IN (...) and ELWTES='N'
GROUP BY ELWEID, ELWSPE
HAVING COUNT(*)=MAX(ELWCNT)приходится переводить на «нативный» RPG (с чтением записей из файла по ключу типа
chain (curWrd: 'N') ELW30LF;
А все distict, group by, having count эмулировать вспомогательными средствами (в моем случае хорошо сработали сортированный список уникальных значений и список на основе SkipList для пар ключ-данные).
В результате все работает чуть быстрее и нагрузка упала:
Тестирование проведено в копии пром среды, запуск СМ осуществлен 34648 раз.
Среднее время получения ответа, при запуске СМ:
Текущая версия функционала (копия в пром среды от 25.01.2020) — 7.98 м. сек
Обновленная версия, СМ — 6.71 м. сек
Рессурсовзатратность QSQRPARS уменьшилась до незначительных показателей.
О них на модных митапах, видимо, как-то стыдновато рассказывать
Ну у нас свой митап есть :-) Начиналось с вутреннего «слета разработчиков EQ», с прошлого года выросло до IBM i DevConf
НЛО прилетело и опубликовало эту надпись здесь
А что есть опыт который трансформируется? Умение работать с каким-то фреймворком? Вот это точно не трансформируешь т.к. в другом месте будет другой фреймворк.
Трансформируется опыт разработки, не кодирования, а именно разработки. Умение правильно выбрать архитектуру, умение эффективно использовать ресурсы…
Из личных устриц. Был опыт разработки гетерогенных распределенных многопроцессных систем с гарантированным временем отклика. Это область близкая к промышленной автоматизации. А потом ушел в банк. Во-первых, опыт (на уровне интуиции) нахождения эффективных решений весьма пригодился — здесь чато приходится решать задачи на оптимизацию старых модулей к которым есть вопросы со стороны сопровождения в плане потребления ресурсов. Во-вторых, как-то попалась задачка где надо было с сжатое время обработать несоколько десятков миллионов объектов. Вот там очень помог опыт разработки мультипоточных и мультипроцессных систем с организацией обмена данных между потоками/процессами (в том числе опыт распараллеливания обработки данных в batch машинах).
Даже опыт работы с конечными автоматами и то пригождается иногда. Просто видишь задачу и сразу понимаешь что вот тут можно это использовать, там то…
И от языка и платформы это не зависит от слова совсем никак. Это общие, как ныне модно выражаться, паттерны. Которые ты или знаешь как использовать, или вообще при них ничего не слышал.
В общем, опыт — это не знание конкретного языка/фреймворка/платформы — это как раз нарабатывается быстро (я за полтора месяца вышел на уровень решения несложных боевых задач на IBM i на RPG хотя до того всю жизнь писан на С.С++ под винду, а придумать более разные платформы сложно).
Опыт — это прежде всего понимание даже не как надо, а как не надо решать ту или иную задачу. Общие подходы, которые формируются в голове еще до того, как напишете первую строчку кода.
Трансформируется опыт разработки, не кодирования, а именно разработки. Умение правильно выбрать архитектуру, умение эффективно использовать ресурсы…
Из личных устриц. Был опыт разработки гетерогенных распределенных многопроцессных систем с гарантированным временем отклика. Это область близкая к промышленной автоматизации. А потом ушел в банк. Во-первых, опыт (на уровне интуиции) нахождения эффективных решений весьма пригодился — здесь чато приходится решать задачи на оптимизацию старых модулей к которым есть вопросы со стороны сопровождения в плане потребления ресурсов. Во-вторых, как-то попалась задачка где надо было с сжатое время обработать несоколько десятков миллионов объектов. Вот там очень помог опыт разработки мультипоточных и мультипроцессных систем с организацией обмена данных между потоками/процессами (в том числе опыт распараллеливания обработки данных в batch машинах).
Даже опыт работы с конечными автоматами и то пригождается иногда. Просто видишь задачу и сразу понимаешь что вот тут можно это использовать, там то…
И от языка и платформы это не зависит от слова совсем никак. Это общие, как ныне модно выражаться, паттерны. Которые ты или знаешь как использовать, или вообще при них ничего не слышал.
В общем, опыт — это не знание конкретного языка/фреймворка/платформы — это как раз нарабатывается быстро (я за полтора месяца вышел на уровень решения несложных боевых задач на IBM i на RPG хотя до того всю жизнь писан на С.С++ под винду, а придумать более разные платформы сложно).
Опыт — это прежде всего понимание даже не как надо, а как не надо решать ту или иную задачу. Общие подходы, которые формируются в голове еще до того, как напишете первую строчку кода.
НЛО прилетело и опубликовало эту надпись здесь
За 30 лет в разработке не пользовался ничем из того, что Вы упомянули. И как-то жив до сих пор :-)
Если ко мне на собеседование придет человек и начнет рассказывать как он круто знает буст, я найду что у него спросить :-) Безотносительно буста или какого-то конкретного языка или фреймворка.
Например попрошу набросать план для распараллеливания обработки 50млн объектов, каждый из которых тянет за собой еще десяток связанных объектов. Ну такие простенькие вопросы — как равномерно распределить нагрузку по обработчикам, как организовать обмен данными между процессами и т.п.
Мне не интересует из каких кирпичиков человека научили лепить результат — на барабане можно и зайца научить играть. Меня интересует умеет ли он думать головой и понимает ли какие грабли разложены в той же параллельной обработке данных.
Или еще можно попросить набросать архитектуру распределенной гетерогенной системы. С минимальными задержками в передаче информации с одного края на другой и обратно и гарантией сохранности этой информации и гарантией ее получения на другом конце.
Есть и еще более забавные задачки. Недавно вот на комбинаторику была — в записи 10 полей. Нужно составить все возможные их комбинации. Товарищ очень изящно ее решил.
Или вот такое — 15 программ. Первой может быть запущена любая из них (с передачей некоторого набора параметров). Из нее может вызываться также любая из оставшихся. Как это реализовать чтобы избежать ситуации когда
PgmA -> PgmB -> PgmC -> PgmA
т.е. не должно быть дублирования программы в коллстеке.
Вопросы из жизни все. Есть и еще. И много. Могу задачник уже делать.
Если ко мне на собеседование придет человек и начнет рассказывать как он круто знает буст, я найду что у него спросить :-) Безотносительно буста или какого-то конкретного языка или фреймворка.
Например попрошу набросать план для распараллеливания обработки 50млн объектов, каждый из которых тянет за собой еще десяток связанных объектов. Ну такие простенькие вопросы — как равномерно распределить нагрузку по обработчикам, как организовать обмен данными между процессами и т.п.
Мне не интересует из каких кирпичиков человека научили лепить результат — на барабане можно и зайца научить играть. Меня интересует умеет ли он думать головой и понимает ли какие грабли разложены в той же параллельной обработке данных.
Или еще можно попросить набросать архитектуру распределенной гетерогенной системы. С минимальными задержками в передаче информации с одного края на другой и обратно и гарантией сохранности этой информации и гарантией ее получения на другом конце.
Есть и еще более забавные задачки. Недавно вот на комбинаторику была — в записи 10 полей. Нужно составить все возможные их комбинации. Товарищ очень изящно ее решил.
Или вот такое — 15 программ. Первой может быть запущена любая из них (с передачей некоторого набора параметров). Из нее может вызываться также любая из оставшихся. Как это реализовать чтобы избежать ситуации когда
PgmA -> PgmB -> PgmC -> PgmA
т.е. не должно быть дублирования программы в коллстеке.
Вопросы из жизни все. Есть и еще. И много. Могу задачник уже делать.
Есть и еще более забавные задачки. Недавно вот на комбинаторику была — в записи 10 полей. Нужно составить все возможные их комбинации. Товарищ очень изящно ее решил.Такие вопросы программисту я бы даже постыдился задавать.
Или вот такое — 15 программ. Первой может быть запущена любая из них (с передачей некоторого набора параметров). Из нее может вызываться также любая из оставшихся. Как это реализовать чтобы избежать ситуации когда
Это вопросы не из серии сможет-не сможет, а о том, как он это сможет. Если вы видите решение задачи на комбинаторику в 10-ти вложенных циклах — это не наш вариант.
Мне теперь стало интересно, у вас есть какой-то принципиально другой способ решать задачи на комбинаторику, не используя циклы?
Или вам просто конструкция цикла не нравится и вы ожидаете чего-то вроде итераторов или джойнов?
Может рекурсия какая хитрая нужна, или динамическое программирование. Но там в общем то тоже не вижу способов циклов избежать.
НЛО прилетело и опубликовало эту надпись здесь
Ну совсем без циклов никак.
Но там есть внешний цикл по количеству полей, для которых нужно собрать возможные комбинации.
Ну предположим, есть поля A, B, C, D, E, F.
Один раз мы вызываем функцию с набором из всех пяти полей, в другой раз из трех — A, C, E
Это количество полей будет определять внешний цикл.
Будет еще внутренний цикл, он определяется количеством записей в таблице.
Ну и еще один цикл, его параметр будет переменным, это количество уже собранных наборов.
Все. Три цикла для любого количества полей. хоть 3 поля, хоть 30.
Но там есть внешний цикл по количеству полей, для которых нужно собрать возможные комбинации.
Ну предположим, есть поля A, B, C, D, E, F.
Один раз мы вызываем функцию с набором из всех пяти полей, в другой раз из трех — A, C, E
Это количество полей будет определять внешний цикл.
Будет еще внутренний цикл, он определяется количеством записей в таблице.
Ну и еще один цикл, его параметр будет переменным, это количество уже собранных наборов.
Все. Три цикла для любого количества полей. хоть 3 поля, хоть 30.
Будет еще внутренний цикл, он определяется количеством записей в таблице.
В какой таблице?
Ну и еще один цикл, его параметр будет переменным, это количество уже собранных наборов.
Зачем нам цикл по уже собранным наборам?
Покажите код, пожалуйста, действительно интересно. Из словесного описания пока что не складывается в чем смысл решения.
Строго говоря, это была полуучебная, полубоевая задача.
Был человек в статусе стажера (это 20 часов в неделю, фактически полставки). Пришел к нас совсем нулевой, без никакого опыта (сейчас уже крепкий миддл, достаточно способный парень).
Ну и дали ему задачку. Есть таблица в которой N полей и M записей. Коллеге потребовалось (не помню уже зачем, вроде бы что-то с тестами связанное) список строк, в которых были бы все возможные комбинации полей типа такого:
Поле1.Запись1 Поле2.Запись1 Поле3.Запись1…
Поле1.Запись1 Поле2.Запись1 Поле3.Запись2…
…
Поле1.Запись1 Поле2.Запись1 Поле3.ЗаписьM…
…
Поле1.Запись1 Поле2.Запись2 Поле3.Запись1…
Поле1.Запись1 Поле2.Запись2 Поле3.Запись2…
…
Поле1.Запись1 Поле2.Запись2 Поле3.ЗаписьM…
…
Поле1.ЗаписьM Поле2.ЗаписьM Поле3.ЗаписьM…
ну и так далее…
Количество полей и записей… ну пусть будет 5 полей и 20 записей…
Код приводить не стану — под рукой нет, да и мало чего скажет — RPGLE на IBM i
Но суть была такая (примерно). Товарищ взял две штуки DataQueue (очередь данных, есть такой системный объект на IBM i). Сначала заполнил первуою очередь всеми возможными значениями Поле1.
А потом цикл по оставшимся полям — берем элемент из очереди 1 и приписываем к нему все возможные значения (по количеству записей) очередного поля (со второго и далее). Полученные N-1 элементов записываем в очередь 2.
Когда очередь 1 становится пустой, меняем местами очереди (та, что была 2, стала 1 и наоборот) и переходим к следующему полю.
На выходе получаем очередь, где содержатся искомые строки.
В итоге — один начальный цикл инициализации очереди по количеству записей 1..M
Затем внешний цикл по количеству полей 2..N и две внутренних — по текущему количеству элементов во входной (а данном этапе) очереди и по количеству записей 1..M
Плюсом — функция параметризуется — на вход можно подавать набор полей по которым нужно строить комбинации. Сам алгоритм не завязан ни на количество полей, ни на количество записей.
Был человек в статусе стажера (это 20 часов в неделю, фактически полставки). Пришел к нас совсем нулевой, без никакого опыта (сейчас уже крепкий миддл, достаточно способный парень).
Ну и дали ему задачку. Есть таблица в которой N полей и M записей. Коллеге потребовалось (не помню уже зачем, вроде бы что-то с тестами связанное) список строк, в которых были бы все возможные комбинации полей типа такого:
Поле1.Запись1 Поле2.Запись1 Поле3.Запись1…
Поле1.Запись1 Поле2.Запись1 Поле3.Запись2…
…
Поле1.Запись1 Поле2.Запись1 Поле3.ЗаписьM…
…
Поле1.Запись1 Поле2.Запись2 Поле3.Запись1…
Поле1.Запись1 Поле2.Запись2 Поле3.Запись2…
…
Поле1.Запись1 Поле2.Запись2 Поле3.ЗаписьM…
…
Поле1.ЗаписьM Поле2.ЗаписьM Поле3.ЗаписьM…
ну и так далее…
Количество полей и записей… ну пусть будет 5 полей и 20 записей…
Код приводить не стану — под рукой нет, да и мало чего скажет — RPGLE на IBM i
Но суть была такая (примерно). Товарищ взял две штуки DataQueue (очередь данных, есть такой системный объект на IBM i). Сначала заполнил первуою очередь всеми возможными значениями Поле1.
А потом цикл по оставшимся полям — берем элемент из очереди 1 и приписываем к нему все возможные значения (по количеству записей) очередного поля (со второго и далее). Полученные N-1 элементов записываем в очередь 2.
Когда очередь 1 становится пустой, меняем местами очереди (та, что была 2, стала 1 и наоборот) и переходим к следующему полю.
На выходе получаем очередь, где содержатся искомые строки.
В итоге — один начальный цикл инициализации очереди по количеству записей 1..M
Затем внешний цикл по количеству полей 2..N и две внутренних — по текущему количеству элементов во входной (а данном этапе) очереди и по количеству записей 1..M
Плюсом — функция параметризуется — на вход можно подавать набор полей по которым нужно строить комбинации. Сам алгоритм не завязан ни на количество полей, ни на количество записей.
В итоге это взрывается по памяти. Такое делать не лениво это потенциальная бомба.
В наших условиях не взрывается :-)
У нас 1.8Тб только оперативки. А так — одноуровневая память с 64-разрядной адресацией. И 16Гб на задание (JOB)
Любая задача решается в контексте платформы на которой она решается. В нашем случае портабельность не нужна.
Кроме того, *DTAQ — это персистентный объект, хранящийся на диске. Так что в памяти там фактически только строка с которой в данный момент работаем.
У нас 1.8Тб только оперативки. А так — одноуровневая память с 64-разрядной адресацией. И 16Гб на задание (JOB)
Любая задача решается в контексте платформы на которой она решается. В нашем случае портабельность не нужна.
Кроме того, *DTAQ — это персистентный объект, хранящийся на диске. Так что в памяти там фактически только строка с которой в данный момент работаем.
n^m беспощаден. Его железом не залить.
Гигабайт от терабайта результата отличается во входных данных совсем чуть-чуть. Буквально на еденичку.
И самое главное зачем? Это за час в режиме собеседования пишется нормально. Типовой вопрос же. В прод пусть день займет. Чтобы красиво и падения переживало.
Гигабайт от терабайта результата отличается во входных данных совсем чуть-чуть. Буквально на еденичку.
И самое главное зачем? Это за час в режиме собеседования пишется нормально. Типовой вопрос же. В прод пусть день займет. Чтобы красиво и падения переживало.
Ммм. Персистентные объекты. Я когда у Солтиса об этом впервые прочитал, это для меня было откровением прям. Учитывая то, что ФС в АС-ках нет(точнее скорее всего может и не быть).
НЛО прилетело и опубликовало эту надпись здесь
Что значит набросать план? Шедулер написать? Или какие-то примитивы для параллелизма даны, и надо в рамках них это сделать?
Ну и там ещё миллион вопросов последует.
Да ладно вам. Когда собеседующий хочет 50 абстрактных миллионов без привязки ко времени о шедулере даже речи не идет. От вас явно хотят типичных баззвордов.
А за самое рабочее решение «положить эти 50 миллионов в очередь, читать оттуда нужными пачками и обрабатывать нужным количеством воркеров» на работу точно не возьмут. Хотя в проде именно такое решение и будет.
Возможно возьмут. Потому что построение батчмашины в данном случае вполне рабочий вариант.
Но дьявол в деталях. Что будет с пакетом, если воркер упал во время обработки? Кто должен фиксировать результат обработки так, чтобы нагрузка распределялась равномерно? Что будет, если заданно максимальное время и оно вышло, а обработка не завершена (такое допустимо например, когда задача одноразовая, ее можно выполнить не за один проход, но на ее выполнение можно выделить, скажем, полчаса в сутки в определенный период минимальной загрузки системы).
Если у человека есть или минимальный опыт, или просто умение просчитывать варианты, он такие вещи сразу держит в голове. И на любом этапе задается вопросом — «а что будет если...»
Плывут на таких вопросах те, кто привык пользоваться разными фреймворками и считать что фреймоворк отработает всегда на 100% надежно и корректно. А случись чего — «ну, это где-то там проблема...»
А у нас проблема всегда «здесь». И ее всегда надо обработать так, чтобы во-первых, зафиксировать что она была, во-вторых, сохранить целостность данных (в худшем случае — откатиться к стабильному состоянию на начало процесса.
В нашем случае пренебрежение этими правилами может привести к весьма печальным последствиям. Как вам непрохождение платежей по пластиковым картам банка в течении нескольких часов в масштабах страны?
Или сломалась проверка по спискам комплаенса, прошел платеж в сторону сомнительного корреспондента и регулятор выкатил штраф со многими нулями?
Такие вещи на фреймворк не спишешь. Это вам не сайт с котиками.
В принципе, у нас нет «неправильных ответов». Это все скорее чтобы понимать уровень кандидата и чему его учить, а что он и сам уже понимает.
Но дьявол в деталях. Что будет с пакетом, если воркер упал во время обработки? Кто должен фиксировать результат обработки так, чтобы нагрузка распределялась равномерно? Что будет, если заданно максимальное время и оно вышло, а обработка не завершена (такое допустимо например, когда задача одноразовая, ее можно выполнить не за один проход, но на ее выполнение можно выделить, скажем, полчаса в сутки в определенный период минимальной загрузки системы).
Если у человека есть или минимальный опыт, или просто умение просчитывать варианты, он такие вещи сразу держит в голове. И на любом этапе задается вопросом — «а что будет если...»
Плывут на таких вопросах те, кто привык пользоваться разными фреймворками и считать что фреймоворк отработает всегда на 100% надежно и корректно. А случись чего — «ну, это где-то там проблема...»
А у нас проблема всегда «здесь». И ее всегда надо обработать так, чтобы во-первых, зафиксировать что она была, во-вторых, сохранить целостность данных (в худшем случае — откатиться к стабильному состоянию на начало процесса.
В нашем случае пренебрежение этими правилами может привести к весьма печальным последствиям. Как вам непрохождение платежей по пластиковым картам банка в течении нескольких часов в масштабах страны?
Или сломалась проверка по спискам комплаенса, прошел платеж в сторону сомнительного корреспондента и регулятор выкатил штраф со многими нулями?
Такие вещи на фреймворк не спишешь. Это вам не сайт с котиками.
В принципе, у нас нет «неправильных ответов». Это все скорее чтобы понимать уровень кандидата и чему его учить, а что он и сам уже понимает.
Но дьявол в деталях. Что будет с пакетом, если воркер упал во время обработки? Кто должен фиксировать результат обработки так, чтобы нагрузка распределялась равномерно?
Очереди это все сами делают. Упал ну и ладно. Значит комита не было, следующий воркер задачу возьмет. Все само из коробки.
Что будет, если заданно максимальное время и оно вышло, а обработка не завершена (такое допустимо например, когда задача одноразовая, ее можно выполнить не за один проход, но на ее выполнение можно выделить, скажем, полчаса в сутки в определенный период минимальной загрузки системы).
Если задача бьется на несколько ну сделайте несколько очердей и перекладывайте по ним. Сделали свой кусочек работы — положили в следующую очередь. Следующий воркер сам возьмет и сделает свою часть работы.
Надо строго убивать по времени? Крон в помощь. Можно весь контейнер с воркером убивать.
Не надо ничего фиксировать или откатываться. Надо писать идемпотентный код. Особенно в случае сложного многоуровнего процессинга. Все падает иногда. В случайных и непредсказуемых местах.
На внешний код закладываться приходится. Раз начали про очереди, то закладываемся что они работают корректно. Считаем что данные из очереди берутся правильно, коммиты работают правильно, данные в очереди не теряются. Мы эту часть не контролируем. Писать самим дорого, и не факт что выйдет надежнее типового решения. Точнее даже факт что выйдет хуже.
Факапы у всех бывают. Ну упали, бывает. Быстро поднимаемся и работаем дальше. Принимаем меры чтобы по этой же причине больше не падать. Следующий раз из-за другой причины упадем.
Все иногда падают. Считаем стоимость даунтайма и принимаем соразмерные меры защиты. Карты с платежами у банков вполне себе ломаются временами. Да и наркобароны платежи свои проводят как-то. Все как у всех.
Вы сейчас про какие очереди говорили?
MessageQueue (MQ)? DataQueue (*DTAQ)? UserQueue (*USRQ)? Их тут всех есть. Они все разные и работают по-разному. В том числе и по эффективности и скорости.
Транзакции здесь работают на уровне задания. Так что два обработчика в разных заданиях не смогут работать в общей транзакции. Возможно, есть механизм общих транзакций, но мы им не пользуемся т.к. даже оычных стараемся избегать в силу того, что commitment control ощутимо нагружает систему (Вы не поверите, сколько ограничений перечислено в «нефункциональных требованиях к разработке» и насколько сложна система, которая способна на 90 и более процентов загрузить кластер из трех серверов на каждом из которых по 16 12-ядерных SMT8 процессоров и 2.5Тб оперативки).
Не поверите, но как-то пришлось переписывать вот такой запрос:
просто потому что список значений в IN(...) при каждом вызове функции был новым. А функция очень часто вызывается из самых разных мест. В результате:
Выкрутится удалось только полностью избавившись от SQL в этом месте (тоже особенность AS-ки — тут есть альтернативный способ доступа к файлам данных).
Так что тут все очень непросто. И многие решения, которые на других системах прокатят, тут не годятся.
MessageQueue (MQ)? DataQueue (*DTAQ)? UserQueue (*USRQ)? Их тут всех есть. Они все разные и работают по-разному. В том числе и по эффективности и скорости.
Транзакции здесь работают на уровне задания. Так что два обработчика в разных заданиях не смогут работать в общей транзакции. Возможно, есть механизм общих транзакций, но мы им не пользуемся т.к. даже оычных стараемся избегать в силу того, что commitment control ощутимо нагружает систему (Вы не поверите, сколько ограничений перечислено в «нефункциональных требованиях к разработке» и насколько сложна система, которая способна на 90 и более процентов загрузить кластер из трех серверов на каждом из которых по 16 12-ядерных SMT8 процессоров и 2.5Тб оперативки).
Не поверите, но как-то пришлось переписывать вот такой запрос:
SELECT DISTINCT ELWWRD FROM ELWPF
LEFT JOIN EWFPF ON ELWWID=EWFID
WHERE EWFEWF IN (....) AND EWFTES='N'просто потому что список значений в IN(...) при каждом вызове функции был новым. А функция очень часто вызывается из самых разных мест. В результате:
Из PEX статистики работы XXXXXXXX видно, что 33% времени и 36% ресурсов CPU тратится на выполнение QSQRPARS в программе YYYYYY, т.е. парсинг статических выражений при подготовке SQL запроса,
Поскольку MMMMM один из наиболее активно используемых сервис модулей, необоснованное повышенное ресурсопотребление является малодопустимым. Просьба инициировать доработку YYYYYY.
Выкрутится удалось только полностью избавившись от SQL в этом месте (тоже особенность AS-ки — тут есть альтернативный способ доступа к файлам данных).
Так что тут все очень непросто. И многие решения, которые на других системах прокатят, тут не годятся.
Вы сейчас про какие очереди говорили?
MessageQueue (MQ)? DataQueue (*DTAQ)? UserQueue (*USRQ)? Их тут всех есть. Они все разные и работают по-разному. В том числе и по эффективности и скорости.
Допустим Kafka. Лицензия хорошая. Опенсорс. Работает под любой разумной операционкой.
Я верю в особенности архитектур. Бывает разное.
Но если ваша архитектура мешает работать, то пора от нее избавляться. Не знаю насколько именно ваша мешает, не работал с ней. На типовых это все решенные задачи. Делать не надо прямо ничего. Все само из коробки работает.
У нашей архитектуры есть минусы. Но плюсов намного больше.
И особенности прежде всего в том, что есть два основных требования — производительность и надежность. Это на уровне паранойи, впрочем, вполне обоснованной. 3млрд изменений в БД в сутки (а обращений к БД на порядок больше, я думаю, если не на порядки) — это не кот наплакал. Огромное количество таблиц и огромное количество одновременно работающих с этими таблицами процессов.
Так что любое решение рассматривается прежде всего с точки производительности и надежности. Я уже приводил пример оптимизаций, которыми мы (в числе многих прочих задач) занимаемся.
У нас есть свои очереди. Основная — IBM MQ — про нее тут как-то давно писали уже
Также, есть персистентные системные объекты *DTAQ и *USRQ — очереди, реализованные на уровне самой операционки.
Есть UnixSockets — не является персистентным, но работает быстрее и не имеет некоторых ограничений очередей (впрочем, и некоторых их возможностей — он всегда FIFO, в отличии от *DTAQ и *USRQ которые могут быть FIFO, LIFO и KEYED).
Любое решение, которое мы привносим в систему, должно быть всесторонне протестировано — кмопонентный тест, бизнестест, интерационный тест и нагрузочный тест. Только после успешного прохождения тестов оно может быть внедрено на пром.
Заменить что-то на проме — огромные затраты. Про всю систему целиком уже не говорю.
Был пример — некий австралийский банк решил заменить весь легаси код, написанный на коболе. Обошлось им это в сумму с шестью нулями и несколько лет работы.
И особенности прежде всего в том, что есть два основных требования — производительность и надежность. Это на уровне паранойи, впрочем, вполне обоснованной. 3млрд изменений в БД в сутки (а обращений к БД на порядок больше, я думаю, если не на порядки) — это не кот наплакал. Огромное количество таблиц и огромное количество одновременно работающих с этими таблицами процессов.
Так что любое решение рассматривается прежде всего с точки производительности и надежности. Я уже приводил пример оптимизаций, которыми мы (в числе многих прочих задач) занимаемся.
У нас есть свои очереди. Основная — IBM MQ — про нее тут как-то давно писали уже
Также, есть персистентные системные объекты *DTAQ и *USRQ — очереди, реализованные на уровне самой операционки.
Есть UnixSockets — не является персистентным, но работает быстрее и не имеет некоторых ограничений очередей (впрочем, и некоторых их возможностей — он всегда FIFO, в отличии от *DTAQ и *USRQ которые могут быть FIFO, LIFO и KEYED).
Любое решение, которое мы привносим в систему, должно быть всесторонне протестировано — кмопонентный тест, бизнестест, интерационный тест и нагрузочный тест. Только после успешного прохождения тестов оно может быть внедрено на пром.
Заменить что-то на проме — огромные затраты. Про всю систему целиком уже не говорю.
Был пример — некий австралийский банк решил заменить весь легаси код, написанный на коболе. Обошлось им это в сумму с шестью нулями и несколько лет работы.
Вы работаете с полностью несовместимым с мейнстримом стеком технологий. Я думал что ВебСфера это что-то из времен нулевых, успешно уже закопанное. Ан нет, оказывается работает еще. И даже развивают.
Ваши решения и даже ваши задачи оказываются абсолютно другими чем все привыкли. В обычном мире разработки всего этого нет, зато есть все другое. Подозреваю что с совместимостью у вас тоже не очень.
Условно я со знаниями Кафки не смогу спроектировать систему под ваши задачи на ваших технологиях. А вы со знаниями своих технологий не сможете сделать такую же систему на типовых решениях.
Лучше сейчас чем еще через 5 лет. Все равно придется же. Нанимать на Кобол уже сейчас нереально сложно должно быть. Да траты, но куда деваться?
Тут лучший пример это наши банки. Без тонн легаси на Коболе. Тинек, Альфа и далее по списку. Они уже на голову выше всех типовых иностранных банков. По качеству софта и обслуживания клиентов.
Судя по их рассказам они все делают на типовых технологиях. И это хорошо работает.
Ваши решения и даже ваши задачи оказываются абсолютно другими чем все привыкли. В обычном мире разработки всего этого нет, зато есть все другое. Подозреваю что с совместимостью у вас тоже не очень.
Условно я со знаниями Кафки не смогу спроектировать систему под ваши задачи на ваших технологиях. А вы со знаниями своих технологий не сможете сделать такую же систему на типовых решениях.
Был пример — некий австралийский банк решил заменить весь легаси код, написанный на коболе. Обошлось им это в сумму с шестью нулями и несколько лет работы.
Лучше сейчас чем еще через 5 лет. Все равно придется же. Нанимать на Кобол уже сейчас нереально сложно должно быть. Да траты, но куда деваться?
Тут лучший пример это наши банки. Без тонн легаси на Коболе. Тинек, Альфа и далее по списку. Они уже на голову выше всех типовых иностранных банков. По качеству софта и обслуживания клиентов.
Судя по их рассказам они все делают на типовых технологиях. И это хорошо работает.
Вы работаете с полностью несовместимым с мейнстримом стеком технологий.
А что есть мейнстрим? Вебразработка? Мобильная?
А какой стек используется в промавтоматизации? В телекоммуникациях?
Ваши решения и даже ваши задачи оказываются абсолютно другими чем все привыкли. В обычном мире разработки всего этого нет, зато есть все другое. Подозреваю что с совместимостью у вас тоже не очень.
Совсем не очень. В силу того, что мы работаем на платформе, которая очень мало где используется в РФ.
Тут лучший пример это наши банки. Без тонн легаси на Коболе. Тинек, Альфа и далее по списку. Они уже на голову выше всех типовых иностранных банков. По качеству софта и обслуживания клиентов.
Судя по их рассказам они все делают на типовых технологиях. И это хорошо работает.
Так вот позвольте представиться — Альфа-Банк, Управление разработки центральных банковских систем, главный разработчик.
То, что делается на «типовых технологиях» — это верхушка. То, что обсепечивает внешние интерфейсы.
Но опирается все это на код, написанный на 80% на RPG (остальное — C/C++) и работающий на платформе IBM i (бывшая AS/400) на серверах PowerS.
А то, что работает на типовых технологиях общается с нами через MQ и вебсервисы (которые сами ничего не не делают а только вызывают наши внутренние процедуры, передавая им набор параметров и получая ответ). А прямого доступа к данным ни у одной внешней системы нет.
А всю работу системы в плане обработки данных обеспечиваем мы. На своих «немейнстримных технологиях».
Тут такой слоеный пирог и в каждом слое свой стек и свои требования. И свои тараканы.
некий австралийский банк решил заменить весь легаси код, написанный на коболе. Обошлось им это в сумму с шестью нулями и несколько лет работы.
Неплохой вариант для банка, как мне кажется.
Очень плохой. И очень тяжелый. Я даже не представляю себе объем работы, который нужно выполнить для перехода на полностью новую АБС.
И такой переход надо делать «на лету», без остановки работы банка. Т.е. надо подготовить полностью рабочий вариант, потом какое-то время тестировать его в условиях параллельной работы старой и новой систем и только после этого уже выводить из эксплуатации старую систему.
При этом старая должна продолжать работать до последнего.
На момент перехода штат разработчиков, аналитиков, тестировщиков, сопровождения придется увеличить в полтора-два раза. Одна команда продолжает поддерживать старую систему, вторая — делает новую.
Работая на уровне развития АБС, могу точно сказать — бросить все тут нельзя. Да, какие-то вещи можно отложить до введения новой системы. Но какие-то никак. Выявился дефект промсреды — его надо править. Вышел новый ФЗ — надо дорабатывать систему для его выполнения. Поменял кто-то из внешних систем формат данных — надо адаптироваться к новому формату. И т.д. и т.п. Все это придется делать и на старой системе и на новой.
И все это при том, что старый код работает.
Тут вообще все очень консервативно. За модой никто не гонится. Просто потому что это бессмысленно.
Ну вот предствьте — сделали вы некий сайт. Он работает. Все довольны. А через год новый движок вышел. Кинетесь вы переделывать сатрый сайт на новый движок просто потому что он более современный? Сомневаюсь. Более того, если заказчик обратится к вам с просьбой доработать новый функционал и даст на это некоторый фиксированный бюджет и сроки, вы не кинетесь переделывать сайт под новый движок, а будете дорабатывать на старом. Потому что полная переделка не впишется ни в бюджет, ни в сроки.
И такой переход надо делать «на лету», без остановки работы банка. Т.е. надо подготовить полностью рабочий вариант, потом какое-то время тестировать его в условиях параллельной работы старой и новой систем и только после этого уже выводить из эксплуатации старую систему.
При этом старая должна продолжать работать до последнего.
На момент перехода штат разработчиков, аналитиков, тестировщиков, сопровождения придется увеличить в полтора-два раза. Одна команда продолжает поддерживать старую систему, вторая — делает новую.
Работая на уровне развития АБС, могу точно сказать — бросить все тут нельзя. Да, какие-то вещи можно отложить до введения новой системы. Но какие-то никак. Выявился дефект промсреды — его надо править. Вышел новый ФЗ — надо дорабатывать систему для его выполнения. Поменял кто-то из внешних систем формат данных — надо адаптироваться к новому формату. И т.д. и т.п. Все это придется делать и на старой системе и на новой.
И все это при том, что старый код работает.
Тут вообще все очень консервативно. За модой никто не гонится. Просто потому что это бессмысленно.
Ну вот предствьте — сделали вы некий сайт. Он работает. Все довольны. А через год новый движок вышел. Кинетесь вы переделывать сатрый сайт на новый движок просто потому что он более современный? Сомневаюсь. Более того, если заказчик обратится к вам с просьбой доработать новый функционал и даст на это некоторый фиксированный бюджет и сроки, вы не кинетесь переделывать сайт под новый движок, а будете дорабатывать на старом. Потому что полная переделка не впишется ни в бюджет, ни в сроки.
Этот процесс представляет определённые сложности, но чем позже это делать — тем сложнее.
И системы всё-таки устаревают.
На новое железо не хотят вставать старые операционки.
Новых операционках не хочет работать старый софт.
И с каждым поколением — всё дальше и больше.
Рано или поздно — переписывать придётся.
И вот тут следует найти баланс:
— чтобы действительно не делать работу впустую, не менять систему, которая ещё вполне себе может работать и может даже не до конца отбила деньги вложенные в неё, и в то же время
— чтобы не затягивать эксплуатацию морально и технически устаревшей системы, её переписывание вылилось в разумные сроки и суммы.
И системы всё-таки устаревают.
На новое железо не хотят вставать старые операционки.
Новых операционках не хочет работать старый софт.
И с каждым поколением — всё дальше и больше.
Рано или поздно — переписывать придётся.
И вот тут следует найти баланс:
— чтобы действительно не делать работу впустую, не менять систему, которая ещё вполне себе может работать и может даже не до конца отбила деньги вложенные в неё, и в то же время
— чтобы не затягивать эксплуатацию морально и технически устаревшей системы, её переписывание вылилось в разумные сроки и суммы.
Вы не учитываете реалии банковской сферы.
Там все, во-первых, мегаконсервативно, во-вторых, используются платформы, несколько отличающиеся от десктопных и даже инетсерверов.
Вот, к примеру мы работает на платформе, которая была создана в 88-м году — AS/400 от IBM. Сейчас эта платформа называется IBM i и продолжает поддерживтаться и развиваться. Выходят новые версии ОС (год или 2 назад мы перешли с 7.2 на 7.3, перодически накатываются мелкие апгрейды, последняя версия 7.4). Выходит новое железо — не так давно мы перешли с PowerS8 (824 на тесте и 828 на проме) на PowerS9 (924 и 928 соответственно).
Но все, что было написано, скажем, в 2016-м и ранее под 828, будет точно также работать и сейчас на 928. Более того, при переносе на более современное железо программынй код «самооптимизуруется» автоматически. Как это работает — объяснять долго, лучше погуглить что такое TIMI:
Фактически, в этой системе отсутствует доступный разработчику ассемблер — он находится ниже уровня System Licensed Internal Code (SLIC), куда доступ разрешен только разработчикам системы. Выше SLIC — уровень разработчиков ПО — существуют тоьок те самые MI — машинные инструкции для работы с системными объектами.
В общем, эти системы изначально рассчитаны на очень долгий срок службы и переносимость ПО на более современные версии с использованием всех новых возможностей. И там нет такой острой необходимости переписывать все (и даже перекомпилировать все) только потому что железо устарело.
Там все, во-первых, мегаконсервативно, во-вторых, используются платформы, несколько отличающиеся от десктопных и даже инетсерверов.
Вот, к примеру мы работает на платформе, которая была создана в 88-м году — AS/400 от IBM. Сейчас эта платформа называется IBM i и продолжает поддерживтаться и развиваться. Выходят новые версии ОС (год или 2 назад мы перешли с 7.2 на 7.3, перодически накатываются мелкие апгрейды, последняя версия 7.4). Выходит новое железо — не так давно мы перешли с PowerS8 (824 на тесте и 828 на проме) на PowerS9 (924 и 928 соответственно).
Но все, что было написано, скажем, в 2016-м и ранее под 828, будет точно также работать и сейчас на 928. Более того, при переносе на более современное железо программынй код «самооптимизуруется» автоматически. Как это работает — объяснять долго, лучше погуглить что такое TIMI:
Одной из особенностей платформы IBM System i является использование высокоуровневой системы команд TIMI («Technology Independent Machine Interface», рус. Машинный интерфейс, независимый от технологии[3]), которая позволяет программам быть переносимыми и при этом получать пользу от более современного аппаратного и программного обеспечения без перекомпиляции.
TIMI является виртуальной системой команд, не зависящей от реальной системы команд центрального процессора. Приложения, работающие в режиме пользователя, могут содержать одновременно машинные коды TIMI и машинные коды конкретного процессора. Концептуально система сходна с архитектурой виртуальных машин, таких как Smalltalk, Java, .NET. Основное отличие от них — глубокая интеграция TIMI в архитектуру AS/400, таким образом, что приложения являются переносимыми между системами System i с различными микропроцессорами.
Особо надо отметить, что в отличие от других виртуальных машин, которые интерпретируют виртуальные инструкции при запуске ПО, инструкции TIMI не интерпретируются. При компиляции ПО, в объектном файле сохраняется как машинный код конкретного процессора, так и TIMI-код. Если приложение, скомпилированное для оригинальных 48-битных процессоров CISC AS/400, будет запущенно на системе с более новым RISC-процессором, например, 64-битном PowerPC, то операционная система проигнорирует машинный код старого процессора и оттранслирует[3] TIMI-код в инструкции нового процессора перед запуском.
Фактически, в этой системе отсутствует доступный разработчику ассемблер — он находится ниже уровня System Licensed Internal Code (SLIC), куда доступ разрешен только разработчикам системы. Выше SLIC — уровень разработчиков ПО — существуют тоьок те самые MI — машинные инструкции для работы с системными объектами.
В общем, эти системы изначально рассчитаны на очень долгий срок службы и переносимость ПО на более современные версии с использованием всех новых возможностей. И там нет такой острой необходимости переписывать все (и даже перекомпилировать все) только потому что железо устарело.
Это просто меняет временнЫе масштабы, но не отменяет самой задачи по обновлению IT-систем.
Временные масштабы меняются радикально.
То, что написано под AS/400 в 1990-м, может быть перенесено и будет эффективно работать на IBM i в 2020-м. На совершенно других процессорах. Это не бытовуха типа маков, где с x86 на ARM перешли и привет — весь софт под переписку.
Тут время жизни софта исчисляется десятилетиями. И вкладываться в его переделку пока совсем не прижмет, только ради «модного стека» никто не будет — это неэффективные затраты.
Тут на любое телодвижение первый вопрос — «а сколько мы на этом заработаем?»
То, что написано под AS/400 в 1990-м, может быть перенесено и будет эффективно работать на IBM i в 2020-м. На совершенно других процессорах. Это не бытовуха типа маков, где с x86 на ARM перешли и привет — весь софт под переписку.
Тут время жизни софта исчисляется десятилетиями. И вкладываться в его переделку пока совсем не прижмет, только ради «модного стека» никто не будет — это неэффективные затраты.
Тут на любое телодвижение первый вопрос — «а сколько мы на этом заработаем?»
В таком подходе вступают в силу ограничения со стороны рынка труда: кто будет сопровождать и модернизировать софт, написанный десятилетия назад?
И это же нужен не 1-2 пенсионера, а нормальные такие IT-отделы: системы-то большие.
Типа, готовых специалистов нет — пусть, возьмём толковых, вырастим для себя сами.
А много ли захотят идти на работу в узкую, в рамках IT-технологий — нишу? Что потом делать с полученными знаниями и навыками?
И это же нужен не 1-2 пенсионера, а нормальные такие IT-отделы: системы-то большие.
Типа, готовых специалистов нет — пусть, возьмём толковых, вырастим для себя сами.
А много ли захотят идти на работу в узкую, в рамках IT-технологий — нишу? Что потом делать с полученными знаниями и навыками?
А вы думаете что всем интересны только модные стеки? :-)
Не могу сказать, чтобы у нас ощущалась острая нехватка кадров. И работают далеко не только пенсионеры, молодых достаточно много.
И ИТ служба у нас вполне себе нормальная. Я затруднюсь сказать сколько человек, но только разработчиков точно больше сотни (по трем городам — Мск, Спб и Екб). Я имею ввиду тех, кто работает именно на AS/400, есть еще кто работает с Pega, мобильная разработка, сайт…
А еще есть аналитики, сопровождение, поддержка — те, кто тоже обязаны очень хорошо понимать как работает эта система.
Тут просто определенны склад характера — глубокий бэкенд, умение писать надежный и эффективный код самому, не опираясь на фреймворки.
Такие люди, если что, легко находят себе работу в других областях — та же промавтоматизация в чем-то предъявляет схожие требования. Телекоммуникации (на нижнем уровне).
Конкретная платформа не так важна — до уровня решения несложных боевых задач человек, обладающий хоть каким-то опытом разработки, но впервые сталкивающийся с этой платформой, выходит через два-три месяца максимум. Дальше уже начинается накопление опыта и переход к более сложным задачам.
И такой человек потом за те же пару месяцев сможет перейти на любую другую платформу.
Я сам пришел три года назад. До этого писал исключительно на С/С++ под винды. Сейчас вот AS/400, RPG и местами С/С++ (там, где это удобнее и эффективнее). Благо концепция системы позволяет написать модуль на RPG, модуль на C/C++, а потом эти два модуля слепить в одну программу. И вызывать функции на С/С++ из функций на RPG и наоборот.
Не могу сказать, чтобы у нас ощущалась острая нехватка кадров. И работают далеко не только пенсионеры, молодых достаточно много.
И ИТ служба у нас вполне себе нормальная. Я затруднюсь сказать сколько человек, но только разработчиков точно больше сотни (по трем городам — Мск, Спб и Екб). Я имею ввиду тех, кто работает именно на AS/400, есть еще кто работает с Pega, мобильная разработка, сайт…
А еще есть аналитики, сопровождение, поддержка — те, кто тоже обязаны очень хорошо понимать как работает эта система.
Тут просто определенны склад характера — глубокий бэкенд, умение писать надежный и эффективный код самому, не опираясь на фреймворки.
Такие люди, если что, легко находят себе работу в других областях — та же промавтоматизация в чем-то предъявляет схожие требования. Телекоммуникации (на нижнем уровне).
Конкретная платформа не так важна — до уровня решения несложных боевых задач человек, обладающий хоть каким-то опытом разработки, но впервые сталкивающийся с этой платформой, выходит через два-три месяца максимум. Дальше уже начинается накопление опыта и переход к более сложным задачам.
И такой человек потом за те же пару месяцев сможет перейти на любую другую платформу.
Я сам пришел три года назад. До этого писал исключительно на С/С++ под винды. Сейчас вот AS/400, RPG и местами С/С++ (там, где это удобнее и эффективнее). Благо концепция системы позволяет написать модуль на RPG, модуль на C/C++, а потом эти два модуля слепить в одну программу. И вызывать функции на С/С++ из функций на RPG и наоборот.
Как у вас обстоят дела с феноменами вроде Undefined Behavior из C++?
Как выглядит версионирование софта?
Как у вас обстоят дела с феноменами вроде Undefined Behavior из C++?
Честно скажу — очень давно не сталкивался. Видимо, интуитивно стараюсь избегать неоднозначных конструкций, в которых оно обычно проявляется.
Как выглядит версионирование софта?
Имеется ввиду наш софт?
В данном случае все завязано на особенности платформы.
Начнем с того, что написание исходного кода ведется на локальной машине (ноут, десктоп...) IDE — или RDi (Rational Development for i — IBM-овская IDE для разработки под AS/400 на базе Eclipce — обвешана всякими плагинами для работы с сервером) или VSC (но тут две проблемы — заброс исходников на сервер и разработки интерфейсов (дисплейные и принтерные формы — в RDi для них есть визуальный редактор).
А чтобы собрать поставку нужно сначала забросить все исходники на сервер и там уже собирать. Сейчас стараниями наших девопсов есть gradle плагин, который все это умеет. Так что первая проблема для VSC решена — прямо в его терминале запускаешь таск гредла и вперед.
Далее — особенности хранения исходников на AS-ке — там нельзя вот так просто взять и положить исходник программы. Там есть т.н. «физический файл исходных текстов» — pf-src. Он содержит в себе набор «элементов» (member) каждый из которых уже есть исходник программы, описание таблицы, SQL скрипт и т.п.
Т.е. исходники поставки, вне зависмости от количества объектов в ней — один pf-src.
Все эти файлы хранятся в специальной библиотеке (на каждом юните своя) со стандартным именем ASRC+мнемоника юнита
Т.о. развернуть поставку на сервере — это значит создать в том юните куда она ставится в соотв. библиотеке pf-src, заполнить его набором элементов и потом оттуда собрать каждый элемент (создать соответсвующий ему объект).
Каждая поставка (патч) имеет мнемонику + трехзначный номер версии. Нумерация начинается с 100. Далее, если изменяется бизнеслогика (новая версия FSD), номер увеличивается на 10 (100, 110, 120...). Если исправление дефекта или оптимизация без изменений в логике — увеличиваем номер на 1 (111, 112...)
Есть правила именования pf-src — мнемоника поставки (линейки, задачи) + SRC + номер версии. Например, работаю с линейкой ECL (мнемоника). Первая поставка. Версия 100. Она будет именоваться у нас везде как ECL#100. На юните разработчиков (он прежде всего для проверки что поставка собирается и не падает при запуске), PGM она будет лежать в ASRCPGM/ECLSRC100
Далее. В поставке может быть много объектов (у меня сейчас их более 160-ти). Собирать каждый руками — страшное дело. Посему пишется программа-инсталятор на языке CL (это командный язык AS/400, его команды могу использоваться как в интерактиве при работе в терминале, так для написания программ на нем, более того, программа на CL компилируется командой того же CL) которая складывается в тот же pf-src под фиксированным именем CRT+мнемоника поставки+номер версии (@CRTECL100).
Теперь чтобы развернуть поставку на юните достаточно скомпилировать инсталятор и запустить его. А он уже соберет все объекты.
На самом деле инсталятор чуть сложнее — он и окружение создает для сборки и проверяет пререквизиты (мнемоники других поставок, которые должны быть установлены на юните чтобы наша заработала) и в конце, елси все хорошо, регистрируется поставку в специальной базе (по ней и проверяются пререквизиты). Туда вносится полная мнемоника поставки — ECL#100, дата и время установки, ссылки на задачу в Jira, на FSD в Confluence, на страничку проекта в Confluence. А также профайл пользователя из под которого производилась установка.
Теперь мы можем простыми SQL запросами посмотреть какие поставки у нас в конкретном юните (вплоть до прома), в каких юнитах установлена наша поставка и т.п.
Слава девопсам, сейчас даше не нужно инсталяторы писать руками — все в гредле. Просто прописываются скрипты где описываются данные для поставки и все входящие в нее объекты и соотв. таск сам сгененирет инсталятор, забросит все на сервер, скомпилирует и запустит инсталятор. Нам нужно только написать в командной строке на компе gradle as400SyncAndDeploy и ждать что из этого получится :-)
У каждого объекта в AS/400 есть такое свойство как TEXT — это строка 50 символов для краткого комментария что это такое. Мы в гредл-скриптах, когда описываем объекты поставки вносим туда краткое описание. А плагин гредловый при создании инсталятора еще к описанию каждого объекта добавит мнемонику поставки — например, ECL#100. Таким образом, мы для каждого объекта в системе можем посмотреть каким патчем он был установлен — команда WRKOBJ имя объекта
и нажимаем 8 — описание объекта
Для программных объектов еще проще — там есть команда DSPPGM
там много экранов, в том числе описание объекта
и список модулей из которых он собран
Для каждого модуля можем посмотреть информацию о нем где будет ссылка на pf-src где хранится его исходник
Т.е. всегда можно найти концы откуда что поставлено. Кем и когда.
Но ручная установка доступна только в юнит разработчиков и песочницы (копии юнитов компонентного тестирования — у каждой команды свой, служит для совместного тестирования и отладки силами аналитика и разработчика, впрочем, у нас есть аналтики, которые сами неплохо дебажат и еще ревью по коду делают). Песочница хороша тем, что может быть в любой момент пересоздана из соответсвующего юнита.
А вот в юнит компонентного тестирования поставка ставится уже через портал DevOps. Для этого нужно поставку официально оформить — коммит в гит, тег на коммит и запустить таск в Jenkins на этот тег.
Дженкинс уже вызовет гредл и тот по скриптам в поставке установит ее в юнит-хранилище поставок и создаст объект в Artifactory, добавив туда ReleaseNotes (тоже на основе информации из гредл-скриптов).
Это уже считается «оформленной поставкой» — ссылка на объект в артифактори публикуется на страничке задачи в Jira с переводом задачи из статуса Dev в статус DevDone и в Confluence дочерней страничкой к страничке с FSD.
Дальше уже все установки поставки в разные юниты идет по ссылке на артифактори. В компонентное тестирование сами ставим (разработчик или аналитик) через портал DevOps, в юниты бизнестестирования, интеграционного тестирования ставит сопровождение по заявке аналитика. При необходимости аналитик может заказать нагрузочное тестирование. Ну и установка на пром (внедрение) тоже по заявке ставит сопровождение.
Вот так, если кратенько :-)
Очень интересно, спасибо что так развернуто отвечаете.
Жаль только что это в комментариях останется, хотя уже тянет на статью.
Ну такие статьи должны писать те, кто все это разрабатывает и внедряет. Мы (разработчики) же тут просто пользователи всех этих сервисов.
Все это, кстати, развернуто за последние годы. Еще три года назад, когда я пришел, гитом так активно не ползовались, гредла не было у нас, не было артифактори, джиры… FSD хранились в базе Lotus. Альтренативы RDi для разработки не было т.к. она позволяла работать с исходниками на сервере — так и работали с тем юнитом, который сейчас отведен как хранилище поставок и закрыт для прямой записи (сейчас только через дженкинс туда ставится). Инсталяторы писали вручную по шаблонам…
Потом был переход к новой схеме. Когда прежде чем начать работу, брали исходники из юнита, создавали репозиторий в гите и втаскивали все туда прежде чем начать доработку.
Сейчас, конечно, все устаканилось, хотя бывает иногда попадается что-то совсем старое чего в гите нет. Но уже очень редко.
Все это, кстати, развернуто за последние годы. Еще три года назад, когда я пришел, гитом так активно не ползовались, гредла не было у нас, не было артифактори, джиры… FSD хранились в базе Lotus. Альтренативы RDi для разработки не было т.к. она позволяла работать с исходниками на сервере — так и работали с тем юнитом, который сейчас отведен как хранилище поставок и закрыт для прямой записи (сейчас только через дженкинс туда ставится). Инсталяторы писали вручную по шаблонам…
Потом был переход к новой схеме. Когда прежде чем начать работу, брали исходники из юнита, создавали репозиторий в гите и втаскивали все туда прежде чем начать доработку.
Сейчас, конечно, все устаканилось, хотя бывает иногда попадается что-то совсем старое чего в гите нет. Но уже очень редко.
Я понимаю, но таки посмотрите на это всё с позиции приходящих к вам людей. Люди приходят, чтобы (в разных пропорциях) получать денежную компенсацию, решать интересные задачи, улучшать мир, получать новые навыки, получать трансферабельные новые навыки.
За трансферабельными навыками — это в учебное заведение или на курсы.
У нас будут прокачиваться те навыки, которые нужны для решения наших задач.
А поскольку сфера специфическая и платформа специфическая, то и навыки будут специфическими.
Если кандидат не согласен — значит не договорились.
Оплата по рынку. Плюс стабильность (тут не будет ситуации когда вдруг скажут «извините, но работы больше нет, проект закончился, нового заказчика не нашли, разбегаемся»). Плюс плюшки — 100% белый оклад, оговариваемый в оффере, бонусы все сверху по результатам работы (тут достаточно ровно выполнять все задачи и будешь иметь +15% от суммарного оклада за период, сделал больше — получишь больше). Плюс ДМС. Плюс страхование жизни и трудоспособности. Поднимешся по грейду — будут еще плюшки в виде различных компенсаций.
Так что тут все должны понимать — кандидат — куда он идет, мы — уровень кандидата, чего от него ждать прямо сейчас и чему его нужно еще учить.
И да. У нас нет «тестовых заданий» в прямом смысле (не решил — не прошел). У меня вот вообще никаких тестов не было. Просто рассказал какие задачи решал, мне рассказали чем занимаются тут. На том и договорились.
Фреймворков, как таковых, у нас нет. Поэтому знание конкретного фреймворка нас не интересует. Интересует как у человека голова работает. Общий подход к разработке.
Более того, те, кто привык работать с фреймворком и на 100% доверять ему (считая его абсолютно надежным и устойчивым) нас интересуют в меньше степени. Потому что у наких людей в среднем больше склонности сказать «я не знаю как это сделать потому что в моем фреймворке этого нет».
Оплата по рынку
А какой рынок вы смотрите если
А поскольку сфера специфическая и платформа специфическая, то и навыки будут специфическими.?
НЛО прилетело и опубликовало эту надпись здесь
А зачем?
Нам нужен человек, который будет решать задачи нашего бизнеса. А человек, который будет прокачивать скиллы чтобы через два года уйти в другое место нам не нужен.
При этом у нас поощряется обучение. Если вы найдете курсы какие-то и сможете обосновать что они вам нужны для работы, то вам их с большой вероятностью оплатят (периодически идут рассылки — «если кто хочет, что-то нашел — сообщайте»).
Все это обговаривается на берегу. Если человек не согласен — его право. Однако, проблем с разработчиками у нас нет. Просто есть дополнительный фильтр — нужны люди, которые хотя заниматься именно нашими задачами и расти в рамках нашей компании. Такие находятся. Текучка у нас очень небольшая. Люди приходят надолго, растут как по позиции, так и по деньгам. «Пехоты» (вечных джунов) у нас нет. Или человек растет, или уходит. По крайней мере в нашей части (backend на IBM i). В части, которая занимается веб и мобильной разработкой, видимо, побольше. Но там нет специфики.
Нам нужен человек, который будет решать задачи нашего бизнеса. А человек, который будет прокачивать скиллы чтобы через два года уйти в другое место нам не нужен.
При этом у нас поощряется обучение. Если вы найдете курсы какие-то и сможете обосновать что они вам нужны для работы, то вам их с большой вероятностью оплатят (периодически идут рассылки — «если кто хочет, что-то нашел — сообщайте»).
Все это обговаривается на берегу. Если человек не согласен — его право. Однако, проблем с разработчиками у нас нет. Просто есть дополнительный фильтр — нужны люди, которые хотя заниматься именно нашими задачами и расти в рамках нашей компании. Такие находятся. Текучка у нас очень небольшая. Люди приходят надолго, растут как по позиции, так и по деньгам. «Пехоты» (вечных джунов) у нас нет. Или человек растет, или уходит. По крайней мере в нашей части (backend на IBM i). В части, которая занимается веб и мобильной разработкой, видимо, побольше. Но там нет специфики.
А человек, который будет прокачивать скиллы чтобы через два года уйти в другое место нам не нужен.
Какое у вас, однако, интересное отношение к сотрудникам
Я уж думал в ИТ прошли времена когда за стаж работы меньше 5-10 лет вешали ярлык «бегунок»
в ИТ если остановиться и сидеть на одном месте 5-10-20 лет, то потом не получится поменять работу, если с вашей конторой чтото случится, потому что опыт устареет, а ваши ценные бизнеспроцессы не будут котироваться.
Я работал в одном месте, у нас в отделе были человек 5 плюсовиков «старой школы», которые работали в этой конторе с середины 90х… и уже дядечки в годах (не пенсионных но близко), они работали на зарплате в -30% от моей (джуновской на тот момент)… и когда за чашкой чая мы разговаривали, они говорили что мало того что по плюсам мало вакансий, так ещё они очень сильно отстали в от современных веяний в ИТ и приходится довольствоваться тем что есть… тупо не берут, опыт частично не релевантен.
И забавно что вы считаете ваших работников железными болванчиками которые должны радеть за вашу фирму и совершенно не думать о своем собственном будущем.
p.s. потому что если у вас в конторе будут проблемы, вы их сократите не моргнув глазом, без всяких «нам нужен правильный человек»… сегодня нужен, завтра не нужен
Тут вопрос не такой простой. Мы же не сайты делаем. Которые в общем-то все одинаковые. И не мобильные приложения клепаем.
Чтобы писать эффективный код, требуется, во-первых, ориентироваться в предметной области (как работает банк вообще и данная конкретная АБС в частности). Хотя бы на самом общем уровне. За себя скажу, что проработав три года (даже больше) я не могу про себя сказать что сильно хорошо во всем этом ориентируюсь. Да, некоторые вещи знаю достаточно прилично — как оно устроено, что с чем как связано и т.п. А некоторых не знаю практически совсем. Поэтому у нас есть разделение по командам — Тарифный модуль, Модуль пластиковых карт, Лимитный модуль, Система расчетов… Есть общие ядровые функции, есть комплаенс… Т.е. все равно у каждого есть какая-то специализация внутри системы. Без этого очень трудно ожидать от человека эффективной работы. Даже при том, что все ТЗ пишутся аналитиками — специально обученными людьми, которые лучше нас разбираются в тонкостях бизнес-процессов.
Во-вторых, нужно еще неплохо понимать как работает AS/400 (IBM i). Там тоже очень много тонкостей на понимание которых уходит время. Какие опции в каком случае надо выставить в DDS для физических файлов. Какие для логических. Какие операции эффективны по нагрузке, какие ресурсозатратны и их надо избегать или выносить в блок инициализации группы активации. И таких тонкостей тоже очень много, все это постигается далеко не сразу, на опыте. И на все это нужно время.
И вот точно не будут сокращать людей с опытом. Потому что это дорого. Подготовить нового спеца на замену тому, кто уже вник в систему.
Так что если человек стремится развиваться, проявлять проактивность — его будут двигать вверх. И по должности и по деньгам. Чтобы сохранить.
Возникает задача чуть посложнее — сразу вопрос — кому ее дать? Кто справится? Кто сможет оптимизировать старый модуль, который отрицательно влияет на эффективность? Явно не тот, кто работает тут без году неделя…
А сокращения… Я писал уже. Даже в нынешней ситуации у нас их не было. Никого не сократили, никому не понизили оклад.
Если Вам не везло с работодателем и к Вам относились как к расходному материалу, пехоте, цена которой рубль за пучок в базарный день — не значит что везде так. Возможно, это типично для вебразработки или мобильной. Но тут ситуация иная. Да, это узкая сфера у нас (но не в мире). Но тут отношение к специалисту с опытом разработки несоколько иное чем в других областях. Хорошего спеца не так просто найти и еще сложнее подготовить. Так что за них держатся. И чем выше по положению, тем сильнее держатся.
Чтобы писать эффективный код, требуется, во-первых, ориентироваться в предметной области (как работает банк вообще и данная конкретная АБС в частности). Хотя бы на самом общем уровне. За себя скажу, что проработав три года (даже больше) я не могу про себя сказать что сильно хорошо во всем этом ориентируюсь. Да, некоторые вещи знаю достаточно прилично — как оно устроено, что с чем как связано и т.п. А некоторых не знаю практически совсем. Поэтому у нас есть разделение по командам — Тарифный модуль, Модуль пластиковых карт, Лимитный модуль, Система расчетов… Есть общие ядровые функции, есть комплаенс… Т.е. все равно у каждого есть какая-то специализация внутри системы. Без этого очень трудно ожидать от человека эффективной работы. Даже при том, что все ТЗ пишутся аналитиками — специально обученными людьми, которые лучше нас разбираются в тонкостях бизнес-процессов.
Во-вторых, нужно еще неплохо понимать как работает AS/400 (IBM i). Там тоже очень много тонкостей на понимание которых уходит время. Какие опции в каком случае надо выставить в DDS для физических файлов. Какие для логических. Какие операции эффективны по нагрузке, какие ресурсозатратны и их надо избегать или выносить в блок инициализации группы активации. И таких тонкостей тоже очень много, все это постигается далеко не сразу, на опыте. И на все это нужно время.
И вот точно не будут сокращать людей с опытом. Потому что это дорого. Подготовить нового спеца на замену тому, кто уже вник в систему.
Так что если человек стремится развиваться, проявлять проактивность — его будут двигать вверх. И по должности и по деньгам. Чтобы сохранить.
Возникает задача чуть посложнее — сразу вопрос — кому ее дать? Кто справится? Кто сможет оптимизировать старый модуль, который отрицательно влияет на эффективность? Явно не тот, кто работает тут без году неделя…
А сокращения… Я писал уже. Даже в нынешней ситуации у нас их не было. Никого не сократили, никому не понизили оклад.
Если Вам не везло с работодателем и к Вам относились как к расходному материалу, пехоте, цена которой рубль за пучок в базарный день — не значит что везде так. Возможно, это типично для вебразработки или мобильной. Но тут ситуация иная. Да, это узкая сфера у нас (но не в мире). Но тут отношение к специалисту с опытом разработки несоколько иное чем в других областях. Хорошего спеца не так просто найти и еще сложнее подготовить. Так что за них держатся. И чем выше по положению, тем сильнее держатся.
Я работал в процессинге, там правда была другая причина почему у конторы проблемы были… и из-за корпоративных соглашений и стечении обстоятельств, я не смог уйти куда «все нормальные убежали»
Везде так, когда бабки кончаются по какойто причине, чудес не бывает. Сократят не моргнув глазом, если бюджеты будут поджимать.
и не повыслили тоже ;) вы таки договаривайте.
Я, так случилось, что хоть и работал программистом но был очень приближен к бюджетированию и экономистам. и знаю что стоит обычно за словами тимлидов/начальников отделов — «я не дам сокращать людей в моем отделе» — а за ними стоит то что их слово второе после текущего бюджета
А если в стране какойто кризис, банки могут начать резать целые подразделения, лет 5 назад на рынке труда было полно бывших банковских айтишников, я работал с админом который в течении 3х лет успел поработать в 3х банках у которых отозвали лицензию… до смешного доходило, в одном месте он отработал 2 месяца… был «успешный банк» у которого совершенно внезапно отозвали лицензию
не значит что везде так.
И вот точно не будут сокращать людей с опытом
Везде так, когда бабки кончаются по какойто причине, чудес не бывает. Сократят не моргнув глазом, если бюджеты будут поджимать.
Никого не сократили, никому не понизили оклад.
и не повыслили тоже ;) вы таки договаривайте.
Я, так случилось, что хоть и работал программистом но был очень приближен к бюджетированию и экономистам. и знаю что стоит обычно за словами тимлидов/начальников отделов — «я не дам сокращать людей в моем отделе» — а за ними стоит то что их слово второе после текущего бюджета
А если в стране какойто кризис, банки могут начать резать целые подразделения, лет 5 назад на рынке труда было полно бывших банковских айтишников, я работал с админом который в течении 3х лет успел поработать в 3х банках у которых отозвали лицензию… до смешного доходило, в одном месте он отработал 2 месяца… был «успешный банк» у которого совершенно внезапно отозвали лицензию
Пересмотр ФЗП в октябре. Понижения точно не будет т.к. оклады прописаны в трудовых соглашениях (то, что получаем каждый месяц — 100% белый оклад, его не сократить просто так). Повышения, наверное, тоже в виду кризиса.
По должности лично меня повысили в мае. Оклад тот же пока (т.к. вилки пересекаются), но появились дополнительные плюшки в виде более высокого коэффициента бонуса, дополнительных компенсационных выплат.
Ну а насчет отозвать лицензию… Банк 5-й (по-моему) с списке «системобразующих». Со всеми вытекающими.
По объему решаемых нами задач — сокращение своего IT автоматически приведет к передаче этих задач вендорам. А банку это по ряду причин не выгодно. Тенденция наоборот.
Кстати, за время кризиса точно знаю что в нашу команду приняли несколько новых сотрудников.
Так что скорее расширяемся чем сокращаемся.
Не, я понимаю, что в мелких банках, котрых с свое время насоздавали как «личный общак», ситуация немного иная. И по отношению к сотрудникам и по оплате.
По должности лично меня повысили в мае. Оклад тот же пока (т.к. вилки пересекаются), но появились дополнительные плюшки в виде более высокого коэффициента бонуса, дополнительных компенсационных выплат.
Ну а насчет отозвать лицензию… Банк 5-й (по-моему) с списке «системобразующих». Со всеми вытекающими.
По объему решаемых нами задач — сокращение своего IT автоматически приведет к передаче этих задач вендорам. А банку это по ряду причин не выгодно. Тенденция наоборот.
Кстати, за время кризиса точно знаю что в нашу команду приняли несколько новых сотрудников.
Так что скорее расширяемся чем сокращаемся.
Не, я понимаю, что в мелких банках, котрых с свое время насоздавали как «личный общак», ситуация немного иная. И по отношению к сотрудникам и по оплате.
НЛО прилетело и опубликовало эту надпись здесь
Оплата по рынку. Плюс стабильность (тут не будет ситуации когда вдруг скажут «извините, но работы больше нет, проект закончился, нового заказчика не нашли, разбегаемся»).
Зато наверное легко могут сказать что банк закрыт (я ведь угадал с областью бизнеса, так?) или у отдела забирают все бизнес-задачи и передают в головной филиал, а на месте оставят только макак-менятелей картриджей в принтерах. Или вы Иегову за гениталии держите чем-то что так уверены что уверены в своей job security?
Банк из 10-ки системообразующих закрыт? :-)
С закрытием отделения тоже не так просто. Скорее наоборот. Есть три команды — Мск, СПб и Екат. И есть курс на отказ от услуг вендоров в бекразработке.
Так что доля вендоров сокращается, доля своих разработчиков наращивается.
За время кризиса у нас не было ни увольнений, ни сокращений оплаты.
И отношение к ИТ командам здесь весьма разумное. Бизнес прекрасно понимает что мы наравне со всеми помогаем делать прибыль. А это основная цель банка.
Так что в плане отношения с работодателем и организации условий для работы тут все очень шоколадно.
С закрытием отделения тоже не так просто. Скорее наоборот. Есть три команды — Мск, СПб и Екат. И есть курс на отказ от услуг вендоров в бекразработке.
Так что доля вендоров сокращается, доля своих разработчиков наращивается.
За время кризиса у нас не было ни увольнений, ни сокращений оплаты.
И отношение к ИТ командам здесь весьма разумное. Бизнес прекрасно понимает что мы наравне со всеми помогаем делать прибыль. А это основная цель банка.
Так что в плане отношения с работодателем и организации условий для работы тут все очень шоколадно.
Люди туда работать идут не ради того, чтобы выяснять, первокурсник лучше освоит лисп или питон.
Вот честно хотелось бы, чтобы именно ради таких вопросов и шли.
А то наши (большей части exUSSR) типовые вузы, где большинство преподавателей пенсионного возраста и в лучшем случае пишут фанфики по мотивам настоящей науки (а то и этим себя не озадачивают) — годятся только ради корочки.
Ну я не знаю, вы как налогоплательщик считаете, что тратить деньги общества на выяснение «что лучше для университета — Питон или Лисп» — это хорошее расходование средств? Притом что классики типа Брукса (или может, не он это сказал, а Перлис или Парнас, не помню) давно заметили, что если бы какой-то язык давал прирост производительности труда по сравнению с другим хотя бы на 5%, все на нём бы сидели. Я не против такого исследования, конечно, с чего бы мне быть против. Но навскидку мне не кажется, что это сверхинтересная работа, потому что с практической точки зрения если даже студенты полгода посидят на Лиспе, всё равно ради реальной жизни через полгода они начнут изучать Питон или C, а если им это слишком сложно, то скорее всего, они для этой профессии слабо пригодны всё равно.
вы как налогоплательщик считаете, что тратить деньги общества на выяснение «что лучше для университета — Питон или Лисп» — это хорошее расходование средств?
Я как налогоплательщик считаю, что образование должно быть чем выше качества, тем лучше, и для этого эксперименты жизненно необходимы — разумеется, по правильным методикам (включающим осторожное начало и независимое оценивание), но необходимы.
В остальном же резкий перевод на тему налогов выглядит приёмом некорректной полемики.
если бы какой-то язык давал прирост производительности труда по сравнению с другим хотя бы на 5%, все на нём бы сидели.
Это откровенная ерунда, потому что приросты бывают и в 500 и в 100500 процентов, но — в конкретных областях и для конкретных типов задач. Иначе бы новые языки просто не выстреливали, и мы бы действительно сидели на одном Фортране или Коболе. Если вы видите язык, который вышел из породившей его лаборатории и пошёл по миру, то он даёт прирост не 5%, а как минимум десятки процентов — иначе легаси не дало бы ему развиться.
потому что с практической точки зрения если даже студенты полгода посидят на Лиспе, всё равно ради реальной жизни через полгода они начнут изучать Питон или C, а если им это слишком сложно, то скорее всего, они для этой профессии слабо пригодны всё равно.
"Реальная жизнь" она разная бывает. Вон если больше половины (навскидку и например) применений Python это врапперы вокруг numpy/pandas/etc., то тем, кто использует его для таких задач, LISP нафиг не сдался.
А вот тем, кто целится на широкий спектр понимания CS, надо учить и LISP, и Forth, и обычные процедурные языки, и акторные цепочки из промисов… а вообще такому надо пройти, например, этот список до указанного уровня (знать по каждому слову, что оно и чем характерно). (Может, чуть устарел — ну так обновлять.)
резкий перевод на тему налогов выглядит приёмом некорректной полемики.Смотрите, этот приём корректен потому, что именно таким образом оцениваются предложения учёных в грантовых комиссиях. Если кто-то захочет провести подобную работу и выбить под это деньги, то проект будут изучать на предмет научной интересности, новизны и да, impact/spillover effects/importance, вот и всё.
Это откровенная ерунда, потому что приросты бывают и в 500 и в 100500 процентовБезусловно. Эта цитата относилась к языку «общего назначения» в рамках написания «софта широкого профиля». Сейчас мы имеем куда больший зоопарк языков и сфер применения, но если сосредоточиться на «учебных» языках, то назовите любую десятку — пусть там будет и Паскаль, и Питон, и Руби, и что угодно ещё. Вот я уверен, что не найдётся такого языка, который вот прямо все понимают, а Питон не понимают. Ну ведь уже учили и на Бейсике, и на Лого, и на чём только не. Любой не слишком замороченный язык плюс-минус одинаков.
А вот тем, кто целится на широкий спектр понимания CS,Мы здесь по сути обсуждаем «вход в IT», то есть с чего начать, а не чего в принципе стоит освоить. Это другой вопрос.
Есть какие-то исследования, что условный питон эффективнее для начального обучения программированию, чем условный лисп?
MIT таки писал какое-то обоснование, почему они перевели CISP со Scheme на Python. Можете поискать.
Не вижу особой проблемы начинать с паскаля в школе
Пачка граблей, которые непонятны и которые надо тупо запомнить, я об этом писал несколько раз: 1 2 и т.д.
Я понимаю критику C, но тогда надо брать не Pascal, а хотя бы Modula-3.
кто заинтересуется изучит и другие.
Школьное образование должно быть рассчитано не на того, кто заинтересуется, а на то, что останется в голове у того, кто не интересуется. Иначе вообще держать предмет нет смысла.
Я понимаю критику C, но тогда надо брать не Pascal, а хотя бы Modula-3.
Но зачем? Это очередной мертвый язык. Ни IDE, ни SO, ни реальных проектов. Ничего нет. Не надо откапывать стюардессу.
а нужно ли детям SO? мы же о первом языке говорим, это должна быть чуть ли не начальная школа
Начальная школа это вы преувеличиваете.
Да, а почему нет? Пусть привыкают что на правильно сформулированный вопрос как сделать тото интернет всегда ответит.
Мы же используем so. Так почему обучающимся не надо? Не надо решать за других. Есть сложившиеся практики. Надо просто обеспечить их доступность.
Да, а почему нет? Пусть привыкают что на правильно сформулированный вопрос как сделать тото интернет всегда ответит.
Мы же используем so. Так почему обучающимся не надо? Не надо решать за других. Есть сложившиеся практики. Надо просто обеспечить их доступность.
Начальная школа это вы преувеличиваете.
помните «математику уже затем учить надо, что она ум в порядок приводит»? программирование «приводит ум в порядок» ничем не хуже, я считаю, что его стоит изучать для развития детей, а не потому, что оно действительно многим пригодится в жизни.
и ещё есть одна мысль (не моя): программирование — это единственная «серьёзная» школьная дисциплина, где разрешено ошибаться (ситуация, когда программа не работает с первого раза, нормальна). и это тоже очень важно именно для развития детей.
первый язык должен ИМХО изучаться достаточно рано, никак не в ВУЗе. ну пусть не начальная школа, 5-6 класс.
уже в седьмом классе дети начинают изучение геометрии с почти полноценным аксиоматическим подходом, то есть ожидается, что они способны понимать и самостоятельно создавать достаточно сложные логические построения. так что и в программировании уже есть где развернуться.
Пусть привыкают что на правильно сформулированный вопрос как сделать тото интернет всегда ответит.
а вот как раз не всегда ответит.
нужно учить решать задачи самостоятельно, если этот навык есть — гуглить всегда научатся. обратное же неверно.
Мы же используем so. Так почему обучающимся не надо?
хотя бы потому, что он превратится ещё в один сайт с набором ГДЗ.
P. S. хотя за «правильно сформулированный вопрос» поставил плюс. но этот навык, наверное, нужно вырабатывать уже позже (по сути он не так уж сильно отличается от навыка самостоятельного поиска информации в библиотеке; что ранее ожидалось от студента, может быть старшеклассника)
первый язык должен ИМХО изучаться достаточно рано, никак не в ВУЗе. ну пусть не начальная школа, 5-6 класс.
уже в седьмом классе дети начинают изучение геометрии
И в итоге геометрия это один из самых непонятных и ненавистных предметов для школьников. Слишком сложно.
Нет смысла гнать. Я бы сказал раньше 9 класса точно рано. 9-10 только самые начала, остальное не влезет. 11 егэ и только подготовка к нему, остальное не важно уже. И в итоге на первом курсе быстрое повторение всего что было в школе. Можно за половину первого курса при желании.
но этот навык, наверное, нужно вырабатывать уже позже (по сути он не так уж сильно отличается от навыка самостоятельного поиска информации в библиотеке; что ранее ожидалось от студента, может быть старшеклассника)
На дворе 2020 год. Надо адаптироваться. Гугл у каждого в кармане. Умение им пользоваться в реальной жизни очень ценится. Человек нагугливший решение и разобравшийся в нем достоин хорошей оценки. Читать чужой код не так просто. Часто проще самому написать.
Проверять что человек разобрался в том что сдает должен преподаватель. Это не так сложно.
хотя бы потому, что он превратится ещё в один сайт с набором ГДЗ.
Вот этим программирование и отличается от многих предметов. Правильный ответ это приличное количество текста. Осмысленного текста. Который незнающий предмет даже прочитать не сможет. Пусть списывают и разбираются. Читать чужой код это нормальный способ обучения.
Нет смысла гнать. Я бы сказал раньше 9 класса точно рано. 9-10 только самые начала, остальное не влезет.
какой-нибудь лого в девятом классе? не смешно )
Вот этим программирование и отличается от многих предметов. Правильный ответ это приличное количество текста
гхм. что в математике, что в физике, что в химии проверяется решение, и это тоже «много текста».
Который незнающий предмет даже прочитать не сможет
и кого это останавливало? списывают всё подряд не разбираясь и не понимая что за символы списывают.
Ко всяким Лого и прочим «детским» языкам я отношусь с большим подозрением и не понимаю зачем оно вообще нужно. Может быть я детей не понимаю. Я про нормальные языки и нормальное программирование.
Там есть правильное решение, а есть неправильное. На школьном уровне это обычно поставить пару формул и все. Что спросить по этим формулам непонятно. Ну можно узнать откуда их человек списал или вообще наизусть помнит. Смысла в этом немного, но можно.
А вот даже строк 30 кода это стиль, имена, вообще оформление. Код с любого идеального решения виден сразу. Он просто хороший. Ни один школьник такое не напишет. Значит списан и можно пообщаться.
А почему тут i++? А что будет если ++i написать?
А почему этот цикл вот такой? А не вот сякой. А напиши его по другому. Как хочешь, но по другому.
А как ты выбрал имя вот для этой переменной? Особенно если она на хорошем английском названа.
И далее по теме. Любая строка, если она не авторская, вызывает вопросы.
А уж спросить как ты это проверял или проверил бы вообще замечательно. Даже корпорации не брезгуют такими вопросами. Корнер кейсы проверь по своему коду вслух. Делаем скидку на школьников и сами кейсы даем. А вот как их код будет работать на них пусть сами проговаривают.
Да пусть. Если понимает как работает — зачет. Нет — на пересдачу. Тот же пузырек правильно реализованный без понимания человек не расскажет что и почему. С кодом перед глазами.
гхм. что в математике, что в физике, что в химии проверяется решение, и это тоже «много текста».
Там есть правильное решение, а есть неправильное. На школьном уровне это обычно поставить пару формул и все. Что спросить по этим формулам непонятно. Ну можно узнать откуда их человек списал или вообще наизусть помнит. Смысла в этом немного, но можно.
А вот даже строк 30 кода это стиль, имена, вообще оформление. Код с любого идеального решения виден сразу. Он просто хороший. Ни один школьник такое не напишет. Значит списан и можно пообщаться.
А почему тут i++? А что будет если ++i написать?
А почему этот цикл вот такой? А не вот сякой. А напиши его по другому. Как хочешь, но по другому.
А как ты выбрал имя вот для этой переменной? Особенно если она на хорошем английском названа.
И далее по теме. Любая строка, если она не авторская, вызывает вопросы.
А уж спросить как ты это проверял или проверил бы вообще замечательно. Даже корпорации не брезгуют такими вопросами. Корнер кейсы проверь по своему коду вслух. Делаем скидку на школьников и сами кейсы даем. А вот как их код будет работать на них пусть сами проговаривают.
и кого это останавливало? списывают всё подряд не разбираясь и не понимая что за символы списывают.
Да пусть. Если понимает как работает — зачет. Нет — на пересдачу. Тот же пузырек правильно реализованный без понимания человек не расскажет что и почему. С кодом перед глазами.
Ко всяким Лого и прочим «детским» языкам я отношусь с большим подозрением и не понимаю зачем оно вообще нужно.
ровно затем же, зачем и геометрия, например. я же выше написал. для развития абстрактного мышления. плюс для обучения планированию действий, умению заглядывать на несколько шагов вперёд.
побочный эффект: когда мы в старших классах начнём изучать «настоящий» язык, у учеников уже будет понимание того, что такое алгоритм, условие, цикл, переменная, а то и функция с рекурсией.
это обычная практика, когда одно и то же изучают несколько раз, та же площадь прямоугольника боюсь даже вспомнить сколько раз, тут вспоминали экстремумы функций, которые «наивно» проходят в 7-8 классе, а потом аналитически в 10 классе, s=v⋅t, которое проходится и в математике, и в физике, и т. д., и т. п.
BTW, вот обучение «настоящему» языку ИМХО можно уже сделать опциональным, далеко не всем оно нужно.
А почему этот цикл вот такой? А не вот сякой.
а что такое a⃗? а что означает стрелочка сверху? а в каких единицах оно измеряется?
Тот же пузырек правильно реализованный без понимания человек не расскажет что и почему. С кодом перед глазами.
вы опять про студентов, а я про детей.
С тем же успехом можно позволять списывать решения по физике, химии, алгебре, геометрии. А что, там же тоже как и в программировании можно решение нагуглить.
И в итоге геометрия это один из самых непонятных и ненавистных предметов для школьников. Слишком сложно.Классическая проблема: есть хороший учитель и хороший учебник — можно и в 5-7 классе давать, и никакой ненависти не будет. Учебники Пойа, Локхарта или Киселёва вполне себе понятные и последовательные, а вот более новые, «академичные» учебники я бы школьникам в руки не давал, минимум студентам.
Нет смысла гнать. Я бы сказал раньше 9 класса точно рано.
НЛО прилетело и опубликовало эту надпись здесь
Как НЕ надо начинать изучать программирование