1. C# / Говнокод #19903

    −2

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    Немного о пропертях
    
    "Лично мне свойства не нравятся и я был бы рад, если бы в Microsoft решили убрать
    их поддержку из .NET Framework и сопутствующих языков программирования."
    
    "Я считаю, что разработчики используют свойства намного чаще, чем следовало
    бы. Достаточно внимательно изучить список различий между свойствами и поля-
    ми, чтобы понять: есть очень немного ситуаций, в которых определение свойства
    действительно полезно, удобно и не запутывает разработчика. Единственная при-
    влекательная черта свойств — упрощенный синтаксис, все остальное — недостатки,
    в числе которых потеря в производительности и читабельности кода. Если бы я
    участвовал в разработке .NET Framework и компиляторов, я бы вообще отказался от
    свойств, вместо этого я предоставил бы разработчикам полную свободу реализации
    методов GetXxx и SetXxx. Позже создатели компиляторов могли бы предоставить
    особый упрощенный синтаксис вызова этих методов, но только при условии его
    отличия от синтаксиса обращения к полям, чтобы программист четко понимал, что
    выполняется вызов метода!"
    
    Джефри Рихтер

    Срач объявляется открытым

    Запостил: kegdan, 29 Апреля 2016

    Комментарии (356) RSS

    • Проперти нинужны
      Ответить
    • >все остальное — недостатки, в числе которых потеря в производительности и читабельности кода
      А еще какие?
      Читабельности: и как же это автопроперти мешает читабельности?
      Производительности: за производительность пусть борется конпелятор, а код должен быть читабельным (но не стоит убивать производительность).
      Ответить
    • А что мешает программеру писать напряную в поле помеченное как public и использовать класс как структуру?
      Ответить
      • потом сложно будет поменять поведение без перекомпиляции
        и бряку не поставить
        Ответить
    • год забыли указать для этой цитати

      Мелкий Билли тоже обещал что 640 кб памяти хватит всем
      Ответить
      • 2013 Только вышел 5 шарп
        Ответить
        • я этот хейт на проперти читал еще в книге по 2.0 .NET
          Ответить
          • ну так и сами проперти не изменились
            Ответить
            • Воды много утекло с того времени, на свойствах построилось множество библиотек и фреймворков. И сейчас это высказывание звучит нелепо неактуально
              Ответить
              • ну да, пришлось бы переписывать дохрена кода. Тот энтети фреймворк завязан исключительно на пропертях.

                Но сами проперти мне не нравятся. явное лучше неявного
                Ответить
                • >явное лучше неявного
                  Многие до этой простой истины годами не могут дойти.
                  Ответить
                  • я тут понял, что чем проще написан код - тем лучше. Никому нафиг не нужны неявные касты, эксепшены в пропертях, перегруженные операторы, которые творят сатанизм.

                    Моргни, если я прав
                    Ответить
    • Сразу вспоминаю Dummy0001, который говорит, что тайпдефы — зло, потому что не позволяют сходу отличить структуру от скалярных типов.
      Ответить
      • не надо меня вне контекста цитировать: "тайпдефы в С - зло".

        я не знаю про пропертисы в шарпах, но везде где видел было полезной фичей. это не то что бы кто-то заставляет пользоваться.
        Ответить
    • Интересно девки пляшут.
      А что Рихтер предлагает сделать с WPF и прочими, где байндинг на проперти - чуть ли не основа технологии? Вон не прошло и десяти лет, а МС уже запилили nameof(), чтобы даже от строкотипизации в INotifyPropertyChanged уйти... Куда это всё теперь? Возврат к ручному бойлерплейту а-ля жаба? Ну не, спасибо...
      Ответить
      • ой, ну не так все страшно в жабе
        intellij генерит аксесоры и мутаторы на ура

        а kotlin так и вовсе не требует
        Ответить
    • На уровне IL свойства -- методы get_PropertyName, set_PropertyName.
      @@
      Попробовал set_PropertyName(), компилятор навалял пиздюлей и сказал мол низзя прямо так вызывать методы доступа.
      @@
      Но ведь можно написать свой ЯП с таким синтаксисом! Джефри Рихтер, сасай.
      Ответить
    • Хуй там. Нужны.
      Ответить
      • "синтаксические подсластители - зло." из той же оперы.
        Ответить
        • Конечно. Чем больше бойлерплейта ты накопипастил руками, тем круче ты как программист
          Ответить
          • Настоящие программисты напишут DSL к Си или ассемблеру, а не будут юзать убогое говно со сборкой мусора, придуманное склонированное с жабы мудаками из мокрософта, которое к тому же нихера не умеет делать динамической JIT компиляции и адаптивной оптимизации, как это делает HotSpot(но не думайте что я сторонник жабы, жаба тоже говно).
            Ответить
            • CLR превосходит JVM, равно как и C# Джаву.
              C# очень богатый ЯП, один из лучших современных ЯП.
              В .NET есть JIT, и он отлично работает.
              Ответить
              • >CLR превосходит JVM
                Нет.
                >равно как и C# Джаву.
                Спорно.
                >C# очень богатый ЯП, один из лучших современных ЯП.
                Нет
                >В .NET есть JIT, и он отлично работает.
                Да, но нет никакого динамического анализа кода, который осуществляется например в HotSpot. HotSpot умеет собирать в рантайме статистику, и на основе этой статистики он умеет делать некие оптимизации.Примерно как profile-guided optimization. В .NET рантайме ничего такого нет, насколько я знаю
                Ответить
                • >> Нет.
                  >> Спорно.
                  >> Нет

                  отличная аргументация
                  Ответить
                  • >отличная аргументация
                    Ну какие утверждения, такая и аргументация. Я например могу заявить:
                    Трава фиолетовая
                    Слоны летают в космосе
                    Тараканы умеют разговаривать на человеческом языке

                    и ожидать на подобный бред каких-то аргументированных опровержений было бы глупо, не находите?
                    Ответить
                • 1. CLR конечно же круче JVM, достаточно посмотреть набор опкодов той и другой машины
                  2. C# конечно же на голову круче Джавы по выразительности: там есть куча всего: от async до вывода типов. От Linq до Dynamic. А в Джаву даже сраные лямбды с кложами только вчера завезли, а генериков в рантайме и вовсе нет.
                  3. Никакого анализа кода не нужно, в дотнете можно сразу же скомпилироваться из CLR в нативный код, причем под конкретный процессор (см ngen)

                  Аргумент про про "склонированное" вообще прекрасен! Что там склонировано? Идея виртуальной машины? Идея ГЦ?

                  Все современные ОС, в таком случае, склонированы с OS360.

                  Ты напоминаешь мне пубертатного кулхацкора, который в журнале "хакер" прочитал что "виндуос это не круто" и теперь обливает говном любой МС продукт просто потому, что это МС
                  Ответить
                  • >1. CLR конечно же круче JVM, достаточно посмотреть набор опкодов той и другой машины
                    Учитывается ли, что есть разные варианты машин с разными опкодами, например Dalvik и Java Card? И как вообще можно судить о крутизне VM только лишь по опкодам? Может надо сравнивать получившийся машинный код, оптимизации например? Или скажем кроссплатформенность? C# научились уже в сим карты засовывать? Какие конкретно среды выполнения Java и С# кода сравнивать? Mono с Dalvik? Или может .NET c HotSpot?

                    >2. C# конечно же на голову круче Джавы по выразительности
                    По-моему они оба говно. Сама идея городить какие-то там виртуалки с обязательным контролем границ массива в рантайме и сборкой мусора - говно. Мне вообще не интересен холивар Java VS C# т.к. на мой взгляд оба они говно. Вот насчет C vs C++, C vs Java, C vs C#, ASM vs C - это сколько угодно
                    >там есть куча всего: от async до вывода типов. От Linq до Dynamic.
                    Для подобной херни пусть Scala используют http://scalaquery.org/doc/ScalaDays2012-SLICK.pdf

                    >3. Никакого анализа кода не нужно, в дотнете можно сразу же скомпилироваться из CLR в нативный код, причем под конкретный процессор (см ngen)
                    Для жабы это тоже есть, JRockit и ART (Android RunTime). И хуй знает что из этого лучше (AoT или всякое профилирование и динамическая компиляция как в HotSpot). В том же GCC и MSVC для Си и плюсов есть PGO например, но есть еще некоторые вещи, которые ни то ни другое не поддерживает, например суперкомпиляция, впервые примененная в языке РЕФАЛ и которую хотят реализовать в JVM.

                    Кстати, для жабы намного больше есть этих виртуальных сред выполнения, чем для дотнетов (официальный .NET от M$ и Mono, создателя которого они не так давно перекупили к себе; был еще какой-то dotgnu но он похоже сдох), т.е. все актуальные реализации CLR находятся под контролем одной корпорации. Не могу сказать что это хорошо.
                    Ответить
                    • >>2. C# конечно же на голову круче Джавы по выразительности
                      >По-моему они оба говно.

                      Сам ты говно. Это языки высокого уровня. Их задача - максимально сократить количество выстрелов в ногу и сконцентрировать программиста на задаче. И простой OutOfRangeException вместо UB, когда компилятор может сжечь твой дом и убить твою собаку - это просто счастье.

                      Разработка одного и того же на c# будет в разы быстрее, чем на крестах, если не так критично быстродействие. А быстродействие в 99% не критично, ибо не семидесятые годы и даже на самых старых компах минимум два ядра по гигагерцу и гиг оперативки.
                      Ответить
                      • >Сам ты говно. Это языки высокого уровня. Их задача - максимально сократить количество выстрелов в ногу и сконцентрировать программиста на задаче. И простой OutOfRangeException вместо UB, когда компилятор может сжечь твой дом и убить твою собаку - это просто счастье.
                        Чтобы избежать UB от выходов за пределы массива можно использовать херню вроде смартпоинтеров которые тебе будут проверять границу. Еще этот Rust, в нем можно через RAII без GC и явных освобождений памяти обходиться.


                        >Разработка одного и того же на c# будет в разы быстрее, чем на крестах, если не так критично быстродействие. А быстродействие в 99% не критично
                        Откуда вы эти 99% вообще берете? С потолка? Методику подсчета - в студию
                        Ответить
                        • И где твой раст сегодня?
                          Ответить
                          • А чего ты вообще хочешь, первый стабильный релиз в 2015 году. Где была Java в 1996?
                            Ответить
                            • Ну ты понимаешь, людям на хлеб что-то мазать хочется, а не ебаться с багами языка и иде нахаляву.
                              Ответить
                        • > Откуда вы эти 99% вообще берете? С потолка? Методику подсчета - в студию

                          С потолка, конечно. Я что, ебанутый искать реальные цифры в интернете? Методику-хуёдику ему подавай. Всё исключительно интуитивно и на собственном опыте.

                          Подумай, сколько процентов кода в мире пишется для ынтырпрайза и прочей некритичной хуйни. Я думаю, около 90%. А потом, прикинь, сколько процентов от каждого проекта критично к быстродействию. Меньше 90% никак не получится, ибо узкие места, как правило, маленькие. А логики много.

                          А теперь вот о чём нужно подумать. Стоит ли оверхед усилий на неуправляемый язык той прибавки производительности, который он даёт? Основная оптимизация - алгоритмическая, она может дать 1000% производительности или больше, в то время, как прибавка от использования крестов, раста и сей ну в два, ну в три раза больше может дать (в особо запущенных случаях). Ассемблер ваще даже не рассматриваю, в современной архитектуре x86-64 нереально написать код лучше компилятора ибо очень сложно.
                          Ответить
                          • Парни, ну уже не смешно. Вы еще подеритесь у какого языка иде лучше
                            Ответить
                            • Кстати, тоже аргумент. У управляемых языков с ИДЕ почему-то лучше.
                              Ответить
                              • пф. просто сравните vs под шарп и vs под C++/CLI
                                Ответить
                                • пф. просто сравните emacs и дырявый вонючий носок
                                  emacs и дырявый вонючий носок
                                  дырявый вонючий носок и emacs
                                  и...
                                  пожалуй, всё же emacs
                                  Ответить
                                • Я вот не втыкаю. Мы таки спорим или говорим об одном и том же? Приходилось в той же vs отлаживать и править крестовый код, от отсутствия элементарных возможностей испытал лютый баттхёрт.
                                  Ответить
                      • C# и жаба это не просто высокий уровень, это еще и ГЦ и рефлексия и типизация и в рантайме и статическая и много чего другого. Но твой собеседник ни про что это не знает, и никогда в жизни не использовал, так что бессмысленно пытаться ему что-то объяснять.

                        Это примерно как говорить про паттерны с ПХПшником
                        Ответить
                        • >ГЦ и рефлексия
                          Это разве не признаки высокого уровня?

                          >типизация и в рантайме
                          Не в жаве.
                          Ответить
                          • >>типизация и в рантайме
                            >Не в жаве.

                            Есть там типизация в рантайме. С дженериками, да, плохо. Впрочем, они сказали, что это Type Erasure и вроде как фича, а не баг.
                            Ответить
                            • это не фича, а кастыль для обратной совместимости

                              всем было бы лучше, если бы генерики были в рантайме
                              но увы
                              Ответить
                          • >>Это разве не признаки высокого уровня?
                            нет. В JavaScript может не быть рефлексии, а в Swift -- gc)

                            >>Не в жаве.
                            именно что в джаве. Попробуй скастить строку к объекту
                            Ответить
                            • что-то я туплю.
                              разве
                              типизация и в рантайме != динамическая типизация? неправ: прав;
                              Ответить
                              • скорее, речь о том, что в жабу можно нарефлексировать объектов, и они всё равно будут статически типизированы
                                Ответить
                                • >в жабу можно нарефлексировать объектов
                                  Што?
                                  Ответить
                            • >Попробуй скастить строку к объекту
                              http://ideone.com/XmQJsn

                              >C# и жаба это не просто высокий уровень, это еще и ГЦ и рефлексия и типизация и в рантайме и статическая и много чего другого.
                              Ну всерхвысоким уровень не становится от этого.
                              Ответить
                              • молодец
                                а теперь скасти объект в строку и получи exception
                                потому что джаве в рантайме есть инфа о типах
                                это и называется дин. типизацией

                                например в сях или ObjC ее нет, ты можешь скастить случайное число в указатель на структуру и сидеть так до Faultа (а в реальном режиме до перезабирания ДОСа или перезагрузки компутера)
                                Ответить
                                • > а теперь скасти объект в строку и получи exception

                                  Да не будет exception, формулируйте мысли правильно.

                                  Серия кастов Integer -> Object -> String приведёт к исключению ClassCastException.

                                  Если в жабе работает явный каст B -> A, то и явный каст A -> B на том же объекте всегда будет работать.
                                  Ответить
                                  • >>Да не будет exception
                                    >>приведёт к исключению ClassCastException.

                                    так будет или нет?)
                                    Ответить
                                    • > так будет или нет?)

                                      От каста String -> Object -> String не будет, ибо с чего бы.

                                      От каста Integer -> Object -> String будет, ибо нефиг.
                                      Ответить
                            • http://ideone.com/iUCs1A

                              сколько строку в объект не касть, она все равно строка
                              Ответить
                              • http://ideone.com/gNpADh

                                динамический питух и в жабе кукарекает
                                Ответить
                              • вот именно)

                                потому что в рантайме есть знание о типе
                                Ответить
                        • >это еще и ГЦ и рефлексия
                          >рефлексия
                          Вот в ассемблере с рефлексией вообще заебись, можно делать самомодифицирующийся код. А встроенный и неотключаемый GC на уровне рантайма это однозначное говно.
                          Ответить
                          • 1. нельзя давно уже его делать.
                            2. рефлексия не имеет никакого отношения как самоодифицируемому коду.
                            3. говно это когда ты пытаешься рассуждать о том, в чем ничего не понимешь
                            Ответить
                            • >1. нельзя давно уже его делать.
                              Можно. Вчера я такой код запускал как раз.
                              >2. рефлексия не имеет никакого отношения как самоодифицируемому коду.
                              System.Reflection.Emit и MethodBase.GetMethodBody это что по-вашему?
                              >3. говно это когда ты пытаешься рассуждать о том, в чем ничего не понимешь
                              Я отлично все понимаю.
                              Ответить
                              • 1. да? и как он работает, учитывая тот факт что как минимум страница с кодом защищена от записи?

                                2. Это только маленькая часть рефлексии. Обычно ее используют для получения информации о типе (например для работы с атрибутами) и для создания типов по имени.

                                3. Ты не понимаешь зачем рефлексия. Ты не понимаешь зачем GC. Видно что ты ничего не писал на .NET, и несешь тут всякую чушь.
                                Ответить
                                • > страница с кодом защищена от записи?
                                  Снимаешь трусы защиту и бежишь модифицировать... Все JIT'ы так и работают.
                                  Ответить
                                  • Окей, принято. Однако это не отменяет того факта, что использовать самомодифициуремый код плохо (джит не является самомодифицируемым) и что рефлексия используется СОВЕРШЕННО НЕ ДЛЯ ТОГО ЖЕ, и нахуя суда приплели самомод. код вообще не понятно
                                    Ответить
                                    • >(джит не является самомодифицируемым)
                                      В жабаскрипте я могу взять строку, менять ее в рантайме и потом eval-ить. Вот вам и самомодифицирующийся код, притом с JIT-ом
                                      $ nodejs
                                      > var expression = new String("2 + 2");
                                      undefined
                                      > eval(expression.toString());
                                      4
                                      > expression=expression.replace("2", "3");
                                      '3 + 2'
                                      > eval(expression.toString());
                                      5
                                      Ответить
                                      • Использование JIT в CLR, очевидно, не является примером самомодифицируемого кода.
                                        Ответить
                                  • Кстати! в некоторых процах есть отдельный кеш для комманд
                                    Так вот кеш этот идет на смарку при самомод..коде
                                    это проеб по перформансу
                                    Ответить
                                    • https://community.arm.com/groups/processors/blog/2010/02/17/caches-and-self-modifying-code - на арме я кстати столкнулся с этой херней.
                                      Ответить
                                • >1. да? и как он работает, учитывая тот факт что как минимум страница с кодом защищена от записи?
                                  https://paste.debian.net/685804/ - отлично работает в линуксах, если объявить свою секцию с "axw"

                                  >2. Это только маленькая часть рефлексии. Обычно ее используют для получения информации о типе (например для работы с атрибутами)
                                  А на кой хер вообще получать информацию о типе в рантайме, если через Хиндли-Милнера все можно вывести еще на этапе типизации?
                                  >и для создания типов по имени.
                                  Ну это как в фортране типа, http://www.lib.ru/ANEKDOTY/non_pas.txt
                                  Хуже всего с этими хитрыми типами данных то, что вы должны их описывать, а настоящие языки программирования, как мы все знаем, обладают возможностью неявного задания типа, основанного на первой букве 6-символьного имени переменной.
                                  Или мы через рефлекшены говорим в компилтайме "а сделай-ка мне вот тип точно такой же, как вон тот" ?

                                  В любом случае это говно. Чтобы в полную силу все это задействовать, надо работать на уровне AST и с макросами как в лиспе с гомоиконностью, а херня из сишарпа просто убогий огрызок от тех возможностей.
                                  Ответить
                                  • >>А на кой хер вообще получать информацию о типе в рантайме, >>если через Хиндли-Милнера все можно вывести еще на этапе
                                    >> типизации?

                                    Нельзя, если ты загружаешь внешний объект, например.

                                    >>надо работать на уровне AST
                                    Совершенно ни причем тут AST.

                                    Рефлексия позволяет сделать AOP, позволяет расставить пермишены на уровне метода, и много чего другого
                                    Ответить
                                    • Все, что можно делать с рефлексией, можно делать и через AST. Фактически, когда программа со своим AST может в рантайме работать, получать некую информацию из него, добавлять и изменять что-то - это и есть по-сути рефлексия

                                      Почитай еще про то, что такое гомоиконность
                                      Ответить
                                  • > через Хиндли-Милнера все можно вывести еще на этапе типизации
                                    *facepalm.jpg*
                                    Ответить
                                    • на этапе компиляции, когда происходит типизация(вывод типов)
                                      Ответить
                                    • Я вот удивляюсь как он умудрился смешать в одну кучу вывод типов, рефлексию и самомодифицируемый код.

                                      Ты понимаешь масштаб каши в голове, да?

                                      "Существует вывод типов, потому рефлексия не нужна". Блядь! Это вореция со мною говорит
                                      Ответить
                                      • вывод типов если есть - значит нехуй их в рантайме определять. Хули тут неясно?
                                        Ответить
                                      • Во всяком динамическотипизированном говне вроде жабаскрипта, там вообще типы каждый раз резолвятся. Хотя вот коммонлисп в этом плане выделяется в положительную сторону, там можно цеплять к этим типам кагбэ аннотации, вот например http://fprog.ru/2010/issue4/vitaly-mayatskikh-lisp-abstractions-on-steroids/
                                        (defun sum (a b)
                                          (declare (type fixnum a b))
                                          (+ a b))


                                        (defun sum (a b)
                                          (declare (type (integer 0 1000) a b))
                                          (+ a b))

                                        И это еще можно использовать как для контрактного программирования.
                                        А если еще вспомнить концепцию суперкомпиляции, которую придумал автор Рефала, т.е. если из самого кода можно было б вывести, что в такую-то функцию не будут передаваться числа, большие чем x, то на основе этого можно было б хуйнуть специализацию функции. Но в ебучем сишарпе хуй знает вообще какое говно из какого блядского модуля подключится к программе, и хуй там такое применишь
                                        Ответить
                                • >3. Ты не понимаешь зачем рефлексия. Ты не понимаешь зачем GC. Видно что ты ничего не писал на .NET, и несешь тут всякую чушь.
                                  Рефлексия это когда программа может залазить в свой собственный код(MSIL или машинный код или в еще какое-нибудь AST говнопредставление) и что-то осмысленное с ним делать. Можно на основе одного кода делать новый код, можно куски кода каким-то образом совмещать, опять таки можно получать информацию о типе, делать какбы-JIT. Это уже дело десятое

                                  А GC это такая херня которая нужна чтобы ручками не дергать malloc-free или другой механизм аллокации(например чтобы не писать кастомных аллокаторов, например пуловых, стековых и проч.), других полезных фич у него нет. Там производится куча каких-то дебильных действий, вроде поиска циклических ссылок, разбрасывания аллокаций на разные поколения, например там есть такое правило, что самое молодое поколение с наибольшей вероятностью скоро надо будет убирать, это все чтоб снизить время цикла сборки мусора. Всю эту херню я в свое время читал, и это говно.
                                  Ответить
                                  • >>Можно на основе одного кода делать новый код, можно куски кода каким-то образом совмещать

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

                                    >> чтобы ручками не дергать malloc-free
                                    Сразу видно что в достаточно крупном проекте ты не работал. Никто практически уже не делает в огромных бизнес-системах malloc-free руками. Используется или GC или Reference Counting. RC тоже не плох, но он не отлавливает islands of isolation, а GC отлавливает.
                                    Это достаточно сильно экономит время и делает код безопаснее
                                    Ответить
                        • > это не просто высокий уровень, это еще и ГЦ и рефлексия и типизация и в рантайме и статическая
                          И неявные ссылки с дипкопи только через анус. Как вы вообще программируете на этом? И в питоне, и в го плююсь с этого дрянья, один геморрой и никакого профита.
                          Ответить
                      • > И простой OutOfRangeException вместо UB
                        А в крестах ассерт. Ну, у нормальных людей. Долбоёбов с int* massiv = new int[N] не берём в расчёт.
                        Ответить
                        • Это сравнение жопы с пальцем.
                          В шарпожабе проверка включена по умолчанию. В крестах её нет. Нужна - напиши ручками... Вот здесь, здесь и вот здесь. Да и вот здесь. Нигде не забыл? Ну ладно, поехали... Блядь! Где-то всё равно забыл.
                          Ответить
                          • За что минус?
                            Ответить
                            • Я откуда знаю? У меня нет привычки минусовать за мнение, отличное от моего.
                              Ответить
                          • а зачем тебе не забывать проверки про границы массива?
                            как ты используешь массив, что тебе нужны эти проверки при каждом обращении?

                            просто зачем вообще людям массив? где путем локальности и четко понятной последовательности элементов достигается максимальное машинное быстродействие

                            в этом случае они прекрасно понимают, как с ним работать, не собираются из сети принимать индекс элемента и лезть по нему без проверки

                            в с++ охулиард более других коллекций, где хоть обмажься проверками на наличие элемента, заодно они более пригодны к вставке в середину и другим мутациям
                            Ответить
                            • Проверки индекса полезны в основном в инфраструктурном аспекте.

                              Допустим, Вася разрабатывает сервис, позволяющий запускать произвольный код, написанный другими разработчиками. Например, он пишет инфраструктуру плюсового HTTP-бэкенда, но не отвечает за код обработки запросов.

                              В управляемом языке можно просто перехватывать в инфраструктуре все исключения и генерить 500 ошибку. В C++ весь инфраструктурный процесс может слечь из-за кривого обращения к памяти / утечек.

                              Единственный способ избежать проблем - запускать обработчики в отдельных процессах и платить за копирование данных по IPC, т.е. fastcgi/nginx.

                              Честно говоря, монолитные управляемые приложения всё равно за nginx обычно сидят, но не для всех инфраструктурных вещей есть подобные стандарты де-факто.
                              Ответить
                              • я не спросил зачем нужны проверки границ или другая валидация параметров, ежу понятно зачем они нужны и полезны, тем более когда дело касается внешних параметров
                                у меня вопрос непосредственно про массив в крестах

                                сука как можно взять такой тупейший контейнер, который занимает минимум места и для которого взятие элемента по индексу O(1), который обычно требуется для того, чтобы засунуть в молотилку, конвейерно отработающую все элементы за 1 проход или даже массивно-параллельно, и сука повесить проверку границ на каждую попытку обращения к каждому его элементу?

                                ЗОТО БИЗОПАСНО!
                                Ответить
                                • В идеальном мире, где пишутся идеальные программы с первого раза и пишутся без ошибок, да... Нахуй проверки не нужны. В реальном мире с тупейшими контейнерами тоже часто ошибки происходят. Не менее тупейшие. Кто-то не учёл единичку, например. Кто-то забыл про нулябрь. Кто-то забыл умножить на три размер массива и при заполнении буффера мы идём гадить непонятно куда...
                                  Ответить
                                  • assert спасёт отца русской демократии.

                                    Если программа кривая, то не важно, это будет аккуратное исключение как в Java или неясное падение, для пользователя программа и там, и там упала.
                                    Ответить
                                    • > для пользователя программа и там, и там упала

                                      Отличие в том, уронит ли эта программа до кучи ещё и "программы" десятка соседних пользователей.

                                      Впрочем, управляемые языки в этом плане тоже говно - в них нет нормальных механизмов управления ресурсами, отличными от памяти. Если кривой обработчик нещадно течёт файловыми дескрипторами, контейнер тоже недолжно проживёт.
                                      Ответить
                                  • ок, довод, что c# для более тупых я принимаю
                                    тем более, что он всё равно тормозит, одной проверкой больше, одной меньше - никто разницы не увидит
                                    Ответить
                                    • компилятор сей тоже иногда делает ненужные вещи, которые крутой асемблерный программр бы делать не стал
                                      ок, си для тупых, я понимаю
                                      си тормозит!
                                      Ответить
                                • > конвейерно отработающую все элементы за 1 проход

                                  Массив - это опупенно нужная и вездесущая структура данных, поверх которой можно запилить кучу ништяков вроде
                                  бинарной кучи, дерева Фэнквика или дерева сегментов. Я уже забыл, сколько раз я отлаживал индексы в сегментном дереве. Больше, наверное, только во всевозможных двоичных поисках.
                                  Ответить
                                  • А вот когда Царь это говорил -- над ним все смеялись
                                    Ответить
                                  • > поверх которой
                                    тебе дали прекрасный золотой дробовик, переопределяй [], используй at в векторе, не используй массив
                                    зачем навязывать всем ухудшение производительности?
                                    Ответить
                                • Проверка границ не такая уж сложная операция, если размер тебе известен заранее
                                  Ответить
                                • Проверка границ тоже O(1)
                                  Ответить
                    • >Или может .NET c HotSpot?

                      >Для подобной херни пусть Scala используют http://scalaquery.org/doc/ScalaDays2012-SLICK.pd
                      Ты охуел? Ты эту скалу вообще видел? Ради линка изучать дубовый ФЯ?

                      Есть еще xamarin, который как-то компилирует c# то ли в жава код, то ли в байткод.

                      А для жавы интерпретатор кто-то кроме оракла реально пилит?
                      Ответить
                      • >Ты охуел? Ты эту скалу вообще видел? Ради линка изучать дубовый ФЯ?
                        Scala - язык мультипарадигменный, с циклами и нормальными изменяемыми(мутабельными) переменными/массивами(объектами), а не какой-то там хачкель с монадками. Да и почему только ради LINQ? Там много другой хуиты есть, макросы например

                        >Есть еще xamarin, который как-то компилирует c# то ли в жава код, то ли в байткод.
                        Там оно скорее всего сразу в машинный код компилирует.

                        >А для жавы интерпретатор кто-то кроме оракла реально пилит?
                        Гугл для андроидов точно что-то пилил, даже со своим байткодом, есть еще Jikes RVM и какая-то Java от IBM которую они пускают на своих System z (хер знает что там у них используется, может и есть куски кода от Sun/Oracle)
                        Ответить
                        • ТЫ скалу видел? Она *гораздо* сложнее c# с linq

                          >Гугл для андроидов точно что-то пилил
                          Все равно, одна система - один интерпретатор.

                          >Там оно скорее всего сразу в машинный код компилирует.
                          В нативный что ли? Не в байткод?
                          Ответить
                          • >ТЫ скалу видел? Она *гораздо* сложнее c# с linq
                            Видел код на скале - нихера особо сложного не заметил там.

                            >В нативный что ли? Не в байткод?
                            https://developer.xamarin.com/guides/cross-platform/getting_started/introduction_to_mobile_development/#How_Does_Xamarin_Work

                            On iOS, Xamarin’s Ahead-of-Time ( AOT) Compiler compiles Xamarin.iOS applications directly to native ARM assembly code. On Android, Xamarin’s compiler compiles down to Intermediate Language ( IL), which is then Just-in-Time ( JIT) compiled to native assembly when the application launches.
                            Ответить
                            • Дык. На иосе VM-то нету!

                              >Видел код на скале - нихера особо сложного не заметил там.
                              Поизучай его дольше 5 минут.
                              Ответить
                              • >Дык. На иосе VM-то нету!
                                Ну раз там есть JavaScript в браузере, VM по-любому должна быть!
                                Ответить
                                • Прием тут браузер? VM для программ по типу жавы там нет, там objc сразу в нативный код.
                                  Кстати, запрет на автогенерацию objc кода из другого кода уже убрали?
                                  Ответить
                                  • >Прием тут браузер? VM для программ по типу жавы там нет, там objc сразу в нативный код.
                                    Надо просто скомпилировать C# в JavaScript

                                    >Кстати, запрет на автогенерацию objc кода из другого кода уже убрали?
                                    А что, у них там был такой запрет? Какое им вообще дело до того, каким образом был получен код на obj-c?
                                    Ответить
                                    • https://habrahabr.ru/post/118116/#comment_3853708
                                      >Когда я начинал, все ненативные средства разработки были запрещены Apple. Тоже был не в большом восторге от Objective-C.
                                      11-й год. Ну значит, вычитал это в каком-то очень древнем журнале :)
                                      Ответить
                                      • что такое "ненативные срдетсва разработки"?

                                        AppCode тогда как работает?
                                        Ответить
                                        • >AppCode тогда как работает?
                                          через жопу и Xcode
                                          Но даже при этом AppCode намного удобнее
                                          Ответить
                                          • Удобнее, да. Но зато примерно все туториалы в мире и все проекты в мире заточены под XCode:) И шото я сильно сомневаюсь чтоб AppCode умел StoryBoard или Archive делать с подписью.

                                            Но вообще XCode страшно глючен конечно, и там много ебанаго стыда. Один хак с cocoa pods чего стоит. Почему XCode не умеет этого нативно?

                                            А еще там отвратный парсер, который ломается на первой незакрытой скобке, убогий рефакторинг (примерно один, да и тот не работает), но зато там есть xcodebuild, а у Intellij такой штуки нет ни в одном продукте! (не считая андроид студио с graddle)
                                            Ответить
                                            • > xcodebuild
                                              что это? если я правильно понял что это - нахуй jetbrains писать замену мавену или гульпу?
                                              Ответить
                                              • >что это?
                                                это консольная хрень для сборки проектов XCode. И это скорее похоже на cmake, нежелин а мавен.
                                                Ответить
                                                • эм, задача то решается именно та же
                                                  внешний инструмент, которому не нужна ide, собирает (минифицирует, чистит, деплоит etc) твой проект, делает это заебись, при этом отлично интегрируется в ide если надо - какие такие охуительные вещи умеет эта похожая на cmake хрень, что мы все дружно согласимся, что Apple 1:0 гетеросексуализм?
                                                  Ответить
                                                  • к сожалению maven херово интегрируется в Intellij.
                                                    а дублировать настройки в проекте и в IDE как-то глупо.

                                                    Хорошо интегрируется только graddle, потому что в Android Studio через него все настройки и делаются.

                                                    Вообще конечно еьаный стыд: у .NET есть msbuild, у xcode есть xcodebuild, и только у Intellij ничего нету.

                                                    Надеюсь, всем очевидно зачем нужно уметь с консоли собирать проект и запускать тесты? Про CI все в курсе?
                                                    Ответить
                                                    • прости, я не понимаю, что такое херово интегрируется
                                                      у меня в отделе иначе, чем мавеном, и не собираются жавопроекты, все это делают тыкая мышкой на предопределенных 1 раз тасках в ide, ну или открывая console если кому удобно
                                                      Ответить
                                                      • ну вот тебе нужно пометить папку как src
                                                        а еще тебе нужно запускать тесты в IDE

                                                        ты как это делаешь? сначала описываешь в pom.xml, а потом настраиваешь IDE чтобы IDE знало что вот src, а потом создаешь в IDE ран конфигурацию для тестов?
                                                        Ответить
                                                        • если чо, я не жава программист, и не запускаю тесты и тем более не настраиваю среду для этого

                                                          те тесты, которые запускают тут, в отделе, запускаются мавеном
                                                          а до автотестирования фронта через какие-нибудь селениум нам как до китая раком, никто и не пробовал

                                                          я лишь сужу о том, о чем ноют разработчики
                                                          например, они могут поныть о том, что 16 рам мало для идеи, всем пробил 32, могут поныть что 2 монитора лучше 1, и 1200 по вертикали лучше 1080 - ну ок

                                                          о плохой интеграции мавена или гульпа в идею никто не ныл, да и смысл - особо упоротые при желании могут хоть в нетбинсе писать, всё взлетит, поэтом хранить какие-то существенные настройки проекта в идее странно
                                                          Ответить
                                                        • > ты как это делаешь? сначала описываешь в pom.xml, а потом настраиваешь IDE чтобы IDE знало что вот src

                                                          Вообще-то идея отлично понимает pom.xml, и, разумеется, подхватывает и обновляет source-каталоги и таргеты.
                                                          Более того, до недавнего времени интеграция с maven была на порядок стабильнее и полнее, чем с Gradle. Ну и до сих пор мавен-интеграция на порядки быстрее и отзывчивее gradle-интеграции, которая тормозит как говно даже на топовых машинах.
                                                          Ответить
                                                          • Как минимум, информация дублирована. Сначала ты правишь pom, затем по нему настраивается проект. В случае msbuild и xcodebuild таких проблем нет.
                                                            Во-вторых сама по себе интеграция тоже довольно глючная.
                                                            Ответить
                                                            • > Сначала ты правишь pom, затем по нему настраивается проект.

                                                              С градлом это не так?

                                                              > Во-вторых сама по себе интеграция тоже довольно глючная.

                                                              В чём именно?
                                                              Ответить
                                                              • >>С градлом это не так?
                                                                ЕМНИП нет. Идея сама считывает настройки в рантайме. Добавил папку сырцов, и она сразу "посинела".

                                                                Но даже если она и синхронизирует это "в фоне", то (еще раз говорю) в msbuild и xcodebuild этих проблем лишены.


                                                                >>В чём именно?
                                                                попробуй описать тесты в мавене, а потом запустить конкретный тест

                                                                Для этого есть отдельный плагин версии 0.0.19
                                                                https://plugins.jetbrains.com/plugin/7446

                                                                Можете себе представить качество его работы;)

                                                                Другой пример: Idea позволяет сделать томкат или джетти конфигурацию и запускать ее.

                                                                И в мавене можно сделать. Но синхронизации тут никакой нет.
                                                                И там и там надо делать ручками.
                                                                Ответить
                                                                • бля
                                                                  > msbuild и xcodebuild этих проблем лишены.
                                                                  дай угадаю, потому что они работают с файлом проекта конкретной ide?

                                                                  ты предлагаешь жидбрейнсу всему ынтерпрайзному миру навязать свои форматы файлов проектов? что делать тем, кому мил нетбинс или кому нравится эклипс?
                                                                  писать адаптер к sln и proj файлам, как это вынуждены делать жалкие конкуренты ide под винду и макось?

                                                                  > И там и там надо делать ручками.
                                                                  даже мне понятно, что томкат у каждого разраба свой, даже версии могут быть разными, а на тестовом и прод сервере свои конфигурации, зачем это вообще тащить через идею и мавен?
                                                                  Ответить
                                                                  • >>дай угадаю, потому что они работают с файлом проекта конкретной ide?

                                                                    именно так

                                                                    потому там не бывает так, что локально все работает, а на CI ёбнулось

                                                                    а в Intellij сплошь и рядом такое
                                                                    Ответить
                                                                    • С чего бы это? В sln / .*proj очень даже легко добавить что-то зависящее от конкретного компьютера на котором разработчик последний раз сохранил свой проект. Принимая во внимание то, что, например, МСВС автоматически форматирует и редактирует файлы .*proj, и то, что их нельзя в той же студии редактировать пока проект открыт - разработчики ленятся / не смотрят на то, что в этих файлах происходит.

                                                                      Что да происходит: проекты в МСВС обычно тривиальные, а задачи автоматизации перекладываются на что-то другое. Что вобщем-то и правильно, т.как МСБилд - очень ограниченый и не подходит для автоматизации. С одной стороны программистам легче компилировать свой код, а с другой - если им нужно работать с готовым продуктом, тестами или какими-то другими аспектами инфраструктуры, то тут они проиграют.
                                                                      Ответить
                                                                • > Добавил папку сырцов, и она сразу "посинела".

                                                                  С мавеном аналогично.

                                                                  > И в мавене можно сделать. Но синхронизации тут никакой нет.

                                                                  В идее можно запускать произвольный мавеновский таргет. Не нужно ничего дублировать.
                                                                  Ответить
                                                                  • точно так же можно запускать его в консоли

                                                                    произвольный таргет для тестов не нарисует слева деревце

                                                                    произвольный таргет для тмоката не будет иметь кнопку "перезапустить"
                                                                    итд
                                                                    Ответить
                                                        • @see https://www.jetbrains.com/help/idea/2016.1/maven.html?origin=old_help
                                                          Ответить
                                                  • >что мы все дружно согласимся, что Apple 1:0 гетеросексуализм?
                                                    да нет никаких профитов. Просто яббл анально огорожен и все остальное либо вызовет еще большую боль
                                                    Ответить
                                  • >>objc сразу в нативный код.
                                    строго говорят не совсем так

                                    сначала он идет в llvm, затем в нативный код под ARM (в случае девайсов) или под x86 (в случае эмулятора)

                                    Но пользователю этого не заметно
                                    Ответить
                                    • Нестрого говоря, пох. VM же нет?
                                      Ответить
                                      • да, исполняемые файлы (mach executable) содержат код прямо под ISA железного процессора
                                        Ответить
                          • И вообще, разве Scala каким-то образом запрещает писать код как на жабе? По-твоему там есть какая-то принудительная функциональнгая чистота как в хачкелях, чтоб без сайд эффектов? Насколько я вижу, ничерта такого там нет, объекты там вполне изменяемые
                            Ответить
                            • Она гораздо сложнее,чем дотнет с линком. Вот что я о ней помню. Алсо, тогда с IDE под нее все еще было плохо, не знаю, как сейчас.
                              Ответить
                  • >Аргумент про про "склонированное" вообще прекрасен! Что там склонировано? Идея виртуальной машины? Идея ГЦ?
                    Дело в том, что M$ создали свою жабу(реализацию JVM (MSJVM) ), но Sun (светлая ему память) засудил их.
                    http://i72.narod.ru/humor/revolution.htm
                    Сейчас идея и там и там в некоей единой среде, в рамках которой поддерживается куча языков. Например в дотнетах это C# F# VB.Net C++/CLI и что там у них еще за херня, у JVM есть Java Scala Kotlin Groovy Ceylon... и там и там из одного языка можно использовать методы/функции другого. Другие "среды" не такие многоязычные. Вот например есть JavaScript и какой-нибудь Erlang, и тебе надо из ерланка дергать какую-то жабаскриптохуйню и наоборот, а работают они в разных виртуальных средах, и все это будет добавлять тормозов, если надо пересылать какие-то массивы байтов из одного рантайма в другой, какие-то SHM костыли городить, или пропихивать байтики через именованные каналы, Unix domain socket и так далее. А если у тебя жаба или дотнет хуйня есть, там все говноязычки варятся в одном котле, и они меж собой может легко коммуницировать без всяких ебаных костылей.

                    Кроме того, вспомните этот Windows Phone. M$ видимо посмотрела на эти андроиды с жабой и задумалась: так ведь у меня тоже своя жаба есть - дотнет. Сделаю-ка я телефоны с дотнетами, вот заебись будет. Только хуй там.

                    >Все современные ОС, в таком случае, склонированы с OS360.
                    Если современная ОС это значит "ОС, использующая концепции, заложенные в OS360" то вполне.

                    >Ты напоминаешь мне пубертатного кулхацкора, который в журнале "хакер" прочитал что "виндуос это не круто" и теперь обливает говном любой МС продукт просто потому, что это МС
                    Заshitников майкрософта я тоже много наслушался, уж поверь мне. Есть за что обливать.
                    Ответить
                    • >Сейчас идея и там и там в некоей единой среде, в рамках которой поддерживается куча языков. Например в дотнетах это C# F# VB.Net C++/CLI и что там у них еще за херня, у JVM есть Java Scala Kotlin Groovy Ceylon... и там и там из одного языка можно использовать методы/функции другого. Другие "среды" не такие многоязычные.

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

                      http://fprog.ru/2010/issue6/interview-simon-peyton-jones/

                      — Говоря о практическом применении исследований, связанных с Haskell, как Вы можете прокомментировать неудачную, в конечном итоге, попытку внедрения Software Transactional Memory в C#?

                      Саймон: Я не участвовал в принятии решения о невнедрении. В моём понимании, рантайм .NET — большой и сложный зверь. Чтобы добавить транзакционную память, они пытались решить задачи гораздо сложнее тех, с которыми столкнулись мы в Haskell STM, где побочные эффекты являются не правилом, а исключением. Они работали с рантаймом, для которого побочные эффекты не являются исключением. И поскольку побочные эффекты должны отслеживаться системой транзакционной памяти и такое отслеживание является дорогой операцией, их исходная позиция была менее выгодна. Они собирались внедрить и многие другие сложные сущности, такие как открытые вложенные транзакции, а также модификацию адресов памяти как внутри транзакции, так и снаружи. В Haskell STM переменные делятся на два класса. Переменные класса TVar могут быть изменены внутри транзакции, но не снаружи. Переменные класса IORef могут изменяться снаружи, но не внутри.
                      Ответить
                      • >>К слову сказать, эта идея тоже говно по своей сути

                        олол, ты не поверишь но ISA любого CPU а так же любая VM (llvm, jvm, clr) строится именно на таких принципах

                        под x86 ты можешь писать на С а можешь на паскале
                        и вызывать функции, написанные на другом языке

                        правда же x86 говно?
                        Ответить
                        • >олол, ты не поверишь но ISA любого CPU
                          Не любого
                          https://en.wikipedia.org/wiki/Dataflow_architecture
                          https://habrahabr.ru/post/122479/

                          Вот например есть процессор Мультиклет на который этот LLVM плохо ложиться.
                          https://habrahabr.ru/post/209732/#comment_8710245

                          >а так же любая VM
                          Не любая

                          >x86 говно
                          Да, говно
                          Ответить
                          • ок, я понял

                            x86 говно и .NET говно потому, что позволяет писать под себя на разных ЯП.

                            Вопросов больше нет
                            Ответить
                            • >x86 говно и .NET говно потому, что позволяет писать под себя на разных ЯП.
                              Нет, понял ты неправильно. Одни среды заточены под одну парадигму, другие под другую. Например, вышеупомянутая dataflow architecture(есть аппаратные реализации) лучше ложится на функциональную парадигму, чем на всякую императивщину.

                              Еще раз процитирую, может быть до тебя дойдет:
                              В моём понимании, рантайм .NET — большой и сложный зверь. Чтобы добавить транзакционную память, они пытались решить задачи гораздо сложнее тех, с которыми столкнулись мы в Haskell STM, где побочные эффекты являются не правилом, а исключением. Они работали с рантаймом, для которого побочные эффекты не являются исключением. И поскольку побочные эффекты должны отслеживаться системой транзакционной памяти и такое отслеживание является дорогой операцией, их исходная позиция была менее выгодна.

                              У хачкеля есть свой рантайм, отличный от рантайма .NET, в нем есть свои особые механизмы и сборщик мусора, конкретно заточенные под эту функциональную парадигму, абстрагируясь таким образом от императивного ассемблера x86. А если б был некий процессор, который специально спроектирован для поддержки функциональщины, с какой-нибудь встроенной на аппаратном уровне сборкой мусора и этими dataflow, хачкель работал бы на нем эффективнее. Хачкель можно при желании и в брейнфак скомпилировать, но работать это будет через одно место и с тормозами
                              Ответить
                    • >Сделаю-ка я телефоны с дотнетами, вот заебись будет. Только хуй там.
                      Хуй из-за венды на телефоне. C# живет на андроиде в виде ксамарина.
                      Ответить
                    • >>Дело в том, что M$ создали свою жабу(реализацию JVM (MSJVM) ), но Sun (светлая ему память) засудил их.


                      и дальше что ? причем тут .NET?

                      >>Сейчас идея и там
                      зачем вот эта вся шизофазия дальше?

                      >>"ОС, использующая концепции, заложенные в OS360" то вполне.
                      таком образом все ОС говно, ок

                      >>Заshitников майкрософта
                      MS есть за что критиковать, но ты не назвал ни одного аргумента кроме невнятного блекотания про "клоны".
                      Ответить
                      • >и дальше что ? причем тут .NET?
                        Ну они попробовали к Java применить свой прием embrace, extend and extinguish, только их обломали, и они решили сделать свою Java, только лучше. Получился .NET

                        >зачем вот эта вся шизофазия дальше?
                        Это и есть общая идея

                        >таком образом все ОС говно, ок
                        Нет. Скорее уж говно это твои представления о том, что считать современной ОС

                        >MS есть за что критиковать, но ты не назвал ни одного аргумента кроме невнятного блекотания про "клоны".
                        А ты вот думаешь что я тут поставил себе цель максимально раскритиковать M$? Или ты отрицаешь, что .NET задумывался именно как конкурент Java, когда Sun обломал их с этим Visual J++?
                        Ответить
                        • >>Ну они попробовали к Java применить свой прием embrace, extend and extinguish, только их обломали, и они решили сделать свою Java, только лучше. Получился .NET

                          И что дальше? Это типа минус дотнета такой?

                          А Linux клон UNIX, и потому тоже говно?

                          >>А ты вот думаешь что я тут поставил себе цель максимально раскритиковать M$?

                          нет, я думаю что ты ничерта не разбираешься ни в .NET ни в C#, и что ты не смог пока привести ни одного аргумента кроме того что "это майкрософт, их обламали с джавой и они сделали C#".
                          Ответить
                          • >И что дальше? Это типа минус дотнета такой?
                            Нет, минус заключается не в этом. Где вообще ты нашел утверждение "если клон то говно"?

                            >А Linux клон UNIX, и потому тоже говно?
                            У UNIX хватает недостатков и Linux все эти недостатки наследует. Говно там есть несомненно

                            >ни одного аргумента кроме того что "это майкрософт, их обламали с джавой и они сделали C#".
                            Я тебе приводил аргументы, только ты и предпочел игнорировать. Отсутствие динамической компиляции и профилизование как в HotSpot. .NET нихрена не кроссплатформенный, в отличии от Java, которую (J2ME) до сих пор пихают в телефоны(не смартфоны), мидлеты всякие. Java Card может даже выполняться в SIM картах, ничерта такого про сишарп я не слышал. Вообще, основная проблема дотнета лично для меня в том, что это все заточено под винду.

                            Могу еще:
                            Отсутствие в Mono херни, связанной с WPF а также привязка этого WPF к DirectX которого нигде нет кроме как в винде(в вайне какая-то костыльная багнутая эмуляция, это не в счет) http://www.mono-project.com/docs/about-mono/compatibility/ - вот более подробно о неполной совместимости. Winforms в mono тоже багнутый.

                            Если говорить про винду, то: необходимость держать дохера версий .NET framework в винде, если часть софта хочет один дотнет, другая часть - другой (ну т.е. им насрать на обратную совместимость. Вот лучше поставьте побольше версий дотнетов, хули там, гигом меньше гигом больше, не в 70 же живем). Сам дотнет отжирает дохрена памяти, и дохрена места на жестком диске(хотя это же касается и жабы, но мне почему-то не надо кучу разных версий Java ставить, а для дотнета надо), программы под Java и .NET обычно работают медленней и требуют больше памяти, чем С/С++/Objective-C etc. Проблемы с реалтаймовостью у всех этих языков с GC, отчего даже придумали специальные GC для Java чтобы в реальном времени кое-как работало(интересно, есть ли такое для .NET). А, ну и еще потеря производительности из-за проверки границ массивов(хотя там есть всякие unsafe но ими обычно не пользуются)
                            Ответить
                            • >.NET нихрена не кроссплатформенный, в отличии от Java,
                              Один недостаток, хотя есть уже указанные моно и ксамарин.
                              J2Me формально может и жава, а фактически - сильно порезанное подмножество, про Java Card вообще молчу, блядь, там от жавы одно название, гц нет. Что сложнее - изучить язык похожий на тот который знаешь, или изучить с нуля стек библиотек?
                              Неполная эмуляция дотнета в моно (на самом деле - почти все кроме гуя).
                              Дальше?

                              >необходимость держать дохера версий .NET framework в винде
                              Тебя что смущает? 100-200 метров места? Гигом? Хуй тебе, я оффлайновые инсталляторы качал. У тебя SSD на 32 гига, что ты шипишь-то? В семерве фреймверки прилетают вообще с апдейтами.

                              >программы под Java и .NET обычно работают медленней и требуют больше памяти, чем С/С++/Objective-C etc.
                              И отзывчивость меньше, и стартуют дольше. Но вся эта радость до первого сегфолта.

                              Реальные недостатки будут еще?
                              Ответить
                              • Блядский рот, нет "лучшего" языка программирования. Шарп создавался с оглядкой на безопасность, плюсы - на скорость. Логично что движок для игр на шарпе ты писать не будешь, но и лишний раз бизнес приложение на крестах писать не станешь. Все зависит от конкретной задачи.
                                Ответить
                                • Бггг... Уже не первый год Unity в тренде. Понятно, что только начало, но реально и игры проще писать на шарпе. А если взлетит, тогда уже можно на плюсах переписать. Да и то не всё, а только 2-3 процента критичного кода.
                                  Ответить
                                  • >> Бггг... Уже не первый год Unity в тренде
                                    У него кишки на плюсах написаны, так-то
                                    Ответить
                                    • Ну ёп вашу мать! У дотнета кишки тоже на плюсах написаны! Компиляторы испокон веков пишутся если не не сях, то на плюсах. Интерпретатор пхп тоже на плюсах написан. Про JS с его адовой оптимизацией вообще молчу. Компилятор плюсов и библиотеки плюсов на каком языке написаны? Правильно!
                                      Ответить
                                      • >> Компиляторы испокон веков пишутся если не не сях, то на плюсах.

                                        о чем я, блеать, и говорю!
                                        Ответить
                                      • Феноменальный пиздеж. Компиляторы пишутся на чем угодно, но на Си / С++ - относительно не часто. Большинство компилируемых языков пишет компилятор на том же языке, в который компилируется. Первые компиляторы были чем-то вроде Meta2, т.е. BNF с минимальным набором функций, которые нужно было реализовать на Ассемблере.
                                        Компиляторы Явы - написаны на Яве (Oracl, OpenJDK, IBM, Google) и на Си (jcc - которым никто не пользуется).
                                        Компиляторы JVM языков: Groovy - смесь Java + Groovy, Scala - Scala, Clojure - Java.
                                        Разные Лиспы: как правило на Лиспе (SBCL, CCL, Allegro, Racket) + минимальный бустрап на Си.
                                        Прологи: SWI - Пролог + минимальный бустрап на Си. Mercury - Mercury.
                                        Компилятор Haskell, OCaml, Rust, Go, Pascal, Ada написаны на Haskell (оба), OCaml (с десяток), Rust, Go (один из двух, оффициальный), Pascal (все, на сколько мне известно), Ada.

                                        Недавно видел объявление по найму: искали программистя писать компилятор Сиквела на Хаскеле.

                                        Есть еще курьезные ситуации. Например, компилятор ActionScript написан на Яве. Компилятор HaXe написан на OCaml. Есть PyPy (компилятор Питона на Питоне). TypeScript - JavaScript, CoffeeScript - CoffeeScript.

                                        Большинство существующих компиляторов написаны не на Си / С++.
                                        Ответить
                                        • > пишет компилятор на том же языке
                                          Кстати, сейчас есть возможность честно скомпилировать компилятор таких языков?

                                          Скажем, рассматриваю язык X с компилятором на X, нахожу нормальную версию исходников компилятора на каком-то другом языке Y (причём Y не зависит от X), чей компилятор у меня запустится (т.е. актуален, а не написан в стародавние времена под железо авторов C; ну или хотя бы на какой-нибудь реально существующей машине запустится), компилирую нормальную версию компилятора X, потом ей компилирую "циклическую" версию компилятора X.
                                          Ответить
                                          • Как правило: да. Типично проблема сводится к бутстрапу небольшой / платформозависимой части компилятора (десяток функций), которые пишутся либо на ассемблере, либо на чем-то, что автор верит должно присутствовать в системе (Си должен быть в ЮНИКСе, например). После чего, бутстрап код используется для того, чтобы создать компилятор-компилятор, типа OMeta, YACC, и т.д. - программа с минимальным, фиксированым набором функций способная генерировать код. Дальше эта программа уже собирает настоящий компилятор, котороый уже собирает стандартную библиотеку языка, утилиты и т.д.

                                            ЗЫ. Си / С++ вообще малопригодны для написания компиляторов. Код компиляторов "написаных на Си / С++" как правило не написан на Си / С++, а на чем-то типа YACC. Си, выбриается в качестве целевого языка YACC как правило в виду распространенности, а не потому что он как-то лучше приспособлен для таких задач.
                                            Ответить
                                            • а как же оптимизация? все таки на с можно написать более компактный код чем на жабе, разве нет?

                                              Логично, что YACC, BISON и всякие COCO\r имеют место быть, ибо писать весь этот код самому нудно, долго и, что самое важное, черевато ошибками
                                              Ответить
                                              • Оптимизация размера компилятора находится на хз-каком месте в списке приоритетных задач при написании компилятора. Для компилятора главное: корректность, скорость сгенерированого кода, расширяемость, быстрота генерации. Даже если компилятор на Яве будет в десять раз больше компилятора на Си (хотя и не понятно по каким причинам), то это, скорее всего, останется в большинстве случаев никем не замеченым.
                                                Ответить
                                            • На YACCе реализуется только парсер с описанием на BNF
                                              Это примерно 5% того, из чего состоит компилятор

                                              и дело тут не в си: ты думаешь что на джаве парсер с нуля руками написан?
                                              Ответить
                                              • только слабый духом падаван возьмёт yacc/bison вместо прельстивого boost.spirit
                                                Ответить
                                                • ладно, lex то можно?
                                                  Ответить
                                                • А я люблю обмазываться boost::spirit и компилять. На одно маленькое изменение в грамматике уходит целый час компиляния на i7. Зато, когда билд падает с ошибкой…ммм он вываливает в консоль сообщения об ошибках в десятиуровневых шаблонах. Я разбираю их, представляя, что меня поглотил единый организм питух. Мне вообще кажется, что тьюринг-полные шаблоны, умеют думать, у них есть свои семьи, города, чувства, не смывайте сообщения об ошибках boost в /dev/null, лучше приютите у себя, говорите с ними, ласкайте их…. А вчера в ванной, мне преснился чудный сон, как будто я нырнул в море, и оно прератилось в метапрограммирование, рыбы, водоросли, медузы, все из шаблонов, даже небо, даже Аллах!.
                                                  Ответить
                                        • Насчёт жавы, ты, мягко говоря, не прав. Современный энвайрмент не позволит в настолько массовом продакшене копмилятор на Java. Ибо буст даже в 10% будет влиять на конкуренцию. HotSpot JVM состоит не менее чем из 250к строк c/c++. Курить здесь: http://openjdk.java.net/groups/hotspot/
                                          Ответить
                                          • kerman, есть компилятор жавы в байткод, есть jit компилятор байткода в нативный код. HotSpot второе.
                                            Ответить
                                        • >Компиляторы Явы - написаны на Яве
                                          Компилятор жавы в байткод - хуйня на постном масле. Вся мощь в jit, а он на c(++)
                                          Ответить
                              • > 100-200 метров места? Гигом?

                                А про директорию assembly, куда срёт NGEN и в которой хранится по несколько нативных сборок для каждой DLL (причём все сборки, кроме самой свежей, не нужны), все забыли...
                                Ответить
                                • Не то, что забыл - не знал :) У меня 1,4Гб.
                                  А что там хранится? Нативный код фреймверка или внешних программ?
                                  Ответить
                            • Этот блядский дотнет ещё и легко декомпилируется без обфускации.

                              Херня аргументы. Дохрена памяти дотнет отжирает, если памятью пользоваться слишком сильно. Вообще GC дотнета лучший из управляемых. Понятно, что если ты потратишь десять лет на оптимизацию крестовой программы, то она будет быстрее и меньше памяти жрать, чем дотнетовская. Только нахуй она нужна через 10 лет?
                              Ответить
                            • >>>программы под Java и .NET обычно работают медленней и требуют больше памяти, чем С/С

                              Программы на чем угодно часто работают медленее (иногда на 0.0001%) и требуют больше памяти (иногда на 10 мегабайт больше) чем программы на си

                              итого: ничего кроме си не нужно.

                              Пиздец. Школьники так рассуждают "джава тормозит -- джава ни нужна".
                              Ответить
                              • >джава тормозит
                                Гуй на джаве на старом компе может тупить. А где она еще подтормаживает?
                                Ответить
                                • ЯП не может подтормаживать

                                  могут подтормаживать конкретные реализации конкретных алгоритмов на конкретном железе

                                  Если человек говорит "язык $LANG тормозит" то перед нами не программист, а ламер
                                  Ответить
                                  • Если ты на языке не только helloworld писать собрался, то он вполне может тормозить.

                                    >могут подтормаживать конкретные реализации конкретных алгоритмов на конкретном железе
                                    Без этих реализаций язык не нужен, а лучшей альтернативы может не быть.
                                    Ответить
                                    • что такое "язык тормозит"?

                                      Вообще нет понятия "тормозит", нужно говорить о нехватке конкретного ресурса (памяти, IO, CPU) на конкретном железе

                                      а то я сейчас напишу алогоритм с O(N!) на си и запущу ее на 286, и скажу что си тормозит
                                      Ответить
                                      • Месье философ?
                                        Можно почти на любом языке написать медленный код, можно для любого языка написать быстрый интерпретатор/компилятор, но в реальности есть какие-то средние выходные характеристики, определяемые порогом вхождения, существующими инструментами, популярностью, характерными задачами и т.п.
                                        Языков программирования не существует. Языков в чистом виде нет. Есть только парсеры, трансляторы и наши представления. Всё, что связано с языками - это наши впечатления от работы компиляторов и программ. Смысла нет говорить о несуществующих математических абстракциях. Есть смысл говорить о существующих программных и аппаратных решениях.
                                        Потому проще и логичнее сказать, что язык X тормозит, а Y - нет, потому что у X низкий порог вхождения, а у Y - высокий, а ещё и компилятор вылизанный.
                                        Или давайте, обучите программистов, а также напишите оптимальные инструменты.
                                        Ответить
                                        • интересно

                                          а какой язык быстрее: C, асемблер, C++ или pascal?
                                          Ответить
                                          • Я бы сказал, что C быстрее. Автоматика развилась, люди пошли напитон, ассемблер стал медленнее.

                                            Кстати, вспомним, что язык (именно та математическая абстракция) накладывает свои ограничения на мышление, направляет мысль что ли. Возьмём jQuery как такой язык (думаю, вполне можно считать это отдельным языком). document.getElementById('pitux') - долгая операция поиска в DOM, лучше не вызывать часто; $('#pituh') - простая и удобная магия, вызови её ещё раз, и ещё, и ещё.
                                            Ответить
                                      • Ты до всего решил доебаться? www, перелогинься.
                                        Ответить
                  • > CLR конечно же круче JVM

                    А что насчёт Parrot? В Parrot можно добавлять опкоды с помощью динамических библиотек:
                    http://docs.parrot.org/parrot/latest/html/ops.html
                    Ответить
                    • parrot наверное хорош, я с ним глубоко не работал

                      вот llvm хорош: это _регистровая_ виртуальная машина (такое редко бывает, поравда?) но регистры там можно добавлять на лету


                      во всяком случае у apple она отлично работает, и шланг умеет c/c++/objc из нее
                      Ответить
                  • >C# конечно же на голову круче Джавы по выразительности: там есть куча всего: от async до вывода типов.

                    А ну-ка расскажи поподробнее. Интересно послушать.

                    >Аргумент про про "склонированное" вообще прекрасен! Что там склонировано? Идея виртуальной машины? Идея ГЦ?

                    Детали реализации, подходы к разработке. java-специфичные уши торчат тут и там.
                    Типа Math.abs в c# возвращает signed (в жабе других нету).
                    Ответить
                    • Math.abs в c# возвращает signed потому, что в жабе других нету? Оригинально.
                      Ответить
                    • >>CLRом пользуются только идиоты. Нужно писать на прологе.
                      >А ну-ка расскажи поподробнее. Интересно послушать.

                      тебя в гугле забанили? Почитай про ключевое слово var в C#.
                      Если ты не знаешь что такое "вывод типов" то википедия тебе в помощь

                      Сайт ебаных дремучих ламеров блядь
                      Ответить
                      • >> до вывода типов.
                        >А ну-ка расскажи поподробнее. Интересно послушать.

                        тебя в гугле забанили? Почитай про ключевое слово var в C#.
                        Если ты не знаешь что такое "вывод типов" то википедия тебе в помощь

                        Сайт ебаных дремучих ламеров блядь
                        Ответить
                • А я знаю откуда такой бред берется. У адептов Майкрософта есть пионэрские слеты евангелистов, где им рассказывают о том, как это самый замечательный язык, при этом всегда бездоказательно, и без каких-либо сравнений с чем-либо другим. Эти евангелисты очень еще любят ходить по всякого рода учебным заведениям и устраивать политинформации долбоебам преподавателям. После чего долбоебы преподаватели, которые ничего до этого кроме псевдопаскаля не видели, пишут бумаги в мин. образования, где говорят, что С# - это самый лучший и модный язык, и его надо учить всем детям восьми годов отроду и старше.

                  Со стороны это похоже на смесь гербалайфа и комсомола.

                  Что происходит потом: студенты выпускаются. Часть, конечно пойдет работать в другие конторы, которые уже уверовали в целительную силу Майкрософта, а часть которая захочет сделать по-новому и правильно - выберет, естесственно, самые лучшие технологии Майкрософта для своего стартапа. Пройдет лет десять, и бывшие стартаперы поймут, что выбор может быть был не самым удачным, но менять все теперь уже очень дорого.
                  Ответить
                  • бля, точнее и не скажешь

                    я хорошо помню как в году эдак 04-05 к нам в вуз тоже приходили мальчики с одинаковыми прическами и галстуками, рассказывать какое дотнет охуительное изобретение, всучали брошюрки и кепки, покупайте нашу поебень, и вот уже почти готов процессор, исполняющий IL напрямую

                    одному так засрали мозги, что он с тех пор только на с# и пишет
                    Ответить
                    • Почитал я тут про АОП и шарп - так вот, нет в шарпе АОПа и хрен когда оно там будет. Майкрософт считает что нинужно, сторонние дяди мутятся через написание проксей обьектов через рефлексию (что роняет производительность на пол) или вбивания кусков кода непосредственно в cil на этапе компиляции, что реализовано плохо, дорого и "срезы только в избранных местах". Ну и некоторые предлагают пойти и написать свой компилятор со всеми прелестями. Пичаль - тоска. В итоге все сводиться к тому, что написать сниппеты в решарпере и вдолбить из во все методы проще. Майкрософт - мы любим индусов
                      Ответить
                      • а безопасность на ресты в asp.net mvc как накручивается?
                        кто проверяет, что вот этому принципалу можно дёргать вот этот рест?
                        Ответить
                        • Ну так токен сервером при каждом обращении проверяется. если токен невалиден но клиент идет повторно на авторизацию.

                          Или я не понял вопроса?
                          Ответить
                          • токен валиден, но я пытаюсь отредактировать чужой личный кабинет
                            или я юзер, а лезу в админские ресты
                            Ответить
                            • Фильтр аутентификации на сервере ловит токен и стучится к OAuth . Тот обрабатывает токен и возвращает восстановленный по токену объект claims identity или типа того. Потом фильтр авторизации смотрит, хватает ли прав у этого объекта на эту операцию, если да - норм, если нет - идите нах
                              Ответить
                              • Т.е. фильтр авторизации это такой god object, который знает про все-все-все объекты, к которым может быть доступ?

                                Или всё-таки можно несколько фильтров с разными зонами ответственности?
                                Ответить
                        • >а безопасность на ресты в asp.net mvc как накручивается?
                          АОП не панацея. Тем более в данном конкретном случае.

                          В жабе испокон веков (до модных анотаций и jersey/spring rest) юзали javax/servlet/Filter.
                          Думаю в ASP.net так же можно зафигачить.
                          Ответить
                      • Пардон, в жаве AOP реализуется сторонней библиотекой. Причем тут майкрософт? Или ты привык что тебе мс жопу вытирает?
                        Ответить
                        • скинь ссылку на такую библиотеку на шарпе
                          Ответить
                          • https://www.postsharp.net/
                            Ответить
                            • А теперь
                              1. расскажи как вставить срез в любое место кода
                              2. оплати мне лицензию в 630 бакинских
                              Ответить
                              • ты выбрал c#
                                поэтому должен платить и каяться платить и каяться
                                Ответить
                              • 1. почитай мануал, вставить можно на любой вызов метода
                                2. извини чувак, около микрософтовые техн0логии редко бывают бесплатными

                                ты сам C# выбрал
                                Ответить
                                • Но нельзя в любое место кода. А вдруг я хочу в серединку, а?

                                  И вообще, какого х!!! ты отвечаешь, если я жду. что пидар выдаст что то интересное и тупое, как

                                  3_14dar в http://govnokod.ru/19903#comment325322 написал:
                                  >> жаве AOP реализуется сторонней библиотекой
                                  Ответить
                                  • зачем в серединку
                                    аоп обычно работает по принципу "обвесить"
                                    Ответить
                                  • а как ты правила опишешь? "на семь строчек ниже объявления переменной foo"?
                                    Ответить
                                    • специальным синтаксисом

                                      бла бла бла
                                      <DoSomeJob>
                                      бла бла бла
                                      Ответить
                                      • тогда зочем тебе AOP?
                                        Ответить
                                        • зачем тогда вообще AOP?
                                          Ответить
                                          • Представь что у тебя есть интерфейс FooService с десятком методов. Ты хочешь логировать все обращения к нему. А так же хочешь не пускать туда неавторизированных пользователей.

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

                                            Это лучше чем в начале каждого метода писать одинаковый код
                                            Ответить
                                            • а чем тебе не нравится такое?

                                              бла бла бла
                                              <DoSomeJob>
                                              бла бла бла

                                              привязываем код на DoSomeJob и втыкаем куда хотим в любые методы. Можно гибко перенастроить в процессе выполнения, привязав другой код
                                              Ответить
                                            • А если просто декоратор налепить?
                                              Ответить
                                              • Заебешься на все классы декораторы лепить

                                                даже простое логирование выльется в работу на несколько дней - создай им всем декораторов. А так еще и кеширование. и еще что нибудь добавится - вообще пиздец. Бизнес логики на 2 строки и 10 декораторов сверху
                                                Ответить
                                                • Для контроля доступа декораторы - самое то, ибо тебе надо для каждого метода права проверять.
                                                  Ответить
                                                  • https://ideone.com/alN5sz

                                                    офигенно, не правда ли?

                                                    А теперь представь что так нужно к каждому классу написать
                                                    Ответить
                                                    • Бля, ты знаешь что такое аннотации или декораторы?
                                                      Ответить
                                                      • https://ru.wikipedia.org/wiki/Декоратор_(шаблон_проектирования)
                                                        Ответить
                                                        • @decorator в питоне. В жавке вроде называются аннотациями.

                                                          А вообще иди нахуй. Нехуй тебе что-то объяснять.
                                                          Ответить
                                                          • А теперь вопрос - какого хуя ты пишешь про питоновкие @decorator, которые есть только в питоне, при обсуждении АОП на шарпе?
                                                            Ответить
                                                    • блин
                                                      смысл АОПа в том что ты описываешь нечто не в вызываемом коде, а сам код про это ничего не знает
                                                      Ответить
                                  • В джаве AOPы бывают разные

                                    Есть AspectJ, есть Spring. Синтаксис одинаков.
                                    Spring умеет интроспектить создаваемые им бины, AspectJ умеет патчиить байткод, а умеет и ставиться агентом к джаве и править на лету
                                    Ответить
                                  • Что тебе непонятно, мудень? Импорты писать надо? Или она в стандартную библиотеку встроена?

                                    Иди нахуй, нахуй тебе что-то объяснять чтобы потом ты еще помои лил.
                                    Ответить
                              • 2. Чувак, я с утра эту тему изучал. Там есть бесплатная версия с АОП.
                                Ответить
                          • Майкрософт тут причем?
                            Ответить
                  • Ты написал тонну хуйни без единого довода, браво
                    Ответить
                    • Первый раз www читаешь?
                      Ответить
                      • не в первый, и каждый раз он пиздит как неграмотный 17ти летний красноглазик.

                        --кококо, ворд нистандартизирован
                        --вот же тебе спека docx
                        --кокок, я говорил про doc

                        --сишарп говно
                        --почему говно?
                        --потому что микрософт говно, кококо

                        --гимп лучше фотошопа
                        --чем лучше?
                        --тем что бесплатный

                        и такого ЛОРобразного дерьма из него вываливается вагон и маленькая тележка
                        Ответить
                        • Я за ним заметил, что на любой говновопрос он напишет комент на 1950 символов из 2000 допустимых (кто-то статистику делал) с заумными словечками.
                          Ответить
                          • То что вы не понимаете о чём трёт wvxvw, не означает что он неправ.

                            Сравнивая его опыт и образованность, с твоим вопиющим неосиляторством... Ну это как сравнить Германию с усраиной.
                            В большинстве случаев wvxvw говорит очень дельно.
                            Ответить
                            • конечно же миллионы компаний в мире, выбравшие C# и Java (включая гугл и яндекс и дойчебанк) просто не осилили

                              а один wvwvwvw со своим прологом осилил

                              это приверно как сравнивать нормальную страну в ватностаном
                              Ответить
                              • не в, а на, хлопчик
                                Ответить
                              • А че ты смеешься? Популярны те языки, что доступны большинству. Пролог непопулярен потому что сложен. Логично, если язык сложен, то на нем мало кто пишет, вносят мало новых фич и техов мало и либ мало и язык не развивается.
                                Ответить
                            • Только его никто не понимает. Эдакий непризнанный гений. Докажет 2+2=4 через тензоры, а никто даже спасибо не скажет.

                              Кстати, 3.14159265, иди нахуй, 3.14159265!
                              Ответить
                  • Вот давайте конкретно и по пунктам, в порядке убывания важности - чем c# хужее жавы?
                    Ответить
                    • Это ко мне вопрос? Я как бы в сортах говна... Они оба бесперспективные направления в программировании. Живут в мире искаженной реальности, где люди обсуждают какие-то плюсы и минусы чего-то, что построено на заведомо неустойчивом фундаменте. Кто из них кого переобсуждает - мне как-то лень следить и разбираться. Это как арабо-израильский конфликт: тут пидарасы и там пидарасы, но новости только и ждут когда те пидарасы этими пидарасами наваляют - публика заангажирована.
                      Ответить
                      • Ко всем.

                        > Я как бы в сортах говна... Они оба бесперспективные направления в программировании.
                        Ыыыыы :) Нахуй.

                        Не знаю какие это направления, но настоящее у них вполне есть.

                        Кстати, где больше градус - в украино-российских срачах или арабо-израильских?
                        Ответить
                      • хахахахаха, пиши больше!! особенно приятно послушать высеры про джаву, на которой примерно половина современного энтерпрайза написана, и примерно 80% современного мобильного софта

                        но крутому сис-админу из газеты конечно виднее что говно а что нет
                        Ответить
                      • > Они оба бесперспективные направления в программировании.
                        Они настолько, блядь, бесперспективные, что уже не первый десяток лет захватывают рынок и всё больше кода на них пишется. Шарп ещё молодой, а жава поглотила энтерпрайз сегмент чуть менее, чем полностью. И мобилки. И андроид в том числе. И ещё хуй знает что, ибо в каждом сегменте найдётся своя жаба.
                        Ответить
                        • Ну может он имел в виду, что через 30 лет на них мало кто писать будет.
                          Ответить
                        • Точно так же, как есть примерно в тысячу раз больше людей заинтересованых в арабо-израильском конфликте, чем участников. При чем, этим людям на самом деле абсолютно безразлично, чем этот конфликт закончится, т.как на них никак не повлияет, и тем не менее.

                          Есть много людей толкающих Яву, или .НЕТ. Не потому что языки хорошие, или потому что им от этого хорошо. Просто так исторически сложилось. Большинство людей занимающихся продвижением этих языков элементарно ничего не знают про другие языки / технологии. Обычно это дурачки-студенты, которые проработали в одной и той же среде с десяток лет, и решили, что их опыта теперь достаточно для того, чтобы составить мнение. Это люди без теоретической базы, без настоящего жизненного опыта, заменившие и то и другое коммерческими лозунгами.

                          Ну и почему энтерпрайз стал эталоном написания хорошего кода? Я проработал в HP Business Object (APS отделе). Это был мой единственный долгосрочный контакт с энтерпрайзом в качестве программиста. Кроме этого у меня есть долгая история знакомства с энтерпрайзным кодом Адоба (в качестве тестера). Я не заметил никаких преимуществ в качестве кода. Как раз наоборот: такой код, как правило, унылое однообразное говно. Примеры хорошего кода, который я встречал были, как правило написаны энтузиастами развивающими свой язык, иногда - преподавателями публикующими книги, иногда - реализации утилит, у которых есть множесто конкурентов (не типично для энтерпрайза), например, компиляторы регулярных выражений, реализация IP протокола и т.п.
                          Ответить
                          • Может, ты что-то лучше хочешь предложить?
                            Ответить
                          • лол))) ребята из Яндекса, например, выбирающие джаву, или ребята из гугла выбирающие Java и JVM для своего Dalvik (а в последствии ART) это просто неграмотные студенты которые конечно никаких других языков не знают


                            вот если бы был у них Великий Гуру из газетенки, который даже си не осилил, он бы рассказал им что настоящие продукты нужно писать на адобовском Кэшен Скрипте!
                            Ответить
                            • А ребята из вконтакта и фейсбука выбирают пхп, и что? Это значит что пхп автоматом становится мегаохуенным языком?
                              Ответить
                              • конечно не становится

                                достаточно посмотреть на сложность решений гугла и вконтакта чтобы понять что сравнивать их не нужно
                                Ответить
                              • Где-то была цитата людей из фейсбука, где они жалеют, что юзали рнр и пишут, что потихонечку переписывают код на другие языки, подсоединяя его как сервисы.
                                Ответить
                            • Ребята из Яндекса, Гугла и Фейсбука принимают решения исходя из экономических соображений. Рыночная экономика не продвигает самые качественные продукты, она продвигает продукты оптимизированые по нескольким критериям, таким как цена, разница между ценой и стоимостью, качество, популярность, исключительность, простота в производстве и в поддержке и т.д.

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

                              У энтерпрайза как правило нет цели написать очень качественную програму, т.как цена, время и требования к персоналу скорее всего окажутся коммерчески неадекватными. Вотличие от этого, программы, где качество играет большую роль будут писаться на других технологиях, и тут, например, не редкость увидеть что-то из ML/Miranda-подобных языков, или даже Лисп/Пролог.
                              Ответить
                              • А каким образом Лисп обеспечивает высокое качество кода? Я понимаю ML, понимаю, если бы там была Ада или ещё что-нибудь с заточкой на верифицируемость, но динамический пиздец для метапрограммирования как улучшает код?
                                Ответить
                                • В Лиспе есть очень серьезная система типов. Про динамический пиздец - это сказки неосиливхших разобраться в том, как и что проверяется. Инструменты проверок: ну, например, https://en.wikipedia.org/wiki/ACL2.
                                  Ответить
                                  • > Инструменты проверок: ну, например, https://en.wikipedia.org/wiki/ACL2

                                    Так эта штука не проверяет произвольные программы на CL, это просто очередной прувер. Как наличие прувера с CL-подобным синтаксисом помогает избегать ошибок (в том числе и в типах) в типичном CL-коде?
                                    Ответить
                                    • А кто говорит про произвольные программы на CL? Эта штука проверяет схемы / алгоиртмы изложеные в на специальном языке (этой программы), который случайно - Лисп.
                                      Ответить
                                  • Эта серьёзная система типов точно не относится к очередному умному DSL вместо самого лиспа?
                                    Ответить
                                    • Я хз. о каком ДСЛ речь. В Самом Лиспе система типов. Никаких ДСЛов.
                                      Ответить
                              • >>энтерпрайз
                                >>пролог
                                тьы болен
                                Ответить
                                • Ты просто работаешь в какой-то жопе, где никогда не будет никаких интересных задач. Всю жизнь видишь одно и то же говно, и думаешь, что у других так же :)
                                  Ну и кроме того, читать не умеешь. Речь про задачи требующие высокого качества, а не про энтерпрайз, где качество максимум среднее.
                                  Ответить
                                  • расскажи же мне об интересных продакшен задачах на прологе!
                                    Ответить
                                    • легкий гуглеж и .....

                                      быстрая разработка прототипов прикладных программ;
                                      автоматический перевод с одного языка на другой;
                                      создание естественно-языковых интерфейсов для существующих систем;
                                      символьные вычисления для решения уравнений, дифференцирования и интегрирования;
                                      проектирование динамических реляционных баз данных;
                                      экспертные системы и оболочки экспертных систем;
                                      автоматизированное управление производственными процессами;
                                      автоматическое доказательство теорем;
                                      полуавтоматическое составление расписаний;
                                      системы автоматизированного проектирования;
                                      базирующееся на знаниях программное обеспечение;
                                      организация сервера данных или, точнее, сервера знаний, к которому может обращаться клиентское приложение, написанное на каком-либо языке программирования.
                                      Ответить
                                      • быстрая разрабатка проторипов прикладныз программное обеспечение; ррганизация сервера данных или, точнее, сервера знариях программное обеспечение; ррганизация сервера данных или, точнее, сервера знаниях программное обеспечение; базирующееся нс знаний, к которому может рбращоться клиентское приложееии, написанное на каком-либо языке праграммное обеспечение; организация серверо данных или, точнее, сервира знаний, к котарому может обращаться клиентское приложееие, написанное на коклм-либо языке программированное на каком-либо языки программ; автоматизированного проектированного рроектированного проектированного проектированного проектироваеия; проектированного проектирование динамических вореционных баз данныз или, точние, сервера данных или, точнее, сервера знаниях программное обеспечение; орнанизация мервера данных или, точнее, сервира знаниях программное обиспечение; организация сервера данных; экспертных систем; символьные вычицления для решения уравнений, ворецирование динамических вореционных баз данних; экспертные системы автоматическое цоставление расписаний; системы автоматизирлванного проектиравание динамических вореционных баз данных; экспертных систем; символьныи вычисления ддя решения уравнений, ворецирования; проектиравания; проектирования и интегриравание динамических вореционных баз данних; экспертные систем; символьные вычисления для решения уравнений, воренцирования и интегриравания; базирующеися на знаний, к котарому может оюращарься клтентское приложение, написанное но каком-либо языке праграммное обеспечение; ррганизация серверо данных; экспертные мистемы автоматическое доказательства теорем; палуавтоматизированного проектирование динамических вореционных боз данных или, точнее, серверо данных; экспертные системы и оболоски экспертные систем; символьные вычицления для решиния уравнений, ворецирование динамических вореционнфх боз данных или, точнее, сирвира
                                        Ответить
                                      • это были вореции сейчас?
                                        Хочешь, я тебе такого же про Фортран накидаю? или про Кобол?

                                        Я тебе вопрос задал: в каких продакшен задачах сейчас он используется

                                        А ты мне рассказал для чего он создавался.

                                        Какие бля системы проектирования, какие сервера данных сейчас используют Пролог?
                                        Ответить
                                        • Тебе такие сервера не известны, т.как они разрабатывались для конкретных организаций, и название ни о чем тебе не скажет. Например, в контексте бизнес-обжект над которым я работал в ХП, одно из подразделений работало над базой знаний, которая в свою очередь использовала Сикстус.

                                          Меня, как простого программиста не особо посвящали в детали того кто именно заказчик. Все, что я знал, что установок было около десятка. На одном из собраний промелькнула новость о том, что Бритиш Эирвейз является нашим "новым стратегическим партнером", что значит, что мы им поставляли наши САП говнопрограммы. Вот, я так понимаю они там в Бритиш Эирвейз, например, и пользуются Прологом.

                                          Пример интересных задач, где используется Пролог: как язык запросов в графовых базах данных. Например в AllegroGraph. Другой пример: Пролог используется для парсинга и поиска закономерностей в ДНК (DNA-ChartParser).
                                          Ответить
                          • > Просто так исторически сложилось.
                            Заебись логика. Шарп и жава популярны, потому что их толкают те, кто нихуя не понимает, но так исторически сложилось.
                            То есть ты реально не понимаешь, почему эти языки стали популярными?
                            Ответить
                            • Ну не все что популярно всегда хорошо. рнр лучший пример. Но человечек забыл сказать, что же по его мнению лучше.
                              Ответить
                    • >2. извини чувак, около микрософтовые техн0логии редко бывают бесплатными
                      Это действительно так? Что на жаве бесплатно, на шарпе платно?
                      Ответить
                      • 1. Разработка. NetBeans бесплатен и работает на бесплатных ОС. Intellij тоже бесплатен в коммунити, а студия бесплатная хоть и есть, но требует платного Windows.

                        2. Сервер под веб. IIS требует Windows Server (ну для серьезных задач) а сервер стоит денег. tomcat (или jetty)@Linux бесплатен

                        Это так, сразу
                        Ответить
                        • Ну про платный виндовс это лол, только красноглазым студентам может печь. Другое дело, что экспресс студия - пиздец еще тот, а нормальная стоит денег намного побольше десктопной шинды, как и серверные версии.
                          IIS на десктоп вообще не ставится что ли?
                          Ответить
                          • ставится
                            с ограничением 10 одновременных клиентов
                            Ответить
                            • Как они считаются?
                              Небось все отключается одним ключиком в реестре?
                              Ответить
                              • нет
                                искусственные ограничения ОС
                                иначе все будут на виндовс 7 работать вместо гораздо более дорогого винсервера
                                Ответить
                                • >искусственные ограничения ОС
                                  Они раньше парой ключиков и отключались.
                                  Ответить
                                  • Нельзя взять и просто так отключить всё ключиками. Для снятия некоторых ограничений в Винде придётся половину DLL заменять библиотеками от другого (более дорогого) выпуска и/или подменять файлы лицензии.
                                    Ответить
                              • как что считается? как сервер может посчитать сколько к нему одновременно HTTP коннектов сделано?

                                Придумай алгоритм, ты же программист.

                                Даже если и ключиком -- это нарушение лицензии, а энтерпрайз на это не пойдет
                                Ответить
                                • Нахуй мне придумывать, я спросил как там сделано.

                                  >Даже если и ключиком -- это нарушение лицензии, а энтерпрайз на это не пойдет
                                  Вот поэтому могли и ключиком сделать.

                                  Кстати подменять баннер апача - нарушение лицензии.
                                  Ответить
                  • >Со стороны это похоже на смесь гербалайфа и комсомола.
                    В граниты!
                    Ответить
              • Што? Вендоблядок?
                Ответить
        • > "синтаксические подсластители - зло." из той же оперы.
          Ненавижу это явление. Какой-нибудь прославившийся хрен под вечернее пивко в твиттерок пишет: "Нормальные пацаны пишут typedef посерёдке: int typedef ko_type; по-старому - пидарство и нечитаемо."
          А через неделю на совещании солянка из таких "правил" распечаткой падает на стол, сопровождаемая словами: "теперь пишем так, иначе - минус премия, плюс десять ударов хлыстом на главной площади".
          Любой код, если его не трогать, через полгода превращается в говно, как бы старательно в нём не избегали использования свойств, синтаксического сахара, венгерки, копипаста и т.д.
          Ответить
          • > Ненавижу это явление. Какой-нибудь прославившийся хрен под вечернее пивко в твиттерок пишет [...]

            это называется "мода". или - "стадный инстинкт".

            и человечество всегда было падко на шарлатанов с панацеями.

            > А через неделю на совещании солянка из таких "правил" распечаткой падает на стол [...]

            а это скорее лень и часто простая неграмотность начальства/лидов. вместо того что бы работу делать, и себя в курсе текущих подводных мин держать, предпочитают время расходовать на поиск панацей проблем программирования. но все заканчивается тем что все эти панацеи оказываются на самом деле плацебо... и все начинается по новой.
            Ответить
    • Ничто не нужно кроме ассемблера
      Ответить
      • Зачем ассемблер? Лучше прямо машинными кодами программы писать.
        Ответить
        • Зачем машинные коды? Лучше прямо из транзисторов собирать свой процессор с уже заложенной в него программой на аппаратном уровне
          Ответить
          • Да и сам процессор не нужен, можно сразу реализацию алгоритма делать из транзисторов
            Ответить
            • Их тогда слишком дохуя выйдет. А процессор всё-таки позволяет реюзать одни и те же транзисторы...
              Ответить
              • google: рефлексный усилитель

                В аналоговых схемах удавалось реюзать транзисторы. Количество уровней сигнала, ограниченное только квантовыми эффектами, позволяет разделить сигналы после смешивания.

                В цифровых хуже: там придётся разделять сигналы по времени с помощью стробирования. В итоге придём к чему-то, похожему на процессор.

                P.S. Хотя в цифровых мы можем использовать ШИМ, фактически пропуская аналоговые сигналы через цифровые логические элементы.
                Ответить
                • > В цифровых хуже: там придётся разделять сигналы по времени с помощью стробирования. В итоге придём к чему-то, похожему на процессор.

                  TDMA не одинок. есть еще CDMA. это когда (примитивный пример) бродкастится число, и каждый девайс вычисляет модуль по сконфигурированому числу. остаток после модуля и есть передаваемая информация для этого девайса.

                  ЗЫ похоже все уже забыли про "аналоговые компьютеры". https://ru.wikipedia.org/wiki/Аналоговый_компьютер . там правда мало чего описано и примеров мало. но тут есть чего - https://ru.wikipedia.org/wiki/Интегратор .
                  Ответить
            • Не поверишь, но некоторые так и делают.
              Ответить
      • Ничто не нужно
        Ответить
    • > Немного о пропертях

      ты где это Г нашел?
      Ответить
      • Джефри Рихтер - CLR via C#. Программирование на платформе Microsoft.NET Framework 4.5 на языке C#
        Ответить
        • пипец.

          это как там еще какое то светило в некрософте, который проповедует что номера версий это излишне и плохо. под его влиянием народ на первых Н версиях DirectX трахался с определением версии DX (что бы воркараунды/совместимость в рантайме активировать).
          Ответить
          • А как определяли?

            Нарисуем куб с двумя источниками света. Если площадь тени меньше 42.314, то версия X, иначе Y.
            Ответить
            • на первых версиях (1-5?) народ длл ручками грузил и в versioninfo лез. но потом некрософт это сломал (в районе 4й версии?), потому что перестали мажор/майнор версии увеличивать. в поздних версиях (6, 7) в реестре была пара мест (но там мог и мусор стоять). если не ошибаюсь в 8й версии только добавили официальный способ опроса версии. (мелкие грабли там в том что у DX компонент могут быть разные версии.)
              Ответить
              • А в DX9, емнип, даже интерфейсы нумеровать перестали и начали тупо добавлять в них новый функционал...
                Ответить
        • Эта книга более чем наполовину состоит из примеров, как не надо писать код.
          Ответить
          • Вредные советы?
            Ответить
            • Там автор упоротый. Ему не надо программы писать (и, тем более, поддерживать), ему интересно узнать, как всё устроено, как можно поизвращаться и всё такое.
              На читаемость кода и возможность поддержки ему просто насрать.

              Короче, эту книжку надо в обязательном порядке закусывать Мартином Фаулером.
              Ответить
              • Упоротый твой дед

                А Рихтер один из старейших сотрудников MS
                Он писал про WinApi via C и про разработку под винду еще в 80х (кроме него и Пецольда про винду вообще тогда не писали)

                Его книга про .NET одна из лучших
                Ответить
                • Он теперь неоспоримый авторитет, да? Критически ко всему надо относиться, критически. Обколются тут Рихтером и пишут такую дрянь, что читать невозможно. Типа, показать, какие мы крутые программеры.
                  Ответить
                  • Причем тут авторитет?

                    Он учит не красоте кода, а архитектуре вирт машины, и называть его упоротым, по меньшей мере, глупо
                    Ответить
                    • > А Рихтер один из старейших сотрудников MS
                      > Он писал про WinApi via C и про разработку под винду еще в 80х (кроме него и Пецольда про винду вообще тогда не писали)
                      >> Причем тут авторитет?

                      Ну так аппелирование к авторитету же.

                      А термин "упоротый" в данном случае трактуйте как синоним "черезмерно увлечённый", чтобы не было баттхёрта. Сэр.
                      Ответить
                  • >> Обколются тут Рихтером и пишут такую дрянь, что читать невозможно.

                    Ну так Рихтер и не учит писать красиво. Он рассказывает как устроен дотнет
                    Ответить
                    • вот да

                      красоте учит Фаулер, "программист прагматик", "совершенный код", "континиус деливери" итд
                      Ответить
                      • эх, я его только по учебе читал, когда паттерны изучал
                        Ответить
                        • А надо бы)

                          У него есть отличная книжка про энтерпрайз паттернс
                          и про энтерпрайз интегрейшен паттернс
                          итд

                          а про сами паттеры нужно ганг ов фор
                          Ответить
                          • и их читал.

                            Самые адекватные паттерны у Лармана.
                            Ответить
                          • >отличная книжка
                            >энтерпрайз паттернс
                            >энтерпрайз интегрейшен паттернс
                            >паттеры нужно ганг ов фор

                            Не возвращайся никогда.
                            Ответить
                            • да-да
                              интерпрайз ни нужен

                              ты бессмысленный, жалкий пиздун
                              Ответить
                    • Ну а я что, против? Я ни разу не говорю, что книжка плохая. И не говорю, что Рихтер мудак. Сам прочитал книжку с большим удовольствием и другим рекомендую. Только надо понимать, для чего и как он эту книжку написал (там есть дисклеймер, почти всё объясняющий), но всё же. И не писать так же, как он в реальных проектах )
                      Ответить
                      • Так у него и нет ни одного реального примера в книге. Там только суррогаты для демонстрации особенностей
                        Ответить
                        • Ну так мне хочется в половине примеров подписать, что нельзя эту особенность использовать.
                          Ответить
          • Тогда почему ее рекомендуют читать чуть более чем везде?
            Ответить
            • Куда писать? На заборе?
              Ответить
            • Для того, чтобы понимать, как устроено. Там очень хорошо все кишки CLR описаны. Ну и код там весьма специфический...
              Ответить
            • Кстати, вот что я рекомендую:
              http://i.imgur.com/RcBizFT.jpg
              Ответить
              • А что за девайс справа от клавы?
                Ответить
              • че за книга четвертая?
                Ответить
                • Р.С. Мартин. М.Мартин. Принципы, паттерны и методики гибкой разработки на языке C#.
                  Вообще все книжки рекомендую с оговорками. Эту особенно с оговорками.
                  Ответить
                  • ну из всех только эту я в руках не держал
                    Ответить
              • >CLR
                >C#
                >ООП
                >реfuckторинг
                >паттерны
                Да тут же полный набор!

                wvxvw, срочно 10 томов нормальных книжек, внутричерепно!
                Ответить
                • CLRом пользуются только идиоты. Нужно писать на прологе.
                  C# пользуются только идиоты. Нужно писать на прологе.
                  ООП пользуются только маркетологи. Нужно писать на прологе.
                  Рефакторинг это маркетинговый шлак. Нужно сразу писать хорошо (и на прологе).
                  Паттерны это маркетинговый шлак, у нас в прологе их нету
                  Типизации не существует, это маркетинговый шлак

                  с уважнием,
                  Сетевой администратор "Едиот Ахронот", wvxvw
                  Ответить
                  • можно я продолжу?
                    Microsoft не стандартизирован и им пользуются только посредственности. С Microsoft никогда не стать программистом.
                    В Microsoft даже пролог не используется.
                    Microsoft не мощный, и фотошоп не мощный потому что платный. Гимп бесплатный, потому им удобнее. Чем бесплатнее продукт, тем он удобнее. Непосредственности пользуются бесплатными продуктами, платными продуктами пользуются только посредственности, потому что это это гербалайф и секта. Если ты пользуешься майрософт, то ты посредственность, жертва маркетинга, гербалайф и секта. нужно использовать gimp и пролог.
                    Ответить
                  • >Нужно писать на прологе.
                    На ассемблере
                    Ответить
    • Ну что, годный срач получился?
      Ответить
    • Срач объявляется открытым.
      Ответить
    • Вот и прошло уже два года, а Рихтер ещё бомбит по поводу свойств.
      Ответить
      • Джефри просто надо из его MS мирка за кинутьв шестую джаву чтобы он вручную аксесоры и мутаторы пописал, вот тогда бы он поянл

        Но вообще Рихтер крут
        За Win32 via C и CLR via C# надо ставить памятник
        Ответить
    • А я согласен. У нас в с++ никаких пропертей нет и не нужно. Зачем нужен этот сахар, если вызвать метод ничуть не сложнее и код с сетерами понятней? Не нужен.
      Ответить
      • Написать метод в дохуя раз дольше и сложнее
        Ответить
        • Покеж пример.
          Ответить
          • У тебя под хвостом.
            Ответить
          • public class Pituh
            {
               public string Name 
               { get; set; }
            }


            В последствие можно будет реализовать set и get по-другому, а пока что они просто представляют аксессор и мутатор для филда.

            Сравним с жабой
            public class Pituh {
               private String name;
               public String getName(){ 
               return name;
               } 
            
               public String setName(String name) {
                 self.name = name;
               }
            }
            Ответить
      • > У нас в с++ никаких пропертей нет
        Бедненькие! Не могу читать без слёз. Это несправедливость. Как же вы без них живёте?
        Кушайте, крестушатки. Кушайте, маленькие.
        template <typename O, typename T>
        class Property {
        public:
          Property(O* that, T (O::*getter)() const, void (O::*setter)(const T&)):
            that(that), getter(getter), setter(setter) {}
          
          operator T() const {
            return (that->*getter)();
          }
          
          Property& operator = (const T& value) {
            (that->*setter)(value);
            return *this;
          }
          
        private:
          Property(const Property&);
          Property& operator=(const Property&);
          
          O* that;
          T (O::*getter)() const;
          void (O::*setter)(const T&);
        };

        https://ideone.com/Y4S7jx
        Ответить
        • Повышаем читаемость в одном месте, пися говно в другом. Тут уж лучше методы.
          Ответить
          • Где говно? Property - библиотечная питушня, пишется и отлаживается один раз.
            Написание кода с пропертями можно и подсахарить:
            #define PROPERTY(type, name) Property<CLASS_NAME, type> name
            #define INIT_PROPERTY(name) name(this, &CLASS_NAME::get##name, &CLASS_NAME::set##name)
            #define GETTER(type, name) type get##name() const
            #define SETTER(type, name, var) void set##name(const type& var)


            И можно использовать без знания тонкостей проставления const и ссылок:
            #define CLASS_NAME Demo
            class CLASS_NAME {
            public:
              CLASS_NAME() :
                INIT_PROPERTY(x),
                INIT_PROPERTY(x2),
                a(0) {}
              
              GETTER(float, x) {
                return a;
              }
              
              SETTER(float, x, value) {
                if(value >= 0 && value < 10) a = value;
                else a = 0;
              }
              
              GETTER(float, x2) {
                return a * a;
              }
              
              SETTER(float, x2, value) {
                if(value >= 0 && value < 100) setx(sqrt(value));
                else setx(0);
              }
              
              PROPERTY(float, x);
              PROPERTY(float, x2);
              
            private:
              float a;
            };
            #undef CLASS_NAME
            Ответить
            • .
                     _
                    | |
               _ _ _| | _
              | | | | |/ /
              |         /
               \       /
                |     |

              Мама-мама, а этот дяденька ругается нехорошими словами. Он сказал "#define" и "##name", а ещё он показывал мне свой SETTER.
              Ответить
              •        .
                       _
                      | |
                 _ _ _| | _
                | | | | |/ /
                |         /
                 \       /
                  |     |

                Крестушоночек, не плачь. Тех, кто плачет, сбрасывают со скалы в обрыв с макросами. Это не Питония, это C++арта.
                Ответить
                • //  
                       _
                      |_|
                      | |
                   _ _| |_ _
                  | | | | | | 
                  | | | | | | 
                  |         /
                   \       /
                    |     |
                  Ответить
                  •          _
                            |_|
                            | |
                     _ _ _ _| |_ _ _ _
                    | | | | | | | | | |
                    | | | | | | | | | |
                    |                 /
                     \               /
                      | (__)    === |
                      |     (*)     |
                      |             |
                      |   NAKATIM   |
                    Ответить
                    • В цвете давай.
                      Ответить
                      •  ___ ___ ___ ___ ___
                        |   |   |   |   |   |
                        |   |   |   |   |   |
                        |                   /
                         \                 /
                          |  (__)    ===  |
                          |      (*)      |
                          |               |
                          |    NAKATIM    |
                        Ответить
                        • Ватник книзу вроде не сужается.
                          Ответить
                          • На этой картинке видно, что линии не совсем прямые: http://pics.wikireality.ru/upload/thumb/4/40/Vatnik.jpg/280px-Vatnik.jpg
                            Впрочем, на ней он всё равно не так сильно искривляется, это да.
                            Ответить
          • Я нечто похожее когда-то делал, но совсем из других соображений, для наколеночной рефлексии.

            > Тут уж лучше методы.
            +1
            Ответить
        • показать все, что скрытоvanished
          Ответить
    • Весь этот тред очень хорошо показывает главный, я бы сказал основополагающий принцип любого программиста:

      Одну технологию выбирый
      @
      Про другие технологии нихуя не знай
      @
      Но усиленно их обсирай
      Ответить
      • Весь этот пост очень хорошо показывает главный, я бы сказал основополагающий принцип любого человека:

        Мое мнение правильное
        @
        Все несогласные - мудаки
        Ответить

    Добавить комментарий