О языках программирования

[vlkamov]

Некоторое время назад состоялся вот такой диалог

iamphet
А вообще ждём, когда же появится на свете чудо-язык, который был бы мужественным и нежным мощным и удобным одновременно.

vlkamov
"Не дождетесь"
Если серьезно, то ассемблер. В принципе почти любой язык можно сделать удобным, но мощный - он.

iamphet
Мощный в смысле залезть в I/O порты и при этом упихнуть программу в некоторое малое количество килобайт и миллисекунд? Согласен. Для остального он ничем не лучше, а зачастую и хуже любого другого языка программирования.

vlkamov
А что такое "остальное" ? Речь шла о мощности и удобстве. Мощность несомненна, а удобным его делает пользователь. Например, таким образом:
http://vlkamov.livejournal.com/685130.html
"Высокоуровневый" язык - это такая же надстройка над ассемблером, но с одним отличием, он прежде всего удобен своему автору. Максимально удобна будет сделанная самому себе надстройка над ассемблером.

iamphet
Я считаю довольно расточительным тратить несколько лет на то, чтобы написать язык программирования, полноценно отражающий именно мою индивидуальную разруху в голове. Большинство всё же предпочитает идти другим путём: заточить свою голову под существующие парадигмы или придумать свои парадигмы в рамках существующих языков.
Кстати, а почему ассемблер? Если говорить про x86, то кому-нибудь может не понравиться ни интеловский синтаксис, ни AT&T и ему придётся писать свой компилятор своего ассемблера в машинных кодах.

vlkamov
Дело в том, что при таком подходе базовый ассемблер быстро уходит под фундамент и какой он там был - маловажно. Годы тоже не нужно тратить, т.к. необходимые кирпичики пишутся только по мере надобности.
Более того. Я уверен, что существуют сотни C-библиотек для манипуляций с векторами, но написать такую как у меня быстрее и проще, чем разобраться в чужой. А использовать ее можно много раз - во всех векторных вычислениях - с нулевыми затратами времени.
Просто существует предрассудок, что сделать дольше, чем воспользоватьсчя готовым.
Но даже и для использования сторонних разработок можно с помощью define соорудить интуитивно понятный вызов.
Ассемблер - потому что мощный. Даже прямое программирование в машинных кодах не даст улучшения.

А вчера попался отчет о сравнении perl и python.

Дальше меня спросили, как в python обстоят дела с регулярными выражениями, и в результате пришли мы к такой задаче:
Есть строка, необходимо вывести все слова в ней, которые встречаются N раз.

и я тот диалог вспомнил. Регулярные выражения очевидно в базовом питоне не предусмотрены, ну так и что ?! Для любителей регулярных выражений есть

#!/usr/bin/env python
import re

То есть тот самый подход: если нравится/удобно/часто используешь что-то - сделай библиотеку. Время потратишь то же, что и на изучение чужих разработок, зато меньше нагрузка, меньше ошибок - ведь что-то удобно потому, что уже выучено. Да, это не совсем Unix way - использовать не уже готовые кирпичики, а сделать кирпичи самому под себя. Собственно высокоуровневые языки и являются такими библиотеками, и их авторы делали их по своему вкусу.

Еще зацепило, что и питон и перл решают задачу вдвое быстрее C++. "Тут что-то не так".

Comments

[vlkamov.livejournal.com]

> Ну и "Война и мир" - это не "war and peace", а "War and world".

Виноват.
"все прижизненные издания романа Толстого выходили под названием „Война и миръ“, и сам он писал название романа по-французски как „La guerre et la paix“."

[gptu-navsegda.livejournal.com]

Вы хотите сказать, что между делом можете написать библиотеку для обработки регэкпов?

[vlkamov.livejournal.com]

Конечно.
Для начала всего-то и нужно поиск определенной символьной последовательности и ее замена на что-то другое. Ну а там добавлять по мере необходимости.

Перлом я пользуюсь с 2004 года, но только два месяца назад мне понадобилось рег.выражение, содержащее начало или конец строки. Если бы я добавлял полезности только по одной в месяц, за это время было бы более 70 - это почти все регулярные выражения.

[gptu-navsegda.livejournal.com]

я когда-то столкнулся с ошибкой в работе регэкспов в emeditor и на их форуме нашел объяснение, что они для регэкспов используют внешнюю библиотеку и сами не могут ее пофиксить:) Из этого факта я сделал вывод, что не такая уж это простоя штука.

[vlkamov.livejournal.com]

...
Чтобы этим воспользоваться, я посмотрел справку по р.в. и уже успешно забыл. А если бы писал сам, то применил бы пусть и более длинное, но незабываемое \начало_строки.

[serg-markov.livejournal.com]

как то подумал что "лучше писать самому все либы для джавы" и мне резко поплохело :-)

[vlkamov.livejournal.com]

Все возражения ошибочны в этом пункте
> писать самому все либы

Не обо "все" речь. И не "сразу".

[snowman-fedya.livejournal.com]

Такой язык есть. Это Форт.

Но за его мощь и гибкость приходится платить повышенным напряжением мозгов. Впрочем, это даже полезно.

[vlkamov.livejournal.com]

Повышенное напряжение мозгов - НЕ удобство

[snowman-fedya.livejournal.com]

Удобство есть достижение цели с минимальными затратами, не так ли? Форт отвечает этим условиям. Но при этом он требует бОльшей внутренней дисциплины.

Ну, скажем так: некоторым удобнее доехать быстрее, а некоторым -- чтобы не трясло (при этом даже можно и не ехать).

[vlkamov.livejournal.com]

> Удобство есть достижение цели с минимальными затратами, не так ли?

Не так.

[vlkamov.livejournal.com]

Глянул основы Форта. Да, создатель языка сделал define (в сишной терминологии) едва ли не главным инструментом.

Насчет мощи непонятно
http://dan.corlan.net/bench.html
GForth - интерпретатор, но показывает результат на порядок лучше чем другие ин-ры. И на порядок же не дотягивает до лучших компиляторов.
В то же время вижу в других источниках про транслятор f2c пишут, что транслированный из Фотра в C и потом откомпилированный код дает -10...14 % от скорости C кода. То есть примерно равны.

[snowman-fedya.livejournal.com]

главная фишка Форта не в определении новых слов, а в шитом коде.

У Форта нет интерпретатора как такового. Построение словарной статьи, те. операция, аналогичная компиляции в других языках, происходит при её определении. То есть внёс

: bb 2 2 + .

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

Извеcтные мне реализации Форта по быстродействию оставляли С далеко позади и были на уровне ассемблера. Правда, это было во времена DOS. Вменяемого Форта под Windows я не нашёл (да и не искал особо). Виндовые программы сильно завязаны на сишноподобные вызовы функций виндовых либ, и при этом вся прелесть Форта теряется. Если бы вся винда была написана на Форте (неисполнимая мечта)...

В своё время (конец 80х) я пробовал написать на Форте виндоподобную оболочку для БК0010. Собственно, винды я тогда ещё не видел, а видел Макинтош, на который и ориентировался. Так вот, быстродействие оконного интерфейса получалось даже на БК вполне на уровне юзабельности, а сам код составлял 4-5 килобайт.

[shark-ru.livejournal.com]

Форт -- это всё тот же ассемблер, только для виртуальной машины.

[snowman-fedya.livejournal.com]

Не только и не совсем.

Это и шитый код, и метод определения слов, дающий ни с чем не сопоставимую свободу организации кода.

Но неважно -- форт не стал тем, чем мог бы стать, и уже не станет. Развитие программирования пошло по кривым окольным тропам.

[shark-ru.livejournal.com]

А в чём вы меряете "мощность" языка?

Обычно, под "мощностью" языка понимают количество выразимых на языке абстракций.
Ассемблер является НИЗКОуровневым языком именно потому что реализует наименьшее количество наиболее простых абстракций -- машинные операции над несколькими аппаратно реализованными форматами машинных слов и небольшое количество метаинформации, ориентированной, опять же, на машинное представление программ.
Разумеется, ни один язык не содержит абстракций на все случаи жизни, поэтому приходится либо отображать понятия предметной области на абстракции языка, либо конструировать новые абстракции из уже имеющихся (и пользоваться библиотеками таких конструктов). Поэтому второй составляющей "мощности" языка является качество конструирования таких новых понятий. Ассемблер и здесь в самом низу из-за того, что отображать предметные понятия приходится на наиболее примитивные из всех возможных и из-за того, что средства конструирования новых понятий бедны и примитивны.

А самым "мощным", в приведённом смысле, был бы проблемно-ориентированный язык, позволяющий оперировать непосредственно понятиями предметной области. Правда, он бы перестал быть универсальным и умер бы при малейшем изменении предметной области.
И "мощным" и универсальным был бы язык, предназначенный для создания языков. Тогда бы каждая задача решалась наиболее "мощным" из всех возможных способом "каждой задаче -- свой язык".
В общем-то, все эти "парадигмы программирования" и меряния пиписьками, у кого больше встроенных финтифлюшек и богаче библиотеки -- это всё слепые тыканья именно в этом направлении: как из имеющихся средств соорудить некое подобие проблемно-ориентированного языка и на этом языке решить задачу.