Здравствуйте, okman, Вы писали:
O>Здравствуйте, jazzer. O>Вы как-то очень уж серъезно решили "не обойти стороной" мое сообщение.
А почему я должен к вашим сообщениям относиться несерьезно?
O>В любом языке, как и в человеке, можно найти кучу недостатков, и при этом спокойно с ним жить.
С этим никто не спорит.
O>>>Отсутствие двоичного стандарта. J>>Посмотрел бы я на этот стандарт, который бы удовлетворил и 64-битовым билдам, и 8-битным микроконтроллерам
O>А мне бы хватило стандарта для одной определенной платформы (Windows) — схема расширения имен, O>объектные файлы, передача объектов/исключений между модулями и тому подобное. O>Чтобы можно было гарантировать совместимость интерфейсов C++ между теми же dll, собранными O>разными компиляторами. Может быть, в таких громадинах как COM тогда и не было бы необходимости.
Ну, вам бы на Windows хватило, а что насчет всех остальных? Речь же о языке. Никто не мешает компиляторостроителям договориться, как реализовать совместимость в рамках конкретной платформы. Было бы желание. А вот его, как показывают заседания комитета, как рих и нет. С другой стороны, есть же усилия на ABI типа Itanium, DWARF и т.д. — может, оно понемножку и выстаканится. Но это в любом случае не проблема языка, именно из-за его огромной кроссплатформенности.
O>>>Зоопарк библиотек, из которых трудно выбрать ту самую единственную, которая на всю жизнь. J>>Ну вот была MFC "на всю жизнь" — и как?
O>Вот и я о том же — MFC даже не является частью языка, подобно STL.
А была бы — было бы хорошо? А что делать нам на Motif, маководам на Cocoa и прочим на gnome/KDE/whatever?
Там архитектура и подходы в принципе разные, не просто названия классов-методов.
В винде — сообщения и одна оконная функция.
В иксах — индивидуальный колбэк на каждое сообщение, с контекстной информацией.
O>А если сесть и перечислить все либы, с которыми приходилось работать, получится весьма немалый список. O>Причем каждая из них реализует какую-то особую концепцию, каждую нужно понять и осилить, хотя бы O>на уровне прототипов. Куда эта дорога ведет ? Почему в новом стандарте нет либы для работы с XML, O>ведь он используется повсеместно ?
Потому что XML огромен сам по себе, плюс он же не в вакууме, с ним вместе должны идти XSLT, XPath, схемы и прочая. А если мы хотим все это сделать частью языка — создание и поддержка всего этого дела ложится на производителей компиляторов.
O>Но почему-то в том же .NET принято именовать сущности более-менее единообразно (видел в нескольких O>проектах), а в коде на C++ постоянно приходится видеть нечто в таком стиле:
Наверное, потому что развивалось все очень быстро быстро, все книжки писались в деином стиле и на базе огромной библиотеки сформировалась некая "экосистема". Такое под силу только корпорациям за деньги. В остальном же — вот был Си и С++: в обеих основополагающих книжках используется нотация с подчеркиваниями и маленькими буквами. С какого бодуна та же MFC написана мелкософтом с верблюжьей нотацией? Для единообразия с WinAPI? А там почему так? Чтоб символы в объектниках были покороче? В общем, большие игроки, которые и должны задавать тон, действуют вразнобой. В случае же C#/Java большой игрок ровно один, а остальные просто принимают правила игры.
O>(На мой вкус. Кому-то не понравится, но по крайней мере выполнено в едином стиле).
Кто ж спорит. Ну вот в бусте приняты правила именования, например, там все единообразно.
O>>>Наплодили меташаблоны с концептами, списками типов и кортежами, вместо того, чтобы вызвать O>>>add_ref, поставить блокировку и вернуть shared_ptr. J>>не понял, какая связь?
O>Я к тому, что некоторые существующие концепции программирования в C++ эволюционировали в нечто O>настолько сложное и запредельное для понимания обычными людьми, что сильно потеряли, на мой взгляд, O>в практическом отношении. Особенно в коллективной разработке, когда квалификация программистов O>может значительно отличаться. Мне нравится, когда шаблоны используются как в STL или бустовских O>смартпоинтерах, или как обертки для COM-интерфейсов в ATL, но когда из них делают что-то, O>понятное лишь гуру метапрограммирования — это перебор.
Все гуру-фичи нужны только разработчикам библиотек, по большому счету. Для нормальных прикладников все остается на простом уровне либо становится еще проще, типа того же цикла foreach, универсального синтаксиса инициализации, auto для автоматического выведения типа... Это все облегчает жизнь именно "простым" программистам.
O>>>Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64. J>>Вообще-то возможность заточки под платформу — это фича языка
O>Если заточек становится слишком много, значит язык не справляется со своей задачей.
Очень расплывчатый критерий, имхо. Что значит "слишком много"? Сколько их должно быть, учитывая огромное количество существующих архитектур? Более того, как без declspec ты сможешь обеспечить сопряжение своей программы с несколькими сишными, паскалевскими и фортрановскими библиотеками одновременно?
Здравствуйте, Курилка, Вы писали:
O>>>Отсутствие единого глобального соглашения о скобках, отступах и именах. J>>Это должно быть частью языка? Типа не правильный отступ или скобка не на той строчке — и код не должен компилироваться?
К>В качестве примеров "из другой песочницы" — Code Conventions for the Java Programming Language и Style Guide for Python Code.
Я тебе и на Си с десяток таких насобираю.
Это часть языка? Нет.
Код, не соответствующий этим соглашениям в "других песочницах", отвергается компиляторами? Нет.
Вот в хаскеле это часть языка — типы всегда с большой буквы. А то, что ты показываешь — это просто рекомендации, их в любом языке навалом. Что их делает выделенными? То, что их написали создатели языков? Ну так на Си и С++ есть книжки от создателей языков (написанные в практически одинаковом стиле, кстати) — кто мешал пользоваться их стандартами? В юниксовом мире в основном и пользуются, кстати, хотя графика что в X Window, что в WinAPI, написала в совершенно других соглашениях. Почему? Зачем нарушили сложившийся стиль стандартных сишной и плюсовой библиотек и книг? Кто знает. Может, экономили таблицу символов в объектниках
Здравствуйте, Lloyd, Вы писали:
L>Я привел пример с выбором между var и явной декларацией типа.
OK, давай разберем этот пример.
Итак на входе мы имеем язык в котором определение неизменяемой переменной имеет синтаксис (упрощенно):
def varName = expression;
а изменяемой
mutable varName = expression;
Все кто получает компилятор в свое распоряжение имеют именно такой синтаксис. Никто из них не может переопределить его так, чтобы кто-то другой был вынужден использовать отличный синтаксис.
Теперь кто-то захотел использовать в своих программах синтаксис:
И спокойно пользуется новым синтаксисом в программе.
Может ли он как-то перенести свой новый синтаксис в основной язык? Очевидно — нет.
Что же он может сделать? Он может предложить свое решение разработчикам языка. Для этого достаточно создать сообщение на одном из форумов которые они читают и приложить к сообщению свой чудо-макрос вводящий этот синтаксис.
Разработчики выслушают товарища предлагающего расширение и обдумают нужно ли такое расширение вообще и если нужно, то стоит ли поместить его в стандартную библиотеку макросов, или в отдельную библиотеку (чтобы им могли пользоваться те кто захочет, но чтобы он не был доступен по умолчанию).
Как разработчик языка я сразу скажу, что данный макрос будет завернут. В синтаксисе уже есть аналог и ничего кроме двух способов написать одно и то же новый макрос не привнесет.
В итоге данный макрос не попадет в стандартную библиотеку, но пользователь сможет использовать свой макрос и передавать его другим людям которые выразят желание его использовать. Все что нужно для того чтобы использовать в проекте этот макрос — это приложить к проекту соответствующую ДЛЛ. Если его проекты попадут в чужие руки, они будут прекрасно работать, так как ДЛЛ будет в их составе.
L>Хотя я уже знаю ответ. Вы просто опять съедете на то, что нет такой проблемы.
Ну, дак это потому что так оно и есть. Ты выдумал себе проблемы и теперь пытаешься доблестно с ними сражаться.
При этом ты выдаешь дичайшие алогизмы которые раздражают окружающих.
L>Собственно, как было с ненужностью "отладки" макросов, когда ты на публике с пеной у рта уверял, что средств получения кода, сгенерированного макросом нет за ненадобностью, а в личной переписке, надев маску "ты кого угодно достанешь", признал, что средства-таки есть.
Это уже какой-то совсем другой вопрос... видимо. Я не знаю что ты вкладываешь в понятие "отладки" (в кавычках). Средства отладки макросов несомненно есть и я никогда не говорил об их ненужности (особенно с пеной у рта). Так что ты просто в очередной раз лжешь.
Ну, да попытка подменить тему уже сама по себе свидетельствует о сливе и попытке перевести разговор в демагогическую форму. Если эта попытка неосознанная, предлагаю ее остановить.
VD>>Случаев использования полно.
L>Опять как и год назад сошлешься на компилятор?
Сошлюсь на гугль. Делать тебе на каждый чих подборку не собираюсь. Если бы ты постоянно читал форум Немерла, то заметил бы, что там эта тема поднималась не однократно и не однократно же приводились примеры.
Многие из примеров использования находятся в каталоге snippets. Там есть и просто примеры, но зачастую это части реальных проектов или просто реальные проекты. Например, вот это часть какой-то внутренней системы в Билайне (если не ошибаюсь), а это код текущей версии форматера статей для РСДН.
VD>>Но ты от вопроса то не уходит.
L>А это и не уход от вопроса. Собеседник в качестве аргумента сослался на практику, вот пусть и уточнит, что за практику он имеет в виду.
Собеседник тебе русским языком четко и доходчиво объяснил прицип того почему не возникает проблем. Ты же начал молоть чепуху на что он тебе и сказал, что это домыслы которые на практике не существуют. В принципе он мог и не говорить про практику, так как твои слова являются домыслами, а стало быть опровергать их не имеет смысла.
Докажи наличие проблемы, а потом будет что-то обсуждать. Сейчас же ты пытаешься навязать обсуждение отсутствующей проблемы. А это очень трудно делать корректно.
VD>>А то у тебя и так логиках хромает как у блондинки. Сосредоточься на одной проблеме. Так будет проще не ошибиться.
L>Ты как всегда очень конструктивен. Фразы "алогичность мышления", "повторяешь глупость", "ранимая душа", "логиках хромает как у блондинки" очень настраивают на конструктивный разговор.
Да я конструктивен. Если я вижу проблему в чей-то логике, и вижу (в добавок) что человек, чья логика хромает на обе ноги, в добавок начинает перескакивать с темы на тему, то я и говорю об этом. Уж извини.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
6. Рефлексия. Сейчас своей у скалы нет, используется жавовская. Не умеет как минимум одну очень важную вещь: вызывать методы (включая конструкторы), задавая значения параметров по имени параметра (не позиционно "p1: Any, p2: Any", а "Map(pName: String, pValue: Any)"). Из-за этого тот же squeryl при материализации создаёт экземпляр entity-класса (реализованного как immutable case class) с помощью дефолтного конструктора (каковой требуется объявлять во всех entity-классах), а после инжектит значения полей. Из-за этого невозможно сделать такую полезную вещь, как проверку инвариантов в теле класса (т.е. в теле основного конструктора).
Здравствуйте, Курилка, Вы писали:
К>А покажи неривиальную валидаци, не вписывающуюся в JSR-303?
А в Spring MVC можно к параметру контроллера страницы (т.е. к GET-параметру HTTP-запроса) прикрутить этот самый JSR303-валидатор, и спринг его зацепит? Если да, тогда данная претензия снимается.
Здравствуйте, jazzer, Вы писали:
J>А почему я должен к вашим сообщениям относиться несерьезно?
Это был мой ответ на вопрос что мне не нравится в языке.
Мне показалось, что Вы пытаетесь меня в чем-то разубедить. Нет ?
В общем-то, я соглашусь почти со всем, что Вы написали, но ведь
проблемы от этого не исчезнут.
Здравствуйте, Kir., Вы писали:
K> def run(self): K> while True: K> numpy.sin(self.ws)
Ага. И вот тут оно в нативной функции и считает параллельно. Заменим на простой while True: pass и получим один процессор.
Здравствуйте, neFormal, Вы писали:
F>>>и выглядит оно вполне логично.. Z>> можно посмотреть на эту логику?
F>ну если сложные типы передаются по ссылке и сигнатура метода создаётся лишь однажды при объявлении/импорте, то логично, что список создаётся на момент объявления функции и живёт там продолжительное время..
Это причина, а не логика. Логика подсказывает, что следующие вызовы должны быть эквивалентны, но это не так:
Здравствуйте, Don Reba, Вы писали:
DR>.NET вообще плохая платформа для вычислений, но в Немерле производительность сильно зависит ещё и от того, инлайнятся ли функции, оптимизируется ли хвостовая рекурсия, во что разворачивается использование туплов, и какой код генерируется макросами (особенно foreach). Чисто личный опыт.
Это в любом языке есть. Более того, если есть более одного компилятора, то у каждого могут быть свои особенности.
Я не понимаю где здесь именно непредсказуемость?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, jazzer, Вы писали:
J>>А почему я должен к вашим сообщениям относиться несерьезно?
O>Это был мой ответ на вопрос что мне не нравится в языке. O>Мне показалось, что Вы пытаетесь меня в чем-то разубедить. Нет ? O>В общем-то, я соглашусь почти со всем, что Вы написали, но ведь O>проблемы от этого не исчезнут.
Если вы согласны почти со всем, то это значит, что вы согласны, что почти все претензии не относятся к собственно языку.
Проблемы от этого не изчезнут, это да, но это проблемы не языка.
Я ведь не на всё возражал, что вы указали, а только на то, что к языку не относится.
Это значит, что всё остальное упомянутое я признаю за проблемы самого языка, типа отсутствия частичных специализаций функций и прочего.
Здравствуйте, Abyx, Вы писали:
F>>есть GIL => нет многопоточности.. A>никакой связи.
ты понимаешь вообще зачем нужен GIL?.
он нужен, чтобы данные объектов (__dict__) не разрушались при доступе из разных потоков.. поэтому и нужен глобальный лок..
A>всё прекрасно работает в разных потоках
это псевдопотоки.. потоки в одном системном потоке..
это быстрее, чем всё делать только на процессах, но медленнее, если бы были нормальные потоки..
...coding for chaos...
Re[25]: C#: const для переменных, pattern-matching, ...
Здравствуйте, VladD2, Вы писали:
L>>Я привел пример с выбором между var и явной декларацией типа.
VD>OK, давай разберем этот пример.
VD>Итак на входе мы имеем язык в котором определение неизменяемой переменной имеет синтаксис (упрощенно): VD>
VD>def varName = expression;
VD>
VD>а изменяемой VD>
VD>mutable varName = expression;
VD>
VD>Все кто получает компилятор в свое распоряжение имеют именно такой синтаксис. Никто из них не может переопределить его так, чтобы кто-то другой был вынужден использовать отличный синтаксис.
VD>Теперь кто-то захотел использовать в своих программах синтаксис: VD>
VD>var varName = expression;
VD>
VD>как замену синтаксиса с mutable.
VD>Он создает макрос: VD>
VD>И спокойно пользуется новым синтаксисом в программе.
VD>Может ли он как-то перенести свой новый синтаксис в основной язык? Очевидно — нет. VD>Что же он может сделать? Он может предложить свое решение разработчикам языка. Для этого достаточно создать сообщение на одном из форумов которые они читают и приложить к сообщению свой чудо-макрос вводящий этот синтаксис.
VD>Разработчики выслушают товарища предлагающего расширение и обдумают нужно ли такое расширение вообще и если нужно, то стоит ли поместить его в стандартную библиотеку макросов, или в отдельную библиотеку (чтобы им могли пользоваться те кто захочет, но чтобы он не был доступен по умолчанию).
VD>Как разработчик языка я сразу скажу, что данный макрос будет завернут. В синтаксисе уже есть аналог и ничего кроме двух способов написать одно и то же новый макрос не привнесет.
VD>В итоге данный макрос не попадет в стандартную библиотеку, но пользователь сможет использовать свой макрос и передавать его другим людям которые выразят желание его использовать. Все что нужно для того чтобы использовать в проекте этот макрос — это приложить к проекту соответствующую ДЛЛ. Если его проекты попадут в чужие руки, они будут прекрасно работать, так как ДЛЛ будет в их составе.
К чему все это? Я тебе специально вопрос выделил жирным. Выбор var/декларация типа — исключительно иллюстрация того, что изменение синтаксиса — не такая тривиальная задача. Дабы тема опять не съехала в сторону, повторюсь, что речь не о технической стороне дела, а о концептуальной.
L>>Хотя я уже знаю ответ. Вы просто опять съедете на то, что нет такой проблемы.
VD>Ну, дак это потому что так оно и есть. Ты выдумал себе проблемы и теперь пытаешься доблестно с ними сражаться.
Я вижу проблему в приведенном примере, я вижу на примерах nikov-а, что и в шарпе полно нелогичностей и неоднозначностей. Какие еще мне могуть понадобиться подтверждения того, что проблема реальна?
VD>При этом ты выдаешь дичайшие алогизмы которые раздражают окружающих.
Алогичность — это обвинять оппонента в алогичности, не приводя пример того, где именно была запечена алогичность.
L>>Собственно, как было с ненужностью "отладки" макросов, когда ты на публике с пеной у рта уверял, что средств получения кода, сгенерированного макросом нет за ненадобностью, а в личной переписке, надев маску "ты кого угодно достанешь", признал, что средства-таки есть.
VD>Это уже какой-то совсем другой вопрос... видимо. Я не знаю что ты вкладываешь в понятие "отладки" (в кавычках). Средства отладки макросов несомненно есть и я никогда не говорил об их ненужности (особенно с пеной у рта). Так что ты просто в очередной раз лжешь.
Доказательства моей "лжи" ты можешь увидеть в истории переписки в скайпе. К сожалению, я не могу ее процитировать, т.к. недавно переставлял систему.
VD>Ну, да попытка подменить тему уже сама по себе свидетельствует о сливе и попытке перевести разговор в демагогическую форму. Если эта попытка неосознанная, предлагаю ее остановить.
А вписываться в обсуждение с фразами "алогичность мышления", "повторяешь глупость", "ранимая душа", "логиках хромает как у блондинки" о чем должна была свидетельствовать? Так что для начала сам придерживайся общепринятых норм ведения дискуссий, а уж потом тыкай своих собеседников.
VD>>>Случаев использования полно.
L>>Опять как и год назад сошлешься на компилятор?
VD>Сошлюсь на гугль. Делать тебе на каждый чих подборку не собираюсь. Если бы ты постоянно читал форум Немерла, то заметил бы, что там эта тема поднималась не однократно и не однократно же приводились примеры. VD>Многие из примеров использования находятся в каталоге snippets. Там есть и просто примеры, но зачастую это части реальных проектов или просто реальные проекты. Например, вот это часть какой-то внутренней системы в Билайне (если не ошибаюсь), а это код текущей версии форматера статей для РСДН.
Спасибо.
VD>>>Но ты от вопроса то не уходит.
L>>А это и не уход от вопроса. Собеседник в качестве аргумента сослался на практику, вот пусть и уточнит, что за практику он имеет в виду.
VD>Собеседник тебе русским языком четко и доходчиво объяснил прицип того почему не возникает проблем. Ты же начал молоть чепуху на что он тебе и сказал, что это домыслы которые на практике не существуют. В принципе он мог и не говорить про практику,
Однозначно мог бы не говорить про нее, но если уж начал говорить, то неплохо бы уточнить, какую практику он имеет в виду.
VD>так как твои слова являются домыслами, а стало быть опровергать их не имеет смысла.
Я бы назвал их сомнениями.
VD>Докажи наличие проблемы, а потом будет что-то обсуждать. Сейчас же ты пытаешься навязать обсуждение отсутствующей проблемы. А это очень трудно делать корректно.
VD>>>А то у тебя и так логиках хромает как у блондинки. Сосредоточься на одной проблеме. Так будет проще не ошибиться.
L>>Ты как всегда очень конструктивен. Фразы "алогичность мышления", "повторяешь глупость", "ранимая душа", "логиках хромает как у блондинки" очень настраивают на конструктивный разговор.
VD>Да я конструктивен. Если я вижу проблему в чей-то логике, и вижу (в добавок) что человек, чья логика хромает на обе ноги, в добавок начинает перескакивать с темы на тему, то я и говорю об этом. Уж извини.
В начале темы я писал, к чему сведется эта "дискуссия". Собственно к тому она и скатилась.
Здравствуйте, neFormal, Вы писали:
F>это псевдопотоки.. потоки в одном системном потоке..
я не знаю, может вы говорите про какую-то одну версию питона для какой-то ОС,
но у меня на винде питон нормально работает в нескольких системных потоках, и использует системные потоки для своих потоков,
см. \Python\thread_nt.h
Здравствуйте, Abyx, Вы писали:
F>>это псевдопотоки.. потоки в одном системном потоке.. A>я не знаю, может вы говорите про какую-то одну версию питона для какой-то ОС, A>но у меня на винде питон нормально работает в нескольких системных потоках, и использует системные потоки для своих потоков, A>см. \Python\thread_nt.h
не, падажжи.. ты хочешь сказать, что у тебя питон без GIL-а?. и данные не разрушаются?.
дай погонять, а?.
ЗЫЖ можешь посмотреть на другие реализации питона, которые пытались обойтить эту проблему.. не просто же так шутки ради авторы CPython придумали несколько вывертов для обхода gil-а..
можно посмотреть на эту логику? 
