Здравствуйте, trukhin.yuri, Вы писали:
S>>А сколько пользователей винды в мире? в цифрах... TY>94% Windows TY>4% Mac TY>2% Остальные
Это вы погорячились. Такие цыфры были в конце 90'х и верны только для десктопов.
Вообще же, можно оперировать цифрами распространённости WWW-браузеров и на их основе строить предположения той или иной платформы. К слову: Firefox занимает около 97% ниши браузеров на *nix-платформе. На сайте Dell число пользователей, вибирающих Linux вместо Windows превысило число последних очень заметно, что вынудило компанию заняться предустановкой и поддержкой Ubuntu Linux в своих ноутбуках.
Лично я предполагаю рубеж 15%, после которого начинается уверенное завоевание рабочих мест *nix-подобными операционками. Но преодолён ли этот рубеж сейчас, сказать не берусь. Микросовт с выходом Vista взяла таймаут и дала некий карт-бланш Linux'у на десктопах: через год-два можно будет уверенно сказать, что количество *nix-пользователей больше нельзя будет игнорировать просто так, так как в коммерческом плане, особенно в корпоративном секторе, этот сегмент будет самым динамично развивающимся и капиталоёмким.
Кодовая база у всех *nix одна и та же, то есть совместимость, по крайней мере по исходным текстам, обеспечить легче. Выгоднее вкладывать в разработку такого софта, который обеспечит минимальные усилия на сопровождение, и это у *nix-систем уже есть по факту.
Java-куда ни шло -- она всё-таки обеспечивает полную интероперабельность софта между разными платформами. А вот .Net уже опоздала и место ей такое же как у Python, Ruby и Perl на *nix-платформе, то есть "Ещё один язык" (c) Microsoft. .Net больше не платформа -- её опередили распределённые репозитории нативного кода и удобные утилиты инсталляции и менеджмента ПО (Synaptic, Yast и т.д.), которые стирают границы между разными версиями *nix, привнося общие принципы управления прикладным программным обеспечением, нужным конечному пользователю.
Здравствуйте, iZEN, Вы писали:
ZEN>Лично я предполагаю рубеж 15%, после которого начинается уверенное завоевание рабочих мест *nix-подобными операционками. Но преодолён ли этот рубеж сейчас, сказать не берусь. Микросовт с выходом Vista взяла таймаут и дала некий карт-бланш Linux'у на десктопах: через год-два можно будет уверенно сказать, что количество *nix-пользователей больше нельзя будет игнорировать просто так, так как в коммерческом плане, особенно в корпоративном секторе, этот сегмент будет самым динамично развивающимся и капиталоёмким.
Тема начиналась в шараварном форуме, и пока end user шараварки под linux дают прибыль близкую к нулю.
ZEN>Java-куда ни шло -- она всё-таки обеспечивает полную интероперабельность софта между разными платформами. А вот .Net уже опоздала и место ей такое же как у Python, Ruby и Perl на *nix-платформе, то есть "Ещё один язык" (c) Microsoft. .Net больше не платформа -- её опередили распределённые репозитории нативного кода и удобные утилиты инсталляции и менеджмента ПО (Synaptic, Yast и т.д.), которые стирают границы между разными версиями *nix, привнося общие принципы управления прикладным программным обеспечением, нужным конечному пользователю.
Это с каких пор вдруг питон стал хуже переносимым чем ява?
Здравствуйте, FR, Вы писали:
FR>Это с каких пор вдруг питон стал хуже переносимым чем ява?
Я не об этом. Python -- это ещё один язык. Интерес представляют ПЛАТФОРМЫ, переносимые, конечно же (Java, AJAX, например).
.Net -- это платформа только на Windows, на *nix никакая она не платформа, а просто ещё один язык, как и Python, Perl, Ruby, Modula, Lisp и т.д..
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, FR, Вы писали:
FR>>Это с каких пор вдруг питон стал хуже переносимым чем ява?
ZEN>Я не об этом. Python -- это ещё один язык. Интерес представляют ПЛАТФОРМЫ, переносимые, конечно же (Java, AJAX, например). ZEN>.Net -- это платформа только на Windows, на *nix никакая она не платформа, а просто ещё один язык, как и Python, Perl, Ruby, Modula, Lisp и т.д..
Здравствуйте, FR, Вы писали:
FR>Можно определение понятия "платформа" в студию?
Платформа -- это программная оболочка над системой, не требующая от прикладных программистов знаний и применения нативного программирования. Впрочем, возможность этого может быть обеспечена, но не может поощряться (программы с нативным кодом, как правило, непереносимы).
Переносимая платформа сохраняет все свои свойства независимо от природы операционной системы, на которой она работает, и гарантирует однозначное поведение прикладного кода, запущенного на/в такой платформе, на различных операционных системах.
.Net не может считаться платформой на *nix, так как не подтверждена полнота ни одной из его реализаций на отличных от линейки Windows операционках.
ZEN>Платформа -- это программная оболочка над системой, не требующая от прикладных программистов знаний и применения нативного программирования. Впрочем, возможность этого может быть обеспечена, но не может поощряться (программы с нативным кодом, как правило, непереносимы). ZEN>Переносимая платформа сохраняет все свои свойства независимо от природы операционной системы, на которой она работает, и гарантирует однозначное поведение прикладного кода, запущенного на/в такой платформе, на различных операционных системах.
ZEN>.Net не может считаться платформой на *nix, так как не подтверждена полнота ни одной из его реализаций на отличных от линейки Windows операционках.
QT, wxWidgets, Ultimate++, Python да и многие другие межплатформенные скриптовые языки тогда можно отнести к платформам, правильно?!
ZEN>>Платформа -- это программная оболочка над системой, не требующая от прикладных программистов знаний и применения нативного программирования. Впрочем, возможность этого может быть обеспечена, но не может поощряться (программы с нативным кодом, как правило, непереносимы). ZEN>>Переносимая платформа сохраняет все свои свойства независимо от природы операционной системы, на которой она работает, и гарантирует однозначное поведение прикладного кода, запущенного на/в такой платформе, на различных операционных системах.
ZEN>>.Net не может считаться платформой на *nix, так как не подтверждена полнота ни одной из его реализаций на отличных от линейки Windows операционках.
В>QT, wxWidgets, Ultimate++, Python да и многие другие межплатформенные скриптовые языки тогда можно отнести к платформам, правильно?!
Нет. Это библиотеки и языки. У каждого из них нет целостности и "завершённости", чтобы полностью "закрыть" (или подменить -- кому как больше нравится) собой системный API. Они созданы для выполнения задач в конкретном аспекте функционирования, но не в целом по системе. На Java точно можно написать операционную оболочку (пример: SavaJe и JNode) над нативным нано-ядром, на других языках этого делать никто не пробовал, потому как они -- не платформа. AJAX уже использовали для создания виртуальной операционной системы, функционирующей в броузере, я уж не говорю об успешных попытках сделать на нём офисную десктопную среду с хранилищем данных пользователя в Сети. Такая виртуализация не доступна языкам типа Perl или Python, работающим сами по себе, -- всё равно язык должен "опираться" на другие языки, может быть использовать нативные средства операционной системы, не всегда подменяя собой явные (то есть заметные программисту; он знает, в какой ОС работает) системные вызовы своим набором API.
Так вот, неполнота API того или иного языка/набора библиотек для прикладного программирования не делает её платформой в широком понимании. К платформе относятся: GCC и userland в Unix как целостность, опирающаяся на системные вызовы ядра. Языки Perl, Python, Ruby, Modula, Lisp по-отдельности абстрагируют для прикладного программиста лишь узкую часть системных вызовов и являются прослойкой между прикладным кодом на них и библиотечным кодом, написанным на C, находящимся в ядре и в userland. Каждый из этих языков не может решить задачи другого, потому что они создавались не как универсальные языки, а как языки для быстрого и эффективного решения определённого круга задач в своей области. Платформа же предполагает универсальные решения с использованием одного языка, будь-то Java или MSIL, или AJAX (динамический HTML на стороне пользователя).
Не буду говорить за Perl, так как я его не знаю. А вот с Питоном у тебя точно не сходиться.
iZ>Нет. Это библиотеки и языки. У каждого из них нет целостности и "завершённости", чтобы полностью "закрыть" (или подменить -- кому как больше нравится) собой системный API.
Питон вполне "закрывает" собой системное АПИ. Ни разу не приходилось использовать системные АПИ.
iZ>Они созданы для выполнения задач в конкретном аспекте функционирования, но не в целом по системе. На Java точно можно написать операционную оболочку (пример: SavaJe и JNode) над нативным нано-ядром, на других языках этого делать никто не пробовал, потому как они -- не платформа.
А тебе не приходило в голову, что не пытались, потому что никому это не надо. Я на Питоне могу спокойно писать для Web, создавать desktop-приложения, серверные приложения. Что я не могу создать на Питоне?
iZ>AJAX уже использовали для создания виртуальной операционной системы, функционирующей в броузере, я уж не говорю об успешных попытках сделать на нём офисную десктопную среду с хранилищем данных пользователя в Сети.
Знаю команду, которая создает специализированнюу систему документооборота на Питоне. В состав этой системы сходит аналог Ворда.
iZ>Такая виртуализация не доступна языкам типа Perl или Python, работающим сами по себе, -- всё равно язык должен "опираться" на другие языки,
Что значит "опираться на другие языки"?
iZ>может быть использовать нативные средства операционной системы, не всегда подменяя собой явные (то есть заметные программисту; он знает, в какой ОС работает) системные вызовы своим набором API.
Ни разу не понадобилось на Питоне в какой ОС я работаю. В той же java тоже не всегда удается абстрагироваться от ОС. Например, на моей старой работе приятелю пришлось прикручивать к java прогу COM-объекты. А они есть только под виндой. Вот и приходилось смотреть где прога работает.
iZ>Так вот, неполнота API того или иного языка/набора библиотек для прикладного программирования не делает её платформой в широком понимании. К платформе относятся: GCC и userland в Unix как целостность, опирающаяся на системные вызовы ядра. Языки Perl, Python, Ruby, Modula, Lisp по-отдельности абстрагируют для прикладного программиста лишь узкую часть системных вызовов и являются прослойкой между прикладным кодом на них и библиотечным кодом, написанным на C, находящимся в ядре и в userland. Каждый из этих языков не может решить задачи другого, потому что они создавались не как универсальные языки, а как языки для быстрого и эффективного решения определённого круга задач в своей области.
Какие задачи я не могу решить на Питоне и могу на Java? Питон как раз универсальный язык.
Здравствуйте, romangr, Вы писали:
R>Здравствуйте, trukhin.yuri, Вы писали:
TY>>О господи. Чего только не услышишь. Office 2007 — .net
R>Это в каком месте?
Здравствуйте, ambel-vlad, Вы писали:
AV>А тебе не приходило в голову, что не пытались, потому что никому это не надо. Я на Питоне могу спокойно писать для Web, создавать desktop-приложения, серверные приложения. Что я не могу создать на Питоне?
Ну, вот скажем кмопилятор сложного языка. Точнее наверно можешь, только будет это сложно и работать он будет очень медленно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jenyavb, Вы писали:
TY>>Сам сказал — требовал 1,1. Так поставь его! 2,0 и 1,1 — две разные виртуальные машины.
J>.Net — не виртуальная машина. IL при jit-компиляции компилится в native.
Ява тоже. Понятие "виртуальная машина" само по себе виртуальное. Нет никакой машины. Они виртуальна. Просто разработчик думает, что он пишет не под настоящую машину с ее проблемами (разными процессорами, версиями ОС и т.п.), а под некую универсальную машину. А уже рантайм думает как заставить работать программу написанную под виртуальную машину на совершенно реальном компьютере с соврешенно реальными ОС, памтьяю, процессором и т.п.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, вот скажем кмопилятор сложного языка. Точнее наверно можешь, только будет это сложно и работать он будет очень медленно.
Ну жаба в этом случае не сильно лучше. Разве что работать быстрее будет.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi iZEN
AV>Не буду говорить за Perl, так как я его не знаю. А вот с Питоном у тебя точно не сходиться.
iZ>>Нет. Это библиотеки и языки. У каждого из них нет целостности и "завершённости", чтобы полностью "закрыть" (или подменить -- кому как больше нравится) собой системный API. AV>Питон вполне "закрывает" собой системное АПИ. Ни разу не приходилось использовать системные АПИ.
Но это, вообще-то, не значит, что вы пытались охватить всю функциональную область традиционной операционной системы.
iZ>>Они созданы для выполнения задач в конкретном аспекте функционирования, но не в целом по системе. На Java точно можно написать операционную оболочку (пример: SavaJe и JNode) над нативным нано-ядром, на других языках этого делать никто не пробовал, потому как они -- не платформа. AV>А тебе не приходило в голову, что не пытались, потому что никому это не надо. Я на Питоне могу спокойно писать для Web, создавать desktop-приложения, серверные приложения. Что я не могу создать на Питоне?
На Питоне нельзя создать аналог сервлетов и EJB.
iZ>>AJAX уже использовали для создания виртуальной операционной системы, функционирующей в броузере, я уж не говорю об успешных попытках сделать на нём офисную десктопную среду с хранилищем данных пользователя в Сети. AV>Знаю команду, которая создает специализированнюу систему документооборота на Питоне. В состав этой системы сходит аналог Ворда.
Она вся на Пионе будет написана?
iZ>>Такая виртуализация не доступна языкам типа Perl или Python, работающим сами по себе, -- всё равно язык должен "опираться" на другие языки, AV>Что значит "опираться на другие языки"?
Грубо говоря: использовать нативные вызовы в прикладных программах и наоборот, могут использовать их нативные программы. Примеров не счесть в Unix-подобных операционках. Perl входит в зависимости к большому числу программ.
iZ>>может быть использовать нативные средства операционной системы, не всегда подменяя собой явные (то есть заметные программисту; он знает, в какой ОС работает) системные вызовы своим набором API. AV>Ни разу не понадобилось на Питоне в какой ОС я работаю. В той же java тоже не всегда удается абстрагироваться от ОС. Например, на моей старой работе приятелю пришлось прикручивать к java прогу COM-объекты. А они есть только под виндой. Вот и приходилось смотреть где прога работает.
Можно подумать, что большинство Java-программистов только и думают, как сделать свои приложения непереносимыми, заменяя использование явных библиотек JNI-вызовами функций API операционок.
iZ>>Так вот, неполнота API того или иного языка/набора библиотек для прикладного программирования не делает её платформой в широком понимании. К платформе относятся: GCC и userland в Unix как целостность, опирающаяся на системные вызовы ядра. Языки Perl, Python, Ruby, Modula, Lisp по-отдельности абстрагируют для прикладного программиста лишь узкую часть системных вызовов и являются прослойкой между прикладным кодом на них и библиотечным кодом, написанным на C, находящимся в ядре и в userland. Каждый из этих языков не может решить задачи другого, потому что они создавались не как универсальные языки, а как языки для быстрого и эффективного решения определённого круга задач в своей области. AV>Какие задачи я не могу решить на Питоне и могу на Java? Питон как раз универсальный язык.
Обработку фотографий нельзя сделать на Питоне, на Java -- можно. Ещё предложите вариант Java3D на Питоне. Не слабо реализовать JSR 1 на Питоне?
Есть ли вообще полные аналоги/близкие аналоги питоновских реализаций вот этих спецификаций: http://jcp.org/en/jsr/all
чтобы как можно плотнее закрыть системные API от программистов-прикладников?
Hi VladD2
AV>>А тебе не приходило в голову, что не пытались, потому что никому это не надо. Я на Питоне могу спокойно писать для Web, создавать desktop-приложения, серверные приложения. Что я не могу создать на Питоне?
V>Ну, вот скажем кмопилятор сложного языка. Точнее наверно можешь, только будет это сложно и работать он будет очень медленно.
Что этому мешает? Почему на других язык4ах это сделать можно, а на Питоне нет? Или почему на других языках не сложно, а на Питоне сложно?
Про скорость. Во-первых, про нее не говорилось. Во-вторых, насколько медленно? Будет ли это критично? А то по моим наблюдениям, скорость компилятора никак не является узким местом в процессе разработки.
Hi iZEN
AV>>Не буду говорить за Perl, так как я его не знаю. А вот с Питоном у тебя точно не сходиться.
iZ>>>Нет. Это библиотеки и языки. У каждого из них нет целостности и "завершённости", чтобы полностью "закрыть" (или подменить -- кому как больше нравится) собой системный API. AV>>Питон вполне "закрывает" собой системное АПИ. Ни разу не приходилось использовать системные АПИ.
iZ>Но это, вообще-то, не значит, что вы пытались охватить всю функциональную область традиционной операционной системы.
А java охватывает? Ни одна платформа (в том числе java) исходя из твоего определения не может охватить всю функциональную область традиционной операционной системы. Ибо слишком много различий. И, если попытаться охватить все, то получиться такой монстр, которым пользоваться будет невозможно. Это раз.
А во вторых, приложения, которые я разрабатывал на Питоне, по были такими же как и на мои приятели на java.
iZ>>>Они созданы для выполнения задач в конкретном аспекте функционирования, но не в целом по системе. На Java точно можно написать операционную оболочку (пример: SavaJe и JNode) над нативным нано-ядром, на других языках этого делать никто не пробовал, потому как они -- не платформа. AV>>А тебе не приходило в голову, что не пытались, потому что никому это не надо. Я на Питоне могу спокойно писать для Web, создавать desktop-приложения, серверные приложения. Что я не могу создать на Питоне?
iZ>На Питоне нельзя создать аналог сервлетов и EJB.
Да ну? А на что тогда Zope, Plone и компания? Почитай и убедись, что не на одной java можно писать под Web.
iZ>>>AJAX уже использовали для создания виртуальной операционной системы, функционирующей в броузере, я уж не говорю об успешных попытках сделать на нём офисную десктопную среду с хранилищем данных пользователя в Сети. AV>>Знаю команду, которая создает специализированнюу систему документооборота на Питоне. В состав этой системы сходит аналог Ворда.
iZ>Она вся на Пионе будет написана?
Практически вся. Только пару функций, к скорости которых были очень жесткие требования, были написаны на С++. Предвижу твую следующую твою фразу. Поэтому спрашиваю сразу. Что ты будешь делать, если некоторые функции твоей проги на java не будет удовлетворять требованиям по скорости?
iZ>>>Такая виртуализация не доступна языкам типа Perl или Python, работающим сами по себе, -- всё равно язык должен "опираться" на другие языки, AV>>Что значит "опираться на другие языки"?
iZ>Грубо говоря: использовать нативные вызовы в прикладных программах
Во-первых, ты пробовал программировать на Питоне? Потребность вызова нативных функций там мизерна. А что ты делал бы если java тебе не предоставляла необходимой функциональности? Например, как ты сделал бы в java 1.4 сворачивание своей проги в SystemTray?
iZ>и наоборот, могут использовать их нативные программы. Примеров не счесть в Unix-подобных операционках. Perl входит в зависимости к большому числу программ.
Здесь вообще не понимаю претензий. Чем отличается ситуация если другой программер использует мою прогу на Питоне из своей, от ситуации, когда он же использует твою прогу на java? И что плохого в Питоне в том, что кто-то в своих программных комплексах использует программы написанные на Питоне. Мне наоборот кажеться, это только в плюс Питону.
iZ>>>может быть использовать нативные средства операционной системы, не всегда подменяя собой явные (то есть заметные программисту; он знает, в какой ОС работает) системные вызовы своим набором API. AV>>Ни разу не понадобилось на Питоне в какой ОС я работаю. В той же java тоже не всегда удается абстрагироваться от ОС. Например, на моей старой работе приятелю пришлось прикручивать к java прогу COM-объекты. А они есть только под виндой. Вот и приходилось смотреть где прога работает.
iZ>Можно подумать, что большинство Java-программистов только и думают, как сделать свои приложения непереносимыми, заменяя использование явных библиотек JNI-вызовами функций API операционок.
Можно подумать, что большинство Python-программистов только и думают, как сделать свои приложения непереносимыми, заменяя использование явных библиотек вызовами функций API операционок.
iZ>>>Так вот, неполнота API того или иного языка/набора библиотек для прикладного программирования не делает её платформой в широком понимании. К платформе относятся: GCC и userland в Unix как целостность, опирающаяся на системные вызовы ядра. Языки Perl, Python, Ruby, Modula, Lisp по-отдельности абстрагируют для прикладного программиста лишь узкую часть системных вызовов и являются прослойкой между прикладным кодом на них и библиотечным кодом, написанным на C, находящимся в ядре и в userland. Каждый из этих языков не может решить задачи другого, потому что они создавались не как универсальные языки, а как языки для быстрого и эффективного решения определённого круга задач в своей области. AV>>Какие задачи я не могу решить на Питоне и могу на Java? Питон как раз универсальный язык.
iZ>Обработку фотографий нельзя сделать на Питоне, на Java -- можно.
Да ну? Библиотеки для работы с графикой на Питоне есть. Так что мимо.
iZ>Ещё предложите вариант Java3D на Питоне.
Я вообще-то с графикой, и в частности с 3D, в Питоне не работал. Поэтому прямо сейчас назвать такие библиотеки не могу. Но более чем уверен, что они есть. Если тебе интересно, то могу поискать.
iZ>Не слабо реализовать JSR 1 на Питоне?
Что такое JSR 1?
iZ>Есть ли вообще полные аналоги/близкие аналоги питоновских реализаций вот этих спецификаций: http://jcp.org/en/jsr/all чтобы как можно плотнее закрыть системные API от программистов-прикладников?
Библиотек для Питона очень много. Вероятно, что для java их больше. Но надо учесть, что Питон фактически развивается на энтузиазме. Но в целом, необходимость образщения к системному АПИ возникает ну очень редко.
Здравствуйте, ambel-vlad, Вы писали:
AV>Что этому мешает? Почему на других язык4ах это сделать можно, а на Питоне нет? Или почему на других языках не сложно, а на Питоне сложно?
Ну по тому что ты знаешь слишком мало других язычков.
Некоторые из других язычков (которые ты по всей видимости не знаешь) имеют pattern matching при разработке компиляторов фича абсолютно необходимая, а в питоне ее нет.
AV>Про скорость. Во-первых, про нее не говорилось. Во-вторых, насколько медленно? Будет ли это критично? А то по моим наблюдениям, скорость компилятора никак не является узким местом в процессе разработки.
Скорость важна всегда.
Причем если на 10-20 процентов можно забить при условии что мы получи серьезное удешевление разработки то забить на питоновские 10 раз не получится.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Hi WolfHound
AV>>Что этому мешает? Почему на других язык4ах это сделать можно, а на Питоне нет? Или почему на других языках не сложно, а на Питоне сложно? WH>Ну по тому что ты знаешь слишком мало других язычков.
Сколько мало, а сколько много? И откуда тебе известно сколько и какие языки я знаю?
WH>Некоторые из других язычков (которые ты по всей видимости не знаешь) имеют pattern matching при разработке компиляторов фича абсолютно необходимая, а в питоне ее нет.
Так и ждал этого. А как обходятся в языках где pattern matching нет? А то сколько не вижу промышленных компиляторов, что-то большинство написано на языках где pattern matching нет. И ничего, живут же как-то. Да, эта фича облегчает написание. Но она не является настолько жизненно важной, чтобы без нее никак. А принципиальных причин, почему нельзя на Питоне написать компилер так и не было приведено.
AV>>Про скорость. Во-первых, про нее не говорилось. Во-вторых, насколько медленно? Будет ли это критично? А то по моим наблюдениям, скорость компилятора никак не является узким местом в процессе разработки. WH>Скорость важна всегда.
А почему-то когда идет речь про сравнение скорости работы managed/unmanaged кода, то скорость не важна. А сейчас она уже стала важна.
WH>Причем если на 10-20 процентов можно забить при условии что мы получи серьезное удешевление разработки то забить на питоновские 10 раз не получится.
Сколько процентов можно пожертвовать?
Тем более, что критические по скорости функции я могу написать на С/С++. Не думаю, что их там будет очень много.
То есть принципиальных препятствий для написания компилятора на Питоне нет? Я правильно понял?
А так врятли.
