Через пятнадцать лет останется джава или останется C# в масcовом использовании?

Через пятнадцать лет останется джава или останется C# в масcовом использовании?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

С момента публикации топика прошло 8 лет. Осталось еще 7. То есть большую половину отведенного топикстартером периода мы уже прошли. Как видим, .NET становится только лучше, выше, быстрее. Захватывает новые области и постоянно развивается. А Java... а что там Java -даже как-то и не интересно, когда есть .NET Встретимся через 7 лет? :)

Как видим, .NET становится только лучше, выше, быстрее. Захватывает новые области и постоянно развивается.

А у адептов дотНета все еще подгорает настолько что они некропостят в 8-летних темах.

Пока что все выглядит так:

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 лет получить )

www.tiobe.com/tiobe-index

Там нет якоря, поэтому вам прийдется прокручить вниз самому :)

Перший результат з гугла за запитом 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

Не ті технології порівняв, беру слова назад)

А у джава ещё остались какие-то достоинства по сравнению с дотнетом кроме кучи написанного кода?

Навіть Андроід-розробка в околиці Кронштадту тікає ;-)

доля жабы 4% а доля луа 5% — вы што там курите ?

Топик обнаружения диванных аналитиков.

Java как виртуальная машина никогда умрет.

А что касается языка, то судя по анонсам, лет через 15 это может быть совсем другой язык.

А что касается языка, то судя по анонсам, лет через 15 это может совсем другой язык.

Не исключено что этот язык будет Java8 :(

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

много такого, что сделает из нее что то вроде похожее на руби или скалу.

Это ж чего такого?

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

функции высшего порядка.

Не обещали.

введение дефолтных методов (похоже на трейты в скала),

От ни капли. Дефендеры — это развитие интерфейсов (по факту костыль, но таки общеполезный), трейты — это больше про миксины.

лямбды

Упрошенный синтаксис + (пока) минорные оптимизации для ... анонимных классов. Которые появились когда?

Java не умрет, станет новым коболом. Ее место займет Scala. С# будет один саппорт и багфикс, и неизвестно что с MS будет через 15 лет

Большинство ИТ-инфраструктуры бизнеса уйдет в облака. Рынок любит зарабатывать дешевыми и быстрыми методами, поэтому и был изобретен конвейер. Вся потребительская челядь :) будет полжизни плавать в тех же облачных сервисах. Т.е. морда как всегда какой-нибудь HTML10 и CSS6. А вот бэкэнд будет писан на куче разных языков в зависимости от платформы. Одного языка точно не будет.

А если приземленнее: что там решили с концом света: мне зимние сапоги покупать или я в осенних дохожу?.

Через 15 лет будет следующее «говорят, что в Москве кур доят, а в Рязани — грибы с глазами».

C# останется если Микрософт себя не погубит и сможет хотя бы не сдавать позиций на рынке.

Все среды разработки будут схожи на Step 5-7(LAD, FBD, STL) — цель быстрые средства разработки.

Десктопные платформы умирают, а вместе с ними мне кажется неизбежным и закат «традиционных» платформ разработки. Уже сейчас нужны «быстрые» средства разработки, с супер-коротким циклом прототипирования, типа Rails или Meteor или Bootstrap. Дальше эта тенденция будет только ускоряться, мне кажется.

э... по моему, из-за количества прототипов уже интернет скоро закончится.

есть такой тренд, но ИМХО, нужно учитывать его причины.
а они, мне думается в изменении пользовательского юзкейса. появилось большое число пользователей, которым достаточно возможностей «веба». и скоростная разработка ПО направлена именно на этот бурно растущий класс пользователей.

десктопы же, думается, станут оборудованием профессионалов. Никакое скоростное прототипирование не поможет в конкуренции скажем CAD систем.

Мне тоже так кажется. Добавлю, что для обычных пользователей веб-ос — отличное решение.

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

Я вижу три равновероятных сценария развития событий.

Через пятнадцать лет саммыми массовыми языками программирования будут естественные языки. Программисту достаточно будет громко сказать «Привет, Мир!», или показать это жестом, и голографичекий принтер сразу напечатает это на любой электронной бумаге.

Через пятнадцать лет программистов заменят роботами и самым популярным языком снова станет ассемблер. Система логически замкнётся и роботы будут писать программы для роботов, а люди только подчинятся. Причём отдельные роботы будут считать что настоящий язык это машинные кода, а майкрософт просто украл ассемблер и это не хардкор.

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

Через пятнадцать лет программистов заменят роботами и самым популярным языком снова станет ассемблер. Система логически замкнётся и роботы будут писать программы для роботов, а люди только подчинятся. Причём отдельные роботы будут считать что настоящий язык это машинные кода, а майкрософт просто украл ассемблер и это не хардкор.

Это называется технологической сингулярностью, только там будет не ассемблер, а язык совсем другого характера, я как раз таким занимаюсь.

Название этого коррелирует только с сортом утреннего виски у сайнсфикшн писателей

Можешь привести другие термины?

от ты ж зануда
рекурсивное самоулучшение, «большое откровение» — не читаю я давно нф. должно быть ещё.

я не хотел тебя троллить. само написалось. иди строй свой скайнет.

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

Бляяяя..... Пей салподеин в этот период лучше.

Не подскажешь зачем мне его пить? У меня все Ок.

Ещё можешь занять себя в этот период прочтением Суммы Технологий С.Лема.

Только не забудь мне пожалуйста сообщить когда у тебя этот период закончится.

для того чтобы заниматься языком будущего — вам стоит вначале заняться изучением связи мышления и обычного языка. по уровню троллинга — у вас слишком косная, слишком традиционалиская речь, для того чтобы создавать нечто качественно новое.

Через пятнадцать лет самыми массовыми языками программирования будут естественные языки.

вряд ли. слишком многозначны и контекстно-зависимые. не годятся для инженерии. а вот DSL — да, вполне, об этом писал.

«Роботы» и «все запрограммируют» — наверное когда-нибудь такое случится. сложно сказать когда, и в какой мере.

Признаться, я хотел пошутить, но как-то не сложилось, видимо.

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

или тролля, который объяснит тебе — до чего ж ты даун :)

Ты прав сережа, во всем виноваты троли, которые не понимают твоих безспорно тонких шуток

DSL это такая вещь, которую каждый захочет писать сам и под себя.

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

DSL это такая вещь, которую каждый захочет писать сам и под себя.

захочет то захочет, дык кто ж ему даст :)

Как то не ассоциируется у меня оно с массовостью.

а это не важно - хоть стопицот DSL сотвори - а жена тебе - а деньги где?

Только с сугубо специфическими

на то они и DSL

и тоже самое будет что и с фреймворками сейчас - да пиши свой лисапед, только вот...

очень локальными задачами.

врядли.

а вот указание руководства - есть такой расхваливаемый DSL для нашей специфики - берите и пишите на нем - будет обычным делом

И как DSL может охватить масштабный круг задач?

Их делают для спецов-непрограммистов. С низким порогом вхождения и нацеленностью на узкую задачу.

А самому программисту DSL просто не хватит.

И если есть какая то локальная задача, типа запросы к БД стряпать, то проще сисадмина напрячь, ну или профильного спеца заставить учить.

А если задача состоит в том, чтобы вот заставить девайс делать, что заказчик пожелает, там нужно что то более низкоуровневое.

В таких случаях нельзя просто нарисовать приложение. И через 15 лет нельзя будет.

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

Можно конечно, дать возможность программисту создания DSL под каждый свой проект. Тогда каждый накодит что то свое теплое и ламповое.

Но кто ж нам разрешит...

И как DSL может охватить масштабный круг задач?

наоборот, как все усложняющиеся специализации можно охватить с помощью универсального языка? :)

Их делают для спецов-непрограммистов.

не обязательно - непрограммистов.

Зависит от абстракций в DSL.

многие скриптовые довески к ПО - уже выполняют роль DSL, но требуют - знаний азов программирования. Например язык в Gimp, забыл название. И фильтры, и преобразования на нем пишутся.

А самому программисту DSL просто не хватит.

Какого уровня задач программисту? Одни программисты пишут компиляторы, другие - дописывают "джумлу".

Первым - не хватит, вторые и так - специализированы.

И если есть какая то локальная задача, типа запросы к БД стряпать

Для запросов уже есть язык. Если к реляционным БД - это SQL :)

но уже потребности ORM - порождают головняк и фреймворки.

А если задача состоит в том, чтобы вот заставить девайс делать, что заказчик пожелает, там нужно что то более низкоуровневое.

какой девайс, какого уровня действия от него ждет заказчик?
если управление сервоприводом - это один уровень

если вывести фотку котенка и мяукнуть - это другой.

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

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

И уже сейчас нет такого ЯП, одинаково удобного для разработки всех этих видов ПО. И тьюринг полнота ЯП - проблем никак не решает.

А вот отдаленность ЯП от предметной области порождает проблемы: проектирования, разработки и поддержки.

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

Можно конечно, дать возможность программисту создания DSL под каждый свой проект

Но - не нужно. Разве что - внутренний DSL, для сложного проекта.
А так - есть бух учет, есть классические, независимые от законодательств стран его правила. Есть - зависимые. Так вот DSL должен обеспечить такой уровень абстракции когда мы более легко можем написать это ПО, чем на более низкого уровня C++, Java или Ruby

а так как выражено будет описание на ЯП более близком к предметной области - то и читать, и модифицировать его будет - легче.

В идеале - да сами законы должны писаться на более формальном языке :) Но это уже к "Основанию" Азимова :) совсем далеко.

Тогда каждый накодит что то свое теплое и ламповое.

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

DSL - на самом деле очень широкое понятие. И те о которых намекаю - придут наверное не скоро, если вообще придут.

Но ЯП призваны решать задачи
повышение уровня абстракции (ограничивается аппаратными средствами)

сужение контекстного пространства (не искал как академически это называется, но языкоделам это известно)

первое более менее развитием ЯП обеспечивается.

а со вторым - вечная проблема.

DSL - ее то и призваны решить

P.S.
Кстати, глянул в вики - Предметно-ориентированный язык программирования
там ссылки есть
вот, из одной, раньше не читал:
Мотивация ЯОП приблизительно такова: мне нужна возможность работать в терминах концепций и понятий проблемы, которую я решаю, вместо того чтобы переводить свои мысли в нотацию языка программирования общего назначения (классы, методы, циклы, ветвления и т.п.). Для этого мне нужен язык, специфичный для предметной области.
www.rsdn.ru/…losophy/LOP.xml

Можно и нужно дискутировать о существующих подходах и реализациях

но сама эта мотивация - по моему все обостряется.

Можно конечно, дать возможность программисту создания DSL под каждый свой проект. Тогда каждый накодит что то свое теплое и ламповое.

Для этого и есть MPS. Где сам язык можна определить в терминах более низкоуровневой джавы (или любого другого языка, даже смеси других дэселей), а логику писать уже на дсэле. Это будет куда более ДДД, чем то что есть сейчас.

Для этого и есть MPS

Не только
Такого уровня есть
Xtext is a framework for development of programming languages and domain specific languages.

www.eclipse.org/Xtext

и сделанный на нем
Xtend is a statically-typed programming language which compiles to comprehensible Java source code.

www.eclipse.org/xtend

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

  • NoSQL база данных.
  • Node.js или Twisted для серверной логики.
  • Стастические HTML-страницы и богатая JavaScript логика на клиенте. Например, рендеринг страниц преимуещственно в браузере. Это происходит уже сейчас.

А что будет через 15 лет предположить невозможно.

ДжаваСкрипт зохватет мир?

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

Думаю, да, захватит. Безотносительно личных предпочтений очень уж много преимуществ у описанного мною стека. Из-за инертности людей и рынка это пока еще не мейнстрим, но скоро станет мейнстримом.

а какие у этого стека плюсы?

Ну как же, это почти как на PHP с MySQL, только круче и моднее!

Причем тут «круче и моднее»? Вы действительно считаете, что нет ощутимых преимуществ для многих задач?

Если бы я был бы PHP веб-разработчиком, то я конечно тоже бы считал, что Node.js или Twisted это лучше чем на PHP (наверно у них даже есть нормальный вменяемый API, с нормальными вменяемыми именами для функций) к примеру.
Ведь разве существуют в мире другие языки? Скажем с более строгой типизацией и с чуть другим ООП? А даже если бы и существовали, у них преимуществ то и не особо, поэтому они никому и не нужны конечно, были бы.

Поэтому NoSQL + node.js — это самые лучшие инструменты для большинства задач в вебе. И не в вебе тоже (вообще круто, можно ведь подымать Node.js и NoSQL локально, и писать точно также как под веб, и рич интерфейс на JS и HTML5 в помощь) , так как выше уже было написано, JS — единственно истинный кросс-платформенный язык (вот только Twisted тогда нужно вычеркнуть с его Питоном)

Что касается NoSQL. Зачастую мы сталкиваемся с необходимостью хранить объекты. Нам не нужна их декомпозиция в 3NF, так как в реальности многие объекты нам нужны в виде единого и неделимого целого. Очевидно, что NoSQL предоставляет лучший инструментарий для этого как с точки зрения производительности, так и с точки зрения программных интерфейсов.

Что касается Node.js. Тут плюсов очень много. Это и возможность использования одного языка по всему стеку, и возможность быстро обслужить запрос и продолжить выполнение затратной логики после отправки ответа, и нативная поддержка JSON, который стал стандартом де-факто для обмена данными. Список можно продолжить.

Что касается статического (по возможности) контента и богатой JavaScript логики. Тут все очевидно. Этот подход позволяет перенести нагрузку с сервера в браузеры. Так приложение работает быстрее, а операционные расходы сокращаются. Кроме того, когда это необходимо, статику можно разместить в CDN и, таким образом, еще сильнее улучшить показатели производительности.

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

да всё это здорово. вот только этих nosql хранилищ данных тысячи и всякие фейсбуки и контактики делали свои простые хранилища, которые отвечают именно их потребностям, а рыб помельче вполне удовлетворит реляционная база при том, что использовать ее они будут только как хранилище данных.
все киллер фитчи хипстерских языков реализуются в мейнстримовых быстрее, чем хипстерские языки становятся популярными.

ну насчет богатого клиента — то тут вы конечно же правы. интерфейс становится более отзывчивым.

facebook в основном mysql юзает и слезать не собираются.

ну да, но для каких-то нужд они всё-таки разработали кассандру. а еще hbase используют.

На касандру они забили болт, а hbase используют для организации текстового поиска по сообщениям, по крайней мере так написано в интернетах.

ну я про кассандру писал лишь к тому, что текущие реализации документопомоек подходят не всем и они лепят свои реализации

Ну да, но как оказалось не всегда получается

Что касается NoSQL. Зачастую мы сталкиваемся с необходимостью хранить объекты. Нам не нужна их декомпозиция в 3NF, так как в реальности многие объекты нам нужны в виде единого и неделимого целого. Очевидно, что NoSQL предоставляет лучший инструментарий для этого как с точки зрения производительности, так и с точки зрения программных интерфейсов.

NoSql != обьектные базы. Последним 100 лет в обед уже.

Это уже терминологические споры. Понятное дело, что когда в 2012 году мы говорим NoSQL, подразумеваем в первую очередь MongoDB, во вторую — Redis. Хоть у них и разные контексты применения. И говоря о преимуществах использования NoSQL мы как правило говорим о преимуществах MongoDB в сравнении с MySQL и MS SQL. «Столетние объектные базы» как-то выпадают из такой дискуссии.

NoSql это еще и cassandra, hbase, riak и туева куча других баз, которые совсем не обьектные, или документоориентированные.

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

я конечно могу ошибаться, но обычно когда сравнивают скорость того же Mysql и mongoDB — сравнивают как-то уж очень по-тупому.

тупая запись и тупое считывание.

... и тупое считывание.

потому что они, NoSQL и появились ради обильного тупого считывания :)
будь то обслуживание в вебе тьмы клиентов
будь то модная BigData.

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

а браузер есть везде.
Что правда, и с одинаковым API? Не говоря уже о том что API браузера недостаточно для многих задач. JS гибкий, приятный язык, но ни как не истинно кроссплатформенный, и никак не самый лучший (если такой вообще есть)...

В предыдущем комментарии совершается та же самая ошибка, NoSQL — не заменяет везде классические реляционные СУБД.

EDIT:
На самом деле, так можно сказать и про С/C++, компиляторы есть везде (точнее во всё).
Да и виртуальные машины Java, тоже есть везде, даже есть там где нету полноценного браузера (мобильные телефоны которые ещё недавно выпускались).
Если игнорировать API и какие-то различия в среде в которой код выполняется (у браузеров тоже есть различия), то тот же C# есть на линуксе, маке, винде, iOS, Android.

NoSQL — не заменяет везде классические реляционные СУБД.

Везде — действительно не заменяет. Но во многих приложениях заменяет. Причем очень успешно.

Но во многих приложениях заменяет.

я бы сказал — не во многих, а в известных и обсуждаемых.

почему вообще воскрес NoSQL, ведь «scheme free» базам и был когда-то ответ в виде RDBMS, и вытеснили они их.

а воскрес, потому что появились задачи которых не было — сотни тысяч одновременных запросов, причем не связанных между собой.
потребовалось горизонтальное масштабирование с невиданной ранее пластичностью. чего от RDBMS сложно добиться
и все. остальное — детали.
в слове «NoSQL» — неточность. не отражена их суть, цель появления :)

Они не 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, но вот косвенно...)
— для серверной логики — вообще говоря прямой связи нет. Просто — фронтэндщики захотели еще и бэкэнд сами писать. Ну тогда да, им — Node.js самое то.

— Статические HTML-страницы и богатая JavaScript логика на клиенте. — а клиент то — планшетник. и далеко не всегда о 4ех головах. у меня о 4ех головах x86 по 3+ GHz на dou.ua Хром начинает тупить иногда... Так что — пишут нативное все больше, на iOS или Андроиде...

А что будет через 15 лет предположить невозможно.

да проще некуда:
либо тоже самое что сейчас,

либо и представить трудно

...пообщался вот с одним стаааарым знакомым. давно в реале не виделись :)
У них ПО, по SaaS продаваемое, B2B, с своими несколькими «облаками» написано на С и PHP для веб мордочки. Ну и все остальные привычные дела — головные в штатах, сейлсы в штатах и европе, разработчики с саппортом тут, а клиентам в штатах, европе, и вот еще на Бразилию вышли. Несколько лет работает в этой фирме — клиентов все прибывает, людей не хватает...
Но я к чему вспомнил — будет ли успешная эта контора уходить с фряхи(в их датацентрах она), С и PHP на другое?

а, забыл, DB — от Oracle

NoSQL — проблема: «CAP теорема», которая как бы и не теорема..., а так, эмпирическая мыслишка. То есть — «веб-приложение» ничего не говорит о том — что собственно оно реализует, какую предметную область. Оказалось, для «фейсбуков» ACID не нужен. (очень интересный теоретический вопрос что CAP теорема не входит напрямую в противоречие с ACID, но вот косвенно...)
facepalm.jpg
нагуглил презенташку попроще
чтобы мало буков было

www.slideshare.net/...nal-data-stores

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

Я в этом всем несколько разбираюсь,

да-да :D

меня позабавил твой неупорядоченный поток мысли.

ах это всего-то D

конченный тролль только то в постах и ищет :D

конченный тролль

Ну я же тебе уже наглядно на пальцах обяснил, что конченный троль — это ты

Я в этом всем несколько разбираюсь,

да-да :D

Кстати, скромно напомню что совсем недавно ты имел очень не верное представление о предмете, о котором сейчас напыщено разсуждаешь, и именно благодаря моим усилиям стал на путь истинный, хотя похоже из-за бардака в твоей голове, усилия канули в лету. Пруфлинк: dou.ua/...ic/5773/#207626

ах оказывается я не знал разницы до твоего того комментария :D

это оказывается ты светоч мой, и все только от тебя можно узнать, если снизойдешь :D

завидная самоуверенность.
я вот ни об одном из своих уже за 2к постов такого сказать не могу

максимум, что может быть читающий пропустил нечто ранее, и мой пост просто подчеркнул нечто ему известное, или изменил весовой коэффициент в его ментальной БД.

Да, ты пишешь значительно меньше по сути чем я, все какие то копипасты и пространные расмышления не по теме получаются

то что пишешь якобы по сути
либо обычный троллинг всезнайки
либо банальности

поэтому я обычно и пропускаю.

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

доку да, можно цитировать и без ссылок. чем ты обычно и занимаешься :D

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

за следующме 15 лет маятник успеет качнуться еще минимум раза 2

Да, заменит какой нить Turbo C#

ИМХО — ни то, ни то.

Уверен, что как минимум одна «революция» в направлении разработки софта (или вообще в том, как будет выглядить и использоваться этот софт) однозначно будет за 15 лет.

Джава и сишарп никуда не уйдут, останутся как кобол...

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

в смысле JetBrains MPS?

да, у DSL куда больший потенциал изменить мир программирования, чем у мультипарадигменных языков.

Мне непонятно только почему вся передовая братия хипстеров, альтернативщиков-эксперементататоров и прочих «геев», дружно др0чит на метрику написания экспрешенов как можно меньшим количеством символов, напрочь забывая про все остальное. Про то, что проэкты большие, сложные, что их со временем надо поддерживать и модифицировать.

на метрику написания экспрешенов как можно меньшим количеством символов,

Про то, что проэкты большие, сложные, что их со временем надо поддерживать и модифицировать.

Потому что это их реальность.
ТекстМейт (или сейчас Саблайм) и проект который через 6 месяцев купят за 100500 денег. А когда купят, то они будут сидеть и командовать, а уже наемные инженеры будут переписывать код на джаве. От им то и надо будут паттерны и ЕДжБ.

А если за 6 месяцев не получилось, все выбрасываем и пишем новый. И так пока не получитсо.

А языкоделы... таже нода с темиже рубями, с тойже скалой «посмотрите как круто у нас можно записать цикл одной строчкой вместо 5 на ужас-джаве». Тупое рубилово бабла на тренде ?

а еще в руби нет этих дурацких скобочек и точку с запятой не надо ставить

Зато там есть длинный и некрасивый «end» вместо простого и понятного «}»

...

с тойже скалой «посмотрите как круто у нас можно записать цикл одной строчкой вместо 5 на ужас-джаве»

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

Ключевое слово — «разумная». Хотя кому-то и APL слишком многословен.

А ты считаешь что в скале лаконичность неразумная?

А языкоделы...

они либо в плену традиций, либо «математики», либо трудятся для кодеров (чтобы дать им один язык на все случаи жизни)

у нас можно записать цикл одной строчкой вместо 5 на ужас-джаве

это да, быстрая сортировка на Haskell выглядит конечно очень лаконично.

Так что если нужно будет писать сортировки — может возьму Haskell

Только — чего-то никому не нужно чтобы я писал сортировки...

Богдан уже частично ответил:

таков их «мирок».

У крутых языкоделов — «личный кабинет», кафедра, и научные тусовки. И иногда неплохие концепции, подходы, которые можно использовать если не впрямую, то в качестве вдохновения для инженеров-прагматиков

у мелких — выполняя свои десятки тикетов, хочется ж побыстрее реализовать это однообразие.

И вот почему я думаю что DSL имеет бОльший потенциал чем выразительный — но универсальный язык. Потому что он нужен как мелким, так и инженерам. При этом, «футуристическая картинка» будет такой: инженеры вместе с аналитиками — создают не фреймворк — а DSL, или наращивают уже созданный для этого вида задач. Собственно кодеры — имея сноровку в типичных задачах — будут бодаться не с языком и его фичами, не с инфраструктурой, а очень быстро реализовывать те самые рутинные задания. Уже потому что ошибок будет меньше, они, ошибки уйдут на уровень транслятора DSL, и будут головняком инженеров(как сейчас ошибки компиляторы или ВМ). И участие их в совершенствовании DSL тоже будет более весомым, а не как сейчас «ну вот те исходники, предложи допиши, авось в комитеры возьмут». Весомыми — потому что будут слать просьбы — не хватает вот такой конструкции, для такого типа ситуаций предметной области. То есть использование DSL повысит И качество обмена опытом, знаниями.

Недостатки, опасности у DSL конечно есть — «вавилонское смешение языков», тьма диалектов для одного и того же класса задач. Но с другой стороны — фреймворки уже его породили, ты можешь знать один, но тебе придется осваивать другой, хотя в нем те же концепции.
Но, когда устаканится, думаю будет несколько признанных DSL для каждого типа задач, и создание ПО будет иметь такой вид:

Берется DSL, добавляются в него недостающие возможности(они, описаны формально, так что потом можно переделать язык, а код переписывать будет не нужно, проблема транслятора поддерживать версии диалекта) Программисты-кодеры, или те кто работают непосредственно с заказчиком — на этом удобном для этого конкретно проекта — бытенько пишут нужный людям код. Намного быстрее чем сейчас, при тех же мозгах.

Вобщем это будет — очень другой мир программирования. Прикладного программирования.
Останутся конечно и Си, для эмбедед и системного ПО, тех же ядер ОСей, и С++ для игрушек, браузеров и ВМ.

Но там где сейчас коробочные ERP и Java-C# - очень много изменится. (первые не дают гибкости при программировании уникальных свойств заказчика, проблемы вторых — все на доу и без меня знают)

P.S.

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

на судьбе проекта куда сильней сказываются
1. адекватность модели той предметной области по которой она строится
2. адекватность кодирования и инструментария для воплощения этой модели

3. скорость внесения изменения в эту модель.

читабельность нужна для 3го пункта.

Концепция DSL — берется решать проблемы всех 3 пунктов.

Например по 1 и 2

идеи DDD — практически впрямую бы воплощались в виде DSL и его транслятора

Я думаю появится какой-то язык, на котором можно будет писать так же быстро и удобно, как на Джаве и Шарпе, но он будет компилироваться в нативный код. Все-таки тренд «Going native» нельзя не заметить и лично меня это радует.

Что-то вроде D, но он чето не выстрелил, нужна поддержка корпораций.

Rust — офигенный язык, но увы.

Посмотрел.
В D синтаксис почище имхо.

и я посмотрел, и согласен.

Да, 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. Тут правда, тоже не все ідеально, тому і з«являються хитрі фреймворки, але навчанні новачків і включення «в струю» відбувається знайно скорше.

на вихід за межі масиву до мови С, то вона стане набагато безпечніше. Але питання — чи варто?

для С — може й не варто

а може треба компромісний варіант — небезпечні і безпечні масиви.

Як надумаю робити свою мою на заміну — подумаю докладніше :)

вони мають ще і чудові бібліотеки.

так. але тоді треба аналізувати а чому у С++ такого не сталося, «стандартна бібліотека С++ ще багато чого не включає»

думаю то буде вже не зовсім про властивості мов програмування.
А про інженерію — як взаємодіє з ОС програма, у який засіб лінкуюєця код C++ та Java,

та «маркетинг» — хто відповідає за «стандартну бібліотеку», і такє інше.

для С — може й не варто

а може треба компромісний варіант — небезпечні і безпечні масиви.

ага, для С++ можна заюзати катомний клас, наприклад, а для того треба домовитися всім і одразу про такий клас, який юзати для такого масиву, щоб не треба було зхрещувати «велосипеди».

А покищо маємо std::vector та std::array operator[] без перевірки меж масиву а операція at з перевіркою, але ніхто не юзає at, натомість юзають operator[]...

так. але тоді треба аналізувати а чому у С++ такого не сталося, «стандартна бібліотека С++ ще багато чого не включає»
думаю то буде вже не зовсім про властивості мов програмування.
А про інженерію — як взаємодіє з ОС програма, у який засіб лінкуюєця код C++ та Java,

та «маркетинг» — хто відповідає за «стандартну бібліотеку», і такє інше.

як не дивно, але саме маркетингу Microsoft чи Sun/Oracle ми завдячуємо більш
консистентними апішками С# та Джави відповідно.

хоча це і недомократично і, можливо, не всі чудові ідеї втілено, а дещо реалізовано дубово, зато стандартно...

Насправді розмірковування подібні до дебатів про те, чому Лінукс досі не переміг Вінду...

tirania.org/...012/Aug-29.html

взагалі, контроль на вихід за межі масиву — я не відношу до «мовних» питань :)

тобто натякав я зовсім про інше, а не про ці проблеми.

Щодо «чому Лінукс досі не переміг Вінду...» — за роки цього питання втратив інтерес. :)

саме маркетингу Microsoft чи Sun/Oracle ми завдячуємо більш консистентними апішками

любий стандарт має два необхідних фактора, щоб бути дієвим стандартом
1. розробка єдиним колективом

2. масове використання цього стандарта

володіння розробкою інструмента так, дає можливість реалізувати ці два фактора.

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

З.ы. А ведь еще С++11 есть, со всякими rvalue references, var-args в templat’ах, да и вообще темплейтную магию никто не отменял.

появится какой-то язык, на котором можно будет писать так же быстро и удобно, как на Джаве и Шарпе,

ChinaJSC#

Мне почему то видится только одна область где может быть тренд ’going native’ - это смартфоны и планшеты. И причина только в, производительности (но это должно решится с развитием железа в телефонах — дешевле, производительней, холодней, и с появлением более емких аккумуляторов) и в том что на мобильных платформах существует монополия — кто делает платформу, тот выбирает язык/рантайм* по умолчанию, и поэтому используя С/С++ и компилируя в нейтив, можно переносить код гораздо легче (это могло бы решится, если бы разработчики платформы заранее бы предусматривали возможность — интегрировать разные рантаймы, на тех же правах что и какой то родной, но такого мы вряд ли дождемся).
В остальном же, менеджед рантайм имеет преимущества перед нейтив на мобильных устройствах — не нужно думать о железе, приложение работает на всех устройствах независимо от того — какой там процессор (в этом плане тренд помоему наоборот — ’go managed’, так как ’go cross-platform’).

Есть ещё embeded, но там как был нейтив, так и остался, может быть тоже даже наоборот... железо мощнее, хочется удобства, кроссплатформенности, высокоуровневости (netduino.com =))

*под райнтаймом — я имею ввиду среду выполнения, к примеру на Андроиде есть уже Dalvik, он там очень плотно засел, так что в любом случае, у Dalvik+Java преимуществ больше, чем у Mono+C# на андроиде. Невозможно или трудно впихнуть Mono, так что бы оно было не поверх Dalvik, и на тех же правах (оно должно работать для телефонов из коробки, без перепрошивки). Так что легче уж взять С++ и юзать нейтив (что бы реюзать код с другой платформы). Разве что так я могу оправдять этот тренд.

Это будет круто, если они это реализуют.
Сишарп компилируемый в натив — это прям мечта.

а зачем? что это дает, окромя 5% производительности ?

Меня лично ужасно бесит что обычные десктопные приложения тормозят. Я имею ввиду отзывчивость интерфейса, скорость запуска, это ужас просто. Я не хочу ждать пока джит откомпилирует полностью программу. Я хочу просто запустить и чтобы оно летало, как программы написанные на С++. Когда нажимаешь на какую-то вкладку или менюшку в первый раз в более-менее среднем приложение обязательно будет фриз на пару секунд. Ну что это такое блин? Это что веб-приложения что-ли? Нет, это десктопные, они обязаны летать. А скорость запуска? Тьфу.

Просто сравните скорость работы нескольких аналогичных по функционалу приложений написанных на плюсах и на шарпе/джаве.

Меня лично ужасно бесит что обычные десктопные приложения тормозят.

обычно десктопные приложения и сейчас написаны на С++

на джаве написаны IDE и разный корпоративный софт.

На C# - тоже немного десктопных приложений

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

Я не хочу ждать пока джит откомпилирует полностью программу

JVM можно сказать компилировать сразу, без набора статистики запусков.

.NET компилит сразу. Мало того, позволяет сохранять результат компиляции в натив между запусками приложения.

Кроме того, JIT не компилит всю программу, упрощенно там часть процесса такая
....
вызов метода
класса в памяти нет, загружаем
JVM его валидирует
начинает выполнять байткод метода
увеличивает счетчик вызовов метода
...
вызов метода который уже в памяти
счетчик по умолчанию 1500 для клиентской JVM 10000 для серверной — компилируем в натив
...

(сбор статистики для перекомпиляции в более эффективный код, например замена вызова по интерфейсу если возможно опускаю)

Фризятся приложения на JVM и .NET не из-за ненативности. А из-за — работы сборщика мусора.

Скажу про IDE на джава, и те приложения что использую, например RSSOwl — настраивайте параметры запуска JVM — памяти побольше давайте, и указывайте ParallelGC или CMS сборщики мусора. Можно еще указать запускать серверную JVM а не клиентскую, только не забыть указать количество вызовов метода когда сработает JIT. Фризов раздражающих как-то не упомню.

А скорость запуска?

Скорость запуска зависит больше от количества и размера файлов, которые требуется прочесть с диска. Starcraft и Фотошоп тоже не мгновенно стартуют :)

обычно десктопные приложения и сейчас написаны на С++

Ну да, так поэтому их и пишут на плюсах, потому что на дотнете или джаве оно тормозит. Боюсь представить как тупил бы Microsoft Office, будь он написан на WPF. Вижуал Студия 2008 просто летала, она была полностью на плюсах, а в 2010 добавили WPF и она стала работать медленнее, хотя не так конечно как Эклипс или Идея, которые полностью на Джаве.
Клиент евернота под винду сначала был написан на WPF и он был адским тормозом, потом переписали на плюсах и он начал летать.

Хотя WinForms приложения работают довольно шустро, иногда даже не отличить от нативных.

С тем что вы написали про работу JIT спорить не буду, полагаю все объяснения действительно верные.

вот не понимаю откуда такая уверенность, что приложения под десктоп писали только на с++. буд-то бы дельфей всяких и бейсиков никогда и не было.
ну и насчет тормозов 2010 студии по сравнению с 2008 как-то даже странно читать.
2005 тормозила по сравнению с 2003, 2008 по сравнению с 2005.

тоже на что-то другое с с++ переписывали?

Да нет, я просто для примера про с++ писал, на самом деле конечно же и на дельфях всяких писали и приложения были ни чуть не медленне чем на с++.

А вот 2012 студия по-моему даже пошустрей 2010-й )

Боюсь представить как тупил бы Microsoft Office, будь он написан на WPF.

Вы не поверите...

Вот ни за что не поверю, что офис написан на wpf, слишком быстро он работает. И да, я про 2010 и 2013.

В википедии тоже написано, что он на плюсах написан.

Если считаете, что на впф, киньте ссылочку плз.

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

а вижуал студию перевели на wpf исключительно как POC ну и в довесок новый продукт для работы с XAML Expression Blend написали на нем. сам я с это тулзовиной не работал, но вроде бы нареканий у людей на скорость работы нет.

Ну да, так поэтому их и пишут на плюсах

так пусть и дальше пишут :)

какие проблемы?

для десктопных приложений никто уже не будет делать новый язык. за ненадобностью.

Клиент евернота под винду сначала был написан на WPF

пользуюсь евернотом с версии 2.1, тогда это была вобщем-то другая программа. так что лично пережил и появление и 3ей версии, ее тормоза и переписывание ее с .NET на C++.

WPF, вообще не имеет отношения к "нативности". А к уровню использования средств GUI ОСи. Чем дальше от нее - тем будет тормозней интерфейс. Программисты на Java знают мелкие отличия как пользователи между SWT и Swing приложения - хотя ж Java же.

Не следил, но подозреваю что самое шустрое GUI приложения под винду как и раньше писать нужно на MFC. Которое в сравнении с WPF что асссемблер с бейсиком.

С историей еверноте же у меня еще вопросы остались:
1. Опытная команда плюсовиков могла просто не успеть перестроиться для разработки на managed languages, у них разная идеология проектирования, в части хранения данных в ОЗУ. А так как продукт новый, 3я версия, то имеем хрестоматийный пример плохого менеджмента, нарушение правила: НЕ пишите новую программу на новом, плохо освоенном инструменте

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 акселерацией для вывода обычного интерфейса.

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

И память уже опера отожрала в 2 раза больше и продолжает отжирать дальше.

дело хозяйское - мне тоже вначале показалось что ух здорово. :)
ну а о смазанности шрифтов - как понимаю CPU точнее рассчитывает сглаживание чем GPU.

Это ж как рендерить видео - CPU медленно но качественно, включишь CUDA - результат будет быстр, но годится только для документальных фильмов без яркого видеоряда.

ну я как-то в ie9 и 10 не заметил смазанности шрифтов.
ну и вот я пытался нагуглить что-то насчет худшего рендера картинки с помощью гпу, но как-то ничего такого не нашел.

Это точно проверенный факт или всё-таки ваши догадки?

ну я как-то в ie9 и 10

не пользуюсь. но замечал что они как-то по другому выглядят чем в остальной винде и ПО под нее :)

Это точно проверенный факт или всё-таки ваши догадки?

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

и Intel Quick Sync - много качественней дает чем CUDA и Ati Stream

вообще, вы уже второй раз просите "цитировать доку". надо видать оставить вас в покое:

я все всегда выдумываю, не читайте впредь мои посты ни в коем разе ;)

я думал, что мы говорим о рендере картинки, а не кодировании видео.

вы же понимаете, что это совершенно разные операции?

я не помню чтобы говорил о рендеринге картинки

а вот о выводе контролов офисного GUI - да, говорил. растровую картинку из контролов - еще нужно получить. Кто ее формирует и как - в том и вопрос. И как DirectX - ее формирует - тоже вопрос для меня.

что оно какое-то не то - в указанном вами ПО - IE9 - заметил.

Но вот шрифты стали смазанными - сказано не мной, о другом продукте с включенным GUI рендерингом.

давайте еще названия программ, чтобы было о чем говорить.

P.S.
Кажется сам вспомнил:
Adobe InDesign, пользуюсь иногда.
У него внешний вид, надписи, линии тоже какие-то невиндовые, и почему-то нередко размытые. библиотека GUI явно своя, но может еще тот самый рендеринг с помощью GPU? В старом Page Maker - точно не было. И все было ок и без ентих фичей
и почему - Acrobat Reader - тормозит при масштабировании, а Foxit, STPU - нет?...

Вряд ли программисты в 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, щас поклацал, интерфейс летает, как и положено.

может внимания не обращали :)
в 2.* я не вижу как оно рисует.

в 3.* - вижу. Комп не слабый, и GPU вполне. и на ноуте - вижу.

Кстати, еще вспомнил.
инет-пейджеры Trillian и Miranda
первый давно что-то там типа генерил HTML и своей внутренней либкой его выводил.
Miranda - классически

Очень даже видно как первый пыхтит. Для Mirandы тоже есть плагин, кажется для отрисовки вызывает IE - получаем пыхтение Trillianа :)

На С++ написаны оба.

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

так что не, не в плюсах или С# дело, ИМХО

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

Вот это и расстраивает, мощность компов стремительно растет, а программы тупят так же.

Такое ощущение, что если скажем через 10 лет компы станут еще в 10 раз мощнее, то придумают еще туеву хучу оберток, фреймворков и абстракций и окошки с тремя кнопками и пятью текстбоксами будут так же тормозить )

меня это не расстраивает.

может потому что в начале 90ых я такое уже слышал :)

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

а значит будут еще обёртистей обертки.

Кстати , что вспомнил. Есть такая прога под винду — лингво называется.
На чем оно написанно, на джаве ? Логика подсказывает что на крестах.

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

Мне чегото кажется что фриз на менюшке не из за джита, или большого количества слое\объектов. А из за того, что они ёё инициализируют лейзи, чтобы таки ускорить начальную загрузку и так не легкого приложения.

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

Отлично фризятся менюшки в Thunedbird'е. Первые несколько раз.

А в IDE таких проверок еще больше - пройтись по внутреннему представлению проекта, найти классы, переменные, методы, которые, ... сверить найденное... запросить окна редактора кода...

Джавошарпы сгниют вместе с остатками балмерсофта, и только РНР будет гордо возвышаться над горами постапокалиптического ИТ-шного пепла!

Не мечты, а вера в светлое будущее, когда программисты освободятся от ярма строгой типизации и чистого неймспейса!

... и от необходимости трезво, связно и чётко излагать мысли.

Джавошарпы сгниют вместе с остатками балмерсофта, и только РНР будет гордо возвышаться над горами постапокалиптического ИТ-шного пепла!

навоза, а не пэпла

Вполне может быть. Не тонет сами знаете что.

Какое 15 лет. Нам месяц осталось =) до 21.12.2012 )

Останутся. В роли Кобола нового времени. Думаю им на смену придут Scala, F# и им подобные.

а почему вы так думаете?

я думаю что как раз указанные ЯП не будут сменой ни Java ни C#
Scala — уже слишком сложная, аргумент «а можно писать просто на ней, как на улучшенной джаве» опровергается — и на С++ можно было писать как на улучшенном С. Только как-то не сложилось — пишут все же на как на С++, а не на улучшенном С.

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 применяемый к коллекциям, вместо таблиц.

Но на ЯП нужно описывать не только получение и агрегацию данных, а и сложные алгоритмы их — взаимодействия, взаимовлияния. (уже на уровне даже хранения — физическая целостность еще не гарантирует — логической целостности).
И сами данные — просто обрабатывать когда они «чистые», «мертвые». Без своего — поведения. Собственно поведение — и есть алгоритмы. А сложность появляется быстро: куда ни помещай поведение: неразрывно с данными, в виде rich объекта, или выноси поведение в сервисы, обработчики — нам это поведение все равно нужно описывать = записать на ЯП.

И когда мы начинаем моделировать поведения — быстро приходим к такой концепции как «состояние» и правила их, состояний смены, а в чистых ФП, или декларативном подходе — описание такой концепции весьма затруднительно, утомительно.

а в чистых ФП, или декларативном подходе — описание такой концепции весьма затруднительно, утомительно.

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

Но я к тому и веду, чтол будущее за гибридными языками.

за гибридными да.

но не за Scala, и тем более не за F# - вот я к чему веду.

Ну и ладно. Java и C# тоже начинались с C++.

концептуально эти три языка не отличаются :)

а вот то что они проще С++ - думаю отрицать не будете?

и повторюсь — 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. А одновременно — ни к чему.

Фреймвёрк предлагает решение общих проблем. Всегда есть проблемы, которые выходят за сферу его возможностей.

разумеется, всегда есть такие проблемы.
но раз проблема не общая — то она — маргинальная или уникальная :)

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

То есть, если нет фреймвёрка для решения задачи — да, нужен бы ЯП повыразительней. А если есть фреймвёрк — то выразительный ЯП — не нужен.

Или еще так:
Haskell делает простые вещи сложными, а сложные вещи — простыми.

www.pcweek.ru/...g/idea/2764.php

а чем linq to sql не орм?

сейчас вот есть 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 преобразует их обратно в объекты, с которыми можно работать на собственном языке программирования.
msdn.microsoft.com/...y/bb386976.aspx

кто пишет эти «запросы LINQ»? вот такое например: foreach (var cust in rep.GetAll().WithNameLike("Google").OrderBy(x => x.Name)) { ... }

А используя orm фреймворк — программист избавлен от необходимости писать запросы (в жизни не все так красиво, ессно)

если же вы подразумевали под orm — object-relational mapping как процесс, то тогда да, и сугубо объектный код, без всяких LINQ который формирует запросы(из объектной модели в SQL) и парсит ответ в объекты предметной области — будет кодом выполняющим — orm.

ну по вашему и EF не орм совсем

просто читайте доки побольше, интересуйтесь концепциями, их историей и проблематикой, подходами, реализациями в других языках.
а то неинтересно на всякие «это ваши догадки?» копипастить ее, а сейчас еще и браться за объяснение разницы между Entity SQL и LINQ to SQL.

MSDN — по моему очень удобная вещь для повышения своего уровня.

вы несете какие-то глупости. Я вас и не прошу объяснять разницу между linq to sql и ef.
я прошу чтобы вы не несли всякие глупости.

или хотя бы приведите критерии по которым фреймворк для работы с базой можно считать ORMом и по каким критериям linq to sql не проходит

вы несете какие-то глупости.

увы мне, увы, стыд и позор «ниасилятор детект» :D

я прошу чтобы вы не несли всякие глупости ... по каким критериям linq to sql не проходит

это да, ваша правда, я периодически забываю что рунет — неудачное место для разговоров о программировании.

спасибо что напомнили.

отлично съехали.
я написал, что Linq to SQL является ORMом потому, что умеет мапить реляционную модель MS SQL в объектную модель .net языков.

вы написали что он таковым не является потому, что он умеет работать с 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 то прикрыли, если вы не в курсе (хотя использовать можно).

ну я вообще-то не о EF спрашивал, а о F#
да и ЕФ в общем-то не является де факто стандартом. проектов на nHibernate не меньше.

А вот на F# где проекты? ну хотя бы какое-то минимальное использование языка в коммерческих проектах?

НХибернейт левое, а Энтити родное. Честно — не знаю проектов на Ф#, хотя читал гиганское кол-во статей, вплоть до Ф# для Юнити. Я собственно доказываю, что в случае Мелкософта отдача в опенсорс не есть признак того, что от язвка отказались. Опенсор частая практика в Мелкософт Ресёрч.

какая разница левое или родное?

Scala — уже слишком сложная
ниасилятор детектед
Только как-то не сложилось — пишут все же на как на С++, а не на улучшенном С.
ниасилятор детектед 2
настраиваешь presubmit check условие что бы код проходил linter, и радуешься жизни.

ниасилятор детектед

почему ж сразу неосилятор :D

сложный язык — остается сложным даже если осилить.
Вот есть такой Ыфкуил и с пару сотен человек на нем говорят.

На сам его автор говорит — да, язык сложный.

ниасилятор детектед 2

аха, и про С++ - сколько профессионалов есть, но они его простым не считают :)

сложность ЯП к ниасиляторству не имеет отношения.

Это вполне объективный критерий.


Похоже, что чем больше мощности и выразительности добавляется в язык программирования, тем более сложным он становится. Чем более сложным становится язык, тем труднее программистам понимать, читать и поддерживать его. И чем более сложный язык, тем более вероятно, что он будет сведен к его подмножеству, что уменьшит переносимость его между программистами. Один программист может знать одно подмножество языка и другой — другое. Хорошим примером этого видимо является С++.
metaclass.livejournal.com/412514.html

На сам его автор говорит — да, язык сложный.

пруфлинк в студию

аха, и про С++ - сколько профессионалов есть, но они его простым не считают :)

ниасилятор детектед 3

Я не говорил что с простой, я говорил что можно настроить линтер который отсекает сложные конструкции и программировать на нем как на простом языке.

пруфлинк в студию

погуглите сами :)

Я не говорил что с простой, я говорил что можно настроить линтер который отсекает сложные конструкции и программировать на нем как на простом языке.

а я уже на это сказал ранее:
и на С++ можно было писать как на улучшенном С. Только как-то не сложилось — пишут все же на как на С++, а не на улучшенном С.

читайте внимательней, прежде чем браться троллить ;)

погуглите сами :)

слив в лучших традициях доу

а я уже на это сказал ранее:

и на С++ можно было писать как на улучшенном С. Только как-то не сложилось — пишут все же на как на С++, а не на улучшенном С.

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

Ты просто за всех расписался

всех не знаю.

знаю многоопытных программистов на С++
знаю мнения что Степанова, автора STL, что иных, типа вот zouev.blogspot.com/.../blog-post.html
и только у троллей все объясняется ниасиляторством.

на то они и тролли.

слив в лучших традициях доу

это потому что вам ник сменить нужно.

я давно вас, как конченного тролля игнорирую, просто тема интересная, вот и ответил :)

Базовые же, объективные сложности ЯП складываются из:
1. количества синтаксических конструкций, правил их построения
2. количества семантических «оборотов», вариантов

3. сложности, двусмысленности чтения как попытке избавиться от первых двух сложностей (Lisp — прост по синтаксису, в итоге в коде никаких подсказок к пониманию семантики. в Haskell — вообще концептуально поставлен вопрос — как добиться истинности семантики только с помощью истинности синтаксиса).

знаю многоопытных программистов на С++
знаю мнения что Степанова, автора STL, что иных, типа вот zouev.blogspot.com/.../blog-post.html
и только у троллей все объясняется ниасиляторством.

на то они и тролли.

Ближе к телу, ты уверен что в хплабс или где там Степанов работал(ет) нету ограничения на фичи с++, которые энфорсятся автоматическими тулами?

это потому что вам ник сменить нужно.

я давно вас, как конченного тролля игнорирую, просто тема интересная, вот и ответил :)

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

любой может взять, и сравнивать количество информации в моих постах и твоих.

и кто применяет ad hominem

любой может взять, и сравнивать количество информации в моих постах и твоих.

Ну да, у тебя информационный понос, куча какой то ерунды пальцы настукивать не болят, зато от ответа по сути(пруфлинк что одерски называет скалу сложной) как то не видно, что впрочем не удивительно

maxplanet.ru/yfkuil.htm

www.computerra.ru/xterra/34923

и из вики:
Создатель ифкуиля, американский лингвист Джон Кихада, описывает язык так:

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

Ну так твой пример ни в красную армию, скала по количеству элементов и конструкций компактнее с++, с# и джавы

всегда приветствую самокритику

Scala не очень сложная, до хаскелля не дотягивает по сложности.

аргумент «а можно писать просто на ней, как на улучшенной джаве» опровергается
Пруфы ?
F# - это вообще-то OCaml для .NET.
Мертворожденный язык
Какие причины для замены C# на F#?
Никаких. Что то, что то есть ересь

Пруфы ?

их очень много, поэтому не копил.

уже есть и от самих лучших программистов на Scala. — они НЕ пишут на ней как на улучшенной Java.

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

Scala — очень выразительный язык, и странно предполагать, что программист которому понравилась ее выразительность — остановится просто на «улучшенной Java» по собственной воле. Хотя не исключено конечно, если программист — опытный инженер... то сможет, правда тогда ему и ЯП особо не важен :)

А еще скалка не перегружена всякими редкоиспользуемыми штуками вроде монадных трансформеров.

. Думаю им на смену придут Scala, F# и им подобные.

Только за! Заодно отсеит из наших рядов быдлокодеров которые не ©могут освоить новую парадигму.

Ты что, не видел обезьянок, которые кодят на Java и C# в процедурном стиле? Быдлокодинг непобедим!

Таких в нормальных командах на мороз выкидывают. По крайней мере в крупнейших бодишопах.

Я не к тому. Будет мультипарадигменный язык — будут продолжать говнокодить. Быдлокодеры никуда не отсеются.

быдлокодеры исчезнут когда исчезнет в них потребность.

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

либо — коробочные продукты охватят те сферы, где сейчас пишут собственное ПО.

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

в свое время я встречал исследования и диаграммы, насколько, и с какого уровня сложности проекта разработка на С++ дает ощутимый эффект в сравнении с Си

ни по Scala ни по F#, или их родственникам такого не встречал.

А в чем проблема набыдлокодить на скале?
Когда вам этот код потом разгребать прийдется, вы будете вспоминать джаву как сладкий сон :-)

Я на досуге пилю новый язык, он убьет обоих, и за одно серьезно уменьшит потребность в программистах. Трепещите 23-ех летние синьёры!

лютую смесь лиспа с forth я надеюсь? на меньшее я не согласен

А в чем крутось forth кроме того что там нужно писат все наоборот?

А в чем крутось forth кроме того что там нужно писат все наоборот?

власне в тому, що і Ліспа: написати таку сяку реалізацію, що не тільки повна по тюрінгу, але і вміє зробити щось більш-менш толкове можна буквально за пару вечорів (звісно, я не кажи про повну реалізацію стандартів і специфікацій, я кажу про «свою версію мови програмування» аля Форт чи Лісп :)))

Тооже самое относится и к бейсику, и еще к 100500 недоязыков.

Я теж колись так думав, але в Бейсику ніколи не вийде зробити таких метапрограмувальних трюків як в Ліспі, коли Лісп — сам собі синтаксичне дерево.
Тут рекомендую почитати Грехема, якщо мажте час:

www.paulgraham.com/...isphistory.html

ні в якому разі не пропагую Лісп як порятунок від всіх проблем програмування — але з пізнавальною метою дуже цікава штука.

При чем тут лисп если обсуждается форт?

Соррі, випав із контексту.
Конкретно по Forth — то є «зразково показова» стекова машина. Все стає на свої місця, якщо дивитися на Forth не як на «екзотичну мову, що вирішує всі проблеми», а як на високорівневий (дуже високорівневий) асемблер для стекової машини, але і одночасно досить низькорівневий, щоб створити для нього мікропроцесор

www.enet.ru/...rezov/forthcpu

знову ні в якому разі не пропагую 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 приложения надо переписывать. Возникает вопрос: а окупится ли? Или может лучше сразу переписать под линукс, андроид или ось?

зачем переписывать приложения под windows 8?

Он про метро-интерфейс. Там надо переписывать морду. А если там по заветам смартУИ, то и всё остальное. Десктопные приложение переписывать не надо.

ну а зачем старым приложениям метро интерфейс?

Не знаю, спросите Бивера.

Метро — интерфейс это не просто «морда». Это фактически другой менеджер приложений в винде.
В нем приложения гораздо больше интегрированы с системой и между собой. Система запускает их в «песочнице» и приложение должно четко описывать в манифесте куда оно хочет получить доступ (файлы на диске, внешние сервисы, реестр, геопозиционирование и т.д.). После этого система спросит у юзера разрешения и только тогда запустит приложение. Если программа попытается сделать «шаг в сторону» от манифеста — сразу ошибка.
Так же система может «уложить спать» приложение или вообще выгрузить на диск (типа хибернейта). Система вызывает приложение когда юзер что-нибудь ищет в системе даже если оно сейчас не запущено. То же касается и других «чарм» иконок (шаринг и что там еще есть не помню). Что бы уметь на все это правильно реагировать приложение должно реализовать специальные интрефейсы и правильно обрабатывать команды от системы.
Если кто помнить COM, то METRO приложение в этом плане больше похоже на ActiveX компонент (который зависит от контейнера), чем на отдельную программу (которая делает «что захочет»).

Думаю есть еще 100500 отличий. Так что просто мигрировать существующее приложение на METRO думаю будет равнозначно его переписыванию.

ну так вас же никто не заставляет переводить свое приложение с десктопа в метро.

Теоретически — да. Так же как программы под ДОС с интерфейсом на турбовижине еще долго успешно работали на 95, 98 и даже 2000 винде. А может и сейчас работают где-то в бухгалтерии или складе.
Разница между метро и не-метро примерно такая же как между оконным приложением и ДОС программой в окошке.

Существующие приложения сразу переписывать никто не кинется. А вот новые приложения или новые версии старых уже придется делать с оглядкой на метро. Даже если не ради интерфейса, то ради «живой» иконки, участия в поиске и интеграции с другими приложениями (тем же мылом или файловой системой).

Если функционал вынести в библиотеки — не будет. Но не важно, ибо

ну а зачем старым приложениям метро интерфейс?

Вы себе Метро — 3DsMax представляете?

Сейчас мода на супер-навороченные приложения вроде Ворда проходит. Много ли юзеров будет читать книжку 200 страниц про 100500 менюшек?
На планшетах рулит простой интерфейс. Например «Пацанский фотошоп» с 3 большими кнопками «Убрать прыщи», «Добавить тачку», «Дорисовать телок».
zadolba.li/story/7289

Да 3DsMax и Visual Studio МЕТРО интерфейс не нужен — ну так они совсем не массовые приложения.

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

The Unofficial Windows 8 Developer FAQ
www.riagenic.com/archives/960
Кратко говоря: все старые приложения (WinForm, WPF) будут выглядеть и работать как в семерке (переключаться на десктоп).

А что бы сделать приложение с METRO интерфейсом, поддержкой жестов, поиска, «живых» «плиточек», «засыпания» и т.д. его нужно почти полностью переписать на других классах .Net (другой тип проекта в VS, если так понятнее).


... в статье «Microsoft has failed». анализирует деловую тактику Микрософт за последние десять лет и показывает, как нескончаемая череда стратегических просчетов привела некогда замечательную компанию к полной утрате даже не контроля за рынком.
...
но за 25 лет доминирования Microsoft насоздавала такое множество замечательных вещей и продуктов, что было бы странно, если бы всё это богатство в одночасье кануло в небытие.
...
Сама Microsoft прекрасно понимает, что творится за окнами ее прекрасного лесного кампуса в Редмонде ... и пытается как-то разрулить ситуацию: покупает Nokia, запускает Metro, удивляет мир Surface. Проблема только в том, что ни во что дельное разруливание это не выливается. Почему? Прочитайте статью Чарли Демерджана и сами узнаете.

www.computerra.ru/sgolub/724213

Вот это и пугает. Майкрософт не исчезнет за один день, как и все приложения под винды. Но вот «выйти из моды» у юзеров майкрософт вполне может очень быстро.
Айпады уже отобрали у винды интернет-серфинг и социальные сети (и задвинули IE). Следующим шагом начнут делать 3D игрухи под другие операционки. Зачем тогда юзеру покупать винду?

А это значит что никто не захочет вкладываться в новые приложения под винды и виндовым девелоперам останется только сапорт старых приложений.

3д игрухи отлично делают под консоли уже давно, но пользователи почему-то по-прежнему покупают винду.

и как ни странно лидер рынка видеокарт для пк — это интел.

меня не пугает.

думаю что и производителей 3D игр — тоже.

а вот кто должен пугаться — так это завязавший свое ИТ на стек технологий от MS.

Кстати OYA — открытая, дешовая консоль на базе дроида. Имхо, подприбавит жару :-)

на консолях люди всё еще без проблем покупают A title баксов за 80.

вы думаете, что лидеры рынка будут писать что-то путное под эту консоль?

Сервера серверами, десктопы десктопами. Виста не взлетела, помните? Никто даже не чихнул.

Потому что тогда оставалась XP. А теперь у Windows 8 альтернативы нет — только она поддерживает тач-интерфейс и подходит для планшетов, мобил и новых ноутов (думаю тач будет везде).

С дектопами еще хуже: для них 8 винда хуже(!) чем 7. А это значит что идея новой «единой операционки» может провалиться просто потому что она не понравиться юзерам ни на планшетах ни на десктопах.

Для планшетов Win8 отлично подходит, но чем хуже для десктопов? Отсутсвием Пуска? Есть дофига способов его вернуть. Ещё есть способ сделать так, что Метро вообще появлятся не будет, даже при загрузке.

Потому что тогда оставалась XP.

А сейчас есть 7.

PS: Win8RT это не касается. Там эпик фейл.

Черес 15 років програмуватимуть нейроімпульсами з мозку. Але не всі. Організм деяких індивідуумів відторгне електроди і вони зійдуть з розуму :)

сумніваюсь.міняються не тільки «віндовси» але і ринок.на арену зараз виходять всеможливі андроїди і тд тп.доля мобільних пристроїв зростає з кожним днем.якщо майкрософт зможе втримати свої позиції на ринку то так,але я зараз бачу інше..

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

Через пятнадцать лет останется джава или останется C# в масcовом использовании?

ДА!

Они — локомотивы индустрии — думают о своих карманах, о долях на рынке, о том как отхватить свой кучок, а через 15 лет, нашим детям достанется весь этот обьектно-ориентированный хлам, что вы тут год назад двумя лагерями поочереди расхваливали.

Через 15 лет программирование будет совсем на другом уровне, а дедушки Джава и СиШарп сядут в последнем ряду рядом со скелетом Кобола. Но они будут... и Кобол еще будет... Аминь.

некропостер :)

В листинге видно, что при хранении структуры как object-а, делается боксинг объекта. При добавлении же в дженерик-список боксинга нет.

И?

Не уверен, что даже C будет вечно.

В листинге видно, что при хранении структуры как 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. Вывод.

Я не согласен со всеми тремя утверждениями — структуры могут лежать на куче без боксинга (например когда они являются филдами обьекта на куче), ну и дженерики сами по себе не вызывают анбоксинг, но он вполне может иметь место при их использовании, ну и как это относится к исходному вопросу вообще не понятно.

А сколько они должны занимать?

Сорри, забыл что структуры не поддерживают наследование

Совсем ничего не понял, вы говорите что обьект value type нельзя создать на куче?

Можно, но тогда это уже будет boxed value type => performance penalty.

Когда создают 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 бит, например.

crypto5

Да заквотил же специально:

это не такая уж и проблема, создание маленьких короткоживущих объектов очень дешевая операция.

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

Смешались в кучу кони люди, я вот выше спросил — вы уверены что в ц шарп в колекции структуры кладутся по значению? Можно ссылку? А то пока это на уровне фантазий, как бы не о чем разговаривать.

И что вы все уцепились за этот чар-инт

чар-инт — это просто пример кривой реализации. На практике он не так существенен.

При чем здесь вообще дженерики, если просто один тип приводится к другому

Вопрос в дизайне дженериков. В джаве основная их задача — ограничивать разработчика, а в Црешотке — я не понимаю зачем они надо, кроме как каких-то сказочных гуано-оптимизаций когда объект-коллекция подменяется массивом (если я правильно понял Ивана Мазепова)

Здесь по вашему тоже ошибка?

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

Речь о маленьких порциях данных изначально! Вам лишь бы поспорить?

У кого была речь о маленьких порциях изначально?

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

blockquote> 4) создается объект на куче => hence тормоза — в Java — это не такая уж и проблема, создание маленьких короткоживущих объектов очень дешевая операция.

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

Речь о маленьких порциях данных изначально! Вам лишь бы поспорить?

Обычно так и бывает. Поэтому большие объемы данных в структурах не хранят. А всякие точки-прямоугольники — в самый раз.

Ну «обычно» — достаточно спорный аргумент, кому нужен язык который «обычно» работает; -)? Ну и второй вопрос, если говорить о ц шарп, есть повод для уверенности, что там в листах хранят структуры именно по значению?


2Иван Мазепов
1) Речь шла не о скорости, а о целостности.

2) Не знаю как в новых версиях, но в старых версиях int соответствовал структуре Int32, со всеми вытекающими. (тут я могу ошибаться)

Поэтому по поводу
1. Все вопросы к MS. Это все равно, что говорить «почему кейворд называется int, а не integer, как я привык». Ну приводятся чары в инт и наоборот с их точки зрения и все тут.

2. И _что_ отсюда вытекает? Боюсь представить.

А с структурами все не так просто, так как присваивание структуры может больше времени занимать чем присваивание указателя на обьект.

Обычно так и бывает. Поэтому большие объемы данных в структурах не хранят. А всякие точки-прямоугольники — в самый раз.

silverwolf
Целостность данных — это из другой оперы. Когда данные частично отсутствуют или наоборот — есть излишек и они противоречивы.
И что вы все уцепились за этот чар-инт. При чем здесь вообще дженерики, если просто один тип приводится к другому. Это можно проверить и при обычном присваивании.

Здесь по вашему тоже ошибка?


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-тый?

2Иван Мазепов
1) Речь шла не о скорости, а о целостности.
2) Не знаю как в новых версиях, но в старых версиях int соответствовал структуре Int32, со всеми вытекающими. (тут я могу ошибаться)
3) В реальной жизни (по крайней мере в моей реальности) применение примитивов в коллекциях крайне ограничено, а если вам уж понадобился список int, а не Integer — то скорее всего вызовы методов и тот оверхед который дает сама коллекция не допустимы (вспоминаем что такое массивы или чего веселее вспоминаем ЦПП/Ц/Асм;))

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

Ключевое слово int обозначает целочисленный тип, в котором хранятся значения, размер и диапазон которых приведены в следующей таблице.

msdn.microsoft.com/...ibrary/5kzh1b5w (v=VS.90).aspx
В коллекцию целых чисел кладем символ Юникод — так будет вернее. Давайте еще булевский тип приводить к целочисленному — шоб савсем Ц получилсо.

Аноним, почитайте таки хоть пару глав в книге по джава, что бы понять в чем разница между подходом в Java и.Net.

Не помню как академически звучит, но есть «расширяющееся», есть «сужающееся»

Covariant and contravariant. http://en.wikipedia.org/wiki/Covariance_and_contravariance_ (computer_science)

С таким же успехом можно забить на дженерики и пользоваться коллекциями Object’ов.

В Java не существует boxing и unboxing?

с каких пор char это буква? char — это код, причем числовой... Кто-то из нас идиот, невже це я?! =)

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

Логическая. char — это буковка, int — это число. Вы в коллекцию чисел кладете буковку, она приводится к числу и достаете вы число, нарушается целостность.
С таким же успехом можно забить на дженерики и пользоваться коллекциями Object’ов.
В ЦПП — шаблоны это способ обобщить конструкцию,

дженерики (в джаве) — это способ увеличения надежности, конкретизации.

ИМХО в данном случае Java перестраховывается. Это как при переходе моста C#-программисты его просто перебегают, Java заставляет одевать спасательные жилеты на входе.

В списке байтов нельзя хранить инт, не сделав явное приведение.

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

Класс-оболочка Integer нужен для передачи int по ссылке

Интеджер — не мутабельный в джаве, поэтому передавать его по ссылке особого смысла нету, все равно внутри не изменишь.

Неявное приведение типа это не ошибка и если спецификация языка определяет, что char приводится к int-у, то это не ошибка.

Достаточно очевидно, что язык стал бы более устойчивым к ошибкам, если бы такое привидение запретить, а требовать явное преобразование типов.

Класс-оболочка Integer нужен для передачи int по ссылке, а также, вместе с другими подобными классами, для реализации динамической типизации.

Я прошу объяснить в 2 словах по простому почему в Java 2 инта

В Java 1 int (архаизм из ранних версий, имхо) и класс-оболочка для него.

Так, разбор дальше. Я поверил, что будет ошибка (и удивился, неужели компилятор не бросит ошибку несоответствия типа, а в рантайме свалит ошибку), а оказывается «ошибка» — она только семантическая с точки зрения silverwolf.

А код

int d = new char();
List<int> t = new List<int>();
t.Add('a');

прекрасно выполняется. Может быть вы хотели бы, чтобы и

t.Add((byte) 5);

валил ошибку? Неявное приведение типа это не ошибка и если спецификация языка определяет, что char приводится к int-у, то это не ошибка.

Я прошу объяснить в 2 словах по простому почему в Java 2 инта. Я не хочу изучать по ней документацию, писать на ней я не буду.

Если не хотите, ваше право.

Тогда может быть вы понимаете и почему и зачем в Java cуществует 2 типа инта, а то я не догоняю.

Я понимаю. А судя по «cуществует 2 типа инта» вы не понимаете в принципе что происходит, возьмите почитайте (организация и система типов в Java и в.Net отличается).

Так я думал вы приводите листинг на Java.

Тогда может быть вы понимаете и почему и зачем в Java cуществует 2 типа инта, а то я не догоняю.

Вы пишете good и что это разрешено

Код компилируются. И позволяет сделать ошибку.
Компилятор говорит good, а должен был сказать НЕ ГУД, ибо нарушается целостность.

Почитайте про дженерики.

Вы пишете good и что это разрешено, но «дженерики в Java такого не позволяют».

А почему вы не пишете, что Java — синтаксический наследник C++?

«Синтаксический наследник» и «синтаксис подогнанный под модные на данный момент фишечки» — это разные вещи. Java создавалась что бы «пофиксить баги в C++», и в некотором плане у них это получилось, в некотором нет. Но это тема другого холивара.

Что позволяют дженерики Java и не позволяет C#?

Не правильный вопрос. Правильный вопрос:
Чего они не позволяют делать?
Дженерики в Java — это средство контроля (я уже писал об этом повторятся не буду).

Если вкратце:

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 года)

Словосочетание «помесь Java и C++» вообще странно звучит. От C++ там только фигурные скобки. Указатели-разыменовывание есть? Выделение памяти легко и просто есть? Или буква «С» тоже в названии смущает?
Лямбды — никто не говорит, что это изобретение C#, но они добавляют удобства, для тех кто понимает как их использовать.

Встречал мнение, что дженерики C# — кастрированные темплейты C++ (не знаю так глубоко С++, поэтому не могу судить, но что-то мне кажется вы тоже не в теме).

C# — это замена VB.

lol. C# — замена VB.NET. А VB.NET — VB6. А VB6 — QBasic. Ну да, совсем похожи.

Сборка мусора появилась первой не в Джаве.

Никто этого и не утверждает, но факт: первые версии C# — были помесью Java и C++.

Лямбды — тоже.

Да, «лямбды» — это гениальное изобретение C#? Надобности в них особой никогда не было (в императивных языках) и добавлены они «потому что это круто» (модными стали Python’ы и Ruby)

От C++ что, ДллИмпорт? Unsafe код?

По большей части дженерики, которые являются смесью подходов Java и большей частью C++.

VB — даже комментировать не буду.

Да тут и не чего комментировать. C# — это замена VB. Поэтому стиль кодирования (внешние признаки) очень сходны.
Я не утверждаю, что какой-то конкретный кусок взят из какого-то конкретного языка, ,

но когда смотришь на C# — первое ощущение «это уже было в языке...»

Вдобавок не могу еще ничего сказать по C# 4.0 (пока не читал нового Рихтера), но по краткому обзору изменений я подобного не видел в других языках так точно

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

Бред.
Сборка мусора появилась первой не в Джаве.
Лямбды — тоже.
От C++ что, ДллИмпорт? Unsafe код? Слишком сильно сказано.

VB — даже комментировать не буду.

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

Это как в известном анекдоте: «слизать слизали, а пользоваться не научились»

Проблема С# — в том что в него суют ВСЕ, немного от Java, немного от C++, немного от VB, немного от Python, немного от SQL, немного от еще чего-то. Язык создан не с целью решать какие-то задачи или реализовать какую-то парадигму, а с целью переманить как можно больше людей. Поэтому на начальных этапах все классно, а когда проект разрастается и оказывается, что «каждому пользователю невыгодно давать новый сервер».

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

По-моему очевидное преимущество явы проявляется сразу на страте проэкта. Допустим нужно пять разрабов — во сколько обойдется такой старт на дот нете, если, скажем, пишется нечто похожее на ebay?

C/C++ точно никогда не исчезнет, как как high level assembler. Любая системная вещь на C#/Java хоть и возможна теоретически, но реализуется всегда через ass.

а
Що ти в православний храм ООП / ООД лізеш із своїм псалтирем системної єрєсі?

Дивись щоб жреці бізнес логіки наклали на тебе анафему і вічне прокляття синглетона.

КОНТЕСТ 1 дн. назад

Само предположение того, что Java или C# останется в массовом использовании через 15 лет есть идеотизм. ООП как концепт существует уже 50 лет и если раньше это была новая и революционная технология, то сейчес это просто ущербное средство с множеством неуклюжих дополнений, в виде фреймворков и прочей лабуды.

Я чомусь був подумав, що пустий холівар С# Java Білої і Червоної Троянди цьому закінчиться.
Копіпаст — форева.

Амінь


дядя 3 дн. назад

Через 15 лет Oracle купит все компании мира, разработает языка jPL\SQL# и все будут програмировать на этом прекрасном языке. А про java и C# можно будет узнать только из книг десятилетней давности или устроившись на работу в гос учереждение.

C/C++ точно никогда не исчезнет, как как high level assembler. Любая системная вещь на C#/Java хоть и возможна теоретически, но реализуется всегда через ass.

1% юниха влияет на рынок десктопа

Нет, просто рынок десктопа менее 1% рынка мобильных устройств

вы действительно думаете, что 1% юниха влияет на рынок десктопа?

Moonlight и MonoTouch — это выход на рынок айТелехвончиков и тд.

Вообще, единственный интерес в Mono у Microsoft заключается в Moonlight, т.к. для успеха технологии им нужна поддержка на клиентах

вы действительно думаете, что 1% юниха влияет на рынок десктопа?

ПыСы. сам линуксоид, если что

Oracle купил джаву это плохо? оракл же написан на джаве?

Честное слово — КОНТЕСТ — єто не я

Само предположение того, что Java или C# останется в массовом использовании через 15 лет есть идеотизм. ООП как концепт существует уже 50 лет и если раньше это была новая и революционная технология, то сейчес это просто ущербное средство с множеством неуклюжих дополнений, в виде фреймворков и прочей лабуды.

Oracle купил джаву это плохо? оракл же написан на джаве?

@silverwolf да WS «модный» клас лоадер многим попортил нервы:)

Ну и какие специальные знания сейчас требует C#? SQL и так все учили в универе, лямбды похожи на кванторную запись, которой пользуются математике (типа «все х, такие что...»). В отличие от F#, тут мозги на изнанку выворачивать не нужно.

Отличия джава от с шарп далеко не только в linq.


т.е. все что пишут мелкомягкие то по определению кошерно и годно, а то что другие крап и в пищу не годиться?

Не слишком ли однобоко это выглядет?

Никто здесь не обобщал, но то что качество моно реализации библиотек ниже оригинала, и содержит несовместимости с оригиналом вроде не вызывает сомнений.

Через 15 лет Oracle купит все компании мира, разработает языка jPL\SQL# и все будут програмировать на этом прекрасном языке. А про java и C# можно будет узнать только из книг десятилетней давности или устроившись на работу в гос учереждение.

переносимость между веб контейнерами не совсем простая временами.

То что специфицировано все выполняется, насколько я знаю. То что вы использовали какое-то поведение конкретного контейнера — это ваши проблемы (у меня были такие проблемы при переносе с Tomcat на WebSphere). Про МС и стандарты я уже говорил:)
Кроме того контейнер не является частью Java, это по факту сторонняя либа (немного утрировано).

На данный момент все Java-машины должны пройти сертификацию у Сан Оракл. Кстати, для меня оказалось откровением что у IBM таки своя JVM.

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

но все решаемо правда

Очевидно что реализация библиотек в моне «неофициальная».

И реализована через GTK, соответственно требует рантайм.

Моно соответствует официальному стандарту ECMA для СиШарпа и СиЭлЭра.

1) Все мы знаем как МС следует стандартам, кстати, насколько я помню, и в контексте C#.

2) В том смысле, что МС (именно МС — как вендор) не гарантируют, что программа написанная под Mono компилируются под.Net и что самое главное наоборот (это проверено). Про перенос бинарников я уже говорил.

С++ реализаций вообще тьма тьмущая, и ничего

Это была одна из причин, почему «энтерпрайз» не любит C/C++

> Очевидно что реализация библиотек в моне «неофициальная».
т.е. все что пишут мелкомягкие то по определению кошерно и годно, а то что другие крап и в пищу не годиться?

Не слишком ли однобоко это выглядет?

Очевидно что реализация библиотек в моне «неофициальная».

В каком смысле не является «официальной версией.Net»?
Моно соответствует официальному стандарту ECMA для СиШарпа и СиЭлЭра.
Или этого не достаточно? А что тогда, по вашему входит в понятие «официально»?
С++ реализаций вообще тьма тьмущая, и ничего. И стандарту соответствуют далеко даже не половина)

Так что ненужно рубить с горячя не разобравшись в предмете

подскажите мне аналог сервера апликаций типа WebSphere со всеми его вкусностями в.net

Как-то мне рассказывали, что в WebSphere можно использовать.Net, я не проверял.

> Однако, на клиентские места Джава тоже идёт, в связке с Линуксом

Mono

Прошу прощения. БЛЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯ, ЗАИПАЛИИИИИИИИИИИИИИИИИ!!!

Mono — это придлуда, которая не является официальной версией.Net. Не поддерживает (по крайней мере раньше не поддерживала) всех возможностей последних версий (совместима вроде в 2.0 или 3.0), не имеет бинарной совместимости, имеет свой набор либ и самое интересное имеет реализацию под винду.

> Однако, на клиентские места Джава тоже идёт, в связке с Линуксом

Mono

> Но если ориентироваться на кобол (langpop.com/ — то в десятки раз меньше спецов

Однако, на клиентские места Джава тоже идёт, в связке с Линуксом. Скажем, государственые органы цивилизованных стран переходят именно на бесплатные решения (а это, как правило, Линукс с клиентом на джава), в целях сбережения средств налогоплательщиков. > это десятки тысяч, если не сотни тысяч клиентских мест в каждой стране. Правда, к бытовым клиентам пробиться будет сложнее — там винда пока рулит, без вопросов.


Java идет курсом на замену кобола
О чем и я. Фиг она умрет и в 15 и в 30 лет. И спецы будут нужны.

Но если ориентироваться на кобол (langpop.com/ — то в десятки раз меньше спецов. Хотя для твердых духом — оплата их труда может быть существенно выше средней. Но и работу искать надо будет не полдня, а полгода.

@WIgor
ну кроме WS есть и другие решения — конечно не настолько страшные.
по моему просто у них пока эко ниши ПОКА слабо пересекаются. Где сильны одни — другие слабо представлены,

а Java идет курсом на замену кобола (я как бы не скажу что сильно рад- уж сильно я не люблю overengineering). и она с нами на долго- 100%.

а вот Terracotta ту же вы чем заменять будете?

Ну лично я, тут не скажу аналогов — нужно хорошо знать что могут системы, что бы аналоги найти. А я в java проектах с Terracotta не сталкивался, разве что с EhCache (для этого кстати аналог Velocity (не шаблонный движек, а вот это msdn.microsoft.com/...e695849.aspx))

у MS продуктов есть неизлечимая болезнь- они работают на OS от MS и только. И они платные.

Тут не поспоришь. Только WebSphere тоже не бесплатная ведь.

@WIgor к стати наблюдаю тенденцию к отмиранию.net проектов в нашей компании. Клиенты поигрались и наелись. Для переучивания.net програмистов у нас даже делали специальные курсы. В итоге.net остался только в проектах поддержки. новые проекты- J2EE только. Конечно это наш финансовый загончик -, но уж очень наглядно.

@WIgor да ну:) ,
а вот Terracotta ту же вы чем заменять будете? А что бы оно еще и Open Source было? С этим в.net все вообще как в каменном веке.
у MS продуктов есть неизлечимая болезнь- они работают на OS от MS и только. И они платные. Прикинте разницу в цене на 10К серверов;) ,

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

Та ладно. В чем именно лучше? Не, я понимаю что если в компании корп стандарт Linux сервера — то пихать туда.Net практически бесполезно, но и наоборот точно также. Ну и естественно у Java было больше времени на проникновении в компании. Текущая ситуация видна по вакансиям — Java в 2 раза больше.Net требуется.
Если «лучше» в смысле более распостранена — то да. Но с точки зрения технологий не думаю что Java лучше.
В серверных системах платформы сопоставимы.
В клиентских приложениях ИМХО Java не конкурент.

Ну и то, что я выше говорил — «синтаксический сахар» в C# вкуснее.

Справедливости ради, при всей моей нежной любви к дотнету (и его не очень нежной, но регулярной ко мне) не могу не согласиться, что на сегодня для энтерпрайза все-же лучше ява, увы: (

Вот-бы их перемешать, и получить две нормальных...© Тарапунька и Штепсель, вроде...

@гыгы я MS разработкой не занимаюсь, сами пишите;)

То есть детали нас не интересуют -, но тем не менее, утверждаем, что нет аналогов «WebSphere со всеми вкусностями»?
Всему J2EE есть аналоги в MS\.Net.

А вот аналоги 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

2DmitriyK
«я MS разработкой не занимаюсь, сами пишите;) »

так так, знакомая песня: «Пастернака не читал, но осуждаю...»

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

2aga

самое ценное в этой статье — комменты, реально доставляют =)

@WIgor
уели- прощелкал я появление MSMQ и ESB toolkit в BizTalk, мало слежу за MS линейкой:) ,

но опять же — продукты от MS... a альтернативы? Java инфраструктура хороша обилием альтернатив (правда иногда это жутко бесит — неудачный выбор набора технологий — и ваш проект в жопе)

@гыгы я MS разработкой не занимаюсь, сами пишите;)

@DmitriyK

подскажите мне аналог сервера апликаций типа WebSphere со всеми его вкусностями в.net.

Не могу придумать ничего незаменимого из WebSphere. Скажите что вы считаете вкусностями — я скажу аналоги.

Или там WS MQ? А как с ESB решениями?

MSMQ, BizTalk


Лондонская фондовая биржа (50 процентов международной торговли акциями) крутится на точкаНете, правда у них там куча проблем с этим софтом, но кто виноват платформа или разрабы я так и не понял...
проблемы уже устранили

blogs.computerworld.com/...ffers_net_crash

Лондонская фондовая биржа (50 процентов международной торговли акциями) крутится на точкаНете, правда у них там куча проблем с этим софтом, но кто виноват платформа или разрабы я так и не понял...

net- хороший инструмент для мелких проектов. С хорошими преспективами, идеями -, но пока катастрофически далекий от ентерпрайза в западном его понимании

это правда? ужас.

@WIgor, а она и занимает эту нишу. вытесняет Cobol которого просто чудовищное количество в критических приложениях на западе (stuffthathappens.com/...new-cobol.png) у нас практически нет систем такого уровня- вот многие и думают пописав учет складских ценностей на c# о том как он могуч. А если копнуть — нет его в больших приложениях...
подскажите мне аналог сервера апликаций типа WebSphere со всеми его вкусностями в.net. Или там WS MQ? А как с ESB решениями?
вообще.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 решений — см. ниже

А как с ESB решениями?

NServiceBus, MassTransit, Rhino Service Bus, ESB .NET,

Некоторые из них построены на базе MSMQ.

понекрофилю следом за вами
и что из этого опенсорсное или не дай бог бесплатное?
у нас например неслабое кластерное решение есть. Платного там Oracle и MSSQL (нормальная база ничего плохого сказать не могу)
а вообще там ниже по теме вроде все неплохо обсосали

а де хоч один комент від автора? (натурального троля)


Cobol в продакшенах в полный рост (и будет там еще лет 10, а то и 20), а MSюнгерт уже Java хоронит:)

спасибо развлекли

Если Java займет место Cobol — буду считать что мой прогноз сбылся.

И ладно MSюргентами обзываться:) Сейчас есть масса компаний и проектов где лучше Java и чуть меньше, но тоже большое количество мест где лучше.Net. Просто при прочих равных лично я за.Net — по причинам выше описанным.

@чук И классический С который хрен закопаеш

Cobol в продакшенах в полный рост (и будет там еще лет 10, а то и 20), а MSюнгерт уже Java хоронит:)

спасибо развлекли

через 15 лет ни Java, ни C# не будут массово использоваться.

+1

Wer redet heute noch von der Vernichtung der Armenier?

через 15 лет ни Java, ни C# не будут массово использоваться.
(а хули, все равно любая точка зрения — пальцем в небо)
хотя если гипотетически рассмотреть варианты, то:
1. будет какой-нибудь пикапец, и что-то принципиально новое

2. будет все супер, невообразимые сейчас компьютеры и языки под них (не сабж)

Что будет рулить Шарпей или Джава?

Шарпей конечно, типа кругом тя MS, а наверху # (решетка) -как в зиндане типа.

сквозь # виднеется небо в облаках и пахнет Джавой))

Оффтом жёсткий!

Что будет рулить Шарпей или Джава?

Да, изучение F# значительно повышает ваше ЧСВ.

А че хаскль уже не штырит?:)

Спецы по F#, чем он лучше OCaml, кроме того, что из него удобно вызывать new Form ().Show ()?

Функциональное программирование как-то слабо вяжется с 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# или питон, которые имеют поболее синт. сахара чем С#?

Да и по поводу F# — сравнивать его с C# нельзя — совершенно другой стиль программирования. Это не добавление «синтаксического сахара» в императивный C#, это функциональный язык с возможностью использовать императивный стиль. Этот язык мейнстримом врятли сможет стать ближайшие лет 5−10. А вот Scala для Java — тут перестройки мозга практически не требуется — идеология таже, кода меньше.

Правда что у F#, что у Scala есть детская болезнь — редакторы если и работают корректно, то не многим отличаються от notepad.

2 WIgor Ну вот, я так и думал

и то и другое сопоставимы

при создании таблицы,

2 denis.gz, извините не буду ставить на Джобса, вот уж кто маркетолог. На продукции Эппл не работают, её лелеют и милуются, и архитектора там то же нет

2 Андрей

всего лишь проверка скорости жесткого диска, если базасоздаётся на диске

Да, не уточнил — генерировалась html таблица. База данных в тесте отсутствовала как таковая.

Скорость-то по сути была одинаковая при любом случае Java или.Net — только при включеном ViewState было дольше — что вполне естественно так как размер веб-странички существенно больше. То есть на простейшей задаче из web разработки — и то и другое сопоставимы. И то, что говорили что hibernate быстрее nhibernate — ну может так и есть для этих двух отдельно взятых orm, а может быть при тестах забыли выключить\включить какую-то дефолтовую опцию у nhibernate (по аналогии с ViewState для ASP.NET)?

Что сложного в Linq и лямбдах?

Ничего плохого, как и в F#

ставки хотите сделать

Ну канешно, куда миллионы вкладывать, непонятно, особенно когда это решают маркетологи.

Чего то про МС кажется, что навороты в шарпе от отсутсвия архитекторов. Архитекторы свои фирмы понаделали их страшно нехватает у МС. Их всего то может человек 10 в мире, типа страустрапа или самого Билли в молодости.

Андерс Хейлсберг и Эрик Мейер уже ушли из MSFT? :-O

А что тут думать. C# это мейнстрим, язык общего назначения. Задуманный, чтобы сделать проще разработку под.NET (сравните с C++/CLI, бррр). Имеющий традиционную императивную парадигму. У него априори будет большая область применения и большая аудитория, чем у F# и прочих. Таковы стереотипы, если хотите.

Точно как и джава — язык общего назначения, и не нужно ее перегружать всякими элементами лямд (linq). Для таких вещей как я уже говорил есть groovy и scala. А С# с такими маркетинговыми порывами МС скоро станет сложнее С++.

2 silverwolf

А C# — еще и в планах не было:)

Ну писали уто то тут в другой ветке, что шарп написан по мотивам джавы, после того, как МСы получили штрафы за джаву в Винде, и им пришлось нашарпить.
Но вот куда что движется, чесно говоря не понял, особенно про маркетологов, что то народ невнятно излагает.
2 denis.gz

Ну объясните бестолковым, что же где же куда же. мейнстрим не оправдание, вон пхп мейнстрим, ну и что?

Джава вообще тогда только для апплетов годилась, когда нам ее читали (97 год).

А C# — еще и в планах не было:)

Указатели сборщик не удаляет, потомучто он их незнает

Есть переменная, есть на нее указатель.
Если сборщик собирает переменную, то указатель становится невалидным.

Если же запретить собирать переменную, то она может попасть в более старые поколения, как результат хуже очистка памяти (особенно если переменная содержит большой объект, то есть саму структуру, а не ссылку на нее). Кроме того программист должен не забить запретить собирать переменную — вот в этом и увеличении опасности.

2 silverwolf

Tomcat не знаю, а вот ASP.NET пишет точно, если считает нужным. Дело вот в чём, согласен, что

генерить контент для отдачи и писать его на диск — это смешно.

, только если база 10 Тера, а результат запроса 10 к, то пытаясь угадать запросы 99% народа ответы (html) yf частые запросы создаются уже при генерации базы сразу и кладутся на диск, что бы не загромождать память и не тратить время на них при запросах, если сам запрос длится скажем 30 сек (база 10 Тера), а чтение ответа с диска 12 мс, то наверно есть выигрыш, к томуже при перезапуске сервера если что всё готово.

2 silverwolf

Да я знаю, что там есть сборщик мусора в шарпе, но он вроде выключается, кокгда надо. Так Вы объясните, почему со сборщиком мусора указатели опасней? Указатели сборщик не удаляет, потомучто он их незнает

то опять же на диске, суда по времени создания, соответственно и кеш там же

Tomcat вроде стараетсо пользоваться памятью (я там не видел потоков которые не с памятью работаю, но я особо не копался), генерить контент для отдачи и писать его на диск — это смешно.

Странно, а пишут, что сборщик появился как раз потому, что нет указателей, объясните пожалуйста.

В.Net есть сборщик мусора, по крайней мере так говорили несколько лет назад.

2 silverwolf

Вообще то

Задача — генерация таблицы с пару тысяч строк

Ну если и Вы правы, т.е.

страница с табличкой (хтмл).

, то опять же на диске, суда по времени создания, соответственно и кеш там же

2 silverwolf

учитывая наличие сборщика мусора, указатели становятся еще более опасными чем в C

Странно, а пишут, что сборщик появился как раз потому, что нет указателей, объясните пожалуйста.

Ну, уже говорилось, что сборщик мусора и реалтайм несовместимы, извините, если что.

Давайте начнем с начала. В неуправляемых языках (C/C++) программист управляет выделением и освобождением памяти самостоятельно. В управляемых же (C#, Java) за него это делает виртуальная машина.

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

В C# (вернее, в .NET Framework Class Library) имеются средства проинструктировать сборщик мусора на тему «На вот этот объект имеется низкоуровневый указатель, его не трогай, пока я не скажу, что можно», а Silverwolf говорит о том, что новички об этих средствах могут быть не в курсе.

Кстати большее время IIS7 в основном объясняется записью на тот же диск более развитого индекса

Какие индексы у веб-сервера? Можно поподробнее, кэш в памяти, так контент вроде динамический.

всего лишь проверка скорости жесткого диска, если базасоздаётся на диске.

Так вроде же не база создавалась, а страница с табличкой (хтмл).

Ладно уговорили, джава — язык для былокодеров, C# — нет:)

А можно всю логическую цепочку? А то как то не прозрачный вывод.

в шарпе еще указатели есть и всякий там unsafe, давайте за это его поругаем:)

А вот ничего смешного. Поскольку учитывая наличие сборщика мусора, указатели становятся еще более опасными час в C.

Выбирая технологию, обычно никто не тратит несколько лет на попробовать то, попробовать это.

Тогда давайте не будем говорить о «не удобности языка». Кстати, обычно у вас есть 4−6−9 лет на то что бы «попробовать то, попробовать это» — универ называетсо.

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

Это уже ближе к теме. Много сокурсников говорили что выбрали C# потому что там «студия классная». И интересно получается те кто выбирал язык потому что студия классная или потому что однокомнатник пишет на языке А, получают не очень высокую ЗП, некоторые ищут работу (не на одном месте дольше 0, 5 года не задерживались). Такой подход говорит о человеке не с лучшей стороны.
Основной плюс.Net — низкий порог входа, порой ниже чем у PHP. Кстати, с Java такое было еще лет 5 назад.
2Антон Мартыненко

Что такое *.Parallels, можно ссылку где почитать?

Но на старте, C# был куда удобнее и продвинутей Java тех же лет, то же касается и библиотеки.

А конкретнее? Особенно про библиотеку?

Ладно уговорили, джава — язык для былокодеров, C# — нет:)

Вы кстати не задумывались почему МС ставит именно на С#, а не скажем на F# или питон, которые имеют поболее синт. сахара чем С#? И джава и С# это компромисы между простотой, предсказуемостью с одной стороны и фичами с другой, просто компромисы разные.

2 WIgor

Уважаемый, всегда считал, что такая

Задача — генерация таблицы с пару тысяч строк.

всего лишь проверка скорости жесткого диска, если базасоздаётся на диске.
Как же можно сделать выоводы о платформе, или я неправ?

Кстати большее время IIS7 в основном объясняется записью на тот же диск более развитого индекса, что в итоге ускорит исполнение запросов, хотя Вы и не просили его, он индекс (индексы?) делает по умолчанию

Та ладно, в дотнете давно есть MS Test, NUnit. Для dependecy injection применяется Unity и Spring.net

Я не говорил что их нет, я говорил что.нет аналоги в роли догоняющих.

2crypto5

например в unit testing, dependency injection.

Та ладно, в дотнете давно есть MS Test, NUnit. Для dependecy injection применяется Unity и Spring.net

Hibernate однозначно быстрее чем NHibernate, это проверено.

Интересно — надо проверить. Както проверял ради интереса Tomcat (JSP) vs Resin (JSP) vs ASP.NET vs ASP.NET MVC
Задача — генерация таблицы с пару тысяч строк.
Сервер\фреймворк\технология Avg. Page Time Req\sec Avg.Page Size
Tomcat 6.0.18\Servlet + JSP 0, 39 38, 8 135882
Caucho Resin 3.1.9\Servlet + JSP 0, 33 39, 5 135882
IIS7\ASP.NET Web Forms\Repeater 0, 76 28, 3 367824
IIS7\ASP.NET Web Forms\Repeater (Disabled ViewState) 0, 52 40 136259
IIS7\ASP.NET Web Forms\Table Server Control 0, 79 27, 3 360181
IIS7\ASP.NET Web Forms\Table (Disabled ViewState) 0, 52 39, 6 143300

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 нет.

А кто-то мерял количество? Я например аналоги библиотек могу найти практически всегда. А если вдруг в java 3−5 похожих библиотек, а в.Net одна — если она хорошая — какая разница?

а померять просто, посмотреть сколько соответствующих проэктов на codeplex, sf.net и google code.

Ну и многие.net аналоги отстатют от своих братьев джава — например в unit testing, dependency injection.

У Microsoft армия тоже хорошая — банкам бы вполне хватило.

Это так кажется, IBM очень сильно развила консалтинговый бизнес для большого бизнеса, МС тут проигрывает.

Пока не видел этих мейнфреймов ни в одной компании с которой работал. Можете привести пример компаний которые их используют? По крайней мере наш Enterprise — он в массе попроще (всякие HP сервера — в лучшем случае)

У большинства больших загран. банков (bank of america, citi) например операции по перекидыванию денег между эккаунтами происходит на мейнфреймах.

Ок — 10 лет преувеличение:) Java с 2000-го.Net c 2004-го. Кстати последнее время с Java — ибо бабло все таки победило «синтаксический сахар», пока:)
Другое дело, что я все таки считаю что этот «синтаксический сахар» всетаки будет продавливать.Net в корпорации все глубже. Так как программисты любят такой «сахар» — посмотрите сколько поклонников Ruby, Python.
И когда какая нибудь корпорация будет внедрять очередную систему — руководство будет советоватсья у IT специалистов. А они будут советовать уже то, что им больше нравится и что им удобнее.

Именно поэтому я считаю, что если Java не нагонит этого «сахара» себе — она со временем вымрет.

касаемо сабжа

Через пятнадцать лет останется джава или останется C# в масcовом использовании?

концепция Джавы оказалась на удивление толковой и живучей.

Перечитайте первый пост темы — там человек задает вопрос. Вот на него я и отвечаю.

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

Кстати работаю с обоими платформами уже более 10-ти лет. Поэтому знаю о чем говорю.

за прошедшие годы обе платформы настолько разрослись, что полноценно и одновременно владеть обеими все труднее, если вообще возможно.

Кстати работаю с обоими платформами уже более 10-ти лет.

Не надо преувеличивать,.Net выпущен то ли в 2002 то ли в 2003

Тема в общем не о сравнении платформ. Тема о том какая платформа выживет, грубо говоря «у кого маркетологи лучше».

вот это 100%


linux/postgersql/java/hibernate/spring/tomcat/jquery)

Во первых как выделенное относиться к Java?

это правда, не относится ни к Джаве ни к MS

2 no pasaran
Перечитайте первый пост темы — там человек задает вопрос. Вот на него я и отвечаю.
И почему вы на личности переходите? За неимением аргументов по сути?:)

Кстати работаю с обоими платформами уже более 10-ти лет. Поэтому знаю о чем говорю.

полностью бесплатный стек (например linux/postgersql/java/hibernate/spring/tomcat/jquery)

это полностью бесплатное решение цепи от БД до Веб аппликухи, сделанное
полностью на Джаве.
и оно не единственное.

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

А что могут натворить дети со спичками, страшно подумать...

Один из плюсов Java как раз в том что она не дает «детям» нанести сильный вред. Кстати в Java generics — это средство ограничить разработчика от ошибок (которые могут возникать если разрешить использовать в них примитивы и сознавать экземпляры)

На свойствах основаны data bindings и многие фичи дизайнера в студии, которые выполняются через reflection.

В.Net 2 (или то была уже версия 3, не помню) свойства превращались в методы на этапе компиляции, насколько я видел. Что мешает место свойств использовать set- get- методы? Претензии не к механизмы, а к реализации.
Основное преимущество.Net то что он рассчитан на переманивание разработчиков с других языков. Таким образом создается армия голодных программистов и с снижается цена разработки (вот с ценой эксплуатации не все так просто).
Тема в общем не о сравнении платформ. Тема о том какая платформа выживет, грубо говоря «у кого маркетологи лучше».

Я очень надеюсь на маркетологов Оракла:)

WIgor, вам в затеянном споре важно:
1) победить?
2) что-то понять?

удивляет подход, когда сравнивают две сферы не имея полного представления об одной из них.

— нельзя построить полностью бесплатный стек (например linux/postgersql/java/hibernate/spring/tomcat/jquery)

Во первых как выделенное относиться к Java?
Во вторых вопрос сводитсья к бесплатности linux в отличии от windows. Все что дальше перечислено можно переписать вот так /postgersql или вобще любая база включая mssql express/asp.net (mvc) /linq2sql или entity framework или nhibernate/iis/jquery

Мне кажется, что все такие агрументы, почемуто исходят из идеи: раз windows платно — то все остальное тоже, соответственно раз linux бесплатен — то все остальное тоже. И если говорить о серверных продуктах то сравните цены на Windows Server и WebSphere.

— нету аналога hadoop, hive, pig.

Тут сказать не могу — не использовал такие вещи. Но разработки ведутся — вот к примеру research.microsoft.com/...nq/default.aspx

И если вдруг сейчас нет систем продуктового уровня (хотя это не факт), то думаю скоро будут.

— нету систем управления зависимостями от сторонних библиотек (maven, jakarta ivy)

Это да. Таких вещей нет — по крайней мере продуктового уровня.

— ну и библиотек особенно опен сорс под джаву намного больше!

А кто-то мерял количество? Я например аналоги библиотек могу найти практически всегда. А если вдруг в java 3−5 похожих библиотек, а в.Net одна — если она хорошая — какая разница?

— нету армии консультантов и поддержки как например от IBM (поэтому многие большие банки выбирают джаву и дорогущие WebSphere)

У Microsoft армия тоже хорошая — банкам бы вполне хватило.

— нельзя запускать на супернадежных мейнфреймах

Пока не видел этих мейнфреймов ни в одной компании с которой работал. Можете привести пример компаний которые их используют? По крайней мере наш Enterprise — он в массе попроще (всякие HP сервера — в лучшем случае).

Если вас интересуют синтаксические финтифлюшки

Вообще то финтифлюшки делают для повышения производительности и уменьшения ошибок. Думаю у джавы и у шарпа свои скелеты есть в шкафу, но лично мне главное, что оба имеют «хозяина» в смысле надо платить рано или поздно за что нибуть, за инструмент, за среду, за библиотеки, и как только заплатил, снова изменяется версия и нет обратной совместимости и надо снова всё переписывать и снова платить. Лучше что бы всё зависело от меня, поэтому прохожие и пишут, им то же хочется, но наверное это недостижимый идеал

А помоему джаверы в правильном направлении движутся — язык для бизнеса — джава, для продуктивного прототипирования, разработки всяких скриптов, DSL, синтаксического сахара и для интереса гиков есть groovy, clojure, scala.
По поводу Linq, ну так в джаве в куче библиотек есть способы высокоуровневого фильрования коллекций — есть и в jakarta commons и в google collections, и есть всякие другие open source библиотеки.
Чего сходу нету в.NET по сравнению с джава: — нельзя построить полностью бесплатный стек (например linux/postgersql/java/hibernate/spring/tomcat/jquery) — нету аналога hadoop, hive, pig. — нету систем управления зависимостями от сторонних библиотек (maven, jakarta ivy) — ну и библиотек особенно опен сорс под джаву намного больше! — нету армии консультантов и поддержки как например от IBM (поэтому многие большие банки выбирают джаву и дорогущие WebSphere) — нельзя запускать на супернадежных мейнфреймах

По поводу 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 таки возьметься за голову.

А в чем конкретно она более чем обратная?

По языку — гдето так:
LINQ, lambda — аналогов в Java нет, var декларация переменных — тут на вкус и цвет конечно -, но мне нравиться, объявления анонимных типов вроде new {Property1=’1’, Property2=’2’} — аналогов нет, dynamic тип — аналогов нет
Ну еще свойства удобнее ИМХО — лень мне дописывать get..., set..., is...
Обращение к спискам list [i] map [key] по моему более лаконично чем list.get (i) map.get (key)
Generics лучше в.net — пруфлинк en.wikipedia.org/..._Java#Generics
Кстати в Scala практически все уже есть. Проблема только — Scala это не mainstream.

Так что если делать ставки между java и c# — то ставлю на c#. А вот в случае.Net и JRE — тут пожалуй не выберу.

Программистов будет на порядки меньше из-за автоматизации фреймворками.

Могу ещё поумничать и сказать что если будущее Интернет (а) — это Семантическая Сеть (Semantic Web), то ого-го сколько всего нужно будет переписывать и дописывать.

Ну... или это я уж размечталась. Но в то что «программистов будет на порядки меньше из-за автоматизации фреймворками» не верю.

Программистов будет на порядки меньше из-за автоматизации фреймворками.

Какой-то странный вывод. Я о C#/Java не могу говорить, но на на PHP сейчас существует куча-куча фреймворков, готовых интернет-магазинов, систем электронной коммерции — и тем не менее люди продолжают заказывать кастомные (custom) сайты, ибо каждый бизнес — уникален. Это несбыточная мечта — чтобы существовали фреймворки на все случаи жизни. Всё идёт/меняется и даже на старые сайты (и наверное не-сайты тоже) каждый год нужны и заказываются новые фичи.

moderator так быстро трет, что я писать не успеваю

Андрей, когда вы допишете фреймворк-убийцу HTML?

интегрируйте его в Баду непременно, и документацию — на русском.

это была шутка))

трите на здоровье))

В 2012 конец света, так что не парьтесь:)

ээээээээээээээээээээээээээээээээээээээээээээээээээээээээээ
куда потерли наш флуд?
все, точно пойду бухать.
нафик фреймворки.

жаль, Сашка -синего нету))

В 2012 конец света, так что не парьтесь:)

А я думал, что я единственный верю в прилет нового календаря майя, который разрушит Землю:)

В 2012 конец света, так что не парьтесь:)

*пляя точно ((
пора бухать, нафик эту учебу, новые фреймворки.

налоги — туда же.

В 2012 конец света, так что не парьтесь:)

Ну если разогнаться до скорости света, то по теории относительности можно надолго растянуть два года

Какие 15 лет?

В 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.

хм, если мерять письки приводить версии к «штукам» и сравнивать их (5−6 < 1.1−4.0)

то получаем обманчивую картину))

Java из версии 5 подросла к 6

это дааалеко не вся Джава, если вкратце))

Посмотрите с какой скоростью развивается дотнет. Я уверен, эта платформа будет еще долго существовать, т.к. ее продвигает и развивает Microsoft.

А после покупки ораклом сана, вообще не верится в будущее джавы...

сейчас при сравнении.Net 4.0 и Java 6 ситуация более чем обратная.

А в чем конкретно она более чем обратная?


не скажу за ms, ,
а Джава так прирастает и обновляется, что только успевай догонять-учить.
Если говорить о языках\базовых фреймворках как таковых:
с 2004-го года Java из версии 5 подросла к 6, в тоже время.Net с версии 1.1 до 4.0.Net 1.1 явно не дотягивал до Java 5, сейчас при сравнении.Net 4.0 и Java 6 ситуация более чем обратная.

То есть судя по тенденции, на срок 15 лет — я бы ставил на.Net.


1) Сейчас супер-профи в одной технологии не нужны.

2) Нужны те которые знают много технологий на среднем уровне.

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

2) ценность спеца с увеличением широты компетенции растет квадратично, затем упирается в «стеклянный потолок»


no pasaran 1 час назад
не скажу за ms, ,

а Джава так прирастает и обновляется, что только успевай догонять-учить.

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

Сейчас супер-профи в одной технологии не нужны. Нужны те которые знают много технологий на среднем уровне.

MS тоже не отстает. C# 4.0, MEF, снова новый Silverlight, еще появится какой-то говномодныйлайт.

не скажу за ms, ,

а Джава так прирастает и обновляется, что только успевай догонять-учить.


spill 41 мин. назад

через пятьнадцать лет останется джава или с шарп?

А какая разница? Основные принципы у того и того одинаковые (C# удобнее), разница в фреймворках. А их почти каждый раз нужно изучать новый на проект (кроме основных).

Ранок энтерпрайз приложений очень скоротечен. Не факт что через 15 лет останутся Java и C#.

А что касается Украины, как страны без собственного сильного потребителя, то писать тут будут «на чем скажут».

останется джава или останется с шарп? в масовом использовании?

Подписаться на комментарии