1. Pascal / Говнокод #17157

    +87

    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
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    37. 37
    38. 38
    39. 39
    40. 40
    41. 41
    42. 42
    43. 43
    44. 44
    45. 45
    46. 46
    47. 47
    48. 48
    49. 49
    50. 50
    51. 51
    52. 52
    53. 53
    54. 54
    class function TTransfer.getCreditStateOFCreditPoints(creditPoints:Int64):Integer;
    begin
      Result := 0;
      if (creditPoints>=0) AND (creditPoints <200) then
         begin
              Result := 1;
              exit;
         end;
      if (creditPoints>=200) AND (creditPoints <600) then
         begin
              Result := 2;
              exit;
         end;
      if (creditPoints>=600) AND (creditPoints <1200) then
         begin
              Result := 3;
              exit;
         end;
      if (creditPoints>=1200) AND (creditPoints <2000) then
         begin
              Result := 4;
              exit;
         end;
      if (creditPoints>=2000) AND (creditPoints <3700) then
         begin
              Result := 5;
              exit;
         end;
      if (creditPoints>=3700) AND (creditPoints <7000) then
         begin
              Result := 6;
              exit;
         end;
      if (creditPoints>=7000) AND (creditPoints <15000) then
         begin
              Result := 7;
              exit;
         end;
      if (creditPoints>=15000) AND (creditPoints <25000) then
         begin
              Result := 8;
              exit;
         end;
      if (creditPoints>=25000) AND (creditPoints < 100000) then
         begin
              Result := 9;
              exit;
         end;
      if (creditPoints>=100000) then
         begin
              Result := 10;
              exit;
         end;
    end;

    Типа Ы-нтерпрайз код. Где таких делают только.

    Запостил: Cynicrus, 24 Ноября 2014

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

    • Делают там, где не знают про BRMS вроде Drools.
      К сожалению я сплошь-и-рядом вижу ынтерпрайзников которые о таких вещах не задумываются.

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

          И что такое "говнофреймворков не тянет"?
          Ответить
          • Сокетный сервер. Обслуживает пока до 5к клиентов. Плюс логика браузерки. Ничего такого. Но приходится всякую такую херню находить, и переписывать. Что значит без фреймфорков? Значит что собранному бинарнику не нужен не мностроуозный Qt, ни .net - собрал раз,и работает на XP,7,8, 2003,2008, etc.
            Ответить
            • Я бы согласился, если бы код приходилось раздавать тысячам клиентов... Там да, неприятно лишние зависимости иметь.

              Но для серверов зависимость от фреймворков/либ никогда не была проблемой, имхо.
              Ответить
              • Ну когда его запускаешь на ограниченных ресурсах - то всё таки без лишних зависимостей оно веселее. Да и отладка - дело не последнее. Будь в линуксе отладчик уровня дельфей, тоуже давно бы выловили большую часть всяких неприятных багов.
                Ответить
                • >>Будь в линуксе отладчик уровня дельфей
                  што?;)
                  Ответить
                  • Отладчик, уровня того, что имеется в Delphi => XE:)
                    Ответить
                    • Ну вообще в линуксе есть отлачик. Gdb, например.
                      И есть к нему разные гуи.
                      Например вот http://www.eclipse.org/cdt/

                      Что не так-то?
                      Ответить
                      • А кто-то говорил, что нету? Просто отладчики от MS и Embarcadero - уделывают gdb со всеми гуями по удобству и наглядности.
                        Ответить
                        • Не знаю. Чего Вам в gdb не хватает?

                          Вон у CLION какой дебагер отличный:
                          https://www.jetbrains.com/clion/quickstart/img/debugger.png
                          Ответить
                          • Да мне всего хватает в gdb, меня его командная строка и недогуи к нему выстёгивают. А вот в CLION - да, симпатичен. Только вот сам Clion запилен пока...на троечку.
                            Ответить
                          • И тут даты!
                            Ответить
                • > отладчик уровня дельфей
                  Х.з. Спокойно дебажил код на другой машине через gdbserver и QtCreator. Вроде бы есть всё, что надо для счастья. По крайней мере мне хватало.
                  Ответить
              • Ну что Вы! Ставить джаву или .NET на сервер -- это же лишние 200 мегабайт!
                А готовые фреймворки вроде упомянутого выше Drools это еще мегабайт 300. Лучше написать свое, теплое и ламповое. Как в этом примере)
                Ответить
                • В этом примере - ни один фрэймворк не спасёт, ибо сие кусок логики игровой.
                  Ответить
                  • Спасет фреймворк который позволит эту логику вынести в хранищиле и редактировать в нормальной человеко-читаемой форме, и в ней же отображать и версионировать.
                    Ответить
                    • Не совсем понял.
                      Ответить
                      • В системах часто бывает много мутной бизнес-логики вроде "если X меньше 42 и больше 31 то Y должно быть 64.22". Эту логику совсем не хочется писать на императивном языке и вкомпилировать в продукт.

                        Потому и было придумано:
                        http://www.drools.org/landingPage/Limited_Decision_Table_Big.png
                        http://www.drools.org/landingPage/Guided_Decision_Table_Big.png

                        Подобные штуки позволяют:
                        1) бизнес-аналитикам и математикам редактировать данные не влезая в код
                        2) редактировать данные в удобно формате
                        3) версионировать их
                        4) применять данные не перезапуская приложение

                        как-то так)
                        Ответить
                        • Это типа того же, что можно вынести в скрипты на том же LUA только для более ленивых?
                          Ответить
                          • Почти. Просто подобные штуки проще писать ввиде таблиц принятия решений а не ввиде LUA скриптов. Кроме того в интерпрайзе их может править бизнес-аналитик, а он луам не обучен.

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

                                А потом у них вместо BRMS такие вот ифы, вместо OLAP кубов 100500 страничек с SQL запросами, вместо SOAP свой собственный протокол с авторизацией наколенной, итд
                                Ответить
                                • Вот так все и говорят: "наш проект вырастет до настоящего энтерпрайза, поэтому мы будем юзать готовые решения". А потом у них вместо пары-тройки ифов - BRMS, вместо десятка SQL запросов - OLAP куб, вместо простенького протокола с наколенной авторизацией - SOAP. И, в итоге, прога для какого-нибудь ларька крутится на сервере с десятком гигов памяти, которой еле хватает...
                                  Ответить
                                  • Вот никогда такого не видел.

                                    Обычно девелоперы пилят на коленке квадратноколесные велосипеды из бойлерплейта, багов и боли, и гордятся тем что у них нет ORM, OLAP, SOA, ESB итд.
                                    Ответить
                                    • Плохо смотрели. На соурсфорже тысячи over9000 переусложненных хреновин.

                                      ЗЫ: ну и когда главное быстродействие, то применение SOAP как минимум спорно. Уж лучше BSON какой нибудь или свой бинарный протокол.
                                      Ответить
                                      • энтерпрайзы на соурсфорже? где это?
                                        Ответить
                                        • Ну там есть решения, претендующие на энтерпрайз. Таки да. Типа ERP или CRM.
                                          Ответить
                                          • Приведите пожалуйста пример "переусложненных хреновин.":)
                                            Ответить
                                            • Сейчас пример не приведу, искать лень. Но как нибудь - обязательно.
                                              Ответить
                                      • >>ну и когда главное быстродействие, то применение SOAP
                                        Разумеется.
                                        Но у большинства энтерпрайз система боттлнек вовсе не коммуникейшенах между системами. И такие конструкции как сквозная авторизация (ws-federation), ws-роутинг да и сама возможность герерировать статически типизированный прокси-класс по контракту -- такие вещи целиком эти проблемы перекрывают)
                                        ---
                                        А вот людей, которые сначала вручную отдают друг другу JSON, потом вручную пилят SSO, потом забывают обновить документацию и путаются в параметрах -- такое сплошь-и-рядом
                                        Ответить
                                        • Я вспоминаю систему гостиничного поселения от Libra Hospitality, и думаю..Раз столько технологий, чего же они до сих пор используют морду на мёртвом VC 5.5 с обвязками на скриптах от Power Builder 6.5, а то что нельзя прикрепить на древнем PB - прикрепляют костылями на соплях, да ещё и на C#.
                                          Ответить
                                    • Я в таком работал. Приложение занималось тем, что предлагало админку желающим поместить свою рекламу в лицокнигу. Желающих было ну не так, чтобы совсем не много, но до сотни (статистика была скрытой от разработчиков, но по логам было не сложно догадаться).
                                      Было написано на Спринге с Хайбернейтом запускалось в Томкате (ну это не столь важно) с жсп страничками и т.п. В репозитории проекта было около 40-50 джаров. Деплоймент был такой стремный, что Томкат не мог с ним совладать, и каждый раз, когда приложение пересобиралось, сервер тоже нужно было рестартить. Весь процесс занимал минут пять.
                                      По хорошему, все приложение можно было уложить в десяток-два ХТМЛ страничек, но поскольку жсп = шаблоны собирающиеся инклудами по кусочкам, этих кусочков там было до сотни примерно.
                                      Ответить
                                      • Вы уверены что на поддерживать приложение из двух десятков копипасченных HTMLев (и кстати, с каким бекендом? без спринга, DI, и с ручным SQL?) было бы проще?

                                        Но вообеще у каждого свой опыт, конечно. Обычно я встречаю именно что наколенщиков, не желающих понимать что их задачу можно немного генерализировать и она кажется уже решена тысячу раз, причем стабильнее, красивее и с плюшками)

                                        И как свою морду к почте пилили я видел, и как писали тьму одинаковых CRUD запросов потому что "хибернейт говно" и как репорты верстали вручную и каждому репорту писали SQL запрос потому что "кубы это сложно и ненужно" и как делали самописный таск шедулер чтоб эти репорты отправлять ("кварц тяжелый") и как вручную гоняли JSON а потом путались в API и надо было "спросить у разработчика что это поле значит" ("зато не тяжелый soap") и как делали сквозную авторизацию передавая ГЕТом везде какой-то ID (ну, про federation молчу), и как вместо приснопамятного brms делали кучу ифов итд.
                                        Видел даже как свою вики пилили.

                                        Так что по помему опыту именно так и бывает...)
                                        ------
                                        ps: самый смак что я видел, это когда ребята выставили нам API, и поверх HTTP придумали свой протокол и реализовывали там приватные ключи: "мы вам передаем N байт, а вы их ксорите с вот этим вот ключом и передаете нам обратно, и так мы знаем что вы это вы". Ну понятное дело что TLS это сложно и не нужно.
                                        Ответить
                                        • Зачем это вообще было на Яве делать? Там какой-нибудь ПХП скрипт лего бы справился. Просто если делать просто, то потом продать сложно. Ну не с руки же продавать скрипт + пару ХТМЛей. Надо нахерачить туда чего побольше, чтобы солиднее выглядело.
                                          Ответить
                                          • Наверное за тем что код на яве легче поддерживать ввиду хорошего API и внятной типизации, легче писать, легче решать проблемы с перформансом (ввиду хороших профайлеров), легче дебажить, легче расширять в будущем.

                                            Впрочем, не зная задачи это беспредметный разговор конечо:)
                                            Ответить
                                            • Код на Яве легче поддерживать? Это сраказм такой? На Яве кода будет в несколько раз больше и сложнее - в чем заключается легкость такой поддержки?
                                              Ответить
                                              • Просто на яве не надо держать в уме архитектуру для которой пишешь. Медитировать на WinAPI или Posix. Главное знать api vm. Ну а что до тормозов, то если без гуя - то оно и приемлемо.
                                                Ответить
                                              • тем, что если его писал не школьник, то он будет хорошо поддаваться распознаванию, т.к. будет содержать в себе все привычное и знакомое

                                                все же AOP и DI очень облегчают жизнь, т.к. везде, в каждом проекте, каждый день одно и то же

                                                могу даже рассказать прохладную историю, как нам однажды пришлось декомпильнуть (!) чужой огромный .ear, получив 1M строк кода, и успешно исправить и переписать несколько модулей в нем
                                                Ответить
                                                • Зачем для какого-то десятистраничного сайта медитировать над ВинАПИ / Позикс? Чем тут Ява будет лучше ПХП?

                                                  Если на Яве писал не школьник, а на ПХП - школьник? - давайте все-таки сравнивать сравнимые вещи.
                                                  Ответить
                                                  • десятистраничные сайты не писал, сервер-сайд вообще тупизм для неосиляторов
                                                    много сталкивался с жалкими потугами ынтерпрайзно засунуть пхп в мир взрослых людей - ну там, написать хотя бы soap-сервис/клиент (я уж не говорю к шине подключиться)
                                                    почему-то постоянно с этим только проблемы и недели отладки взаимодействия систем

                                                    насчет школьник-нешкольник, в джаве всё приспособлено для того, чтобы неправильно было бы написать сложнее, чем правильно
                                                    встаешь в колею и никуда с нее не сходишь

                                                    в пхп же никаких норм, сам язык не может соответствовать одному стилю, и с низким порогом вхождения даже "проффессионалы" с опытом 10 лет за плечами настолько избалованы, что не могут сделать нормальный проект, который будет поддерживаться не ими
                                                    Ответить
                                                    • Да я бы не сказал... можно много говорить о качестве, но есть сколько-то ПХП проектов, которые поддерживаются кучей других разработчиков: Медиавики, ЦПанель, Вордпресс, форумы всякие - что в голову пришло. Но я не искал специально, наверняка есть и еще.
                                                      Более того, допилить Дженкинс или Селениум до нужного состояния гораздо сложнее, чем тот же Вордпресс.
                                                      Ответить
                                              • В том что код может быть :
                                                1) типизирован
                                                2) иметь нормальную архитектуру.
                                                3) Использовать нормальные библиотеки
                                                4) Юзать нормальную стандартную библиотеку

                                                Все четыре пункта для PHP не верны
                                                Ответить
                                                • Как Ява влияет на нормальность архитектуры. Я чет такой связи не прослеживаю.
                                                  Типизорованость делает код более часто более сложным (и чем больше типизированости, тем более сложным) в поддержке, так что это скорее минус, чем плюс.
                                                  Ява как-то влияет на нормальность библиотек? Чет я не замечал.
                                                  В Яве нормальная стандартная библиотека? Та ну, даже большие любители Явы используют всякие Апачи / ЕЕ / Гуяву напильники чтобы работать со стандартной библиотекой.
                                                  Ответить
                                                  • > В Яве нормальная стандартная библиотека?
                                                    По сравнению с пыхой? Да.
                                                    Ответить
                                                  • >В Яве нормальная стандартная библиотека?
                                                    Разные её куски по-разному. Т.к. писалось в разное время и совершенно разными людьми.
                                                    concurrency близок к гениальности. коллекции из util в принципе хороши. старые даты - говно. новые - удобно, итд.
                                                    Ответить
                                                    • Ну хз. Я с ПХП почти не сталкивался по жизни. Как-то всего пару месяцев что-то поддерживал, тогда и пришлось заглянуть. Я бы не сказал, чтобы у меня прям такие плохие воспоминания остались. С помощью PDO и какой-то функции для конвертации в JSON (вот, что правда, то правда, ее пришлось доделывать, т.как она пыталась числа послать как строки, а строки с юникодами как код-поинты... но, прямо скажем, ЖСП тоже любит время от времени код-поинтов насовать, так что это не показатель.) С другой сторноы, код был очень компактным, всего каких-то 3-4 файла по 200-300 строчек.
                                                      Ответить
                                                      • > строки с юникодами как код-поинты
                                                        Да это нормально для json'а. Я точно не помню, но возможно спека требует такую запись чтобы избежать всех проблем с кодировками.
                                                        Ответить
                                                        • Не, в JSON строки изначально UTF-8 без вариантов. Такое экранирование там возможно, но не нужно (и делает отладку очень нескучной).
                                                          Ответить
                                                  • >>Как Ява влияет на нормальность архитектуры
                                                    Как типизированный язык с внятной стандартной библиотекой.
                                                    >> Я чет такой связи не прослеживаю.
                                                    Откройте любой опенсурсный PHP проект и узрейте.
                                                    >>Типизорованость делает код более часто более сложным
                                                    Типизированность помогает отлавливать ошибки на стадии компиляции, помогает при использовании IDE, и как-то даже странно объяснять что белое это белое. Вот, можете еще Романа спросить: http://govnokod.ru/17154#comment256247 :)
                                                    >>Ява как-то влияет на нормальность библиотек? Чет я не замечал.
                                                    Да. Сравните, например, спринг и Zend. Сравните стандартную библиотеку PHP и явы.
                                                    >>В Яве нормальная стандартная библиотека? Та ну, даже большие любители Явы используют всякие Апач
                                                    В то время как большие любители PHP обычно пилят свой класс "Array", причем в каждом проекте заново.
                                                    Ответить
                                                    • Слово типизация - это самое большое заблуждение современных программистов. Ява не более типизированая чем ПХП. В компилятор Явы встроен механизм, который умеет проверять некоторые типы на определенные нсоответсвия. Но это не делает Яву более типизированым языком, чем ПХП. Пример нетипизированого языка: Форт, вот там действительно типов нет. В ПХП есть типы, просто нет статической проверки, но может линт какой-нибудь есть - я не знаю, т.как не искал никогда.

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

                                                      Опять же, нужно понимать что такое тип. Иначе высказивания об "отлове ошибок во время компиляции" превращается в пустое выражение. Типы, или, вернее, желание их иметь проистекает от желания формально выразить назначение програмы. Т.е. параллельно с программой написать и доказать теорему гарантирующую правильность написаной програмы. Но, тут же напрашиваются вполне резонные вопросы:
                                                      1. А что если мы неправильно доказали теорему?
                                                      2. А что если мы доказали не ту теорему?
                                                      3. А что если программа, относительно которой доказывалась теорема, не смотря на доказательство не соответствует доказаному?

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

                                                        Конечно я не говорил что PHP вообще не типизирован. Он типизирован динамически, а ява -- и статически и динамически.

                                                        >>Опять же, нужно понимать что такое тип
                                                        Можете на досуге ознакомиться с понятием ADT:)

                                                        >>. А что если мы неправильно доказали теорему?
                                                        Ну вот опять: "если %FOO% не решает всех проблем, то %FOO% не нужен":)

                                                        Не используйте вообще никакие средства разработки и никакие современные языки, ведь все они основаны на каких-то контрактах, а контракт может быть описан неверно.

                                                        >>Я никогда не занимался подсчетом и статистикой связаной с >>ошибками типов относительно усилий потраченых на
                                                        >>типизацию
                                                        Достаточно один раз порефакторить большой проект. Метод переименовать, например.

                                                        >>Путем написания адаптеров
                                                        Да, это действительно минус. К счастью, в современных языках он часто решен заменой наследования на делегирование (kotlin, например).

                                                        Да и отсутствие статической типизации ни коим образом не оправдывает кашу со стандартной библиотекой , типами, отсутствием неймспейсов и модульности и arrayем.
                                                        Охх) Вам тоже статью про "фрактал плохого дизайна" показать?)
                                                        Ответить
                                                        • "Статическая типизация" это лечение заговором. Науке ничего не известно о свойствах и возможностях статической типизации. Она существует исключетельно в фольклере программистов которые так называют возможность компилятора проверить код на соответствие некоторых правил до того, как программу выполнит пользователь. У меня даже где-то была закладка на стековерфлоу где Пирс жаловался на то, как программисты бесцеремонно обходятся с терминологией руководствуясь народными приметами и повериями.

                                                          Я как бы провожу досуг за чтением того же Пирса или Милнера... АДТ - это что-то из книг для начинающих изучать Яву, о нем же и на собеседованиях любят спрашивать. Я не пытаюсь сказать, что это что-то бесполезное, очень даже наоборот, просто это указывает более-менее на степень погружения :)

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

                                                          Да, я рефакторил большие проекты. И при этом связь от меня все так же ускользает. Самый лучший помощник в этом всегда был grep и тесты... если были. А если приглядется, большая часть рефакторинга в больших проектах была связана с бюрократией типов.

                                                          В современных языках? О каких языках позвольте спросить идет речь? Если это случайно Ява, то это язык морально устаревший в зародыше...

                                                          Да, я читал когда-то статью про ПХП. И я не утверждаю, что это замечательный язык, я говорю, что Ява - даже если в чем-то и лучше, то эта разница на столько не заметна на общем фоне, что не стоит таких категорических утверждений.
                                                          Ответить
                                                          • >>"Статическая типизация" это лечение заговором. Науке ничего не известно о свойствах и возможностях статической типизации.

                                                            Науке-то (в отличии от Вас) это прекрасно известно.


                                                            >>АДТ - это что-то из книг для начинающих изучать Яву
                                                            Нет, это Abstract Data Types. Это, кстати, тоже науке известно.

                                                            >> Если это случайно Ява, то это язык морально устаревший в зародыше...

                                                            Вот это аргумент!

                                                            Ладно) Вы или троллите или находитесь в какой-то параллельной реальности, не думаю что стоит продолжать беседу:) Оставляю Вас в мире где статической типизации не существует, проекты рефакторят грепом, пользователи VisualStudio не умеют пользоваться компьютером, а ADT " это что-то из книг для начинающих изучать Яву":)
                                                            Ответить
                                                            • в мире лисп типизации не существует, в емаксе нечем больше рефакторить проекты, а вижуал студия, кроме того что не запускается на его операционной системе, стоит денег, и не умеет в лисп и actionscript
                                                              Ответить
                                                              • > в мире лисп типизации не существует
                                                                Да почему. Там абсолютно такая же типизация, как в том же жс.
                                                                Ответить
                                                              • В Лиспе (каком из? я так понимаю, что речь идет о CL) типизация примерно такая же по духу, как в МЛ. С той разницей, что в МЛ для типов существует отдельный язык в языке, а в Лиспе для определения того, что такое тип используются механизмы все того же языка (было бы очень странно если бы было по-другому). Это значит, что, например, я могу создать тип для чисел в нужном диапазоне, или тип для массивов определенной длины и т.д.

                                                                Почему имея такую возможность почти никто этим не занимается и оставляет вывод типов компилятору (в отличие от МЛ и ему подобных?) - наверное традиция / есть более интересные вещи. Как правило люди пишущие на Лиспе задаются вопросом более точной типизации, если нужно добиться лучшей производительности от програмы, в большинстве случаев точные определения типов (такие как, например, численный диапазон) просто не интересны.
                                                                Ответить
                                                              • Я не берусь с полной ответственностью утверждать, но мне кажется это оно: http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD663.html Для заинтересованых читателей, контекст этого документа:

                                                                Дейкстра жалуется на очень херовое качество языков представленных на "конкурс" Ironman. Ironman - это проект организованый минобороны США (DoD в документе) для того, чтобы решить какой же язык использовать для embedded систем. У Ironman никогда не было победителей, и спецификацию заменили на Steelman, после чего победила Ада. Что интересно в этом документе, что судя по дате, один из языков-претендетнов был С++.

                                                                Два интересных момента: Дейсктра говорит о том, что понятие strongly typed имеет больше отношения к жаргону менеджеров по продажам, чем к программированию, кроме этого он жалуется на то, что в целом программирование скатилось и деградировало, и теперь управляется тупыми менеджерами по продажам.
                                                                Ответить
                                                            • К сожалению, я не могу найти запись этой лекции: http://www.cis.upenn.edu/~bcpierce/papers/harmful-mfps.pdf но тут Пирс говорит и об ограниченой полезности типов и, в том числе, о заблуждении и словоблудии существующем в среде программистов. И, уж если мы говорим о научной стороне вопроса, то Пирс как бы человек не просто авторитетный в отношении типов, он может быть один из десятка людей, которых имеет смысл слушать, когда речь об этом заходит.

                                                              Дело в том, что с научной точки зрения само выражение "статически типизированый" появилось в книке On Understanding Types, Data Abstraction, and Polymorphism за авторством Луки Кардели и Питера Вегнера (можно ознакомиться тут: http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf ). Они предложили определение, которое говорит следующее: языки, где правильность типов может быть установлена статической программой называются статически типизироваными. В этом смысле ни Ява ни С++ не являютыса статически типизироваными, т.как разрешают "опасные" касты. Более того, нет никаких известных не академических языков, которые бы были действительно статически типизированы в этом смысле. Кроме этого есть понятие статической проверки (близкое, но включающее гораздо больше), которое путают со статической типизацией.

                                                              Кроме этого есть еще strongly typed, который сюда до кучи примешали. Это говорит о том, что в языке все типы не противоречивы. Опять же, в Яве это не соблюдается, т.как в ней можно создать типы, которые нельзя скомпилировать изза противоречия, которое возникает у компилятора. Более того, интересные системы типов (по силе выразительности такие же или более выразительные как логика первого порядка) в принципе не могут быть эквивалентны strongly typed языкам.
                                                              Ответить
            • А протокол свой? Прямо поверх TCP?
              А клиенты на чем?
              Ответить
              • > А клиенты на чем?
                >> браузерки
                Видимо какой-нибудь вебсокет или комета.
                Ответить
                • Фраза "Плюс логика браузерки." вовсе не говорит мне что клиентом этого сервера выступает обычный веб браузер
                  Ответить
                  • Клиент напилен на флешке. Но клиент не моя вотчина.
                    Ответить
        • VCL не ?
          Ответить
          • Ха-ха-ха, так это толстый клиент чтоль?
            Это логика _на_клиенте_ такая?
            Ответить
        • > говнофрэймворков не тянет
          А как же любимое всеми BDE? :)
          Ответить
          • Уважаемый, BDE умерло вместе с Delphi 7:)
            Ответить
            • Ага. Вместе с таким замечательным софтом как WinXP, IE6-8, C++ Builder 6, FoxPro... Пусть земля им будет пухом.
              Ответить
      • Это не поскаль, это дэлфи.
        Ответить
        • Ну тогда я и точно прав: http://govnokod.ru/17157#comment256059

          Всё намного хуж
          Ответить
    • Тут можно как-то двоичным поиском обойтись?
      Ответить

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