LINUX.ORG.RU

tcl vs rebol/red

 , , ,


1

5

Ваши мысли.

Вот мои: конечно, круто иметь компилятор в натив, но я так понял, что до лиспа они всё же не дотянули в этом плане. Но, допустим, тут они побеждают tcl.

С другой стороны, классно иметь множество типов, но формат даты типа 1-Jan-1990 не дают никакого шанса на локализацию. Да и вообще, после опыта лиспа сложность определения типа литерала выглядит явным путём не туда. ПРоблема здесь в том, что все форматы встроенных типов данных (насколько я понял), глобальны. Т.е. если я хочу свой DSL, я быстро могу вступить в конфликт. Даже и внутри самого языка такой конфликт есть. Например, 123.45 - это число, 123.45.6 - это tuple из 123.45.6 . А если я хочу tuple из двух чисел 123 и 45 ? Кривота получается.

С другой стороны, есть сходства: очень гибкий и простой синтаксис, батарейки, кросс-платформенность.

Соответственно, ваши мнения. Может быть, кому-нибудь пришлось на red/rebol что-то делать.

★★★★★

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

По TIOBE на 5 месте. К слову, Javascript на 8.

Ух ты, чудо!

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

А как же dbase III? Clipper 87? Были же технологии...

dBASE III - «технология»? O_O Это наколенная поделка (до сих пор помню поле «указатель на рабочую область» в заголовке dbf-файла); Clipper 87 - в общем, тоже. Clipper 5.0 - это было неплохо для своего времени, но даже там определение своих структур данных было угребищным.

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

С Бейсиком тоже, кстати, странно получилось - он вымер.

По TIOBE на 5 месте

Чтобы назвать VisualBasic.NET «Бейсиком» - это надо не знать ни того, ни другого.

tailgunner ★★★★★
()
Ответ на: комментарий от vasiliy-pupki

В scheme и racket обработка строк выглядит нелогично. В CL, кстати, лучше.

Можно пример? Что значит «нелогично»?

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

Чтобы назвать VisualBasic.NET «Бейсиком» - это надо не знать ни того, ни другого.

Ну называют же Common Lisp «лиспом». Так и в VisualBasic все конструкции, которые позволяют в нём узнать «бейсик», в наличии (вплоть до названия).

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

Да, наверное, Clipper 5.0 - уже плохо помню номера версий. Как бы то ни было, можно было на них написать приложение для работы с БД в несколько строк, вместе с графическим интерфейсом. А сколько нужно потратить труда, чтобы сделать такой хелло-ворлд на сегодняшних технологиях? И на сколько порядков больше ресурсов ему понадобится для работы?

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

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

den73 ★★★★★
() автор топика

никто не пишет про ребол с редом

icefreeze
()
Ответ на: комментарий от den73

А сколько нужно потратить труда, чтобы сделать такой хелло-ворлд на сегодняшних технологиях?

На C# примерно столько же. До 2015 года был Visual FoxPro практически совместимы с Clipper. Потом MS его закрыла как устаревший. Хотя VFP 9 до сих пор многие используют.

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

найти букву в строке

В смысле, позицию?

(define (find-str s ch)
  (for/first ([c (in-string s)]
              [i (in-naturals)]
              #:when (char=? c ch))
    i))

заменить эту букву на другую

(define (replace-str! s ch new)
  (for/first ([c (in-string s)]
              [i (in-naturals)]
              #:when (char=? c ch))
    (string-set! s i new)))

или если все, то

(define (replace-str-all! s ch new)
  (for ([c (in-string s)]
              [i (in-naturals)]
              #:when (char=? c ch))
    (string-set! s i new)))

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

На C# примерно столько же.

Не верю.

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

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

Если с графическим интерфейсом, то это более поздние версии Clipper или даже Visual FoxPro.

А сколько нужно потратить труда, чтобы сделать такой хелло-ворлд на сегодняшних технологиях?

Полагаю, столько же.

И на сколько порядков больше ресурсов ему понадобится для работы?

Спрашивать нужно «сколько стоят потребляемые ресурсы по сравнению с теми временами».

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

Чтобы назвать VisualBasic.NET «Бейсиком» - это надо не знать ни того, ни другого.

Ну называют же Common Lisp «лиспом»

CL гораздо больше похож на Lisp 1.5, чем VB.NET на Beginner All-purpose Instruction Symbolic Code.

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

сделай индекс списком: 1.end = ('index 1 'end)=результат какого-то макроса (m.ndx "1.end")

тогда и для 1.$currentRow=('index 1 currentRow) = (m.ndx "1.$currentRow")

тоже всё будет однородно.

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

сделай индекс списком: 1.end = ('index 1 'end)

Ага, стало в 3 раза длиннее и в 4 раза больше знаков препинания. Элегантность сшибает с ног. Моя версия состоит в том, что на чтение букв тратится гораздо больше ресурсов, чем на понимание. Представим себе, что нам нужно скомпилировать 1 кб исходников. Это быстро. А теперь представим себе, что нам надо скомпилировать 1 кб исходников, напечатанных в виде файла .png . Их надо сначала распознать программкой, а уже потом отдать компилятору. Затраты энергии на распознавание букв будут на порядки больше, чем затраты на собственно компиляцию.

То же и человек. Понимая программу, он читает её с экрана. Там, конечно, векторный процессор и бла-бла-бла, но затраты энергии на чтение велики. Количество смысла на странице - тем больше, чем лаконичнее текст. Я верю (пока не доказано обратное), что лаконичность языка кардинально влияет на производительность труда (при прочих равных). Поэтому удлинение втрое и увеличение числа знаков препинания вчетверо - это не годное решение.

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

Нет, наверное, насчёт гораздо больших затрат на чтение я загнул. Но, тем не менее, лаконичность всё равно влияет сильно.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от vasiliy-pupki

В scheme и racket обработка строк выглядит нелогично. В CL, кстати, лучше.

Использовать язык, развитием которого никто не занимается с 1994 года выглядит нелогично. В Racket, кстати, с этим лучше.

azelipupenko
()
Ответ на: комментарий от vasiliy-pupki

В нем гораздо меньше кода.

Исключительно потому, что search и substitute в стандартной библиотеке.

Впрочем, в scheme/racket я тоже могу написать (require srfi/13) и будет у меня встроенный string-index и string-map!.

Большая неотключаемая стандартная библиотека плоха тем, что даже если ей не пользуешься, она табуирует имена. Более 900 запретных имён, из-за того, что они есть в CL, это много.

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

Использовать язык, развитием которого никто не занимается с 1994 года выглядит нелогично.

A concise definition of the first partial edition of R7RS-large, known as the Red Edition, was made available in 2016. It is a frozen copy of the Red Edition ballot plus the names of the libraries, which were passed by unanimous consent. A single physical document is in preparation.

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

Кстати, что на аватарке?

Дзюбэй из «Манускрипта ниндзя».

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

Я верю (пока не доказано обратное), что лаконичность языка кардинально влияет на производительность труда (при прочих равных).

Тогда почему до сих пор не пишешь комментарии по-китайски?

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

Но в самом лиспе 1.2 = 1.200, т.е. напрямую синтаксис лиспа использовать нельзя.

Можно как в shelisp. Если (...), то внутри парсер лиспа, иначе парсим как строку и отдаём макросу. Можно селектор по имени или флагу (свойству символа) макроса прикрутить.

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

Для небольших работ это имеет смысл, дальше становится обузой.

почему «становится обузой»? ИМХО, наоборот — если не садиться кодить сразу в бой, в рукопашную с IDE с кодом, а сначала подумать, набросать какой-то план, подзадачи, зайчатки архитектуры.

всё равно получается некий «поток сознания», только записанный на «записках на манжетах». так почему бы не сразу его записывать в некоторый «грамотный» гипертекст (а не колбасить сразу код)?

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

из недостатков подхода «грамотного программирования» что я видел:

  • 1. ещё один макрогенератор сверху. сложно проследить соответствие исходных строк сгенерированным. в CLiP-style подходе это исправили, проследить просто.
  • 2. нужно изучать 4 отдельных языка: LitProg разметки, LaTeX разметки, собственно код и нечто для тестирования, скриптованного данными.

ну тут пытаются упростить: например, в том же Emacs org-mode есть а) вики-разметка, б) «блоки данных» (таблица, ящик, и т.п.) в) «блоки кода» с параметрами (частично выводимыми из «блоков данных»). вики-разметка сама по себе упрощает конкретный синтаксис разметки документации для заголовков, ссылок, таблиц, картинок. кроме того, в org-mode можно ввести несколько типов ссылок, какие угодно. вики-ссылки проще, чем обычные ссылки; проще гарантировать для вики-ссылок что они не указывают в никуда (как для обычных битых HTML или ref ссылок).

команда TANGLE в обычном LitProg WEB-средстве делает из «грамотного исходника» код из «блоков кода», собранный в нужном порядке программы (а не порядке «потока сознания»).

затем запускаются какие-то тесты (из того же TANGLE извлечённого кода). строятся графики, гистограммы, матрицы трассировки, ссылки на результаты тестирования :)

команда WEAVE теперь собирает доку из «потока сознания» с этими подставленными (графиками, глистограммами, результатами тестирования), с автогенерируемыми индексами про переменные и функции, классы, ссылки и оглавления :)

в CLiP пытаются упрощать тем, что: нет отдельных 4 языков, есть 4 уровня синтаксиса: (чем-то алгол напомнило с его W-грамматиками многоуровневыми :))

  • «блоки кода» и игнорируемая «какая-то фигня» (с описанием)
  • сегменты блоков кода
  • внутренняя структура сегментов
  • конкретный синтаксис

здесь AST — это первые три уровня из сущностей-строк (в лиспе будут сущности-списки), CST — последний уровень, который учитывает внутреннюю структуру этих строк.

CLiP в отличие от других LitProg WEB-средств НЕ ПЫТАЕТСЯ делать WEAVE, только TANGLE. также он не пытается переформатировать pretty print «блоки кода», подставляет как есть.

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

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

A concise definition of the first partial edition of R7RS-large, known as the Red Edition, was made available in 2016. It is a frozen copy of the Red Edition ballot plus the names of the libraries, which were passed by unanimous consent. A single physical document is in preparation.

Я в курсе, спасибо. Но с 1994 года не развивается Common Lisp.

azelipupenko
()
Ответ на: комментарий от anonymous

опять же, синтаксис CLiP очень простой по сравнению с другими LitProg WEB средствами :

  • * LitProg разметка пишется только в комментариях. в итоге LitProg исходник — это обычный исходник, в Word-е или в обычный текстовый исходник.
    • ** для лиспа это означает, что LitProg разметку со специальными комментариями можно исполнять в REPL
  • * «блоки кода» помечаются комментариями специального вида. у них могут быть опции.
    • ** например, #multiple для различных вариантов одного и того же гнезда.
      • *** вообще, сам pdf про clip_style.pdf — есть иллюстрация подхода Дейкстры и Вирта «метод последовательного уточнения»: см. пример. пишутся Абстрактные типы данных (TEXT_LINE = ABSTRACT), потом последовательно уточняются в RECORD, при этом уточняются и операции.

        более формализованное описание «метода последовательного уточнения» — в списке литературы этого pdf ([Wirth 1971/1974, Dijkstra 1974, Back 1980, Morris 1987] в обратном порядке, у Morris и Back более формализованная теория этого «метода последовательного уточнения».

      • *** собственно, ООП с АДТ и абстрактными интерфейсами — и потом конкретными реализациями (в лиспе — метаклассов и объектных протоколов родовых функций, т.е. более композабельное, чем обычное ООП)
  • * «блоки кода» нумеруются строками.

    вот тут вручную неудобно, нужен какой-то редактор с макросами (например, X2 / XWing по умолчанию переформатирует строки и комментарии(отключаемо в профиле); ну мог бы и определять, внутри «блока кода» ли он, либо просто в «потоке сознания» описания, и работать только внутри «блока кода». частично там что-то есть: например, если в комментарии писать новую строку Ctrl-Enter, то автоматически вставляются скобки комментария в новой строке. есть ещё пару макросов для нумерации строк в вертикальном блоке, в примерах xmacros.zip есть мини-электронная таблица на REXX (ну чем не org-mode на elisp с таблицами и формулами, а ? :)))

  • * всю остальную фигню с «потоком сознания» и описанием вполне можно писать хоть в обычном ворде.

CLiP-style средство «грамотного программирования» просто извлекает «блоки кода» ,и ничего не делает с индексами и оглавлением, и сильно упрощает разметку. просто пишутся специального вида комментарии.

синтаксис зело упрощён (вместо 4 отдельных синтаксисов отдельных языков — один с 4 уровнями 3 AST 1 CST), задачи упрощены (только извлечение «блоков кода» без индексов, pretty printing и прочей макрообработки).

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

«грамотная разметка» вида просто «комментарии особого вида» КОМПОЗАБЕЛЬНА! её можно исполнить в REPL, подставить в выражения, вложить в другой блок кода.

например, есть CLiP-style реализации на CL: erudite LP/lisp

wart — пример интерпретатора лиспа, написанного в «грамотной разметке»

собственно тезис в том, что как раз для более-менее крупных проектов подобную фигню в виде «грамотной разметки» и "формализованного" «потока сознания» как раз писать и проще, и понятнее — чем напрямую врукопашную бросаться сразу в IDE и кодить, а потом придти в какой-то логический тупик.

хотя хочется чего-то большего, каких-то подвижек в сторону Literate Programming IDE — чего-то смоллтокоподобного, где в IDE могут быть сразу виджеты-компоненты, которые в свою очередь как-то связаны с моделями и метамоделями «блоков кода» и «блоков данных» в единую фреймовую :) ООП сеть через MVC/MVP, с наследованием, метаклассами и МОП — с автовыводом и параметрическим синтезом!

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

потом как-то это всё композабельно обрабатывать.

ну типа как Notebook в Mathematica. вот кстати, нормальный пример композабельности того, о чём тут говорю — все эти составные типы связаны в единый векторный тензорный гипертекст не элементарных, но составных типов, объектов, контейнеров — и всё это вживую вычисляется в каком-то реактивно-лайвкодинговом многомерном гипертекстовом виде!!!

кстати, на сайте той же Wolfram Mathematica есть и довольно большие проекты в таком вот стиле. (например)

вместо такого вот могла бы быть и разметка на S-выражениях типа Erudite.

tl;drне сказал бы, что только для небольших примеров это пригодится, скорее наоборот: чем больше проект, тем нужней там подход «грамотного программирования».

anonymous
()
Ответ на: комментарий от den73

в общем-то F12 в браузере очень много из него взяли. Да, многое криво (в т.ч. на концептуальном уровне).

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

нечто в духе интерфейса Compound Doc в BlackBox Component Pascal, BlackBox Component Framework (BCF): там можно в текст вставлять контейнеры, виджеты (причём виджет может быть контейнером), гиперссылки (на команды модуля-виджета), «командеры» которые интерпретируют содержимое следующей строки / контейнера/whatever.

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

вот «потом» больше всего и интересует. например, составить индекс переменных, функций, классов, символов и т.п.

сделать что-то большее, чем просто открыть исходник и пялиться туда глазами — например, обработать какой-то моделью и отрефакторить полуавтоматически, а потом edit-and-continue

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

И дальше могли победить только языки, совместимые по семантике и с похожим синтаксисом на C или Basic.

ну вот почему не победил например, Basic-подобный REXX с ОО расширениями типа ooREXX, а тот же питон с батарейками?

и тот, и этот — бейсик бейсиком.

Либо язык должен быть или быстрее C++

опять же, неясно Ada / Modula-2 / Oberon-2 vs. C++. просто нравится curly-braced language?

или компактней и более читабелен (без знания языка) чем Javascript или Basic.

то есть, это просто привычка к синтаксису и инерция мышления?

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

Слушай, ну ты горазд грузить! Здесь вообще речь про синтаксис, и кстати, тему можно закрывать. Синтаксис Red не понравился мне. Могу сказать про Mathematica, с которой работал довольно плотно. Правда, версии 4. И про BlackBox.

Что плохо в Mathematica - отсутствовал (на тот момент) всякий аналог go to source. Я глаза посадил конкретно с ней, потом переписал всё на CL (конечно, с потерей гибкости, но для той программы это было приемлемо). В любом интерфейсе а-ля notebook с image-based development есть ловушка, что ты определил функцию, сослался на неё, стёр исходник, а функция в памяти осталась. При отсутствии указания, что вот эта функция должны быть в этом файле отловить эту ошибку до перезапуска образа невозможно.

Касаемо BBCB, круто, что можно вставить коммандеры, но зато потом такой текст нельзя сохранить в файл. Когда я заинтересовался одно время BBCB, я первое, что захотел - это возможность сериализовать тамошние модули для хранения в системе контроля версий как текст. Мы там конкретно упёрлись в этом месте в тупик. Раскраску нормальным образом нельзя сохранить. Хотя если поставить ограничения, что раскрашивается только токен лексера целиком, то тогда можно с помощью комментариев её выражать.

COM-объект, образующие граф с внутренними указателями, тем более нельзя сериализовать. Т.е. исходник BBCB нельзя выдрать из BBCB и это ад (или нужно писать свой diff, свой patch, свой git).

Кроме того, наличием коммандеров они (сектанты) оправдывают отсутствие консольного REPL. Но эргономика у коммандеров, по сравнению с REPL, мягко говоря, прихрамывает.

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

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

причём, производитель клиппера скупил производителя компилятора модулы-2. какое-то время ещё потрепыхался, а потом сдох (похоронив под собой вполне пристойную реализацию модулы-2)

сам как язык клиппер вообще-то очень даже ничего... а dBase горбуха та ещё.

Infocom, кстати, не только игрушки текстовые писал, типа Zork-a. ещё они пытались сделать СУБД CornerStone с ЕЯ интерфейсом, но надорвались:

из обзоров того времени: «хотя база и продвинута, удобна в использовании и всё такое, во-первых, дороговата за $500, во-вторых тормозит, а в-третьих нифига не программируется, ну вот вообще (в отличие от той же dBASE с её дурацким недоязычком)»

а если бы они прикрутили бы туда какие-то хранимки и язык запросов, да хоть тот же LISP MDL, Muddle (а в перспективе и человекопонятный естественноязычный mud-подобное) — ещё могли бы потрепыхаться, редиски такие.

anonymous
()
Ответ на: комментарий от den73

ввести списки вида

integer    1234
decimal    12.34
string     "REBOL world!"
time       13:47:02
date       30-June-1957
tuple      199.4.80.1
money      $12.49
pair       100x200
char       #"A"
binary     #{ab82408b}
email      info@rebol.com
issue      #707-467-8000
tag        <IMG SRC="xray.jpg">
file       %xray.jpg
url        http://www.rebol.com/
block      [milk bread butter]

alist? с символом-предикатом типа?

('list
 ('integer 1234r10)
 ('decimal 1.234); not ambigous decimal/tuple because pair properly
 ('string ("just a string"))
 ('string (interpolate-string " a $interpolated string"))
 ('string (concat-string "a " interpolated " string"))
 ('time (make-time (parse-time "12:34:56")))
 ('time (make-time (parse-other-time 123456)))
 ('time (make-time (parse-time "12:34:56" :timezone "GMT+3")))
 ('date (make-date (parse-date "30-June-1957"))
 ('date (make-date (parse-date "Jun-30-1957" :format 'US :tz 'Moscow)))
 ('tuple (make-tuple (parse-tuple "199.4.80.1")))
 ('tuple (make-tuple :from-list (199 4 80 1)))
 ('money (make-money (parse-money "$12.49")))
 ('money (make-money (parse-money "$12.49" :currency 'USD :target-currency RUB :exchange-rate CURRENT-USDRUB)))
 ('pair   (make-tuple (parse-tuple (split   "100x200" "x" ))))
 ('pair   (make-tuple (parse-tuple (100 200))))
 ('pair   (make-tuple :from-list (100 200)))
 ;или оставить всё-таки отдельный тип для pair. он-то нужен чтобы не спутать
 ;'decimal, 'tuple и 'pair
 ('chair "A")
 ('binary ab82408b)
 ('binary (make-binary (parse-binary "#{ab82408b}")))
 ('email (make-email (parse-email "info@rebol.com")))
 ('email :kind netmail (make-netmail (parse-netmail "2:123/456.789")))
 ('issue  (make-rebol-issuetracker-issue (parse-issue    "#707-467-8000")))
 ('tag (make-tag (parse-tag "<IMG SRC=\"xray.jpg\">")))
 ('tag (make-tag (parse-tuple "IMG.SRC.'xray.jpg'")))
 ('tag (make-tag (make-type :from-list ('IMG ('src "xray.jpg")))))
 ('file     (make-file "%xray.jpg"))
 ('file  #P"xray.jpg")
 ('file (get-wiki-link (make-wiki-link :from-string "[ЛУЧИ СМЕРТИ|xray.jpg]")))
 ('url   (make-url (parse-url "http://www.rebol.com/")))
 ('url   (make-url (parse-url "http://www.rebol.com/" :protocol 'http)))
 ('url   (make-url (parse-url "gopher://www.rebol.com/" :protocol 'gopher )))
 ('url  (make-url (get-wiki-link (make-wiki-link :from-string "[РЕБОЛ|http://www.rebol.com"))))
 ('url  (get-my-wiki-link-for 'REBOL))
 ('block (make-block (parse-block "[milk bread butter]")))
 ('block  (make-block :from-list ('milk 'bread 'butter)))

ну и т.п.

некузяво, конечно с этим ('foo (make-foo (parse-rebol-expression «foo»)))

но композабельно.

можно под это дело и макрос написать, композирующий :)

или макрос, пишуший макрос :))

anonymous
()
Ответ на: комментарий от den73

но ведь дело не в количестве знаков препинания (морфем), и не в количестве звуков (фонем), а в количестве смыслов (семем)?

и даже не в количестве, а в качестве?

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

хотя попрограммировать на иероглифах было бы прикольно.

но, скорее, нужны руны — один знак с наиболее точным смыслом, но позволяющий составлять другие руны в заклинания :)))

ребол для этого вводит диалекты — считая что толмач не требуется :) хотя это просто блок символов и значений (которых много, да) — контекстно-зависимых от интерпретатора диалекта.

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

не всегда. можно убирая одну букву «Ѣ» такого напутать, что приведёт к путанице в падежах, неоднозначности, к не той семеме — и путанице в смыслах. «кто на ком стоял» и о чём это они вообще.

то есть: не любой лаконичный текст композабельный (без знания контекста).

вопрос, эти поясняющие контекст слова — это слова языка или метаязыка уже.

anonymous
()
Ответ на: комментарий от den73

Я верю (пока не доказано обратное), что лаконичность языка кардинально влияет на производительность труда (при прочих равных). Поэтому удлинение втрое и увеличение числа знаков препинания вчетверо - это не годное решение.

Восхваляемый тобой tcl никак не назовешь лаконичным. Может в сравнении с лиспом он таким тебе кажется, но это же самый многословный скриптовый язык, хотя и чистенький. Я считаю это одна из главных причин его непопулярности. Так что ты вроде правильно рассуждаешь, но тянет тебя ко всякой пардон параше.

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

Какие лаконичнее? Нужно ещё посчитать макросы, которые в тикле, по сути, есть (можно даже сказать, fexpr-ы).

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

хотя попрограммировать на иероглифах было бы прикольно.

Да. Иконки на рабочем столе и тулбаре - это как раз эрзац-иероглифы.

ввести списки вида

Не, я чиню не ребол, а tcl :)

но ведь дело не в количестве знаков препинания (морфем), и не в количестве звуков (фонем), а в количестве смыслов (семем)?

Как я уже написал, что морфемы очень дороги на этапе чтения с экрана. Поэтому в них дело тоже.

ребол для этого вводит диалекты — считая что толмач не требуется :) хотя это просто блок символов и значений (которых много, да) — контекстно-зависимых от интерпретатора диалекта.

А что, там в рамках диалекта можно отменить форматы по умолчанию, т.е. сделать, чтобы 18-January-2001 было не датой?

то есть: не любой лаконичный текст композабельный (без знания контекста).

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

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

Basic-подобный REXX с ОО расширениями типа ooREXX

А он разве был где-то кроме OS/2? Питон-то сразу переносимым писали.

опять же, неясно Ada / Modula-2 / Oberon-2 vs. C++. просто нравится curly-braced language?

STL позволяет инлайнить код для контейнеров. В Modula-2 и Oberon-2 аналогов, насколько я знаю, нет. В Ada требования стандарта не позволяют оптимизировать настолько агрессивно, как это возможно в C++. Поэтому gnat выдаёт код в среднем в два раза медленней, чем g++.

то есть, это просто привычка к синтаксису и инерция мышления?

Именно так. Писать на Haskell большую часть типовых задач легче. Но если до этого изучал только Java/C++/assembler, то пару месяцев уходит, чтобы правильно перевернуть восприятие в голове.

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

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

опять же, неясно Ada / Modula-2 / Oberon-2 vs. C++. просто нравится curly-braced language?

Терехов сказал, что за С стоял AT&T - титан отрасли и ветеран разведки :) Вот и весь секрет.

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

хотя попрограммировать на иероглифах было бы прикольно.

Есть языки APL, J, K.

Например,

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
import java.util.Arrays;
 
public class LetterFreq {
	public static int[] countLetters(String filename) throws IOException{
		int[] freqs = new int[26];
		BufferedReader in = new BufferedReader(new FileReader(filename));
		String line;
		while((line = in.readLine()) != null){
			line = line.toUpperCase();
			for(char ch:line.toCharArray()){
				if(Character.isLetter(ch)){
					freqs[ch - 'A']++;
				}
			}
		}
		in.close();
		return freqs;
	}
 
	public static void main(String[] args) throws IOException{
		System.out.println(Arrays.toString(countLetters("filename.txt")));
	}
}

превращается в

APL:
freq←{(⍪∪⍵),+/(∪⍵)∘.⍷⍵}

J:
ltrfreq=: 3 : 0
  letters=. u: 65 + i.26  NB. upper case letters
  <: #/.~ letters (, -. -.~) toupper fread y  
)

K:
+(?a;#:'=a:,/0:`)

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

Какие лаконичнее?

Любые си-подобные. Зацени foo[bar[x]] против dict get $foo [dict get $bar $x]. Гомоиконность небесплатна, и синтаксис не просто так придумали из вредности. Это только лисп-машине пофиг сколько букафф ворочать. А у человеков страшный ужасный перл в тысячи раз популярнее няшного тикля.

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