Как стать автором
Обновить

Комментарии 130

Глаголы — это как в хаскеле point-free нотация, это круто; только, если переменных несколько, то начинается ад, чтобы растасовать их по нужным операциям.
Жесть! Это как программирование через регулярные выражения…
Нет, вы меня не заставите! Больше никогда!
Я такие языки называю «Write-only language» (WoL). Пояснять, думаю, не надо.
Есть WoL и среди популярных языков — XSL и regexp.
В некоторых клинических случаях и SQL в него превращается, несмотря на максимальную близость к естественным языкам.
Наверное не совсем донес идею, а наоборот испугал непонятным кодом.

Он не такой уже непонятный. Чтобы понимать язык, нужно знать его слова. Джей по словам-примитивам намного богаче, чем привычные языки программирования. Например, никого не убивает в С++, операция >>, или ++, или просто скобки {}, служебное слово class и тому подобное.
Также и здесь.
Я в посте хотел объяснить именно эту логику, потому что люди думают эмоциями в таких случаях. Если вас пугает синтаксис, то это где-то аналогично, как пугаться иностранного языка и думать, что им пользуются дураки только – он же на ваш родной не похож. Это «попроще» — просто ваши ожидания от языка. Вам хочется, чтобы он сразу был понятен. Не изучая слова. Но тогда, он либо должен быть похож на естественный язык, причем желательно родной (а таких нет еще), либо не содержать слов, а позволять их побольше самому писать. В этом случае, заметьте, что вы бъете по своим воротам. Разве не надоело в каждой новой компании разбиратьяс я с новым методом DoSomethingEveryYearBefore2012? Слова понятны, но они не из языка программирования – это наносное. А наносят бог весть что. И каждый раз нет претензий к самому языку, претензии только к предыдущим именователям.
Ожидания от языка, которого вы не знаете, не всегда играют хорошую роль. Этих глаголов здесь штук 150 и за долгое время работы они становятся узнаваемыми. Правила комбинирования глаголов довольно простые. Поэтому, еще очень спорный вопрос, на каком языке код понятнее.
Далее, наиболее важный плюс джея – это работа с многомерными массивами. Т.е. представьте себе алгоритмическую сторону ваших программ. Вам часто надо создать массив. Тут делается элементарно. Хотите траспонировать? |: без проблем. Хотите развернуть список/массив. |. без проблем. Хотите уникальные элементы найти? ~. без проблем. Вот эти маленькие комбинации избавляют вас от кучи кода в других языках и вы мыслите совсем на другом уровне. Код без циклов, практически, вы только вращаете кубы, клеите их, находите пересечения, проекции – что угодно. А то, что эти операции обозначаются значками – это во-первых кода меньше, а во-вторых не особо им из нашего мира дашь подходящее название. Это векторно-массивные операции. Которыми можно легко выражать почти любой алгоритм.
Он не такой уже непонятный. Чтобы понимать язык, нужно знать его слова. Джей по словам-примитивам намного богаче, чем привычные языки программирования. Например, никого не убивает в С++, операция >>, или ++, или просто скобки {}, служебное слово class и тому подобное.
Также и здесь.

Позволю с вами не согласиться.
isVar =: [:(91&>*.64&<)[:a.&i.[:{.>
replace =: ((]i.~[:{.[){([:{:[),]`([:<[$:[:>])@.([:32&=[:3!:0[:>]))«2 0
gp =: [:>[:{.>
gv =: [:(#~[:+./»1 isVar«0),.
suit =: ([(0:`(([:(#=[:#[:~.[:{.|:)[:~.[:(#~[:-.[:isVar»0[:{:|:)gv)*.([:*./[:+./[:(isVar«0,=/),:))@.(([:#[)=[:#]))[:gp])»1 0#]
sr =: [(](replace~[:|:])«2[:(([:-.[:isVar{:)»1#])[gv~[:gp])«1 0 suit
groupVars =: [:([:<]$~2:,~[:-:#)»1[:>[:([:<[:;(>@[)([:<,«1 1)»1 2(>@]))/]</.~[:{.|:
isRuleTrue =: ([:+./([:*./](isTrue~[:>])«1 0[:>[)»0 1)`(0:<[:#getVarsFromRule)@.(0:<#@gv@;@;@[)
isTrue =: ]((a:&e.@])+.[:+./[(isRuleTrue~[:>])«1 0[:-.&a:])[:{:[:|:[:-.&(a:,a:)[:(0 2$a:)&,[:>sr
getVars =: ;(([:<[:~.(>@{.@[)gv[:gp])`((>@{.@[)$:(<@<@gp@])([replace~[:|:[:>])»0 0(}.@[)getVarsFromRule~[:>[:{:[:>])@.([:<:[:#[:>]))«1 0 sr
getVarsFromRule =: ](([:{.])#~[(isRuleTrue~[:>])»1 0[:{:])[:|:[(],[:<[replace~[:|:[:>])«1 0[:]`groupVars@.(0:<#)[:~.[:;[:;]([:<[getVars~[:>])»1 0[:;[

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

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

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


В отношении джея это утверждение для меня не очевидно. А личный опыт говорит об обратном.
Люди говорят, что в Лиспе скобки — самое вкусное. И что это круто. Я их не понимаю, потому как глазами разбирать, где какая скобка закрывается — мне неуютно. Джей же как раз наоборот — эргономичен. Вилки и крючки (правила построения выражений) как раз минимизируют скобки, позволяют писать и читать линейно сложные алгоритмы, а не только последовательные преобразования.

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

Кстати, в этом тоже плюс джея. На нем можно достаточно легко написать вот такие длинные большие штуки и они работают. И не париться. Там внизу писали, что джей используется когда много данных и мало времени. Это отчасти верно. Джей — он как инструмент для быстрой обработки данных, здесь и сейчас. Иногда и не надо ничего рефакторить, возможно, это одноразовый был бы код в реальной задаче.
>В отношении джея это утверждение для меня не очевидно.

Оно очевидно хотя бы тем, что мозг человека не умеет распознавать число «закорючек». Не важно, скобки это или крючки. Только медленным пересчётом по одной. Из-за этой особенности и родилось структурное программирование, которое позволяет разделить блоки визуально на порядки ускоряя распознавание структуры. Вы же в J от этого принципа отходите, на чём сильно проигрываете в анализе кода.
Эргономичность языка программирования сильно зависит от IDE, в которой на нём пишут. Читабельность «функционального стиля» на Java1.6+GoogleCollections сильно больше в IDE, чем в без неё. Особенно это видно при сравнении такого стиля с работой через традиционные циклы — с IDE писать «функционально» и читать «функциональный» код становится лучше и проще по сравнению с ними.
Я знаю синтаксис с++ подобного языка программирования.
Если мне понадобится найти велосипедный алгоритм, я пойму любой из языков, похожий на с++, java, c#, as3, pascal и прочие. Я смогу использовать найденный код, даже если придется его переписать.
Если взять ваш пример с языками, то с++ подобные языки — русский, белорусский, украинский. Язык J в таком случае можно отнести к китайскому.
Язык J в таком случае можно отнести к китайскому.
Язык J в таком случае претендует на место Ithkuil'a или даже чего-то более мощного…
А вам не очевидно, что я, например, вполне себе читаю, иначе бы просто не смог бы написать сколько кода write-only?

isVar =: [:(91&>*.64&<)[:a.&i.[:{.>

Отрыть коробку, взять первый элемент со списка (символ), узнать его номер в алфавите (ASCII), и истина, если он входит в интервал — (91;64) — и называется isVar. Вспоминаем, что в прологе переменные пишутся с большой буквы.
Читается такой код элементарно, никаких хитростей нет. Просто надо знать эти элементарные глаголы и правила построения выражений.
Скажите, а какой современный язык программирования вам не знаком? Готов поспорить, что если такой есть, вы легко сможете понять по коду о чем речь в принципе.
Теперь возьмем разработчика на этом языке и покажем ему программу на J.
<реакцию вы и так знаете>

Теперь надеюсь понятно, в чем разница?

Но, в любом случае спасибо вам за статью, очень полезно бывает расширить кругозор.
C#, допустим.
Готов поспорить, что если бы программист написал методами или в одном методе код, то в любом случае этот код выше читается намного проще. Просто пройтись глазами справа налево.
И это простенький глагол. Если бы написали побольше алгоритм, то мне только на небо надо было бы надеяться, что программист, назвав как-то метод в другом классе в другом файле, делает в том методе то, что говорит его название. Если оно говорит.

Только linq где-то сравнится с джеем, но оно не достаточно мощное, кода раза в 4 будет больше обычно. И более захламлен точками, скобками методов, ненужным именами параметров.

А вообще, где-то похоже по ощущениям. На джее вообще, ощущения как и на SQL. Только на последнем реально бывает очень тяжело выразить довольно простые мысли, в отличии от джея. Где-то в мозгах так же на SQL комбинируете множества, как и на джее, но там сложности из-за отсутствия упорядоченности, индексного доступа. На джее же всё пишется легко.
Простите, но синтаксис языка J сделан не для людей. Например: глагол деления — %, запись отрицательных чисел — _4, _10, глагол вычисления корня — %:
Это контринтуитивно. И мне, как математику и программисту, запись
max(a) + sum(a)/len(a)

понятнее, проще для поддержки и поиска ошибок, чем
d =: >./++/%#
d a
позвольте возразить )

На счет выбора знаков, почему именно эти — я не в курсе истории. Наверняка были на то причины.

Но вот это:
max(a) + sum(a)/len(a)
понятно, пока оно просто. А так:
sum(a)/len(a) + max(a)
Тоже понятно. Тогда так:
sum(a)/len(a)<<2 + max(a) Упс, уже надо смотреть приоритеты.
А если надо к сумме добавить максимальное, а потом всё поделить? Только скобки. Когда как в джее всего лишь меняются местами операции. Если выражения усложняются, то вам как математику и программисту на каком-то уровне придется пойти покурить и передохнуть, чтобы понять длинное выражение со скобочками.

В этом то и плюс джея — вилки и крючки. И отсутствие приоритета операций. Именно это и позволяет писать большие выражения, а потом так же их легко читать. Вам сейчас просто кажется из-за незнания синтаксиса, что там ужас написан. Но привыкнув к нему, он начинает давать профит. В лиспе, например, тоже передумали писать, как привыкли математики. И не для усложнения, а для упрощения.
Позвольте возразить. Вы постоянно говорите, что после многолетнего опыта языка J можете легко читать сложные выражения, так вот программисту достаточно неделю учить язык Python, чтобы прочитать вот это

[ days[i:i+7] for i in range(0, len(days), 7) ]


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

В современных языках как раз избегают писать длинные выражения в одну строку. Гораздо понятнее и удобнее разбивать сложный алгоритм на несколько более простых, которые затем комбинируются понятными операторами.
В языке J наоборот стараются много действий закодировать в короткой записи. Только встаёт вопрос отладки таких программ. Как быстро вы сможете найти ошибку в следующем алгоритме?

s =: ({. , }. /: 12"_ o. }. - {.) @: /:~
g =: _2: }. 0: > (-~1&|.) 11&0.@:* +@:(-~ 2&|.)
r =: (1"_ , g , 1"_) # ]
hull2 =: [: r^:_ s

Подсказка: это алгоритм нахождения выпуклой оболочки ;)
В современных языках как раз избегают писать длинные выражения в одну строку. Гораздо понятнее и удобнее разбивать сложный алгоритм на несколько более простых, которые затем комбинируются понятными операторами.

Так это не недостаток джея, а преимущество.
Разбивают код на куски, когда внимание не справляется. Чем лучше сделан язык, чем меньше напрягается внимание при чтении, тем бОльшие куски способен программист «обработать» за раз. Слишком много маленьких кусков — каждый может и понятен, но на уровень выше проблема — слишком много кусков.

В общем, джей позволяет писать бОльшими кусками и не запрещает разбивать на меньшие.

Как быстро вы сможете найти ошибку в следующем алгоритме?

Плотно в проектах я давно с джеем работал. С тех пор развилось IDE хорошо, появились какие-то средства отладки. Но вообще, ни разу как-то не видел надобности в таких средствах. Действительно, через время пишется на этом языке легко. А в побольше проектах надежность кода гарантируется как обычно — юнит-тестами.
Странно, за что столько минусов? Где я не логичен?

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

То, что вы критикуете, что программист пишет большую часть логики в одном предложении, так это потому, что для него так комфортно писать, что есть, несомненно, плюсом. И ваша критика основывается только на непонимании, почему этот программист понимает этот код. А именно, не знание глаголов и правил построения. Вам кажется тот код сложным? Чистый и простой код. Просто обратите внимание на скобки. Их много? Нет. Если их не много, то внутри код читается линейно. Давайте разберем первое:
s =: ({., }. /: 12"_ o. }. — {.) @: /:~

справа налево. Первый глагол:
/:~
Обозначает отсортировать по возрастанию. Тут наверное вектор, т.к. в задаче вектор. Я давно статью читал и вообще в код не вникаю сейчас, с нуля разбираем. Сортировка — понятно, что это такое.
Далее союз @: — говорит, что после сортировки надо делать то, что в скобках.
В скобках берем три первых (с конца) глагола:
}. — {.
Отсечь голову вектора (списка) и от этого получившегося списка отнять голову.
Следующие два глагола берем:
12"_ o. }. — {.
Сначала выполняется первый левый, потом тот, что посредине, берет правую (уже вычисленную раннее) и левую часть.
12"_ — это хитрый глагол, порождающий константу (12), вне зависимости от аргументов. Просто число не подошло бы, т.к. требуется глагол, а не существительное. Т.е. по сути, далее, если в прямом режиме, без глаголов писать, то выполнится выражение:
12 o. к нашему обрезанному и отнятому списку
12 o. — это поиск угла комплексного числа. К списку применяется, значит там список комплексных чисел — применится к каждому. Берем новые два глагола:
}. /: 12"_ o. }. — {.
То же самое. Сразу левый выполняем — отрезать голову исходному отсортированному (за скобками вначале) списку. И диадный глагол сортировки — это значит, что находим перестановку для углов справа и в этом порядке располагаем список слева. Т.е. перемещаем все комплексные числа так, чтобы углы, если их взять, были отсортированы.
Снова берем два глагола:
{. ,}. /: 12"_ o. }. — {.
Взять голову отсортированного списка и запятой приклеить к списку справа — т.е. отсортированному (без головы)

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

Я полагаю, дело в том, что, например (если я правильно понял ваше объяснение) такой код:

def order(numbers: List[Complex]): List[Complex] = {
  val minimal = numbers.min
  numbers.sortBy(number => abs(number.phase - minimal.phase))
}


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

А код, который вы только что разобрали, непонятен не только непосвящённым (вот откуда можно понять, что 12 o . — это взятие фазы комплексного числа, а?), но я боюсь, и начинающим изучать J тоже.
Этот код, который написан, понятен и да, он больше. Но он понятен, но не использует по всей видимости только изначальные языковые вещи. (Я не знаю Питон).
sortBy — это скорее уже библиотечная функция, как и тип List, даже если они из коробки.

Почему это важно? Потому что я показал разбор только одной строки, которая удачно, только с сортировкой связана. На джее таким же образом можно сделать всё. Кстати, у вас голова не вычитается, это меняет алгоритм, потому как 0 может получиться не только у самого себя, но и у точек на одной линии. Далее, вы не сортируете углы относительно минимальной точки. Вы сортируете углы относительно 0+j0, просто отняв угол минимальной точки и взяв абсолютное значение. Это был тест, насколько я пойму код другого неизвестного языка?

На джее, аналогичный вашему код будет поменьше:

s =: /:[:|-/12"_ o.],:<./


И специально, для ненавидящих таситную форму джея и любителей абстракций, то же самое в экслисит форме с именами, чтобы не раздражали значки глаз:
min =: <./
angle =: 12&o.
sortBy =: /:
abs =: |

s =: monad define
   y sortBy abs
(angle y) (angle min y)
)



Как видите, этот код не хуже вашего питоновского, но он все же хуже того, что в таситной форме как по мне.
Почему 12 выбрано? Это к создателям джея. Это язык такой, что там элеметнарным глаголам имена не раздаются направо и налево. o. применяется для разных случаев.
Я извините, не внимателен. Scala, а не Питон.
Далее, вы не сортируете углы относительно минимальной точки. Вы сортируете углы относительно 0+j0, просто отняв угол минимальной точки и взяв абсолютное значение.

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

Что такое «сортировка углов относительно минимальной точки» также не совсем понятно. Для меня эта фраза означает «сортировка значений углов по метрике в R относительно угла минимальной точки», и это именно то, что я написал.

Но он понятен, но не использует по всей видимости только изначальные языковые вещи. (Я не знаю Питон).
sortBy — это скорее уже библиотечная функция, как и тип List, даже если они из коробки.

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

Я опять не понял, что вы хотели сказать. Вы имеете в виду, что те глаголы, которые использу.ются в примере, встроены в язык, а типы и методы вроде List и sortBy являются частью стандартной библиотеки? А какая разница? Из Scala стандартную библиотеку убрать нельзя в принципе, поэтому классы коллекций вполне можно считать частью языка как платформы. Я не вижу существенной разницы этого с наличием встроенного в язык функционала, разве что последнее менее гибко.

o. применяется для разных случаев.
Есть такой очень важный принцип, особенно в обучении. Называется «принцип наименьшего удивления». Когда я вижу sortBy, я могу с достаточной долей уверенности предполагать, что это какой-то вариант сортировки. Приставка By также намекает, что мы будем указывать то, с помощью чего нужно сортировать. То же самое с фазой комплексного числа: minimal.phase, особенно в контексте того, что minimal имеет тип Complex, однозначно говорит, что мы хотим взять значение фазы. 12 o., к сожалению, об этом говорит чуть менее, чем никак. Особенно если учесть, что, судя по всему, 13 o. и 11 o. будут делать что-то совершенно другое, если это вообще будут корректные выражения.

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

Разница небольшая, но есть. Просто я показал как разобрать удачную для Scalа строку джея. Но джей с нуля позволяет и другие, неудобные для других языков вещи писать кратко. Все таки — это работа с многомерными массивами, а не списками.
Вот, расскажу, что делается в предыдущем примере в этом коде. Хотя код аналогичен вашему, но мог бы быть и другим.
s =: /:[:|-/12"_ o.],:<./


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

3 7 8 2 9
2 2 2 2 2
Найти у каждого элемента угол. И отнять от второй строки первую. Далее, найти перестановку для сортировки этого массива и применить эту сортировку к исходному массиву.

Да, это Спарта. Но в джее мышление немного как бы шире списков. Этим он и прекрасен.

То, что там непонятные значки, так это из-за таситности записи. Из-за крючков и вилок. Значок легко пишется рядом с другим и несложно отличается. Если бы была надобность только буквенные названия глаголам писать — это как раз был бы ад. Никакой таситной формы бы не получилось. Между каждым надо пробел, имена длинные — какая же тогда вилка или крючек? Три глагола — и приехали, строка закончилась.

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

Потом, эти значки — это операции с массивами, а не привычные нашему ООП-мозгу названия из нашего реального мира. Тяжело им названия подавать и чтобы они были более понятные чем значки. Тут нет объекта птичка или бизнес-правило. Если soryBy еще куда ни шло, то там есть и похитрее операции. Плюс к этому, джеист мыслит этими многомерными массивами, его воображаемая очевидность для вас будет совсем не очевидна, даже если он назовет.

Однажды меня попросили описать алгоритм для документа, это была жесть. Мне надо было или врать, или говорить: берем 6-ранговый массив, меняем 3 ранг с пятым и находим проекцию на вектор с операцией агрегации такой-то. Технический писатель отказалась переводить и оформлять этот документ.

Так что тяжело в учении — легко в бою. Эти значки — неплохая и вынужденная вещь. Я думаю, было бы лучше, если бы там были по одному символу на глагол значки и какие-то покрасивее, чтобы картинка подсказывала, что за операция. Но клавиатуры не позволяют. И вообще, это не критичная проблема. За неделю можно заучить все эти комбинации.

НЛО прилетело и опубликовало эту надпись здесь
А, я не понял вопрос правильно, понял как общий вопрос, сколько бы я искал ошибку в коде джея такого объема.

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

11&0. — это свалит джей, т.к. нет глагола с цифрой ноль и точкой. буква о с точкой есть. Если вы сюда внесли ошибку. Вообще эта «хитрость» с нулем ищется почти мгновенно, если это в IDE перенести. Глагол о. зеленым рисуется, цифра фиолетовым. Т.е. даже если шрифты бы были неудобные

И читается он также легко.
Второй глагол (g) описывать не буду, т.к. голова у читающих сломается. Там два сдвига вектора, на один и два элемента, разности с исходными, поиск сопряженного, перемножение их, нахождение углов, проверка, меньше углы нуля и отрезать два с хвоста. Всё читается, много логики, а что за логика, надо смотреть — зачем это в алгоритме. Этот глагол вычисляет булевский вектор. Если вас пугает такая сложность и много логики в этом глаголе, то представьте себе этот код на Си. Он не будет понятнее. Сложный алгоритм и останется сложным, для тех, кто не понимает, зачем производятся такие действия (не знает алгоритма) и такой математики, допустим, что такое сопряженное число.

Третий глагол добавляет единицы в голову и хвост вектору, который вернул второй глагол g. Он возвращал без двух элементов, этот глагол их добавляет. И применяет вектор как фильтр к аргументу.

Ну и последний: применяет s — т.е. сортирует по углам исходный вектор. А далее, применяет r в цикле, до тех пор, пока вектор не перестанет меняться.

Неясность моего описания связана только со сложностью алгоритма, а не с джеем. Джей ничего не усложняет
В этом то и плюс джея — вилки и крючки. И отсутствие приоритета операций.


Тогда куда приятнее Forth. Отсутствие приоритета при отсутствии «вилок и крючков» :) А программы мало того, что прекрасно читаются, так ещё самодокументируемость считается важнейшим атрибутом «thinking forth». В J же писать самодокументирующиеся программы, как я понимаю, вообще невозможно. Соответственно, придётся тратить время сперва на параллельное документирование, потом, время спустя — на синхронизацию комментариев и изменений.
C++, кстати, тоже многими и давно считается «Write-only language»… В С++11 что-то улучшили, правда…
НЛО прилетело и опубликовало эту надпись здесь
Да, я согласен, что язык состоит из слов и их можно выучить.Но есть важное отличие J от всех современных высокоуровневых языков. Все современные языки как раз таки стараются быть похожими на естественный, и двигаются в этом направлении (например C->C++->C#). Таким образом, программист на Delphi не особо напрягаясь может понять программу на C++, хотя бы концептуально, даже если никогда на плюсах ни строчки не написал.

Понять J не зная его — невозможно.

И второй момент — комментарии. Я не представляю как в эту адовую конструкцию их вставить. Раскроете тайну?
а, да. Комментарии нужны, просто я хотел кпд языка показать. Обычно, под каждый глагол аннотацию желательно писать. Потому как глаголы обобщенные, но часто при создании глагола программист какие-то ожидания на них вешает, тип массива например. Вот, в isVar нужно передавать бокс с текстовой строкой. Хотя, из тела видно, но можно, обычно пишут.

Комментарий после NB.

Не особо плюсы или шарп и естественные. Они позволяют просто давать имена. А ООП ближе к естественному мышлению, чем массивное программирование. Но имена и здесь в джее хорошо даются глаголам, можно и классы писать. Никакой разницы в этом нет. Просто джей позволяет это делать меньше. Хотите, делайте очень маленькие простые глаголы и каждому давайте имя. Будет как в С++
Вы одержимы идеей минимализации кода, причем в очень болезненной форме. Когда я прочитал в этом году замечательную книжку про Haskell (дада, ту самую, со слоником) и крайне впечатлился его элегантностью и экспрессивностью мне тоже стало противно писать длинные конструкции на других языка, вспоминая, как легко то же самое можно выразить на Haskell какой-нибудь простенькой композицей функций. Вот только Haskell при этом действительно остается читаемым (если не перебарщивать символьными операторами и хорошо структурировать свой код), а J — это просто набор закорючек, которые превартятся в тыкву, как только их попытается прочитать человек отличный от того, кто их написал.
делайте очень маленькие простые глаголы и каждому давайте имя
Изрядная морока — 60% рабочего времени придумывать имена, причём уникальные, причем непонятно в каком scope-е уникальные…
SQL я вообще не смотрю без Notepad++ с PoorMan'sSQLFormatter…
regexp
Ага, без переменных и констант любой язык стал бы «Write-only»…
вел у нас факультет по программированию в далеком 87 году странный дядечка, мы к нему ходили на ВЦ программить на APL на ДВК (!) в 9-м то классе…
листинги я хранил до института, на первом уже курсе забыл что это такое написаное, на 3-м выкинул.
До сих пор помню инстайт понимания как «оно массивы обрабатывает» :) на ДВК кстати было много странных символов на клаве, да.

не хочу сейчас в такое врубаться. python лучше :)
А я вот открыл программу, которую писал 15 лет назад на QuickBasic. Написано конечно адово, но в целом все ясно.
Бейсик отличается как раз очень простым и прозрачным синтаксисом. В этом плане хорош и его внук — Python. Хотя, конечно, уже заметно сложнее и неоднозначнее. Но на подобных языках, действительно, проще поддерживать код. Как свой, годы спустя, так и чужой. Одной из причин (хотя далеко не единственной), по которым я с Perl ушёл — даже при постоянном самоконтроле всё равно так и норовил где-то сэкономить и влепить оборот, который сложно понять в своём коде несколько лет спустя.
С чего вдруг Пайтон стал внуком Бейсика?
Python создавался под влиянием ABC (и с опытом его разработки). ABC создавался как улучшенный Бейсик.

Вообще, я ещё не зная про это родство, когда первый раз Питон увидел, сразу о Бейсике подумал :)
Он создавался как замена бейсику, но ближе скорее к алголу.
Википедия утверждает:
ABC задумывался для использования в целях, аналогичных применению Бейсик, Паскаля и AWK

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

У Пайтона языков, которые оказали на него влияния вообще вагон: ABC, Modula-3, C/C++, Smalltalk, Lisp, Fortran, Miranda, Java и Icon.

На этом фоне «генетический вклад» Бейсика совершенно теряется.
Ну, очевидно же, что подразумевается не биологическое родство с двумя разнополыми предками :)

В «генетике» языков рассматривают именно взаимное влияние. И в Python опытный глаз видит ряд генетических остатков Бейсика. Посмотрите на input и print, например :)
Понятное дело, что влияние. Только влияние языков не по названиям операторов считается, а по заимствованию идей. Оператор PRINT, например, есть в Фортране — в одном из самых старых языках, не знаю есть ли там INPUT, подозреваю, что есть.

Какие идеи Пайтон взял из Бейсика? На мой взгляд — ни одной.
Оператор PRINT, например, есть в Фортране


Он там совсем другой.

Какие идеи Пайтон взял из Бейсика?


А какие идеи были в Бейсике? :) Простота, универсальность, нестрогая типизация, интерактивность, расширенная диагностика ошибок, изоляция от железа, изоляция от ОС? Чего из перечисленного нет в Питоне?

Но, в любом случае, в наследовании языков смотрят не на идеи обычно, а на типичные способы решения тех или иных вопросов. И напомню, я утверждал, не что Питон — прямой потомок Бейсика. Он потомок ABC. Который уже, в свою очередь, потомок Бейсика. Соответственно, влияние Бейсика уже минимально. Но — заметно намётанному глазу,
Ещё раз. ABC — не потомок Бейсика, откуда вы это взяли.

А глаз у меня намётан, могу дать пару пруфлинков.
ABC — не потомок Бейсика, откуда вы это взяли.


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

Во-первых, как замена. Замена не значит заимствование идей.
Во-вторых, замена трёх языков, а не одного. Причём AWK похож на Бейсик, как трактор на помидор — помидор красный, а трактора дверки наружу открываются.
Какие идеи Пайтон взял из Бейсика
В частности, не заключать условия в if и циклах в скобки, в отличие от С. И более, по сравнению с С, «вербозный» синтаксис…
Почему вы решили, что это Бейсик вообще? А не Кобол, например?
Кобол — язык со строгой статической типизацией. Ну и идеологически имеет с Бейсиком мало общего.
А Пайтон — объекто-ориентированный язык, поддерживающий функциональное программирование и вообще ничего общего с Бейсиком не имеющий.
Википедия пишет, что ABC создавался под влиянием SETL и ALGOL 68, Бейсик среди «предков» не упоминается.
А, собственно, какие тут пяни есть, которых нет в APL (кроме того, что весь код можно в ASCII-символах печатать)?
у J есть ниша – обработка данных, особенно в финансовой сфере


Что-то, с учетом недавней статьи про IT в банках, мне кажется, что J в финансовой сфере привлекателен, в первую очередь, как раз своей мало-читаемостью.
Ага, почему-то мне это кажется «Как 45 минут терять в секунду по $172 222 виртуальных денег, которые никто не собирался допускать до покупки на них чего-то материального», что-то в этом роде…
Цель примеров – показать код в таситной форме.


А я думал показать читателю какой же он идиот, что не может понять такие простые и коротенькие примеры! ;)
НЛО прилетело и опубликовало эту надпись здесь
> createTable =: [:|:,.&a:
С этого места и далее ничего понять нельзя, потому как не ясна суть используемых глаголов.
«J – самый ненормальный и самый эффективный язык из известных мне языков.»
Он неэффективен хотя бы тем, что такой код невозможно поддерживать.

p.s. а ещё над Brainfuck смеялись…
Я хотел сказать, что код очень трудно читаем. Я сомневаюсь, что написание и чтение такого кода может быть эффективным. Например, нужно найти какой-то кусок кода через поиск в редакторе, где делается код. И как это сделать? Везде комменты добавлять?
НЛО прилетело и опубликовало эту надпись здесь
Я скажу, когда нужен J — это когда у вас данных больше, чем времени.
У меня один коллега (за 40) на нем «лабает» и в течение 3-х последних лет закрывает весьма нехилый фронт работ по анализу и управлению потоками данных. Причем он по образованию не Ай-Ти, а «предметник» — Animal Science.

Беда пришла нежданно.
Объем работ/данных вырос.
Коллеге в подмогу дали 2-х молодых, вооруженных дот-нетом и джавой.
Молодые скололись, «ни асилили» J.
Сейчас они всей группой учат питон и пытаются на него мигрировать.

Я делал два подхода к J.
Но мне аналогичные задачи комфортнее делать в R.
К слову говоря, если заменить всякие знаки препинания красивыми иконками, то, наверное, было бы намного проще понимать.
Так вот для чего на самом деле нужны клавиатуры типа Optimus
Хорошая мысль. Но ещё тогда нужен и редактор типа Optimus, который автоматом вставляет иконки в текст по аналогии как IM-клиенты вставляют смайлики. Есть идеи?
К слову говоря, APL.
В статье была ссылка на APL. И в APL не использовались красивые интуитивно-понятные иконки.
А какие вам нужны иконки? Я лично не могу себе представить, например, интуитивно понятную иконку для curtail, behead или ravel. К тому же, код будет совсем уже смайликовым.
Имхо, понятно почему в первой версии языка были не ASCII символы, а собственные обозначения. И, по моему — это именно то что нужно языку.

Если бы для всех этих |:, |., ~. и т.п. — были свои уникальные знаки (а для большинства уже есть подходящие математические знаки операций над множествами). Тогда код выглядел бы не тарабарщиной, а очень похоже на обычный математический язык,

Дело только в создании хорошей IDE, наподобие Matlab. А в идеале, вообще движок для рукописного ввода…

Интересно, если что-то подобное?
Интересно, если что-то подобное?


В начале темы как раз APL упоминался. В оригинале он именно на своей системе символов.

Лет семь назад мне пришлось столкнуться с APL — там как раз «крючки». Минус такого подхода — нужно либо увеличивать шрифт по сравнению с «чисто текстовым» языком, либо ломать глаза и блюсти чистоту монитора. Ну и плюс там была неуютная ситуация какого рода: в APL один и тот же крючок может значить разные вещи, в зависимости от того, интерпретируется ли он, как унарный или как бинарный оператор. Например, А|B — это остаток от деления B на A. А просто |B — это абсолютное значение B. Плюс в некоторых случаях «одним крючком» рисуются вещи, которые в «привычных языках» рисовались бы двумя — например, есть отдельные операторы Nand(«Not and») и Nor(«Not or»).
Именно поэтому я не предлагаю вернуться к APL, а только «визуализировать» J.
Судя по статье язык J — во многом похож на обычные математические выкладки. Но в обычных формулах используется много спец. символов и символов со специальным размещением аргументов (интеграл например), поэтому математические выкладки выглядят читабельнее.

Например, что проще: или Abs(Sin(Sqrt(10.5*X)))/(Exp(3*Ln(X*X))-0.143)+2*Pi*X?

Если взять за основу стандартные алгебраические знаки для работы с матрицами, векторами и пространствами, плюс добавить какие-то свои — может получится достаточно наглядно. А запись на нескольких уровнях позволит избавиться от «леса» скобок…

При этом от канонической записи отказываться незачем. Можно параллельно показывать ASCII запись и «формульную», как в некоторых математических пакетах.
Тем более что язык настолько сжат, что экономить место совершенно незачем, все равно на экран влезет такое количество логических конструкций что удержать их одновременно в голове нереально…

Понятно что знаков получается много, и тем кто уже знает J — учить новые знаки нет особого смысла. Но если сохранить возможность использовать в формулах ascii запись, то этот недостаток нивелируется. А вот для начинающих, такая запись будет полезна.

Например мне после статьи захотелось поставить J периодически его использовать (вроде мегакалькулятора). Мне поначалу понадобятся от силы 10-15 операторов, Из которых большая часть уже имеет стандартный символ или в алгебре или в комбинаторике. Возможность их использовать для меня открыла бы дверь в этот язык.

p.s. Имхо, возможность записывать формулы в алгебраическом виде давно пора внедрять в распространенные IDE. Это сделало бы код многих программ (особенно научных) гораздо читабельнее. Может есть что-то в этом роде?
пример функции на APL:
Пример

Этот код также малочитабелен. Я предлагаю нормальный формульный редактор.

Что-то типа такого:
image

Здесь принцип немного другой, но по идее, если считать что красным — ascii запись, а синим — формульная.
И править можно и тот и другой вариант — должно быть удобно.
и в самом деле, автор с такой фамилией мог бы и получше постараться — азиат ведь, в глифописи разбираться должен :)
Язык программирования на смайликах.
Я пытался выучить K, но оказался неспособным запомнить значения разных знаков в разных контекстах (типа того, что + как одноместная операция охначает транспорирование).
Но за то научился писать в pointfree стиле на Haskell, что мне потом помогало.
А синтаксис особых проблем не вызвал :-).
Напоминает некоторые либы, написанные на скале, где дорвавшийся до def <=!+ () {} программист отрывается по полной.
Интересный и необычный синтаксис. На мой личный взгляд — плохо читаем. В связи с этим возникает вопрос — кто-нибудь использовал его в реальных проектах? Если да, то поделитесь, пожалуйста, опытом, что на нем было сделано и какие преимущества это дало. А особенно — не было ли потом проблем с поддержкой.
Еще бы примеры продакшн-кода. То есть, вполне может статься, что автор поста предоставил (не)умышленно нечитаемый образец кода (сишный код тоже в 1 строку можно написать весь), и при соблюдении некоторых правил, которые, в целях облегчения поддержки, должны выполняться в настойщих проектах-неоднострочниках, код станет существенно понятней.
Такой вот пример есть в книге «J for C programmers»

Вычисление среднедневного остатка
NB. Verb to convert TAB-delimited file into numeric array
rdtabfile =: (0&".;.2@:(TAB&,)@:}:);._2) @ ReadFile @<

NB. Verb to process journal and account files
NB. y is (# days in current month);(Account filename);
NB.   (Journal filename)
acctprocess =: monad define
'ndays acctfn jourfn' =: y

NB. Read files
'acctano openbal' =. |: rdtabfile acctfn
'jourano jourday jouramt' =. |: rdtabfile jourfn

NB. Verb: given list of days y, return # days that
NB. each balance is a day's closing balance
wt =. monad : '(-~ 1&(|.!.(>:ndays))) 0{"1 y'

NB. Verb: given an Account entry followed by the Journal
NB. entries for the account, produce (closing balance),
NB.  (average daily balance)
ab =. monad : '(wt y)({:@] , (%&ndays)@(+/)@:*)+/\1{"1 y'

NB. Create (closing balance),(average daily balance) for
NB. each account.  Assign the start-of-month day (1) to the
NB. opening balance
cavg =. (acctano,jourano) ab/.(1,.openbal),jourday,.jouramt

NB. Format and print all results
s =. 'Account %d: Opening %d, closing %d, avg %d\n'
s&printf"1 acctano ,. openbal ,. cavg
''
)

Прошу прощения, что без подсветки.
Мне понравилась аналогия с китайским языком, которую автор статьи привел выше в комментариях. Безусловно, если потратить несколько (а на самом деле, десятки) лет на изучение китайского языка, то вы сможете на нем читать и писать, и иероглифы уже не будут вам казаться такой жуткой кашей. Вопрос только в том, стоит ли оно того? Окупятся ли потраченные на это годы?

Проблема в том, что не понятно, в каких реальных проектах/задачах J настолько удобно использовать, что бы потом можно было бы сказать: «да, не зря я учил его все эти годы». По статье этого не понятно, как непонятно и то, существуют ли такие ситуации/задачи.

Основная аргументация автора статьи, почему стоит учить J, заключается в том, что J позволяет кратко записывать алгоритмы. Это правда. Годы изучения китайского языка тоже позволят вам записывать целые тексты в очень кратком виде. Но согласитесь, не это является причиной, по которой его учат иностранцы, а совсем наоборот — это отталкивает многих. И если бы исторически не сложилось бы так, что на китайском говорит миллиард человек, то вряд ли его бы вообще кто-нибудь учил, кроме людей, которые занимаются этим ради фана, и что бы похвастаться.

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

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

Я джей изучил за месяц по вечерам. Просто прочитал и опробовал все примеры в книге Lerning J. Я ее даже конспектировал. Неделю заучивал на память все глаголы. Просто, зазубривал. Наверное, для джея это важно, т.к. их там достаточно. Но и надо сказать, что такое зазубривание — не так много времени и занимает.
После этого делал первое свое большое задание. Тоже с месяц по вечерам. Было очень сложно. Но постепенно мышление привыкало мыслить массивами.
После этого был готов работать. Пошел на работу на этом языке. Хотя как-то работать и мог, нельзя сказать, что ясно понимал текст и хорошо писал. В процессе, с год этот навык улучшался.

Так что вполне в разумные сроки можно изучить. Возможно, это требует какого-то специального мышления, у меня статистики нет.
Уважаю!
Я так в свое время осваивал Lisp, потом R.

А другого и не дано, по-видимому.
Само ветром не надУет.
Я разве ставлю под сомнение тот факт, что изучение J — легче китайского?
Я говорю о том, что непонятна область его применения, и как следствие — нету ответа на вопрос, «зачем нужно тратить время и усилия на его изучение».
Если отвечать упрощенно прагматично — есть такие рабочие места с весьма привлекательными условиями по зарплате и пр.

Ну это если аргументы типа «Ну, во-первых, это красиво...» Вы считаете несущественными и не относящимися к делу.

Если посмотреть на текст, не читая заголовок, можно подумать, что это очередная статья про обфрускацию JS.
Читал об APL. Язык интересный, уже решивший некоторые задачи, с которыми сейчас сталкиваются новые языки. Но синтаксис — да, очень сложный. Даже Rust с его тремя типами указателей выглядит проще, не говоря уж о C, Python и Go. Где-то встречал сравнение языков с точки зрения простоты использования (или популярности) и количества ключевых слов. Как раз в Go указывалось меньшее число, чем в C.
Читал об APL.

Спасибо за ссылку. Прочитал, получил удовольствие.

В тексте по ссылке мне понравилось сравнение APL-языков в области обработки «больших данных» с классикой музыки — Бетховен и иже с ним.
Они не соберут полные стадионы поклонников (как Lady Gaga или Hive с Hardoop'ом ), но будут жить, впечатлять призводительностью и мастерством создателей еще долго, если не всегда.
Хорошая статейка по ссылке.

Мое мнение — ниша J и подобных — программирование с данными.
С Большими Данными — в частности.
И в этой области, как нигде, видна разница php, к примеру, и J.
НЛО прилетело и опубликовало эту надпись здесь
Если вы отличный специалист в С++, то всегда можно написать программу, работающую быстрее, чем на J. Но разница будет: месяц по сравнению с час, утрированно, работы программиста. Иногда это просто неприемлемо. Пусть J и медленнее, но он достаточно производителен. Причем не факт, что он будет медленнее, если писать на плюсах в лоб.

Я так прямо не могу дать сравнительные тесты, просто из своего опыта. Потому что допиливали проблемные места кода на джее с помощью С или плюсов.
Местами он заметно неэффективен. Причем, эти места даже понятны, можно привыкнуть. Он энергичный, не ленивый. И в непонятной ситуации для сохранения имутабельности данных делает копию. А копии — это весь массив, который может быть большим. Поэтому там неэффективна рекурсия.
Но и оптимизируется легко. Пишете на С эту часть. Джей передает туда ссылку на массив и вы уже делаете, что хотите.
НЛО прилетело и опубликовало эту надпись здесь
Lisp очень прост, на самом деле, и я не шучу. Если хотите, почитайте SICP (про Scheme) или Practical Common Lisp. Для Scheme есть неплохая минималистичная среда разработки — Dr. Racket.

Что до J… Я бы на таком программировать побоялся. Да, с опытом будешь читать эту символьную кашу быстрее, но всё равно это дольше парсить, чем даже код STL на C++.
На perl тоже можно кодить смайликами, но J явно круче.
Похоже что J — это как Ифкуиль, только в программировании, а не в естественных языках.
Во многих языках сейчас есть лямбды и прочие штуки, на которых сделаны eDSL-ки например для работы с коллекциями (LINQ то же, всякие map/filter во многих языках). Не проще ли в своем языке построить уютненький eDSL для задач, решаемых J? Все-таки и порог вхождения сильно ниже будет, и расширять это можно как угодно, интегрировать сторонний штуки не нужно. В каких случаях J будет лучше чем такой eDSL?
Статья обстоятельная и даже интересная, но по прочтению возникает вопрос: «А зачем?» Ведь кроме перла есть еще масса языков на которых можно писать врайтонли код)
ТС, я извиняюсь, но по-моему выбирая из
Рассмотрим такой пример на SQL. У нас есть две таблицы:
CREATE TABLE Customers (ID INT, Name TEXT, Age INT, Salary INT)
CREATE TABLE Orders (OID INT,  Date  DATETIME,  CustomerID INT, Amount INT)

и
  createTable =: [:|:,.&a:
  union =: ([:{.[),:[:([:<[:;]#~~:&a:)"1([:{:[),.([:{:]){~([:{.])i.[:{.[
  insert =: [union[:({.,:([:([:<[:(]$~[:1&,#)>)"0{:))[:|:[:>]
  rows =: {.([:<,:)"1 1[:|:[:([:<"1[:,.>)"0{:
  value =: [:(]`{.@.([:1&=#))[:,[:>[((([:<[)=[:{.])#[:{:])[:>]
  pr =: [:,[:(([:>[)(([:<([:>[),.[:>])"0 0)"0 1[:>])/[:([:<[:rows>)"0]
  join =: 1 : '((([:{.[:>{.),:[:([:<(>"0))"1[:{:[:1 2 0&|:[:>([:,u"0)#]) (pr y))' 

очевиден ответ, какой язык более «человечен». Мне кажется, даже ассемблер понятнее, чем это. Просто какой-то ад и израиль, я не могу представить, что это написал человек, больше похоже на автогенерацию, причем очень нехилого обфускатора…
Вопрос

Вы часто на SQL-ле пишете сам движок субд? Код, который ниже, который на джее — не делает выборку, он создает возможность такой работы. Навесить парсер SQL и можно писать к такой СУБД уже какие-то запросы.
Я всегда считал, что ЯП придумывают для решения определенных задач. Этот язык — эзотерический, его практическое использование — невозможно. Во-первых потому что он тупо не семантичен. Во-вторых, время индивидуалов-гениев прошло, никто не напишет нормальный проект в одиночку, поэтому нужны более массовые языки, чем вывод /dev/random. Ответ товарища vladob более чем подтверждает эту точку зрения.
Слишком резкие высказывания. Его используют. Я всеми силами тут пытаюсь объяснить, что язык семантичен, не стоит дураками китайцев например, называть, или немцев, что ж они очень семантический русский не пользуют? Чтобы понять, насколько семантический язык, надо его знать и сравнить, а не пугаться всего, что непонятно.

Это скорее психологическая реакция. Дети в школе так делают — называют всё, что непонятно, идиотизмом. Физику, математику. «какой это идиот придумал?»

Знание глагогов приводит к их узнаванию в тексте, логично. Что приводит к чтению кода. Логично. А вот, насколько сложный код можно записать и насколько легко он читается, при условии, что вы знаете язык — это и будет семантичностью.

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

Математику придумывали не одно тысячелетии. Как вы думаете, они случайно используют большие формульные выкладки, огромные значки интегралов, всякие полосочки вроде модулей, кучу словосочетаний вроде sin, cos, arctg и пр. для обозначения того, для чего хватило бы какого-нибудь спец.символа? Все же учебник по высшей математике намного понятнее, чем написанное выше. А то вы выполняете функции архива: длинные частовстречаемые последовательности (ключевые слова) заменяете спец.символами. Количество информации на миллиметр экрана повышается, а вот качество восприятия этой информации — понижается, причем экспоненциально. Как в примере выше, я скалу никогда в жизни не видел, C/C++/C# и пр, баловался и функц. языками и прочим, мне хватило одного взгляда чтобы понять, что делает метод товарища Googolplex

Бывают разные люди. Некоторым биологам не может придти в голову, что изучать 30 лет сексуальные потребности особой разновидности жучков-боровичков не является крайне занимательным занятием. Я уважаю ваш выбор и выбор создателей этого языка. Но ваше восприятие — это отклонение от нормы, глупо ждать, что подобное может получить популярность. Хотя пример с судоку очень показателен и краток, но писать что-то серьезнее второй лабораторки по информатике, имхо, на подобном языке не стоит. По крайней мере языки появляются и исчезают, и я не позавидую человеку, которму придется отлаживать хотя бы пару десятков подобных строк. Особенно, если к тому моменту этот язык отомрет по тем или иным причинам… А вот если подобное случится со скалой, любой человек, знакомый с linq или любым функц. языком найдет ошибку и исправит.
я участвовал в реальных проектах, написанных на джее: датамайнинг.

Один из проектов — высоконагруженный сервер, нереляционная субд, для датамайнинга. Кластер, шардинг. Это еще в далеком 2005 году, когда такие слова не были особо в обиходе у программистов модными.

Я лично, например, писал там еще математические сервер, считающий ОЛАП-преобразования. Еще про олап мало кто слышал.

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

Посмотрите на главной странице http://www.jsoftware.com/ в разделе Representative Users кто его использует и найдете Hewlett Packard, Intel, Microsoft и много других.

И не стоит противопоставлять математику джеевской форме записи. Иначе все языки попадут под такую категорию. Не говорю только о Лиспе, а даже и о плюсах и Scala. В математике звездочки вместо умножения не пишут, наклонную черту вместо деления не пишут. Или во многих других языках есть графические способы записать интеграл?
Математика создавалась тысячелетия, но далеко не вся. Интегралы только во время Ньютона появились. И сейчас появляются новые значки. И не думаю, что Кенет Айверсон глупее араба две тысячи лет назад.

Я лично тоже считаю, что один красивый уникальный значок на глагол был бы понятнее, чем комбинация из двух. Но клавиатуры мешают. И это не критично. А сама форма записи и разбора предложений — очень и очень неплохая в джее.
Математику придумывали не одно тысячелетии
Если говорить о современной математической нотации, то, судя по Википедии, все знаки кроме "+" и "-" придумали в 17 веке и позже, "+" и "-" — в конце 15 века.
К слову сказать, Айверсон придумал APL (IBM) именно как разновидность математической нотации. Новая нотация должна быть проще, логичнее и удобно записываться в строчку. Ну и в целом у него получилось. К классической нотации даже до учебника по высшей математике привыкают лет десять, APL можно освоить за семестр или два.

J страдает не из-за плохой нотации, а из-за неподходящих средств ее выражения. Нотация хорошая. Но для того, чтобы читать J, надо не просто знать нотацию, а еще и то, как он ложится на ASCII. Это двойной барьер для восприятия, да. Хотя и преодолимый.
Вы, кажется, не поняли. Вторая ваша цитата — это и есть «СУБД на коленке», которая реализует похожий на первую цитату синтаксис.

Правда, мне тоже кажется, что в продакшне такому коду не место.
Правда, мне тоже кажется, что в продакшне такому коду не место.

Основное требование к продакшен коду, что бы когда вы уйдете на повышение или покинете компанию, другой человек разобрался бы с кодом в кратчайшие сроки и мог делать правки. А с кодом на этом языке, никто разбираться не будет, и я думаю даже пробовать не будут.
Да, мой Капитан!
Сравнивать надо другое:
CREATE TABLE Customers (ID INT, Name TEXT, Age INT, Salary INT)
CREATE TABLE Orders (OID INT,  Date  DATETIME,  CustomerID INT, Amount INT)
Customers =: createTable 'ID';'Name';'Age';'Salary'
Orders =: createTable 'OID';'Date';'CustomerID';'Amount'
Действительно, ([(0:`(([:(#=[:#[:~.[:{.|:)[:~.[:(#~[:-.[:isVar«0[:{:|:)gv)*.([:*./[:+./[:(isVar»0,=/),:))@.(([:#[)=[:#]))[:gp])«1 0#] — что тут сложного?
А на сколько возможно оторваться от матриц? И писать более абстрактный код, нежели работа с матрицами на J?

Кстати, с матрицами элементарно работает MatLab(matrix laboratory) и, вроде, R
На месте автора я уже вышел бы из дискуссии.
Он все сказал.

Дальнейшая дискуссия бесполезна — только минусов нахватает.
Его комментарии еще на одну статью по J (или про технологии/проекты, которые он упомянул в связи с ним) тянут легко.

Статья про J более чем своевременна.
Я уверен — многие попробуют себя и узнают что-то новое про свои возможности, а как следствие, возможно, подкорректируют свои амбиции.

На вопрос «как рефакторить не понимая кода?» отвечу вопросом как если бы заказчиком был я —
«Вы серьезно собираетесь что-то рабочее рефакторить, не понимая кода?!
И показав неспособность и/или нежелание его понимать?

А как ТЗ мое?
Вы тоже „отрефакторите“ по самое нехочу до уровня своего понимания?
Нет-нет, спасибо…
Будем искать с перламутровыми того, кто понимает».

Рефакторят такие задачи просто — не трогают рабочий код пусть он хоть на китайском. хоть на J, хоть на ANSI C, хоть на Фортране с Лиспом пополам.
Потому как такой код, как правило, воплощает вещи более концептуальные, а посему долгоживущие.

Но это только мое мнение.

че все разнылись то?

сложно, непонятно.

идите пишите на php своем.
И никогда ничего не ищите по тегам

лисп, рефал, хаскель, джей…

бизнес-программирование такое прикольное!
Lisp и Haskell поставить в один ряд с J — это уже слишком (Refal не знаю). Не знаю, как там насчёт сложности, а по уровню понятности (читабельности):
  • Haskell — 8/10
  • Lisp — 7/10
  • ARMv7 assembler — 5/10
  • Brainfuck — 1.1/10 (синтаксис проще, чем у J)
  • J — 1/10
Проблема читаемости J в том, что это адаптация APL под ASCII. Нотация APL непривычная, но неплохая. Не хуже привычной математической. Конечно, если взять его графемы и «втиснуть» в алфавит телетайпа, получится плохо. Это примерно как писать по-русски латиницей, только в восемнадцать раз хуже.

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

Но почему-то J под андройд есть, а APL нет.
Последний мой комментарий в этой теме.

Уперлись в нечитаемость для «непрофи» в J.
Но есть прецеденты.

Ноты!
Отдельный (письменный!) язык.
И ничего!
Плачут миллионы детей во всем мире, но жуют кактус учат нотную грамоту…

Еще раз спасибо автору.
Нотам нет полноценной альтернативы вне нотной записи.

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

Наконец, нотная запись — это именно аналог уже упоминавшегося китайского. Альтернативная знаковая система, но полноценная знаковая система, эффективно распознаваемая мозгом. Синтаксис же J к такой, увы, не относится (в отличие, скажем, от синтаксиса APL).
полноценная знаковая система, эффективно распознаваемая мозгом. Синтаксис же J к такой, увы, не относится


Но чьим-то мозгом он все-таки распознается.
Как миним — могзом автора поста.

Хоть это признайте и разойдемся друзьями.
>Но чьим-то мозгом он все-таки распознается.

В контексте, всё же, речь о быстром распознавании структуры целиком была. А не о последовательном чтении токенов.

>Хоть это признайте и разойдемся друзьями.

Это завсегда пожалуйста :)

Пусти код на J в продакшн и тебя никогда не уволят

m36, спасибо за статью.
Очень хочется поиграть с парсером пролога, но изучать полноценно J пока не решился.
При копипасте Вашего кода в J807 Qt IDE, получаю различные вариации ошибок, в зависимости от того, вводить ли данные одним большим блоком или строка за строкой, например:

|value error: goal
| prolog_code goal'sister_of(mary, X)'

|value error: parse
| prolog_code goal'sister_of(mary, fred)'

|spelling error
| sister_of(X,Y) :- female(X), parents(X, F, M), parents(Y, F, M).
| ^


Поможете разобраться?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории