Интерпретатор Forth в Java
Мне платят за код, который работает, не тесты, таким образом, моя философия должна протестировать как можно меньше для достижения данного уровня уверенности (я подозреваю, что этот уровень уверенности высок по сравнению с промышленными стандартами, но это могло просто быть гордостью). Если я обычно не делаю своего рода ошибку (как установка неправильных переменных в конструкторе), я не тестирую на него. Я действительно склонен понимать тестовые ошибки, таким образом, я дополнителен осторожный, когда у меня есть логика со сложными условными выражениями. При кодировании в команде я изменяю свою стратегию к тщательно тестовому коду, который мы, коллективно, склонны понимать превратно.
у Различных людей будут различные стратегии тестирования на основе этой философии, но это кажется разумным мне, учитывая незрелое состояние понимания того, как тесты могут лучше всего вписаться во внутренний цикл кодирования. Десять или двадцать лет с этого времени, у нас, вероятно, будет более универсальная теория, которой тестирует для записи, который тестирует для не записи, и как сказать различие. Тем временем экспериментирование кажется в порядке.
4 ответа
Поможет ли это письменно эффективное / жесткие программы?
Это спорно.
Я уверен, что Forth люди скажут вам, что это быстро. Но я сомневаюсь, что скорость выполнения программы FORTH, работающей на интерпретаторе FORTH, реализованном на Java, будет соответствовать скорости эквивалентной программы, реализованной непосредственно на Java. Для начала, JIT-компилятор не сможет так хорошо оптимизировать интерпретатор FORTH, как для простой версии Java.
Если под «плотным» вы имеете в виду «использование меньшего объема памяти», я думаю что разница будет незначительной. Помните, что как в случае «FORTH в Java», так и в случае «простой Java» у вас есть все накладные расходы памяти Java JVM. Это, вероятно, затмит любое сравнение плотности кода FORTH с эквивалентной плотностью скомпилированного кода Java.
Автор на этой странице описывает at как реализацию подмножества FORTH и подходящую для включения g в другие приложения; предположительно, он предназначен для обеспечения возможности написания сценариев для приложения. Маловероятно, что система работает, выплевывая байтовые коды java или JVM; он почти наверняка использует интерпретатор, написанный на Java.
Традиционно, интерпретатор FORTH может быть реализован с очень небольшим объемом памяти. Я знаю кого-то, кто реализовал один на COSMAC, и основной интерпретатор имел длину 30 байт . Байт-код, ориентированный на стек, также был очень компактным, так как ему не нужно было указывать расположение операндов - он просто считывал из стека и помещал результат в верхнюю часть стека.
Не переводчик байт-кода
Ответы на ваши вопросы: «см. ниже, вроде и нет» .
Это просто программа, которая принимает некоторый ввод и производит некоторый вывод. Входными данными является скрипт Forth. За исключением некоторых очень крупных систем, на самом деле байт-код создается редко. jRuby, Clojure, Scala ... большие системы, подобные этой, действительно производят байт-код.
Однако ваш интерпретатор Forth, вероятно, именно так: интерпретатор сценария, который написан на java. Входные данные, которые он принимает, - это своего рода программа, так что в итоге вы получаете красивое двойное косвенное выполнение. Далее выполняется через интерпретатор байт-кода, выполняемый через jvm, запущенный на CPU.
Теперь, если вы запустили это на эмуляторе процессора или написали интерпретатор на Forth, вы могли бы сделать его тройным косвенным. (И в некотором смысле это уже так, потому что ваш процессор Intel переводит большинство кодов операций x86 в микрооперации перед их выполнением.: -)
В любом случае, дело в том, что программа, написанная на довольно статический язык, такой как java, может захотеть принять какой-то сложный пользовательский ввод и выполнить его, или, возможно, у автора программы есть вещи, которые легче сделать прямо, и это позволяет ему писать как на java, так и на других языках.
думайте обо всем этом, пока не поймете это.
потому что ваш процессор Intel переводит большинство кодов операций x86 в микрооперации перед их выполнением. : -)В любом случае, дело в том, что программа, написанная на довольно статическом языке, таком как java, может захотеть принять какой-то сложный ввод пользователя и выполнить его, или, возможно, у автора программы есть вещи, которые легче сделать , и это позволяет ему писать как на java, так и на других языках.
Вы должны думать обо всем этом, пока не поймете это.
потому что ваш процессор Intel переводит большинство кодов операций x86 в микрооперации перед их выполнением. : -)В любом случае, дело в том, что программа, написанная на довольно статическом языке, таком как java, может захотеть принять какой-то сложный ввод пользователя и выполнить его, или, возможно, у автора программы есть вещи, которые легче сделать , и это позволяет ему писать как на java, так и на других языках.
Вы должны думать обо всем этом, пока не поймете это.
и это позволяет ему писать как на java, так и на других языках.Вы должны думать обо всем этом, пока не поймете это.
и это позволяет ему писать как на java, так и на других языках.Вы должны думать обо всем этом, пока не поймете это.
Это позволяет писать эффективные / компактные программы. Отчасти потому, что способность определять определяющие слова (слова, выполняемые во время компиляции) может иметь эффект эффективного определения предметно-ориентированного языка (DSL). Форт также поощряет рефакторинг (иначе содержимое стека просто станет непонятным ...), и поэтому код будет жестким.