tcl/tk без знания английского

(.*) без знания английского

Зачем решать частные проблемки, если можно решить общую?

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

Он должен tclshrc открывать, поэтому не нужно ничего поддерживать.

Я понял, что ты хочешь. В таком виде именно этой проблемы не будет. Но есть ещё остальные. В любом случае, русифицировать сами команды в мои планы не входило. И без русификации документации всё равно будет мало пользы. При том, существующие книжки на Русском годятся для англоязычного tcl/tk, но не будут годиться для переводного. Т.е., нужно ещё и книжки будет заново «переводить».

Но есть ещё остальные.

Какие остальные проблемы?

Я согласен, что идея не очень, потому что обучение на таком модифицированном языке не позволит обучившимся брать код из имеющихся готовых проектов на Tcl и не позволит их код применять в продакшне.

Но этот язык всё равно будет лучше разработанного с нуля языка с русской лексикой, который ты предлагал раньше.

И без русификации документации всё равно будет мало пользы.

Перевести man Tcl недолго, а вот для модифицированных команд придётся написать свои маны, да.

существующие книжки на Русском годятся для англоязычного tcl/tk, но не будут годиться для переводного.

Учитывая, что они описывают версию 8.4 в лучшем случае, а уже есть 8.6, я не уверен, что они годятся. Если ты собираешься обучать кого-то Tcl, то надо или писать свои книжки или переделывать уже написанные — но тогда будут юридические проблемы. Разрешат ли их авторы обновить книжки до Tcl 8.6 — неизвестно.

остальные проблемы?

Я писал. Например, если переадресовывать Русские команды к исходным, то увеличится глубина стека и может сломаться uplevel. Далее возникнет вопрос с индексами типа end, которые наверняка часто участвуют в сравнениях, в т.ч. в библиотеках. Snit непонятно как будет работать.

Но этот язык всё равно будет лучше разработанного с нуля языка с русской лексикой, который ты предлагал раньше.

Свой язык я не перестал предлагать, просто сейчас по нему почти ничего не делаю. Этот язык вообще мало похож на tcl/tk, он скорее ближе к Яве или Лиспу. Я считаю, что это намного лучше, чем tcl/tk. tcl/tk к нему нужен только для GUI, поскольку tk нельзя использовать без tcl, делать обёртки нетехнологично, а остальные библиотеки GUI мне не нравятся.

Будет странно, если язык русскоязычный, а гуй к нему доступен только при знании Английского.

Т.е. мои планы не поменялись, просто я пытаюсь их детализировать.

sql запросы в новом языке тоже будут русскоязычные?

Да вообще не надо знать буквы вероятного противника. Это только вредит делу. В самых лучших языках уже можно писать код на языке Маяковского, например в 3-питоне.

sql запросы в новом языке тоже будут русскоязычные?

Нет.

Буквы вероятного противника знать надо. Но не надо, чтобы знание языка вероятного противника было обязательным для хоть какой-то конструктивной деятельности, как сейчас.

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

Похоже, что я нашёл русскоязычный tcl/tk, хотя не на 100% похож.

http://gendoc.ru/