Язык для прикладных задач

[valexey]

А так?

VAR
rec: RECORD
   one: INTEGER;
   two: INTEGER;
   three: INTEGER;
   four: INTEGER;
END;
i: INTEGER;
BEGIN
   i := 1;
   RUN("FOR EACH field IN rec DO rec[field.key] = i; INC(i); END;");
END

Тоже хрень какая-то. Что тут key для field? Обычно бывает таки key-value пары, где ключ это, переходя к терминологии записей, это поле, а значение это значение и есть - чиселка которая лежит в этом поле.

Ну и контрольный вопрос, что делает этот код:

Код: [Выделить]

Поля = "Oдин, Двa, Три; Чeтыре";

Запись = Новый Структура(Поля)


[ilovb]

Ну ладно map есть в плюсах с шаблонами. А сколько нужно всего для поддержки этих контейнеров?

А если map кроме строк должно уметь еще и числа хранить?

Запись.Один = 1;
Запись.Два = "2";

а это:

Поля = "Oдин, Двa, Три; Чeтыре";
Запись = Новый Структура(Поля)

равносильно

Код: [Выделить]

VAR
rec: RECORD
   one: INTEGER;
   two: INTEGER;
   three: INTEGER;
   four: INTEGER;
END;Только гибкость такого подхода куда больше.

[ilovb]

Тоже хрень какая-то. Что тут key для field? Обычно бывает таки key-value пары, где ключ это, переходя к терминологии записей, это поле, а значение это значение и есть - чиселка которая лежит в этом поле.

Так и есть. Записываем значение по данному ключу. Тут ключ - это имя поля структуры.

Т.е. в 1С разрешен рефлекшен относительно имен полей RECORD'а.
Унутрях это map конечно (модифицированный). Но для кодера это выглядит как обращение к полю RECORD рефлексивно, т.е. обращаясь к метаданным в реалтайме.

[valexey]

Ну ладно map есть в плюсах с шаблонами. А сколько нужно всего для поддержки этих контейнеров?

Нужен всего лишь язык высокого уровня :-)

А если map кроме строк должно уметь еще и числа хранить?

Запись.Один = 1;
Запись.Два = "2";

То никаких проблем :-)

Код: [Выделить]

map<string, boost::any> record;
record["Один"] = 1;
record["Два"]  = "2";
Штука в том, что если у тебя есть язык высокого уровня со статической типизацией, то ты там можешь легко сделать себе подъязык с динамической типизацией, просто в виде либы. Ибо язык высокого уровня для того и нужен, чтобы можно было создавать нужные тебе абстракции (иначе это не ЯВУ), а динамическая типизация - всего лишь одна из таких абстракций.

а это:

Поля = "Oдин, Двa, Три; Чeтыре";
Запись = Новый Структура(Поля)

равносильно

Код: [Выделить]

VAR
rec: RECORD
   one: INTEGER;
   two: INTEGER;
   three: INTEGER;
   four: INTEGER;
END;Только гибкость такого подхода куда больше.

То есть оно спокойно прожует вместо запятой (',') мою точку с запятой (';'), и ошибки в рантайме не будет? :-) А если я эти слова в той строке буду разделять буквой "Ы"?

[ilovb]

Точку с запятой я проглядел.    В этом случае будет исключение времени выполнения (без краха даже если нет обработчика)

Сдаюсь. Шаблоны в данном случае рулят. Но процедуру по имени они все равно не смогут вызвать. 

У меня тогда такой вопрос: Зачем мне прикладнику изучать монстра С++? Пусть он даже большинство плюшек скриптовых языков покроет? Смысл?

[valexey]

Точку с запятой я проглядел.    В этом случае будет исключение времени выполнения (без краха даже если нет обработчика)

Сдаюсь. Шаблоны в данном случае рулят. Но процедуру по имени они все равно не смогут вызвать. 

Смотря что такое вызов "процедуры по имени" :-) Тут нужна корректная полная постановка задачи. Возможно тебе и не нужна тут вызов произвольной процедуры по произвольному имени на самом деле. (тем более что "процедуры" можно сложить в тот же map, а ключ будет строка, по строке достаешь нужную "процедуру" и вызываешь её).

У меня тогда такой вопрос: Зачем мне прикладнику изучать монстра С++? Пусть он даже большинство плюшек скриптовых языков покроет? Смысл?

Ну, во-первых про терминологию я вроде бы все выше разжевал. Как прикладнику тебе больше подойдет C++ или даже asm нежели любой из скриптовых языков (иначе попробуй все выше перечисленные примеры написать на типичном скриптовом языке - например на языке bat-файлов).

Видимо ты таки подразумеваешь языки с динамической типизацией (в том числе хм… компилирующиеся в нативный код :-) ).

Так вот, я тоже прикладник (системным программированием по работе я не занимаюсь как бы, то есть не пишу ни ОС ни компиляторы). И я слабо представляю где динамическая типизация мне принесла бы больше пользы чем вреда. В общем то потенциальный вред от подхода через динамическую типизацию + eval (интерпретируем строку как кусок кода) я вроде бы успешно продемонстрировал - глаз пропустил точку с запятой, и это будет не ошибка компиляции, а ошибка в рантайме. Внезапная и беспощадная. Но даже если из моей строки это точказапятую заменить на запятую, то код:

Код: [Выделить]

Поля = "Oдин, Двa, Три, Чeтыре";
Запись = Новый Структура(Поля)

Запись["Один"]=42;
Запись["Четыре"]=13;

Счетчик = 1;

Выполнить("
|Для Каждого Поле Из Запись Цикл
|   Запись[Поле.Ключ] = Счетчик;
|   Счетчик = Счетчик + 1;   
|КонецЦикла;")
наверняка отработает не так как ожидалось. ;-)

А "монстра" можно и не учить, можно взять любой другой монстр язык высокого уровня - например Java (хотя оно и уровнем ниже чем C++), или Kotlin, или Go (хотя там в чем-то уровень еще ниже чем в яве - приходится многое делать в рантайме), или, не к ночи будет упомянут, C#. Да даже Оберон можно (в самом-самом худшем случае там будет надежность такая же как в языке с динамической типизацией, в среднем же надежность/отлавливаемость ошибок там будет лучше). Ах, да, Аду тоже можно и нужно. Ибо оня ня (особенно если больше хочется иметь набор инструментов для работы, нежели инструмент с помощью которого можно сделать этот самый набор инструментов).

[Peter Almazov]

например Java (хотя оно и уровнем ниже чем C++), или Kotlin, или Go (хотя там в чем-то уровень еще ниже чем в яве - приходится многое делать в рантайме), или, не к ночи будет упомянут, C#.

Типа, C# хуже, чем все вышеперечисленное.
А в чем, собственно, претензии к C#?

[vlad]

например Java (хотя оно и уровнем ниже чем C++), или Kotlin, или Go (хотя там в чем-то уровень еще ниже чем в яве - приходится многое делать в рантайме), или, не к ночи будет упомянут, C#.

Типа, C# хуже, чем все вышеперечисленное.
А в чем, собственно, претензии к C#?

Да у него, собственно, только один фатальный недостаток (на фоне остальных перечисленных языков) - его "придумала" M$

[vlad]

Сдаюсь. Шаблоны в данном случае рулят. Но процедуру по имени они все равно не смогут вызвать. 

Рано сдаешься Позиция должна быть примерно такая: на плюсах можно сделать ВСЁ, но почти всё будет через одно место И ткнуть в исходники какого-нибудь boost::any.

[valexey]

например Java (хотя оно и уровнем ниже чем C++), или Kotlin, или Go (хотя там в чем-то уровень еще ниже чем в яве - приходится многое делать в рантайме), или, не к ночи будет упомянут, C#.

Типа, C# хуже, чем все вышеперечисленное.
А в чем, собственно, претензии к C#?

Ну, он не то чтобы хуже… он другой :-)

Во-первых в C# уж очень резво пихают все фичи подряд (ортогональные и не очень). Такое ощущение что у них там сидит специальный человек, который гуглит какие же еще есть фичи в других ЯП, которые они еще в шарп не запихнули. ООП? Легко! ФП - да не вопрос! Контракты - уже впихнули! Ждем элементов пролога и брейнфака, а также APL. С# это такой современный PL/I, с поправкой на возможности сегодняшних машин (то есть C#  еще крупнее).

Во-вторых, C# это MS. Я вообще не шибко жалую языки от которых наносит vendor lock-in'ом. А тут запашок весьма и весьма сильный, да к тому же не просто lock-in какой-нибудь АдаКоры, а толстячка в виде MS. Причем не только на язык (как в случае java), но и на основной инструментарий и либы и вообще все (да, mono есть, но mono все же вторично и по большей части следует за MS). Поэтому нафиг-нафиг.

Но в плане рассматриваемого вопроса, C# весьма неплох (хотя он, повторюсь, как минимум не менее монстр нежели С++). Он быстрый, он более высокоуровневый нежели Java (сравнивать его уровневость с плюсами я не берусь, просто потому что не достаточно компетентен в современном C# для этого).

[alexus]

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

Такие задачи составляют 95% от задач, которые приходится решать. И большая часть времени тратится программы при приёме данных на работу со строками, если конечно запросы к базе данных составлены корректно, а в самой базе данных сделана оптимизация (хотя бы на уровне индексов, чтобы исключить fullscan).
Я не использую разные датасеты, данные из запроса "руками" размещаются в памяти (это совсем не трудно, а параллельно с получением и размещением данных выполняются и другие операции, установка признаков, калькуляция и т.п.).
(Работа ведётся в Delphi)

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

С моей точки зрения, это несколько преждевременный вывод.

[alexus]

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

Эмм. Ну вот мне нужно рисовать спектрограмму в режиме реального времени. То есть в простейшем случае это будет либо DFT либо DCT (дискретное преобразование фурье, либо дискретное косинусное преобразование). Теперь вопрос - реально ли все равно на каком языке решать такую ПРИКЛАДНУЮ задачу?

Подпрограмму преобразования Фурье лучше и проще написать на ассемблере... я бы сказал, без вариантов. А обрамление - на том, что удобно для разработки интерфейса с пользователем или другими (под)программами.

[ilovb]

...Видимо ты таки подразумеваешь языки с динамической типизацией...

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

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

Еще попробую по пунктам пройтись.
1. Языки обычно простые для изучения и использования.
2. Переносимость выше чем у статических языков.
3. Непосредственный и естественный рефлекшн
4. Нет необходимости в использовании стека, т.к. скорость исполнения не имеет высокого приоритета. Можно использовать альтернативные более гибкие способы (как в JS например)
5. Нет необходимости в компиляции и линковке. Более того можно работать в режиме диалога (Python, Scheme)
6. Динамический язык обычно имеет богатое окружение в виде всяких контейнеров, коллекций и т.д., которых обычно с лихвой хватает для прикладных задач. Окружение пишется на нативных языках, и как следствие производительность оказывается достаточной для большинства прикладных задач. Прикладник не занимается разработкой сложных структур данных. Он пишет окружение только для своей конкретной прикладной задачи.

Ну и по поводу всяких медиаплееров с играми. Нет никакой проблемы написать медиаплеер на том же Python, т.к. кодеки можно использовать готовые (написание коих я отношу к системному программированию). А игры (3D с крутой графикой) спокойно пишутся на том же жабаскрипте (см. Unity)

[ilovb]

Такие задачи составляют 95% от задач, которые приходится решать. И большая часть времени тратится программы при приёме данных на работу со строками...

Не очень понятно. Что имеется ввиду? Какие именно операции со строками?

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

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

Я вот сейчас дописываю расчет коммунальных услуг для водоканала. Город (120000 абонентов) обсчитывается за 5 минут. Код работает только 10% времени (1000 строк) Остальное время это выгребание исходных данных SQL'ом (примерно 30%) и запись результата расчета (примерно 60%). И это при том, что язык 1С примерно в 500 раз медленнее нативного.
Это не первый такой случай. Да и вообще я не помню, чтобы язык был узким местом. В подавляющем большинстве случаев виновником является ввод/вывод.

[ilovb]

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

Это она в плюсах внезапная и беспощадная. А в том же 1С это форточка с сообщением об ошибке времени выполнения. В котором отображается строчка кода в которой произошла ошибка (и даже кнопочка чтобы перейти к этой строчке кода) и причина ошибки.
Некоторые пользователи даже не подозревают что это ошибки в программе  Закрывают форточку с ошибкой и дальше работают (Либо звонят кодеру, который удаленно подключается и за пару минут исправляет ошибку).
Проблема возникает только когда из-за ошибки пользователь не может сохранить свою работу, но это редко.