CyberManiac Ваши предсказания были актуальны лет десять тому назад. Сегодня же текстовые файлы перешли на utf8, "дефективная сучность консоли" тоже перешла на utf8, но "юниксвэйные копролиты" не заметили никаких существенных изменений. Ну разве что strlen работает не всегда так, как того ожидаешь.
CyberManiac, Что-то я теряюсь в логике: сначала недостатком было то, что компиляторы поддерживают разрешённые стандартом дополнительные возможности, к примеру возможность напрямую использовать в идентификаторах символы, не принадлежащие basic character set. Теперь же эта возможность приветствуется. То, что стандарт вводит ограничения на базовый набор символов, не вызывает возражений? Утилита для перекодировки исходника между ним и UTF-8 (с учётом возможностей препроцессора) может оказаться сложной, но такова жизнь. Определение понятия «текстовый файл» в студию, пожалуйста.
По сабжу: Удобства написания кода не хватает мне в Си. Вот если скрестить питон (boo), C# и D, добавить еще немного интроспекции времени компиляции, - получился бы вполне себе хороший язык.
поддерживаю CyberManiac. Очень не хватает возможности называть функции на отличном от инглиша языке. Слова на инглише не звучат, пустой звук. нет корня в англ. словах, душа не отзывается на них.
newbie длнстр (strlen), м_бФлаг (m_bFlag), уснСтр (pszStr). Тебе что, самому не догадаться? Но сокращения очевидно вызывают лишь смех, мне всегда вот что было интересно, а как склонять? Я пытался какое-то время в lisp'е использовать русские имена, но очень сложно выработать правильный стиль. Потом я и отказался из-за того, что меня раздражал тот факт, что вся программа выглядела издевательством над русским языком. Например, взять cl-ppcre. Есть функция scan-to-strings, как её перевести на русский? сканируй-в-строки, пожалуйста-сканируй-в-строки, сканируй-в-строки-я-сказал, сканировать-в-строки, сканирование-в-строки. Как? Ещё интереснее, что-нибудь в стиле do-register-groups -- это макрос-цикл, слово do служит намёком на то что это цикл. Как это записать на русском? делай-регистрируй-группы? делать-регистрируй-группы? делать-регистрировать-группы? Слово "регистрируй" может не по-русски само по-себе, но я затрудняюсь предложить что-то адекватнее, может "присваивай", "лексически связывай" или что-нибудь в этом стиле. Хотя опять же, "лексически" -- это тупое заимствование из английского, английское слово записанное транслитом. Его пожалуй тоже надо перевести, скажем "контекстно". jabocrack А по-моему, в этом и есть главное преимущество. Мы берём комбинацию английских букв, которая для нас пустой звук, и наполняем тем смыслом, который нам нужен. И этот наш смысл никак не интерферирует со старым смыслом, потому что старого смысла нету. Собственно, я бы всем поборникам русского языка в программировании, рекомендовал бы взять lisp систему и перевести её на русский. Это совсем несложно. Если хотите я могу макрос написать, и вам останется лишь указать список пар слов: английское название функции и русский перевод. А макрос всё переведёт на русский, согласно вашим указаниям. И можно будет писать что-нибудь в стиле: Код (Text): (цикл для и от 0 вверх-до Н с к = 0 пока (< к М) если-не (= 0 (mod к и)) делай (что-то-там-с и к) собирай (спяч i k) в результат ;; спяч -- это cons, вообще cons от слова construct, но я не знаю как перевести, пускай будет СПисочнаяЯЧейка в-конце (верни результат)) Мне бы было интересно посмотреть на результат, в первую очередь потому, что я не вижу никакого способа перевести так, чтобы результат не вызывал бы приступа тошноты. И если результат будет, то можно будет говорить о каком-то русском стиле именования. Это действительно было бы интересно.
Я вообще-то хочу именовать отдельные функции, а не переводить весь язык программирования на русский ) Хотя создание языка программирования на русском языке - в этом что -то есть.
r90 сканировать_с_записью_результатов_в_строки я макросы не использую, так что данная проблема меня не касается
scan-to-strings, ПрочитатьСтроки "в" не нужно do-register-groups Так и пиши ЦиклРегистрацииГрупп Это все виновата Русская школа которая учит переводить дословно, а не по смыслу.
Были уже такие языки. Слава богу, вымерли. Самое отвратительное, что я могу представить в тексте программы ("наевшись" немецких, японских и ивритских локализаций) - это что-то на национальных языках (даже в комментариях). И я уж не говорю про многонациональные проекты.
jabocrack Это не про лисп. В лиспе крайне сложно провести грань между языком и "отдельными функциями". Абсолютно неясно, является ли макрос loop частью языка или он привнесён библиотекой. Так же, как скажем defclass -- сейчас-то всё ООП реализуется на уровне lisp машины, но когда-то CLOS был лишь библиотекой написанной на лиспе. Но ты и не пишешь на lisp'е. В C++ пришлось бы выкручиваться как-то ещё, но это не существенно. Короче, отмазка не канает. Pavia Первый пример, показывает что ты сторонник повелительного наклонения, это я понял. Я, в общем-то, тоже думаю, что повелительное наклонение -- лучший вариант. Но перевод неверный в корне: scan-to-strings сканирует данную строку в поисках регекспа и возвращает набор строк -- весь match (совпадение?) и отдельные группы. to это к тому, что в результате я хочу получить строки, а не индексы начала/конца подстрок. Поэтому слово "в" было бы не лишним иметь. Если тебя смущает то, что ПрочитатьВСтроки будет выглядеть по-идиотски, это как раз не страшно, лисповский стиль подразумевает такое написание: прочитать-в-строки. Смотрится это уже не столь идиотски, вполне пристойно. Но смысл не соответствует действительности. Нисколько. Во втором же примере, ты отходишь от повелительного наклонения в пользу... как это в русском называется я не знаю. На лекциях по английскому это называлось, помнится, цепочки существительных. Ты уверен, что смешение стилей в названиях -- это хорошо? Может тогда уж всё цепочками существительных? Или есть какие-то закономерности, типа в таких-то ситуациях глаголами, а в других существительными? В смысле перевода, мне не нравится слово "регистрация". Это просто цикл по match'ам в строке, в теле которого я могу обращаться к отдельным группам по именам, как к заурядным переменным. Группа -- это то, что в регекспе круглыми скобочками выделено. И слово register -- это как раз к тому, что группы как бы "регистрируются" на время итерации цикла под заданными именами. Но вообще, слово "регистрировать" у меня вызывает ассоциации с чем-то типа "внести в глобальное хранилище", "оставить памятку на будущее". В общем мне не нравится слово "регистрировать" и производные от него в переводе. Может быть ты прав. Может быть я слишком старался держаться исходных названий. Но не держаться их достаточно сложно: среди слов из которых составляются названия функций очень часто попадаются термины. То есть слова, которые переводить надо всегда одинаково, соответствующим русским термином. То есть, это не художественный перевод, и излишние вольности непозволительны. То же do который ты перевёл словом цикл. В лиспе есть ряд макросов, описанных в ANSI стандарте, которые начинаются со слова do, и представляют собой именно цикл (dolist, dotimes, do), а есть ещё макрос loop, который привносит в lisp язык для итеративного описания циклов. Надо ли в переводе отражать эту разницу? Хотя глупый вопрос, конечно же надо: макрос do и макрос loop должны в переводе называться по разному. Как? В общем моя попытка сделать русский лисп, показала что вопросы появляются быстрее чем ответы. Быть может если долго-долго сидеть и думать, тыкаться и так и эдак, то что что-нибудь придумается. Но у меня не хватило терпения. Поэтому я и подбиваю народ проделать эту фишку. Не обязательно с lisp'ом, но с чем-нибудь предназначенным для решения реальных задач. И не просто так, русский паскаль, где переведены ключевые слова, плюс несколько процедур. Не, это не пойдёт. Надо что-то вполне рабочее, нацеленное на настоящие программерские задачи. Скажем если переводить C++, то вместе с STL и Boost.
С Лиспом незнаком. Как раз таки нет. Когда мы встречаем термин мы должны придумать ему эквивалент в русском языке. И тут проявляется разность языков в русском есть суффиксы окончания которые могут менять форму слова. В английском такого меньше. Я считаю хорошо все что естественно. А для русского языка эта естественно. Не согласен. Да стремиться надо по возможности. Напиши do=ЦиклПо, loop Цикл. В данном случаи стандарт отошел от английского в угоду наглядности. А мог ведь и не отходить. Тут больше попахивает не стандартом, а спецификацией. Если ты делаешь перевод для Русских то будь добр в первую очередь придерживаться Русских правил. А потом уже наглядность. И на третьем месте возможность однозначно перевести на английский. Придерживайся этих правил и ряда других тогда переводить станет проще. А вот правила надо будет выробатать. do-register-groups Тогда ЦиклПоЗарегестрированнымГруппам или ЦиклПоНайденнымГруппам второй мне больше нравится
CyberManiac Стандарт Ады (во всяком случае, Ады-2005) предписывает обеспечивать поддержку в идентификаторах любых символов (во всяком случае, любых, являющихся буквами с точки зрения Юникода). Так что по крайней мере в одном "полноценном" языке это есть на уровне стандарта. jabocrack Русский Кобол -- это было нечто... )))) Пы.Сы. То, чего мне не хватает в Си, есть в Аде и -- не полностью, но во многом -- в Паскале. Посему и пишу на них, а не на Си и его потомках -- ну и на асмах, конечно (благо, я сам определяю, на каком языке мне писать).
SII +1000 с фиговли зацикливаься на С или идеологически верном стиле программирования на с++ с обязательным втыканием объектов во все, что только можно? есть куча разных языков и их диалектов. каждый протачивался больше для какойто своей цели. можно и мешать их и свой замутить. инструментов хватает. зачем говорить - "мне в С, а тем более в асме очень не хватает авто-типо/боунд чеканья"? эти языки и были задуманы с минимальным контролем в этой области. точно также не стоит выписывать те же моторы для гамов (и прочих прог с развитой функциональностью) на С++. неважно с каким по высокоуровневости фреймворком. тк, при любом изменении в сценарии и прочих куколках, которые лабают отдельные команды, придется все перекомпиливать. и заново начинать охоту на баги ЗЫ помню, в пас3 можно было писать чтото наподобие var m: array [0..1] of byte; a = m[-3]; (подробностей синтаксиса не помню). там еще можно было адрес переменной/массиву присвоить, удобнейшая штука была для ковыряния в памяти и самомодификации.
Pavia Ну дык я о том и говорю. Я не делаю перевод. Я пытался несколько лет тому назад. Исключительно интереса ради: эдакая разведка боем. Не было никакого чёткого ТЗ, просто я переводил, чтобы было "хорошо", набивая шишки и коллекционируя грабли. На этой стадии всё и зависло, поскольку я пришёл к выводу, что перевод не только не сделает мир лучше, он ещё больше усложнит ситуацию. Мало того, что для внедрения придётся ломать существующие традиции терминологии (в некотором смысле, было бы хорошо сломать, и сделать лучше, но это лишь на словах всё хорошо), так ещё ведь нельзя никоим образом дать гарантию, что в будущем не возникнет конфликтов типа character и symbol, которые переводятся одним словом "символ". statement и operator, которые оба, традиционно, переводятся словом "оператор". Я думаю если поковыряться, можно найти большее число примеров. thread/stream: thread иногда, крайне редко, переводят как "нить", но всё же у всех уже забито глубоко-глубоко в подсознание, что thread -- это поток, а поток -- это stream. Проще и дешевле научить всех программистов разговорному английскому, чем создавать и поддерживать транслятор программы с русского на английский и обратно (да-да, капитан очевидность). Для поддержания такого транслятора, должен существовать некая организация, достаточно большая чтобы отслеживать не только несколько наиболее знаковых языков, но и множество различных публикаций; организация достаточно большая чтобы отвечать на постоянно сыплющиеся вопросы. Организация которая будет централизованно принимать и стандартизировать переводы тех или иных терминов. Либо, есть такой вариант: все аглицкие термины переводить кириллической транслитерацией. Собственно этот вариант мне больше всего по душе. Но уже есть масса "традиционных" переводов, которые портят всю малину. И при этом варианте, как-то теряется глубинный смысл русских имён функций/типов и пр.
xcode он разрабатывался как основной язык для оси план9. С++ и С рассматривались как опциональные. после смерти белов, во времена план9-2 (~95-97), тот огрызок, что остался уже не мог себе позволить двигать так много и от алефа, как и от ряда других разработок посложнее отказались. другие оси были слишком слабы, чтоб поддержать возможности алефа и на них он в то время прижиться не мог. сейчас он перенесен, как я уже говорил, на план9-4 и достаточно несложно может быть перенесен на вынь и линь (особенно на линь, тк потоки там отщепляются форком). таким образом, если вы не стыкались досе с планом, то и с алефом вы столкнуться не должны были. в настоящее время живут следующие его потомки - лимбо -- симбиоз урезанного алефа с обероном. не отделим от инферно (точнее отделим, но делать это нет смысла), такого себе варианта план9-2 основанного в целях переносимости на виртуальной машине. можно рассматривать и использовать и как ось, и как фреймворк, и как обычную вм. в следствие особенностей реализации - одна из наиболее быстрых и компактных вм. го -- дальнейшее развитие лимбо. с компиляцией в натив и угибчением языка в сторону скриптовых лангов. те, "хочу простой как питон, мощный как С++, быстрый как С и чтоб потоки, синхронизации и прочие множества/хэши"