Через пятнадцать лет останется джава или останется C# в масcовом использовании?
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Через пятнадцать лет останется джава или останется C# в масcовом использовании?
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Через пятнадцать лет останется джава или останется C# в масcовом использовании?
С момента публикации топика прошло 8 лет. Осталось еще 7. То есть большую половину отведенного топикстартером периода мы уже прошли. Как видим, .NET становится только лучше, выше, быстрее. Захватывает новые области и постоянно развивается. А Java... а что там Java -даже как-то и не интересно, когда есть .NET Встретимся через 7 лет? :)
Как видим, .NET становится только лучше, выше, быстрее. Захватывает новые области и постоянно развивается.
А у адептов дотНета все еще подгорает настолько что они некропостят в
Пока что все выглядит так:
Sep 2018 Sep 2017 Change Programming Language Ratings Change 1 1 Java 17.436% +4.75% 2 2 C 15.447% +8.06% 3 5 change Python 7.653% +4.67% 4 3 change C++ 7.394% +1.83% 5 8 change Visual Basic .NET 5.308% +3.33% 6 4 change C# 3.295% -1.48%
Боюсь, что вы неправильно определили источник дыма. Он у вас за спиной ;)
былобы круто графики популярностей за последниие 10 лет получить )
былобы круто графики популярностей за последниие 10 лет получить )
Там нет якоря, поэтому вам прийдется прокручить вниз самому :)
Перший результат з гугла за запитом Java vs C# показує що доля ринку Java — 4.39%, C# - 0.14%.
www.datanyze.com/...mming-languages/java-vs-c
Про яке захоплення областей мова?
Може тому що платформа .NET? Ми, власне, ніколи себе сі-шарпістами чи шарпістами не називаємо, лише донтетчикамм.
Правда? А тут как раз наоборот получается — www.datanyze.com/...anguages/java-vs-asp.net
А у джава ещё остались какие-то достоинства по сравнению с дотнетом кроме кучи написанного кода?
Java как виртуальная машина никогда умрет.
А что касается языка, то судя по анонсам, лет через 15 это может быть совсем другой язык.
А что касается языка, то судя по анонсам, лет через 15 это может совсем другой язык.
Не исключено что этот язык будет Java8 :(
Неправильно выразился. Как раз это я имел в виду.
Судя по анонсам в джаву собираются добавлять много такого, что сделает из нее что то вроде похожее на руби или скалу.
много такого, что сделает из нее что то вроде похожее на руби или скалу.
Это ж чего такого?
Ну это только обещания, но вроде как пообещали — лямбды, введение дефолтных методов (похоже на трейты в скала), функции высшего порядка.
функции высшего порядка.
Не обещали.
введение дефолтных методов (похоже на трейты в скала),
От ни капли. Дефендеры — это развитие интерфейсов (по факту костыль, но таки общеполезный), трейты — это больше про миксины.
лямбды
Упрошенный синтаксис + (пока) минорные оптимизации для ... анонимных классов. Которые появились когда?
Java не умрет, станет новым коболом. Ее место займет Scala. С# будет один саппорт и багфикс, и неизвестно что с MS будет через 15 лет
Большинство ИТ-инфраструктуры бизнеса уйдет в облака. Рынок любит зарабатывать дешевыми и быстрыми методами, поэтому и был изобретен конвейер. Вся потребительская челядь :) будет полжизни плавать в тех же облачных сервисах. Т.е. морда как всегда какой-нибудь HTML10 и CSS6. А вот бэкэнд будет писан на куче разных языков в зависимости от платформы. Одного языка точно не будет.
А если приземленнее: что там решили с концом света: мне зимние сапоги покупать или я в осенних дохожу?.
Через 15 лет будет следующее «говорят, что в Москве кур доят, а в Рязани — грибы с глазами».
C# останется если Микрософт себя не погубит и сможет хотя бы не сдавать позиций на рынке.
Все среды разработки будут схожи на Step 5-7(LAD, FBD, STL) — цель быстрые средства разработки.
Десктопные платформы умирают, а вместе с ними мне кажется неизбежным и закат «традиционных» платформ разработки. Уже сейчас нужны «быстрые» средства разработки, с супер-коротким циклом прототипирования, типа Rails или Meteor или Bootstrap. Дальше эта тенденция будет только ускоряться, мне кажется.
э... по моему, из-за количества прототипов уже интернет скоро закончится.
десктопы же, думается, станут оборудованием профессионалов. Никакое скоростное прототипирование не поможет в конкуренции скажем CAD систем.
Мне тоже так кажется. Добавлю, что для обычных пользователей веб-ос — отличное решение.
Так уже давно. Из десктопных платформ наполовину-жив развечто сишарп со своими формсами. Дельфи вон загнулся, десктопные кресты тоже скорей мертвы чем живы.
Я вижу три равновероятных сценария развития событий.
Через пятнадцать лет саммыми массовыми языками программирования будут естественные языки. Программисту достаточно будет громко сказать «Привет, Мир!», или показать это жестом, и голографичекий принтер сразу напечатает это на любой электронной бумаге.
Через пятнадцать лет программистов заменят роботами и самым популярным языком снова станет ассемблер. Система логически замкнётся и роботы будут писать программы для роботов, а люди только подчинятся. Причём отдельные роботы будут считать что настоящий язык это машинные кода, а майкрософт просто украл ассемблер и это не хардкор.
Через пятнадцать лет не будет никаких языков программирования, потому, что всё наконец запрограммируют и наступит рай на земле и программисты вернутся к своим обычным занятиям — пахоте яровых, конвейерной сборке, уборке помещений, продажам и продажам по телефону.
Через пятнадцать лет программистов заменят роботами и самым популярным языком снова станет ассемблер. Система логически замкнётся и роботы будут писать программы для роботов, а люди только подчинятся. Причём отдельные роботы будут считать что настоящий язык это машинные кода, а майкрософт просто украл ассемблер и это не хардкор.
Это называется технологической сингулярностью, только там будет не ассемблер, а язык совсем другого характера, я как раз таким занимаюсь.
Название этого коррелирует только с сортом утреннего виски у сайнсфикшн писателей
я не хотел тебя троллить. само написалось. иди строй свой скайнет.
Ещё можешь занять себя в этот период прочтением Суммы Технологий С.Лема.
Только не забудь мне пожалуйста сообщить когда у тебя этот период закончится.
для того чтобы заниматься языком будущего — вам стоит вначале заняться изучением связи мышления и обычного языка. по уровню троллинга — у вас слишком косная, слишком традиционалиская речь, для того чтобы создавать нечто качественно новое.
Через пятнадцать лет самыми массовыми языками программирования будут естественные языки.
вряд ли. слишком многозначны и контекстно-зависимые. не годятся для инженерии. а вот DSL — да, вполне, об этом писал.
«Роботы» и «все запрограммируют» — наверное когда-нибудь такое случится. сложно сказать когда, и в какой мере.
Признаться, я хотел пошутить, но как-то не сложилось, видимо.
или тролля, который объяснит тебе — до чего ж ты даун :)
Ты прав сережа, во всем виноваты троли, которые не понимают твоих безспорно тонких шуток
DSL это такая вещь, которую каждый захочет писать сам и под себя.
Как то не ассоциируется у меня оно с массовостью. Только с сугубо специфическими (и совсем необязательно связанными с программированием) и очень локальными задачами.
DSL это такая вещь, которую каждый захочет писать сам и под себя.
захочет то захочет, дык кто ж ему даст :)
Как то не ассоциируется у меня оно с массовостью.
а это не важно - хоть стопицот DSL сотвори - а жена тебе - а деньги где?
на то они и DSLТолько с сугубо специфическими
и тоже самое будет что и с фреймворками сейчас - да пиши свой лисапед, только вот...
врядли.очень локальными задачами.
а вот указание руководства - есть такой расхваливаемый DSL для нашей специфики - берите и пишите на нем - будет обычным делом
И как DSL может охватить масштабный круг задач?
Их делают для спецов-непрограммистов. С низким порогом вхождения и нацеленностью на узкую задачу.А самому программисту DSL просто не хватит.
И если есть какая то локальная задача, типа запросы к БД стряпать, то проще сисадмина напрячь, ну или профильного спеца заставить учить.
А если задача состоит в том, чтобы вот заставить девайс делать, что заказчик пожелает, там нужно что то более низкоуровневое.В таких случаях нельзя просто нарисовать приложение. И через 15 лет нельзя будет.
Слишком широкий круг задач, чтобы можно было сделать кучу популярных, отлаженных DSL, которые будут их все покрывать.
Можно конечно, дать возможность программисту создания DSL под каждый свой проект. Тогда каждый накодит что то свое теплое и ламповое.Но кто ж нам разрешит...
И как DSL может охватить масштабный круг задач?
наоборот, как все усложняющиеся специализации можно охватить с помощью универсального языка? :)
не обязательно - непрограммистов.Их делают для спецов-непрограммистов.
Зависит от абстракций в DSL.
многие скриптовые довески к ПО - уже выполняют роль DSL, но требуют - знаний азов программирования. Например язык в Gimp, забыл название. И фильтры, и преобразования на нем пишутся.
Какого уровня задач программисту? Одни программисты пишут компиляторы, другие - дописывают "джумлу".А самому программисту DSL просто не хватит.
Первым - не хватит, вторые и так - специализированы.
Для запросов уже есть язык. Если к реляционным БД - это SQL :)И если есть какая то локальная задача, типа запросы к БД стряпать
но уже потребности ORM - порождают головняк и фреймворки.
какой девайс, какого уровня действия от него ждет заказчик?А если задача состоит в том, чтобы вот заставить девайс делать, что заказчик пожелает, там нужно что то более низкоуровневое.
если вывести фотку котенка и мяукнуть - это другой.
Слишком широкий круг задач уже породил разделение наСлишком широкий круг задач, чтобы можно было сделать кучу популярных, отлаженных DSL, которые будут их все покрывать.
И уже сейчас нет такого ЯП, одинаково удобного для разработки всех этих видов ПО. И тьюринг полнота ЯП - проблем никак не решает.
А вот отдаленность ЯП от предметной области порождает проблемы: проектирования, разработки и поддержки.а также - передачу знаний, новому программисту входить в прикладную область приходится долго, решения которые есть - тоже долго, потому что - низкоуровневы.
Но - не нужно. Разве что - внутренний DSL, для сложного проекта.Можно конечно, дать возможность программисту создания DSL под каждый свой проект
а так как выражено будет описание на ЯП более близком к предметной области - то и читать, и модифицировать его будет - легче.
В идеале - да сами законы должны писаться на более формальном языке :) Но это уже к "Основанию" Азимова :) совсем далеко.
Тогда каждый накодит что то свое теплое и ламповое.
Повторюсь - как и сейчас далеко не каждому разрешается выбирать ЯП какой ему хочется, так и тогда будет.
DSL - на самом деле очень широкое понятие. И те о которых намекаю - придут наверное не скоро, если вообще придут.
Но ЯП призваны решать задачисужение контекстного пространства (не искал как академически это называется, но языкоделам это известно)
первое более менее развитием ЯП обеспечивается.а со вторым - вечная проблема.
DSL - ее то и призваны решить
P.S.Можно и нужно дискутировать о существующих подходах и реализациях
но сама эта мотивация - по моему все обостряется.
Можно конечно, дать возможность программисту создания DSL под каждый свой проект. Тогда каждый накодит что то свое теплое и ламповое.
Для этого и есть MPS. Где сам язык можна определить в терминах более низкоуровневой джавы (или любого другого языка, даже смеси других дэселей), а логику писать уже на дсэле. Это будет куда более ДДД, чем то что есть сейчас.
Не толькоДля этого и есть MPS
Не через пятнадцать лет, а гораздо раньше привычный стек веб-приложения будет выглядеть примерно так:
А что будет через 15 лет предположить невозможно.
Самый ненавистный многими язык программирования, а зря, ведь это единственный истинно-кроссплатформенный язык, он работает там где есть браузер, а браузер есть везде.
Думаю, да, захватит. Безотносительно личных предпочтений очень уж много преимуществ у описанного мною стека. Из-за инертности людей и рынка это пока еще не мейнстрим, но скоро станет мейнстримом.
Причем тут «круче и моднее»? Вы действительно считаете, что нет ощутимых преимуществ для многих задач?
Поэтому NoSQL + node.js — это самые лучшие инструменты для большинства задач в вебе. И не в вебе тоже (вообще круто, можно ведь подымать Node.js и NoSQL локально, и писать точно также как под веб, и рич интерфейс на JS и HTML5 в помощь) , так как выше уже было написано, JS — единственно истинный кросс-платформенный язык (вот только Twisted тогда нужно вычеркнуть с его Питоном)
Что касается NoSQL. Зачастую мы сталкиваемся с необходимостью хранить объекты. Нам не нужна их декомпозиция в 3NF, так как в реальности многие объекты нам нужны в виде единого и неделимого целого. Очевидно, что NoSQL предоставляет лучший инструментарий для этого как с точки зрения производительности, так и с точки зрения программных интерфейсов.
Что касается Node.js. Тут плюсов очень много. Это и возможность использования одного языка по всему стеку, и возможность быстро обслужить запрос и продолжить выполнение затратной логики после отправки ответа, и нативная поддержка JSON, который стал стандартом де-факто для обмена данными. Список можно продолжить.
Что касается статического (по возможности) контента и богатой JavaScript логики. Тут все очевидно. Этот подход позволяет перенести нагрузку с сервера в браузеры. Так приложение работает быстрее, а операционные расходы сокращаются. Кроме того, когда это необходимо, статику можно разместить в CDN и, таким образом, еще сильнее улучшить показатели производительности.
Я перечислил только некоторые преимущества. На самом деле их больше. Разумеется, у традиционных технологий тоже есть сильные стороны. Но если посмотреть правде в глаза, самая сильная их сторона — это традиционность. И это не очень убедительно.
ну насчет богатого клиента — то тут вы конечно же правы. интерфейс становится более отзывчивым.
ну да, но для каких-то нужд они всё-таки разработали кассандру. а еще hbase используют.
На касандру они забили болт, а hbase используют для организации текстового поиска по сообщениям, по крайней мере так написано в интернетах.
ну я про кассандру писал лишь к тому, что текущие реализации документопомоек подходят не всем и они лепят свои реализации
Что касается NoSQL. Зачастую мы сталкиваемся с необходимостью хранить объекты. Нам не нужна их декомпозиция в 3NF, так как в реальности многие объекты нам нужны в виде единого и неделимого целого. Очевидно, что NoSQL предоставляет лучший инструментарий для этого как с точки зрения производительности, так и с точки зрения программных интерфейсов.
NoSql != обьектные базы. Последним 100 лет в обед уже.
Это уже терминологические споры. Понятное дело, что когда в 2012 году мы говорим NoSQL, подразумеваем в первую очередь MongoDB, во вторую — Redis. Хоть у них и разные контексты применения. И говоря о преимуществах использования NoSQL мы как правило говорим о преимуществах MongoDB в сравнении с MySQL и MS SQL. «Столетние объектные базы» как-то выпадают из такой дискуссии.
Ну и mongodb не может быть образцом для обьектной базы, чему свидетельствует зоопарк ORM напложеных вокруг него.
тупая запись и тупое считывание.
потому что они, NoSQL и появились ради обильного тупого считывания :)... и тупое считывание.
будь то облачная инфраструктура, где требуется легким движением подкидывать узлов для обработки
а браузер есть везде.Что правда, и с одинаковым API? Не говоря уже о том что API браузера недостаточно для многих задач. JS гибкий, приятный язык, но ни как не истинно кроссплатформенный, и никак не самый лучший (если такой вообще есть)...
В предыдущем комментарии совершается та же самая ошибка, NoSQL — не заменяет везде классические реляционные СУБД.
EDIT:
На самом деле, так можно сказать и про С/C++, компиляторы есть везде (точнее во всё).
Да и виртуальные машины Java, тоже есть везде, даже есть там где нету полноценного браузера (мобильные телефоны которые ещё недавно выпускались).
Если игнорировать API и какие-то различия в среде в которой код выполняется (у браузеров тоже есть различия), то тот же C# есть на линуксе, маке, винде, iOS, Android.
NoSQL — не заменяет везде классические реляционные СУБД.
Везде — действительно не заменяет. Но во многих приложениях заменяет. Причем очень успешно.
Но во многих приложениях заменяет.
я бы сказал — не во многих, а в известных и обсуждаемых.
почему вообще воскрес NoSQL, ведь «scheme free» базам и был когда-то ответ в виде RDBMS, и вытеснили они их.
а воскрес, потому что появились задачи которых не было — сотни тысяч одновременных запросов, причем не связанных между собой.Они не SQL заменяют, а просто на шпагат умеют садиться.
Вот если мы скажем DDBS(distributed database system), и будем рассуждать о них, тогда многое прояснится :)
Самый ненавистный многими язык программирования, а зря,
Не зря, потому что более хреново разработанного языка с таким количеством wtf’ов на единицу кода ещё надо поискать, местами он переплёвывает по количеству диверсий даже PHP (что надо было особо постараться). Лет через 5, если его не исправят, начнётся движение за введение чего-то получше в веб (точнее, то, чем веб станет).
Концептуально он неплох, его просто исказил сишный синтаксис.
Никакой Си не даст результат, что "5"-3==2, но "5"+3=="53″. И точно так же никакой Си со своим синтаксисом не даст того, что если после слова return перевести строку, то выражение за ним проигнорируется в ноль. Это всё PHP’шные выбредки.
С приведением типов в JS сильный перебор, но я не о том. Например, нельзя было разрешать объявлять локальные переменные где попало, а ля Си. Кстати, про JS2 знаете? Вам должно понравиться.
я практически уверен, что лет так 6 назад так же безапелляционно утверждал, что в вебе будут только рельсы и пхп умрет. Но вот прошло пять лет и пхп живее всех живых, а руби язык для хипстеров
Я не говорю о том, что что-то «умрет». Это, действительно, было бы безапеляционным заявлением. Очень уж много всего сделано на технологиях, которые сейчас являются мейнстримом. Просто для многих применений выбор традиционных технологий обусловлен именно традиционностью. Один только класс ORM-продуктов заставляет задуматься, что RDBMS часто — компромисс. То же в какой-то мере можно сказать о системах очередей, которые становятся неизбежными в ситуациях, когда нельзя отправить ответ клиенту и продолжить делать «что-то еще».
вчера были модными рельсы, сегодня нод жс, завтра еще что-то
ну не реляционная база данных — это ведь тоже компромисс.
Смотря для какой задачи. Уверен, если вы будете выбирать способ хранения исходя из задачи, а не привычки, то очень часто это будет NoSQL. Хотя, само собой, RDBMS «никто не отменял».
и динамическая типизация — компромис. и отсутствие нормального ООП — это компромис.
Не могу согласиться. И статическая типизация, и «нормальное ООП» — это привычные парадигмы, а не что-то обязательно правильное. Действительно, распространенность парадигмы — это аргумент. Много разработчиков, проверенный инструментарий. Но все меняется и когда критическая масса людей выбирает альтернативу, она становится мейнстримом.
вчера были модными рельсы, сегодня нод жс, завтра еще что-то
Если вынести за скобки вопросы моды, то явные преимущества у «модной сегодня технологии» все-таки есть. И их немало. Просто не стоит впадать в крайности. Никто не говорит «Java is dead». Конечно, нет. Но лет через N... Кто знает? :-)
Не могу согласиться. И статическая типизация, и «нормальное ООП» — это привычные парадигмы, а не что-то обязательно правильное.
ниже уже писали, что код приходится поддерживать и дорабатывать
Просто для многих применений выбор традиционных технологий обусловлен именно традиционностью
скорей — экономической целесообразностью
Один только класс ORM-продуктов заставляет задуматься, что RDBMS часто — компромисс.
она, реляционная модель, хорошо формализуется.
есть такая проблема — время одномерно. События на прямой времени связаны отношениями «до» «после». перестановка событий на оси — изменяет поведение, то есть эти отношения не коммутативны. когда говорят «конкурентный доступ к общим данным» — то это просто частный случай более фундаментальной проблемы — времени (причинно-следственных связей)То же в какой-то мере можно сказать о системах очередей, которые становятся неизбежными в ситуациях, когда нельзя отправить ответ клиенту и продолжить делать «что-то еще».
иногда можно и «внеочередное выполнение команд» сделать. Когда они — не связаны этим отношением — до после
но обычно то... «время» кругом :)
согласен с парой уточнений «скорее да чем нет» (обсуждение ниже читал)
— NoSQL — проблема: «CAP теорема», которая как бы и не теорема..., а так, эмпирическая мыслишка. То есть — «веб-приложение» ничего не говорит о том — что собственно оно реализует, какую предметную область. Оказалось, для «фейсбуков» ACID не нужен. (очень интересный теоретический вопрос что CAP теорема не входит напрямую в противоречие с ACID, но вот косвенно...)— Статические HTML-страницы и богатая JavaScript логика на клиенте. — а клиент то — планшетник. и далеко не всегда о 4ех головах. у меня о 4ех головах x86 по 3+ GHz на dou.ua Хром начинает тупить иногда... Так что — пишут нативное все больше, на iOS или Андроиде...
да проще некуда:А что будет через 15 лет предположить невозможно.
либо и представить трудно
...пообщался вот с одним стаааарым знакомым. давно в реале не виделись :)а, забыл, DB — от Oracle
NoSQL — проблема: «CAP теорема», которая как бы и не теорема..., а так, эмпирическая мыслишка. То есть — «веб-приложение» ничего не говорит о том — что собственно оно реализует, какую предметную область. Оказалось, для «фейсбуков» ACID не нужен. (очень интересный теоретический вопрос что CAP теорема не входит напрямую в противоречие с ACID, но вот косвенно...)facepalm.jpg
Я в этом всем несколько разбираюсь, в некоторые продукты из одного из слайдов я комитил код, меня позабавил твой неупорядоченный поток мысли.
Я в этом всем несколько разбираюсь,
да-да :D
ах это всего-то Dменя позабавил твой неупорядоченный поток мысли.
конченный тролль только то в постах и ищет :D
конченный тролль
Ну я же тебе уже наглядно на пальцах обяснил, что конченный троль — это ты
Я в этом всем несколько разбираюсь,да-да :D
Кстати, скромно напомню что совсем недавно ты имел очень не верное представление о предмете, о котором сейчас напыщено разсуждаешь, и именно благодаря моим усилиям стал на путь истинный, хотя похоже из-за бардака в твоей голове, усилия канули в лету. Пруфлинк: dou.ua/...ic/5773/#207626
это оказывается ты светоч мой, и все только от тебя можно узнать, если снизойдешь :D
максимум, что может быть читающий пропустил нечто ранее, и мой пост просто подчеркнул нечто ему известное, или изменил весовой коэффициент в его ментальной БД.
Да, ты пишешь значительно меньше по сути чем я, все какие то копипасты и пространные расмышления не по теме получаются
поэтому я обычно и пропускаю.
мало того, по опыту сравнения когда другим подобные субчики закидывают «пишешь не по сути» — нередко эти субчики как раз кроме фанатичного повторения банальностей даже не пробовали копнуть в суть.
доку да, можно цитировать и без ссылок. чем ты обычно и занимаешься :D
Это все бла-бла-бла, а мой пример выше в очередной раз наглядно показывает кто из нас не пробовал копнуть в суть зато имеет свое экспертное мнение
за следующме 15 лет маятник успеет качнуться еще минимум раза 2
Уверен, что как минимум одна «революция» в направлении разработки софта (или вообще в том, как будет выглядить и использоваться этот софт) однозначно будет за 15 лет.
Из нового я бы поставил на какойнибуть MPS, уж больно много правельных идей там в нем. Непонятно почему оно досих пор не взлетает, а гдето в тени.
в смысле JetBrains MPS?
да, у DSL куда больший потенциал изменить мир программирования, чем у мультипарадигменных языков.
Мне непонятно только почему вся передовая братия хипстеров, альтернативщиков-эксперементататоров и прочих «геев», дружно др0чит на метрику написания экспрешенов как можно меньшим количеством символов, напрочь забывая про все остальное. Про то, что проэкты большие, сложные, что их со временем надо поддерживать и модифицировать.
на метрику написания экспрешенов как можно меньшим количеством символов,
Потому что это их реальность.Про то, что проэкты большие, сложные, что их со временем надо поддерживать и модифицировать.
А если за 6 месяцев не получилось, все выбрасываем и пишем новый. И так пока не получитсо.
А языкоделы... таже нода с темиже рубями, с тойже скалой «посмотрите как круто у нас можно записать цикл одной строчкой вместо 5 на ужас-джаве». Тупое рубилово бабла на тренде ?
а еще в руби нет этих дурацких скобочек и точку с запятой не надо ставить
Зато там есть длинный и некрасивый «end» вместо простого и понятного «}»
с тойже скалой «посмотрите как круто у нас можно записать цикл одной строчкой вместо 5 на ужас-джаве»
А не приходило в голову что разумная лаконичность сильно повышает читабельность кода и вполне себе сказывается на судьбе проекта?
Ключевое слово — «разумная». Хотя кому-то и APL слишком многословен.
А языкоделы...
они либо в плену традиций, либо «математики», либо трудятся для кодеров (чтобы дать им один язык на все случаи жизни)
у нас можно записать цикл одной строчкой вместо 5 на ужас-джаве
это да, быстрая сортировка на Haskell выглядит конечно очень лаконично.
Так что если нужно будет писать сортировки — может возьму HaskellТолько — чего-то никому не нужно чтобы я писал сортировки...
Богдан уже частично ответил:
таков их «мирок».
У крутых языкоделов — «личный кабинет», кафедра, и научные тусовки. И иногда неплохие концепции, подходы, которые можно использовать если не впрямую, то в качестве вдохновения для инженеров-прагматикову мелких — выполняя свои десятки тикетов, хочется ж побыстрее реализовать это однообразие.
И вот почему я думаю что DSL имеет бОльший потенциал чем выразительный — но универсальный язык. Потому что он нужен как мелким, так и инженерам. При этом, «футуристическая картинка» будет такой: инженеры вместе с аналитиками — создают не фреймворк — а DSL, или наращивают уже созданный для этого вида задач. Собственно кодеры — имея сноровку в типичных задачах — будут бодаться не с языком и его фичами, не с инфраструктурой, а очень быстро реализовывать те самые рутинные задания. Уже потому что ошибок будет меньше, они, ошибки уйдут на уровень транслятора DSL, и будут головняком инженеров(как сейчас ошибки компиляторы или ВМ). И участие их в совершенствовании DSL тоже будет более весомым, а не как сейчас «ну вот те исходники, предложи допиши, авось в комитеры возьмут». Весомыми — потому что будут слать просьбы — не хватает вот такой конструкции, для такого типа ситуаций предметной области. То есть использование DSL повысит И качество обмена опытом, знаниями.
Недостатки, опасности у DSL конечно есть — «вавилонское смешение языков», тьма диалектов для одного и того же класса задач. Но с другой стороны — фреймворки уже его породили, ты можешь знать один, но тебе придется осваивать другой, хотя в нем те же концепции.Берется DSL, добавляются в него недостающие возможности(они, описаны формально, так что потом можно переделать язык, а код переписывать будет не нужно, проблема транслятора поддерживать версии диалекта) Программисты-кодеры, или те кто работают непосредственно с заказчиком — на этом удобном для этого конкретно проекта — бытенько пишут нужный людям код. Намного быстрее чем сейчас, при тех же мозгах.
Вобщем это будет — очень другой мир программирования. Прикладного программирования.Но там где сейчас коробочные ERP и Java-C# - очень много изменится. (первые не дают гибкости при программировании уникальных свойств заказчика, проблемы вторых — все на доу и без меня знают)
P.S.
на судьбе проекта куда сильней сказываютсяразумная лаконичность сильно повышает читабельность кода и вполне себе сказывается на судьбе проекта
3. скорость внесения изменения в эту модель.
читабельность нужна для 3го пункта.Концепция DSL — берется решать проблемы всех 3 пунктов.
Например по 1 и 2идеи DDD — практически впрямую бы воплощались в виде DSL и его транслятора
Что-то вроде D, но он чето не выстрелил, нужна поддержка корпораций.
ручное управление памятью vs автоматическое
в D помнится и так и сяк можно было.Некое подобие есть и C++, auto_ptr и прочее (если память не изменяет)
вот пока автоматическое управление памятью требует избыточную память для выполнения программы, и нередко ощутимых затрат процессорного времени — и будет желание вернуться в нативТак что возврата в натив тоже не будет, пока там не удешевят разработку.
ручное управление памятью vs автоматическое
в D помнится и так и сяк можно было.Некое подобие есть и C++, auto_ptr и прочее (если память не изменяет)
Ага, в C++ є і shared_ptr і weak_ptr, біда тільки, що
1. при малтісредінгу вони повинні бути потокобезпечними (просте копіювання поітера в іншому среді призводить до інкременту лічильника посилань й інші среди повинні побачити це, щоб не затерти об«єкт, який ще юзається).
2. навіть там, де швидкодія некритична, то все одно народ починає робити передчасні оптимізації, і жертвою такий оптимізацій стають смартпоінтери, навіть якщо в ВТюн вони в топах ніразу не фігурували, але багатьом «великим оптимізаторам» вони як більмо на оці «а вот на всякий случай».
3. тотальне небажання вчитися. проблема С++ не в тому, що на ньому програмують «в стилі С++» а якраз в тому, що на ньому програмують як на «С з класами», де класи, то такі собі «більш продвинуті структури» а методи то «більш зручна форма запису функцій, що працюють з членами структурок». про юзання RAII і вміння грамотно написати оператор присвоєння (щоб без ресурс лік) я вже і не згадую.
тотальне небажання вчитися.
не без цього.
але, коли кажуть що то не «комунізм», «С++», ..., ..., винний, я завжди кажутак, скільки можна зекономити на перилах, якби не оті дурні люди, які не хочуть вчитися ходити по сходах.
річ же у тому, що й ті що навчилися — пишуть ПО повільніше на С++ :)
скільки можна зекономити на перилах, якби не оті дурні люди, які не хочуть вчитися ходити по сходах.
поза всакими сумнівами, якщо додати перевірку на вихід за межі масиву до мови С, то вона стане набагато безпечніше. Але питання — чи варто?
річ же у тому, що й ті що навчилися — пишуть ПО повільніше на С++ :)
так, але проблема тут двояка. Джава та С# мають не тільки прекрасний захист від наступання на граблі (такі, як меморі корапшени), вони мають ще і чудові бібліотеки. Можливо не такі чудові, як би хотілося, але стандартизовані.
Нажаль, стандартна бібліотека С++ ще багато чого не включає, відповідно треба або писати велосипед, або обирати Qt чи WxWidgets? Boost.Asio чи ACE? А якщо треба перенести код, що юзає одне в аплікуху, що юзає інше? А перенети на іншу платформу?Чувак 2 роки працював з одною лібою а в нас зовсім інша, тепер йому треба вчитися, щоб включитися в процес.... І пішло і поїхало...
Звісно, є новий класний стандарт C++11, з няшками і вкусностями, але, на мою думку, він повинен був вийти ще десь так в 2008 році...
Джава та С# то такі собі, майже операційки, де все готовеньке, і все стандартизовано, і не треба довго мучатися над задачами, типу як зробити серіалізацію/десеріалізацію глибоко вложеного дерева об"єктів в XML. Тут правда, тоже не все ідеально, тому і з«являються хитрі фреймворки, але навчанні новачків і включення «в струю» відбувається знайно скорше.
для С — може й не вартона вихід за межі масиву до мови С, то вона стане набагато безпечніше. Але питання — чи варто?
а може треба компромісний варіант — небезпечні і безпечні масиви.
Як надумаю робити свою мою на заміну — подумаю докладніше :)
вони мають ще і чудові бібліотеки.
так. але тоді треба аналізувати а чому у С++ такого не сталося, «стандартна бібліотека С++ ще багато чого не включає»
думаю то буде вже не зовсім про властивості мов програмування.та «маркетинг» — хто відповідає за «стандартну бібліотеку», і такє інше.
для С — може й не вартоага, для С++ можна заюзати катомний клас, наприклад, а для того треба домовитися всім і одразу про такий клас, який юзати для такого масиву, щоб не треба було зхрещувати «велосипеди».а може треба компромісний варіант — небезпечні і безпечні масиви.
А покищо маємо std::vector та std::array operator[] без перевірки меж масиву а операція at з перевіркою, але ніхто не юзає at, натомість юзають operator[]...
так. але тоді треба аналізувати а чому у С++ такого не сталося, «стандартна бібліотека С++ ще багато чого не включає»як не дивно, але саме маркетингу Microsoft чи Sun/Oracle ми завдячуємо більш
думаю то буде вже не зовсім про властивості мов програмування.
А про інженерію — як взаємодіє з ОС програма, у який засіб лінкуюєця код C++ та Java,та «маркетинг» — хто відповідає за «стандартну бібліотеку», і такє інше.
хоча це і недомократично і, можливо, не всі чудові ідеї втілено, а дещо реалізовано дубово, зато стандартно...
Насправді розмірковування подібні до дебатів про те, чому Лінукс досі не переміг Вінду...
тобто натякав я зовсім про інше, а не про ці проблеми.
Щодо «чому Лінукс досі не переміг Вінду...» — за роки цього питання втратив інтерес. :)
любий стандарт має два необхідних фактора, щоб бути дієвим стандартомсаме маркетингу Microsoft чи Sun/Oracle ми завдячуємо більш консистентними апішками
2. масове використання цього стандарта
володіння розробкою інструмента так, дає можливість реалізувати ці два фактора.
З.ы. А ведь еще С++11 есть, со всякими rvalue references, var-args в templat’ах, да и вообще темплейтную магию никто не отменял.
появится какой-то язык, на котором можно будет писать так же быстро и удобно, как на Джаве и Шарпе,
ChinaJSC#
Есть ещё embeded, но там как был нейтив, так и остался, может быть тоже даже наоборот... железо мощнее, хочется удобства, кроссплатформенности, высокоуровневости (netduino.com =))
*под райнтаймом — я имею ввиду среду выполнения, к примеру на Андроиде есть уже Dalvik, он там очень плотно засел, так что в любом случае, у Dalvik+Java преимуществ больше, чем у Mono+C# на андроиде. Невозможно или трудно впихнуть Mono, так что бы оно было не поверх Dalvik, и на тех же правах (оно должно работать для телефонов из коробки, без перепрошивки). Так что легче уж взять С++ и юзать нейтив (что бы реюзать код с другой платформы). Разве что так я могу оправдять этот тренд.
Это будет круто, если они это реализуют.
Сишарп компилируемый в натив — это прям мечта.
Меня лично ужасно бесит что обычные десктопные приложения тормозят. Я имею ввиду отзывчивость интерфейса, скорость запуска, это ужас просто. Я не хочу ждать пока джит откомпилирует полностью программу. Я хочу просто запустить и чтобы оно летало, как программы написанные на С++. Когда нажимаешь на какую-то вкладку или менюшку в первый раз в более-менее среднем приложение обязательно будет фриз на пару секунд. Ну что это такое блин? Это что веб-приложения что-ли? Нет, это десктопные, они обязаны летать. А скорость запуска? Тьфу.
Просто сравните скорость работы нескольких аналогичных по функционалу приложений написанных на плюсах и на шарпе/джаве.
Меня лично ужасно бесит что обычные десктопные приложения тормозят.
обычно десктопные приложения и сейчас написаны на С++
на джаве написаны IDE и разный корпоративный софт.На C# - тоже немного десктопных приложений
Вы б конкретизировали с пару-тройку десктопных приложений, тормоза в которых вас раздражают.
JVM можно сказать компилировать сразу, без набора статистики запусков.Я не хочу ждать пока джит откомпилирует полностью программу
.NET компилит сразу. Мало того, позволяет сохранять результат компиляции в натив между запусками приложения.
Кроме того, JIT не компилит всю программу, упрощенно там часть процесса такая(сбор статистики для перекомпиляции в более эффективный код, например замена вызова по интерфейсу если возможно опускаю)
Фризятся приложения на JVM и .NET не из-за ненативности. А из-за — работы сборщика мусора.
Скажу про IDE на джава, и те приложения что использую, например RSSOwl — настраивайте параметры запуска JVM — памяти побольше давайте, и указывайте ParallelGC или CMS сборщики мусора. Можно еще указать запускать серверную JVM а не клиентскую, только не забыть указать количество вызовов метода когда сработает JIT. Фризов раздражающих как-то не упомню.
А скорость запуска?
Скорость запуска зависит больше от количества и размера файлов, которые требуется прочесть с диска. Starcraft и Фотошоп тоже не мгновенно стартуют :)
Ну да, так поэтому их и пишут на плюсах, потому что на дотнете или джаве оно тормозит. Боюсь представить как тупил бы Microsoft Office, будь он написан на WPF. Вижуал Студия 2008 просто летала, она была полностью на плюсах, а в 2010 добавили WPF и она стала работать медленнее, хотя не так конечно как Эклипс или Идея, которые полностью на Джаве.обычно десктопные приложения и сейчас написаны на С++
Хотя WinForms приложения работают довольно шустро, иногда даже не отличить от нативных.
С тем что вы написали про работу JIT спорить не буду, полагаю все объяснения действительно верные.
тоже на что-то другое с с++ переписывали?
Да нет, я просто для примера про с++ писал, на самом деле конечно же и на дельфях всяких писали и приложения были ни чуть не медленне чем на с++.
А вот 2012 студия по-моему даже пошустрей
Боюсь представить как тупил бы Microsoft Office, будь он написан на WPF.
Вы не поверите...
Вот ни за что не поверю, что офис написан на wpf, слишком быстро он работает. И да, я про 2010 и 2013.
В википедии тоже написано, что он на плюсах написан.Если считаете, что на впф, киньте ссылочку плз.
а вижуал студию перевели на wpf исключительно как POC ну и в довесок новый продукт для работы с XAML Expression Blend написали на нем. сам я с это тулзовиной не работал, но вроде бы нареканий у людей на скорость работы нет.
так пусть и дальше пишут :)Ну да, так поэтому их и пишут на плюсах
какие проблемы?
для десктопных приложений никто уже не будет делать новый язык. за ненадобностью.
Клиент евернота под винду сначала был написан на WPF
пользуюсь евернотом с версии 2.1, тогда это была вобщем-то другая программа. так что лично пережил и появление и 3ей версии, ее тормоза и переписывание ее с .NET на C++.
WPF, вообще не имеет отношения к "нативности". А к уровню использования средств GUI ОСи. Чем дальше от нее - тем будет тормозней интерфейс. Программисты на Java знают мелкие отличия как пользователи между SWT и Swing приложения - хотя ж Java же.Не следил, но подозреваю что самое шустрое GUI приложения под винду как и раньше писать нужно на MFC. Которое в сравнении с WPF что асссемблер с бейсиком.
С историей еверноте же у меня еще вопросы остались:2. Переписывание с нуля ПО, когда уже известна задача, набиты шишки в ее реализации - даже теми же инструментами - очень даже может улучшить его характеристики.
То бишь пример с Evernote - весьма смазан. И ИМХО - его сразу и нужно было писать на плюсах. Из-за - потенциально высокого "тиража". Они вообще могли вылететь с рынка, с "прототипированием" клиента 3ей версии на .NET.
Кстати, памяти жрет столько же сколько и .NETовский вариант :)
В том то и дело, что WPF позиционируется, что он значительно производительней WinForms, т.к. он работает через DirectX и использует аппаратное ускорение, то бишь видеокарточку. В принципе где нужна отрисовка каких-то сложных и красивых интерфейсов со свистелками и перделками так оно и есть, да и вообще на WinForms это сложнее и геморнее делать. Но со стандартными контролами интерфейс WPF явно тормознее WinForms. Хотя мне больше нравится писать на WPF.
Ну да, про евернот согласен, вполне возможно, что его коряво написали. Я помню он уж очень сильно тупил, хотя программа то не сильно сложная.
В том то и дело, что WPF позиционируется, что он значительно производительней WinForms
не встречал. в скорости разработки - да.
т.к. он работает через DirectX и использует аппаратное ускорение, то бишь видеокарточку
непростой вопрос - что дает DirectX для 2D интерфейса.
Я помню он уж очень сильно тупил
не то слово :) но думаю проблема в WPF, а не C# .NET
непростой вопрос - что дает DirectX для 2D интерфейса.
вы не поверите, но как правило (возможно даже без исключений) gpu лучше справляется с отрисовкой интерфейса, чем cpu.
для градиентного фона кнопочки - согласен.
а так, зачем мне верить, везде где я знал что используется GPU - интерфейс становился как тормознутей, так и "мыло" какое-то в отображении того же текста (пробы исправить с ClearType не помогают).
Вот, в Опере сделали возможность включить GPU для рендеринга. Попробовал, пожил пару дней - прироста отзывчивости как-то не приметил, а вот то самое "мыло", какие-то рывки при скроллинге и прорисовке - да, надоели и отключил.
то есть вы считаете, что узкоспециализированная система (gpu) будет хуже справляться со своей профильной задачей, чем система широкой специализации(cpu)?
а какая специализация у GPU - выводить текст, рамки?
Мои знания совсем устарели, и я их не обновлял, но из опыта геймдева, когда впрямую писал в видеопамять запомнилась проблемка "специализации", и думаю к нынешним режимам работы GPU она тоже относится.Так что готов к забрасыванию гнилыми помидорами и тухлыми яйцами :)
Грубо говоря их, режима 2 штуки (тесселяции, полигоны, натягивание текстур, оставлю за кадром)но кошмарик наступает когда нам нужно хаотически менять по 1ому пикселю. Тогда приходится пересчитывать всю область. и так для каждого пикселя.
Когда начали появляться карты с аппаратным ускорением 3D графики, в них по по прежнему оставался режим - 2D. Сейчас не пишут уже - а раньше писали, наш новый чип ускоряет вывод 2D в .. раза, а вывод 3D в ... раз!
И есть у меня такая догадка, что все те окна с текстом, кнопками, менюшками и прочим - очень плохо ложатся для обработки 3D возможностями. И 2Dшыми для спрайтов.Отсюда, у меня от оптимизированных под GPU "офисных" приложений тоже самое ощущение - это веб приложение чтоли в лоб портировали? чего он все так сонно, с такими масштабными подрагиваниями и подмигиваниями ради перерисовки малюсенькой части на экране?
Давайте так - назовите мне неигровое приложение с GPU акселерацией для вывода обычного интерфейса.
И память уже опера отожрала в 2 раза больше и продолжает отжирать дальше.
Это ж как рендерить видео - CPU медленно но качественно, включишь CUDA - результат будет быстр, но годится только для документальных фильмов без яркого видеоряда.
Это точно проверенный факт или всё-таки ваши догадки?
ну я как-то в ie9 и 10
не пользуюсь. но замечал что они как-то по другому выглядят чем в остальной винде и ПО под нее :)
про конвертацию видео - на любом форуме соот тематики можно почитатьЭто точно проверенный факт или всё-таки ваши догадки?
и Intel Quick Sync - много качественней дает чем CUDA и Ati Stream
вообще, вы уже второй раз просите "цитировать доку". надо видать оставить вас в покое:я все всегда выдумываю, не читайте впредь мои посты ни в коем разе ;)
вы же понимаете, что это совершенно разные операции?
я не помню чтобы говорил о рендеринге картинки
а вот о выводе контролов офисного GUI - да, говорил. растровую картинку из контролов - еще нужно получить. Кто ее формирует и как - в том и вопрос. И как DirectX - ее формирует - тоже вопрос для меня.
что оно какое-то не то - в указанном вами ПО - IE9 - заметил.Но вот шрифты стали смазанными - сказано не мной, о другом продукте с включенным GUI рендерингом.
давайте еще названия программ, чтобы было о чем говорить.
P.S.Вряд ли программисты в Adobe столь криворуки. Технологии может быть?...
я ведь и сказал в самом начале, что тормоза интерфейса — не в ненативности. вот откуда читать dou.ua/...ic/2504/#265231
тот же wikidpad — на wxPython написан.Не тормозит там ничего. Ну, пока слово не переименуешь, или еще какое тяжелое закадровое действие не запросишь.
а в — сложности задач что решает ПО, способе организации создания интерфейса, и — «количестве» и «тяжести» промежуточных библиотек что его наконец покажут на экране.
вы же затронули другую тему — GPU акселерация.Теоретически, действительно — если всю отрисовку отдать GPU — то должно быть быстрее. Например в 3D — насколько понимаю уже многое отдают туда — вот тебе координаты фигур, вот тебе координаты источников света, вот тебе текстуры, — рисуй!
Но так как 2D функции в GPU существует давно — я не очень понимаю почему до сих — проблема и в чем она. Устаревшие свои знания рассказал.
Если можете — поясните на пальцахНо в любом случае — не имеет значения с какого языка будет пересылаться в GPU задание на отрисовку, нативного, или Ruby какого-нить.
P.S.а в гугле ты его переспроси»
почитавши материалы и обсуждения по теме тормозов WPF, сохранил одну ссылочку.где в игровой форме и дружелюбной атмосфере обсуждаются плюсы и минусы, и их причины:
Стоит ли начинать сейчас учить WinForms?
с вброса:Существует распространённое заблуждение, что WPF может полностью заменить Windows Forms. В общем случае это не так. Бизнес-приложения (толстые клиенты трёхзвенок), лучше писать на Windows Forms, так как элементарно быстрее работает, а эффекты на шейдерах не нужны.
Но со стандартными контролами интерфейс WPF явно тормознее WinForms.
мне кажется, что у вас какие-то предрассудки на этот счет или просто очень древний тазик
есть такой uTorrent. В квалификации разработчика и тени сомнения нет.
Но у 3.* - тормозной, "сонный" интерфейс, так и вспоминается NetBeans, но там то - Swing - все рисуется самой Javой. И то, как JVM разогреется, сонливость немало уходит.
В итоге, вернулся и живу на последнем 2.* - очень живенький интерфейс.
Странно, у меня версия 3.2.1, щас поклацал, интерфейс летает, как и положено.
в 3.* - вижу. Комп не слабый, и GPU вполне. и на ноуте - вижу.
Кстати, еще вспомнил.Очень даже видно как первый пыхтит. Для Mirandы тоже есть плагин, кажется для отрисовки вызывает IE - получаем пыхтение Trillianа :)
На С++ написаны оба.
Меня это не удивляет - чем дальше от низкоуровневых средств ОСи по рисованию GUI, чем выше уровень абстракции - тем больше работы нужно проделать чтобы вывести все то же окошко с кнопочкой.
так что не, не в плюсах или С# дело, ИМХО
Вот это и расстраивает, мощность компов стремительно растет, а программы тупят так же.Меня это не удивляет - чем дальше от низкоуровневых средств ОСи по рисованию GUI, чем выше уровень абстракции - тем больше работы нужно проделать чтобы вывести все то же окошко с кнопочкой.
Такое ощущение, что если скажем через 10 лет компы станут еще в 10 раз мощнее, то придумают еще туеву хучу оберток, фреймворков и абстракций и окошки с тремя кнопками и пятью текстбоксами будут так же тормозить )
может потому что в начале 90ых я такое уже слышал :)
а если посмотреть на разнообразные ролики от Intel, MS о недалеком будущем - то так и будет - в программировании пока никаких прорывов не просматривается, а все эти голографические интерфейсы, кластеризирующиеся и говорящие смартфончики, наночипы в асфальте и на каждой городской мухе - программировать придется старыми способами.а значит будут еще обёртистей обертки.
Но, за время его запуска, я успеваю вбить лингво ру в браузере, и выполнить поиск слова через веб. Потому нейтив с большими базами тут проигрывает даже вебу.
Мне чегото кажется что фриз на менюшке не из за джита, или большого количества слое\объектов. А из за того, что они ёё инициализируют лейзи, чтобы таки ускорить начальную загрузку и так не легкого приложения.
или из-за динамического или ленивого конструирования меню. когда перед первым разворачиванием нужно осуществить немало проверок для каждой позиции, вытянуть иконки, а потом еще и отметить недоступность в данном состоянии программы.
Отлично фризятся менюшки в Thunedbird'е. Первые несколько раз.
А в IDE таких проверок еще больше - пройтись по внутреннему представлению проекта, найти классы, переменные, методы, которые, ... сверить найденное... запросить окна редактора кода...
Джавошарпы сгниют вместе с остатками балмерсофта, и только РНР будет гордо возвышаться над горами постапокалиптического ИТ-шного пепла!
Не мечты, а вера в светлое будущее, когда программисты освободятся от ярма строгой типизации и чистого неймспейса!
... и от необходимости трезво, связно и чётко излагать мысли.
Джавошарпы сгниют вместе с остатками балмерсофта, и только РНР будет гордо возвышаться над горами постапокалиптического ИТ-шного пепла!
навоза, а не пэпла
Останутся. В роли Кобола нового времени. Думаю им на смену придут Scala, F# и им подобные.
а почему вы так думаете?
я думаю что как раз указанные ЯП не будут сменой ни Java ни C#F# - это вообще-то OCaml для .NET. Есть и для JVM. Но массовым он не стал, хотя: Why Ocaml?
Какие причины для замены C# на F#?
Скажем так, на чём мы будем писать, определяем не мы. Мелкософт вложил нехилые усилия в F# и всячески его пиарит, значит уловили тенденцию. Вообще я имел в виду не конкретно Ф# и Скалу, а мультипарадигменные языки, которые совмещают императивщину, функциональщину и строгую типизацию.
вот я пока не уловил этой тенденции, того и спрашиваю :)Мелкософт вложил нехилые усилия в F# и всячески его пиарит, значит уловили тенденцию.
то есть она конечно есть, будущий успех ФП уже не один год кучкой адептов-маргиналов обсуждается..
Вложил MS же в F# - всего ничего :) CLR — есть, OCaml — есть. Нужно было немного подправить для лучшей интеграции с системой типов, и все — компилятор написать — какие затраты по нынешним временам?
а мультипарадигменные языки
Scala да, мультипарадигменная. F# насколько знаю, все же просто — OCaml(причем урезанный). И мультипарадигменность ему предоставляет CLR .NET. хоть с Boo связывай.
Цитата:которые совмещают императивщину, функциональщину и строгую типизацию.
Why Ocaml? — Type checking. ML is statically type checked (unlike Lisp), which reduces errors and improves efficiency.
что же до смешения императивщины и функциональщины — да, в языко строении просто никаких других вариантов не осталось :)декларативное
за десятилетия ничего не прибавилось третьей :)
Осталось их как-то — скрестить :)
вот я пока не уловил этой тенденции, того и спрашиваю :)
А что странного? ООП не стал серебрянной пулей, нужно что то новое. Или хорошо забытое старое.
Ну и личные впечетления: я был поклоником чистого ООП, пока не появились лямбды и ЛИНК в Шарпе. Теперь уже без них ощущение, словно к рукам привязанны гантели.
ООП — это не способ записи кода, а способ — проектирования.я был поклоником чистого ООП, пока не появились лямбды и ЛИНК в Шарпе.
сугубое ИМХО разумеется, но аргументация есть, если в корне не согласны :)
P.S.Что и наблюдаем в идеологии ЛИНК — это SQL применяемый к коллекциям, вместо таблиц.
Но на ЯП нужно описывать не только получение и агрегацию данных, а и сложные алгоритмы их — взаимодействия, взаимовлияния. (уже на уровне даже хранения — физическая целостность еще не гарантирует — логической целостности).И когда мы начинаем моделировать поведения — быстро приходим к такой концепции как «состояние» и правила их, состояний смены, а в чистых ФП, или декларативном подходе — описание такой концепции весьма затруднительно, утомительно.
а в чистых ФП, или декларативном подходе — описание такой концепции весьма затруднительно, утомительно.
Ага, монады. Но я к тому и веду, чтол будущее за гибридными языками. Шарп или Джаву сделать таковыми уже не получится, они слишком много тянут за собой.
за гибридными да.Но я к тому и веду, чтол будущее за гибридными языками.
но не за Scala, и тем более не за F# - вот я к чему веду.
концептуально эти три языка не отличаются :)
а вот то что они проще С++ - думаю отрицать не будете?
и повторюсь — F# никого из троицы не продолжает. Он есть — OCaml для .NET.
Scala да — новый язык, мультипарадигменностью новый. То есть их нельзя ставить рядышком.Уж если и увязывать, то Scala это Java + OCaml. о F# C# + OCaml сказать не могу
а вот то что они проще С++ - думаю отрицать не будете?
Фреймвёрки учитываем?
Если полезть в анменеджед, то Шарп уже не проще, другое дело, что оно обычно никому не надо.
конечноФреймвёрки учитываем?
тренд: от библиотек к фреймвёркам — тем более делает ненужными выразительные ЯП
это хорошо видно по коробочным ERP системам с кастомизацией, SAP R/3, Axapta и та же 1СВот они — первые фреймвёрки, где система кастомизируется не параметрически, а вставкой, изменением некоторых алгоритмов.
Фреймвёрки — это трендище однозначно не только в мире Java, C#а и на PHP, Python ну а Ruby без Рельсов вообще оказался «не нужен».
Фреймвёрки как тренд, толкают скорей в сторону DSL, а не мультипарадигменности в ЯП.
По мне так фреймвёрки и мультипрадигменность понятия разных категорий: ничто не мешает кодить под ASP.net на F#.
да, мешает только бессмысленность перехода на F# при таком раскладе :D
а именно — если фреймвёрк берет на себя рутину проектирования и кодирования — то выразительность ЯП — будет не востребована. Какой тогда смысл в переходе на F#?
Как по мне, вот пример того же:...ORM на .net. LinqToSql то прикрыли...
потому что — либо ORM-фреймвёрк, либо LinqToSql. А одновременно — ни к чему.
Фреймвёрк предлагает решение общих проблем. Всегда есть проблемы, которые выходят за сферу его возможностей.
и раз для нее не подходит универсальный ЯП, то обратный вывод — ЯП подошедший для нее лучше универсального — будет плох для общих проблем.
То есть, если нет фреймвёрка для решения задачи — да, нужен бы ЯП повыразительней. А если есть фреймвёрк — то выразительный ЯП — не нужен.
Или еще так:сейчас вот есть linq to entities. в чем разница то?
Ну разница то в том, что ЛинкТуСкл — это надслойка над Адо. А Линк ту Энтити — надслойка над Энтити, которая надслойка над Адо. Имхо — лишнее.
да глупости вы какие-то пишете. какие-то надстройки над надстройками. и то и то ормы, только вот linq to sql только для mssql, а ef для многих других реляционных субд.
объекты в модели ef реализуют интерфейс IQueryable (ну или какой там интерфейс нужен)точно так же (ну или похожим образом), как и объекты в ORM Linq to SQL. linq to entities это не фреймворк. это обыкновенный linq по отношению к объектам орма
тим що орм бере на себе ту роботу, яку буде писати в коді програміст використовуючи linq to sql
по іншомутим що орм відносиця до інфраструктури, аlinq to sql — до мови
дело в том, что в linq to sql вы работаете мапите реляционную модель в объектную и линком работаете уже с ней
При запуске приложения LINQ to SQL преобразует запросы LINQ из объектной модели в SQL и отправляет их в базу данных для выполнения. Когда база данных возвращает результаты, LINQ to SQL преобразует их обратно в объекты, с которыми можно работать на собственном языке программирования.это ваши догадки?
А используя orm фреймворк — программист избавлен от необходимости писать запросы (в жизни не все так красиво, ессно)
если же вы подразумевали под orm — object-relational mapping как процесс, то тогда да, и сугубо объектный код, без всяких LINQ который формирует запросы(из объектной модели в SQL) и парсит ответ в объекты предметной области — будет кодом выполняющим — orm.
MSDN — по моему очень удобная вещь для повышения своего уровня.
или хотя бы приведите критерии по которым фреймворк для работы с базой можно считать ORMом и по каким критериям linq to sql не проходит
вы несете какие-то глупости.
увы мне, увы, стыд и позор «ниасилятор детект» :D
это да, ваша правда, я периодически забываю что рунет — неудачное место для разговоров о программировании.я прошу чтобы вы не несли всякие глупости ... по каким критериям linq to sql не проходит
спасибо что напомнили.
вы написали что он таковым не является потому, что он умеет работать с linq. Я заметил, что EF точно так же умеет работать с linq и у вас аргументы закончились и вы почему-то решили дать мне ссылку на статью о linq to sql в msdn
??????вы написали что он таковым не является потому, что он умеет работать с linq.
не, ну это просто 3.14ец какой-то :D
может я еще написал что и Hibernate не является ORM фреймворком из-за наличия HQL, а JPA это вообще незнамо что, из-за Criteria API?
вы расскажите подробней, какой ахинеи я еще понаписал :D
... а может все таки не «вы написали», а «я прочитал». Не? ;)
Является ли Linq to Sql ORMом? и если нет — то почему?
и что за вакансию вы мне предлагаете?
у меня то к вам нет вопросов, после «это ваши догадки?» — все далее произошедшее было очевидно, стоило бы сразу и проигнорировать. но, «а вдруг», люди разные, и прочие «бла-бла».
так на какую вакансию мне собеседование проводите?
ну не хотите отвечать — не надо.
может когда-нибудь созрею на строгую формальную статью :)
Потому что у молодых программистов такое же затруднение вызывает и вопрос:«MyBatis — ORM или нет?», при вполне хороших навыках использования в работе :)
так что да, не хочу сейчас утруждаться, статьи, эссэ, да и толковая заметка в блоге мне даются куда дольше, чем просто плохооформленный выброс перезревшей мысли в виде комментария на форуме.
потому что — либо ORM-фреймвёрк, либо LinqToSql. А одновременно — ни к чему.
Мелкософтовские фреймвёрки ОРМ не включают. Прикрыли, видимо, из за Энтити, что бы был единый стандарт.
Например сделав де-факто стандартом ORM на .net? LinqToSql то прикрыли, если вы не в курсе (хотя использовать можно).
А вот на F# где проекты? ну хотя бы какое-то минимальное использование языка в коммерческих проектах?
НХибернейт левое, а Энтити родное. Честно — не знаю проектов на Ф#, хотя читал гиганское кол-во статей, вплоть до Ф# для Юнити. Я собственно доказываю, что в случае Мелкософта отдача в опенсорс не есть признак того, что от язвка отказались. Опенсор частая практика в Мелкософт Ресёрч.
Scala — уже слишком сложнаяниасилятор детектед
Только как-то не сложилось — пишут все же на как на С++, а не на улучшенном С.ниасилятор детектед 2
ниасилятор детектед
почему ж сразу неосилятор :D
сложный язык — остается сложным даже если осилить.На сам его автор говорит — да, язык сложный.
ниасилятор детектед 2
аха, и про С++ - сколько профессионалов есть, но они его простым не считают :)
сложность ЯП к ниасиляторству не имеет отношения.Это вполне объективный критерий.
На сам его автор говорит — да, язык сложный.
пруфлинк в студию
ниасилятор детектед 3аха, и про С++ - сколько профессионалов есть, но они его простым не считают :)
Я не говорил что с простой, я говорил что можно настроить линтер который отсекает сложные конструкции и программировать на нем как на простом языке.
пруфлинк в студию
погуглите сами :)
а я уже на это сказал ранее:Я не говорил что с простой, я говорил что можно настроить линтер который отсекает сложные конструкции и программировать на нем как на простом языке.
читайте внимательней, прежде чем браться троллить ;)
погуглите сами :)
слив в лучших традициях доу
а я уже на это сказал ранее:и на С++ можно было писать как на улучшенном С. Только как-то не сложилось — пишут все же на как на С++, а не на улучшенном С.
Ты просто за всех расписался, видимо с уровня своего ниаслиляторства. Очевидно кто асилил построить правильные стандарты и настроить линтер, у тех все Ок, а для ниасиляторов с++ сложный.
Ты просто за всех расписался
всех не знаю.
знаю многоопытных программистов на С++на то они и тролли.
это потому что вам ник сменить нужно.слив в лучших традициях доу
я давно вас, как конченного тролля игнорирую, просто тема интересная, вот и ответил :)
Базовые же, объективные сложности ЯП складываются из:3. сложности, двусмысленности чтения как попытке избавиться от первых двух сложностей (Lisp — прост по синтаксису, в итоге в коде никаких подсказок к пониманию семантики. в Haskell — вообще концептуально поставлен вопрос — как добиться истинности семантики только с помощью истинности синтаксиса).
знаю многоопытных программистов на С++
знаю мнения что Степанова, автора STL, что иных, типа вот zouev.blogspot.com/.../blog-post.html
и только у троллей все объясняется ниасиляторством.на то они и тролли.
Ближе к телу, ты уверен что в хплабс или где там Степанов работал(ет) нету ограничения на фичи с++, которые энфорсятся автоматическими тулами?
это потому что вам ник сменить нужно.я давно вас, как конченного тролля игнорирую, просто тема интересная, вот и ответил :)
Вот ты уже который пост вместо того что-бы поставить точку и привести цитату занимаешься откровенным хамством. Помоему абсолютно очевидно кто из нас двоих конченый троль.
любой может взять, и сравнивать количество информации в моих постах и твоих.
и кто применяет ad hominem
любой может взять, и сравнивать количество информации в моих постах и твоих.
Ну да, у тебя информационный понос, куча какой то ерунды пальцы настукивать не болят, зато от ответа по сути(пруфлинк что одерски называет скалу сложной) как то не видно, что впрочем не удивительно
www.computerra.ru/xterra/34923
и из вики:Ифкуиль совмещает априорный философский язык с логическим языком, применяя лексикон из 3600 семантических корней, развиваемых с помощью сложной, матрицеподобной грамматики, ... Словообразование в ифкуиле использует ряд принципов из когнитивной психологии и когнитивной лингвистики, таких как теория прототипов, радиальная категоризация, нечёткая логика и семантическое взаимоисключение.
Ну так твой пример ни в красную армию, скала по количеству элементов и конструкций компактнее с++, с# и джавы
Scala не очень сложная, до хаскелля не дотягивает по сложности.
аргумент «а можно писать просто на ней, как на улучшенной джаве» опровергаетсяПруфы ?
F# - это вообще-то OCaml для .NET.Мертворожденный язык
Какие причины для замены C# на F#?Никаких. Что то, что то есть ересь
их очень много, поэтому не копил.Пруфы ?
уже есть и от самих лучших программистов на Scala. — они НЕ пишут на ней как на улучшенной Java.
И просто опыт программерский — почти каждый программист стремится к все более выразительному, емкому, лаконичному коду, и только внешние ограничения — либо в ЯП, либо в коллективе — останавливают его от увеличения мудрености кода.
Scala — очень выразительный язык, и странно предполагать, что программист которому понравилась ее выразительность — остановится просто на «улучшенной Java» по собственной воле. Хотя не исключено конечно, если программист — опытный инженер... то сможет, правда тогда ему и ЯП особо не важен :)
А еще скалка не перегружена всякими редкоиспользуемыми штуками вроде монадных трансформеров.
. Думаю им на смену придут Scala, F# и им подобные.
Только за! Заодно отсеит из наших рядов быдлокодеров которые не ©могут освоить новую парадигму.
Ты что, не видел обезьянок, которые кодят на Java и C# в процедурном стиле? Быдлокодинг непобедим!
Таких в нормальных командах на мороз выкидывают. По крайней мере в крупнейших бодишопах.
Я не к тому. Будет мультипарадигменный язык — будут продолжать говнокодить. Быдлокодеры никуда не отсеются.
быдлокодеры исчезнут когда исчезнет в них потребность.
а это случится — в качественном прорыве в разработке ПО, когда либо такое количество программистов станет не нужным, как сейчас, либо золотокодеры в разы, а то и на порядки поднимут свою производительность.либо — коробочные продукты охватят те сферы, где сейчас пишут собственное ПО.
если освоившие новую парадигму увеличат свою производительность труда в разы — то вероятно да.
иначе, если не будет экономического эффекта — новая парадигма — останется маргинальной, для узкого круга задач где либо этот эффект будет, либо этими задачами, ввиду какой-то их сложности, будут заниматься только программисты, которым просто удобней, психологически — Scala или Haskell.
в свое время я встречал исследования и диаграммы, насколько, и с какого уровня сложности проекта разработка на С++ дает ощутимый эффект в сравнении с Си
ни по Scala ни по F#, или их родственникам такого не встречал.
А в чем проблема набыдлокодить на скале?
Когда вам этот код потом разгребать прийдется, вы будете вспоминать джаву как сладкий сон :-)
Я на досуге пилю новый язык, он убьет обоих, и за одно серьезно уменьшит потребность в программистах. Трепещите
А в чем крутось forth кроме того что там нужно писат все наоборот?
А в чем крутось forth кроме того что там нужно писат все наоборот?
власне в тому, що і Ліспа: написати таку сяку реалізацію, що не тільки повна по тюрінгу, але і вміє зробити щось більш-менш толкове можна буквально за пару вечорів (звісно, я не кажи про повну реалізацію стандартів і специфікацій, я кажу про «свою версію мови програмування» аля Форт чи Лісп :)))
www.paulgraham.com/...isphistory.html
ні в якому разі не пропагую Лісп як порятунок від всіх проблем програмування — але з пізнавальною метою дуже цікава штука.
знову ні в якому разі не пропагую Forth як порятунок від всіх проблем програмування — але з пізнавальною метою дуже цікава штука (якщо є час)
java точно останется, судьба шарпа сильно привязата к M$, 95% что останеся, такие компании могут долго загибатся.
Ждать 15 лет не придется. Если Windows 8 юзерам не понравится — то уже через несколько лет C# уйдет вслед за Паскалем.
Сейчас майкрософт технологии — это целостная платформа. У юзеров есть Windows + IE. На серверах есть Windows Server + MS SQL + IIS + C#. Заказчики понимают что если все на одной платформе то проблем меньше. Особенно если это внутрикомпанейская система автоматизации, а не просто интернет-сайт.
Что будет, если юзера пересядут на яблоки, андроиды и линуксы? Какой тогда смысл платить за недешевую серверную платформу от MS если то же самое на линуксе и джаве будет дешевле?
Уже сейчас шарпоинт и эксченж вытесняют гугл-доки и жмаил. Вместо TFS многие ставят джиру и гит. Мелкомягкие теряют и в серверных решениях.
Если Windows 8 а с ней IE 10, онлайн-офис, скайдрайв и ажур смогут захватить хороший кусок рынка (и самое главное — корпоративных клиентов) то у MS технологий будет будущее. Если 8 винда «не взлетит» — то мелкомягких постепенно вытеснят отовсюду.
Судя по действиям Балмера, который просрал все что можна, есть таки нехилая вероятность что микрософт попрут отовсюдого :-)
Под windows 8 приложения надо переписывать. Возникает вопрос: а окупится ли? Или может лучше сразу переписать под линукс, андроид или ось?
Он про метро-интерфейс. Там надо переписывать морду. А если там по заветам смартУИ, то и всё остальное. Десктопные приложение переписывать не надо.
Думаю есть еще 100500 отличий. Так что просто мигрировать существующее приложение на METRO думаю будет равнозначно его переписыванию.
ну так вас же никто не заставляет переводить свое приложение с десктопа в метро.
Существующие приложения сразу переписывать никто не кинется. А вот новые приложения или новые версии старых уже придется делать с оглядкой на метро. Даже если не ради интерфейса, то ради «живой» иконки, участия в поиске и интеграции с другими приложениями (тем же мылом или файловой системой).
Если функционал вынести в библиотеки — не будет. Но не важно, ибо
ну а зачем старым приложениям метро интерфейс?
Вы себе Метро — 3DsMax представляете?
Да 3DsMax и Visual Studio МЕТРО интерфейс не нужен — ну так они совсем не массовые приложения.
Но на них делают деньги. И сила винды в большом количестве профессиональных приложений.
А что бы сделать приложение с METRO интерфейсом, поддержкой жестов, поиска, «живых» «плиточек», «засыпания» и т.д. его нужно почти полностью переписать на других классах .Net (другой тип проекта в VS, если так понятнее).
А это значит что никто не захочет вкладываться в новые приложения под винды и виндовым девелоперам останется только сапорт старых приложений.
и как ни странно лидер рынка видеокарт для пк — это интел.
думаю что и производителей 3D игр — тоже.
а вот кто должен пугаться — так это завязавший свое ИТ на стек технологий от MS.
Кстати OYA — открытая, дешовая консоль на базе дроида. Имхо, подприбавит жару :-)
вы думаете, что лидеры рынка будут писать что-то путное под эту консоль?
Сервера серверами, десктопы десктопами. Виста не взлетела, помните? Никто даже не чихнул.
С дектопами еще хуже: для них 8 винда хуже(!) чем 7. А это значит что идея новой «единой операционки» может провалиться просто потому что она не понравиться юзерам ни на планшетах ни на десктопах.
Для планшетов Win8 отлично подходит, но чем хуже для десктопов? Отсутсвием Пуска? Есть дофига способов его вернуть. Ещё есть способ сделать так, что Метро вообще появлятся не будет, даже при загрузке.
Потому что тогда оставалась XP.
А сейчас есть 7.
PS: Win8RT это не касается. Там эпик фейл.
Черес 15 років програмуватимуть нейроімпульсами з мозку. Але не всі. Організм деяких індивідуумів відторгне електроди і вони зійдуть з розуму :)
сумніваюсь.міняються не тільки «віндовси» але і ринок.на арену зараз виходять всеможливі андроїди і тд тп.доля мобільних пристроїв зростає з кожним днем.якщо майкрософт зможе втримати свої позиції на ринку то так,але я зараз бачу інше..
Такой эпический срач, а ответ правильного нету. Раз уж тема поднялась из пепла...
Через пятнадцать лет останется джава или останется C# в масcовом использовании?ДА!
Они — локомотивы индустрии — думают о своих карманах, о долях на рынке, о том как отхватить свой кучок, а через 15 лет, нашим детям достанется весь этот обьектно-ориентированный хлам, что вы тут год назад двумя лагерями поочереди расхваливали.
Через 15 лет программирование будет совсем на другом уровне, а дедушки Джава и СиШарп сядут в последнем ряду рядом со скелетом Кобола. Но они будут... и Кобол еще будет... Аминь.
-
-
-
-
-
-
В листинге видно, что при хранении структуры как object-а, делается боксинг объекта. При добавлении же в дженерик-список боксинга нет.
И?
В листинге видно, что при хранении структуры как object-а, делается боксинг объекта. При добавлении же в дженерик-список боксинга нет.
То есть что бы положить в объект в список объектов — это надо как-то преобразовывать?
Если бы S был reference type, этой строчки бы не было.
2Иван Мазепов
IL_0011: box ClassLibrary1.Class1/S
То есть что бы положить в объект в список объектов — это надо как-то преобразовывать?
и я не понимаю к чему это, и не понимаю зачем этот листинг ниже?
Чтобы похвастаться знанием мсдн, вероятно.
Согласен. Причем тут дженерики?
Ну это вы привели цитату из мсдн с фразой что генерики не вызывают боксинга, и я не понимаю к чему это, и не понимаю зачем этот листинг ниже?
структуры могут лежать на куче без боксинга (например когда они являются филдами обьекта на куче)
Согласен. Причем тут дженерики?
и дженерики сами по себе не вызывают анбоксинг, но он вполне может иметь место при их использовании, ну и как это относится к исходному вопросу вообще не понятно.
Вот вам еще пример:
public class Class1
{
public struct S
{
private int x;
private int y;
}
public static void F1()
{
ArrayList al = new ArrayList();
S s = new S();
al.Add(s);
}
public static void F2()
{
List<S> l = new List<S>();
S s = new S();
l.Add(s);
}
}
И вот дизассемблер F1:
.method public hidebysig static void F1() cil managed
{
// Code size 29 (0x1d)
.maxstack 2
.locals init ([0] class [mscorlib]System.Collections.ArrayList al,
[1] valuetype ClassLibrary1.Class1/S s)
IL_0000: nop
IL_0001: newobj instance void [mscorlib]System.Collections.ArrayList::.ctor()
IL_0006: stloc.0
IL_0007: ldloca.s s
IL_0009: initobj ClassLibrary1.Class1/S
IL_000f: ldloc.0
IL_0010: ldloc.1
IL_0011: box ClassLibrary1.Class1/S // Вот!
IL_0016: callvirt instance int32 [mscorlib]System.Collections.ArrayList::Add(object)
IL_001b: pop
IL_001c: ret
} // end of method Class1::F1
и метода F2
.method public hidebysig static void F2() cil managed
{
// Code size 24 (0x18)
.maxstack 2
.locals init ([0] class [mscorlib]System.Collections.Generic.List`1<valuetype ClassLibrary1.Class1/S> l,
[1] valuetype ClassLibrary1.Class1/S s)
IL_0000: nop
IL_0001: newobj instance void class [mscorlib]System.Collections.Generic.List`1<valuetype ClassLibrary1.Class1/S>::.ctor()
IL_0006: stloc.0
IL_0007: ldloca.s s
IL_0009: initobj ClassLibrary1.Class1/S
IL_000f: ldloc.0
IL_0010: ldloc.1
IL_0011: callvirt instance void class [mscorlib]System.Collections.Generic.List`1<valuetype ClassLibrary1.Class1/S>::Add(!0)
IL_0016: nop
IL_0017: ret
} // end of method Class1::F2
Можно, но тогда это уже будет boxed value type => performance penalty.Когда создают value types на куче — это называется boxing. МСДН пишет, что дженерики не вызывают boxing. Вывод.
Я не согласен со всеми тремя утверждениями — структуры могут лежать на куче без боксинга (например когда они являются филдами обьекта на куче), ну и дженерики сами по себе не вызывают анбоксинг, но он вполне может иметь место при их использовании, ну и как это относится к исходному вопросу вообще не понятно.
А сколько они должны занимать?
Сорри, забыл что структуры не поддерживают наследование
Можно, но тогда это уже будет boxed value type => performance penalty.Совсем ничего не понял, вы говорите что обьект value type нельзя создать на куче?
Когда создают value types на куче — это называется boxing. МСДН пишет, что дженерики не вызывают boxing. Вывод.
Структуры относятся к value types. Does not force boxing and unboxing — значит для них не создаются объекты на куче.
Совсем ничего не понял, вы говорите что обьект value type нельзя создать на куче?
лет через 15 этот вопрос, наверное, будет выглядеть примерно как «Через пятнадцать лет останется Clojure или останется F# в масcовом использовании? », а джава с С# займут почетное место рядом с COBOL т.к. старый код тоже нужно будет кому-то поддерживать.
the generic code does not force the boxing and unboxing of value types
Структуры относятся к value types. Does not force boxing and unboxing — значит для них не создаются объекты на куче.
вы уверены что в ц шарп в колекции структуры кладутся по значению?
msdn.microsoft.com/...ibrary/ms379564 (VS.80).aspx
Because the generic code does not force the boxing and unboxing of value types, or the down casting of reference types, performance is greatly improved.
И где тут написано про способ хранения структур в коллекциях?
Да заквотил же специально:
То что один человек такое сказал, не означает что все обсуждали исключительно маленькие короткоживушие (почему короткоживущие? Мы ведь о обьектах в коллекциях говорим) обьекты.
вы уверены что в ц шарп в колекции структуры кладутся по значению?
msdn.microsoft.com/...ibrary/ms379564 (VS.80).aspx
Because the generic code does not force the boxing and unboxing of value types, or the down casting of reference types, performance is greatly improved.
silverwolf
Что 20 int’ов не будит занимать 20*32 бит, например.
А сколько они должны занимать? 4 байта каждое значение. И? В Джаве меньше?)
silverwolf
Поскольку код приведенный вами только запутывает человека который будет его читать, имхо.
Я абсолютно согласен, поэтому никогда не использую и перегрузку операторов, вызов метода очевиднее, чем искать что где переопределено. Но если язык позволяет перегружать, а я это не использую, язык от этого не хуже, он просто предоставляет разные подходы. А как они будут использоваться — дело рук программиста.
2. И _что_ отсюда вытекает? Боюсь представить.
Что 20 int’ов не будит занимать 20*32 бит, например.
Да заквотил же специально:
это не такая уж и проблема, создание маленьких короткоживущих объектов очень дешевая операция.
А если речь о тяжеловесных объектах в большом количестве, от которых нужно быстро потом избавиться, то есть принудительная сборка мусора. И вдобавок есть книги по алгоримтам и хорошему дизайну классов (наверняка понадобятся если возникнет такая задача).
Смешались в кучу кони люди, я вот выше спросил — вы уверены что в ц шарп в колекции структуры кладутся по значению? Можно ссылку? А то пока это на уровне фантазий, как бы не о чем разговаривать.
И что вы все уцепились за этот чар-инт
чар-инт — это просто пример кривой реализации. На практике он не так существенен.
При чем здесь вообще дженерики, если просто один тип приводится к другому
Вопрос в дизайне дженериков. В джаве основная их задача — ограничивать разработчика, а в Црешотке — я не понимаю зачем они надо, кроме как каких-то сказочных гуано-оптимизаций когда объект-коллекция подменяется массивом (если я правильно понял Ивана Мазепова)
Здесь по вашему тоже ошибка?
Я говорю не об ошибке, а о потенциальной ошибке. Кстати в вашем примере, если я все правильно понял, то просто происходит создание нового объекта на основе объекта другого класса. Мое личное мнение, что ваш код должен был бы вывалить ошибку компиляции и заставить разработчика создать новый объект явно. Поскольку код приведенный вами только запутывает человека который будет его читать, имхо.
Речь о маленьких порциях данных изначально! Вам лишь бы поспорить?
У кого была речь о маленьких порциях изначально?
А если речь о тяжеловесных объектах в большом количестве, от которых нужно быстро потом избавиться, то есть принудительная сборка мусора. И вдобавок есть книги по алгоримтам и хорошему дизайну классов (наверняка понадобятся если возникнет такая задача).
blockquote> 4) создается объект на куче => hence тормоза — в Java — это не такая уж и проблема, создание маленьких короткоживущих объектов очень дешевая операция.
Структуры тоже сюда относятся.
К примеру, такую структуру:... имеет смысл хранить на стеке
А с структурами все не так просто, так как присваивание структуры может больше времени занимать чем присваивание указателя на обьект.
Речь о маленьких порциях данных изначально! Вам лишь бы поспорить?
Обычно так и бывает. Поэтому большие объемы данных в структурах не хранят. А всякие точки-прямоугольники — в самый раз.
Ну «обычно» — достаточно спорный аргумент, кому нужен язык который «обычно» работает; -)? Ну и второй вопрос, если говорить о ц шарп, есть повод для уверенности, что там в листах хранят структуры именно по значению?
2Иван МазеповПоэтому по поводу
1) Речь шла не о скорости, а о целостности.2) Не знаю как в новых версиях, но в старых версиях int соответствовал структуре Int32, со всеми вытекающими. (тут я могу ошибаться)
2. И _что_ отсюда вытекает? Боюсь представить.
А с структурами все не так просто, так как присваивание структуры может больше времени занимать чем присваивание указателя на обьект.
Обычно так и бывает. Поэтому большие объемы данных в структурах не хранят. А всякие точки-прямоугольники — в самый раз.
Здесь по вашему тоже ошибка?
class Program
{
static void Main(string[] args)
{
CustomInt i = new CustomChar {Char = "7"};
CustomChar c = new CustomInt {Int = 2};
var list = new List<CustomInt>();
list.Add(new CustomChar { Char = "1"});
}
}
class CustomChar
{
public string Char { get; set; }
public static implicit operator CustomChar(CustomInt i)
{
return new CustomChar {Char = i.Int.ToString()};
}
}
class CustomInt
{
public int Int { get; set; }
public static implicit operator CustomInt(CustomChar c)
{
return new CustomInt {Int = Convert.ToInt32(c.Char)};
}
}
Структуры тоже сюда относятся.К примеру, такую структуру:
А с структурами все не так просто, так как присваивание структуры может больше времени занимать чем присваивание указателя на обьект.
А расширить память, в массиве то 3 элемента, а мы добавляем
4-тый?
Это в любом случае придется сделать.
2) Не знаю как в новых версиях, но в старых версиях int соответствовал структуре Int32, со всеми вытекающими. (тут я могу ошибаться)
Структуры хранятся на стеке.
Структуры тоже сюда относятся.3) В реальной жизни (по крайней мере в моей реальности) применение примитивов в коллекциях крайне ограничено
К примеру, такую структуру:
struct Point
{
int x;
int y;
}
- имеет смысл хранить в стеке.
Хотя сопгласен что в случае масивовой реализации листа может произойти просто присвоение
А расширить память, в массиве то 3 элемента, а мы добавляем
4) создается объект на куче => hence тормоза — в Java — это не такая уж и проблема, создание маленьких короткоживущих объектов очень дешевая операция.
Хотя сопгласен что в случае масивовой реализации листа может произойти просто присвоение.
О чем и глаголю. Понятно, что к LinkedList это неприменимо.
Что значит просто добавить? Это значение тоже на куче выделится, как и вспомогательные обьекты листа.
Хотя сопгласен что в случае масивовой реализации листа может произойти просто присвоение.
просто добавить числовое значение 10
Что значит просто добавить? Это значение тоже на куче выделится, как и вспомогательные обьекты листа.
Вроде есть. А какое это имеет отношение к дженерикам?
Такое, что дженерики (по крайней мере, в С#) позволяют избежать этих явлений.
List<int> l = new List<int>() { 1, 2, 3 };
l.Add(10); // просто добавить числовое значение 10
List<object> o = new List<object>{ "Hello", "world" };
o.Add(10); // o.Add(new Integer(10)); - создается объект на куче => hence тормоза
Можно и на веб глянуть. Если взять то же самое PHP то оно держится на мощи библиотек на с++
Не уловил суть.
silverwolf 16 мин. назад
>> А кривого и глючного ПО на Java намного больше чем на С++. Может не в языке дело?Десктопного ПО.
Можно и на веб глянуть. Если взять то же самое PHP то оно держится на мощи библиотек на с++. А дергать их можно откуда угодно. Конкретный пример — XML, чистый С++, дергаемый php-ным скриптом.
Совершенно неверно. Они обеспечивают контроль типов. Вы путаете контроль типов с особенностями неявного преобразования типов.Вот именно в описанном выше случае генерики совершенно не при чем, это общий антураж, с таким же успехом это мог бы быть вызов метода -, а вы решили, что они корень зла:)
Да, согласен, здесь проблема не в генериках.
Совершенно неверно. Они обеспечивают контроль типов. Вы путаете контроль типов с особенностями неявного преобразования типов.А зачем вообще тогда генерики нужны если они контроль типов во время компиляции не делают?
Вот именно в описанном выше случае генерики совершенно не при чем, это общий антураж, с таким же успехом это мог бы быть вызов метода -, а вы решили, что они корень зла:)
А кривого и глючного ПО на Java намного больше чем на С++. Может не в языке дело?
Десктопного ПО. Проблема в том когда оно писалось: Появился новый инструмент (джава), пользоваться им не умели (сборка мусора в условиях десктопа, подкидывает кучу проблем, лукАндФилу тоже не уделяли достаточно внимания) и главное все решили что будут шшастя, мол «можно писать как угодно, ошибки не будет» (а ошибки то и нет, есть тормоза), лично я из всего десктопного на java использую только mucommander. К слову приложения написанные с наскоку на mono или python тоже безбожно глючат, но радует что уже учатся (реже падают)
А кривого и глючного ПО на Java намного больше чем на С++. Может не в языке дело?
И на какой доказательной базе базируется столь безапеляционное утверждение?
ИМХО в данном случае Java перестраховывается. Это как при переходе моста C#-программисты его просто перебегают, Java заставляет одевать спасательные жилеты на входе.
А зачем вообще тогда генерики нужны если они контроль типов во время компиляции не делают?
WIgor 1 час назадИМХО в данном случае Java перестраховывается. Это как при переходе моста C#-программисты его просто перебегают, Java заставляет одевать спасательные жилеты на входе.
А кривого и глючного ПО на Java намного больше чем на С++. Может не в языке дело?
В Java не существует boxing и unboxing?
Вроде есть. А какое это имеет отношение к дженерикам?
с каких пор char это буква?
Простите за фамильярность. char — это символ.
Ключевое слово char используется для объявления символа Юникода в диапазоне, указанном в следующей таблице. Символы Юникода — это
16-разрядные символы, которые используются для представления большинства известных письменных языков мира.
msdn.microsoft.com/...ibrary/x9h8tsay (VS.90).aspx
msdn.microsoft.com/...ibrary/5kzh1b5w (v=VS.90).aspxКлючевое слово int обозначает целочисленный тип, в котором хранятся значения, размер и диапазон которых приведены в следующей таблице.
Аноним, почитайте таки хоть пару глав в книге по джава, что бы понять в чем разница между подходом в Java и.Net.
Не помню как академически звучит, но есть «расширяющееся», есть «сужающееся»
Covariant and contravariant. http://en.wikipedia.org/wiki/Covariance_and_contravariance_ (computer_science)
С таким же успехом можно забить на дженерики и пользоваться коллекциями Object’ов.
В Java не существует boxing и unboxing?
с каких пор char это буква? char — это код, причем числовой... Кто-то из нас идиот, невже це я?! =)
Логическая. char — это буковка, int — это число. Вы в коллекцию чисел кладете буковку, она приводится к числу и достаете вы число, нарушается целостность.Так какая ошибка может произойти, если ты сохранишь значение типа, допускающего меньший диапазон, в переменную, допускающей больший значений?
дженерики (в джаве) — это способ увеличения надежности, конкретизации.
ИМХО в данном случае Java перестраховывается. Это как при переходе моста C#-программисты его просто перебегают, Java заставляет одевать спасательные жилеты на входе.
В списке интов можно хранить байт, делается неявное приведение. Не помню как академически звучит, но есть «расширяющееся», есть «сужающееся». Так какая ошибка может произойти, если ты сохранишь значение типа, допускающего меньший диапазон, в переменную, допускающей больший значений?
Класс-оболочка Integer нужен для передачи int по ссылке
Интеджер — не мутабельный в джаве, поэтому передавать его по ссылке особого смысла нету, все равно внутри не изменишь.
Неявное приведение типа это не ошибка и если спецификация языка определяет, что char приводится к int-у, то это не ошибка.
Достаточно очевидно, что язык стал бы более устойчивым к ошибкам, если бы такое привидение запретить, а требовать явное преобразование типов.
Класс-оболочка Integer нужен для передачи int по ссылке, а также, вместе с другими подобными классами, для реализации динамической типизации.
Я прошу объяснить в 2 словах по простому почему в Java 2 инта
В Java 1 int (архаизм из ранних версий, имхо) и класс-оболочка для него.
А код
int d = new char();
List<int> t = new List<int>();
t.Add('a');
прекрасно выполняется. Может быть вы хотели бы, чтобы и
t.Add((byte) 5);
валил ошибку? Неявное приведение типа это не ошибка и если спецификация языка определяет, что char приводится к int-у, то это не ошибка.
Если не хотите, ваше право.
Тогда может быть вы понимаете и почему и зачем в Java cуществует 2 типа инта, а то я не догоняю.
Я понимаю. А судя по «cуществует 2 типа инта» вы не понимаете в принципе что происходит, возьмите почитайте (организация и система типов в Java и в.Net отличается).
Тогда может быть вы понимаете и почему и зачем в Java cуществует 2 типа инта, а то я не догоняю.
Код компилируются. И позволяет сделать ошибку.Вы пишете good и что это разрешено
Почитайте про дженерики.
Вы пишете good и что это разрешено, но «дженерики в Java такого не позволяют».
А почему вы не пишете, что Java — синтаксический наследник C++?
«Синтаксический наследник» и «синтаксис подогнанный под модные на данный момент фишечки» — это разные вещи. Java создавалась что бы «пофиксить баги в C++», и в некотором плане у них это получилось, в некотором нет. Но это тема другого холивара.
Не правильный вопрос. Правильный вопрос:Что позволяют дженерики Java и не позволяет C#?
Если вкратце:
List<int> list = new List<int>();
list.Add(1); //good
list.Add('c'); // good
Почему в лист int’ов разрешили записать букавку? (объяснять не надо, механизм я понимаю, дженерики в Java — такого не позволяют)
А почему вы не пишете, что Java — синтаксический наследник C++? Потому что у вас в профайле Java, а не C#?
Не совсем. Дженерики C# — это помесь «кастрированных темплейтов C++» и идей заложенных в дженерики Java, при этом помесь получилась «как абычно»
Что позволяют дженерики Java и не позволяет C#? Без ехидства, мне прсото интересно.
Словосочетание «помесь Java и C++» вообще странно звучит
В синтаксическом смысле.
Встречал мнение, что дженерики C# — кастрированные темплейты C++
Не совсем. Дженерики C# — это помесь «кастрированных темплейтов C++» и идей заложенных в дженерики Java, при этом помесь получилась «как абычно»
C# — это замена VB
Уточняю: одна из задач C# пересадить всех разработчиков с VB на новый «супер крутой язык от МС», патамушо они начали задумываться о переходе на Java, которая не принадлежит МС (вспоминаем 2000−2004 года)
Встречал мнение, что дженерики C# — кастрированные темплейты C++ (не знаю так глубоко С++, поэтому не могу судить, но что-то мне кажется вы тоже не в теме).
C# — это замена VB.
lol. C# — замена VB.NET. А VB.NET — VB6. А VB6 — QBasic. Ну да, совсем похожи.
Сборка мусора появилась первой не в Джаве.
Никто этого и не утверждает, но факт: первые версии C# — были помесью Java и C++.
Лямбды — тоже.
Да, «лямбды» — это гениальное изобретение C#? Надобности в них особой никогда не было (в императивных языках) и добавлены они «потому что это круто» (модными стали Python’ы и Ruby)
От C++ что, ДллИмпорт? Unsafe код?
По большей части дженерики, которые являются смесью подходов Java и большей частью C++.
Да тут и не чего комментировать. C# — это замена VB. Поэтому стиль кодирования (внешние признаки) очень сходны.VB — даже комментировать не буду.
но когда смотришь на C# — первое ощущение «это уже было в языке...»
Вдобавок не могу еще ничего сказать по C# 4.0 (пока не читал нового Рихтера), но по краткому обзору изменений я подобного не видел в других языках так точно
То, что язык берет лучшее из существующих наработок, по поему характеризует мудрость, а не когда «сделаем специально наоборот чем везде».
VB — даже комментировать не буду.
Это как в известном анекдоте: «слизать слизали, а пользоваться не научились»Смешно читать о преимуществе джавы по сравнению с языком, который обвиняется в слизывании всего с этой же джавы.
Проблема С# — в том что в него суют ВСЕ, немного от Java, немного от C++, немного от VB, немного от Python, немного от SQL, немного от еще чего-то. Язык создан не с целью решать какие-то задачи или реализовать какую-то парадигму, а с целью переманить как можно больше людей. Поэтому на начальных этапах все классно, а когда проект разрастается и оказывается, что «каждому пользователю невыгодно давать новый сервер».
Смешно читать о преимуществе джавы по сравнению с языком, который обвиняется в слизывании всего с этой же джавы.
По-моему очевидное преимущество явы проявляется сразу на страте проэкта. Допустим нужно пять разрабов — во сколько обойдется такой старт на дот нете, если, скажем, пишется нечто похожее на ebay?
аC/C++ точно никогда не исчезнет, как как high level assembler. Любая системная вещь на C#/Java хоть и возможна теоретически, но реализуется всегда через ass.
Дивись щоб жреці бізнес логіки наклали на тебе анафему і вічне прокляття синглетона.
КОНТЕСТ 1 дн. назадЯ чомусь був подумав, що пустий холіварСамо предположение того, что Java или C# останется в массовом использовании через 15 лет есть идеотизм. ООП как концепт существует уже 50 лет и если раньше это была новая и революционная технология, то сейчес это просто ущербное средство с множеством неуклюжих дополнений, в виде фреймворков и прочей лабуды.
Амінь
дядя 3 дн. назадЧерез 15 лет Oracle купит все компании мира, разработает языка jPL\SQL# и все будут програмировать на этом прекрасном языке. А про java и C# можно будет узнать только из книг десятилетней давности или устроившись на работу в гос учереждение.
C/C++ точно никогда не исчезнет, как как high level assembler. Любая системная вещь на C#/Java хоть и возможна теоретически, но реализуется всегда через ass.
1% юниха влияет на рынок десктопа
Нет, просто рынок десктопа менее 1% рынка мобильных устройств
вы действительно думаете, что 1% юниха влияет на рынок десктопа?
Moonlight и MonoTouch — это выход на рынок айТелехвончиков и тд.
вы действительно думаете, что 1% юниха влияет на рынок десктопа?Вообще, единственный интерес в Mono у Microsoft заключается в Moonlight, т.к. для успеха технологии им нужна поддержка на клиентах
ПыСы. сам линуксоид, если что
-
Само предположение того, что Java или C# останется в массовом использовании через 15 лет есть идеотизм. ООП как концепт существует уже 50 лет и если раньше это была новая и революционная технология, то сейчес это просто ущербное средство с множеством неуклюжих дополнений, в виде фреймворков и прочей лабуды.
Ну и какие специальные знания сейчас требует C#? SQL и так все учили в универе, лямбды похожи на кванторную запись, которой пользуются математике (типа «все х, такие что...»). В отличие от F#, тут мозги на изнанку выворачивать не нужно.
Отличия джава от с шарп далеко не только в linq.
т.е. все что пишут мелкомягкие то по определению кошерно и годно, а то что другие крап и в пищу не годиться?Не слишком ли однобоко это выглядет?
Никто здесь не обобщал, но то что качество моно реализации библиотек ниже оригинала, и содержит несовместимости с оригиналом вроде не вызывает сомнений.
Через 15 лет Oracle купит все компании мира, разработает языка jPL\SQL# и все будут програмировать на этом прекрасном языке. А про java и C# можно будет узнать только из книг десятилетней давности или устроившись на работу в гос учереждение.
То что специфицировано все выполняется, насколько я знаю. То что вы использовали какое-то поведение конкретного контейнера — это ваши проблемы (у меня были такие проблемы при переносе с Tomcat на WebSphere). Про МС и стандарты я уже говорил:)переносимость между веб контейнерами не совсем простая временами.
На данный момент все Java-машины должны пройти сертификацию у Сан Оракл. Кстати, для меня оказалось откровением что у IBM таки своя JVM.
но все решаемо правда
Очевидно что реализация библиотек в моне «неофициальная».
И реализована через GTK, соответственно требует рантайм.
1) Все мы знаем как МС следует стандартам, кстати, насколько я помню, и в контексте C#.Моно соответствует официальному стандарту ECMA для СиШарпа и СиЭлЭра.
2) В том смысле, что МС (именно МС — как вендор) не гарантируют, что программа написанная под Mono компилируются под.Net и что самое главное наоборот (это проверено). Про перенос бинарников я уже говорил.
С++ реализаций вообще тьма тьмущая, и ничего
Это была одна из причин, почему «энтерпрайз» не любит C/C++
Не слишком ли однобоко это выглядет?
Так что ненужно рубить с горячя не разобравшись в предмете
подскажите мне аналог сервера апликаций типа WebSphere со всеми его вкусностями в.net
Как-то мне рассказывали, что в WebSphere можно использовать.Net, я не проверял.
> Однако, на клиентские места Джава тоже идёт, в связке с ЛинуксомПрошу прощения. БЛЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯ, ЗАИПАЛИИИИИИИИИИИИИИИИИ!!!Mono
Mono — это придлуда, которая не является официальной версией.Net. Не поддерживает (по крайней мере раньше не поддерживала) всех возможностей последних версий (совместима вроде в 2.0 или 3.0), не имеет бинарной совместимости, имеет свой набор либ и самое интересное имеет реализацию под винду.
Однако, на клиентские места Джава тоже идёт, в связке с Линуксом. Скажем, государственые органы цивилизованных стран переходят именно на бесплатные решения (а это, как правило, Линукс с клиентом на джава), в целях сбережения средств налогоплательщиков. > это десятки тысяч, если не сотни тысяч клиентских мест в каждой стране. Правда, к бытовым клиентам пробиться будет сложнее — там винда пока рулит, без вопросов.
Java идет курсом на замену коболаО чем и я. Фиг она умрет и в 15 и в 30 лет. И спецы будут нужны.
Но если ориентироваться на кобол (langpop.com/ — то в десятки раз меньше спецов. Хотя для твердых духом — оплата их труда может быть существенно выше средней. Но и работу искать надо будет не полдня, а полгода.
а Java идет курсом на замену кобола (я как бы не скажу что сильно рад- уж сильно я не люблю overengineering). и она с нами на долго- 100%.
а вот Terracotta ту же вы чем заменять будете?
Ну лично я, тут не скажу аналогов — нужно хорошо знать что могут системы, что бы аналоги найти. А я в java проектах с Terracotta не сталкивался, разве что с EhCache (для этого кстати аналог Velocity (не шаблонный движек, а вот это msdn.microsoft.com/...e695849.aspx))
у MS продуктов есть неизлечимая болезнь- они работают на OS от MS и только. И они платные.
Тут не поспоришь. Только WebSphere тоже не бесплатная ведь.
@WIgor к стати наблюдаю тенденцию к отмиранию.net проектов в нашей компании. Клиенты поигрались и наелись. Для переучивания.net програмистов у нас даже делали специальные курсы. В итоге.net остался только в проектах поддержки. новые проекты- J2EE только. Конечно это наш финансовый загончик -, но уж очень наглядно.
а так же во многих облостях использование MS операционных систем просто запрещенно по соображениям безопасности....net хорош своей динамикой и идеями -, но это продукт отдной компании. И с плохой репутацией в ентерпрайзе. И никакие лямбды и функциональщина его в этом плане не спасают
Ну и то, что я выше говорил — «синтаксический сахар» в C# вкуснее.
Вот-бы их перемешать, и получить две нормальных...© Тарапунька и Штепсель, вроде...
То есть детали нас не интересуют -, но тем не менее, утверждаем, что нет аналогов «WebSphere со всеми вкусностями»?@гыгы я MS разработкой не занимаюсь, сами пишите;)
А вот аналоги WPF и Silverlight в Java есть -, но они довольно угрюмы.
2Paul
Лондонская фондовая биржа (London Stock Exchange, LSE) подтвердила информацию о том, что сменит платформу TradElect, основанную на.NET, на разработку от MillenniumIT на базе Linux и Solaris.Стоимость использовавшейся до сих пор TradElect составляет 65 миллионов USD, а решения от компании MillenniumIT из Шри-Ланки — 30 миллионов USD. Ожидается, что с новой платформой LSE будет ежегодно экономить около 15 миллионов USD начиная с 2011/2012 годов. На интеграцию разработки MillenniumIT, базирующейся на Linux и Solaris, потребуется около 1, 5 лет.
8 октября 2009
так так, знакомая песня: «Пастернака не читал, но осуждаю...»
@Paul редко в таких случаях виновато что то одно- комбинация факторов думаю. Опять же они наверно во многом были первопроходцами с решением на такой платформе- так что опыт сбора граблей получили в незамутненном виде...
но опять же — продукты от MS... a альтернативы? Java инфраструктура хороша обилием альтернатив (правда иногда это жутко бесит — неудачный выбор набора технологий — и ваш проект в жопе)
@DmitriyK
подскажите мне аналог сервера апликаций типа WebSphere со всеми его вкусностями в.net.
Не могу придумать ничего незаменимого из WebSphere. Скажите что вы считаете вкусностями — я скажу аналоги.
Или там WS MQ? А как с ESB решениями?
MSMQ, BizTalk
Лондонская фондовая биржа (50 процентов международной торговли акциями) крутится на точкаНете, правда у них там куча проблем с этим софтом, но кто виноват платформа или разрабы я так и не понял...проблемы уже устранили
Лондонская фондовая биржа (50 процентов международной торговли акциями) крутится на точкаНете, правда у них там куча проблем с этим софтом, но кто виноват платформа или разрабы я так и не понял...
net- хороший инструмент для мелких проектов. С хорошими преспективами, идеями -, но пока катастрофически далекий от ентерпрайза в западном его понимании
это правда? ужас.
пока net- хороший инструмент для мелких проектов. С хорошими преспективами, идеями -, но пока катастрофически далекий от ентерпрайза в западном его понимании
подскажите мне аналог сервера апликаций типа WebSphere со всеми его вкусностями в.net
Пардон за ответ вопросом на вопрос, но в самом деле — а что такое умеет WebSphere (если мы говорим именно об Application Server), чего не умеют .NET и Windows Server?
Транзакции — запросто. REST — пожалуйста. XML — не вопрос. Компонентная модель — пожалуйста. Аналог OSGi у Microsoft тоже есть — MEF называется. Web и mobile разработка — присутствует. Вот разве что по поводу «дружбы» со всякими SAP и Siebel я не уверен, с кем из них умеет работать BizTalk, а с кем — нет.
Или там WS MQ?
Если говорить именно про message queueing — то MSMQ более чем хватает. Для более навороченных ESB решений — см. ниже
NServiceBus, MassTransit, Rhino Service Bus, ESB .NET,А как с ESB решениями?
Некоторые из них построены на базе MSMQ.
понекрофилю следом за вами
и что из этого опенсорсное или не дай бог бесплатное?
у нас например неслабое кластерное решение есть. Платного там Oracle и MSSQL (нормальная база ничего плохого сказать не могу)
а вообще там ниже по теме вроде все неплохо обсосали
Cobol в продакшенах в полный рост (и будет там еще лет 10, а то и 20), а MSюнгерт уже Java хоронит:)Если Java займет место Cobol — буду считать что мой прогноз сбылся.спасибо развлекли
И ладно MSюргентами обзываться:) Сейчас есть масса компаний и проектов где лучше Java и чуть меньше, но тоже большое количество мест где лучше.Net. Просто при прочих равных лично я за.Net — по причинам выше описанным.
спасибо развлекли
+1через 15 лет ни Java, ни C# не будут массово использоваться.
Wer redet heute noch von der Vernichtung der Armenier?
2. будет все супер, невообразимые сейчас компьютеры и языки под них (не сабж)
Шарпей конечно, типа кругом тя MS, а наверху # (решетка) -как в зиндане типа.Что будет рулить Шарпей или Джава?
сквозь # виднеется небо в облаках и пахнет Джавой))
Функциональное программирование как-то слабо вяжется с GUI в моём понимании, а юзать из F# не GUI, а что-то другое с FCL, так не всё оно соответствует функциональному подходу и тогда опять же в чём здесь скрыт смысл?
отличие от F#, тут мозги на изнанку выворачивать не нужно.
Да, изучение F# значительно повышает ваше ЧСВ.
-
Вы кстати не задумывались почему МС ставит именно на С#, а не скажем на F# или питон, которые имеют поболее синт. сахара чем С#?
Я бы не сказал, что внимание к F# значительно меньше, нежели к более традиционным языкам и технологиям. Похоже, мелкомягкие всерьез нацелились вернуть размягченные ООП-парадигмой мозги коммьюнити к функциональности.
Жесткий офтоп, но ладно:)Лисп медленнее джавы?
Я пока вижу тесты над которыми люди проделали довольно большую работу и ваше утверждение в одну строку в стиле «мой шворц больше». Почему мне надо верить второму?
LINQ и lambda дают возможность декларативно описывать доступ к данным, что для приложений, работающих, в основном, с массивами данных — неоценимый плюс. Аналогично — анонимные типы.
Лисп медленнее джавы? Выбрось этот чарт на помойку. Не стоит верить всему, что пишут в интернетах. Самое время вспомнить поговорку «На заборе тоже... написано», а лежат дрова.
И интересно получается те кто выбирал язык потому что студия классная или потому что однокомнатник пишет на языке А, получают не очень высокую ЗП
Возможно, вы удивитесь, но не все былокодеры вышли из киевских общаг.
Есть тесты которые не столь пессемистичны
Значит я просто не умею ее (Скалу) готовить:)
2 crypto5
каким обьемом знаний нужно обладать что бы ее понять
Ну самая сложная программа изложена стариком золотой рыбке:
причём объём знаний деда стремится к нулюсделай мне кайф
Простота языка скрывает сложность его выполнения
у Scala — основная проблема не редакторы, а скорость, на порядок ниже чем у Java (ну может не на порядок, но в 3−5 раз точно)
Есть тесты которые не столь пессемистичны shootout.alioth.debian.org/...4/benchmark.php test=all& lang=all
На мой взгляд он становится только проще. Меньше кода, ликоничнее.Есть конечно спорные вещи: тот же тип dynamic.
Количество строк кода программы — это не показатель ее простоты, показатель — это каким обьемом знаний нужно обладать что бы ее понять
Да и по поводу F# — сравнивать его с C# нельзя — совершенно другой стиль программирования. Это не добавление «синтаксического сахара» в императивный C#, это функциональный язык с возможностью использовать императивный стиль. Этот язык мейнстримом врятли сможет стать ближайшие лет 5−10. А вот Scala для Java — тут перестройки мозга практически не требуется — идеология таже, кода меньше.
На F# можно точно так же программить в ОО парадигме там все есть.
Правда что у F#, что у Scala есть детская болезнь
Про F# не знаю, но у Scala — основная проблема не редакторы, а скорость, на порядок ниже чем у Java (ну может не на порядок, но в 3−5 раз точно)
А С# с такими маркетинговыми порывами МС скоро станет сложнее С++На мой взгляд он становится только проще. Меньше кода, ликоничнее.
Есть конечно спорные вещи: тот же тип dynamic.
Да и по поводу F# — сравнивать его с C# нельзя — совершенно другой стиль программирования. Это не добавление «синтаксического сахара» в императивный C#, это функциональный язык с возможностью использовать императивный стиль. Этот язык мейнстримом врятли сможет стать ближайшие лет 5−10. А вот Scala для Java — тут перестройки мозга практически не требуется — идеология таже, кода меньше.Вы кстати не задумывались почему МС ставит именно на С#, а не скажем на F# или питон, которые имеют поболее синт. сахара чем С#?
Правда что у F#, что у Scala есть детская болезнь — редакторы если и работают корректно, то не многим отличаються от notepad.
-
2 WIgor Ну вот, я так и думал
при создании таблицы,и то и другое сопоставимы
2 denis.gz, извините не буду ставить на Джобса, вот уж кто маркетолог. На продукции Эппл не работают, её лелеют и милуются, и архитектора там то же нет
2 Андрей
Да, не уточнил — генерировалась html таблица. База данных в тесте отсутствовала как таковая.всего лишь проверка скорости жесткого диска, если базасоздаётся на диске
Скорость-то по сути была одинаковая при любом случае Java или.Net — только при включеном ViewState было дольше — что вполне естественно так как размер веб-странички существенно больше. То есть на простейшей задаче из web разработки — и то и другое сопоставимы. И то, что говорили что hibernate быстрее nhibernate — ну может так и есть для этих двух отдельно взятых orm, а может быть при тестах забыли выключить\включить какую-то дефолтовую опцию у nhibernate (по аналогии с ViewState для ASP.NET)?
-
Ну канешно, куда миллионы вкладывать, непонятно, особенно когда это решают маркетологи.ставки хотите сделать
Чего то про МС кажется, что навороты в шарпе от отсутсвия архитекторов. Архитекторы свои фирмы понаделали их страшно нехватает у МС. Их всего то может человек 10 в мире, типа страустрапа или самого Билли в молодости.
-
-
А что тут думать. C# это мейнстрим, язык общего назначения. Задуманный, чтобы сделать проще разработку под.NET (сравните с C++/CLI, бррр). Имеющий традиционную императивную парадигму. У него априори будет большая область применения и большая аудитория, чем у F# и прочих. Таковы стереотипы, если хотите.
Точно как и джава — язык общего назначения, и не нужно ее перегружать всякими элементами лямд (linq). Для таких вещей как я уже говорил есть groovy и scala. А С# с такими маркетинговыми порывами МС скоро станет сложнее С++.
-
2 silverwolf
Ну писали уто то тут в другой ветке, что шарп написан по мотивам джавы, после того, как МСы получили штрафы за джаву в Винде, и им пришлось нашарпить.А C# — еще и в планах не было:)
Ну объясните бестолковым, что же где же куда же. мейнстрим не оправдание, вон пхп мейнстрим, ну и что?
Джава вообще тогда только для апплетов годилась, когда нам ее читали (97 год).
А C# — еще и в планах не было:)
Есть переменная, есть на нее указатель.Указатели сборщик не удаляет, потомучто он их незнает
Если же запретить собирать переменную, то она может попасть в более старые поколения, как результат хуже очистка памяти (особенно если переменная содержит большой объект, то есть саму структуру, а не ссылку на нее). Кроме того программист должен не забить запретить собирать переменную — вот в этом и увеличении опасности.
-
Tomcat не знаю, а вот ASP.NET пишет точно, если считает нужным. Дело вот в чём, согласен, что
генерить контент для отдачи и писать его на диск — это смешно.
, только если база 10 Тера, а результат запроса 10 к, то пытаясь угадать запросы 99% народа ответы (html) yf частые запросы создаются уже при генерации базы сразу и кладутся на диск, что бы не загромождать память и не тратить время на них при запросах, если сам запрос длится скажем 30 сек (база 10 Тера), а чтение ответа с диска 12 мс, то наверно есть выигрыш, к томуже при перезапуске сервера если что всё готово.
Да я знаю, что там есть сборщик мусора в шарпе, но он вроде выключается, кокгда надо. Так Вы объясните, почему со сборщиком мусора указатели опасней? Указатели сборщик не удаляет, потомучто он их незнает
то опять же на диске, суда по времени создания, соответственно и кеш там же
Tomcat вроде стараетсо пользоваться памятью (я там не видел потоков которые не с памятью работаю, но я особо не копался), генерить контент для отдачи и писать его на диск — это смешно.
Странно, а пишут, что сборщик появился как раз потому, что нет указателей, объясните пожалуйста.
В.Net есть сборщик мусора, по крайней мере так говорили несколько лет назад.
Вообще то
Задача — генерация таблицы с пару тысяч строк
Ну если и Вы правы, т.е.
страница с табличкой (хтмл).
, то опять же на диске, суда по времени создания, соответственно и кеш там же
2 silverwolf
Странно, а пишут, что сборщик появился как раз потому, что нет указателей, объясните пожалуйста.учитывая наличие сборщика мусора, указатели становятся еще более опасными чем в C
Ну, уже говорилось, что сборщик мусора и реалтайм несовместимы, извините, если что.
Давайте начнем с начала. В неуправляемых языках (C/C++) программист управляет выделением и освобождением памяти самостоятельно. В управляемых же (C#, Java) за него это делает виртуальная машина.
Следовательно, в неуправляемом языке указатель на нечто в памяти будет валидным до тех пор, пока вы сами это нечто из памяти не удалите или не переместите по другому адресу. В случае же с управляемыми языками сборщик мусора по умолчанию ничего не знает про ваш
В C# (вернее, в .NET Framework Class Library) имеются средства проинструктировать сборщик мусора на тему «На вот этот объект имеется низкоуровневый указатель, его не трогай, пока я не скажу, что можно», а Silverwolf говорит о том, что новички об этих средствах могут быть не в курсе.
Кстати большее время IIS7 в основном объясняется записью на тот же диск более развитого индекса
Какие индексы у веб-сервера? Можно поподробнее, кэш в памяти, так контент вроде динамический.
всего лишь проверка скорости жесткого диска, если базасоздаётся на диске.
Так вроде же не база создавалась, а страница с табличкой (хтмл).
Ладно уговорили, джава — язык для былокодеров, C# — нет:)
А можно всю логическую цепочку? А то как то не прозрачный вывод.
в шарпе еще указатели есть и всякий там unsafe, давайте за это его поругаем:)
А вот ничего смешного. Поскольку учитывая наличие сборщика мусора, указатели становятся еще более опасными час в C.
Выбирая технологию, обычно никто не тратит несколько лет на попробовать то, попробовать это.
Тогда давайте не будем говорить о «не удобности языка». Кстати, обычно у вас есть 4−6−9 лет на то что бы «попробовать то, попробовать это» — универ называетсо.
Это уже ближе к теме. Много сокурсников говорили что выбрали C# потому что там «студия классная». И интересно получается те кто выбирал язык потому что студия классная или потому что однокомнатник пишет на языке А, получают не очень высокую ЗП, некоторые ищут работу (не на одном месте дольше 0, 5 года не задерживались). Такой подход говорит о человеке не с лучшей стороны.Выбор делается еще в самом начале, зачастую интуитивно, на основе либо курса в универе, либо самостоятельно прочитанной книжки.
Что такое *.Parallels, можно ссылку где почитать?
Но на старте, C# был куда удобнее и продвинутей Java тех же лет, то же касается и библиотеки.
А конкретнее? Особенно про библиотеку?
Ладно уговорили, джава — язык для былокодеров, C# — нет:)
Вы кстати не задумывались почему МС ставит именно на С#, а не скажем на F# или питон, которые имеют поболее синт. сахара чем С#? И джава и С# это компромисы между простотой, предсказуемостью с одной стороны и фичами с другой, просто компромисы разные.
Уважаемый, всегда считал, что такая
всего лишь проверка скорости жесткого диска, если базасоздаётся на диске.Задача — генерация таблицы с пару тысяч строк.
Кстати большее время IIS7 в основном объясняется записью на тот же диск более развитого индекса, что в итоге ускорит исполнение запросов, хотя Вы и не просили его, он индекс (индексы?) делает по умолчанию
Та ладно, в дотнете давно есть MS Test, NUnit. Для dependecy injection применяется Unity и Spring.net
Я не говорил что их нет, я говорил что.нет аналоги в роли догоняющих.
-
2crypto5
например в unit testing, dependency injection.
Та ладно, в дотнете давно есть MS Test, NUnit. Для dependecy injection применяется Unity и Spring.net
Интересно — надо проверить. Както проверял ради интереса Tomcat (JSP) vs Resin (JSP) vs ASP.NET vs ASP.NET MVCHibernate однозначно быстрее чем NHibernate, это проверено.
IIS7\ASP.NET MVC 0, 5 41, 3 136037
По моему это не так:)
Hibernate однозначно быстрее чем NHibernate, это проверено. Правда говорят у MS есть свой ORM, который «почти как взрослый», я не сталкивался, только слышал.
И что-то мне подсказывает, что приложения, написанные для исполнения на «виртуальных машинах» будут довольно-таки тормознутые, в условиях 1Гб оперативной памяти, да чипа, по мощности сопоставимого с P4 (это платформа следующих лет 3, если не 5).
Ну и многие.net аналоги отстатют от своих братьев джава — например в unit testing, dependency injection
По моему это не так:)
Без синтаксиса свойств пришлось бы обвешивать эти методы атрибутами, чтобы как-то связать их вместе в одну сущность.
А вы не задумывались как это работает в Java? И при том появилось раньше чем C# как язык (вроде договоренность про сеттеры геттеры была еще до создания Java). В C# просто добавили синтаксическую обертку, я сходу не могу представить не одного места где она была бы необходима или давала значительные преимущество созданию сет-гет-методов (особенно если учитывать что их умеет генерировать любая ИДЕ)
«Дети» когда-нибудь вырастут,
Самое смешное что некоторые так и не «вырастают» — их называют «быдлокодерами», и в их руках всякие синтаксические финтифлюшки из спичек превращаются в бомбы.
а джава так и останется неудобным языком.
Хотелось бы поинтересоваться: Через сколько лет серьезной разработки на Java вы поняли что она не удобна? Чем именно она неудобна?
Во первых как выделенное относиться к Java?
Во вторых вопрос сводитсья к бесплатности linux в отличии от windows. Все что дальше перечислено можно переписать вот так /postgersql или вобще любая база включая mssql express/asp.net (mvc) /linq2sql или entity framework или nhibernate/iis/jqueryМне кажется, что все такие агрументы, почемуто исходят из идеи: раз windows платно — то все остальное тоже, соответственно раз linux бесплатен — то все остальное тоже. И если говорить о серверных продуктах то сравните цены на Windows Server и WebSphere.
Вы правы, все сводится к платности виндовс и студии, но это сути не меняет, на джава я могу разрабатывать совершенно бесплатно серверные решения, а на.net нет.
а померять просто, посмотреть сколько соответствующих проэктов на codeplex, sf.net и google code.А кто-то мерял количество? Я например аналоги библиотек могу найти практически всегда. А если вдруг в java 3−5 похожих библиотек, а в.Net одна — если она хорошая — какая разница?
Ну и многие.net аналоги отстатют от своих братьев джава — например в unit testing, dependency injection.
У Microsoft армия тоже хорошая — банкам бы вполне хватило.
Это так кажется, IBM очень сильно развила консалтинговый бизнес для большого бизнеса, МС тут проигрывает.
Пока не видел этих мейнфреймов ни в одной компании с которой работал. Можете привести пример компаний которые их используют? По крайней мере наш Enterprise — он в массе попроще (всякие HP сервера — в лучшем случае)
У большинства больших загран. банков (bank of america, citi) например операции по перекидыванию денег между эккаунтами происходит на мейнфреймах.
Именно поэтому я считаю, что если Java не нагонит этого «сахара» себе — она со временем вымрет.
-
касаемо сабжа
Через пятнадцать лет останется джава или останется C# в масcовом использовании?
концепция Джавы оказалась на удивление толковой и живучей.
Перечитайте первый пост темы — там человек задает вопрос. Вот на него я и отвечаю.
от темы мы все уже как бы уклонились, перейдя к сравнению технологий.
Кстати работаю с обоими платформами уже более
10-ти лет. Поэтому знаю о чем говорю.
за прошедшие годы обе платформы настолько разрослись, что полноценно и одновременно владеть обеими все труднее, если вообще возможно.
Кстати работаю с обоими платформами уже более
10-ти лет.
Не надо преувеличивать,.Net выпущен то ли в 2002 то ли в 2003
Тема в общем не о сравнении платформ. Тема о том какая платформа выживет, грубо говоря «у кого маркетологи лучше».
вот это 100%
linux/postgersql/java/hibernate/spring/tomcat/jquery)Во первых как выделенное относиться к Java?
это правда, не относится ни к Джаве ни к MS
Кстати работаю с обоими платформами уже более
это полностью бесплатное решение цепи от БД до Веб аппликухи, сделанноеполностью бесплатный стек (например linux/postgersql/java/hibernate/spring/tomcat/jquery)
также, масса бесплатных опенсорс фишек может быть подключена для решения попутных задач типа логгирования, индексации итп.
А что могут натворить дети со спичками, страшно подумать...
Один из плюсов Java как раз в том что она не дает «детям» нанести сильный вред. Кстати в Java generics — это средство ограничить разработчика от ошибок (которые могут возникать если разрешить использовать в них примитивы и сознавать экземпляры)
В.Net 2 (или то была уже версия 3, не помню) свойства превращались в методы на этапе компиляции, насколько я видел. Что мешает место свойств использовать set- get- методы? Претензии не к механизмы, а к реализации.На свойствах основаны data bindings и многие фичи дизайнера в студии, которые выполняются через reflection.
Я очень надеюсь на маркетологов Оракла:)
удивляет подход, когда сравнивают две сферы не имея полного представления об одной из них.
Во первых как выделенное относиться к Java?— нельзя построить полностью бесплатный стек (например linux/postgersql/java/hibernate/spring/tomcat/jquery)
Мне кажется, что все такие агрументы, почемуто исходят из идеи: раз windows платно — то все остальное тоже, соответственно раз linux бесплатен — то все остальное тоже. И если говорить о серверных продуктах то сравните цены на Windows Server и WebSphere.
Тут сказать не могу — не использовал такие вещи. Но разработки ведутся — вот к примеру research.microsoft.com/...nq/default.aspx— нету аналога hadoop, hive, pig.
И если вдруг сейчас нет систем продуктового уровня (хотя это не факт), то думаю скоро будут.
— нету систем управления зависимостями от сторонних библиотек (maven, jakarta ivy)
Это да. Таких вещей нет — по крайней мере продуктового уровня.
— ну и библиотек особенно опен сорс под джаву намного больше!
А кто-то мерял количество? Я например аналоги библиотек могу найти практически всегда. А если вдруг в java 3−5 похожих библиотек, а в.Net одна — если она хорошая — какая разница?
— нету армии консультантов и поддержки как например от IBM (поэтому многие большие банки выбирают джаву и дорогущие WebSphere)
У Microsoft армия тоже хорошая — банкам бы вполне хватило.
— нельзя запускать на супернадежных мейнфреймах
Пока не видел этих мейнфреймов ни в одной компании с которой работал. Можете привести пример компаний которые их используют? По крайней мере наш Enterprise — он в массе попроще (всякие HP сервера — в лучшем случае).
Если вас интересуют синтаксические финтифлюшки
Вообще то финтифлюшки делают для повышения производительности и уменьшения ошибок. Думаю у джавы и у шарпа свои скелеты есть в шкафу, но лично мне главное, что оба имеют «хозяина» в смысле надо платить рано или поздно за что нибуть, за инструмент, за среду, за библиотеки, и как только заплатил, снова изменяется версия и нет обратной совместимости и надо снова всё переписывать и снова платить. Лучше что бы всё зависело от меня, поэтому прохожие и пишут, им то же хочется, но наверное это недостижимый идеал
По поводу Azure — я вообще не понял почему его упомянули, что в нем революционного? Чем не подходят обычные VPS, E2, есть AppEngine наконец?
-
А как насчет PLINQ или либа *.Parallels, или Windows Azure? В джаве есть что-то подобное?
LINQ, lambda — аналогов в Java нет, var декларация переменных — тут на вкус и цвет конечно — но мне нравиться, объявления анонимных типов вроде new {Property1=’1’, Property2=’2’} — аналогов нет, dynamic тип — аналогов нет
Вам нравится — это одно, а эффективно — это другое. Скажите, то что вы перечислили — это необходимость? Я в этом далеко не уверен.
Ну еще свойства удобнее ИМХО — лень мне дописывать get..., set..., is...
Лень она и есть лень, а вот то что не понятно существуют ли сеттеры и геттеры — это уже чуть хуже. Иными словами сеттер выглядит как геттер — это не нормально. Даже Рихтер (вроде так зовут) такое говорил.
Обращение к спискам list [i] map [key] по моему более лаконично чем list.get (i) map.get (key)
Тут реально проблема, я бы сделал другие названия для методов get, хотя переопределении оператора [] — тоже вариант.
Generics лучше в.net — пруфлинк en.wikipedia.org/..._Java#Generics
Дженерики не лучше и не хуже — они разные. В C# они ближе к C+±шаблонам.
Кстати в Scala практически все уже есть.
Если вас интересуют синтаксические финтифлюшки, то может лучше таки Python. Проблема в том что многие люди считают «синтаксический сахар» — приимуществом. Вы только подумайте чего может натворить неопытный джун с индексаторами, свойствами и самое страшное с var-декларацией.
А вот в случае.Net и JRE — тут пожалуй не выберу
Кстати, говорят, что.Net 4 значительно лучше чем предыдущие версии в плане производительности.
Вам нравится — это одно, а эффективно — это другое. Скажите, то что вы перечислили — это необходимость? Я в этом далеко не уверен.
Не необходимость, но лучше писать одну строчку, вместо пяти. Кроме того — читаемость кода выше (когда привыкаешь).
Иными словами сеттер выглядит как геттер — это не нормально. Даже Рихтер (вроде так зовут) такое говорил.
Рихтеру не нравится, что свойства, будучи методами, выглядят как поля.
Я же говорил «Если говорить о языках\базовых фреймворках как таковых». Читайте ответ целиком.это дааалеко не вся Джава, если вкратце))
По поводу не всей Java — да есть Scala — в её я верю больше чем в Java. Ну либо Oracle таки возьметься за голову.
По языку — гдето так:А в чем конкретно она более чем обратная?
Так что если делать ставки между java и c# — то ставлю на c#. А вот в случае.Net и JRE — тут пожалуй не выберу.
Могу ещё поумничать и сказать что если будущее Интернет (а) — это Семантическая Сеть (Semantic Web), то ого-го сколько всего нужно будет переписывать и дописывать.Программистов будет на порядки меньше из-за автоматизации фреймворками.
Ну... или это я уж размечталась. Но в то что «программистов будет на порядки меньше из-за автоматизации фреймворками» не верю.
Программистов будет на порядки меньше из-за автоматизации фреймворками.
Какой-то странный вывод. Я о C#/Java не могу говорить, но на на PHP сейчас существует куча-куча фреймворков, готовых интернет-магазинов, систем электронной коммерции — и тем не менее люди продолжают заказывать кастомные (custom) сайты, ибо каждый бизнес — уникален. Это несбыточная мечта — чтобы существовали фреймворки на все случаи жизни. Всё идёт/меняется и даже на старые сайты (и наверное не-сайты тоже) каждый год нужны и заказываются новые фичи.
интегрируйте его в Баду непременно, и документацию — на русском.
ээээээээээээээээээээээээээээээээээээээээээээээээээээээээээВ 2012 конец света, так что не парьтесь:)
жаль, Сашка -синего нету))
В 2012 конец света, так что не парьтесь:)
А я думал, что я единственный верю в прилет нового календаря майя, который разрушит Землю:)
*пляя точно ((В 2012 конец света, так что не парьтесь:)
налоги — туда же.
В 2012 конец света, так что не парьтесь:)
Ну если разогнаться до скорости света, то по теории относительности можно надолго растянуть два года
Из какого кирпича будут делать дома через надцать лет, правильно, из красного и силикатного, белого. Будет и шарп и джава. Программистов будет на порядки меньше из-за автоматизации фреймворками.
Посмотрите с какой скоростью развивается дотнет. Я уверен, эта платформа будет еще долго существовать, т.к. ее продвигает и развивает Microsoft.
А джава стоит на месте что ли? Ну и ее тоже всякие IBM, Oracle и прочие развивают.
А после покупки ораклом сана, вообще не верится в будущее джавы...
Это почему?
Это как рах минус что он так быстро развивается, большой проект переживает несколько новых свистулек от микрософта.
Если говорить о языках\базовых фреймворках как таковых:хм, если
с2004-го года Java из версии 5 подросла к 6, в тоже время.Net с версии 1.1 до 4.0.Net 1.1 явно не дотягивал до Java 5, сейчас при сравнении.Net 4.0 и Java 6 ситуация более чем обратная.То есть судя по тенденции, на срок 15 лет — я бы ставил на.Net.
то получаем обманчивую картину))
Java из версии 5 подросла к 6
это дааалеко не вся Джава, если вкратце))
А после покупки ораклом сана, вообще не верится в будущее джавы...
сейчас при сравнении.Net 4.0 и Java 6 ситуация более чем обратная.
А в чем конкретно она более чем обратная?
не скажу за ms, ,Если говорить о языках\базовых фреймворках как таковых:
а Джава так прирастает и обновляется, что только успевай догонять-учить.
То есть судя по тенденции, на срок 15 лет — я бы ставил на.Net.
1) Сейчас супер-профи в одной технологии не нужны.1) еще как нужны. такой супер-профи с трудом находит новую работу, потому сидит и кодит за скромную з\п. очень экономно в продуктовом проекте иметь набор узко2) Нужны те которые знают много технологий на среднем уровне.
2) ценность спеца с увеличением широты компетенции растет квадратично, затем упирается в «стеклянный потолок»
no pasaran 1 час назадДа любой язык прирастает технологиями. Просто большинство их них клоны старых с новым интерефейсом. И большую часть технологий можно доучивать в процессе работы с ними.
не скажу за ms, ,а Джава так прирастает и обновляется, что только успевай догонять-учить.
Сейчас супер-профи в одной технологии не нужны. Нужны те которые знают много технологий на среднем уровне.
MS тоже не отстает. C# 4.0, MEF, снова новый Silverlight, еще появится какой-то говномодныйлайт.
а Джава так прирастает и обновляется, что только успевай догонять-учить.
spill 41 мин. назадчерез пятьнадцать лет останется джава или с шарп?
А какая разница? Основные принципы у того и того одинаковые (C# удобнее), разница в фреймворках. А их почти каждый раз нужно изучать новый на проект (кроме основных).
-
А что касается Украины, как страны без собственного сильного потребителя, то писать тут будут «на чем скажут».
496 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів