Здравствуйте, Laughing_Silencer, Вы писали:
L_S>Вот все говорят про правильный и неправильный дизайн забывая о том, что задача языка не быть красивым, а быть функциональным. Т.е. идея не в том, что бы писать абсолютно безопасные программы, а что бы писать нужные программы. Вообще я смотрю на разные языки и у всех свои недостатки, просто некоторые языки развиваются и со временем превращаются в фичепомойку, которую затем зачем то называют неправильным дизайном, а другие языки в свою очередь отстаивают определенные позиции и с академической точки зрения имеют мало недостатков, но не применяются ибо для того, что бы их применять на промышленном уровне нужны высококлассные специалисты и до кучи не все на них можно сделать. Примеры приводить не буду ибо начнется холи вар ИМХО всем не угодишь по части фич
Действительно, от языка требуется, чтобы он был решал свои задачи. И он их должен решать быстро и просто. А вот подход C++ мне напоминает человека, который, чтобы почесать нос, просовывает руку под ногу и весь изгибается. Вот как раз C++ напоминает фичепомойку. Причём это, как я уже сказал, является следствием того, что C++ даржится за прошлое (а что же ему ещё остаётся делать с таким громадным объёмом legacy-кода). В прошлом люби были наивнее и вносили не самые нужные фичи, или нужные, но не самым нужным образом.
K>>
K>>несмотря на всю кривизну такого подхода. L_S>Да что ты говоришь — ну ка расскажи ка мне про кривизну этого подхода ? В чем она ? В том, что есть другие способы что ли ? Единственный недостаток на мой личный взгляд это отрыв библиотеки от ее описания, а все остальное мелочи не заслуживающие внимания.
В том, что это очевидный костыль. Так пишут не от того, что жизнь хорошая, а от того, что никак иначе и сделать-то нельзя. Не говоря уж о тормозах компиляции. Или полной неспособности сделать поддержку такого в IDE. Вообще, подход с разделением на .h- и .cpp-файлы для описания модуля — штука весьма сомнительная. Она чревата дублированием кода (тратой времени) и полным отказом IDE поддерживать такое.
K>>Всё будущее, которое очевидно для C++ — уход в узкую нишу написания чего-то низкоуровневого. Причём, возможно, что его и оттуда вытеснит какой-нибудь язык, более специализированный, потому гораздо более удобный для решения конкретного круга задач. L_S>Ладно тебе — какая уж тут узкая ниша. Ну вот например для встроенных систем пока нету тенденций к переходу на другие языки, а это отнюдь не узкая ниша и деньги тут крутятся очень большие. Затем всяческая цифровая обработка, драйвера, коммуникационное ПО, анализаторы сигналов и т.п. Я бы сказал, что .Net займет свою узкую нишу для создания бизнес приложений и автоматизации нежели С++
Что-то такое низкоуровневое и производительное, но полностью избавленное от призраков прошлого, красиво и современно сдизайнено, с учётом того, что нужна поддержка IDE. Не знаю, появилось ли что-то такое, или только появится. Люди вот говорят о D, но я в нём пока не копался.
K>>В общем, если что-то не очевидно сейчас, то это не значит, что не назрели тенденции. Язык C++ сделал когда прорыв в мэйнстриме, многому нас научил, многое сделал. Но теперь он уже отжил своё. L_S>Просто ты наверное устал от С++ и тебе хочется чего то нового, но это не значит, что язык свое отжил.
Просто я поюзал более продвинутые языки, потому мне бросаются в глаза все минусы C++, и их куда больше, чем плюсов. Отбросить же минусы эволюционным путём не получится — они накапливались в течение многих лет. А вот если произвести над C++ революцию, то получим некоторый язык, который в кратчайшие сроки вытеснит C++.
Кстати, по поводу legacy-кода. Если эта проблема существует на десктопах, то это ведь не значит, что всё так плохо со всякими там КПК, телефонами и проч. Если там своеверменно отказаться от C++ в пользу гипотетического нового языка, то мы автоматически избавим будущее отрасли от всех проблем, что нажили десктопы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Как скрестить ужа и ежа или статическую и утиные тип
я думаю, что у человека еще просто не было возможности поработать на C++ в достаточной степени, над разными задачами и на разных платформах.
Хм... Мне не кажется, что поработай я над проектом на C++, я бы тут высказался даже более категорично. Тут опыт не имеет большого значения. Главное, трезво смотреть на вещи.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, eao197, Вы писали:
E>Аналогия: человеческий организм перестает расти к 23-27 годам, после чего начинаются необратимые обратные процессы, затягивающиеся у некоторых индивидов на 50 и более лет. Однако, мало кому приходит в голову обзывать живых людей, находящихся в зрелом возрасте, "трупами" просто на основании того, что их биологическое развитие завершено.
Судя по всему, C++ уже 90-летний старик. Его можно уважать, считаться с ним. Но ему осталось недолго. Пусть он уступит место молодым.
E>Теперь ближе к теме. Никто, вдумайтесь, никто не в стостоянии вообразить себе степень проникновения C++ в современный IT. Об этом неоднократно говорил Страуструп, а уж кому как не ему интересоваться судьбой языка и выслушивать пожелания от разных групп пользователей. Изъять C++ из современных систем невозможно, переписать все C++ программы на что-то другое -- невозможно. Просто представте себе: н-е-в-о-з-м-о-ж-н-о!
Нет ничего невозможного, бывает только архисложное. Изъять полностью (отнять и поделить, всех убить, одному остаться) никто не требует. Есть куча старого кода, который нужно сопровождать, это правильно. Но зачем стартовать новые проекты на C++ там, где можно обойтись другими средствами?
E>Даже если сейчас интерес к нему снижается и количество стартующих на нем проектов уменьшается, C++ обеспечена еще очень и очень долгая жизнь. Не верите -- посмотрите на COBOL.
COBOL лежит в мавзолее и на него приходят посмотреть местные некрофилы.
Мне кажется, мы просто по разному понимаем слово "умер". Вот я понимаю "ЯП жив" когда:
1. ЯП изменяется, развивается, чтобы быть современным, причём это у него получается без всяких костылей.
2. Количесво проектов, которые на нём целесообразно писать множится и множится.
Если ЯП не удовлетворяет этим требованиям — то "ЯП умер". Кстати, это верно только для мэйнстримовых языков.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>Даже если сейчас интерес к нему снижается и количество стартующих на нем проектов уменьшается, C++ обеспечена еще очень и очень долгая жизнь. Не верите -- посмотрите на COBOL.
K>COBOL лежит в мавзолее и на него приходят посмотреть местные некрофилы.
Извини, но Cobol 2002 (стандарт) некрофилы видимо создали?
Re[16]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, konsoletyper, Вы писали:
K>Судя по всему, C++ уже 90-летний старик. Его можно уважать, считаться с ним. Но ему осталось недолго. Пусть он уступит место молодым.
Блин! Где C++ насаждается силой и где он не дает развиваться конкурентам?
K>Но зачем стартовать новые проекты на C++ там, где можно обойтись другими средствами?
Вы вообще-то сейчас о реальной жизни говорите или так, гипотетически?
Можете привести примеры, когда на C++ начинаются новые серьезные проекты и в которых C++ явно прогрывает конкурентам? И все ли факторы, сказывающиеся на таком выборе вы можете оценить?
K>Мне кажется, мы просто по разному понимаем слово "умер". Вот я понимаю "ЯП жив" когда:
Вот уж яркое проявление юношеского максимализма. По мне, так ваше определение, да еще с делением на мейнстримовые языки и все остальные напоминает выражение "чуть-чуть беременна". Такого не бывает -- беременность или есть, или нет. Точно так же и со смертью.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Как скрестить ужа и ежа или статическую и утиные тип
поискипал все нафиг ибо смысла обсуждать ИМХИ нет.
Я хочу говорить за фичи якобы не нужные и переписывание ПО
Дабы не разводить флейма я дам ссылку на Спольски с которым абсолютно согласен по части практики переписывания старого кода ибо пару раз наблюдал на практике к чему приводит поддержка старой системы в новых реалиях и к чему приводят попытки ее переписать на новой платформе или новом языке. Результат настолько не в пользу переписывания, что я даже и предположить не мог глядя на начало этого проекта — все было очень радужно в начале и настолько же печально закончилось, унеся с собой в небытие пару тройку милллионов долларов, а старая система опосля "рихтовки напильником" великолепно живет и еще долго проживет.
Прошу заметить — я не говорю, что язык С++ не имеет недостатков и нужно молится на него. Я хочу сказать во первых, что язык не умер, а во вторых, что дизайн языка промышленного уровня вряд ли может быть иным. Да, можно избежать всех недостатков С++ и повысить продуктивность как конечного приложения, так и разработчиков в определенной области, но обязательно будут другие проблемы ничем не лучше и не хуже. Каждой проблеме — свой язык. Вот только где разработчиков найти на рутинную работу по поддержке
Re[17]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, Laughing_Silencer, Вы писали:
L_S>Прикладное ПО для настольных компьютеров — я бы сказал, что сектор расширяется и там есть место для всех, а не то, что уходит.
Именно что уходят. Старые системы начинают поддержывать, а новые не пишут (ну разве что оголтелые фанатика но они прогорят).
L_S>Зато вся та масса встроенных программ в оборудование начинает потихоньку переходить на С и С++ как наиболее удобные средства.
С ассемблера или вобще машинных кодов... L_S>Просто для бизнес приложений главное скорость разработки и минимизация ошибок.
Это главное всегда. L_S>а при большом объеме кода проще сделать это на управляемых средах.
При любом объеме проще писать в средах где при всем жилании не проехатся по памяти и не ловить потом ошибку... L_S>В случае же со встроенным ПО намного проще работать с С и С++. Поэтому все производители уходят туда с других языков.
Оно тоже бывает разное.
Есть такое что туда только с ассемблером и можно, а все что позволяет С/С++ уже можно писать и на чемто по умнее. L_S>Использование Жабы или Шарпа для встроенного ПО просто нецелесообразно и вряд ли будет целесообразно — они нацелены на другое.
Про шарп и жабу согласен. Но виртуальную машину можно спроектировать куда умнее.
L_S>Вот все говорят про правильный и неправильный дизайн забывая о том, что задача языка не быть красивым, а быть функциональным.
Те полным по Тьюрингу? Самому не смешно? L_S>Т.е. идея не в том, что бы писать абсолютно безопасные программы, а что бы писать нужные программы.
Нет. Идея в том чтобы писать абсолютно безопасные нужные программы. L_S>Вообще я смотрю на разные языки и у всех свои недостатки, просто некоторые языки развиваются и со временем превращаются в фичепомойку, которую затем зачем то называют неправильным дизайном, а другие языки в свою очередь отстаивают определенные позиции и с академической точки зрения имеют мало недостатков, но не применяются ибо для того, что бы их применять на промышленном уровне нужны высококлассные специалисты и до кучи не все на них можно сделать.
Ты сейчас глупость сказал ибо ни для какого другого языка не нужно знать столько граблей как для С++.
L_S>Да что ты говоришь — ну ка расскажи ка мне про кривизну этого подхода ? В чем она ? В том, что есть другие способы что ли ? Единственный недостаток на мой личный взгляд это отрыв библиотеки от ее описания, а все остальное мелочи не заслуживающие внимания.
Да на С++ ты писал маловато... Что никогда небыло что из-за изменения порядка includ'ов программа работала по разному?
L_S>Ладно тебе — какая уж тут узкая ниша. Ну вот например для встроенных систем пока нету тенденций к переходу на другие языки, а это отнюдь не узкая ниша и деньги тут крутятся очень большие.
Тут многое можно писать и на чемто получше, а остальное на ассемблере. L_S>Затем всяческая цифровая обработка, драйвера, коммуникационное ПО, анализаторы сигналов и т.п.
А вот это точно можно перенести на управляемые среды. И получится лучше чем на С++.
L_S>Просто ты наверное устал от С++ и тебе хочется чего то нового, но это не значит, что язык свое отжил.
Лично я могу писать вобще на всем что шевелится (за исключением brainfuck'ов и прочих whitespace'ов).
Но мне не нравится я вместо решения задачи решать проблемы языка.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Как скрестить ужа и ежа или статическую и утиные тип
konsoletyper wrote: > А вот я вижу. Прикладное ПО (за исключением игр) уже давно переходит на > Java и .NET. Есть особые ситуации — графические библиотеки, игры, ОС и > т.д.
А еще:
Прикладные программы
Ресурсоемкие системы
Браузеры
Встроенный софт
и т.п.
На моем компьютере сейчас не работает ни одной managed-программы. Так
что слухи о смерти С++ — сильно преувеличены.
У Java/C# есть свои ниши — но вот на мировое господство они пока даже
близко не претендуют.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[11]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, FR, Вы писали:
FR>Ты тоже вовсю плевался в Boo FR>Там подход обратный, в языке со статической типизацией есть опциональная утиная динамическая.
Это вопрос аналогичный тому является ли стакан на половину пустым или на половину полным. В твоем случае ты видишь разница так как предвзято относишся к самой идее. Кога же ты ее слышишь из уст неприкосаемого для тебя авторитета, то воспринимаешь ее более спокойно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, FR, Вы писали:
FR>Понятно что self в интерфейс передавать малоосмысленно. Но то что тело все таки есть уже сразу подсказывает что его можно использовать не только для контрактного программирования
Без self ты не сможешь сделать ничего с объектом. Выражаясь наукообразно ты не сможешь изменить инвариант объекта. Это делает бесполезым такой код для большинства применений. Думаю, что есди до этой реализации дойдет дело, то он еще запретит возврат значений из таких тел, чтобы ты не мог предотвратить выполнение реального тела.
Кстати, в отличии от этого в Хаскеле можно создавать именно что тела используемые по умолчанию. Если в реальном воплощении интерфейса метод (функция класса типа) не переопределн, то используется реализация по умолчанию. Так для класса типа Eq реализуется оператор "не равно" который инвертирует значение оператора "равно" (который обязан быть задан явно). Но постусловия так уже не сделать. Ведь если в воплощении реализовать метод явно, то реализация по умолчанию попросту не будет учитываться компилятором.
Так что лично у меня нет сомнений, что данная возможность предлагается искоючительно для реализации пред-условий.
FR>Кстати все что описанно там можно и сейчас на метаклассах сварганить, кое где конечно будет коряво и не причесано синтаксически.
Кстати, он по этому поводу тоже говорил. И вывод его был однозначный, что это худшее решение нежели интеграция в комплитор.
FR>Вот 3. 4. 5. нормально нужно разрешить, и обсудалось именно это.
Ни один пункт не имеет отношения к тому о чем говоришь ты. Так что не надо валить напраслины.
FR>Так никто ни спорит что окамл неплохой язык, но не без недостатков.
Не без недостатков. Но они не там где ты ты их хочешь выдеть. С точки зрения вывода типов и стройности системы типов в ОКамл и темболее в Хаскле все ОК.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, FR, Вы писали:
FR>Это проблемы не только Окамла, просто там они достаточно ярко проявлены. Почитай снова тему все это уже обсудили.
Что почитать? Дай ссылки. Пока что я склоняюсь к тому мнению, что ты наговаривашь на ОКамл по причине его плохого знания и по причине пристрастности к динамической типизации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, AndreiF, Вы писали:
FR>>Да те же самые про которые пишет выше eao197 и которые затронуты у ван Россума, и нерешение которых в окамле привело к уродцам типа '.+'
AF>Если ты говоришь о перегрузке операторов, то ее отсутствие вызвано совсем другими причнами, которые к типизации не имеют никакого отношения. Или ты что-то другое имел в виду?
Кстати, в Хаскле, благодаря как раз классам типов, нет проблем с переопределением операторов. А ведь система типов там используется очень похожая на ОКамловскую.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, Laughing_Silencer, Вы писали:
L_S>Либо пиши ИМХО, либо обоснуй... Честно говоря я не понимаю критериев по которым можно сказать, что некоторый язык умирает за исключением оттока разработчиков и снижение абсолютной доли рынка. Пока этого не видно.
Лично я не считаю, что язык умерает. Он еще долго будет существовать по разным причинам. Но как раз таки то что наблюдается отток разработчиков и снижение абсолютной доли рынка С++ у меня не вызвает никакого сомнения. Дотент, Ява и скрипты сильно сократили долю С++ на рынке. И тендеция эта продолжается.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, AndreiF, Вы писали:
AF>Что интересно, статья ван Россума выглядит намного адекватнее, чем заявления многих любителей Питона и Руби на нашем форуме. Которые привыкли заявлять, что "статическая типизация вообще не нужна, и вообще только мешает".
Ссылки можно на такие заявления?
Re[6]: Как скрестить ужа и ежа или статическую и утиные типи
Здравствуйте, AndreiF, Вы писали:
AF>Если ты говоришь о перегрузке операторов, то ее отсутствие вызвано совсем другими причнами, которые к типизации не имеют никакого отношения. Или ты что-то другое имел в виду?
Я про это:
def min(a: T, b: T) -> T:
if a < b:
return a
else:
return b
As a (rather unpythonic) strawman, I'm using T and T0, T1, T2, etc. as type variables. You can think of these as the free variables in an equation of types; we're saying that the types of a, b and the (unnamed) return value must all be the same. So min(1, 2) is valid and returns an int; min("a", "b") is valid and returns a string.
What about min(1, 2.5)? That ought to be valid and return a float. I guess this means that there should be some kind of typing hierarchy that explains how the various numeric types are embedded in each other. The VM already knows about these coercion rules, but the trick is to build them into the type system. I think I would like to do this using a mechanism separate from inheritance, since I really don't think that it is a good idea to require that int is a subclass of float and float a subclass of complex. But the mechanism should also be open to user-defined types; there shouldn't be mechanisms in Python that the user cannot extend (not many, anyway).
Re[14]: Как скрестить ужа и ежа или статическую и утиные тип
konsoletyper wrote: > Что уж говорить о таких давно освоенных вещах, > как, например GC, который так и не добавили в C++? Все добавления, > которые в нём есть — это робкие попытки залатать те дырки, которые > возникли в нём давно из-за неправильного дизайна, сохранив при этом > совместимость. Единственное, что заслуживает внимания — это развитие > метапрограммирования, но без всего остального оно того стоит?
GC в С++ не добавляют принципиально — для точного GC нужно менять
семантику кучи конструкций. А консервные GC — пожалуйста, сколько угодно.
Кстати, а почему на таком хорошем и развитом C# еще не переписан Word и
сама .NET VM?
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[12]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Ты тоже вовсю плевался в Boo FR>>Там подход обратный, в языке со статической типизацией есть опциональная утиная динамическая.
VD>Это вопрос аналогичный тому является ли стакан на половину пустым или на половину полным. В твоем случае ты видишь разница так как предвзято относишся к самой идее. Кога же ты ее слышишь из уст неприкосаемого для тебя авторитета, то воспринимаешь ее более спокойно.
Во первых ван Россум не является для меня неприкосаемым авторитетом. Во вторых все что исходит от тебя приходится сильно фильтровать, так как ты слишком увлекаешся и видишь все только в одном цвете. В третьих я нормально отношусь к статической типизации и также нормально отношусь и к динамической и постоянно пишу на языках с разными типизациями.
ИМХО всем не угодишь по части фич 
