Я считаю, что оно нужно только для того, чтобы понтоваться, растопыривая пальцы.
Существуют математики, существуют программисты. У первых это исчисление и TeX для того, чтобы в нём писа́ть,
а у вторых есть машины Тьюринга, Поста, которые полностью этому лямбда-исчислению эквивалентны
,
и позволяют всё программировать на мейнстримной сишечке (ну или на упоротый случай на расте).
Математикам очень хочется денег, и поэтому они настаивают именно на своём синтаксисе в "научных" статьях.
Хотя так-то синтаксис программистов лучше (и это доказывается практикой ИТ).
Если бы математики были бы правы, то лисп бы всех зарулил. Но нет, его в курсах MIT заменили на Python.
Это о многом говорит. Или должно говорить.
---
Лямбда-исчисление было изобретено раньше машины Тьюринга
Алонзо Черчем, который был преподавателем Тьюринга
(т.е. Тьюринг это исчисление знал, но свою машину изобрёл всё равно).
Поэтому пользоваться сишечкой идеологически более верно, потому что более прогрессивно, модно и более современно.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я считаю, что оно нужно только для того, чтобы понтоваться, растопыривая пальцы.
ЭФ>Существуют математики, существуют программисты. У первых это исчисление и TeX для того, чтобы в нём писа́ть, ЭФ>а у вторых есть машины Тьюринга, Поста, которые полностью этому лябмда-исчислению эквивалентны, ЭФ>и позволяют всё программировать на мейнстримной сишечке (ну или на упоротый случай на расте). ЭФ>Математикам очень хочется денег, и поэтому они настаивают именно на своём синтаксисе в "научных" статьях.
ЭФ>Хотя так-то синтаксис программистов лучше (и это доказывается практикой ИТ). ЭФ>Если бы математики были бы правы, то лисп бы всех зарулил. Но нет, его в курсах MIT заменили на Python. ЭФ>Это о многом говорит. Или должно говорить.
Что, с лямбдами в C#/ES пытаешься разобраться? Никак не даются?
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Эйнсток Файр, Вы писали:
Pzz>> Рефал забыли, гады
ЭФ>Мне тут говорят — а ты на haskell, на Хаскель смотри. ЭФ>Не будешь его использовать, не будет никакого автоматического распараллеливания ЭФ>и не возьмут тебя огромные суперкомпьютеры программировать.
Зачем тебе огромные суперкомпьютеры? Они шумные, пыльные и громоздкие.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>И очень странно слышать от собеседующего вопрос "а как вы тогда сможете функцию в функцию передавать"? ЭФ>Т.е. он не знает Си! Вообще! Иначе бы это не было для него вопросом.
Я же говорил. Пытается осилить лямбды, лямбды отчаянно сопротивляются. Картина "Неравный бой" ))
Запишись на курсы. Там рассказывают про "гражданство первого класса", может расскажут и про разницу с сишными указателями.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Мне не может достаться на поддержку код. Потому что это означает, что уволили человека, который его разрабатывал. А зачем мне такой руководитель, который успешных разработчиков увольняет? Если же разработчик не был успешным, значит и код плохой, и его надо переписать =)
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Существуют математики, существуют программисты. У первых это исчисление и TeX для того, чтобы в нём писа́ть, ЭФ>а у вторых есть машины Тьюринга, Поста, которые полностью этому лямбда-исчислению эквивалентны, ЭФ>и позволяют всё программировать на мейнстримной сишечке (ну или на упоротый случай на расте).
Мы ж не программируем в машине Тьюринга, мы пишем функции/методы. ))
Ты бы задолбался машину Тьюринга прогать.
ЭФ>Математикам очень хочется денег, и поэтому они настаивают именно на своём синтаксисе в "научных" статьях.
Синтаксис там минимальный, как любят математики.
ЭФ>Хотя так-то синтаксис программистов лучше (и это доказывается практикой ИТ).
Возможно.
Чёрч разработал эту нотацию до завоевания популярности Си-подбного или ML-подобного синтаксиса в ЯП.
На деле там достаточно простое отображение в привычный синтаксис, например в C#:
Л.И.:
(/xy.x+y) 42 43
Шарп:
((x, y) => x + y)(42, 43)
или, более педантично:
(но, увы, уже в типах и промежуточных переменных)
var xy = (int x) => (int y) => x + y;
xy(42)(43);
(нахрена ему промежуточная переменная xy? пипец, дичь...)
ЭФ>Если бы математики были бы правы, то лисп бы всех зарулил.
Убогость Лиспа была связана с необходимостью достаточно быстрого его интерпретирования на технике конца 50-х.
ЭФ>Но нет, его в курсах MIT заменили на Python.
Давно пора.
ЭФ>Это о многом говорит. Или должно говорить.
Ес-но.
Хотя, Питон тоже гавнецо, но всяко лучше Бейсика.
Я пока не вижу достаточно удачного языка для начала обучения программированию.
Паскаль тоже донельзя дебильный — писать кучу "шапочного" объявления, заранее планировать, какие переменные могут понадобиться и заранее их объявлять.
Это всё сплошная тухлятина прямиком из 50-х, из Алгола.
ИМХО, если бы чуть осовременить Фортран — было бы самое то.
(совместить объявление переменных и инициализацию их значениями, разрешить рекурсию, чуть упростить запись end type MyType и других аналогичных выражений до простого end)
(дополнение: оказывается, частично Фортран уже осовременнили)
(дополнение 2: оказывается, в стандартах F2008 и F2018 осовременнили полностью, но оба стандарта официально так и не вышли)
Потому что совсем простые ЯП, типа Бейсика или Лого, не тянут на язык для студентов, в лучшем случае как язык для школьников 5-8-х классов.
Я когда-то своих обучал программированию в их 15 лет, показал язык что-то типа осовремененного Лого — им хватило разобраться и начать писать минут через 10, хотя до этого не вникали ни в один ЯП и вообще этой темой не интересовались. А тут полюбопытствовали.
Так вот, я так и не сообразил, что им дать для самостоятельного копания далее.
В мою эпоху в старших классах на 8-битных компах можно было хотя бы в видеопамять сразу писать, т.е. хотя бы минимально-примитивные игры можно было писать сходу на коленке, даже можно было генерировать сразу же звук в цикле. А мне для своих пришлось сделать достаточно громоздкую заготовку бойлерплейт-кода ради маленького участка "пишите сюда процедуру рисования".
И особо оно не впечатлило, и после первых экспериментов любопытства и задора далее не вызвало.
Т.е. когда вокруг дохрена непонятного кода, который нужен для запуска небольшого кусочка понятного — это признак нездоровой какой-то херни, конечно.
А со звуком и вовсе уже на совсем другом уровне возились, когда уже в ВУЗ-е учились.
В плане непосредственного контакта со звуком современные архитектуры страшно далеки от народа.
В общем, с одной стороны, моща и удобство компов выросли, но, с другой стороны, комп и ПО для новичков всё более видятся вещами в себе, которые хрен его знает каким таким волшебным образом вообще работают. И куча непонятного бойлерплейт кода для любой примитивщины чуть сложнее "Привет, Мир!" наглухо отбивает позывы к любопытству!
Ну вот на МатЛабе немного повозились еще, но это тоже весчь слишком узкоспецифичная.
В общем, на простейших персоналках из 80-х понять целиком и полностью принцип работы компьютера было элементарно, просто взглянув на схему, прочитав 15 мин вводную и немного попрограммировав.
Сейчас аналогичная глубина понимания достигается за годы близкого общения с техникой.
Я со своими разбирал комп, показывал и на бумажках рисовал, что там вообще унутре происходит.
И что должно произойти, чтобы пиксель засветился или звук появился.
Но одновременно с этим схематично показывал и рассказывал, как оно было на компах моей эпохи, чтобы ответить на немой вопрос "чего так всё мудрёно-то?"
Т.е. вот так — сразу же необходимо было оправдывать неприспособленность современных компов для близкого общения и экспериментов. ))
Питон в этом смысле тут хорош лишь тем, что позволяет обходиться без бойлерплейта.
Но сам язык — полное Г, конечно, еще больше отдаляет студентов от понимания принципов работы техники и ПО на ней.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Существуют математики, существуют программисты. У первых это исчисление и TeX для того, чтобы в нём писа́ть, ЭФ>а у вторых есть машины Тьюринга, Поста, которые полностью этому лябмда-исчислению эквивалентны, ЭФ>и позволяют всё программировать на мейнстримной сишечке (ну или на упоротый случай на расте). ЭФ>Математикам очень хочется денег, и поэтому они настаивают именно на своём синтаксисе в "научных" статьях.
На LISP-е определенно проще писать, чем для машины Тьюринга
ЭФ>Хотя так-то синтаксис программистов лучше (и это доказывается практикой ИТ).
Видел бы ты этот синтаксис в языках времен машины Тьюринга. Ты, пожалуйста, его с тёплой и ламповой Сишечкой не путай.
ЭФ>Если бы математики были бы правы, то лисп бы всех зарулил. Но нет, его в курсах MIT заменили на Python. ЭФ>Это о многом говорит. Или должно говорить.
Одичание. Скоро вообще будут учиться на этих системах для детей, когда "программа" собирается из картинок, изображающих ее отдельные элементы.
P.S. Рефал забыли, гады. Это еще одна Тьюринг-полная система программирования.
Мне тут говорят — а ты на haskell, на Хаскель смотри.
Не будешь его использовать, не будет никакого автоматического распараллеливания
и не возьмут тебя огромные суперкомпьютеры программировать.
Здравствуйте, Эйнсток Файр, Вы писали:
A>> Что, с лямбдами в C#/ES пытаешься разобраться? Никак не даются?
ЭФ>Нет, у меня нет целей изучать C#, и я вообще не знаю, что такое ES.
А зря. Каждому, кто пишет на "мейнстримной сишечке" я бы прописал пару лет того или и другого, чисто для расширения кругозора. С возможностью досрочного освобождения после сдачи экзамена по промисам. А то выучат один for...
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Эйнсток Файр, Вы писали:
A>> Что, с лямбдами в C#/ES пытаешься разобраться? Никак не даются? ЭФ>Нет, у меня нет целей изучать C#, и я вообще не знаю, что такое ES.
Здравствуйте, Эйнсток Файр, Вы писали:
A>> Там рассказывают про "гражданство первого класса", может расскажут и про разницу с сишными указателями.
ЭФ>Вы даже расшифровать аббревиатуру ES неспособны. ЭФ>Что вы можете понимать в first class citizen-ах?
Зачем мне что-то расшифровывать человеку, который не прошёл собеседование из-за незнания базовых вещей, и вместо того, чтобы сесть и разобраться, не придумал ничего умнее, чем создать тему "Да говно все эти ваши лямбды"? У тебя же на лбу написано, как это было. Пришёл домой расстроенный, сел читать с самых основ... с исчисления... самого Чёрча откопал, наверное. Тебе был дан дельный совет: вместо этого тупо попиши какое-то время на C# или ES, год — не год, это от человека зависит, некоторые за неделю схватывают, и что ты с этим советом сделал? На каком месте его покрутил? Что ж удивляться, что над тобой только издеваются.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
ЭФ>> Я считаю, что оно нужно только для того, чтобы понтоваться, растопыривая пальцы. LVV> Ты че!!!!!
Мне "для понимания темы" нехватает каких-то общих соображений.
Если я не пишу пользовательский интерфейс, то зачем мне "асинхронное программирование"?
Если я знаю, что такое "замыкания", как мне это поможет? Мне чихать на yield, я им всё равно не пользуюсь.
Без этих "общих соображений" у меня нет мотивации к изучению.
Здравствуйте, vdimas, Вы писали:
A>>В-пятых, человек, которому не объяснили, что в каждом ЯПе свои плюсы и минусы, что это как набор отвёрток для разных ситуаций, вырастает законченной бестолочью и потом всю жизнь страдает от утиного эффекта. Спрашивает, например, зачем нужны лямбды. Разве код с лямбдами выполняется быстрее? Нет? Ну и не нужны!
V>Ну... не скажи. V>Даже в весьма далёких друг от друга, на первый взгляд, языках, таких как Си, Паскаль и Фортран приличная часть кода, представляющая некие целевые вычисления, может быть похожа или в точности идентична — это я про математические выражения с переменными, в т.ч. переменными составных типов — структурами, при доступе к полям структур.
Я не настолько стар, чтобы помнить Фортран, а Си и Паскаль это две попытки в одном и том же... роду? семействе?.. (оба императивные, процедурные, статически типизированные, компилируемые, нативные) с разных сторон приблизиться к лучшей выразительности, про которую шла речь в п.2. Что выразительнее — закорючки или слова? А в остальном это одно и то же.
V>А так же все три языка поддерживают в том или ином виде функциональный тип хотя бы в минимальном виде — в виде указателей на ф-ии, т.е. поддерживают косвенный вызов ф-ий, что позволяет использовать инструмент абстракций даже еще безо-всякого встроенного в язык ООП. Вернее, оно даже показывает проблематику, которую затем более полно решает ООП.
Вот уж не думаю, что указатели на функции делают Си функциональным "хотя бы в минимальном виде". Си тупо отражает устройство железа, а железо просто поддерживает адресацию кода (по заветам фон Неймана). Нужно, всё-таки, гражданство первого класса, а это и инлайнинг выражений, и поддержка со стороны стандартной библиотеки.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я считаю, что оно нужно только для того, чтобы понтоваться, растопыривая пальцы.
Мне кажется, что там более сложные переходы были. ФП придумали математики, которые любят создать какую-то аксиоматику, обмазаться теоремами на основе этих аксиом, а потом думать, куда приткнуть этот аппарат. Потом была эра стремительного роста вычислительной техники, где решающую роль сыграли технологии, а не теоремы. Другими словами — важнее было наращивать количество флопс чем работать над инструментами доказательства программ. В какой-то момент об ФП узнали программисты и сказали: "О! А давайте сделаем такой язык, где будут только функции, и эту функции будут без побочных эффектов. И мы будем говорить, как это круто, когда нет побочных эффектов". О том, что результат работы программы это всегда побочный эффект, они, конечно, умолчали (или не знали). Так появились языки, объединённые одной сутью: х..ёвый синтаксис, низкая производительность и слово "functional" в описании. Никаких преимуществ у функциональных ЯП перед императивными нет.
Но вот Если копнуть глубже, но начнут проявлятся такие артефакты как зависимые типы. Я пока недостаточно понимаю теорию, чтобы точно ответить, есть ли у завтипов одна база с ФП, но вот практическая польза точно есть. С завтипами мы не просто пинаем хер, доказывая теоремы про Y-комбинатор, но и можем написать программу, которая, например, на этапе компиляции проверяет, что динамичекая строка соответствует некоему шаблону. Например, что она всегда непустая, или является палиндромом. И делается это не при помощи пре- или пост-условий, модульных тестов или статического анализатора. Это именно математически выводимое доказательство корректности типа, а сами условия на данные содержатся в описании типа. Звучит поистине круто, если бы не одно НО — готового коробочного продукта production-grade пока нет и не предвидится.
лямбда-выражения
это компактный синтаксис, заимствованный из λ-исчисления,
это анонимный (без имени) класс или метод, для передачи кода в качестве параметра в другой код.
т.е. его "компактность" в том, что можно обойтись без имени функции.
но зачем изучать λ-синтаксис, если
в реальности используется другой синтаксис — синтаксис языка программирования?
Сдаёшь на собеседование знание λ-исчисления, а потом никогда, никогда это не используешь в работе.
Кто не прав? Конечно собеседующий, потому что он недавний студент
и ничего не знает, кроме того, что ему в ВУЗе рассказали, но
кичится своим "кругозором человека с вышкой", больше нечем.
Можно сказать, что используются "понятия", и что проверяется именно их знание (наличие в голове).
Но по факту-то используются не те понятия, которые проверяет собеседующий, а другие.
TODO:>>> Привести пример из стандарта на Java
---
Синтаксисы в разных языках программирования разные, и возможно собеседующий хочет спросить "основы",
то есть нечто общее, что подошло бы куда угодно, чтобы не напрягать собеседуемого деталями конкретного языка?
Что мешает собеседуемому выучить как конкретную, так и отвлечённую обобщённую информацию
ради прохождения собеседования?
---
И очень странно слышать от собеседующего вопрос "а как вы тогда сможете функцию в функцию передавать"?
Т.е. он не знает Си! Вообще! Иначе бы это не было для него вопросом.
(может и знает, вопросы-то не ему, а собеседуемому)
Сможем, передача функции в функцию вообще проблемой не является.
Было ли когда-либо проблемой передать в Си указатель на функцию в качестве параметра? Нет, никогда не было.
Делали так ещё в 1994 году то есть 30 лет тому назад.
И главное, что это крайне редко используется (только для организации коллбэков).
TODO:>>> Привести пример кода для GObject на языке программирования Си.
Для чего используется передача функции в функцию? Где ЕЩЁ без этого вот прям концептуально не обойтись?
Здравствуйте, Pzz, Вы писали:
Pzz>Зачем тебе огромные суперкомпьютеры? Они шумные, пыльные и громоздкие.
Я суперкомпьютеров не видел. Зато начинал на ЕС ЭВМ сменным инженером. Шумные — да. Особенно когда АЦПУ работают. Громоздкие — возможно. В шкафу памяти на ЕС-1033 можно было поспать. Память, правда, была не ферритовых сердечниках. ЕС-1036 была намного компактнее.
Но пыльные... Категорически не согласен. В машзал мы всегда заходили в халатах. У меня был синий. И я упоминал как-то: однажды я пинками выгнал из зала взвод курсантов, которых на наш ВЦ на экскурсию привели, и они пытались зайти в зал в шинелях. А диски в отдельной зоне вообще стояли.
Неужели суперкомпьютеры пыли не боятся?
ЭФ>Я считаю, что оно нужно только для того, чтобы понтоваться, растопыривая пальцы.
Ты че!!!!!
Без этого не было бы лямбд! ЭФ>Если бы математики были бы правы, то лисп бы всех зарулил. Но нет, его в курсах MIT заменили на Python. ЭФ>Это о многом говорит. Или должно говорить.
Это говорит о двух вещах:
— о несоответствия архитектуры фон Неймана лямбда-исчислению (функциональное программирование)
— о том, что руководство МИТ следует моде
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Это говорит о двух вещах: LVV>- о несоответствия архитектуры фон Неймана лямбда-исчислению (функциональное программирование)
Скорее, гарвардская архитектура не соответствует, но её можно рассматривать как фон-неймановскую на этапе, когда писать в часть "ленты" уже не требуется.
А так-то абстракция стек-машинки вполне ложится на лямбда-исчисление.
(разве что размеры стека ограничены, ну да раскрутка хвостовой рекурсии в помощь)
И эта абстракция реализована в опкодах большинства исторически бывших или ныне популярных архитектур.
LVV>- о том, что руководство МИТ следует моде
Вернее, исходит из того, что есть.
Бо на сейчас нет адекватных языков для начала обучению программированию от слова совсем.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Мне тут говорят — а ты на haskell, на Хаскель смотри. ЭФ>Не будешь его использовать, не будет никакого автоматического распараллеливания ЭФ>и не возьмут тебя огромные суперкомпьютеры программировать.
Вот кстати сценарий, наверное не слишком реалистичный, но чем чёрт не шутит.
Хаскель ведь известен тем, что если программа скомпилировалась, значит в ней багов нет. Это, конечно, шутка, но с долей правды.
Сейчас есть некоторый тренд на генерацию программ с помощью LLM. И если сравнить, скажем, питон и хаскель, то сгенерированную программу на питоне надо как минимум запустить, и даже это не гарантирует, что в ней всё правильно, возможно в первом запуске не все пути выполнения отработали. Т.е. программу нужно сгенерировать и далее тщательно протестировать все варианты входных данных.
На хаскеле же ИИ имеет все шансы убрать множество багов до первого запуска.
Поэтому я может ставить на этот вариант развития событий и не буду, может быть для ИИ проще написать сто тестов, чем одну программу. Но в целом не слишком удивлюсь, если завтра GPT 5 выпустят с модулем программирования на хаскеле, который будет на голову выше всех остальных альтернатив.
Здравствуйте, LaptevVV, Вы писали:
ЭФ>>Если бы математики были бы правы, то лисп бы всех зарулил. Но нет, его в курсах MIT заменили на Python. ЭФ>>Это о многом говорит. Или должно говорить. LVV>Это говорит о двух вещах: LVV>- о несоответствия архитектуры фон Неймана лямбда-исчислению (функциональное программирование) LVV>- о том, что руководство МИТ следует моде
Архитектура фон Неймана говорит о том, что программа должна храниться в той же памяти, что и данные.
Во времена фон Неймана это было смело потому, что этой памяти было очень мало и она была люто, бешено дорогая. Это было непростое решение, использовать эту память для хранения программ.
Зато это открыло дорогу к программам для работы с программами — компиляторам, линкерам, загрузчикам и т.д. Что для одной программы данные, для другой программы — ее собственный код.
Ламбда-исчислению это не противоречит от слова совсем.
В LISP-е основная структура данных — это односвязанный список. Каждый узел списка состоит из двух указателей: на следующий элемент списка и на данные, которые хранятся в данном узле. Эти указетели традиционно называются CAR и CDR — по именам регистров той машины, на которой LISP был первоначально реализован. Именно эти регистры использовались при исполнении программ на LISP-е, программа, как несложно догадаться, тоже была списком.
В обшем, лямбда-исчисление не чуждо понятному железу
Здравствуйте, vdimas, Вы писали:
V>Бо на сейчас нет адекватных языков для начала обучению программированию от слова совсем.
Python хорош, на мой взгляд. Двигать черепашку командами легко и весело.
Посмотрел бы я, сколько труда пришлось бы вложить в такое в реализации на С/С++
(это я про обучение детей программированию,если что, а не студентов MIT)
Здравствуйте, vsb, Вы писали:
vsb>Хаскель ведь известен тем, что если программа скомпилировалась, значит в ней багов нет. Это, конечно, шутка, но с долей правды.
Может в какой-то части и так, но что есть баг? Результат ошибочно реализованного алгоритма — баг?
Здравствуйте, wl., Вы писали:
wl.>Python хорош, на мой взгляд.
Для изучающих профессию он тупиковый.
ИМХО, его надо давать в разделе языков сценариев, посвятить пару занятий от силы, как и башу, CMD, REXX.
wl.>Двигать черепашку командами легко и весело.
))
wl.>Посмотрел бы я, сколько труда пришлось бы вложить в такое в реализации на С/С++
Это надо брать любую интерпретирующую среду.
На Форте это было бы примерно пол-дня работы.
На JS — чел говорит, что накатал за пару дней: https://bztsrc.github.io/jslogo/
wl.>(это я про обучение детей программированию,если что, а не студентов MIT)
Да понятно.
Студенты должны через несколько занятий написать саму библиотеку черепашки для того же Питона.
А на 3-м курсе полноценный парсер-интерпретатор LOGO безо-всякого Питона. ))
Как раз на небольшой курсовичок труда.
Кстате, вспомнил про язык R.
Его можно считать Питоном с человеческим лицом. ))
Есть список/словарь/объект как в JS и Питоне, но есть и более эффективные типы данных: вектора, матрицы, многомерные массивы и таблицы (в таблице каждый столбец может быть разного типа, но в столбце все значения одного типа).
ЭФ> зачем изучать λ-синтаксис, если ЭФ> в реальности используется другой синтаксис — синтаксис языка программирования? ЭФ> TODO:>>> Привести пример из стандарта на Java
2014-04-12, начались боевые действия на территории Донецкой и Луганской областей.
TODO:>>> «straw-man examples»
Знание синтаксиса никак не добавляет мне знания причин, которые привела к формированию такого подхода/стиля/метода программирования.
«I’d been thinking about a simplified closures proposal for several months, but without a specific syntax.»
Я по-прежнему не знаю, для чего нужны лямбда-выражения.
«programming in a multicore environment» пишут они.
А какая связь между синтаксисом и железом? Где они там синхронизационные примитивы впихивают?
«support for writing scalable parallel programs using bulk-data APIs such as parallel arrays» пишут они.
Казалось бы, какая связь между синтаксисом анонимных методов и обработкой массивов? Там же даже синхронизация не нужна.
Может дело в автоматизации распараллеливания?
«The existing proposals are ... either too simple or too complex.
CICE only goes part-way toward making the parallel-array API easy to use,
while BGGA and FCM contain more features than are needed to address that key use case.»
Тогда об этом надо рассказывать.
2014-10-13, Maurice Naftalin, Mastering Lyambdas. Java Programming in a Multicore World (1-st Edition)
ISBN-10: 9780071829625, ISBN-13: 978-0071829625
Конечно мотивация "каждый орёл в твоей команде будет это использовать, а ты не впишешься" имеет смысл для собеседования,
но правильно ли поступают орлы? Может они все ошибаются?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я считаю, что оно нужно только для того, чтобы понтоваться, растопыривая пальцы.
Функциональное программирование часто используется именно с такой целью
Лямбда-счисление это теория на основе которой вы можете построить внятные синтаксический анализатор. Например, вычислять что угодно — тип результата, сам разультат, время, побочные эффекты, структуру самих вычислений итд.
Т.е. не просто вычислить, а еще и доказать что это будет именно так.
На основе машины Тьюринга вычислить такое не получится, она непрозрачна для таких вычислений. Все что вам может выдать машина Тьюринга это сам результат.
Вы сможете выдать кое что сверх этого, но никакими доказательствами это подкреплено не будет.
ЭФ>лямбда-выражения ЭФ>это компактный синтаксис, заимствованный из λ-исчисления, ЭФ>это анонимный (без имени) класс или метод, для передачи кода в качестве параметра в другой код. ЭФ>т.е. его "компактность" в том, что можно обойтись без имени функции.
ЭФ>но зачем изучать λ-синтаксис, если ЭФ>в реальности используется другой синтаксис — синтаксис языка программирования? ЭФ>Сдаёшь на собеседование знание λ-исчисления, а потом никогда, никогда это не используешь в работе.
IMHO, лямбды в C#/Java это синтаксический сахар. Конечно можно передавать функцию как параметр в виде объекта, реализующего некий интерфейс и обходится без всяких лямбд.
Как оно изначально в Java и было (плюс возможность создавать анонимные классы). В C# делегаты — тоже на мой взгляд лишняя сущность.
На практике основную пользу от лямбд я вижу в захвате контекста. Т.е. видимость локальных переменных метода и членов класса.
В случае класса-обёртки контекст пришлось бы передавать "вручную".
Отмечу, что в Java захват контекста работает по-другому чем в C#.
Вот пример темы, где обсуждается задача, где применяются лямбды, и сравниваются возможности Java и C#: https://rsdn.org/forum/java/8360114?tree=tree
ЭФ>Мне "для понимания темы" нехватает каких-то общих соображений.
ЭФ>Если я не пишу пользовательский интерфейс, то зачем мне "асинхронное программирование"?
Странный вопрос. Любые CPU/IO-bound операции в идеале должны иметь возможность прерывания.
IO-bound операции не должны требовать создания тяжеловесных потоков.
Впрочем в Java некоторое время назад реализовали virtual threads.
Подробнее обсужали тут: https://rsdn.org/forum/philosophy/8521125?tree=tree
Т.е. это абсолютно не обязательно UI, а например веб-сервер.
ЭФ>Если я знаю, что такое "замыкания", как мне это поможет? Мне чихать на yield, я им всё равно не пользуюсь.
А не важно, что ты этим не пользуешься. Тебе может достаться на поддержку код, где всё это есть в избытке.
ЭФ>Без этих "общих соображений" у меня нет мотивации к изучению.
Здравствуйте, Эйнсток Файр, Вы писали:
M>> Тебе может достаться на поддержку код
ЭФ>Мне не может достаться на поддержку код. Потому что это означает, что уволили человека, который его разрабатывал. А зачем мне такой руководитель, который успешных разработчиков увольняет? Если же разработчик не был успешным, значит и код плохой, и его надо переписать =)
Так у нас же не Япония, где работают от поступления до самой смерти в одном месте. Кстати говоря, программистам рекомендуется менять место работы раз в 3-5 лет, чтобы не заржаветь и не стать разработчиком одного продукта.
Так что программист может и сам уйти
LVV>>- о несоответствия архитектуры фон Неймана лямбда-исчислению (функциональное программирование) V>Скорее, гарвардская архитектура не соответствует, но её можно рассматривать как фон-неймановскую на этапе, когда писать в часть "ленты" уже не требуется. V>А так-то абстракция стек-машинки вполне ложится на лямбда-исчисление. V>(разве что размеры стека ограничены, ну да раскрутка хвостовой рекурсии в помощь)
Да, конечно.
Просто давно это было, и я подзабыл, что в серии МО ЭВМ выходила книжка по функциональному программированию
Там и описывалась стек-машина, на которой все работало.
НО это было еще в СССР и я тогда не сильно интересновался ФП. LVV>>- о том, что руководство МИТ следует моде V>Вернее, исходит из того, что есть. V>Бо на сейчас нет адекватных языков для начала обучению программированию от слова совсем.
На мой взгляд есть, как минимум 2 языка для обучения
1. Оберон
2. Go
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Privalov, Вы писали:
P>Я суперкомпьютеров не видел. Зато начинал на ЕС ЭВМ сменным инженером. Шумные — да. Особенно когда АЦПУ работают. Громоздкие — возможно. В шкафу памяти на ЕС-1033 можно было поспать. Память, правда, была не ферритовых сердечниках. ЕС-1036 была намного компактнее. P>Но пыльные... Категорически не согласен. В машзал мы всегда заходили в халатах. У меня был синий. И я упоминал как-то: однажды я пинками выгнал из зала взвод курсантов, которых на наш ВЦ на экскурсию привели, и они пытались зайти в зал в шинелях. А диски в отдельной зоне вообще стояли. P>Неужели суперкомпьютеры пыли не боятся?
Я в СССР поработал немного оператором ЭВМ на СМ-4. В машзал мы заходили покурить. Потому что кроме нас туда никто не заходил.
Здравствуйте, LaptevVV, Вы писали:
V>>Бо на сейчас нет адекватных языков для начала обучению программированию от слова совсем. LVV>На мой взгляд есть, как минимум 2 языка для обучения LVV>1. Оберон
Без обид, но Алгол/Паскаль выглядели сильно устаревшими уже когда я учился на первом курсе ВУЗ-а в 89-м.
Единственное преимущество Паскаля было в наличии среды Турбо-Паскаля, где компиляция-запуск были мгновенны в сравнении с другими более-менее приличными языками.
Сегодня этот фактор нивелирован.
Я рассмотрел модернизированный Фортран стандартов 2008 и 2018 — официально эти стандарты так и не вышли.
В общем, язык избавили от атавизмов/неудобств, на которые пеняли последние лет 40, теперь это вполне себе несложный и достаточно удобный + безопасный язык для начала обучения программированию, а так же для реализации произвольных расчётов/матана.
Будь моя воля, я бы голосовал за шлифовку и выпуск современных стандартов этого легендарного языка с последующим возвращением его в "обойму" мейнстрима.
LVV>2. Go
Этот сильно нишевый.
Для обучения хотелось бы нейтральный, у которого будет поменьше возникающих у адекватного новичка "WTF???" ))
Здравствуйте, Pzz, Вы писали:
Pzz>Я в СССР поработал немного оператором ЭВМ на СМ-4. В машзал мы заходили покурить. Потому что кроме нас туда никто не заходил.
Противоожарная система сработать могла. У нас один раз такое случилось. Два этажа затопило углекислым газом, еле успели убежать.
С курением у нас было строго. В здании ВЦ не курил никто.
Здравствуйте, vdimas, Вы писали:
V>Я рассмотрел модернизированный Фортран стандартов 2008 и 2018 — официально эти стандарты так и не вышли.
Я его мелбком видел, что-то не зашло. Вероятно потому, что я привык к Фортрану 77 (стандарт 90 или 95).
V>В общем, язык избавили от атавизмов/неудобств, на которые пеняли последние лет 40, теперь это вполне себе несложный и достаточно удобный + безопасный язык для начала обучения программированию, а так же для реализации произвольных расчётов/матана.
То есть сломали обратную совместимость? Выходит, проект, который я перенёс когда-то с ЕС на PC, новым Фортраном не откомпилируется? Я не говорю про мегатонны софта, проверенного временем и отлично работавшего на различном железе в различных ОС.
V>Будь моя воля, я бы голосовал за шлифовку и выпуск современных стандартов этого легендарного языка с последующим возвращением его в "обойму" мейнстрима.
У Фортрана (того, на котором я работал) я вижу один недостаток: отсутствие зарезервированных слов. Иногда это приводило к весьма забавным эффектам.
Ну да, у него динамических структур данных не хватало. Приходилось выкручиваться.
Здравствуйте, Alekzander, Вы писали:
V>>Я пока не вижу достаточно удачного языка для начала обучения программированию. A>Ни на какие мысли не наводит? A>Концепция "ЯП для начала обучения программированию" настолько порочна, и в стольких отношениях... Надо ли перечислять?
Наоборот. ))
Это раньше языки, пригодные для начала обучению и работы на ём же были примерно одинаковы или они же и были, из-за убогости аппаратных ср-в и работающих поверх них простейших компиляторов.
Сейчас мейнстримовые языки шагнули далеко вперёд, реализуют кучи концепций.
Даже "обычный Си" уже засорён тонкостями по самое нимогу.
Да и, это системный язык.
Я рядом высказывался по осовременненому Фортрану.
Ничего более адекватного современному состоянию IT я пока мест не вижу.
(Да, рекурсию в нём сделали, переменную функционального типа сделали, синтаксис почистили)
Здравствуйте, vdimas, Вы писали:
V>>>Я пока не вижу достаточно удачного языка для начала обучения программированию. A>>Ни на какие мысли не наводит? A>>Концепция "ЯП для начала обучения программированию" настолько порочна, и в стольких отношениях... Надо ли перечислять?
V>Наоборот. ))
V>Это раньше языки, пригодные для начала обучению и работы на ём же были примерно одинаковы или они же и были, из-за убогости аппаратных ср-в и работающих поверх них простейших компиляторов.
V>Сейчас мейнстримовые языки шагнули далеко вперёд, реализуют кучи концепций. V>Даже "обычный Си" уже засорён тонкостями по самое нимогу. V>Да и, это системный язык.
То есть, всё-таки надо? )
Во-первых, эта концепция преувеличивает роль ЯПов в реальной разработке. Можно вообще не знать ни один ЯП и быть востребованным алгоритмистом. В детстве, помню, всё мечтал разбогатеть и нанять на полставочки старушку-учительницу, преподававшую мне математику. Помогать мне движок пилить. Заворачивать кватеринионы в сишку я бы и сам смог, ума много не надо.
Во-вторых, у ЯП есть *выразительность* (применительно к домену). Для языка это альфа и омега. Если ЯП выразителен, он хорошо подойдёт и для обучения, и для профессионального использования. А если нет — он плохо годится для чего угодно. (Под "профессиональным" я подразумеваю "как для себя", т.е. для фрилансера. Впаривать работодателю говноязык, в котором никто, кроме тебя не разберётся — это тоже профессионально, но мы сейчас не об этом).
В-третьих, в каждом домене будет свой идеал выразительности ЯП, и все выразительные ЯПы в разных доменах будут очень непохожи. В процессинге текстов выразительно, когда текст программы без операторов превращается сам в себя (PHP), а в разработке драйверов совсем другие ценности. Так что, в каждом домене свой "детский" ЯП стряпать? Baby-SQL, Baby-FP, Baby#?
В-четвёртых, обучение программированию включает в себя обучение выбору адекватных инструментов. То есть, тех же ЯПов. Для обучения программированию надо предложить самому выбрать правильный язык для написания лендинга. Или драйвера. Этот важный этап часто пропускают, а в результате обучаемый превращается в шымжу: знает десять языков и не имеет ни малейшего представления, где их применять. Пелевин так выучил ассемблер x86. Но это не мешает ему сочинять совершенно мудацкие пассажи про RCP-программирование.
В-пятых, человек, которому не объяснили, что в каждом ЯПе свои плюсы и минусы, что это как набор отвёрток для разных ситуаций, вырастает законченной бестолочью и потом всю жизнь страдает от утиного эффекта. Спрашивает, например, зачем нужны лямбды. Разве код с лямбдами выполняется быстрее? Нет? Ну и не нужны!
В-шестых... можно ещё долго продолжать, только зачем.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Я считаю, что оно нужно только для того, чтобы понтоваться, растопыривая пальцы.
А я вот соглашусь. Понтующихся теоретиков CS с лямбда-исчислением и особенно теоркатом видел много, а вот практического применения не видел.
Как обычно, надо различать науку и инженерию. В инженерном деле 99% знаний полезно для айтишника, в науке 99% знаний мертворожденные и нужны только для генерации новых знаний, ничтожная часть которых доберется до инженеров.
Здравствуйте, Alekzander, Вы писали:
A>В-пятых, человек, которому не объяснили, что в каждом ЯПе свои плюсы и минусы, что это как набор отвёрток для разных ситуаций, вырастает законченной бестолочью и потом всю жизнь страдает от утиного эффекта. Спрашивает, например, зачем нужны лямбды. Разве код с лямбдами выполняется быстрее? Нет? Ну и не нужны!
Ну... не скажи.
Даже в весьма далёких друг от друга, на первый взгляд, языках, таких как Си, Паскаль и Фортран приличная часть кода, представляющая некие целевые вычисления, может быть похожа или в точности идентична — это я про математические выражения с переменными, в т.ч. переменными составных типов — структурами, при доступе к полям структур.
А так же все три языка поддерживают в том или ином виде функциональный тип хотя бы в минимальном виде — в виде указателей на ф-ии, т.е. поддерживают косвенный вызов ф-ий, что позволяет использовать инструмент абстракций даже еще безо-всякого встроенного в язык ООП. Вернее, оно даже показывает проблематику, которую затем более полно решает ООП.
A>В-шестых... можно ещё долго продолжать, только зачем.
Ну да, есть еще функциональное программирование, которое предоставляет абстрагирование с чуть другим размером гранулы — абстракция описывает не кортеж ф-ий, как в ООП, а одну абстрактную ф-ию. Ну, или класс их (таки, именованный кортеж ф-ий, принадлежащих классу-интерфейсу), как в Хаскеле, и тогда мы получаем ООП в профиль... Да и унутре сильно похожая реализация как в классическом ООП. ))
Здравствуйте, Privalov, Вы писали:
P>То есть сломали обратную совместимость?
Не, старый код компиллируется.
V>>Будь моя воля, я бы голосовал за шлифовку и выпуск современных стандартов этого легендарного языка с последующим возвращением его в "обойму" мейнстрима. P>У Фортрана (того, на котором я работал) я вижу один недостаток: отсутствие зарезервированных слов. Иногда это приводило к весьма забавным эффектам. P>Ну да, у него динамических структур данных не хватало. Приходилось выкручиваться.
Там много чего раздражало с т.з. современных компиляторов и наработанных практик.
Наследование структур, типобезопасные указатели на базовую структуру, информация о типах:
type :: vec_type
real :: x, y
end type vec_type
type, extends(vec_type) :: vec3_type
real :: z
end type vec3_type
type, extends(vec3_type) :: color_type
integer :: color
end type color_type
type(vec_type), target :: v
type(vec3_type), target :: v3
type(color_type), target :: c
class(vec_type), pointer :: ptr
v = vec_type(1.0, 2.0)
v3 = vec3_type(1.0, 2.0, 3.0)
c = color_type(0.0, 1.0, 2.0, 9)
! Point to either v, v3, or c:
ptr => c
select type (a => ptr)
class is (vec_type)
print *, a%x, a%y
type is (vec3_type)
print *, a%x, a%y, a%z
type is (color_type)
print *, a%x, a%y, a%z, a%color
end select
Implied do
(имеется ввиду т.н. "подразумеваемая" разновидность цикла do)
integer :: values(10) = [ (i * 2, integer :: i = 1, 10) ]
Массив values будет содержать 2, 4, ..., 20
do concurrent
integer :: i
real :: a(100)
do concurrent (i = 1:size(a))
a(i) = sqrt(i**i)
end do
Для вычисления в параллель итогов используется reduce(function, variable)
integer :: i
real :: a, x(n)
a = 0.
do concurrent (i = 1:n) reduce(+:a)
a = a + x(i)**2
end do
Вместо '+' могла быть некая пользовательская ф-ия.
Enumeration types
enumeration type :: colour
enumerator :: red, orange, green
end type
type(colour) light
if (light==red) ...
An enumerator may be accessed as an ‘enumeration constructor’ through its position in the type
declaration. For example colour(2) has the value orange. This allows the enumerators to be
accessed in a do loop such as:
do i = 1,3
light = colour(i)
:
end do
select case (light)
case (red)
:
case (orange:green)
:
end select
Для целей интероперабельности с Си есть такая форма:
enum, bind(c) :: season
enumerator :: spring=5, summer=7, autumn, winter
end enum
type(season) my_season, your_season
my_season = spring
your_season = autumn+1 ! winter
Импорт внешних ф-ий
! usleep.f90
module posix
use, intrinsic :: iso_c_binding
private
public :: c_usleep
interface
! int usleep(useconds_t useconds)
function c_usleep(useconds) bind(c, name='usleep')
import :: c_int, c_int32_t
implicit none
integer(kind=c_int32_t), value :: useconds
integer(kind=c_int) :: c_usleep
end function c_usleep
end interface
end module posix
program main
use :: posix
integer :: i, rc, t
t = 500 * 1000 ! 500 milliseconds
do i = 1, 10
print '("zzz ...")'
rc = c_usleep(t)
end do
end program main
Юникод
! unicode.f90
program main
use, intrinsic :: iso_fortran_env, only: output_unit
implicit none
integer, parameter :: ucs2 = selected_char_kind('ISO_10646')
character(kind=ucs2, len=:), allocatable :: str
str = ucs2_'Unicode character: \u263B'
open (output_unit, encoding='utf-8')
print '(a)', str
end program main
Еще видел реализацию Фортрана в LLVM и wasm, которая предлагает так же синтаксис одновременного объявления и присвоения значений переменным, что делает код еще более выразительным.
Есть атомарные операции, есть указатели (но с "осторожной" адресной арифметикой, что оставляет меньше простора для ошибок), есть активная работа над языком.
Причём, я вижу сплошной здравый смысл, натурально "с языка снимают" — что раздражало в Фортране всю дорогу, то сейчас и причёсывают. ))
Плюс возможность установить дефлотный режим 'implicit none' для компилятора, чтобы еще больше почистить сырцы.
При этом легаси код можно компилять с опцией 'implicit'.
В общем, там много ума не надо, чтобы увидеть, как это стоит делать по-уму.
Здравствуйте, vdimas, Вы писали:
V>Не, старый код компиллируется.
Уже хорошо. На Фортране столько прикладной математики сделано, что переписывать её на чём-то другом во-первых затратно, а во-вторых, всё будет хуже, чем на Фортране. Я когда-то пробовал на Сях. Не понравилось. Опять же, у математиков свой стиль, начиная от именования переменных. Постороннему покажется полным бредом. И вникать в низкоуровневые вещи им незачем. Только мешает над задачей сосредоточиться.
V>Там много чего раздражало с т.з. современных компиляторов и наработанных практик.
Поэтому и литературы было больше на тему "Грабли в Фортране", а не "Фортран для чайников". И как-то мы эти грабли автоматом обходили.
Например, за беспорядочное использование COMMON-блоков надо руки отрывать.
V>Arithmetic if V>
V>if (x * y) 100, 200, 300
V>
Я эту конструкцию использовал, чтобы GOTO не писать лишний раз. V>Logical if V>
V>if (x * y < 0) y = 1
V>
На Фортране привычнее писать .EQ., .LT., .LE. и т.д.
V>Block if
Появился в Fortran 77. Облегчил мне жизнь. Но старшие товарищи, привыкшие к Fortran 4, продолжали писать арифметический if или if ... goto.
V>Expressional if
С этим не сталкивался.
V>Select switch
Это успел попробовать.
V>Наследование структур, типобезопасные указатели на базовую структуру, информация о типах:
А всё, что было дальше, я не знаю. Впрочем, имея навык программирования на Фортране, схватить новинки вряд ли такая уж сложная задача. Единственный момент: мне почему-то было сложно читать свободный формат. Привык к фиксированному.
V>В общем, там много ума не надо, чтобы увидеть, как это стоит делать по-уму.
Признаться, я и на Шарпе сейчас пишу, как когда-то на Фортране. И иногда жалею, что ушёл из НИИ, где почти всё было на Фортране.
Здравствуйте, Privalov, Вы писали:
V>>Logical if V>>
V>>if (x * y < 0) y = 1
V>>
P>На Фортране привычнее писать .EQ., .LT., .LE. и т.д.
ИМХО, переносимость сниппетов в исходниках порой помогает.
Я периодически переношу наработки с плюсов в шарп и обратно, к примеру — это экономит усилия.
V>>Expressional if P>С этим не сталкивался.
Полезная новая фича, особенно для ссылочных аргументов, т.к. позволяет ветвиться прямо в одном вызове ф-ии/процедуры, а не прописывать комбинаторику раздельных вызовов для всех комбинаций параметров.
P>А всё, что было дальше, я не знаю. Впрочем, имея навык программирования на Фортране, схватить новинки вряд ли такая уж сложная задача.
Да.
Всё это является хорошо опробованными ср-вами в других императивных и мультипарадигменных языках.
Т.е., будет выглядеть знакомо программисту с другого языка и обратно тоже верно — студент будет видеть знакомое в других языках императивной обоймы после освоения осовременненого фортрана.
P>Признаться, я и на Шарпе сейчас пишу, как когда-то на Фортране. И иногда жалею, что ушёл из НИИ, где почти всё было на Фортране.
У Шарпа сложная судьба. ))
С одной стороны, он должен был стать безопасным инструментом для разработки бизнес-приложений (именно их, вместо VB/VBA/VBS и прочих убогих жаб).
С другой стороны, они сделали его языком, в котором можно наиболее полно задействовать фичи платформы, внеся тем самым в язык приличную долю небезопасности и местами даже противоречивости.
ИМХО, надо было, таки, делать два разных языка, а не два в одном...
Здравствуйте, Alekzander, Вы писали:
A>Я не настолько стар, чтобы помнить Фортран, а Си и Паскаль это две попытки в одном и том же... роду? семействе?.. (оба императивные, процедурные, статически типизированные, компилируемые, нативные) с разных сторон приблизиться к лучшей выразительности, про которую шла речь в п.2. Что выразительнее — закорючки или слова? А в остальном это одно и то же.
Таки, Фортран предоставляет более безопасные конструкции при той же выразительности в оперировании массивами.
Где в плюсах необходимо задействовать уже библиотечный код ради безопасности исходника, в Фортране зачастую хватает встроенных ср-в.
Т.е., случайно наступить на грабли в том же С/С++ всяко проще.
A>Вот уж не думаю, что указатели на функции делают Си функциональным "хотя бы в минимальном виде". Си тупо отражает устройство железа, а железо просто поддерживает адресацию кода (по заветам фон Неймана). Нужно, всё-таки, гражданство первого класса, а это и инлайнинг выражений, и поддержка со стороны стандартной библиотеки.
Лямбды в С++ уже есть, и они успешно инлайнятся.
Но это уже более высокоуровневый инструмент, который не всегда даёт максимум эффективности.
Т.е. эффективное оперирование указателями на ф-ии (особенно таблицами таких указателей с целью диспетчеризации) еще никто не отменял. ))
Здравствуйте, vdimas, Вы писали:
P>>На Фортране привычнее писать .EQ., .LT., .LE. и т.д.
V>ИМХО, переносимость сниппетов в исходниках порой помогает.
А порой мешает. Я уже писал как-то: делал JNI, и иногда терялся, сейчас у меня java открыта или C. Причём там сложного не было ничего: я какую-то обёртку для вызова WinAPI делал. А когда сишные модули к Фортрану подключал, всё было прекрасно. В одной среде два совершенно разных языка не спутаешь.
V>Полезная новая фича, особенно для ссылочных аргументов, т.к. позволяет ветвиться прямо в одном вызове ф-ии/процедуры, а не прописывать комбинаторику раздельных вызовов для всех комбинаций параметров.
Дак у Фортрана всегда были ссылочные аргументы. Передача по значению появилась в F77, не знаю точно в какой версии. При объявлннии нужно было атрибут VALUE указывать. Примерно тогда же, кстати, у Фортрана появились автоматические переменные (атрибут AUTO). Но аксакалы пользовались им редко. Потому что привычка у них была вызывать подпрограммы, которые что-то знают. В том смысле, что значения статических переменных никуда не исчезают при выходе из подпрограммы и могут быть использованы про повторном вызове.
V>Т.е., будет выглядеть знакомо программисту с другого языка и обратно тоже верно — студент будет видеть знакомое в других языках императивной обоймы после освоения осовременненого фортрана.
Фортран в первую очередь — переводчик формул. И прекрасно с этим справляется.
V>У Шарпа сложная судьба. ))
Я не о судьбе. Я не особо использую всякие новомодные конструкции.
Когда-то я знал одного дядьку, вынужденного перейти с Фортрана на Паскаль. Он при написании программ использовал фортрановский стиль кодирования. Я об этом.
V>>>Бо на сейчас нет адекватных языков для начала обучению программированию от слова совсем. LVV>>На мой взгляд есть, как минимум 2 языка для обучения LVV>>1. Оберон V>Без обид, но Алгол/Паскаль выглядели сильно устаревшими уже когда я учился на первом курсе ВУЗ-а в 89-м. V>Единственное преимущество Паскаля было в наличии среды Турбо-Паскаля, где компиляция-запуск были мгновенны в сравнении с другими более-менее приличными языками. V>Сегодня этот фактор нивелирован.
Нет. BlackBox Component Builder — поинтересуйся всерьез, без предвзятости типа "старье". LVV>>2. Go V>Этот сильно нишевый.
Для начального обучения — прекрасный язык.
Самое важное качество: статически типизированный и нет преобразований по умолчанию.
И снова скажу: язык для начального обучения и промышленный язык — не должны быть одним и тем же языком.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Нет. BlackBox Component Builder — поинтересуйся всерьез, без предвзятости типа "старье". P>Вот мне после Фортрана Паскаль не зашёл вообще. Я за всю жизнь написал на нём всего одну программу на 3-м курсе. И ту до ума не довёл.
А мне все заходило, на чем приходилось работать.
И даже кое-что, что изучать приходилось...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>А мне все заходило, на чем приходилось работать. LVV>И даже кое-что, что изучать приходилось...
Дак в том-то всё и дело, что на Паскале мне работать не пришлось. Чего я за него в вузе взялся, я уже не помню. А реально я довольно много имел дело с Фортраном. И в вузе, и потом. Я всё больше на ЕС, а Паскаль был, ЕМНИП, на Электронике 100/25. К которой я никаким боком.
Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>Я считаю, что оно нужно только для того, чтобы понтоваться, растопыривая пальцы. ЭФ>Существуют математики, существуют программисты.
любой язык программирования по сути использует лямбда исчисление — аппликация и бета-редукция,
и этому учат в школе на математике
ничего сложного в этом нет, обычная подстановка аргумента в функцию и её вычисление
Здравствуйте, vdimas, Вы писали:
V>Без обид, но Алгол/Паскаль выглядели сильно устаревшими уже когда я учился на первом курсе ВУЗ-а в 89-м. V>Единственное преимущество Паскаля было в наличии среды Турбо-Паскаля, где компиляция-запуск были мгновенны в сравнении с другими более-менее приличными языками.
Ну так мне и до сих пор непонятно, какой диверсант распространил раннюю кривую версию разработки (под именем "Pascal") вместо более современных — хотя бы семейства Modula.
Хотя это больше похоже на естественный процесс.
Но только с опытом разработки чего-то большого и поиска багов начинаешь понимать, чем подходы Pascal-с-компанией лучше переносимого ассемблера C.
V>Я рассмотрел модернизированный Фортран стандартов 2008 и 2018 — официально эти стандарты так и не вышли.
Ну всё-таки основа очень устаревшая. Из-за этого куча проблем начиная с синтаксиса.
vsb>Поэтому я может ставить на этот вариант развития событий и не буду, может быть для ИИ проще написать сто тестов, чем одну программу. Но в целом не слишком удивлюсь, если завтра GPT 5 выпустят с модулем программирования на хаскеле, который будет на голову выше всех остальных альтернатив.
Только не на Хаскеле, а на верифицируемых языках. А так всё верно, ещё год назад писал
Здравствуйте, netch80, Вы писали:
N>Ну так мне и до сих пор непонятно, какой диверсант распространил раннюю кривую версию разработки (под именем "Pascal")
Вирт, вестимо.
Его язык "Паскаль" — это один в один Алгол, над которым он работал в кач-ве соавтора.
Вирт исключил оператор goto из Алгола и еще всякой специфики по мелочи, с целью создать более "чистый" язык для обучения программированию.
А так-то это один и тот же язык, считай.
N>вместо более современных — хотя бы семейства Modula.
Дык, он же, Вирт, разработал Модулу-2 на ~20 лет позже.
Чуть более выразительный и чуть более строгий синтаксис.
В отличие от Паскаля, этот язык позиционировался для профессиональной разработки, а не обучения.
Классический пример.
Модула-2:
CASE i OF
2: StatementListl
3..5: StatementList2
2*3: StatementList3
ELSE StatementList4
END
Паскаль:
IF (i>0) AND (i<5) THEN
BEGIN
CASE i OF
2: BEGIN StatementListl END ;
3: BEGIN StatementList2 END ;
4: BEGIN StatementList2 END ;
5: BEGIN StatementList2 END ;
6: BEGIN StatementList3 END
END(* case *)END
ELSE
BEGIN
StatementList4
END(* if *)
N>Но только с опытом разработки чего-то большого и поиска багов начинаешь понимать, чем подходы Pascal-с-компанией лучше переносимого ассемблера C.
Чистый Си — он как переносимый ассемблер, верно.
Но плюсы, при том что бесят во многих мелочах, дали, в сравнении с Паскалем, банальную выразительность и заметную экономию времени.
Я где-то в 92-94-м плотно использовал в параллель плюсы и Паскаль (до этого в параллель чистый Си и Паскаль), потом только плюсы и VB/VBA (потому что через COM было удобно сопрягать, бо в плюсах пишешь что-то неординарное, что на VB задолбаешься программировать, а в качестве скрипта-клея и для GUI-формочек использовать VB было самое то).
В 96-97 г опять слегка поюзал Паскаль в его объектной версии в Дельфи, бо формочки легко сопрягались с кодом, собранным Борланд С++, но как только вышел первый приличный MS Visual C++ 5-й версии — ну это было уже всё. ))
Наконец-то под Windows появился более-менее терпимый компилятор плюсов и можно было вздохнуть свободно, как грится, а не выкручиваться каждый божий раз, сопрягая ужа с ежом.
Хотя 5-й С++ и лажал еще в частичной специализации шаблонов, но тогда вообще в природе не существовало идеального С++-компилятора, а тот же gcc отставал безбожно в 90-е, это почему GNU/Linux настолько поздно стали задействовать С++ — из-за отсутствия под руками нормального компилятора.
И почему кросс-разработка для меня в те годы была болью — из-за разночтений компиляторами кода и вообще не всегда пересекающимися подмножествами поддерживаемых конструкций.
MSVC 6.0 затем стал уже просто классикой, окончательно убив примерно пяток конкурентов под виндами, тот же Watcom.
На 6.0 писали много и долго, потому что MSVC 7.0 был глючным, дык, мы подменяли в среде Visual Studio компилятор (оно ж настраивается), они исправили глюки позже в MSVC 7.1.
В общем, по сравнению с нынешней офигенно высокой совместимостью кода для разных компиляторов С++, тогда это было сродни бегу по горячим углям.
И всё-равно, несмотря на все трудности (в сравнении с уютными Дельфи или VB/VBA), плюсы давали прочто чудовищный профит в экономии времени и вообще отдачи от вложенных усилий. Да и, многие задачи всё-равно только на них можно было решить.
Поэтому, проблема не в плюсах конечно, ругать плюсы за их недостатки более чем бесполезно.
Проблема обитает в альтернативах, которых приличных тупо нет.
Вон Rust пытается, но на сегодня даже еще не определились — так будет у них модель исключений или нет, ни за что и никогда? ))
Язык D был неплохой альтернативой, но они там налажали с миксинами и слишком убежали от совместимости в сниппетах с С++.
Всего-то требовалось слегка почистить С++, убрать опасные конструкции из "первой линии доступа", сразу же сделать подмножество SafeD.
Но ребята малость увлеклись и просрали полимеры, увы...
V>>Я рассмотрел модернизированный Фортран стандартов 2008 и 2018 — официально эти стандарты так и не вышли. N>Ну всё-таки основа очень устаревшая. Из-за этого куча проблем начиная с синтаксиса.
О, нет.
Именно почистили синтаксис, сделали его выразительным.
Многословность синтаксиса там начинается, когда ты передаёшь в кач-ве аргумента, допустим, in-ссылку на массив указателей-указателей (раньше такого вообще было нельзя) и пишешь результат в out-ссылку на другой такой же массив.
Но! При всей многословности таких описаний, у них зато не может быть трудности разночтений, типа как в плюсах — спроси новичка что означают эти кракозябры:
template<size_t N>
int f(some_t ** const (&arg)[N]) {}
Здравствуйте, vdimas, Вы писали:
N>>Ну так мне и до сих пор непонятно, какой диверсант распространил раннюю кривую версию разработки (под именем "Pascal")
V>Вирт, вестимо. V>Его язык "Паскаль" — это один в один Алгол, над которым он работал в кач-ве соавтора.
Нет, различий достаточно много. Начиная с синтаксиса. У Алгола он значительно кривее.
V>Вирт исключил оператор goto из Алгола и еще всякой специфики по мелочи, с целью создать более "чистый" язык для обучения программированию. V>А так-то это один и тот же язык, считай.
N>>вместо более современных — хотя бы семейства Modula.
V>Дык, он же, Вирт, разработал Модулу-2 на ~20 лет позже.
Путаешь. Паскаль — 1970. Модула-1 — 1975. Модула-2 — 1978. 20 лет там нет.
Вполне можно было уже вместо трубопоскакаля в 80-х сделать что-то более полезное.
cvsup был написан на Модуле-3 и был на каждой BSD до примерно 2003.
V>Чуть более выразительный и чуть более строгий синтаксис. V>В отличие от Паскаля, этот язык позиционировался для профессиональной разработки, а не обучения.
Но и для обучения он неплох.
Когда я был школоло, мне эта дисциплина их линии ой не нравилась.
Но постепенно начал понимать, чем она хороша.
Проблема в том, что до 20-25 мы почти все такие школоло. Сейчас для таких есть питон и прочая. Тогда — не было.
[skip воспоминания, тут почти полностью согласен]
V>Поэтому, проблема не в плюсах конечно, ругать плюсы за их недостатки более чем бесполезно. V>Проблема обитает в альтернативах, которых приличных тупо нет. V>Вон Rust пытается, но на сегодня даже еще не определились — так будет у них модель исключений или нет, ни за что и никогда? )) V>Язык D был неплохой альтернативой, но они там налажали с миксинами и слишком убежали от совместимости в сниппетах с С++. V>Всего-то требовалось слегка почистить С++, убрать опасные конструкции из "первой линии доступа", сразу же сделать подмножество SafeD. V>Но ребята малость увлеклись и просрали полимеры, увы...
Всё равно они все отнимают ниши у C и C++. И это достаточно правильно.
Я писал недавно — в двух последних проектах, где активно был C++, он там был просто не нужен. Оптимумом был бы Go, и разработка шла бы в разы быстрее и проще.
Но кто-то наверху считал, что если это формально embedded (с ARM/64 и 4-8GB рамы, ага), то ничего кроме сей не катит.
И таких в индустрии вагоны с тележками.
V>В Фортране каждый аргумент подробно описывается.
Про Фортран пока пропущу (может, потом вернусь к).
Здравствуйте, netch80, Вы писали:
V>>Вирт, вестимо. V>>Его язык "Паскаль" — это один в один Алгол, над которым он работал в кач-ве соавтора. N>Нет, различий достаточно много. Начиная с синтаксиса. У Алгола он значительно кривее.
Сама суть языка, способ организации программы, способы объявления и реализации перечислимых множеств, составных типов, массивов, процедур и функций — всё идентично, считай.
Различия синтаксиса косметические, требуют от программиста максимум часа-другого привыкания и далее пошёл как по знакомому. ))
V>>Дык, он же, Вирт, разработал Модулу-2 на ~20 лет позже. N>Путаешь. Паскаль — 1970.
Фактически он его разрабатывал с 68-го.
N>Модула-1 — 1975. Модула-2 — 1978. 20 лет там нет.
Да, десяток лет, конечно.
N>Вполне можно было уже вместо трубопоскакаля в 80-х сделать что-то более полезное.
Модулу-2, например.
Вполне возможно, что на момент начала разработки Турбо-Паскаля Модулы-2 еще не было.
И еще возможно, что Турбо-Паскаль не позиционировался изначально как "серьёзный" язык — не зря же взяли учебный Паскаль?
Выглядит так, что результат получился намного лучше, чем планировали изначально. ))
Реально крутую среду по тем временам сделали.
И Турбо-С затем — все сишники тех лет через него прошли.
N>cvsup был написан на Модуле-3 и был на каждой BSD до примерно 2003.
Ну...
Как появился Оберон, в курсе?
Вот так же и Модула-3.
Т.е., алголоподобные языки (Паскаль и Модулу-2) стали пытаться использовать для низкоуровневой и эффективной разработки.
И сразу всплыла необходимость доработки этих языков.
Вирт выкатил доработанный Паскаль/Модулу-2 — Оберон, с целью написания одноимённой операционной системы.
Ему пришлось сделать индексацию массивов только от 0-ля (убрав произвольную индексацию, в т.ч. индексацию перечислимыми типами), убрал тормознутые паскалевские множества и еще всякого почистил.
Ну и, ввел автоматическую сборку мусора у динамически-выделяемых объектов.
В любом случае, проблема этого семейства языков (включая Object Pascal) очевидна — отсутствие хорошей совместимости, при том, что языки одного семейства.
Т.е. каждая версия языка — это как другой язык, хотя для программиста зачастую — вид в профиль.
Причём, обеспечить совместимость можно было через механизм некоего obsolete, плюс ключи компиляции и прочее такое...
Но Вирт и Ко поставили во главу угла миниатюрность и эффективность компилятора, за что и поплатились "работой в стол".
И это самый важный урок из всей этой истории...
Реально, если бы приоритет совместимости был выше, если бы не вылизывали сам компилятор, а подержали им семейство диалектов, как это делают компиляторы С++ — история с этим семейством могла быть совсем иной.
Например, новые версии Фортрана, хотя резко почистили синтаксис (вернее, ввели более чистую альтернативу или сократили излишнюю многословность), запросто умеют компилять старый код.
Например, объявление переменной одновременно с её инициализацией значением — удобная фича, но старый вариант тоже прокатывает.
N>Проблема в том, что до 20-25 мы почти все такие школоло. Сейчас для таких есть питон и прочая. Тогда — не было.
ХЗ.
Нам, системщикам/железячникам, приходилось много упражняться на асме тогда, поэтому тонкости ЯВУ волновали не сильно.
У меня в обойме одновременно был Паскаль, Си, С++, Форт, VB/VBA, изредка Фортран (когда готовые расчёты уже есть, но надо чуть допилить), MatLab (это, в первую очередь, язык программирования, а не среда — бо писать расчётные утилиты на ём и консольные было удобно).
Не могу сказать, что были какие-то особые предпочтения в те года, бо плюсов и минусов везде хватало.
Банально брал, что удобнее.
Для парсинга и прочих DSL удобней был Форт (свой ASM-51 на нём как-то за рабочий день сделал, вместе с программой для закачки образа в эмулятор ПЗУ — ни на каком другом тогдашнем языке это принципиально было невозможно, да и сейчас тоже).
Для любых расчётных утилит ничего удобнее MatLaba (как языка) не существовало.
По-быстрому наваять формочки — да какой в опу Дельфи, на VB это было быстрее раз эдак в несколько, плюс проще интероп с плюсами, из-за скриптовой натуры языка в отладочном режиме, при том что скомпилированный код был неплохо оптимизирован, особенно в деле работы с COM-объектами, что это даже заметно эффективнее было, чем пользоваться в плюсах смарт-поинтерами для них же. А если не пользоваться — то ресурсы могут утечь, либо код превращается в бесконечную лапшу проверок. VB в этом смысле был идеален. Следующий раз такое же удобство показал уже njkmrj C#. ))
С++ стал относительно неплох лишь к концу 90-х, и совсем неплох в нулевые, когда куча компиляторов стали утрясаться в совместимости вокруг C++03.
Поэтому, мне и были несколько странны обнаруженные здесь споры о языках в первой половине нулевых, да еще нападки представителей одних лагерей на другие.
Барство всё это. Позволять себе перебирать — это уже роскошь. ))
Всегда надо брать наиболее удобный инструмент.
V>>Всего-то требовалось слегка почистить С++, убрать опасные конструкции из "первой линии доступа", сразу же сделать подмножество SafeD. V>>Но ребята малость увлеклись и просрали полимеры, увы... N>Всё равно они все отнимают ниши у C и C++. И это достаточно правильно.
D мог отобрать достаточно много и да, сишники-плюсовики были отнюдь не против.
Многие рассматривали этот язык достаточно серьёзно (я тоже тратил своё время).
Какие проблемы часть кода в сишно-плюсовых проектах писать на D, если всё прекрасно линкуется-стыкуется?
Но они реально переборщили, далеко отошли от первоначальной неплохой задумки.
Искренне жаль.
Там Герб Саттер (один из главных в комитете по плюсам) пытается переосмыслить проблематику СИ-подобных языков и выкатить более выразительную и безопасную версию С++.
Пока что у него получается интересней, чем D, хотя тоже отошёл достаточно далеко от плюсов.
Но! В отличие от D, отход происходит лишь в тех местах, где нельзя не уйти для достижения тех или иных кач-в (т.е., можно принять за эдакий синтаксический сахарок), в отличие от D, где местами откровенная вкусовщина авторов.
N>Я писал недавно — в двух последних проектах, где активно был C++, он там был просто не нужен. Оптимумом был бы Go, и разработка шла бы в разы быстрее и проще.
У Go свои бока, увы. ))
Но тоже неплохой нишевый язык для несложных сервисов, которые можно вложить в механику языка.
Это более грамотный взгляд на проблематику Erlang, который в своём дизайне перебрал малость наивности-академичности. ))
(Выпороть бы авторов Erlang за загубленную неплохую идею... детсадище, блин...)
N>Но кто-то наверху считал, что если это формально embedded (с ARM/64 и 4-8GB рамы, ага), то ничего кроме сей не катит. N>И таких в индустрии вагоны с тележками.
ХЗ.
Если механика Go реально нужна, т.е. если на С++ в любом случае придётся аналогичную механику описывать, то согласен.
А если не нужна, то нафига тащить лишний рантайм?
Если требуется писать более "традиционный" код, то на плюсах можно накидать его быстрее, бо быстрее найдёшь всё готовое сегодня.
Ну и, плюсовые сборки со статическими либами (стандартными и третьесторонними) берут в образ лишь то, что реально используется.
Глядишь, и вместо 4 гиг рамы хватит 256 метров. ))
В крупных партиях это даёт ощутимый профит, ес-но.
Если нам не помогут, то мы тоже никого не пощадим.
