Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Mozilla разрабатывает новый язык программирования Rust"	+1 +/–
Сообщение от opennews (?), 01-Дек-10, 14:28
Представители проекта Mozilla разрабатывают (http://www.readwriteweb.com/hack/2010/11/mozilla-designing-p...) новый мультипарадигменный язык программирования Rust (https://github.com/graydon/rust). Изначально, проект Rust был основан Грейдоном Хоаре (Graydon Hoare (http://blog.mozilla.com/graydon/about/)) в 2006 году, в 2009 году проектом заинтересовалась компания Mozilla Corporation и включилась в его разработку. Исходные тексты проекта распространяются в рамках лицензии BSD. Список базовых возможностей: -  Ориентация на безопасность: -  Аккуратная работа с памятью - никаких нулевых и потерянных указателей. Автоматическое управление памятью; -  Контроль изменчивости. Язык неизменяем (Immutable) по умолчанию; -  Безопасность динамического выполнения: обработка сбоев, исключения, ведение лога, RAII / dtors; -  Typestate: возможность определения сложных инвариантов, контролирующих структуры данных. -  Ориентация на параллельность и эффект... URL: http://www.readwriteweb.com/hack/2010/11/mozilla-designing-p... Новость: http://www.opennet.dev/opennews/art.shtml?num=28837
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от emg81 (?), 01-Дек-10, 14:28	+12 +/–
объясните, пожалуйста, не-программисту, чем их существующие не устроили? я думал, что их уже столько, что всем для всего хватит. если честно, для меня не-программиста (я не могу оценить нужность нового языка) это выглядит как "ни один существующий дистрибутив Linux меня не удовлетворил, и я решил сделать пятьсот первый" минусуйте, если хотите - свое мнение я высказал и не претендую на соответствие истине, это лишь моё мнение
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3, #4, #7, #8, #13, #105

2. Сообщение от выше (?), 01-Дек-10, 14:34	+5 +/–
>объясните, пожалуйста, не-программисту, чем их существующие не устроили? Тем, что не устроили. Эволюция (не по Ламарку) расставит всё на свои места.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #5, #25

3. Сообщение от Devider (ok), 01-Дек-10, 14:36	+2 +/–
Посмотрите статистику языков (ну например http://www.tiobe.com/index.php/content/paperinfo/tpci/index....). Языков 100500, а пишут все все равно на С\С++ и Java. Ну это очередной "еще один". >ни один существующий дистрибутив Linux меня не удовлетворил, и я решил сделать пятьсот первый ИМХО Вы ответили на свой вопрос. )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #11, #99

4. Сообщение от Аноним (-), 01-Дек-10, 14:37	–1 +/–
>я думал, что их уже столько, что всем для всего хватит. нет мейнстрима, который был бы переносим, производителен (не кушал батарейку), плюс современен, так что можно делать своё. это очевидно же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #14

5. Сообщение от Oles (?), 01-Дек-10, 14:37	+/–
Это при условии что программисты будут размножаться и умирать со скоростью бактерий. А без этого тысячи языков программирования без существенной разницы только будут мешать развитию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #6, #30

6. Сообщение от выше (?), 01-Дек-10, 14:45	+3 +/–
Никто и не говорит, что процесс оптимальный. Оптимальных процессов развития пока не придумали, хотя за последних 100 лет есть некоторый прогресс, но человечество не очень рвётся его принять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

7. Сообщение от vle (ok), 01-Дек-10, 14:47	+2 +/–
http://en.wikipedia.org/wiki/Not_Invented_Here Что касается обозначенных целей и задач, то этот "новый" язык в чем-то похож на гугловский Go или, скажем, Erlang. Это если ставить легковесность потоков во главу угла. Все остальное -- просто пустой треп. Ничем не лучше, например, Lua, где все то же самое, и мультипарадигменность и сборщик мусора и легкая встраиваемость и интеграция с "С" и прочее и прочее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #15, #103

8. Сообщение от Аноним (-), 01-Дек-10, 14:52	–2 +/–
Если придумывают новые, значит не все так как хотелось бы со старыми. Да и только наивный дурак будет утверждать, что человечество на пике своего развития в теории и практике программирования. Мы сейчас на уровне обезьянок в этой области, сделали пару шажков на пути до Луны. А насчет Rust'а, я предрекаю ему скорейшую смерть. Объяснять почему не буду, субъективное мнение, все равно в этой области никто ничего не понимает, объективным быть трудно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

9. Сообщение от V (??), 01-Дек-10, 14:57	+2 +/–
если он будет как XUL, то я против ))
Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от FractalizeR (ok), 01-Дек-10, 14:57	+/–
>Язык неизменяем (Immutable) по умолчанию; Это как?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17

11. Сообщение от Serega (??), 01-Дек-10, 14:59	+3 +/–
вы не учитываете что из академических языков фичи перекочёвывают в мейнстрим-языки. Сравните Java 1.4 и Java 7, C++98 и C++0x Просто новые теории в области ЯП обкатываются там, где это удобно и где их можно развить в полной мере (а для этого как раз часто приходится создавать как раз целиком новый язык). И это, пожалуй, правильно. А про конкретно этот язык и его цели - ну что ж, плох тот солдат, который не мечтает стать генералом :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

12. Сообщение от Аноним (-), 01-Дек-10, 15:08	+2 +/–
>Мультипарадигменный, исключительно функциональный, императивно-процедурный, объектно-ориентированный, поддерживающий параллельную actor-модель; "Я одену все лучшее сразу".
Ответить | Правка | Наверх | Cообщить модератору

13. Сообщение от Ананим (?), 01-Дек-10, 15:09	+/–
Например: мне нравится rexx за его простоту и логичность - код тпа ... if then=if then say if/9+say*then ... внём выполнится как и задумано и не будет "выкрика" интерпритатора/компелятора о том что тут синтаксическая ошибка... Но мне не нравится то, что переменные могут называться только латинскими буквами, хочу переменную обзывать не "ochen_vajnayz_peremennaya", а просто "фигня_из_файла". Что мне делать? Можно написать разработчику, а можно взять исходники, подковырять их, дав возможность не только переменные кирилицей писать, но и операторы (if - ежеле, then - тады, say - изложи,...) и выкладываю, вдруг кому из староверов сгодиться... Вот так и создаётся куча языков/дистрибутивов/генно-модефицированых продуктов и т д...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

14. Сообщение от Devider (ok), 01-Дек-10, 15:10	–1 +/–
Идеала-то? Так его нигде нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

15. Сообщение от sk (??), 01-Дек-10, 15:19	+3 +/–
глупости. Где в Луа статическая типизация и контроль мутабельности? Луа с таблицами как основной структурой данных трагически мутабелен. Там есть корутины, которые позволяют писать в конкуррентной парадигме, но мультитредовость и луа плохо совместимые вещи, поэтому оно concurrent, но не parallel, если не считать разного рода самоделок поверх основной реализации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #16, #24

16. Сообщение от vle (ok), 01-Дек-10, 15:38	+/–
> Где в Луа статическая типизация и контроль мутабельности? Если нужен чуть-более статически типизированный язык, можно взять Pike, тоже скриптовой. Если нужно аж чтоб совсем завернуться, можно взять SML или Caml. Если не выпендриваться, сойдут Java, Oberon-2 и многие многие тысячи других, вполне себе безопасных. Зачем нужен "контроль над мутабельностью" я пока себе слабо представляю. > Там есть корутины, которые позволяют > писать в конкуррентной парадигме, но мультитредовость и луа плохо совместимые вещи, > поэтому оно concurrent, но не parallel, Про Go и Erlang я уже сказал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #23, #28

17. Сообщение от Аноним (-), 01-Дек-10, 15:47	+/–
Все переменные по умолчанию константы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #18

18. Сообщение от FractalizeR (ok), 01-Дек-10, 15:49	+/–
> Все переменные по умолчанию константы. Гм. А это как? И зачем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #31

19. Сообщение от Аноним (-), 01-Дек-10, 15:52	+/–
хранение строк в utf8...
Ответить | Правка | Наверх | Cообщить модератору

20. Сообщение от vle (ok), 01-Дек-10, 15:52	–1 +/–
> UTF8 strings. Сколько же поколений будет наступать на одни и те же грабли :-/
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22, #29, #75

21. Сообщение от Anon (?), 01-Дек-10, 15:57	–2 +/–
еще одна поделка с кейвордами типа "fn", "let"... а потом они будут гудеть на каждом углу что оно лаконичнее чем C...
Ответить | Правка | Наверх | Cообщить модератору

22. Сообщение от Crazy Alex (??), 01-Дек-10, 16:10	+/–
А чем UTF для строк не угодил, собственно? Максимум, что еще нужно - альтернативные строки, хранимые как массивы 32-битных символов со свободным преобрахзованием между этими двумя вариантами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #27, #83

23. Сообщение от sku (ok), 01-Дек-10, 16:16	+6 +/–
>> Где в Луа статическая типизация и контроль мутабельности? > Если нужен чуть-более статически типизированный язык, можно взять Pike, > тоже скриптовой. тут дело в чём, этот раст не просто "статически типизированный" в смысле C, он умеет много хорошего и полезного, вроде disjoint union types и typestate, который, в частности, позволяет исключить класс ошибок обращения к неинициализированным данным или использования null pointers. > Если нужно аж чтоб совсем завернуться, можно взять SML или Caml. Rust позиционируется, как "язык для системного программирования" и ограничивает возможности системы типов исходя из соображений эффективности и багоустойчивости, идей, которые не проверены эдак тремя-четырьмя десятками лет, там нет. За вычетом этого Rust и ML немного похожи, что неудивительно, так как автор (Graydon Hoare) фанат Ocaml'я и компилятор Rust'a большей частью на окамле же и написан. Однако SML/Caml не подходят для той ниши системного программирования, в которую целится Rust. Не подходят, в частности, потому, что не поддерживают то самое RAII, не дают возможности подкрутить сборку мусора, не поддерживают прямых вызовов C. В этой нише сейчас только, фактически, намечаются три языка: C, Rust, BitC. Два последних ещё в колыбели. D для этой ниши великоват, он прямой последователь языка C++, не хочется даже думать об использовании D где-нибудь в embedded, месте где C благодаря простоте рантайма хорошо себя проявляет. Но C когда был сделан, пора бы уже как-то смениться поколениям. > Зачем нужен "контроль над мутабельностью" я пока себе слабо представляю. Формально иммутабельность дает коду свойство, называемое referential transparency: если просто, то функция, будучи вызванной с одним набором параметров, всегда возвратит один и тот же результат. Это очень упрощает рассуждения о корректности кода. В случае с наличием мутабельности дело усложняется, результаты зависят от _времени_: какое сообщение было получено объектом раньше, если мы говорим терминах message passing'a и тому подобное. Что в этом плохого: почти все баги, возникающие при concurrent программировании: злополучные races итп., растут из мутабельности и расшаривании мутабельного состояния. При отсутствии по умолчанию мутабельности концепция времени _неявно_ в код не затаскивается, надо явно указывать, что и где будет мутабельным. Это относительно новая для CS идея, которую стали принимать как имеющую практическое применение в конце 70-х, наверное, когда Стилом была доказана эффективность функциональных языков ("Debunking Myths" и другие Lambda Papers). Эта идея получила развитие в конце 80-х, когда Уодлером была придумана концепция монад как, в частности, и средство контроля над мутабельностью. Но монады штука слишком новая для системщиков, поэтому её появления в обозримом будущем в языках этой ниши не стоит ждать. Авторы Go ещё более осторожны и дальше результатов годов 60-х не идут, считая, что этого достаточно (Update: неверно, Hoare, CSP 1978). Кому-то и Си достаточно. Кому-то хочется средств исключения классов ошибок, предоставляемых статической типизацией. > Про Go и Erlang я уже сказал. Erlang - язык с динамической типизацией, компилирующийся в байткод виртуальной машины ErlangVM. Тут никакой речи о прямых вызовах Си не идет. В Го этого тоже, кстати, нет, вызовы через SWIG.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #33, #41, #53, #91

24. Сообщение от vle (ok), 01-Дек-10, 16:17	+/–
В конце концов, нужно различать собственно язык программирования и его реализацию. Если очень уж хочется добиться чего-то конкретно, берешь готовый ЯП с наработанными уже для него библиотеками и пишешь другую РЕАЛИЗАЦИЮ, как это делают любители CLisp, Scheme, CAML, SML и прочих "Паскалей" и "С". Языков, на уровне парадигм и спецификаций не противоречащих целям, практически любым, найти можно полно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #32

25. Сообщение от DeadLoco (ok), 01-Дек-10, 16:27	+1 +/–
Нажал плюс за понимание эволюционного характера технического прогресса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

26. Сообщение от Erley (ok), 01-Дек-10, 16:27	–2 +/–
Недавно в мозиллу проинвестировал кто-то дофига денег, вот и не знают куда тратить...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #78

27. Сообщение от vle (ok), 01-Дек-10, 16:28	–1 +/–
> А чем UTF для строк не угодил, собственно? Максимум, что еще нужно > - альтернативные строки, хранимые как массивы 32-битных символов со свободным > преобрахзованием между этими двумя вариантами. Тем, что в 21-м веке - это просто маразм. Для внутреннего представления строк лучше всегда использовать 32-битные символы, и забыть про все эти замшелости типа utf-8. "Свободное преобразование" в utf-8 и обратно IIRC сделано как раз в Pike. Удовольствия полные штаны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #34, #35

28. Сообщение от VoDA (ok), 01-Дек-10, 16:30	+/–
Судя по всему Immutable объектов дает возможность функционального программирования. Или ФП возможен только при Immutable объектах. Дальше функциональное программирование теоретически легко параллелится. В отличии от С/С++/Java, где для распараллеливания нужно писать код руками (или пользоваться спец средствами типа JavaEE серверов, где обработка запросов идет параллельно, но сами запросы не параллелятся дальше).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #96

29. Сообщение от VoDA (ok), 01-Дек-10, 16:33	+1 +/–
У вас представление строк для разработчика в чем то другом? Тогда постоянные грабли с многоязычностью... ну нах такой язык ;) PS внутреннее представление string может быть хоть во фракталах, если это не сильно затратно =)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

30. Сообщение от DeadLoco (ok), 01-Дек-10, 16:34	+22 +/–
> Это при условии что программисты будут размножаться и умирать со скоростью бактерий. > А без этого тысячи языков программирования без существенной разницы только будут мешать > развитию. Вы неправы. Новые виды внутри техноценоза возникают в силу мутабильности. То-есть, вот этот Хоаре и есть мутаген, который породил совершенно новый вид. Теперь этот вид начнет бороться за жизнь - разумеется, не с монстрами вроде сей/жабы, а с такими же молодыми мелкими видами. Они будут отращивать себе разные органы, вроде контроля указателей, или мощного параллелизма, они будут стремиться найти свою эконишу. В процессе борьбы за существование эти виды будут сдыхать сотнями, появляться сотнями, в них будут возникать тысячи новшеств, они превратят в питательную среду места, где раньше вообще жизни не было. И один раз на миллион из вот такой мелочи вдруг разовьется очередной царь техноценоза. Это нормально, никому не мешают эти тысячи языков, у них своя собственная, очень нужная всем жизнь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #36

31. Сообщение от Аноним (-), 01-Дек-10, 16:34	–1 +/–
Учите Haskell :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

32. Сообщение от sku (ok), 01-Дек-10, 16:35	+1 +/–
> В конце концов, нужно различать собственно язык > программирования и его реализацию. Если очень уж хочется > добиться чего-то конкретно, берешь готовый ЯП с наработанными > уже для него библиотеками и пишешь другую РЕАЛИЗАЦИЮ, > как это делают любители CLisp, Scheme, CAML, SML и прочих > "Паскалей" и "С". > Языков, на уровне парадигм и спецификаций не противоречащих целям, > практически любым, найти можно полно. В Scheme dynamic latent typing реализацией не исправишь. Нужно делать другой язык, который уже неможно будет называть Scheme. SML требует чрезвычайно умных компиляторов, с dataflow analysis и прочими штуками на грани современных технологий для реализации свойства языка principal typing property - кроме пары исключений, типы _всегда_(а не "в большинстве случаев") можно вывести при type omitting. У Caml рантайм вполне большой и сложный, не такой, как у C++, но и с C не сравнить. Он такой не потому что авторы языка не умеют писать компиляторы, а потому что сильно проще не получится, таковы архитектурные решения языка, влекущие за собой решения в реализации. "Паскали" и "Си" - попробуйте на них написать квиксорт, который умеет оперировать с разными типами и принимает разные функции сравнения для этих типов. Это простейшая задача, в Си она решается за счет указателей на воид, фактически, в обход тайпчекера. Проверка корректности таких обобщенных операций целиком ложится на программиста. Хотя это можно делать компилятором. В шестидесятых было нельзя, сейчас часто - можно. В паскале Вирта написание такого обобщенного квиксорта невозможно - нет подходящих средств в языке. Так и со всеми другими языками. Фактически, подходят в нишу только C, C++, ATS, D, Go, Rust, BitC. Если сузить нишу, то C, Rust, BitC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #56

33. Сообщение от VoDA (ok), 01-Дек-10, 16:37	–1 +/–
> Формально иммутабельность дает коду свойство, называемое referential transparency: если просто, то функция, будучи вызванной с одним набором параметров, всегда возвратит один и тот же результат. А как же быть с внешними вызовами? Вызов одной и той же функции с одним и тем же запросом к СУБД может вернуть разные результаты. То же самое с ФС и т.п.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #37

34. Сообщение от yk4ever (?), 01-Дек-10, 16:37	+1 +/–
Дык UTF-32 ведь память будет жрать безбожно. Современные языки жонглируют в памяти кучей ASCII-идентификаторов, для них UTF-8 в самый раз. И вообще, строки в наши дни в основном обрабатывают поточно, равноширинность не критична.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #43

35. Сообщение от VoDA (ok), 01-Дек-10, 16:39	+/–
Так внутреннее представление вообще никак не описано, описано представление для программиста и пользователя. И чем не угодил UTF-8 при работе с внешними системами, надписи на страничке сайта или GUI?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #46

36. Сообщение от Аноним (-), 01-Дек-10, 16:49	–2 +/–
Ну это совсем дарвинизм. Вообще задача прогресса в такой среде, это выделять и подкармливать удачные комбинации, помогать им расти, создавать остальным лучшие условия. Без этого никакой С++ не вырастит, что уж говорить про Жабу. Собственно говоря, крупные компании этим и занимаются, вот и мозилла подключилась, может, что-нибудь и получится. Хотя врядли конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #40

37. Сообщение от sku (ok), 01-Дек-10, 16:52	+1 +/–
>> Формально иммутабельность дает коду свойство, называемое referential transparency: если просто, то функция, будучи вызванной с одним набором параметров, всегда возвратит один и тот же результат. > А как же быть с внешними вызовами? Вызов одной и той же > функции с одним и тем же запросом к СУБД может вернуть > разные результаты. То же самое с ФС и т.п. Тут контроль над мутабельностью и нужен, в хаскелле такие вещи оборачиваются в монады, в F# они называются workflows. В ML-семействе, Scheme, Clojure и многих никаких особенных средств контроля язык не предоставляет, надо лишь объявить явно, что эта вот штука будет мутабельной, а дальше как в С и других императивных языках, с той лишь разницей, что не всё по умолчанию может быть изменено. Иммутабельность это не просто "константы" и не просто referential transparency, за ней тянется реализация основных структур данных (очереди итп) как иммутабельных. Иммутабельность структуры данных означает, что если у вас изменился один элемент, то будет создана новая структура данных, в которой неизменившиеся элементы ссылаются на элементы старой, а изменившийся элемент - изменился. Когда элементы "старой" структуры больше не нужны, они собираются сборщиком мусора. Сейчас такие структуры сплошь и рядом в джаве, C#, STL'e плюсов и других мейнстримных языков. А как именно контроль над этим выглядит или будет выглядить в Rust, пока не знаю, подожду пока он чуть стабилизируется прежде чем смотреть глубже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #38

38. Сообщение от sku (ok), 01-Дек-10, 16:54	+/–
>[оверквотинг удален]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

40. Сообщение от DeadLoco (ok), 01-Дек-10, 17:01	+2 +/–
> Ну это совсем дарвинизм Да! > Вообще задача прогресса в такой среде, это выделять и подкармливать удачные комбинации, Ох, ошибаетесь... Каждый вид сам должен пробиться и выжить в конкурентной борьбе с другими видами в этой нише. Судьба языка должна зависеть от качеств самого языка, а не от баблища, которое в этот язык заливается проприетарщиками. Вспомните, сколько бабла было ухнуто в визуал-бейсик и делфи. И где теперь эти языки? > Собственно говоря, крупные компании этим и занимаются, Нет, они занимаются другим :) Они дают возможность породиться новым языкам и влиться в конкуренцию и отбор по Дарвину. Их интерес - в движле, в шебуршании, в постоянном бурлении эволюционной среды, а не в том, чтобы вылупить свой язык, всех победить и жить на лицензионные отчисления. Ну, то-есть, это неплохой вариант, но практически нереальный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #42, #49, #57, #68

41. Сообщение от Tav (ok), 01-Дек-10, 17:03	+4 +/–
Мутабельность, иммутабельность... По-русски это называется изменяемостью и неизменяемостью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

42. Сообщение от Oles (?), 01-Дек-10, 17:07	+1 +/–
> Каждый вид сам должен пробиться и выжить в конкурентной борьбе с другими видами в этой нише. как буд-то у вас есть пару сотен миллионов лет в запасе
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #45

43. Сообщение от vle (ok), 01-Дек-10, 17:12	–2 +/–
> Дык UTF-32 ведь память будет жрать безбожно. Не будет. Это копейки. > Современные языки жонглируют в памяти > кучей ASCII-идентификаторов, для них UTF-8 в самый раз. Как работает сам интерпретатор/компилятор мне все равно, не об этом речь. > И вообще, строки > в наши дни в основном обрабатывают поточно, Ввод/вывод в кодировке, заданной локалью, например utf-8. Внутреннее представление -- всегда 32бита. Все очень просто. > равноширинность не критична. Критична. Например в регекспах и вообще практически любых операциях над строками. Верх маразма -- это хранить вместе со строкой еще и кодировку и перекодировать по мере требования. Чему людей только в школе учили?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #44, #48, #50

44. Сообщение от yk4ever (?), 01-Дек-10, 17:16	+1 +/–
>> Дык UTF-32 ведь память будет жрать безбожно. > Не будет. Это копейки. Наивное предположение. Поковыряйте дампы памяти современных программ, посмотрите из чего они состоят. >> равноширинность не критична. > Критична. Например в регекспах и вообще практически > любых операциях над строками. Нет, неправда. Регэкспы - поточны, как и большинство операций над строками. Единственная операция, где равноширинность критична - это произвольный доступ к символу или слайсу. Но как часто оно возникает на практике?..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #47

45. Сообщение от DeadLoco (ok), 01-Дек-10, 17:19	+1 +/–
> как буд-то у вас есть пару сотен миллионов лет в запасе Разница в том, что мутабильность языковой среды в сотни раз превышает мутабильность биологического материала. И если природе понадобилось полтора миллиарда лет, чтобы от доклеточной жизни через одноклеточных, многоклеточных, через хордовых, рыб, пресмыкающихся, теплокровных дойти до сегодняшней биосферы, то языки от бинарного кода, задаваемого тумблерами, до объектов, лямбды и предикатов проэволюционировали всего за полвека. То-есть, в 30 миллионов раз быстрее. И скорость такова именно потому, что конкуренция необычайно высока, и новые виды языков появляются чуть ли не каждый день.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

46. Сообщение от vle (ok), 01-Дек-10, 17:26	+/–
> Так внутреннее представление вообще никак не описано, описано > представление для программиста > и пользователя. У меня есть строка str размером в 1000000 символов на неизвестном мне языке. Мне нужно выделить подстроку длиной 5 символов, начиная с 999000-ого символа. Есть возможность написать что-то вроде str[999000..999004] или substr(str, 999000, 5)? Насколько быстро выполнится эта операция? > И чем не угодил UTF-8 при работе с внешними системами, надписи на > страничке сайта или GUI? Для внешних систем будет то, что нужно внешним системам. Речь не об этом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #51, #52, #76, #101

47. Сообщение от vle (ok), 01-Дек-10, 17:30	+1 +/–
>>> Дык UTF-32 ведь память будет жрать безбожно. >> Не будет. Это копейки. > Наивное предположение. Поковыряйте дампы памяти > современных программ, посмотрите из чего > они состоят. Я вас умоляю. "Дампы современных программ"... >>> равноширинность не критична. >> Критична. Например в регекспах и вообще практически >> любых операциях над строками. > Нет, неправда. Регэкспы - поточны, как и большинство операций над строками. Нет. Большинство алгоритмов над строками как раз не поточны и требуют быстрый random access. > Единственная операция, где равноширинность критична - это произвольный доступ к символу > или слайсу. Но как часто оно возникает на практике?.. Именно она практически всегда и возникает, а вот последовательная обработка символов практически никогда не нужна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #54

48. Сообщение от User294 (ok), 01-Дек-10, 17:30	+/–
> Не будет. Это копейки. Ага. До тех пор пока не потребуется работать с большим количеством строк, например. А когда встанет вопрос - сожрать N памяти или 4N под одну и ту же операцию, станет совсем не прикольно. Никто не спорит что у UTF-8 есть свои дебилизмы как то отсутствие четкого понимания что N байтов - это гарантированно ровно M символов, что совсем не упрощает скажем взятие 125-й уникодной буквы из вон того массива. Но зато для английского текста он кушает в 4 раза меньше памяти, а для русского - в два. И конверсия на лету - будет проц грузить. И весь внешний мир и другие программы оперируют отнюдь не в 32-битном уникоде, так что конверсии обеспечены (или ваша сферическая программа работает в вакууме?). В общем напрашивается вывод что некоторым зажравшимся товарисчам уже некуда девать оперативку и вычислительную мощь проца. Ну вот вы такими программами и пользуйтесь, имхо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #66

49. Сообщение от Аноним (-), 01-Дек-10, 17:42	+/–
>Ох, ошибаетесь... Ну, например интернет, которым вы сейчас пользуетесь, был подкормлен DARPА'ой. Железные дороги, медицина и космос - принципиально убыточные. Можете делать выводы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

50. Сообщение от sku (ok), 01-Дек-10, 17:42	+/–
В оправдание автору можно привести разве что распространенность UTF-8 сейчас  ( http://googleblog.blogspot.com/2010/01/unicode-nearing-50-of... ) и заботу о памяти. А так да, было бы удобней с UCS-4.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

51. Сообщение от User294 (ok), 01-Дек-10, 17:47	+/–
> substr(str, 999000, 5)? Насколько быстро выполнится эта операция? Да, именно в утф-8 может получиться не прикольно, т.к. нельзя быстро отмотать к символу номер N. С другой стороны - а часто ли это надо? Чтобы бороться с проблемой, надо понимать насколько она мешает всем жить и сравнить как оно по сравнению с другими проблемами. Иначе можно оказаться в роли одного персонажа, который боролся с ветряными мельницами. > Для внешних систем будет то, что нужно внешним системам. Ну да, конечно, если все заранее конвертить из utf-8 в 32-битный уникод.... проблема только в том что оно распухнет в разы (для инглиша - в 4 раза!), и кроме того, придется все данные конвертить. Так что если вам могут прислать из внешнего мира строку в N символов ее придется полностью пропарсить и сконвертить. Все N символов вообще. Что как-бы ничем принципиально не лучше substr там же, но еще и гарантированно происходит для вообще каждой строки из внешнего мира, независимо от того надо ли будет потом на ней делать substr или нет. А программы все-таки обыно не в вакууме работают, так что эта конверсия будет там и тут. Не боитесь что нужда ее делать поубивает все плюсы от возможности хапнуть N-ный символ просто и быстро? > Речь не об этом. Да никто и не спорит что utf-8 идеален. Он всего лишь компромисс. Достаточно разумный для того чтобы быть используемым в ряде ситуаций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

52. Сообщение от yk4ever (?), 01-Дек-10, 17:49	+/–
> Мне нужно выделить подстроку длиной 5 символов, начиная с 999000-ого символа. Очень типовая задача. Большинство программ только этим и занимаются. "999000" - это вообще магическая константа > substr(str, 999000, 5)? Насколько быстро выполнится эта операция? За несколько миллисекунд на современном процессоре. Для одноразовой задачи - вполне достаточно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #69

53. Сообщение от vle (ok), 01-Дек-10, 17:54	+/–
>> Если нужно аж чтоб совсем завернуться, можно взять SML или Caml. > Rust позиционируется, как > "язык для системного программирования" и ограничивает возможности > системы типов исходя из соображений эффективности и багоустойчивости, идей, которые не > проверены эдак тремя-четырьмя десятками лет, там нет. Для типичных прикладных задач и большинства системных, за исключением разьве что сетевых приблуд, иммутабельность абсолютно не нужна. Я тут пробежался по коллегам, пишущим на Ruby. Ни один мне не сказал "да, эта фишка мне нужна, не могу без не жить". Больше того, никто эту фишку сознательно не использует, просто воспринимают как данность. Конечно, мы не пишем сетевые сервисы, и практически все программы однопоточны, такие задачи. > В этой нише сейчас только, фактически, намечаются три > языка: C, Rust, BitC. Два последних ещё в колыбели. D для > этой ниши великоват, он прямой последователь языка C++, не хочется даже > думать об использовании D где-нибудь в embedded, месте где C благодаря > простоте рантайма хорошо себя проявляет. Но C когда был сделан, пора > бы уже как-то смениться поколениям. По поводу иммутабельности в системных и прикладных задачах см. выше. Для касается ембеда, то там тем более иимутабельность не нужна. Лишние накладные расходы и абсолютно никаких выгод. См. бенчмарки ruby против Lua/Go. Если б я выбирал платформу для ембеда, я бы выбрал Lua или Java Script, практически без вариантов. Для совсем уж критичных случаев Forth.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #55, #58, #60

54. Сообщение от yk4ever (?), 01-Дек-10, 17:55	+1 +/–
> Нет. Большинство алгоритмов над строками как раз не поточны > и требуют быстрый random access. Какие именно, м? split - поточный contains - поточный replace - поточный рекэкспы - поточные printf - поточный startswith, endwith - поточные Не нужен random access строкам, не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #65

55. Сообщение от yk4ever (?), 01-Дек-10, 18:02	+/–
> Для касается ембеда, то там тем более иимутабельность не нужна. > Лишние накладные расходы и абсолютно никаких выгод. См. бенчмарки ruby > против Lua/Go. По-вашему, Ruby тормозит из-за иммутабельности? Очень любопытно. Я вам поведаю неожиданное: в Ruby строки как раз мутабельные, а в Python нет. И при это Python как правило быстрее Ruby. А ещё можно сравнить на бенчмарках Perl (мутабельные строки) vs Haskell (иммутабельные). Угадайте, кто быстрее? Впрочем, если хотите быть дежурным чепухоносиком темы - нет препятствий патриотам :]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #59

56. Сообщение от vle (ok), 01-Дек-10, 18:11	+/–
>> В конце концов, нужно различать собственно язык >> программирования и его реализацию. Если очень уж хочется >> добиться чего-то конкретно, берешь готовый ЯП с наработанными >> уже для него библиотеками и пишешь другую РЕАЛИЗАЦИЮ, >> как это делают любители CLisp, Scheme, CAML, SML и прочих >> "Паскалей" и "С". >> Языков, на уровне парадигм и спецификаций не противоречащих целям, >> практически любым, найти можно полно. > В Scheme dynamic latent typing реализацией не исправишь. Дело не конкретно в схеме или паскале. Дело в подходе. Строить новый велосипед, для которого нет и будет никогда библиотек без многомиллионных/миллиардных вливаний или сделать другую реализацию уже известного языка. "Для SML нужны сильно умные компиляторы" -- аргумен не сильно убедительный. Что касается, сортировки, повторюсь, С здесь ни при чем. Динамических языков и языков с параметризованными классами и функциями полно, например уже упоминавшиеся SML, Caml, C++, Ada, Oberon. Да и ОО языков с полиморфизмом вагон и тележка. Вобщем, если ембед, то иммутабельность совершенно ненужная лишняя плюшка, для этого уже есть Lua, Scheme, Java Script, Forth, cyclone какой-нибудь, если хочется безопастности. Не вижу здесь места для нового языка. Если сетевые приблуды -- Erlang, Go. Не думаю, что Rust/Mozilla сможет составить им конкуренцию в ближайшие 10-15 лет. Если для прикладных задач, тогда новый язык тем более никто не примет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

57. Сообщение от анонимм (?), 01-Дек-10, 18:11	–3 +/–
>Вспомните, сколько бабла было ухнуто в визуал-бейсик и делфи Да уж поменьше, чем в сипэпэ и похапэ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

58. Сообщение от sku (ok), 01-Дек-10, 18:12	+/–
> Lua или Lua хороший выбор, стабильная реализация, хорошие библиотеки, сам он поднимается на платформе как маленькая библиотека над ANSI C. Пойнт людей, делающих сейчас эти языки в том, что теория со времен си сдвинулась дальше и исследования теории типов 60-80 годов позволяют получить ощутимые _инженерные_ результаты. Цена ошибки прямо пропорциональна времени её обнаружения. Если ошибка ловится во время прогона тестов, то это замечательно, надо только ждать, пока тесты прогонятся, обычно несколько итераций. Если не словилась, то вывалится юзеру в рантайме и вернется, возможно, в виде багрепорта. Дешевле те баги, которые можно ловить во время компиляции. Потом прогоняя, конечно, тесты и правя багрепорты. :) Некоторые классы ошибок можно сделать дешевле, даже в C++ время компиляции обычно меньше времени прогона тестов. И, конечно, тесты могут словить присутствующую ошибку. Проверка типов может доказать корректность статических инвариантов, т.е. формально доказать отсутствие целых классов ошибок. Как бы непривычны для людей, привыкших к императивному программированию не были подобные языки, вещи, дающие реальный профит в некоторых областях, применяются или будут применяться в этих областях. В hardware логике, например, без статического анализа никуда - слишком высока цена ошибки. Упомянутый Systems programming - не только embedded, а ещё и ОС, и низкоуровневые сетевые приложения. Статически доказанная корректность работы с сетевым протоколом, как это умеет Idris, дорогого стоит. Так что это нужно, иначе бы люди этим не занимались. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #63

59. Сообщение от vle (ok), 01-Дек-10, 18:15	+/–
>> Для касается ембеда, то там тем более иимутабельность не нужна. >> Лишние накладные расходы и абсолютно никаких выгод. См. бенчмарки ruby >> против Lua/Go. > По-вашему, Ruby тормозит из-за иммутабельности? Нет конечно. Скорее всего там миллион причин. > Очень любопытно. > Я вам поведаю неожиданное: в Ruby строки как раз мутабельные, а в > Python нет. И при это Python как правило быстрее Ruby. И Питон и Руби -- тормозные, монструозные языки. Ни один из них мне не интересен. Кто из них немного менее тормозной не сильно интересно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #61

60. Сообщение от sku (ok), 01-Дек-10, 18:16	+/–
> Для типичных прикладных задач и большинства системных, за исключением разьве что > сетевых приблуд, иммутабельность абсолютно не нужна. А для работы упомянутых систем типов, статического анализа иммутабельность как раз нужна, выше было вкратце написано почему (referential transparency).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

61. Сообщение от yk4ever (?), 01-Дек-10, 18:17	+/–
> И Питон и Руби -- тормозные, монструозные языки. > Ни один из них мне не интересен. > Кто из них немного менее тормозной не сильно интересно. И такая позиция бывает. Но не совсем понятно тогда, зачем вы так смело рассуждаете о вещах, не входящих в сферу ваших интересов/компетенции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

63. Сообщение от vle (ok), 01-Дек-10, 18:30	+/–
> Так что это нужно, > иначе бы люди этим не занимались. :) Да пусть ковыряются, кто ж против. Только вот раскрутить новый ЯП примерно так же сложно, как новую операционную систему. Касательно, статических доказательств работы с сетевыми протоколами... Универсальный язык программирования для этого изобретать совершенно не нужно. Сети Петри придуманы давно, если я правильно понимаю, о чем этот Idris. P.S. И мне все еще не понятно, причем здесь Mozilla. Зачем *ИМ* понадобился еще один proof of concept. В их то задачи явно не входит обслуживание миллионов клиентов единовременно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #64

64. Сообщение от sku (ok), 01-Дек-10, 18:40	+1 +/–
>> Так что это нужно, >> иначе бы люди этим не занимались. :) > Да пусть ковыряются, кто ж против. > Только вот раскрутить новый ЯП примерно так же сложно, > как новую операционную систему. Касательно, статических доказательств > работы с сетевыми протоколами... > Универсальный язык программирования для этого изобретать совершенно не нужно. > Сети Петри придуманы давно, если я правильно понимаю, о чем этот Idris. Idris это попытка (2010 г.) совместить зависимые типы и программирование системного уровня. Зависимые типы тоже придуманы давно, лет сорок назад. Вот pdf с обзором: http://www.cs.st-andrews.ac.uk/~eb/writings/plpv11.pdf > P.S. > И мне все еще не понятно, причем здесь Mozilla. Зачем *ИМ* понадобился > еще один proof of concept. В их то задачи явно не входит > обслуживание миллионов > клиентов единовременно. We aren't going to ship Rust code in Firefox N for any N I can yet foresee, but we are not just hacking on Rust for its own sake. I spoke about this at the #moz10 summit; I'll blog about it shortly. (c) Brendan Eich Mozilla's use of assertions is well-established and part of our development process (we fuzz-test and automatically test debug builds, and treat assertbotches seriously). With Rust we can write check statements instead. This looks likely to be a pure win for our C++ hackers who try out Rust, whatever else happens. It's not a hard shift in programming culture (compared, say, to lack of nominal types and C++-ish OOP support), and it yields compile-time errors instead of possibly-missed runtime assertbotches. Every C or C++ program I've ever worked on, including Unix kernels in my youth, had assertions and even runtime checks attempting to enforce higher level invariants than could be expressed in the host language's type system. Typestate (along with better failure handling of course) looks exactly like what those of us frustrated by the debug-only and unrecoverable nature of assertions have always wanted. Even now, in Mozilla code, we optimize performance-critical paths by hand according to contracts and higher-level invariants or protocols that are implicit and unchecked, ignoring comments and assertions. Of course, there are many ways to beef up one's programming language, or get a better one, to automatically check (statically, dynamically, or both) such high-level contracts. Many of you LtU members know more about this general area than I ever will. But with Rust's typestate system we do not have to make a big bet on a researchy static-only type system, or a still-researchy dynamically checked contract system, or any such thing. Instead, we choose a well-proven (but under-appreciated) approach that resembles our current use of assertions. We can't graft typestate onto C++ easily, although we have invested heavily in C++ static analysis. Anyway C++ would need other major changes to scale up to manycore targets safely. So we're exploring typestate along with other well-researched ideas in Rust. (c) он же
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

65. Сообщение от vle (ok), 01-Дек-10, 18:48	+/–
>> Нет. Большинство алгоритмов над строками как раз не поточны >> и требуют быстрый random access. > Какие именно, м? > split - поточный Нет. См contains. > contains - поточный То есть известные с 60-х алгоритмы Боера-Мура или Кнута-Мориса-Пратта не говорят совсем ни о чем? И у них десятки, если не сотни различных модификаций. > replace - поточный См contains. > рекэкспы - поточные Вы представляете себе как устроены регекспы внутри? К чему приводит [[:alpha:]] внутри регекспа -- к тому, что ц целях эффективности строящегося автомата буду фигурировать 32-битные числа, а не последовательности переменной длины. Соответственно, строя, которая match-ится должна быть преобразована в нормальные символы. > printf - поточный > startswith, endwith - поточные Нуразьве что. А еще copy! > Не нужен random access строкам, не нужен. Это utf-8 не нужен, а random access для строк нужен. Вообще-то по алгоритмам для работы со строками пишутся толстенные книги. И нет, они посвящены не copy или не printf.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #67, #70

66. Сообщение от arturpub (ok), 01-Дек-10, 18:51	+2 +/–
Это во-первых, а во-вторых у них с UCS4 все вроде красиво, пока не... http://en.wikipedia.org/wiki/Unicode_equivalence Но ведь для них все это слишком сложно? ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #71

67. Сообщение от sku (ok), 01-Дек-10, 18:54	+1 +/–
Тут такое дело, <...> Substring search is just byte string search. Properties 2, 3, and 4 imply that given a string of correctly encoded UTF-8, the only way those bytes can appear in a larger UTF-8 text is when they represent the same code points. So you can use any 8-bit safe byte at a time search function, like strchr or strstr, to run the search. Однако, вместе с тем UTF-8 does give up the ability to do random access using code point indices. Programs that need to jump to the nth Unicode code point in a file or on a line—text editors are the canonical example—will typically convert incoming UTF-8 to an internal representation like an array of code points and then convert back to UTF-8 for output, but most programs are simpler when written to manipulate UTF-8 directly. (c) Russ Cox, http://research.swtch.com/2010/03/utf-8-bits-bytes-and-benef...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #74

68. Сообщение от Вася (??), 01-Дек-10, 18:59	–2 +/–
>Вспомните, сколько бабла было ухнуто в визуал-бейсик и делфи. И где теперь эти языки? Слив не засчитан. Дельфи - это не язык а среда разработки, а паскаль себя нормально чувствует в академической среде. Басик(нет) себя тоже замечательно чувствует. И обычный тоже неплохо - учитывая распространненость МС Офиса. ------------------- А мозилле видимо занятся нечем, или лавры хрома покоя недают.... Типа - вон у хрома только ось, а у нас - аж свой язык. ------------------- Лучше занимайтесь биологией, у вас это лучше получается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #95, #104

69. Сообщение от vle (ok), 01-Дек-10, 19:00	+/–
>> Мне нужно выделить подстроку длиной 5 символов, начиная с 999000-ого символа. > Очень типовая задача. Извлечение подстроки в строке -- типовая задача. > Большинство программ только этим и занимаются. "999000" - это > вообще магическая константа 999000 -- это специально для тех, кто не знаком с элементарными основами типа O(). >> substr(str, 999000, 5)? Насколько быстро выполнится эта операция? > За несколько миллисекунд на современном процессоре. Зачет!!! :-D У меня вопросов больше нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #73

70. Сообщение от yk4ever (?), 01-Дек-10, 19:01	+/–
>> contains - поточный > То есть известные с 60-х алгоритмы Боера-Мура или > Кнута-Мориса-Пратта не говорят совсем ни о чем? Кнут-Моррис-Пратт и Бойер-Мур практически поточные. Никто не мешает реализовывать jump table в терминах байтов UTF-8. Это не говоря уже о том, что для UTF-8 можно тупо использовать побайтовый поиск. >> рекэкспы - поточные > Вы представляете себе как устроены регекспы внутри? Да, это конечный автомат. Конечные автоматы работают поточно. > Соответственно, строя, которая match-ится должна быть преобразована в нормальные символы. Строка - нет. Всего лишь каждый символ. >> Не нужен random access строкам, не нужен. > Это utf-8 не нужен, а random access для строк нужен. Не убедили. Примеры ваши разваливаются от любого чиха. Можете попробовать ещё ножкой топнуть. > Вообще-то по алгоритмам для работы со строками пишутся толстенные книги. Ну почитайте их и убедитесь, что произвольный доступ там не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

71. Сообщение от yk4ever (?), 01-Дек-10, 19:03	+1 +/–
> Это во-первых, а во-вторых у них с UCS4 все вроде красиво, пока > не... > http://en.wikipedia.org/wiki/Unicode_equivalence > Но ведь для них все это слишком сложно? ;) Ещё про byte order забыли. И про non-zero-byte-safe окружения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

73. Сообщение от yk4ever (?), 01-Дек-10, 19:09	+/–
>> Очень типовая задача. > Извлечение подстроки в строке -- типовая задача. Нет, не типовая. Это подзадача парсинга строки. Если у вас для парсинга есть более подходящие средства (split, регэкспы и т.п.) - то вам произвольный слайс не нужен. > 999000 -- это специально для тех, > кто не знаком с элементарными основами типа O(). Нет. 999000 - это специально для тех, кто придумывает синтетические тесты. В нормальных программах никаких констант "999000" не бывает. Там бывает индекс, полученный путём того или иного анализа строки. Вот этот анализ и должен возвращать подстроку вместо индекса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #79

74. Сообщение от vle (ok), 01-Дек-10, 19:18	+/–
> Тут такое дело, > <...> > Substring search is just byte string search. Принято. > Однако, вместе с тем > UTF-8 does give up the ability to do random access using code > point indices. Programs that need to jump to the nth Unicode > code point in a file or on a line—text editors are > the canonical example—will typically convert > incoming UTF-8 to an internal representation > like an array of code points Я и говорю, примерно так, если мне не изменяет память, и сделано в Pike -- конвертация во "внутреннее 32-битное представление". Удовольствие сомнительное. И по времени, и по дополнительному расходу памяти. > but most programs are simpler when written to > manipulate UTF-8 directly. Вранье. В Жабе символы фиксированной длины. За 15 лет никто не умер. И если она тормозная и жрущая память, то совсем не по этой причине. Строки, занимающие много места в памяти -- миф, достаточно посмотреть бенчмарки ЯП по этому параметру, типа shootout. Разница в расходе памяти достигает сотен раз!. Поэтому utf-8 в этом месте -- откровенная ошибка дизайна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #77, #94

75. Сообщение от gegMOPO4 (ok), 01-Дек-10, 19:20	+1 +/–
Они объясняют, почему так, и эти доводы разумны. 1) Большинство внешних текстовых данных -- или UTF-8, или ASCII (подмножество UTF-8). Тратиться на перекодировку при вводе/выводе жалко. 2) Большинство простых операций со строками (итерация, поиск символа или подстроки, разбивка, определение класса символа в ASCII) прекрасно работают с UTF-8, и даже проще и быстрее, чем с UTF-32 (достаточно таблицы 2^8 для классификации и преобразования регистра в ASCII). 3) Большинство сложных операций со строками (сортировка, переносы, изменение регистра в странных алфавитах) всё равно требуют учёта национальной специфики (локали), это очень сложная и дорогая задача, накладные расходы на раскодирование UTF-8 на этом фоне мизерны. И в UTF-32 не будет проще, всё равно нужно учитывать комбинированные символы и т.п. Это если делать на совесть. Иначе см. п. 2. 4) Если так уж нужно работать с UTF-32 -- пожалуйста, распакуйте в vec[char] (char 32-разрядный), потом запакуете. Накладные расходы те же, что и неявные при языковых строках в UTF-32, только вы их контролируете. 5) Аналогично, если нужно работать без перекодировки с внешними данными в другой кодировке -- вектор октетов и никаких накладных расходов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #85

76. Сообщение от gegMOPO4 (ok), 01-Дек-10, 19:26	+1 +/–
С чего бы вам понадобилось выделить, начиная с 999000-ого символа? Откуда вы взяли это число? Нашли что-нибудь там? Тогда у вас есть смещение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

77. Сообщение от yk4ever (?), 01-Дек-10, 19:28	+/–
> И если она тормозная и жрущая память, то совсем не по этой причине. И по этой в том числе. Там же рефлексия есть. Все имена объектов и методов плавают в памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #86

78. Сообщение от gegMOPO4 (ok), 01-Дек-10, 19:28	+/–
Недавно? В 2009-м году.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #90

79. Сообщение от vle (ok), 01-Дек-10, 19:29	+/–
> В нормальных программах никаких констант "999000" > не бывает. Там бывает индекс, полученный > путём того или иного анализа строки. Вот этот анализ и должен > возвращать подстроку вместо индекса. То есть уже на уровне языка программирования мне навязывают две лишние не нужные мне сущности: смещение в байтах и длина в байтах вместо того чтобы использовать две уже имеющиеся: смещение в символах и длина в символах. И эти две лишние сущности будут таскаться не по системным внутренним библиотекам, а по моему приложению, которое со строками работает, а не копирует их туда сюда. Нет уж, спасибо, я лучше выкину этот "новый и современный" язык уже по этому критерию. Я готов терпеть этот бред в старых ЯП, но никак не в тех, которые претендуют на новизну и современность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #80

80. Сообщение от yk4ever (?), 01-Дек-10, 19:33	+/–
>> В нормальных программах никаких констант "999000" >> не бывает. Там бывает индекс, полученный >> путём того или иного анализа строки. Вот этот анализ и должен >> возвращать подстроку вместо индекса. > То есть уже на уровне языка программирования мне навязывают две лишние > не нужные мне сущности: смещение в байтах и длина в байтах вместо > того чтобы использовать две уже имеющиеся: смещение в символах и длина > в символах. Нет, вы не поняли. Это в примитивных языках вам навязана лишняя сущность: смещение в символах. Вам не нужно смещение в символах. Вам нужно обработать строку. Если вы при этом возитесь сами со смещениями в символах - значит у вас плохие строковые библиотеки. Ровно так же и со смещением в байтах вы возиться не должны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #82

81. Сообщение от gegMOPO4 (ok), 01-Дек-10, 19:43	+/–
На первый взгляд язык кажется перегруженным фичами. Так и есть, авторы сами признают, что сейчас обеспокоены удалением и стабилизацией фич, а не добавлением новых. Но вроде бы какая-то система в этих фичах есть, и синтаксис отвращения не вызывает. Многие замечают сходство с Go. Оно не случайно, автор впечатлился более ранними языками Пайка. Но Rust появился на несколько лет раньше Go. Темпы развития, конечно, удручают, даже самокомпилятор пока не написан. Это скорее инкубатор для идей, чем реальный инструмент. Но может ещё при поддержке Мозиллы и раскрутят. Желаю удачи.
Ответить | Правка | Наверх | Cообщить модератору

82. Сообщение от vle (ok), 01-Дек-10, 19:49	+/–
>[оверквотинг удален] >>> путём того или иного анализа строки. Вот этот анализ и должен >>> возвращать подстроку вместо индекса. >> То есть уже на уровне языка программирования мне навязывают две лишние >> не нужные мне сущности: смещение в байтах и длина в байтах вместо >> того чтобы использовать две уже имеющиеся: смещение в символах и длина >> в символах. > Нет, вы не поняли. Это в примитивных языках вам навязана лишняя сущность: > смещение в символах. Вам не нужно смещение в символах. Вам нужно > обработать строку. Если вы при этом возитесь сами со смещениями в > символах - значит у вас плохие строковые библиотеки. Все я прекрасно понял. Со строками Вы не работаете. С ними работаю как раз я. И штатные библиотеки типа регекспов и прочих метчеров, сплиттеров и копировщиков мои задачи не решают. Именно я пишу библиотеки и программы для работы со строками, поэтому именно мне навязываются две лишние сущности, прикрывая bad design мифической экономией памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #84, #87

83. Сообщение от gegMOPO4 (ok), 01-Дек-10, 19:56	+/–
vec[char] (char -- 32-битный). А для сложных программ, работающих с текстом, будет не только сам текст, но и деревья, аттрибуты...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

84. Сообщение от gegMOPO4 (ok), 01-Дек-10, 19:58	+/–
Какие ваши задачи?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

85. Сообщение от vle (ok), 01-Дек-10, 20:03	+/–
> Они объясняют, почему так, и эти доводы разумны. > 1) Большинство внешних текстовых данных -- или UTF-8, или ASCII (подмножество UTF-8). > Тратиться на перекодировку при вводе/выводе жалко. Тратить время на перекодировку при вводе и выводе как раз совершенно не жалко. Это делается один раз. А вот времени на перекодировки по требованию происходят несоизмеримо большее число раз во время выполнения приложения. Например, при сопоставлении с теми же регекспами. Лишний расход на пустом месте. > 2) Большинство простых операций со строками > (итерация, поиск символа или подстроки, разбивка, > определение класса символа в ASCII) прекрасно работают с UTF-8, и даже > проще и быстрее, чем с UTF-32 (достаточно таблицы 2^8 для классификации > и преобразования регистра в ASCII). Точно так же, прекрасно все работает и для строк, представленных в виде wide символов. Не вижу никаких выгод. > 3) Большинство сложных операций со строками (сортировка, переносы, изменение регистра > в странных алфавитах) всё равно требуют учёта национальной специфики (локали), это > очень сложная и дорогая задача, накладные расходы на раскодирование UTF-8 на > этом фоне мизерны. И в UTF-32 не будет проще, всё равно > нужно учитывать комбинированные символы и т.п. Это если делать на совесть. > Иначе см. п. 2. И здесь мы опять получаем необходимость перекодировку по требованию, теряя драгоценое время, которое так экономили в п.1. > 4) Если так уж нужно работать с UTF-32 -- пожалуйста, распакуйте в > vec[char] (char 32-разрядный), потом запакуете. Накладные расходы те же, что и > неявные при языковых строках в UTF-32, только вы их контролируете. А заодно перепишите все уже имеющиеся системные и сторонние библиотеки. > 5) Аналогично, если нужно работать без перекодировки с внешними данными в другой > кодировке -- вектор октетов и никаких накладных расходов. Накладных расходов на память нет. Это миф. Несоизмеримо больше занимает то, что никак не связано со строками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #88, #93

86. Сообщение от VoDA (ok), 01-Дек-10, 20:23	+/–
А как связана рефлексия и потребление памяти? Или рефлексия и потребление CPU? Обычные приложение строятся без рефлексии. Или в случае необходимости подстройки в рантайме под класс - рефлексируется одиножды. Имена объектов и методов плавают в памяти только для случая рефлексии. При статической компиляции в byte-code обращение ищет напрямую в вызовы byte-code функций. По сути это assembler только объектный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #89

87. Сообщение от yk4ever (?), 01-Дек-10, 21:10	+/–
> Именно я пишу библиотеки и программы для работы со строками, Может скажете название компании и продукта? Чтоб я ненароком не воспользовался. А то с вашей глубиной понимания алгоритмов и типовых задач...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

88. Сообщение от yk4ever (?), 01-Дек-10, 21:14	+1 +/–
> Например, при сопоставлении с теми же регекспами. Лишний расход на пустом месте. Мы уже вроде выяснили, что для регэкспов не нужно перекодировать строку? > Накладных расходов на память нет. Это миф. Да, да, и системная шина тоже миф. Всё уже прямо в регистрах процессора сразу сидит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

89. Сообщение от yk4ever (?), 01-Дек-10, 21:17	+/–
> А как связана рефлексия и потребление памяти? Напрямую. Все данные для рефлексии обязаны валяться в куче рантайма. Потому что нельзя ведь заранее узнать, будет кто рефлектить наш объект или нет. > Имена объектов и методов плавают в памяти только для случая рефлексии. При > статической компиляции в byte-code обращение ищет напрямую в вызовы byte-code функций. Дык байт-код то в себе тоже содержит все данные для рефлексии. И он будет загружен в память.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

90. Сообщение от Erley (ok), 01-Дек-10, 21:19	+/–
я имел ввиду вот это: http://www.opennet.dev/opennews/art.shtml?num=28710 т.е. они заработали 104 миллиона и вот сейчас не знают куда их девать :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #97

91. Сообщение от p (?), 01-Дек-10, 21:26	+1 +/–
> языка: C, Rust, BitC. Два последних ещё в колыбели. D для Ada :p
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #92

92. Сообщение от sku (ok), 01-Дек-10, 22:14	+1 +/–
>> языка: C, Rust, BitC. Два последних ещё в колыбели. D для > Ada :p Замечательная штука, спасибо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

93. Сообщение от gegMOPO4 (ok), 01-Дек-10, 22:28	+/–
> Тратить время на перекодировку при вводе и выводе как раз совершенно не > жалко. > Это делается один раз. Два раза. На каждый обработанный байт. При вводе и выводе. И много раз, если нужно одни и те же данные выдавать по запросу много раз. Мелочь, но зачем делать лишнюю работу? > А вот времени на перекодировки по требованию > происходят несоизмеримо большее число раз во время выполнения приложения. > Например, при сопоставлении с теми же регекспами. Не надо. Регэкспы, рассчитанные на UTF-8 работают с тем же успехом, что и рассчитанные на UTF-32. Даже лучше, потому, что байтов нужно вчетверо меньше прогнать. И проверки проще. > Точно так же, прекрасно все работает и для строк, представленных > в виде wide символов. Не вижу никаких выгод. Это о том, что у UTF-32 нет выгод перед ASCII/UTF-8. А вот недостатки есть. Поиск цифры [0-9] или начала идентификатора [A-Za-z_] в ASCII -- всего лишь одна табличка, для UTF-32 же будет как минимум к этому ещё проверка/ветвление (десятки процентов к производительности). Для не-ASCII будет в обоих случаях сложно, но в UTF-8 всё же типичные данные будут короче. > И здесь мы опять получаем необходимость перекодировку по требованию, теряя драгоценое время, > которое так экономили в п.1. Так и в UTF-32 перекодировка нужна. Для всяких там комбинированных символов. Не говоря уж о том, что распаковка из UTF-8 -- это 1-3 ветвления, а дальше в подобных задачах этих ветвлений и обращений к таблицам будут десятки. > А заодно перепишите все уже имеющиеся системные и сторонние библиотеки. У вас системные и сторонние библиотеки на UTF-8 или на UTF-32 рассчитаны? Подозреваю, что на первое чаще. А ещё есть UTF-16. Перекодировать всё равно иногда придётся, так лучше уж делать это реже. > Накладных расходов на память нет. Это миф. > Несоизмеримо больше занимает то, что никак не связано со строками. Тут скорее не на память, а на перекодировку. Если нужно найти в файле "\nFrom ", то в любом случае вы работаете с неперекодированными байтами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #100

94. Сообщение от gegMOPO4 (ok), 01-Дек-10, 22:33	+/–
> Вранье. В Жабе символы фиксированной длины. За 15 лет никто не умер. Не подскажете ли размер символа в Жаве?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #98

95. Сообщение от anonymous vulgaris (?), 01-Дек-10, 22:42	+/–
>>Вспомните, сколько бабла было ухнуто в визуал-бейсик и делфи. И где теперь эти языки? А что много? За Васик не скажу, но Дельфя у Борланда/Кодгера всегда была на вторых ролях (kylix вон вовсе сделали и сразу забросили), а потом они ее и совсем продали. И при этом получила большее распространение (и продолжает иметь, особенно в Европе). И причины понятна - оба языка всяко лучше всевозможных вариантов и недопилов/перепилов Си (включая и жабу понятно) + IDE у них из коробки и все работает. > Дельфи - это не язык а среда разработки Они его типа переименовали ( http://ru.wikipedia.org/wiki/Delphi_(язык_программирования) ). Так что object pascal теперь остался у free pascal/lazarus, а у embarcadero со вчерашнего дня delphi language. Наука маркетология панимаэшь. >а паскаль себя нормально  чувствует в академической среде. И не в академической тож, в энтерпрайзе делфи полно, причем часто еще версии 7. ManagementPlus Healthcare Information Systems A managed healthcare provider takes advantage of advanced Delphi features to implement a flexible, modular architecture to respond quickly to new customer requirements and improve customer satisfaction. http://www.embarcadero.com/images/dm/customers/managementplu... Euclid Technology By building ClearVantage Euclid's integrated CRM, ERP, eCommerce and Web Content management, on Delphi, they became the first in industry to run on Vista and XP and compete successfully with companies with 10x larger development teams. http://www.embarcadero.com/images/dm/customers/euclid-delphi... Да и к free pascal/lazarus коммерсанты присматриваются очень даже, особенно из-за кроссплатформенности. Вот эту фигню разрабатывает и использует у себя вполне коммерческая фирма http://crossfpc.untergrund.net/ Welcome to CrossFPC, a free toolkit to integrate the FreePascal compiler, targetting various OS and hardware platforms, into the Borland® Delphi® IDE. В общем хорошие языки вполне себе живут наряду с отвратительными. А что более распространено всякое гумно, так ведь широкие массы завсегда его и хавают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

96. Сообщение от gegMOPO4 (ok), 01-Дек-10, 22:43	+/–
> Судя по всему Immutable объектов дает возможность функционального программирования. Или > ФП возможен только при Immutable объектах. Помимо этого, для неизменяемых объектов вместо хитрого сборщика мусора с разрешением циклических ссылок можно применять просто подсчёт ссылок -- а значит время уничтожения детерминировано, отсюда возможность деструкторов и RAII. А важность последнего постепенно начали понимать и за пределами C++. И это радует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

97. Сообщение от gegMOPO4 (ok), 01-Дек-10, 22:45	+/–
Сомневаюсь, что на Rust пойдёт хотя бы 1% от этой суммы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

98. Сообщение от yk4ever (?), 01-Дек-10, 22:57	+/–
>> Вранье. В Жабе символы фиксированной длины. За 15 лет никто не умер. > Не подскажете ли размер символа в Жаве? Увы, в данном случае товарищ прав. Жабовский char - всегда ровно два байта. Поддержка верхних плоскостей юникода там довольно унылая - не уверен даже, что регулярки нормально работают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

99. Сообщение от emg81 (?), 01-Дек-10, 23:25	+/–
спасибо :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

100. Сообщение от vle (ok), 02-Дек-10, 00:21	+1 +/–
>> Тратить время на перекодировку при вводе и выводе как раз совершенно не >> жалко. >> Это делается один раз. > Два раза. На каждый обработанный байт. При вводе и выводе. И много > раз, если нужно одни и те же данные выдавать по запросу > много раз. Мелочь, но зачем делать лишнюю работу? Однократный ввод и вывод -- абсолютная мелочь, на которую даже не стоит обращать внимания. >> А вот времени на перекодировки по требованию >> происходят несоизмеримо большее число раз во время выполнения приложения. >> Например, при сопоставлении с теми же регекспами. > Не надо. Регэкспы, рассчитанные на UTF-8 работают с тем же успехом, что > и рассчитанные на UTF-32. Даже лучше, потому, что байтов нужно вчетверо > меньше прогнать. И проверки проще. Нет. Регекспы, расчитанные на ucs4 работают лучше, потому что автомат получается меньше, в нем меньше переходов, кроме того, он легче минимизируется, больше возможностей, к примеру, двумя числами представить [from..to], больше шансов "склеить" входные веса переходов и т.п., соответственно автомат меньше занимает места в памяти и быстрее работает. Выигрыш значительный и по скорости и по памяти. Поэтому вход нужно каждый раз перекодировать из utf-8 в ucs4 и обратно, если в качестве внутреннего представления строк выбран utf-8. Простейший пример: (латинское_А|русское_А|японский_иерогриф). В случае utf-8 он будет иметь 6 переходов и 7 состояний. В случае ucs4 -- два перехода (или вообще 1, если использовать мепку входных весов) и два стостояния. Ну а в случае использования character classes разница будет просто невероятная. Один переход + map в случае ucs4 против я даже не знаю скольки переходов в случае utf8. >> Точно так же, прекрасно все работает и для строк, представленных >> в виде wide символов. Не вижу никаких выгод. > Это о том, что у UTF-32 нет выгод перед ASCII/UTF-8. А вот > недостатки есть. Поиск цифры [0-9] или начала идентификатора [A-Za-z_] в ASCII > -- всего лишь одна табличка, И в ucs4 одна табличка, малюсенькая, с указанием ее минимального и максимального индекса. Если проблема и есть, то явно не в том месте. >> И здесь мы опять получаем необходимость перекодировку по требованию, теряя драгоценое время, >> которое так экономили в п.1. >> А заодно перепишите все уже имеющиеся системные и сторонние библиотеки. > У вас системные и сторонние библиотеки на UTF-8 или на UTF-32 рассчитаны? > Подозреваю, что на первое чаще. А ещё есть UTF-16. Перекодировать всё > равно иногда придётся, так лучше уж делать это реже. У нас системная библиотека имеет char и wchar_t-based API, причем первая реализована через вторую. Поэтому да, перекодировать желательно как можно реже, а не туда и потом еще и обратно ;-) >> Накладных расходов на память нет. Это миф. >> Несоизмеримо больше занимает то, что никак не связано со строками. > Тут скорее не на память, а на перекодировку. Если нужно найти в > файле "\nFrom ", то в любом случае вы работаете с неперекодированными > байтами. В этом конкретном случае при использовании ASCII-совместимой кодировки для ввода-вывода перекодировка заключается лишь в том, чтобы переложить char в int. Пользователи Shift-JIS и им подобных сами себе буратины.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

101. Сообщение от VoDA (ok), 02-Дек-10, 00:29	+/–
Сколько вам приходилось делать подобного рода действия. И чтобы не над целой строкой, а только частью. У меня в практике или строка используется как есть ИЛИ парсится вся целиком и дальше разделяется на подстроки, преобразуется в числа и т.п. Потому и вызывает удивление. Это примерно так же как переопределение операторов для Объектов - вроде операция интересная, но нужная только в математике. А если математика идет над большими множествами, то порождать объекты - просадка производительности. Потому вроде переопределение и интересно, но в java ее забанили. И вряд ли когда нибудь сделают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

102. Сообщение от Аноним (-), 02-Дек-10, 11:35	+/–
Чем им http://cobra-language.com/ не подошел? Написали бы компилятор компилятор для реального железа и в бой!
Ответить | Правка | Наверх | Cообщить модератору

103. Сообщение от botman (ok), 02-Дек-10, 19:57	+/–
http://en.literateprograms.org/Category:Environment:Portable Пока этот "язычёк" не появится на подобных вышеприведённому ресурсах - он будет бесполезным языком. Согласен, пока что у Lua и Erlang больше шансов быть хотя-бы академическим языком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

104. Сообщение от Андрей (??), 02-Дек-10, 21:11	+/–
Паскаль давно умер, кроме стран СНГ, где им ещё продолжают мучить подрастающее поколение из-за нежелания самим переучиваться и что-то менять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

105. Сообщение от StrangeAttractor (ok), 08-Дек-10, 04:15	+/–
> это выглядит как "ни один существующий дистрибутив Linux меня не удовлетворил, и я решил сделать пятьсот первый" И что в этом плохого? Imho вполне логично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

106. Сообщение от Аноним (-), 06-Июл-11, 20:25	+/–
Язык программрования Rust с нуля [под Ubuntu x86]: http://www.drevlyanin.ru/post/7305354988/getting-started-wit...
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема