Обозначение как инструмент мысли - как далеко мы пришли?

Недавно я сравнивал старую команду Windows DOS для удаления всех файлов в каталоге с эквивалентом сценария. Я заметил, что "модернизированная" версия требует ввода в 50 раз больше нажатий клавиш для достижения того же результата.

Являются ли эти дополнительные нажатия клавиш повышающими производительность? Используют ли они цель, которая была количественно определена, например, уменьшая частоту ошибок кодирования?

Проблема, как я вижу, заключается в том, что компьютерный язык, написанный прежде всего для размещения архитектуры фон Неймана, а не того, как мы думаем, заставляет нас решать проблемы, манипулируя тремя проблемными доменами в наших головах: а) исходный пробный номер (b ) проблема реструктурирована в соответствии с архитектурой фон Неймана (c) правила отображения, необходимые для перевода вперед и назад между (a) и (b).

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

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

Для интереса я подсчитал байт 37 различных решений для жизни в жизни Конвей и придумал следующую статистику:

J : 80, 
APL : 145, 
Mathematica : 182, 
Ursala : 374, 
JAMES II : 394, 
SETL : 559,
ZPL : 652, 
PicoLisp : 906, 
F# : 1029, 
Vedit macro language : 1239, 
AutoHotkey : 1344, 
E : 1365, 
Perl 6 : 1372, 
TI-89 BASIC : 1422, 
Perl : 1475, 
PureBasic : 1526, 
Ocaml : 1538,
Ruby : 1567, 
Forth : 1607, 
Python : 1638, 
Haskell : 1771, 
Clojure : 1837, 
Tcl : 1888, 
R : 2031, 
Common Lisp : 2185, 
OZ : 2320, 
Scheme : 2414, 
Fortran : 2485, 
C : 2717, 
ADA : 2734, 
D : 3040, 
C# : 3409, 
6502 Assembly : 3496, 
Delphi : 3742
ALGOL 68 : 3830, 
VB.NET : 4607, 
Java : 5138, 
Scala : 5427

(см., например, http://rosettacode.org/wiki/Conway's_Game_of_Life)

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

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

Ответ 1

В качестве примера вы использовали игру Conway Life, и ни один язык не может решить это более элегантно или эффективно, чем APL. Причиной является полная манипуляция массивом/матрицей в очень мощных одно- или многосимвольных операторах.

Смотрите: Что бы ни случилось с APL? и моя история о моем назначении комбинаторики, которое сравнивает APL с PL/I.

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

Ваш байт-счет 145 для APL, решающий игру в Конвее, ошибочен. Это очень неэффективное решение, на которое вы смотрели.

Это одно из решений:

alt text http://catpad.net/michael/APLLife.gif

Это 68 байт и превосходит J-решение. Я думаю, что есть другие решения APL, которые еще лучше.

Также см. это видео об этом.

Ответ 2

Вы действительно сравниваете del /s *.* с реализацией того же самого? Бьюсь об заклад, что автор script может иметь оболочку и выполнить встроенную команду del. Невозможно сказать, почему он этого не сделал, но у него могла быть веская причина.

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

Ответ 3

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

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

Ответ 4

Являются ли эти дополнительные нажатия клавиш повышающими производительность? Используют ли они цель, которая была количественно определена, например, уменьшая частоту ошибок кодирования?

Я думаю, что они частично. Даже если я набрал 10 раз быстрее, проект не будет сделан на 1% быстрее в конце. Но взгляните на файлы bat, они выглядят как спагетти. Нет, больше похоже на рамен.

В большинстве случаев я кодирую "быстрый n" грязный "script, я должен запустить его, чтобы проверить, действительно ли он работает. Но на современном языке я едва ли сталкиваюсь с такими глупыми неожиданностями (например, удаление неправильного файла, поскольку script вызывается с сетевого диска или ярлыка) во время выполнения.