Здравствуйте, 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-программирование.

В-пятых, человек, которому не объяснили, что в каждом ЯПе свои плюсы и минусы, что это как набор отвёрток для разных ситуаций, вырастает законченной бестолочью и потом всю жизнь страдает от утиного эффекта. Спрашивает, например, зачем нужны лямбды. Разве код с лямбдами выполняется быстрее? Нет? Ну и не нужны!

В-шестых... можно ещё долго продолжать, только зачем.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Я считаю, что оно нужно только для того, чтобы понтоваться, растопыривая пальцы.

А я вот соглашусь. Понтующихся теоретиков CS с лямбда-исчислением и особенно теоркатом видел много, а вот практического применения не видел.

Как обычно, надо различать науку и инженерию. В инженерном деле 99% знаний полезно для айтишника, в науке 99% знаний мертворожденные и нужны только для генерации новых знаний, ничтожная часть которых доберется до инженеров.

Здравствуйте, Alekzander, Вы писали:

A>В-пятых, человек, которому не объяснили, что в каждом ЯПе свои плюсы и минусы, что это как набор отвёрток для разных ситуаций, вырастает законченной бестолочью и потом всю жизнь страдает от утиного эффекта. Спрашивает, например, зачем нужны лямбды. Разве код с лямбдами выполняется быстрее? Нет? Ну и не нужны!

Ну... не скажи.
Даже в весьма далёких друг от друга, на первый взгляд, языках, таких как Си, Паскаль и Фортран приличная часть кода, представляющая некие целевые вычисления, может быть похожа или в точности идентична — это я про математические выражения с переменными, в т.ч. переменными составных типов — структурами, при доступе к полям структур.

А так же все три языка поддерживают в том или ином виде функциональный тип хотя бы в минимальном виде — в виде указателей на ф-ии, т.е. поддерживают косвенный вызов ф-ий, что позволяет использовать инструмент абстракций даже еще безо-всякого встроенного в язык ООП. Вернее, оно даже показывает проблематику, которую затем более полно решает ООП.


A>В-шестых... можно ещё долго продолжать, только зачем.

Ну да, есть еще функциональное программирование, которое предоставляет абстрагирование с чуть другим размером гранулы — абстракция описывает не кортеж ф-ий, как в ООП, а одну абстрактную ф-ию. Ну, или класс их (таки, именованный кортеж ф-ий, принадлежащих классу-интерфейсу), как в Хаскеле, и тогда мы получаем ООП в профиль... Да и унутре сильно похожая реализация как в классическом ООП. ))

Здравствуйте, vdimas, Вы писали:

A>>В-пятых, человек, которому не объяснили, что в каждом ЯПе свои плюсы и минусы, что это как набор отвёрток для разных ситуаций, вырастает законченной бестолочью и потом всю жизнь страдает от утиного эффекта. Спрашивает, например, зачем нужны лямбды. Разве код с лямбдами выполняется быстрее? Нет? Ну и не нужны!

V>Ну... не скажи.
V>Даже в весьма далёких друг от друга, на первый взгляд, языках, таких как Си, Паскаль и Фортран приличная часть кода, представляющая некие целевые вычисления, может быть похожа или в точности идентична — это я про математические выражения с переменными, в т.ч. переменными составных типов — структурами, при доступе к полям структур.

Я не настолько стар, чтобы помнить Фортран, а Си и Паскаль это две попытки в одном и том же... роду? семействе?.. (оба императивные, процедурные, статически типизированные, компилируемые, нативные) с разных сторон приблизиться к лучшей выразительности, про которую шла речь в п.2. Что выразительнее — закорючки или слова? А в остальном это одно и то же.

V>А так же все три языка поддерживают в том или ином виде функциональный тип хотя бы в минимальном виде — в виде указателей на ф-ии, т.е. поддерживают косвенный вызов ф-ий, что позволяет использовать инструмент абстракций даже еще безо-всякого встроенного в язык ООП. Вернее, оно даже показывает проблематику, которую затем более полно решает ООП.

Вот уж не думаю, что указатели на функции делают Си функциональным "хотя бы в минимальном виде". Си тупо отражает устройство железа, а железо просто поддерживает адресацию кода (по заветам фон Неймана). Нужно, всё-таки, гражданство первого класса, а это и инлайнинг выражений, и поддержка со стороны стандартной библиотеки.

Здравствуйте, Privalov, Вы писали:

P>То есть сломали обратную совместимость?

Не, старый код компиллируется.


V>>Будь моя воля, я бы голосовал за шлифовку и выпуск современных стандартов этого легендарного языка с последующим возвращением его в "обойму" мейнстрима.
P>У Фортрана (того, на котором я работал) я вижу один недостаток: отсутствие зарезервированных слов. Иногда это приводило к весьма забавным эффектам.
P>Ну да, у него динамических структур данных не хватало. Приходилось выкручиваться.

Там много чего раздражало с т.з. современных компиляторов и наработанных практик.

Стоит пройтись по современному Фортрану, ИМХО, это весьма вкусный язык в последних версиях:
https://cyber.dabamos.de/programming/modernfortran/control-structures.html
https://wg5-fortran.org/N2201-N2250/N2212.pdf

Просто примеры (в т.ч. для остальных коллег):
Arithmetic if

if (x * y) 100, 200, 300

is equivalent to:

if (e < 0) goto 100
if (e == 0) goto 200
goto 300

Logical if

if (x * y < 0) y = 1

Block if

if (a == 0) then
    exit
else if (a < 0) then
    b = 0
else
    b = b + a
end if

Expressional if

b = (a > 0.0 ? a : 0.0)

В том числе это работает для ссылочных типов данных, например, для inout-параметров ф-ий:

call some_sub(a > 0 ? a : b > 0 ? b : c)
...
subroutine some_sub(x)
real, intent(inout) :: x

Т.е., в подпрограмму some_sub будет подана ссылка на a, b или c.

Select switch

select case (grade)
    case ('A')
        print *, 'Excellent!'

    case ('B', 'C')
        print *, 'Well done'

    case default
        print *, 'Invalid grade'
end select

В том числе сравнение в диапазонах:

select case (marks)
    case (91:100)
        print *, 'Excellent!'

    case (81:90)
        print *, 'Very good!'

    case (71:80)
        print *, 'Well done!'

    case (:40)
        print *, 'Better try again!'

    case default
        print *, 'Invalid marks'
end select

Наследование структур, типобезопасные указатели на базовую структуру, информация о типах:

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

ООП: https://cyber.dabamos.de/programming/modernfortran/object-oriented-programming.html
Препроцессор: https://cyber.dabamos.de/programming/modernfortran/preprocessor.html


Еще видел реализацию Фортрана в 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>Этот сильно нишевый.
Для начального обучения — прекрасный язык.
Самое важное качество: статически типизированный и нет преобразований по умолчанию.

И снова скажу: язык для начального обучения и промышленный язык — не должны быть одним и тем же языком.

Здравствуйте, LaptevVV, Вы писали:

LVV>Нет. BlackBox Component Builder — поинтересуйся всерьез, без предвзятости типа "старье".

Вот мне после Фортрана Паскаль не зашёл вообще. Я за всю жизнь написал на нём всего одну программу на 3-м курсе. И ту до ума не довёл.

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 выпустят с модулем программирования на хаскеле, который будет на голову выше всех остальных альтернатив.

Только не на Хаскеле, а на верифицируемых языках. А так всё верно, ещё год назад писал

Автор: hi_octane
Дата: 15.10.23

, что умные люди именно за эту тему взялись. Правда мощного выхлопа вроде не видно, ну так и GPT не сразу 4-й версии вышла.

Здравствуйте, 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]) {}

В Фортране каждый аргумент подробно описывается.