Нотация как инструмент мысли - как далеко мы приехали?
Недавно я сравнивал старый Windows DOS command для удаления всех файлов в каталоге с эквивалентом в виде сценария - я заметил, что "модернизированная" версия потребовала, чтобы ввод в 50 раз больше нажатий клавиш достиг того же результата.
Эти дополнительные нажатия клавиш улучшают производительность? Они служат цели, которая была определена количественно, например, уменьшив кодирующий коэффициенты ошибок?
Проблема, поскольку я вижу его, - то, что язык программирования, записанный, прежде всего, для размещения Архитектуры фон Неймана - а не способ, которым мы думаем - вынуждает нас решить проблемы путем манипулирования тремя проблемными областями в наших головах (a) исходный probem (b) проблема, реструктурированная для установки Архитектуре фон Неймана (c) отображающиеся правила, должен был перевести назад и вперед между (a) и (b).
Как показывает опыт, чем более эффективный нотация языка программирования - в том смысле, что это позволяет Вам работать непосредственно с проблемой под рукой - тем ниже кодирование наверху. Ниже кодирование наверху делает проблему, решающую более послушный, и таким образом уменьшает кодирование и место для ошибки. Это не должно определенно увеличивать рабочую нагрузку!
Который язык программирования по Вашему мнению делает для платформы наиболее эффективного решения проблем - в котором это позволяет Вам думать непосредственно с точки зрения исходной проблемы, не имея необходимость делать междоменное манипулирование задач?
Для интереса я провел подсчет байта 37 различных решений игры Conway жизни и придумал следующую статистику:
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),
Комментарии?
Будьте конкретны относительно достоинств письменного подхода язык, который Вы критикуете, берет, и сделайте так от довольно высокого уровня - предпочтительно с прямым опытом проекта.
3 ответа
Вы использовали игру «Жизнь» Конвея в качестве примера, и ни один язык не может решить это более элегантно или эффективно, чем APL. Причина - полное манипулирование массивом / матрицей в очень мощных одно- или многосимвольных операторах.
См .: Что случилось с APL? и мой рассказ о моем комбинаторическом задании, в котором APL сравнивается с PL / I.
Если вы говорите об «эффективном» с точки зрения нажатия клавиш для решения проблемы, APL будет сложно превзойти.
Ваш счетчик байтов 145 для игры Конвея, решающей APL, неверен. Вы искали это очень неэффективное решение.
(источник: catpad.net )
Это 68 байт, что превосходит решение J. Я думаю, что есть другие решения APL, которые даже лучше.
Также см. это видео об этом .
Вы действительно сравниваете del / s *. * с его реализацией? Готов поспорить, что автор сценария мог бы выполнить оболочку и выполнить встроенную команду del . Невозможно сказать, почему он этого не сделал, но у него могла быть веская причина.
Я за меньше церемоний и с такой низкой цикломатической сложностью , насколько это разумно, но нажатия клавиш кажутся действительно плохим показателем того, насколько легко читать код (Perl - почему ты так на меня смотришь?) или насколько хорошо это соответствует проблемной области. Просто измените все имена переменных на один символ, и вы сэкономите много нажатий клавиш! Или сделайте код полностью нечитаемым с помощью какого-нибудь продвинутого кода игры в гольф . Не очень продуктивно.
Повышают ли продуктивность эти дополнительные нажатия клавиш? Служат ли они цели, которая была определена количественно, например, уменьшению количества ошибок кодирования?
Я думаю, что отчасти да. Даже если я наберу в 10 раз быстрее, в итоге проект не будет выполнен на 1% быстрее. Но взгляните на файлы летучих мышей, они похожи на спагетти. Нет, больше похоже на рамэн.
Большую часть времени я кодирую какой-нибудь "быстрый и грязный" сценарий, мне приходится запускать его, чтобы проверить, действительно ли он работает. Но, говоря на современном языке, я почти не сталкиваюсь с глупыми сюрпризами (такими как удаление не того файла из-за того, что сценарий был вызван с сетевого диска или ярлыка) во время выполнения.