MIT поинтереснее будет, нежели любой вуз Беларуси, особенно, если вспомнить про обязательную отработку обучения воспитателем в детском садике где-нибудь в Шоподрыщинске.
Вот Вы, видимо, читать по-английски умеете, но вникать в суть написанного не утруждаетесь. Ключевое свойство компилятора — это преобразование кода с языка прикладной области (DSL) в язык системы выполнения кода.
Скажите, Вас не смущает, что Google называет свой GWT компилятором с Java в Javascript? А то, что JSP компилируется в Java? А тот факт, что Lisp компилируется в Lisp? ;-)
На крайний случай, вспомните, что Smarty компилируется в PHP.
Синтаксический разбор исходного кода происходит в любом случае, независимо от востребованности того или иного куска кода. А «ленивость вычислений» — это немножко другое ;-)
Эм… я немного о другом) На входе мы имеем проект, написанный по всем канонам ООП и best practices, а на выходе — борщ нечитабельного, но быстрого (в рамках ZE) кода. Например, если в какой-то части графа юзается один-единственный статик метод некоего класса Foo::bar() — имеет смысл декларировать его как функцию. Если метод является однострочник — заменяем его вызов на inline.
А чем это не компилятор, если он разбирает исходный код в AST и потом на его основе генерит новый код? Или, по вашему, компилятор должен непременно native-код генерить?
> The current Ion is closely related to the company's GeForce 9400M graphics processor but is optimized for use in low-power devices.
В полноценном Ion чип типа 9400M, видимо, с зарезанной частотой. Учитывая, что 9400M — не сахар, то можно ожидать Ion LE на уровне 8400M, что по сути суксь, но для тетриса сойдет ;-)
Осталось докрутить один маленький шаг: вместо хранения кода в БД, сделать нормальный компилятор PHP -> PHP. Т.е. на входе имеем N файлов со сложными зависимостями, на выходе -> M файлов без зависимостей и лишней мишуры. Почему автор не дошел до этой точки — остается загадкой.
да вообщем-то на любой схемке (Gambit, например) можно написать подобный кросс-трансформер, а оттуда уже портировать куда угодно. AST — оно и в Африке AST. А XML тут за уши притянут, видимо, исключительно из-за реализации проекта на Java. Ну любят джависты XML, что поделать ;-)
а Вы можете выложить ТЗ в паплик (ну или протектед ;) доступ, дабы местная публика могла оценить его качество и выяснить наконец, кто прав, а кто виноват?
> почему это заказчик виноват в том, что исполнитель плохо прочитал ТЗ в самом начале и не уточнил непонятное ему?
Потому что в этом случае вы рискуете потратить 200% бюджета времени проекта на согласование ТЗ. Это вытекает из конфликта интересов:
— заказчик старается максимизировать кол-во и качество фич на каждый потраченный на исполнителя доллар,
— исполнитель старается минимизировать объем своей работы над каждой фичей.
Т.о. в фиче «сделать удаление пользователей в админке» заказчик подразумевает примерно следующее:
— должен быть список пользователей, из которых админ может выбрать несколько пользователей, подлежащих удалению.
— перед операцией удаления система должна запросить подтверждение у админа, отобразив список пользователей, выбранных для удаления.
А исполнитель, может принять для себя такой брутальный вариант, формально удовлетворяющие фиче:
— инпут для ввода ID или username пользователя, которого нужно удалить + кнопка «Удалить».
> Изменение в ТЗ в середине проекта я вообще считаю неприемлемым.
Чем больше проект — тем меньше шансов на то, что его удастся сделать без изменения ТЗ.
ну зачем же сразу перегенерация. достаточно добавить нужные файлы в список, а иногда вообще ничего не добавлять:
---->8-----------------------------------------
SRC = ../packages
BLD = ../build
COMPRESSOR = ./yuicompressor-2.3.4.jar
SOURCES = $(wildcard $(SRC)/*.js)
MAINS = $(BLD)/core.js
OBJECTS = $(filter-out $(MAINS),$(patsubst $(SRC)%,$(BLD)%,$(SOURCES)))
build: BUILDER = java -jar $(COMPRESSOR) --type js --charset UTF-8 -o $@ $<
build: $(BLD)/.build-optimized $(BLD)/api.js $(BLD)/autoload.no-cache.js
debug: BUILDER = cp $< $@
debug: $(BLD)/.build-debug $(BLD)/api.js $(BLD)/autoload.no-cache.js
$(BLD)/api.js: $(MAINS) $(OBJECTS)
cat $^ > $(BLD)/api.js
$(BLD)/autoload.no-cache.js: ../autoload.js
$(BUILDER)
$(BLD)/%.js: $(SRC)/%.js
$(BUILDER)
$(BLD)/.build-debug:
rm -Rf $(BLD)/*.js $(BLD)/.build-*
touch $(BLD)/.build-debug
$(BLD)/.build-optimized:
rm -Rf $(BLD)/*.js $(BLD)/.build-*
touch $(BLD)/.build-optimized
clean:
rm -Rf $(BLD)/*.js $(BLD)/.build-*
.PHONY:
---->8-----------------------------------------
> Но в данной статье помимо упаковки есть еще и интеграция с javascript_include_tag, что позволяет подключать несколько файлов по ключу
Эм… теперь моя очередь не понимать. Поясните, плиз :-)
Куда катится этот мир… чем плох старый добрый Makefile?
[/voice]
Скажите, Вас не смущает, что Google называет свой GWT компилятором с Java в Javascript? А то, что JSP компилируется в Java? А тот факт, что Lisp компилируется в Lisp? ;-)
На крайний случай, вспомните, что Smarty компилируется в PHP.
пример: haxe.org/api
В полноценном Ion чип типа 9400M, видимо, с зарезанной частотой. Учитывая, что 9400M — не сахар, то можно ожидать Ion LE на уровне 8400M, что по сути суксь, но для тетриса сойдет ;-)
DELETE FROM (`object_`) WHERE `id` = 22567;
Э-э. Почему не прокатят? Всмысле, нахаляву не прокатят?
> заказчикам гораздо проще работать по fixed price…
Процесс — проще, результат — плачевнее, судя по обилию топиков и гневных высказываний с обоих фронтов ;-)
Я уже боюсь повторять, но… есть же нормальные методологии разработки, решающие проблемы неполных ТЗ, изменений, дополнений — тот же Scrum, к примеру…
Потому что в этом случае вы рискуете потратить 200% бюджета времени проекта на согласование ТЗ. Это вытекает из конфликта интересов:
— заказчик старается максимизировать кол-во и качество фич на каждый потраченный на исполнителя доллар,
— исполнитель старается минимизировать объем своей работы над каждой фичей.
Т.о. в фиче «сделать удаление пользователей в админке» заказчик подразумевает примерно следующее:
— должен быть список пользователей, из которых админ может выбрать несколько пользователей, подлежащих удалению.
— перед операцией удаления система должна запросить подтверждение у админа, отобразив список пользователей, выбранных для удаления.
А исполнитель, может принять для себя такой брутальный вариант, формально удовлетворяющие фиче:
— инпут для ввода ID или username пользователя, которого нужно удалить + кнопка «Удалить».
> Изменение в ТЗ в середине проекта я вообще считаю неприемлемым.
Чем больше проект — тем меньше шансов на то, что его удастся сделать без изменения ТЗ.