LINUX.ORG.RU
ФорумTalks

Зачем придумывают всё новые языки-велосипеды?

 , ,


0

1

Зачем кому-то понадобился раст, когда есть адекватные и всем знакомые кресты? Зачем нужен элексир, когда есть шарпик, который знает каждая мартышка? Зачем изобретают го, вместо развития сишечки? Зачем нужна нода, когда есть питон, и зачем нужен питон, когда есть руби?

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

Профессия размывается, за всем нереально уследить. Раньше, с некоторой натяжкой, всё было более-менее понятно: пэхэпэшник пишет бэк под веб, на джаваскрипте ваяют фронт, на делфи пилят формы, сишники — лоулэвл, крестовики — молодцы вообще ребята. А сейчас одно и то же можно сделать сотней разных способов. И вроде бы это хорошо, но вот глядишь на вакансии и там: требуется знания языка X123 (от 5 лет), опыт работы с фреймворком Y456, и ещё тулзы Z789, Z798 и Z897.

Да чёрт возьми, а если я знаю X321 и Z888? Мы вам перезвоним. А потом такие, ко-ко-ко, на рынке дефицит нормальных девелоперов, а юные вайтишники опыть наклепали говна и сорвали дедлайн трижды.

Наболело.


Ответ на: комментарий от monk

Межпроцессное конвейерное взаимодействие на любое количество процессов удобнее писать на шелле.

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

Кстати, именно поэтому всякие IPython и прочие не смогли его заменить.

не, там просто ситуация чуть лучше, чем с жабаскриптом в браузерах

next_time ★★★★★
()
Ответ на: комментарий от next_time

только потому, что в браузере другого языка нету

вообще-то, есть webassembly

Javascript - 1996
WebAssembly - 2016.
Связь ясна?

byko3y ★★★★
()
Ответ на: комментарий от monk

«fgrep bash bigfile | sort | head». На любом другом языке куча возни с промежуточными файлами, выделением памяти под буфер и всё такое.

пффф... я на С++ такое тоже легко могу. смотрите:

std::cout<<"Двоичный файл bigfile совпадает\n";
next_time ★★★★★
()
Ответ на: комментарий от next_time

очередной SDK

то есть, реально ничего

А что тебе еще надо? Переписать андроид весь на котлине? Этого не будет, потому что кучу индусов... пардон, профессиональных программистов на жава не смогут выучить новую технологию, и их придется поддерживать. Плагин Android Gradle, и отдельная мелочевка. Но для сторонних приложений андроида котлин нынче - это основной язык.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Ну т.е., жаба на андроидах вполне жива и ещё долго будет жива. Допустим, ладно, что её юзают только в 50% приложений (на самом деле, чаще).

Но для сторонних приложений андроида котлин нынче - это основной язык.

скоро будет, но пока нет

next_time ★★★★★
()
Ответ на: комментарий от monk

а если серьёзно, то аналогом «fgrep bash bigfile | sort | head» на Qt будет

QFile file("bigfile"); file.open();
file.readAll().split("\n").filter("bash").sort().last();

...ну аналогом, кроме того, что не сфейлится на реальных данных.

next_time ★★★★★
()
Ответ на: комментарий от byko3y

Нет, кнопка ничего не делала. Как баш ничего не делал. Все действия выполняли fgrep, sort, и head - они составляют основную сложность реализации.

Баш обеспечивает возможность передать большой объём данных из одного процесса в другой. Без него пришлось бы делать вручную блокировки, временные файла, области разделяемой памяти для каждого случая взаимодействия процессов. А так можно получить пару терабайтов со стандартного ввода и выдать пару терабайтов результата на стандартный вывод, всё межпроцессное взаимодействие обеспечивается оболочкой.

Я вот так совсем недавно написал «десяток строк на SQL», и выяснилось, что работать они будут несколько дней.

Так с любым языком бывает. Поэтому и переписывают с JS на С++, а потом и на ассемблер. Но это не значит, что язык JS не нужен. Так же и SQL. Если тебе один раз попался запрос, который компилятор SQL не смог правильно оптимизировать, то множеству других людей в тысячах случаев компилятор SQL позволил не тратить часы на ручное детальное описание алгоритма запроса.

monk ★★★★★
()
Ответ на: комментарий от byko3y

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

Не обгоняет. The company considering converting COBOL to Java was correct in its assumption the code would run less efficiently. Ironically, while the company’s aim was to reduce costs, the consequence of this migration would be dealing with CPU efficiency issues in the new Java code. (c) https://www.compuware.com/converting-cobol-to-java/

Учитывай, что запуск процедуры (для создания потока) на Коболе стоит не больше, чем запуск процедуры из разделяемой библиотеки.

И тем не менее, элементарное наследование структуры легко выполнимо в Си, но весьма тяжело сделать в коболе.

Если очень надо именно наследование, в Коболе есть конструкция: IDENTIFICATION DIVISION.CLASS-ID. Account INHERITS Base. (с методами и полями).

Если речь про наследование в стиле fopen (чтобы передать указатель на потомка, а разыменовать как указатель на предка), то в COBOL тоже так можно (SET ADDRESS OF BaseGrp TO Ptr). И даже можно через CORRESPONDING MOVE заполнить поля родственных структур, которые не являются потомками друг друга.

Что значит «неудобных»? Если человек за фиксированный промежуток времени этой структурой может сделать намного больше, чем с коболом - это «неудобный»?

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

monk ★★★★★
()
Ответ на: комментарий от next_time

РСУБД - действительно, значительный прорыв в индустрии, но SQL - просто очередной язычок и не более.

Тогда бы не делали SQLite. SQL именно удобный язык, который позволяет компактно описать задачу компилятору и надеяться, что тот сформирует достаточно эффективный алгоритм.

monk ★★★★★
()
Ответ на: комментарий от next_time

...ну аналогом, кроме того, что не сфейлится на реальных данных.

Так я про то же. Твой «аналог» должен весь файл прочитать в память, а потом на каждой операции его ещё пару раз в памяти скопировать. А sh позволяет не только обеспечить работу с произвольным объёмом данных, но и позволяет выполнять фильтрацию и сортировку параллельно.

monk ★★★★★
()
Ответ на: комментарий от next_time

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

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

monk ★★★★★
()
Ответ на: комментарий от next_time

во-первых, разношёрстный и точной спецификации перловых регэкспов не следует

Как и у любого другого языка. Есть диалекты SQL, C, Pascal, Cobol, и т.д.

во-вторых, он ужасен

И поэтому «это библиотека, которая есть в любом языке»? Интересно, чтож никто не запилил «неужасный»?

monk ★★★★★
()
Ответ на: комментарий от monk

Баш обеспечивает возможность передать большой объём данных из одного процесса в другой

Баш не обеспечивает эту возможность. Баз дает указание ОС обеспечить передачу большого объема данных из одного процесса другой через unix pipe.

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

Что такое «множеству других людей в тысячах случаев»? «SELECT * FROM tablename»? «UPDATE tablename SET field = value WHERE key = :key»?

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Баз дает указание ОС обеспечить передачу большого объема данных из одного процесса другой через unix pipe.

sh, C и UNIX тяжело отделить друг от друга. И даже если оставить эту функцию, то написать пачку pipe/fork/exec на си гораздо длиннее, чем описать в виде строки оболочки.

Что такое «множеству других людей в тысячах случаев»? «SELECT * FROM tablename»? «UPDATE tablename SET field = value WHERE key = :key»?

Например, почти весь код 1С. Там нельзя влезть напрямую в SQL, нельзя написать хранимую процедуру. А запросы на пару тысяч строк SQL кода. Если бы все эти выборки писать вручную, было бы по сотне тысяч строк. И на ней работает больше половины бухгалтеров России.

monk ★★★★★
()
Ответ на: комментарий от monk

Твой «аналог» должен весь файл прочитать в память

должен ради скорости - произойдёт перекодировка медленного в плане обработки utf8 на быстрый QString

если память важна, можно просто читать построчно или использовать аналогичные классы, использующие mmap, но это мало кому надо, ибо обработка текста в голом utf8 медленна даже для питона

а потом на каждой операции его ещё пару раз в памяти скопировать

нет, вот дальше уже избыточных выделений памяти не произойдёт

А sh позволяет не только обеспечить работу с произвольным объёмом данных

вообще-то, ваш код фейлится на реальных данных

я в курсе, что есть какой-то ключ у grep, который это исправляет, но судя потому, что даже такую простую операцию на баше без курения манов написать затруднительно, думаю, показательно, насколько баш в реальности неудобен

next_time ★★★★★
()
Последнее исправление: next_time (всего исправлений: 1)
Ответ на: комментарий от monk

Тогда бы не делали SQLite.

SQLite работает через РСУБД, вообще-то. Вот если бы вы про LinQ написали, тогда бы да - но то, что вы даже в качестве аргумента в споре о нём не вспомнили - думаю, уже показательно, насколько он востребован.

SQL именно удобный язык, который позволяет компактно описать задачу компилятору и надеяться, что тот сформирует достаточно эффективный алгоритм.

лично у меня работа с РСУБД на голом шарпе получалась компактнее и быстрее, чем через SQL

в реальном продакшене традиции вынуждают использовать SQL в качестве промежуточного языка, но так или иначе в любом проекте либо используют готовую ORM, либо велосипедят свою, лишь бы SQL не юзать

SQL сейчас как ассемблер - его используют одновременно все и никто

next_time ★★★★★
()
Ответ на: комментарий от monk

но таких задач меньше, чем конвейерных.

в терминале - да, в скриптах - полно таких задач

next_time ★★★★★
()
Ответ на: комментарий от monk

Как и у любого другого языка. Есть диалекты SQL, C, Pascal, Cobol, и т.д.

ок, соглашусь

И поэтому «это библиотека, которая есть в любом языке»? Интересно, чтож никто не запилил «неужасный»?

а почему find из коробки работает как Автоваз? почему, чтобы просто поискать файл я обязан набирать портянку

find / -iname 2>/dev/null

почему за 30(?) или сколько там лет до сих пор хотя бы не добавили ключ, подавляющий вывод ошибок о доступе к директории?

традиции, сэр - мыши плакали, кололись, но продолжали их соблюдать - вот и с регэкспами также

next_time ★★★★★
()
Ответ на: комментарий от monk

Не обгоняет. The company considering converting COBOL to Java was correct in its assumption the code would run less efficiently. Ironically, while the company’s aim was to reduce costs, the consequence of this migration would be dealing with CPU efficiency issues in the new Java code. (c) https://www.compuware.com/converting-cobol-to-java/

К сожалению, в интернетах крайне мало экспериментальных сведений. которые могли бы подтвердить или опровергнуть это заявление.
Все, что получилось:
- https://books.google.com/books?id=JGKzDwAAQBAJ&pg=PA145&lpg=PA145&amp... - здесь испытывается работа с CISC контейнером, с чем жава справляется хуже, причем, два варианта жавы справляются с этой задачей с заметной разницей, но по этому однорму примеру сложно что-то судить;
- https://www.youtube.com/watch?v=v9-kd5YdoSA - COBOL to Java Migration Patterns and Performance - автор показывает бенчи нескольких разных задач. Не понятно, откуда они выдраны и что значат цифры - в том числе ничего толком не говорит бормочащий себе под нос оратор. Но, судя по всему, жава быстро посчитала числа фибоначи и подсчет кол-во символов.

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

Если очень надо именно наследование, в Коболе есть конструкция: IDENTIFICATION DIVISION.CLASS-ID. Account INHERITS Base. (с методами и полями).

Нет, ты не понял. В Си нет наследования. Вообще. Его можно сделать. А еще можно сделать интерфейсы, списки, деревья. Вполне возможно, что какие-то из них реализованы в каком-то компиляторе кобола, но я хочу подчеркнуть - их нужно реализовывать в компиляторе - их не получится адекватно (поддерживаемо, удобно) реализовать в самом коболе. Вот некоторые люди ругают медленность регулярок в жаве, но, тем не менее, регулярки жавы насписаны на самой жаве. Сколько регулярок написаны на коболе? Их никто до сих пор не написал, потому что он будут весить 100-200 тыс строк на коболе - черт его знает, какая у этого окажется производительность, и как это потом поддерживать.

Что значит «неудобных»? Если человек за фиксированный промежуток времени этой структурой может сделать намного больше, чем с коболом - это «неудобный»? CORRESPONDING MOVE по непредсказуемости поведения будет похуже ручной работы с указателями.

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

Во-первых, никто не запрещает на Си писать со строгой типизацией. Во-вторых, программы со свободной типизацией на коболе вообще не имеют аналогов.

byko3y ★★★★
()
Ответ на: комментарий от monk

Тогда бы не делали SQLite

SQLite использует SQL для примитивных операций, вроде простой выборки/изменения/вставки, а остальную логику обрабатывает приложение. Потому в SQLite ровно пять типов столбцов.

byko3y ★★★★
()
Ответ на: комментарий от monk

Баз дает указание ОС обеспечить передачу большого объема данных из одного процесса другой через unix pipe.

sh, C и UNIX тяжело отделить друг от друга. И даже если оставить эту функцию, то написать пачку pipe/fork/exec на си гораздо длиннее, чем описать в виде строки оболочки.

Ты так пишешь, будто кроме баша и си в никсах вообще ничего нет. POSIX вообще не обязывает реализовывать интерфейсы ОС-и ни на каком конкретном языке - хоть на жаве реализовывай обработку пайпов в ядре.

А запросы на пару тысяч строк SQL кода. Если бы все эти выборки писать вручную, было бы по сотне тысяч строк.

А их на SQL роботы писали, что ли? Не видел еще NoSQL выборок из таблицы на питоне в пару строк?

byko3y ★★★★
()
Ответ на: комментарий от next_time

SQLite работает через РСУБД, вообще-то.

SQLite — это библиотека, позволяющая читать-писать файл запросами SQL. Отдельно РСУБД там нет. А что скажете про SQL в xHarbour, FoxPro, Berkeley DB, MS Excel и MS AD? Это тоже РСУБД?

Причём в BDB добавили SQL в 5 версии. Значит он чем-то лучше, чем её стандартный интерфейс?

если бы вы про LinQ написали

А он-то к SQL каким боком?

работа с РСУБД на голом шарпе получалась компактнее и быстрее, чем через SQL

Это что за функции в C#, которые позволяют получить данные из РСУБД не формируя SQL запрос?

в любом проекте либо используют готовую ORM, либо велосипедят свою, лишь бы SQL не юзать

1С использует SQL. SAP ABAP тоже. ORM используют только если SQL используют не по назначению. Хранят в ней не данные, а объекты. И опять же, вместо создания объектного хранилища всем проще навернуть ORM поверх SQL.

monk ★★★★★
()
Ответ на: комментарий от byko3y

А их на SQL роботы писали, что ли?

Люди. Я про то, что проще написать две тысячи строк, а не сотню. Собственно, только ради этого новые языки и разрабатываются. Иначе можно всё написать и на ассемблере.

monk ★★★★★
()
Ответ на: комментарий от byko3y

Вот некоторые люди ругают медленность регулярок в жаве, но, тем не менее, регулярки жавы насписаны на самой жаве.

Исключительно из-за JVM. Или есть регулярки, написанные на паскале, алголе, C++, фортране?

Сколько регулярок написаны на коболе?

Их никто до сих пор не написал, потому что он будут весить 100-200 тыс строк на коболе - черт его знает, какая у этого окажется производительность, и как это потом поддерживать.

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

Во-первых, никто не запрещает на Си писать со строгой типизацией.

Я уже приводил пример с COMPUTE, который на Си превратится в огромную портянку. И так любые ограничения на типы. Аналогично, если поле структуры имеет какие-то разумные ограничения (например, процент выполнения 0..100), то в Си приходится явно вставлять проверки в вычисления.

Во-вторых, программы со свободной типизацией на коболе вообще не имеют аналогов.

Можно минимальный пример на Си такой программы?

monk ★★★★★
()
Ответ на: комментарий от next_time

почему за 30(?) или сколько там лет до сих пор хотя бы не добавили ключ, подавляющий вывод ошибок о доступе к директории?

Гм... ты первый человек, который сообщил, что это надо. Думаю, кому было сильно надо, сделали псевдоним-однострочник.

monk ★★★★★
()
Ответ на: комментарий от next_time

вообще-то, ваш код фейлится на реальных данных

???

Что я написал не так? Или что значит «фейлится»? Вроде работает...

monk ★★★★★
()
Ответ на: комментарий от monk

А их на SQL роботы писали, что ли?

Люди. Я про то, что проще написать две тысячи строк, а не сотню. Собственно, только ради этого новые языки и разрабатываются.

А я про то, что люди будут хавать то, что навалят в корыто. Аналогичные операции можно было записать более компактно, а если говорить про сотни тысяч строк «с нуля», то таки сама реализация 1С весит миллионы, потому претензия мне не ясна. А компактнее записать можно потому, что SQL 1С хоть и тьюринг полный, но проигрывает языкам общего назначения на задачах, отдаленных от манипуляций таблицами.

byko3y ★★★★
()
Ответ на: комментарий от monk

Вот некоторые люди ругают медленность регулярок в жаве, но, тем не менее, регулярки жавы насписаны на самой жаве.

Исключительно из-за JVM. Или есть регулярки, написанные на паскале, алголе, C++, фортране?

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

Их никто до сих пор не написал, потому что он будут весить 100-200 тыс строк на коболе - черт его знает, какая у этого окажется производительность, и как это потом поддерживать.

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

Если же использовать Жаву в качестве запускалки какого-то pcre2, то оно тоже оч ень быстро будет работать. Вот, мы снова приходим к тому, что кобол используется как «запускалка», которая просто вызывает внешнюю функцию. Можно переписать с Си на кобол какой-то примитивный и медленный алгоритм регулярок алгоритм, вроде этого: https://github.com/kokke/tiny-regex-c/blob/master/re.c Однако, реализация полноценных регулярок на коболе - это боль и страдание, потому что в коболе нет динамичности для генерации сложных и быстрых структур, в которые преобразовывается регулярное выражение, ровно как и мало инструментов абстракций, которые позволяли бы создавать свои собственные функции, подобные встроенным в компилятор. Собсна, из-за отсутствия инструментов абстрагирования и понадобилось делать столько много встроенных команд, которые считаются частью языка, хотя, казалось бы, какое отношения имеют всякие расширения к коболу? По этим причинам к настоящему времени кобол всё больше напоминают некоторую высокоэффективную запускалку команд, вроде баша и питона.

Я уже приводил пример с COMPUTE, который на Си превратится в огромную портянку. И так любые ограничения на типы.

Я пропустил этот момент - где приводил и что за портянка?

Аналогично, если поле структуры имеет какие-то разумные ограничения (например, процент выполнения 0..100)

Да? И какое же замечательное однострочное решение ты можешь предложить для ситуация переполнения целых значений? Также, заодно в двух словах опиши, какие действия будут выполняться в этой ситуации.

Во-вторых, программы со свободной типизацией на коболе вообще не имеют аналогов.

Можно минимальный пример на Си такой программы?

Структура из заголовка и списка, например, целых чисел struct {SomeHeader header; int data[];}, где можно вернуть указатель отдельно на заголовок и на сам список, передавая их соответствующим функциям, которые умеют работать только с заголовком или только со списком. Ну или просто абстрактная структура, правила работы с которой описываются содержимым ее заголовка, вроде struct {TypeDesc *type; char data[];}, но эти правила (TypeDesc) не имеют отношения к наследованию, интерфейсам, а описывают что-то вроде «у этой структуры первое поле - целочисленное, второе поле - строка» или вторая такая же структура «первое поле - указатель, второе поле - вещественное число». Это есть продвинутая динамичность по сишному, когда тип структуры определяется функциями, которые эту структуру используют.

byko3y ★★★★
()
Ответ на: комментарий от monk

Что я написал не так?

как обычно в баше - у вас не хватает очередного ключа у грепа

Вроде работает...

вот именно, что вроде - на каких-то файлах отрабатывает, на каких-то - нет

что значит «фейлится»?

вместо поиска по файлу пишет «Двоичный файл bigfile совпадает»

next_time ★★★★★
()
Ответ на: комментарий от monk

Гм... ты первый человек, который сообщил, что это надо.

вот и всегда так, мыши плачут, колются и даже не задумываются, что можно жить лучше

Думаю, кому было сильно надо, сделали псевдоним-однострочник

и таскают его с собой всякий раз

next_time ★★★★★
()
Ответ на: комментарий от monk

Отдельно РСУБД там нет.

...ведь библиотека SQLite и есть реализация РСУБД

FoxPro, xHarbour

так они же конкуренты SQL, не?

Berkeley DB

key-value

Это что за функции в C#, которые позволяют получить данные из РСУБД не формируя SQL запрос?

уже и не помню

1С использует SQL. SAP ABAP тоже.

...внутри - так-то они как раз и созданы, чтобы юзеры пальцы от sql не ломали

рисование формочек в 1C имеет отношение к SQL такое же, как javascipt к С++ (на котором браузер написан)

А LinQ к SQL каким боком?

ну вот ваш любимый SQL за пределами работы с РСУБД, применяемый, например к xml файлам - что-то не прижился

next_time ★★★★★
()
Ответ на: комментарий от monk

Это что за функции в C#, которые позволяют получить данные из РСУБД не формируя SQL запрос?

Отвечаю вместо него:
https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2005/ms1311...

Microsoft SQL Server 2005 features the integration of the common language runtime (CLR) component of the .NET Framework for Microsoft Windows. This means that you can now write stored procedures, triggers, user-defined types, user-defined functions, user-defined aggregates, and streaming table-valued functions, using any .NET Framework language, including Microsoft Visual Basic .NET and Microsoft Visual C#.

byko3y ★★★★
()
Ответ на: комментарий от next_time

так они же конкуренты SQL, не?

Они конкуренты РСУБД. А SQL они реализуют.

http://www.foxclub.ru/rhproject/project/html/815f7265-4dfd-40b9-8f19-0673b5a4...

https://github.com/harbour/core/tree/master/contrib/rddsql

Berkeley DB key-value

https://docs.oracle.com/cd/E17276_01/html/bdb-sql/index.html

...внутри - так-то они как раз и созданы, чтобы юзеры пальцы от sql не ломали

рисование формочек в 1C имеет отношение к SQL такое же, как javascipt к С++ (на котором браузер написан)

Какие формочки? Вот кусок кода https://pastebin.com/cGqdH9nS

ну вот ваш любимый SQL за пределами работы с РСУБД, применяемый, например к xml файлам - что-то не прижился

К файлам Excel прижился, к объектам AD прижился. А к XML приживётся только когда XML станут таблицами, а не деревьями.

monk ★★★★★
()
Ответ на: комментарий от byko3y

struct {SomeHeader header; int data[];}

    03 REC-1.
        05 header USAGE POINTER.
        05 data USAGE POINTER. 

Передать поле структуры в функцию в Коболе всегда можно было.

monk ★★★★★
()
Ответ на: комментарий от byko3y

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

Покажешь на паскале? Без пруфа-то и на Коболе есть: «I have written a callable regexp routine in MF COBOL that works very nicely» (с) http://computer-programming-forum.com/48-cobol/e3af14a91f8120f0.htm

monk ★★★★★
()
Ответ на: комментарий от monk

Передать поле структуры в функцию в Коболе всегда можно было.

Ладно, хорошо, пусть даже и два указателя вместо цельной структуры. Можно еще было сделать тупо data PIC X BASED, и потом выделять память через

ALLOCATE variable-number CHARACTERS RETURNING pointer-variable
SET ADDRESS OF data TO pointer-variable
то есть - голый массив байтов. Правда, здесь мы внезапно обнаруживаем, что работаем на уровне абстракции ассемблера, поскольку теряем все средства статической типизации, и не имеем никакой возможности создания абстракций, окромя «вызвать функцию».

Развовор ведь был не о «сделать любой ценой», а о том, что в коболе неудобно делать динамичные алгоритмы - что есть правда. Когда глобальные переменные, статические структуры - всё в шоколаде, кобол рулит.

byko3y ★★★★
()
Ответ на: комментарий от monk

Покажешь на паскале? Без пруфа-то и на Коболе есть: «I have written a callable regexp routine in MF COBOL that works very nicely» (с) http://computer-programming-forum.com/48-cobol/e3af14a91f8120f0.htm

https://github.com/andgineer/TRegExpr/blob/master/src/RegExpr.pas
Здесь компилятор и полноценный синтаксис. И я напомню, что паскаль имел первоначальное название ALGOL W: https://en.wikipedia.org/wiki/ALGOL_W.

На фортране серьезных реализаций регулярок нету.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

С этим согласен. Я фразу «программы со свободной типизацией на коболе вообще не имеют аналогов» воспринял как «невозможно сделать».

monk ★★★★★
()

Кстати, в качестве оффтопа нашел старую статью Таненбаума за 1978 год про сравнение ALGOL 68 и Pacsal: https://academic.oup.com/comjnl/article/21/4/316/356817

Оказывается, он был неадекватом всё это время, и 10 лет ему было недостаточно для осознания той простой истины, что алгол 68 - это кусок дерьма, а Паскаль - будущее индустрии на ближайших два десятка лет.

byko3y ★★★★
()
Ответ на: комментарий от monk

Они конкуренты РСУБД. А SQL они реализуют.

Microsoft Visual FoxPro (VFP) — среда разработки систем баз данных[1], включающая объектно-ориентированную реляционную СУБД[2]

всем конкурентам конкурент

Какие формочки?

такие. если бы вы были хоть немного в теме, вы бы понимали о чём речь

Вот кусок кода https://pastebin.com/cGqdH9nS

и где тут SQL?

К файлам Excel прижился

Пруф? Что-то я не слышал об активном использовании SQL в Excel

next_time ★★★★★
()
Ответ на: комментарий от monk

рисование формочек в 1C имеет отношение к SQL такое же, как javascipt к С++ (на котором браузер написан)

Какие формочки?

Что-то вроде проектировки формочек в MS Access. Я когда-то в детстве подобную штуку делал. Честно говоря, каждый раз после того, как я делал графические дизайнеры (а делал я это аж два раза), у меня возникал впечатление, что те затраты на создание дизайнера не стоят той пользы, которая получается от него в сравнении с описанием структуры интерфейса в виде какого-то XAML или просто кода программы. Даже если взять простоту создания кнопочек-панелек - все равно слой невизуального поведения остается и его не поулчится нарисовать, не разломав WYSIWYG. ДА и вообще, у меня есть сомнение по поводу острой необходимости графических интерфесов, помимо банальной таблицы.

Вот кусок кода https://pastebin.com/cGqdH9nS

Весело у них там. Половина содержимого запроса - это описание полей для выборки:

НачисленнаяЗарплатаИВзносы.ФизическоеЛицо КАК ФизическоеЛицо,
НачисленнаяЗарплатаИВзносы.Сумма КАК Сумма,
НачисленнаяЗарплатаИВзносы.ВидОперации КАК ВидОперации,
Весьма неэффективное расходование отображаемой сложности программы. как на мой взгляд.

byko3y ★★★★
()
Ответ на: комментарий от next_time

такие. если бы вы были хоть немного в теме, вы бы понимали о чём речь

Формочек там не больше, чем в C++, например.

и где тут SQL?

Всё, что после «Запрос.Текст =». Русифицированный.

Что-то я не слышал об активном использовании SQL в Excel

https://querysurge.zendesk.com/hc/en-us/articles/205766136-Writing-SQL-Querie...

monk ★★★★★
()
Ответ на: комментарий от byko3y

которая получается от него в сравнении с описанием структуры интерфейса в виде какого-то XAML или просто кода программы.

В 1С сейчас формочки примерно как в Glade. https://infostart.ru/upload/iblock/11a/mngform1.png . И можно получить представление в XML.

Можно и программно всё нарисовать. Но ведь в C/C++ зачем-то Glade и Qt designer сделали.

что те затраты на создание дизайнера не стоят той пользы, которая получается от него в сравнении с описанием структуры интерфейса в виде какого-то XAML или просто кода программы

Затраты делает один раз разработчик платформы, а пользу получает каждый программист.

Весьма неэффективное расходование отображаемой сложности программы. как на мой взгляд.

А как по-другому? Перечислять поля в любом случае надо. Можно, конечно, это делать неявно без указания таблицы или вообще через «*», но тогда читать сложнее. Поэтому в 1С принято многословнее, но читабельнее. Поэтому и таблица НачисленнаяЗарплатаИВзносы, а не НачЗрпВзн или SalTax.

monk ★★★★★
()
Ответ на: комментарий от monk

Затраты делает один раз разработчик платформы, а пользу получает каждый программист.

Пользу? Какую пользу? Я и разрабатывал сами дизайнеры, в том числе упомянутый glade, и кучу лет с помощью них лепил сами формочки. И в какой-то момент я просто начал херачить интерфейсы тупо кодом, когда внезапно осознал, что интерфейс с минимальной сложностью всегда отличается в дизайнере и в работе, и даже если я быстро накидал в дизайнере что-то - потом много времени приходится доводить его. А типа не все ли равно, буду ли я сразу писать интерфейс в коде, или какую-то его часть сделаю в графике?

Еще в 2008 году я пытался придумать, как можно разрулить эту проблему, и с тех пор вывод у меня не изменился: графические дизайнеры не работают, вместо них необходимы инструменты для дизайна во время выполнения, где работающее приложение можно потыкать, подергать, поклацать. Разница заключается лишь в том, что спустя годы я наконец узнал про REPL и про то, как белые люди разрабатывают приложения. Именно REPL пытаются сымитировать дизайнеры, позволяя разрабу расширять design-time фичами из run-time, например, позволяя делать подключение в базе, чтобы настраивать столбцы таблицы и поля по фактическим данным.

А как по-другому? Перечислять поля в любом случае надо. Можно, конечно, это делать неявно без указания таблицы или вообще через «*», но тогда читать сложнее. Поэтому в 1С принято многословнее, но читабельнее. Поэтому и таблица НачисленнаяЗарплатаИВзносы, а не НачЗрпВзн или SalTax.

Я не про полное упоминание имени, я про вот это:

ВТ_РасходыПриУСНОбороты КАК ВТ_РасходыПриУСНОбороты
...
ВТ_ПромежуточныйНДФЛ КАК ВТ_ПромежуточныйНДФЛ
то есть, идентификаторы полностью повторяются. Как я понимаю, это вообще генерированный код, потому что какой человек будет спокойно писать столько бессмысленных дублей?

Как пишет человек? А вот так:

|ВЫБРАТЬ Регистратор, РасчетныйДокумент, СуммаПриход, ВидРасхода, СчетУчета, ОтражениеВУСН
|ПОМЕСТИТЬ ВТ_РасходыПриУСНОборотыСводная
|ИЗ ВТ_РасходыПриУСНОбороты
Компактно, читаемо, по сути. Таким образом SQL часть этого кода ( https://pastebin.com/cGqdH9nS ) переписывается примерно в 70 строк вместо 360.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

Это личный опыт. В моём личном опыте, если добавил полдюжины полей (клиенту надо хранить эти данные в объекте), то гораздо быстрее их просто бросить на форму, чем писать на каждое поле по три строки. Также как макет печатной формы проще заполнить в редакторе, а не писать

Т.Область(1,1).Текст = "Наименование";
Т.Область(1,1).Шрифт = Жирный;
Т.Область(1,2).Выражение = "Наименование";
...

Как я понимаю, это вообще генерированный код, потому что какой человек будет спокойно писать столько бессмысленных дублей?

Для редактирования запросов там есть конструктор запросов (https://programmist1s.ru/opisanie-konstruktora-zaprosov-1s/).

И эти «бессмысленные» дубли помогают удобно делать патчи. То есть меньше вероятность, что патч сломается от того, что в запросе появилось дополнительное поле.

Компактно, читаемо, по сути

Затем надо добавить поле из связанной таблицы (дописываешь через LEFT JOIN) и внезапно надо исправить имя каждого поля.

monk ★★★★★
()
Ответ на: комментарий от monk

гораздо быстрее их просто бросить на форму, чем писать на каждое поле по три строки

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

with TButton.Create(parent) do begin
  Name := 'title';
  Text := "Наименование";
  Font.Style := [fsBold];
end;
Как видишь, избыточность минимальна, а структура очевидна. Проблема только в том, что неочевиден внешний вид полученного окошка.

И эти «бессмысленные» дубли помогают удобно делать патчи. То есть меньше вероятность, что патч сломается от того, что в запросе появилось дополнительное поле.

Может быть они помогают при работе инструментами, но точно не помогают при чтении кода глазами и правке руками. Этот код сгенерирован и он неоправдано раздут - его нельзя оценивать по обычным критериям кол-ва строк в программе.

Затем надо добавить поле из связанной таблицы (дописываешь через LEFT JOIN) и внезапно надо исправить имя каждого поля

Зависит от второй таблицы. Если нет конфликтов имен, то ничего дописывать не нужно.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Тебе все равно нужно прописывать свойства полей.

Нет. Они уже прописаны в структуре данных.

Как видишь, избыточность минимальна, а структура очевидна.

У твоей кнопки координаты на прописаны. А вычислять Left и Top (пусть даже Width и Height автоматически будут) достаточно неприятно. Даже в 1С с его XML-подобной структурой минимальный код для добавления примерно такой:

НовыйЭлемент = Элементы.Вставить("ЗаказПоставщику",Тип("ПолеФормы"),Элементы.Товары,Неопределено);
НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
НовыйЭлемент.ПутьКДанным = "Объект.Товары.ЗаказПоставщику";

А вот когда начинается подбор шрифтов, цвета, размера, то гораздо проще тыкать цвет и шрифт в соответствующих диалогах, а размер подгонять мышкой, а не писать всё это числами в коде. Кроме того для цвета и шрифта приходится ещё и именованные константы вводить, так как угадать, что «Цвет(120, 166, 128)» — серо-зелёный просто по коду достаточно сложно.

Проблема только в том, что неочевиден внешний вид полученного окошка.

Это как раз меньшая из проблем.

monk ★★★★★
()
Ответ на: комментарий от monk

А вычислять Left и Top (пусть даже Width и Height автоматически будут) достаточно неприятно

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

Кроме того для цвета и шрифта приходится ещё и именованные константы вводить, так как угадать, что «Цвет(120, 166, 128)» — серо-зелёный просто по коду достаточно сложно.

Проблема только в том, что неочевиден внешний вид полученного окошка.

Это как раз меньшая из проблем.

Так проблема или меньшая из проблем?

byko3y ★★★★
()
Ответ на: комментарий от monk

Формочек там не больше, чем в C++, например.

1С это не только язык, но и среда разработки - сравнивать вообще некорректно

если сравнивать формошлёпство куте и 1с, то в 1с оно круче и в том числе позволяет работать с БД вообще не написав ни строчки SQL запросы в ручную

Всё, что после «Запрос.Текст =». Русифицированный.

Тогда мы с вами разговариваем на китайском языке. Русифицированном.

https://querysurge.zendesk.com/hc/en-us/articles/205766136-Writing-SQL-Querie

ну и где истории успеха? где там указана статистика использования?

next_time ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.