![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
sab123А вот давно мне хотелось написать комментарии по мотивам http://ivan-gandhi.livejournal.com/2802600.html , только руки как-то не доходили. Про то, как для всех драм есть совершенно разумные объяснения.
> Я не застал того смешного момента, когда от программирования в кодах люди переходили на ассемблер. Ну в смысле, в кодах-то я и сам валял немало; и восхищался системой ИС-2, автор М.Р.Шура-Бура; все это в удовольствие. Но драмы не застал, чтобы пищали - "этот ваш ассемблер только лишняя трата времени".
Времен, когда нормальные люди переходили с кодов на ассемблер я, конечно, и близко не застал. Но вот ситуацию, когда на БК-0010 переходили с ассемблера на коды - застал. С ленточным накопителем ассемблер был редким геморроем: надо загрузить текстовый редактор, загрузить текст программы, редактировать, записать текст программы, загрузить ассемблер, загрузить текст программы, записать ассемблированную программу, прочитать и запустить ассемблированную программу. Все это перематывая вручную ленты и меняя кассеты. впрочем, потом вроде быи и какие-то полу-интегрированные системы. А вот в кодах можно было писать прямо из монитора, который в ПЗУ. Благо, в той системе комманд коды и ассемблер отражались друг на друга довольно очевидным образом.
> Это стоял вопль. Фортран неэффективен. У него там неизвестно какой код получается, а я хочу контролировать код. Толпы идиотов, которые не в состоянии были освоить несколько нехитрых операторов да строку формата (на все уходит пара часов на кухне, проверено) возмущались плохим языком. На самом деле фортран компилируется линейно, и манипуляция скомпилированным годов в рантайме была одно время моим любимым занятием, много чего достигли.
Ну, в сегодняшние-то дни оно выглядит странно. Но во времена маленьких программ, в которых собственно логика была тривиальна, зато пускались на кучу хитроумных трюков чтобы упихать программу в ущербную доступную память, оно действительно было так. А потом когда машины подросли, актуальность экономии байтов уменьшилась.
> На кобол никто никогда не жаловался почему-то, что он неэффективный. На алгол тоже. И на бейсик.
Бейсик - изначально учебный язык. И они с Коболом появились существенно позже.
Про Бейсик, кстати, жаловались. На БК-0010 стандартным языком был выбран Фокал именно для экономии памяти по сравнению с Бейсиком - в Фокале на каждое служебное слово было достаточно одной буквы. И по той же причине был популярен Форт (Forth). Но потом, конечно, появился "вильнюсский бейсик", который сразу сжимал программу через бинарное представление лексем, да потом еще и компилировал ее в байт-код, который исполнялся гораздо быстрее Фокала. Так что проблема оказалась решена.
> Потом вдруг появилось структурное программирование. Идея была такая, что надо писать маленькие програмки и по определенным рулесам, в частности, goto нельзя использовать. Почему - знал один Дийкстра. И выход из функции должен быть только один. Одновременное отсутствие goto и выхода в середине давало определенные неудобства - ну а как вообще программировать-то? Между прочим, в те поры не только выход из функции мог быть не один, но и вход не один. В фортране на БЭСМ 6 запросто в одну функцию можно было зайти несколькими способами.
>
> Постепенно все насобачились рисовать структурно, никто уже в здравом уме не рисовал огромные лабиринты, все чики-чики, асу и асутп.
Но ведь действительно, почему goto нельзя использовать - знает один Дейкстра. На практике в чистом структурном программировании без него очень плохо. Но потом придумали break и continue, которые структуризировали типичные применения goto, и проблема решилась, структурное программирование стало пригодным к использованию.
Кстати о входах, в GCC имеется такое явление как "вычислимый goto", и при большом желании в функции можно входить более чем одним способом.
> И вдруг бац, си++ и объектно-ориентированное программирование. Инкапсуляция, полиморфизм, народность. Если ты эту молитву не скажешь, тебя и на работу не возьмут. Причем, что любопытно, что такое полиморфизм, не знали ни отвечающие, ни спрашивающие. Ну то есть за полиморфизм канал ад-хок полиморфизм, а параметрический полиморфизм назывался "эти дурацкие темплейты" или "ненавижу дженерики".
Темплейты появились сильно позже. Ну и кстати, никакой в них не полиморфизм, а всего лишь инкапсуляция, все делается на стадии компиляции.
> Я пропустил внедрение джавы, кстати. Оно сопровождалось тектоническими явлениями. Неэффективна же джава. Она же интерпретируемая, вроде бейсика. На ней ничего путного не напишешь. Квалифицированные программисты пишут на плюсах. До сих пор эта вера распространена.
Ну так истинная же правда. И неэффективна как не знаю что, и с управлением памятью в ней совсем жопа. Но уже придуман более человеческий вариант, где большинство корявостей исправлены. Называется C#/.NET, уже можно пользоваться.
> ООП завоевало мир с выходом книжки Банды Четырех - "Дизайн Паттерны" ("Шаблоны Проектирования").
ООП сначала продвигалось неотъемлемо от ООД, ОО Дизайна - Гради Буч и всё такое, создавать объекты на каждый чих. С логикой, что раз ООП позволяет контролировать сложность, то теперь можно не заморачиваться, плодить эту сложность налево и направо, а ООП ее прожует. Но на самом деле выяснилось, что ООП не в состоянии прожевывать сложность с такой скоростью как ООД ее создает, не говоря уже про борьбу ООД с человеческим мозгом. В результате ООД похерили (ну, кроме как среди свидетелей Джавы, где он еще цветет среди прочей корявости), а ООП оказалось годным к применению.
Ну и кстати, надо не забывать, что изначально ООП вылезло из диалекта Лиспа. И было как всегда медленным и корявым. И только когда его придумали компилировать в Си++ (и потом оттуда пошли Джавы и прочее), то оно стало пригодным к применению. Ну, вторым фактором стало похерить ООД, тогда оно действительно вошло в повсеместную практику.
То есть, не то что бы ООП как таковой не существовал. Call tables были давно известны и использовались повсеместно как интерфейс для драйверов и тому подобного, в Юниксе самого начала 70-х годов они есть. Достижением ООП как идеи было сделать легким использование этих таблиц налево и направо и генерацию их в компиляторе. Собственно, второй причиной долгого неприятия ООП было "ну и таблицы вызовов, ну и чё? у нас их и без того есть". Собственно, в Го до сих пор продолжается эта самая идея. Ну, есть, но когда их поддерживает язык, то удобнее.
> Короче, фп вылез из ниши для особо одаренных, и полез во все щели в промышленное программирование.
Функциональное программирование существовало с 50-х годов. Из него на самом деле налезло много всего интересного из области побочных экспериментальных ответвлений - начиная от динамического распределения памяти, и до всяких ООПов. Но в общем и целом оно как было непригодно для использования, так и осталось.
Общая мораль заключается в следующем, даже в двух следующих:
1. Когда придумывают новую концепцию, она обычно получается корявой. Настолько корявой, что эта корявость сравнима с проблемами старых концепций, а то и хуже. Но эту корявость со временем обтесывают, и оказывается, что вполне можно пользоваться и даже радоваться, и вот тогда начинается победное шествие.
2. Машинное время дешевеет, а максимально возможная сложность программ растет. Обычно корявость новой концепции оказывается более-менее линейной, а проблемы старых концепций - нелинейными. Поэтому просто закон Мура поспетенно уменьшает значимость этой корявости, даже если ее и не обтесали. Ну, конечно, с дальнейшим ростом оказывается, что оно только казалось линейным для малых масштабов, а потом опять уходит в нелинейность. И приходится придумывать очередную новую концепцию. Что не отменяет совершенно реальной корявости и непригодности концепций в старые времена, пока до них не дорос масштаб производительности.
> Я не застал того смешного момента, когда от программирования в кодах люди переходили на ассемблер. Ну в смысле, в кодах-то я и сам валял немало; и восхищался системой ИС-2, автор М.Р.Шура-Бура; все это в удовольствие. Но драмы не застал, чтобы пищали - "этот ваш ассемблер только лишняя трата времени".
Времен, когда нормальные люди переходили с кодов на ассемблер я, конечно, и близко не застал. Но вот ситуацию, когда на БК-0010 переходили с ассемблера на коды - застал. С ленточным накопителем ассемблер был редким геморроем: надо загрузить текстовый редактор, загрузить текст программы, редактировать, записать текст программы, загрузить ассемблер, загрузить текст программы, записать ассемблированную программу, прочитать и запустить ассемблированную программу. Все это перематывая вручную ленты и меняя кассеты. впрочем, потом вроде быи и какие-то полу-интегрированные системы. А вот в кодах можно было писать прямо из монитора, который в ПЗУ. Благо, в той системе комманд коды и ассемблер отражались друг на друга довольно очевидным образом.
> Это стоял вопль. Фортран неэффективен. У него там неизвестно какой код получается, а я хочу контролировать код. Толпы идиотов, которые не в состоянии были освоить несколько нехитрых операторов да строку формата (на все уходит пара часов на кухне, проверено) возмущались плохим языком. На самом деле фортран компилируется линейно, и манипуляция скомпилированным годов в рантайме была одно время моим любимым занятием, много чего достигли.
Ну, в сегодняшние-то дни оно выглядит странно. Но во времена маленьких программ, в которых собственно логика была тривиальна, зато пускались на кучу хитроумных трюков чтобы упихать программу в ущербную доступную память, оно действительно было так. А потом когда машины подросли, актуальность экономии байтов уменьшилась.
> На кобол никто никогда не жаловался почему-то, что он неэффективный. На алгол тоже. И на бейсик.
Бейсик - изначально учебный язык. И они с Коболом появились существенно позже.
Про Бейсик, кстати, жаловались. На БК-0010 стандартным языком был выбран Фокал именно для экономии памяти по сравнению с Бейсиком - в Фокале на каждое служебное слово было достаточно одной буквы. И по той же причине был популярен Форт (Forth). Но потом, конечно, появился "вильнюсский бейсик", который сразу сжимал программу через бинарное представление лексем, да потом еще и компилировал ее в байт-код, который исполнялся гораздо быстрее Фокала. Так что проблема оказалась решена.
> Потом вдруг появилось структурное программирование. Идея была такая, что надо писать маленькие програмки и по определенным рулесам, в частности, goto нельзя использовать. Почему - знал один Дийкстра. И выход из функции должен быть только один. Одновременное отсутствие goto и выхода в середине давало определенные неудобства - ну а как вообще программировать-то? Между прочим, в те поры не только выход из функции мог быть не один, но и вход не один. В фортране на БЭСМ 6 запросто в одну функцию можно было зайти несколькими способами.
>
> Постепенно все насобачились рисовать структурно, никто уже в здравом уме не рисовал огромные лабиринты, все чики-чики, асу и асутп.
Но ведь действительно, почему goto нельзя использовать - знает один Дейкстра. На практике в чистом структурном программировании без него очень плохо. Но потом придумали break и continue, которые структуризировали типичные применения goto, и проблема решилась, структурное программирование стало пригодным к использованию.
Кстати о входах, в GCC имеется такое явление как "вычислимый goto", и при большом желании в функции можно входить более чем одним способом.
> И вдруг бац, си++ и объектно-ориентированное программирование. Инкапсуляция, полиморфизм, народность. Если ты эту молитву не скажешь, тебя и на работу не возьмут. Причем, что любопытно, что такое полиморфизм, не знали ни отвечающие, ни спрашивающие. Ну то есть за полиморфизм канал ад-хок полиморфизм, а параметрический полиморфизм назывался "эти дурацкие темплейты" или "ненавижу дженерики".
Темплейты появились сильно позже. Ну и кстати, никакой в них не полиморфизм, а всего лишь инкапсуляция, все делается на стадии компиляции.
> Я пропустил внедрение джавы, кстати. Оно сопровождалось тектоническими явлениями. Неэффективна же джава. Она же интерпретируемая, вроде бейсика. На ней ничего путного не напишешь. Квалифицированные программисты пишут на плюсах. До сих пор эта вера распространена.
Ну так истинная же правда. И неэффективна как не знаю что, и с управлением памятью в ней совсем жопа. Но уже придуман более человеческий вариант, где большинство корявостей исправлены. Называется C#/.NET, уже можно пользоваться.
> ООП завоевало мир с выходом книжки Банды Четырех - "Дизайн Паттерны" ("Шаблоны Проектирования").
ООП сначала продвигалось неотъемлемо от ООД, ОО Дизайна - Гради Буч и всё такое, создавать объекты на каждый чих. С логикой, что раз ООП позволяет контролировать сложность, то теперь можно не заморачиваться, плодить эту сложность налево и направо, а ООП ее прожует. Но на самом деле выяснилось, что ООП не в состоянии прожевывать сложность с такой скоростью как ООД ее создает, не говоря уже про борьбу ООД с человеческим мозгом. В результате ООД похерили (ну, кроме как среди свидетелей Джавы, где он еще цветет среди прочей корявости), а ООП оказалось годным к применению.
Ну и кстати, надо не забывать, что изначально ООП вылезло из диалекта Лиспа. И было как всегда медленным и корявым. И только когда его придумали компилировать в Си++ (и потом оттуда пошли Джавы и прочее), то оно стало пригодным к применению. Ну, вторым фактором стало похерить ООД, тогда оно действительно вошло в повсеместную практику.
То есть, не то что бы ООП как таковой не существовал. Call tables были давно известны и использовались повсеместно как интерфейс для драйверов и тому подобного, в Юниксе самого начала 70-х годов они есть. Достижением ООП как идеи было сделать легким использование этих таблиц налево и направо и генерацию их в компиляторе. Собственно, второй причиной долгого неприятия ООП было "ну и таблицы вызовов, ну и чё? у нас их и без того есть". Собственно, в Го до сих пор продолжается эта самая идея. Ну, есть, но когда их поддерживает язык, то удобнее.
> Короче, фп вылез из ниши для особо одаренных, и полез во все щели в промышленное программирование.
Функциональное программирование существовало с 50-х годов. Из него на самом деле налезло много всего интересного из области побочных экспериментальных ответвлений - начиная от динамического распределения памяти, и до всяких ООПов. Но в общем и целом оно как было непригодно для использования, так и осталось.
Общая мораль заключается в следующем, даже в двух следующих:
1. Когда придумывают новую концепцию, она обычно получается корявой. Настолько корявой, что эта корявость сравнима с проблемами старых концепций, а то и хуже. Но эту корявость со временем обтесывают, и оказывается, что вполне можно пользоваться и даже радоваться, и вот тогда начинается победное шествие.
2. Машинное время дешевеет, а максимально возможная сложность программ растет. Обычно корявость новой концепции оказывается более-менее линейной, а проблемы старых концепций - нелинейными. Поэтому просто закон Мура поспетенно уменьшает значимость этой корявости, даже если ее и не обтесали. Ну, конечно, с дальнейшим ростом оказывается, что оно только казалось линейным для малых масштабов, а потом опять уходит в нелинейность. И приходится придумывать очередную новую концепцию. Что не отменяет совершенно реальной корявости и непригодности концепций в старые времена, пока до них не дорос масштаб производительности.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-12-09 12:46 am (UTC)Конкретно, когда появился Кобол (и предшественники), и когда - Фортран (и предшественники)? Существенна ли эта разница?
no subject
Date: 2014-12-09 01:51 am (UTC)no subject
Date: 2014-12-09 02:32 am (UTC)no subject
Date: 2014-12-09 03:38 am (UTC)no subject
Date: 2014-12-09 03:53 am (UTC)no subject
Date: 2014-12-09 06:48 am (UTC)no subject
Date: 2014-12-09 06:59 am (UTC)no subject
Date: 2014-12-09 08:08 am (UTC)PERFORM -> BR ...
MOVE -> LD ... -> ST ...
Я когда первый раз увидел этот Cobol, я еще подумал, что он не намного легче ассемблера, пока не увидел тот HLASM :) там одних мнемоник штук 500.
no subject
Date: 2014-12-09 12:51 am (UTC)Темлпейты таки осуществляют параметрический полиморфизм.
no subject
Date: 2014-12-09 01:55 am (UTC)no subject
Date: 2014-12-09 04:00 am (UTC)no subject
Date: 2014-12-09 11:45 pm (UTC)Развитие программирование подчинено миропониманию "нормальных людей".
В том числе ООП и расцвет квазифункциональщины.
no subject
Date: 2014-12-10 01:59 am (UTC)no subject
Date: 2014-12-09 05:13 am (UTC)no subject
Date: 2014-12-09 07:04 am (UTC)Когда-то в далеких 90-х я тоже от Java плевался и зарекался, что ни строчки на ней не напишу, потом был Perl, и я увидел, что интерпретируемые языки тоже имеют преимущество. А сейчас от Java 1.0 мало что осталось, и некоторые уже делают попытки сравнивать Java c G++ :)
no subject
Date: 2014-12-09 07:08 am (UTC)no subject
Date: 2014-12-09 08:17 pm (UTC)У Джавы мне корявость видится в-основном в следующем:
1. Очень кривые и уродливые API от Сана (тут порадоваться можно только тому, что Апаче постепенно создает более человеческих).
2. Отстуствие нормального множественного наследования, отчего постоянно пишут Interface и InterfaceImpl.
3. Кривая сборка мусора. Сжирает всю память сколько дали (не запускает сборку мусора пока не сожрет всю память), а если дать недостаточно - дохнет. Явный вызов gc.collect() - это не вызов сборки, а так себе, совет, который она обычно ингорирует. Поэтому получается невозможно очистить висячие ссылки. .NET на аналогичный запрос всегда честно чистит память.
4. Кривой формат библиотек, jar в сжатом формате, отчего они даже теоретически не могут быть разделяемыми. И отчего программы очень медленно запускаются.
5. Кривой подход к коллбекам (в отличие от delegate в .NET).
6. Прочие дебильные выдумки, начиная от ant и maven и заканчивая dependency injection, за которые надо сразу больно по голове бить.