Здравствуйте, eao197, Вы писали:

E>Так что ты можешь продолжать считать, что я не вижу достоинств в Nemerle, но дело в другом. Хотелось бы увидеть, насколько безопасно закладываться на Nemerle в долгосрочной перспективе. И здесь, представь себе, есть подозрения, что достоинства Nemerle, которые ты с сотоварищи здесь рекламируете, будут со временем становится недостатками. По той простой причине, что требуют для своего успешного применения высокой квалификации. Может быть поэтому интерес к Nemerle проявляют люди и Top-а RSDN-а (им ведь по барабану, какой язык осваивать и на чем писать). Так что я думаю, у Nemerle есть хорошие шансы стать мощным и сложным инструментом (что-то вроде C++), для небольших высококвалифицированных команд.

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

Чем это может быть чревато? Возьмем стабильный (казалось бы) SML/NJ. На нем написан замечательный пакет — NJ Machine Code Toolkit, предназначенный для быстрого создания эмуляторов процессоров. По декларативному описанию системы команд он генерирует декодер (принцип очень похож на yacc), и ассемблер (в смысле, транслятор с ассемблера).

Проблема в том, что NJ Machine Code Toolkit не собирается на современной версии SML/NJ, вызывая местами очень невнятные ошибки компиляции. Нашей группой был потрачен примерно 1 человекомесяц, на то, чтобы сделать его работоспособным. При этом, писали его те же люди, что делали SML/NJ. Причина — та же, читайте первое предложение в ответе. Хотите, чтобы это однажды произошло с вашим кодом?