Oberon space
General Category => Общий раздел => Тема начата: valexey от Март 20, 2012, 06:09:35 pm
-
Продолжаем про веб: кто-нибудь пробовал Google App Engine? Как оно вообще?
Вроде как там выбор ЯП для реализации относительно вменяемый: Java, Go, Python (особенно если последний вычеркнуть).
-
Продолжаем про веб: кто-нибудь пробовал Google App Engine? Как оно вообще?
Вроде как там выбор ЯП для реализации относительно вменяемый: Java, Go, Python (особенно если последний вычеркнуть).
ААА!!! Наезд на питон детектед!
-
Продолжаем про веб: кто-нибудь пробовал Google App Engine? Как оно вообще?
Вроде как там выбор ЯП для реализации относительно вменяемый: Java, Go, Python (особенно если последний вычеркнуть).
ААА!!! Наезд на питон детектед!
Ога :-) Чего только стоит наличие там ДВУХ питонов - 2.5 и 2.7 (с полными отдельными разделами по документации, API и так далее). Это уже как бэ многое про язык говорит. Для примера java там одна.
-
Ога :-) Чего только стоит наличие там ДВУХ питонов - 2.5 и 2.7 (с полными отдельными разделами по документации, API и так далее). Это уже как бэ многое про язык говорит. Для примера java там одна.
Это говорит о том, что язык эволюционирует. В отличие от жабы, у которой уже полная стагнация :)
P.S. Да, меня лично тоже задели эти несовместимости в питоновских версиях. И тем не менее, те изменения, которые пришлось фикснуть - были в лучшую сторону.
-
Ога :-) Чего только стоит наличие там ДВУХ питонов - 2.5 и 2.7 (с полными отдельными разделами по документации, API и так далее). Это уже как бэ многое про язык говорит. Для примера java там одна.
Это говорит о том, что язык эволюционирует. В отличие от жабы, у которой уже полная стагнация :)
P.S. Да, меня лично тоже задели эти несовместимости в питоновских версиях. И тем не менее, те изменения, которые пришлось фикснуть - были в лучшую сторону.
Нет, это говорит о том, что авторы питона не могут его менять так, чтобы не ломалась обратная совместимость. Сравни с жабой - когда вышла 1.5, это была таки революция: анотации, дженерики, форычи всякие там. Сильно переработана библиотека стандартных контейнеров. И при том, что обратная совместимость сломана не была.
Сейчас вот выползла java 7 - лямбдафункции и еще кучка ништяков. Обратная совместимость сохранена. То есть это реально работает. Ынтырпрайз системы потихоньку мигрируют на java 7. Проблемы бывают только когда народ в коде использовал недокументированные особенности конкретной (например ibm'овской или сановской) реализации jvm.
Ну и см. например эволюцию С++ и Ады (особенно последней). Новых возможностей в новых ревизиях языка действительно много. Обратная совместимость остается (с точностью до использования в качестве идентификаторов новых зарезервированных слов).
-
Нет, это говорит о том, что авторы питона не могут его менять так, чтобы не ломалась обратная совместимость. Сравни с жабой - когда вышла 1.5, это была таки революция: анотации, дженерики, форычи всякие там. Сильно переработана библиотека стандартных контейнеров. И при том, что обратная совместимость сломана не была.
Ага, ага. Только вот смотреть на эти "революционные вещи" без слез нельзя. Причем да, в C++ - слез еще больше ;) Так что дело не в том, что "авторы не могут", а скорее "авторы не хотят" ;) Авторы питона принесли обратную совместимость в жертву качеству новых фич. Их право. И они такие не одни. Вон Вирт, например... ;)
-
Нет, это говорит о том, что авторы питона не могут его менять так, чтобы не ломалась обратная совместимость. Сравни с жабой - когда вышла 1.5, это была таки революция: анотации, дженерики, форычи всякие там. Сильно переработана библиотека стандартных контейнеров. И при том, что обратная совместимость сломана не была.
Ага, ага. Только вот смотреть на эти "революционные вещи" без слез нельзя. Причем да, в C++ - слез еще больше ;) Так что дело не в том, что "авторы не могут", а скорее "авторы не хотят" ;) Авторы питона принесли обратную совместимость в жертву качеству новых фич. Их право. И они такие не одни. Вон Вирт, например... ;)
Да ладно ка. C++11 мне очень даже нравится. Равно как и нововведения в жабе.
И да, языки в которых обратную совместимость регулярно приносят в жертву, обычно в продакшине не задерживаются. См паскаль vs оберон. Да и на тот же хаскель можно посмотреть. Вообще много их...
-
Да ладно ка. C++11 мне очень даже нравится.
Модулей нет? Дальше можно не смотреть ;) По-настоящему важную проблему, которая бьет каждый день не решили.
Ну что там осталось еще из такого "революционного"? Да та же "move semantics" - да, полезно. Но как я и говорил - без слез смотреть нельзя ;)
Равно как и нововведения в жабе.
И да, языки в которых обратную совместимость регулярно приносят в жертву, обычно в продакшине не задерживаются.
Ну правильно, кому нужен С++ с модулями в продакшине... без обратной совместимости. Вот и продолжаем грызть кактус.
-
Да ладно ка. C++11 мне очень даже нравится.
Модулей нет? Дальше можно не смотреть ;) По-настоящему важную проблему, которая бьет каждый день не решили.
...
Ну правильно, кому нужен С++ с модулями в продакшине... без обратной совместимости. Вот и продолжаем грызть кактус.
У меня похоже приступ парадокса блаба… Не вижу я этих проблем в С++ (или слишком свыкся?) с модульностью. Можешь привести примеры проблем с которыми регулярно сталкиваешься из за отсутствия модульности в плюсцах?
-
Помню пару лет назад у наших плюсцеводцев случилась проблема с модульностью. Компилятору С++ не хватило оперативной памяти (32bit) чтобы скомпилировать программу. Вот только тогда им всё таки пришлось порезать программу на модули и компилировать их по отдельности.
-
Помню пару лет назад у наших плюсцеводцев случилась проблема с модульностью. Компилятору С++ не хватило оперативной памяти (32bit) чтобы скомпилировать программу. Вот только тогда им всё таки пришлось порезать программу на модули и компилировать их по отдельности.
Ну, это не вопрос модульности, а вопрос скорее агрессивного использования шаблонов.
Кстати, частенько затыкается не компилятор по памяти, а компоновщик.
Да, если им пришлось порезать на модули, значит модули в С++ таки возможны :-)
PS. Кроме того, можно ж было и на 64битной машине собрать 32битное приложение.
PPS. Опять же это всего лишь вопросы оптимизации компиляции, а не принципиальные проблемы при разработке, то есть ошибок от этого в программе не прибавляется.
-
У меня похоже приступ парадокса блаба… Не вижу я этих проблем в С++ (или слишком свыкся?) с модульностью. Можешь привести примеры проблем с которыми регулярно сталкиваешься из за отсутствия модульности в плюсцах?
Хе-хе. Про идеологические проблемы тебе расскажут на оборонкоре ;) Чисто практические - тормозная компиляция, убогие средства навигации, всякие дебильные ODR, порядок инклудов имеет значение, "паразитные" инклуды (какой-нибудь хидер включает другой хидер и в этом хидеря херня, которая мешает тебе жить вот в этом файле) и т.д. За сколько-то лет к этому можно привыкнуть, но блин, 2012 год на дворе... Уже давно проработано как должно быть по-нормальному и все равно... обратная совместимость.
-
Хе-хе. Про идеологические проблемы тебе расскажут на оборонкоре ;) Чисто практические - тормозная компиляция,
Аду и хаскель от тормозной компиляции модульность не спасает. Я даже не говорю про эйфель :-)
убогие средства навигации,
Тут скорее жуткий синтаксис виноват нежели "модульность". Алсо clang постепенно эту проблему решает (то есть парадигма "компилятор как сервис").
всякие дебильные ODR, порядок инклудов имеет значение, "паразитные" инклуды (какой-нибудь хидер включает другой хидер и в этом хидеря херня, которая мешает тебе жить вот в этом файле) и т.д.
Внезапно в нахваливаемом таком модульном D я обнаружил зависимость от порядка импортов модулей :-)
За сколько-то лет к этому можно привыкнуть, но блин, 2012 год на дворе... Уже давно проработано как должно быть по-нормальному и все равно... обратная совместимость.
А где для тебя идеал в пане модульности? В Обероне мне не нравится. В Аде... Наверно лучше всего. Go - фигня. Java/C# - вообще человеческой модульности нема, все отдано на откуп динамическому компоновщику.
-
Хе-хе. Про идеологические проблемы тебе расскажут на оборонкоре ;) Чисто практические - тормозная компиляция,
Аду и хаскель от тормозной компиляции модульность не спасает. Я даже не говорю про эйфель :-)
Как минимум, это спасет от ненужной перекомпиляции.
убогие средства навигации,
Тут скорее жуткий синтаксис виноват нежели "модульность".
Синтаксис - это фигня, по сравнению с перелопачиванием мегабайтов текста, справленного препроцессором. Сравни с килобайтами текста + список импорта (который можно потреблять в бинарном виде непосредственно от компилятора).
Алсо clang постепенно эту проблему решает (то есть парадигма "компилятор как сервис").
Это решение из серии "вырезание гландов через задницу". Можно восхищаться, если не задаваться вопросом "а нафига так?".
Внезапно в нахваливаемом таком модульном D я обнаружил зависимость от порядка импортов модулей :-)
Тем хуже для D ;) Тяжелое инклудное детство...
А где для тебя идеал в пане модульности? В Обероне мне не нравится. В Аде... Наверно лучше всего. Go - фигня. Java/C# - вообще человеческой модульности нема, все отдано на откуп динамическому компоновщику.
Блин, да хоть как-нибудь. В питоне, например, вполне нормально. В шарпе с его юзингами - хреново, но IDE берет удар на себя. В обероне - вроде нормально, но пока не попишешь - нельзя сказать.
-
Аду и хаскель от тормозной компиляции модульность не спасает. Я даже не говорю про эйфель :-)
Как минимум, это спасет от ненужной перекомпиляции.
Предкомпиляция хедеров не спасает? :-)
убогие средства навигации,
Тут скорее жуткий синтаксис виноват нежели "модульность".
Синтаксис - это фигня, по сравнению с перелопачиванием мегабайтов текста, справленного препроцессором. Сравни с килобайтами текста + список импорта (который можно потреблять в бинарном виде непосредственно от компилятора).
Дык и тут можно непосредственно у компилятора потребовать :-) Если хедеры прекомпилированны. Или если все было уже проиндексировано и идет инкрементальное обновление индексов в фоне.
Алсо clang постепенно эту проблему решает (то есть парадигма "компилятор как сервис").
Это решение из серии "вырезание гландов через задницу". Можно восхищаться, если не задаваться вопросом "а нафига так?".
Нет, это принципиально правильная вещь. Ровно так же это делается в Аде, хаскелле и так далее. Нахрена в IDE городить отдельный велосипедный почтикомпилятор, если можно через API общаться с настоящим компилятором который всяко лучше во всем этом разбирается?
А где для тебя идеал в пане модульности? В Обероне мне не нравится. В Аде... Наверно лучше всего. Go - фигня. Java/C# - вообще человеческой модульности нема, все отдано на откуп динамическому компоновщику.
Блин, да хоть как-нибудь. В питоне, например, вполне нормально. В шарпе с его юзингами - хреново, но IDE берет удар на себя. В обероне - вроде нормально, но пока не попишешь - нельзя сказать.
В C# и Java inport/using не нужны вообще. Тебе без всяких импортов доступно ВСЕ до чего линкер может дотянуться. То есть точный аналог Сишечки без инклудов вообще. Ну, поскольку в сигнатуру функций входит не только имя, но и аргументы и возвращаемое значение, получается побезопасней. Так что, сишечка (старая, без инклюдов - до сих пор на код писанный в такой манере натыкаюсь) модульней плюсав?
-
Предкомпиляция хедеров не спасает? :-)
Она усугубляет. Опять решение из серии "по-нормальному не можем, поэтому сделаем через задницу".
Синтаксис - это фигня, по сравнению с перелопачиванием мегабайтов текста, справленного препроцессором. Сравни с килобайтами текста + список импорта (который можно потреблять в бинарном виде непосредственно от компилятора).
Дык и тут можно непосредственно у компилятора потребовать :-) Если хедеры прекомпилированны. Или если все было уже проиндексировано и идет инкрементальное обновление индексов в фоне.
Ты так говоришь, как будет никогда не компилил что-то кроме хелло вордов ;) ТОРМОЗИТ оно. Конкретно твой clang - тоже тормозит. Тормозит с прекомпом. Тормозит, это значит не успевает скомпилить за те доли секунды, которые допустимы для нормальной навигации/автокомплита/....
Это решение из серии "вырезание гландов через задницу". Можно восхищаться, если не задаваться вопросом "а нафига так?".
Нет, это принципиально правильная вещь. Ровно так же это делается в Аде, хаскелле и так далее. Нахрена в IDE городить отдельный велосипедный почтикомпилятор, если можно через API общаться с настоящим компилятором который всяко лучше во всем этом разбирается?
Я с этим и не спорил. Я говорю о том - зачем при этом инклуды? Чтоб сложнее было сделать этот "настоящий компилятор с API"?
В C# и Java inport/using не нужны вообще. Тебе без всяких импортов доступно ВСЕ до чего линкер может дотянуться.
Нету там линкера :) Есть пэкэджи/ассембли. Там доступно все. И это правильно.
То есть точный аналог Сишечки без инклудов вообще.
Гхм. Даже спорить не буду, оставлю на твоей совести ;)
-
Нету там линкера :) Есть пэкэджи/ассембли. Там доступно все. И это правильно.
Ололо! Это ты видимо с явой не трахался :-) Когда в рантайме у тебя одно, а в IDE другое. И либо у тебя ексцепшины из за того, что в рантайме нет "модулей" нужных (class not found exception) либо IDE тупо не видит их и все подчеркивает красным и вообще говорит - не буду компилять, у тебя тут ошибки (хотя ошибок нет и если заставить скомпилять/запустить ручками, то все работает). Это адский ад. И там именно динамический компоновщик используется во всех случаях (и .net и жаба).
Это все разгрести иногда бывает сложнее (я говорю про trueъ j2ee конечно же), чем приплюснутое "не хочу компиляться, и линковаться тоже не хочу".
То есть точный аналог Сишечки без инклудов вообще.
Гхм. Даже спорить не буду, оставлю на твоей совести ;)
Дык оно и есть. Причем это усугубляется отсутствием статической компоновки. Все валится в рантайме при первом обращении к модулю которого ВНЕЗАПНО не оказалось на месте. Кстати примерно то же самое видел и в питоне.
Короче, нема серебряной пули. Ну, либо все существующие отлитые серебряные пули в плане модульности кривы и разбавлены ослиной мочей. :-)