👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Пока MS не сделает .NET кроссплатформенным (не надо про Mono, серьезные компании не доверяли и не будет ему доверять), успех .NET будет полностью зависеть только от успеха платформы MS и остальных продуктов MS. А не от фич, крути, и прочая.

В разработке ПО давно(по меркам ИТотрасли) рулят не математики, не инженеры, а обычные такие экономические и бизнесовые законы.

Тоже и с разговорами о «сортировке», «медленнее в 12 раз»

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

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

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

По Си же как-то Зубинский прошелся:
О величии, могуществе, ужасе и мелочах

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Лучшее — враг хорошего.

А в здц скажем «добро пожаловать» именно мелкомягким. Будем посмотреть на их продажы восьмёрки. если они даже Висту не смогли продать, то W8 люди и бесплатно взять не хотят в замену семёрке. Ну не нужна. По-хорошему, Windows-95 было революцией пользовательского интерфейса, и даже семёрке не удалось сделать ничего сколь-либо стоящего с тех пор. При том что W95 шла (летала) на 8 мб оперативки, а W8 и 8 гектар уже «скромно».

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

Не будем забывать, что их акции не падают лишь благодаря программам “количественного смягчения”, то есть надувательства пузыря Enron-style.

Я так розумію “інфа 100%”?

Если интересны мнения экономистов, это не ко мне. У меня на этот счёт своё мнение, которым я могу поделиться, но никак не доказывать.

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

Я говорю «не верю». По опыту прошлых инициатив.

Какая каша, то МС, терь уже оракл. МС сгенерировал 6.6 млрд бакса чистого кеша за последние 3 месяца, какие еще программы «количественного смягчения» и пузыри?

Не расстраивайте человека, ему хочется верить, что МС загибается.

Не то чтобы мне шибко нравится Вин8, но оперативы она жрет ни чуть не больше, чем Вин7. Мне лично 3 гб оперативы в 32бит винде хватает с головой на ноуте.

И кстати, оператива это самое дешевое комлектующее в компьютере, 4ГБ стоит 20 сраных долларов.

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

Какая то странная закомерность — как будто других языков нет.

А когда ховнометы иссякнут — скажут что то типа «какие то джависты неадекватные»...

Какая то странная закомерность — как будто других языков нет.

Ну кроме джавы есть еще груви, скала, кложур...

На скалу раньше любили гнать хаскеллисты, но потом появился scalaz (code.google.com/p/scalaz) и вроде как успокоились, груви — просто никому не нужен.

scalaz

Вы его видели? Есть парочка полезных классов, особенно Validation, ValidationNEL, но вообщем значимость остального сильно преувеличена. Хотя вполне возможно что я еще не понял значимость

вроде как успокоились

Вот теперь у scala есть scalaz и мы перестанем гундеть о ЯП которым не пользуемся

груви — просто никому не нужен

Действительно в большинстве случаев groovy можно выкинуть в пользу Scala, когда нельзя, то это связано с Grails. Это по факту наличия Grails. Иначе действительно можно было выкинуть. А так вполне жив-здоров. Не смотря на ущербность по сравнению со Scala

груви — просто никому не нужен.

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

-Куда большие возможности скриптования и всяких дээслей.

Джава синтаксис

Если сравнивать, то это не плюс. Но на практике вы правы

Куда большие возможности скриптования и всяких дээслей

Скриптования за счет grapes? Вобщем можно и на scala писать скрипты. Но лучше уже тогда на Perl/Python/Ruby

дээслей

За счет получения AST? Где тогда completion? В Scala их можно строить так, что еще и IDE будет помогать

Вобщем можно и на scala писать скрипты.

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

Но лучше уже тогда на Perl/Python/Ruby

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

За счет получения AST? Где тогда completion? В Scala их можно строить так, что еще и IDE будет помогать

Ну да, палка на двух концах. Больше «мощи», меньше удобств со стороны иде.

обещают динамик добавить

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

Больше «мощи», меньше удобств со стороны иде

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

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

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

Вон немерле ж людям понравился. А вообще скала превращается в такую сборную солянку всего и всея, что я не удивлюсь если она поимеет статус второго с++ в истории )

статус второго с++ в истории

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

с++

А мне норм. Надо просто иметь высокую квалификацию.

Это не отменяет нарицательного «с++»

Надо просто иметь высокую квалификацию.

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

Про скалу так уже давно говорят

blog.goodstuff.im/...l-java-projects

А вообще скала превращается в такую сборную солянку всего и всея, что я не удивлюсь если она поимеет статус второго с++ в истории )

О, опять пошло «не читал но осуждаю»

что именно не читал, и что именно осуждаю ?

А сам не способен уже догадаться? Ок, не читал скалу, и осуждаешь скалу.

Ну потому что видно что ты ее мало палочкой трогал. Это в джаву как раз пихают всякий мусор, а в скале очень бережно относятся к выбору фич, и как результат java specification почти 700 страниц, а scala specs всего 200.

Ну потому что видно что ты ее мало палочкой трогал.

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

java specification почти 700 страниц, а scala specs всего 200

Длинна спеки тоже отличный аргумент. У джавы длинее ;-)

Это в джаву как раз пихают всякий мусор

А вот тут (кстати, не троллинга ради) прошу по подробней расписать, что именно по вашему мнению там мусор.

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

Это не аргумент, ты спросил я ответил.

Длинна спеки тоже отличный аргумент. У джавы длинее ;-)

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

А вот тут (кстати, не троллинга ради) прошу по подробней расписать, что именно по вашему мнению там мусор.

например примитивные типы(которые все равно имеют обьектные эквиваленты) и массивы(которые по ходу от ArrayList мало чем отличаются).

Это не аргумент, ты спросил я ответил.

Стаческий — семантический разбор текста. ок. :-)

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

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

например примитивные типы(которые все равно имеют обьектные эквиваленты) и массивы(которые по ходу от ArrayList мало чем отличаются).

жжош.

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

Та нет, там больша гавна, пример я уже привел

жжош.

о, опять набросы пошли

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

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

в смысле зачем языку значимые, а не только ссылочные типы? :)

в смысле зачем языку значимые, а не только ссылочные типы? :)

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

то есть для вас значимый тип — это только имьютабилити? :)

Не immutability, т.к. ты можешь его замодифировать, но это не будет видно вызывателю. А для тебя это еще что-то?

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

Чисто для ликбеза бегом читать про escape analysis

то есть жит компилятор на своё усмотрение может разместить экземпляр ссылочного типа в стек на свое усмотрение?

Где то так, с вариациями на тему «на свое усмотрение».

ну тогда у меня ещё вопрос. всякие ли объекты он может разместить в стеке или же есть какие-то конкретные правила для этой процедуры?

Если размещение обьекта на стеке не вредит семантике программы. Типа мы обьект удалили вместе с стеком, а его кто-то изменить извне захотел. Вроде ж в гугле все это написано должно быть?

то есть не проблема в стеке разместить стрим ридер или массив для примера?

то есть чёткого представления о том, как этот автоматический боксинг/анбоксинг происходит у вас нет?

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

то есть чёткого представления

скажем у меня нету 100%тной уверенности. ДжВМ это еще та куча гавнокода со своими костылями.

боксинг/анбоксинг

боксинг тут очевидно совершенно не причем

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

а мне так не кажется. Вот те пример с левым классом: stackoverflow.com/a/1212015

боксинг тут очевидно совершенно не причем

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

а мне так не кажется. Вот те пример с левым классом

опять же компилятор знает, как разместить в стеке int. очевидно, что сможет разместить в стеке и объект состоящий из 2х интов. в си шарпе даже говорят есть пользовательские значимые типы ;)

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

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

Звиздеж, если заэскейпленный обьект уже на стеке, куда там его еще перетаскивать?

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

А еще я пью кровь христианских младенцев.

Звиздеж, если заэскейпленный обьект уже на стеке, куда там его еще перетаскивать?

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

Ты прикалываешься? Я тебе уже и слова по которым гуглить нужно написал(escape analysis) и ссылку на код с дампом гарбадж коллектора и бенчмарком дал.

я сходил уже по этой ссылке.

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

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

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

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

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

он состоит из конечного числа примитивных типов

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

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

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

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

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

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

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

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

о, опять набросы пошли

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

Вам постоянно какието набросы везде мерещатся.

А «обьяснять» вам я уж точно ничего не буду.

Вам постоянно какието набросы везде мерещатся.

А «обьяснять» вам я уж точно ничего не буду.

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

Какой аргумент? Я спросил, ты ответил, давай, до свидания ;-)

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

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

О, «метр» уже подался полную чушь нести. Давай, жги еще.

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

У него то серьезное дело было. Реальное воровстово. А я тут с вами учусь азам мета-троллинга, всегото. Пока ветку не потерли.

Понятно, так и запишем, признание с повинной.

Это у них так на сайте написано. Значит спека неполная и делает отсылки к Java. Я трогал скалу вдоль и поперек, пишу на ней свои проекты и проекты фриланса. И да она сложная и не надо придумывать что она простая любой дятел ее осилит. В ней можно наворотить ужасов. «So what?» Если ты не наворотишь ужасов, то зачем писать на таком handicap как Java

Это у них так на сайте написано. Значит спека неполная и делает отсылки к Java.

Или все таки в джаве куча ненужного мусора

. И да она сложная

Сложная(с чем я не согласен) и «сборную солянку всего и всея» это разные вещи. В скале намного меньше элементов чем в джаве, практически все элементы перечисленны вот здесь и разбираются за пол дня: www.scala-lang.org/node/104

Сложная(с чем я не согласен)

Ну-ну github.com/...scalaz/MA.scala

Existential types, continuations passing style, dependent types, дебильные Enums. Не говоря о том, что for — синтаксис для монадических вычислений.

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

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

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

Скала какраз «продается» как легкая для старта. В том числе аля любой дятел может ёё взять и запросто писать ченить.

В ней можно наворотить ужасов. «So what?»

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

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

Если ты не наворотишь ужасов, то зачем писать на таком handicap как Java

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

Скала какраз «продается» как легкая для старта

Уже нет. Читайте Поллака. Его пойнт в том, что скалу лучше не пиарить и тогда вместо 1000 успешных проектов из 10000 будет 1000 успешных из 2000. В первом случае посредственные команды наворотят как раз ужасов и завалят проект. Если у вас собралась команда пряморуких, то scala ускорит их работу. Не знаю, поможет ли им элитизм, может из-за него инструменты так и будут на том уровне, на котором они сейчас

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

А на каком они сейчас?

Проекте? Ну на другом. Или тот переписали на жабку и повторяют мантру «взять список a, создать ArrayList, пройтись по a в цикле, обработать каждый елемент, добавить его в ArrayList». Так спокойнее

Я имел в виду инструменты. Ты потом уже кажется абзац про ребят дописал.

И в чем проблема писать на скала как на джава?

В качестве вхождения никакой, или при сильной потребности. Просто будет Java, которая будет дольше компилироваться и не всегда нормально подчеркиваться в IDE. «Зачем платить больше» если у тебя весь проект такой?

Другое дело если бы они научились писать именно на Scala. Код стал бы чище и надежнее, вообщем-то иногда даже быстрее

Просто будет Java, которая будет дольше компилироваться и не всегда нормально подчеркиваться в IDE. «Зачем платить больше» если у тебя весь проект такой?

За счет выведения типов и лямбд код бы стал чище. НУ и я как то давно не встречал что бы что-то не подчеркивалось в scala ide.

Другое дело если бы они научились писать именно на Scala.

А что такое писать на скале? Скала мультипарадигменный язык.

иногда даже быстрее

но чаще тормознее

А что такое писать на скале? Скала мультипарадигменный язык.

Больше программирования от структур данных, больше иммутабельных и lock-free структур данных, преимущественное применение ФВП, mixin composition, cake pattern, сведение к минимуму кастов путем правильного использование типов, применение Option, список можно продолжать. Если писать как на Java профитов будет меньше

Если писать как на Java профитов будет меньше

высосано из пальца

Если писать как на Java профитов будет меньше

высосано из пальца

И в чем же «профиты»?

профиты чего по сравнению с чем?

профиты чего по сравнению с чем?

Читайте ветку.

Что, спадет шапка если внешешь ясность в свой лаконичный вопрос?

Что, спадет шапка если внешешь ясность в свой лаконичный вопрос?

Не не спадет.

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

Не не спадет.

А что же тогда? Религия офисного хомячка не позволяет вести конструктивную дискуссию?

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

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

Религия офисного хомячка не позволяет вести конструктивную дискуссию?

:) Забавный вы человек.

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

Если это личная переписка, то ее надо вести не на публичном форуме. Предполагая что это не личная переписка, я вас попросил объяснить ваше утверждение, можете «с удовольствием отвечать».

:) Забавный вы человек.

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

Предполагая что это не личная переписка, я вас попросил объяснить ваше утверждение, можете «с удовольствием отвечать».

Ты спросил «А в чем же «профиты»?"(я типо ни про какие профиты не писалм а совсем наоборот) а не обьяснить мое утверждение. Не надо скатываться в унылое вранье и подмену понятий.

А зачем на Scala тогда писать? Чтобы быть крутым перцем?

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

Ну я же сказал зачем писать на Scala если пишешь как на Java

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

Кстати про производительность разных подходов: java.dzone.com/...g-scala-against

Идиоматический пример Scala из разряда убиться об стену. Алгоритмически. Применяют фантастически неэффективную операцию «:::». Фильтром проходят два раза, хоть бы partition уже осилили

Я заменил на вот такую реализацию: pastebin.com/KGKejD9p
и получил разницу всего в 10% с исходным «идиоматическим» кодом.

Фильтры там не считаются два раза потому что очевидно что это ленивая коллекция как и с партишном. И чем «:::» хуже чего то другого тоже не совсем понятно.

Не факт что ленивая, я там view не видел, а иначе могли не заморачиваться. Я не к тому сказал что это можно оптимизировать. Если сюда глянуть, то видно кучу операций которые создают объекты. Плюс пресловутые «:::» или «++», которые вообще O(n) сложности, и их надо бояться. Функциональный стиль — хорошая штука, но зачем писать код, в котором невооруженным глазом видно алгоритмически неэффективные и тяжелые операции, а потом его бенчмаркать против in-place сортировки. Результат предсказуем, и не надо строить иллюзий о магическом компиляторе, который все сделает как надо, потому что задроты на бумаге доказали что ФП код можно очень хорошо оптимизировать. Ключ в том, что некоторые алгоритмы надо писать оптимально, а остальные лучше кратко. Но те алгоритмы которые будут бенчмаркать в блоге чтобы что-то кому-то доказать нужно писать оптимально, иначе это не бенчмарк, а надругательство над кодом.

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

Это все я к твоей реплике что функциональный код может быть быстрее.

Может, но за счет эффективного параллелизма и lock-free структур данных. И главное — думать головой и оценивать алгоритм, а не ожидать что парадигма даст скорость. Императивный код может быть утыкан lockами, функциональный код может гадить объектами и заниматься дурацкой работой

Может, но за счет эффективного параллелизма и lock-free структур данных.

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

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

От я не пойму ты за меня или за медведя вы считаете что скала (идиоматическая) дает соизмеримую (или более высокую) производительность по сравнению с джава или нет?

Тогда каким макаром «идиоматическая» скала может быть быстрее джавы?

Наш разговор у убогости уже перешел все границы... Не может! Потому что внезапно Scala написана на Java. Другое дело что в Scala есть очень много структур данных и удобных функций для параллелизма, и хотя их можно написать в Java, но вы их не напишете и будете возможно из-за лени или недостатка времени использовать что-то примитивнее. А в Scala вы их будете использовать просто потому что это легко. Психология и затраты времени — ключ ко многим успехам и фейлам в IT

Другое дело что в Scala есть очень много структур данных и удобных функций для параллелизма ... . А в Scala вы их будете использовать просто потому что это легко.

От вам сказочка из жизни:

Есть проект: старое ядро на джава все новое (и ядро, и оболочка) на скале. Люди узнали о существовании магического «par» в коллекциях и начали сувать его везде. И все начало тормозить, ибо цепочки выполнения у них легкие и процы быстрые и не оч то и параллельные.

Вывод: давать абезяне гранату может быть очень не безопасно.

давать абезяне гранату может быть очень не безопасно.

Все правильно

par — хороший способ отстрелить себе все что можно. Например несколько файлов обработать через filesList.par.map, это нормально. А потом reduce. Вообщем уже есть функция, которая комбинирует это вместе — aggregate

Например несколько файлов обработать через filesList.par.map, это нормально.

Вот у меня так и было в коде, ребята это подсмотрели и начали параллелить примитивные фильтрации.

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

Меньше лирики, примеры пожалуйста

Учите Scala, что я могу сказать. ScalaDoc тоже можно

Понятно, слив в старых доуовских традициях.

слив

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

А, так вы думали мы соревнуемся?

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

я не знаю коллекций, проведите бесплатно ликбез

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

Жесть, иди в тот самый гугл и читай о replicate, par, Ctrie и о акторах в целом. И они не делают идиоматическую скалу быстрее джавы, не хочется это повторять второй раз, потому что скала _ни_разу_не_быстрее_джавы_. Только средства параллелизма доступнее, что повышает вероятность их применения.

Ну давай поговорим например об актерах. Тебе с высоты твоего 23-ехлетне-синьёрского опыта не известно что у АККА например есть Java API?

А в чем тогда проявляется «доступнее» в контексте скалы?

Тем что код короче, вместо громоздких фабрик краткие лямбды, удобней писать case классы для иммутабельных сообщений. Ну и future composition. Ты же вроде сам должен такое знать? Просто лучше сначала определиться, ты скалу знаешь или нет. Если да, то у тебя странные вопросы. Если нет, то разговор у нас не получится

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

Это преимущество не «идиоматоческой» скалы, а просто скалы, т.е. мимо цели.

ты скалу знаешь или нет.

Я ее знаю на некотором уровне. Вот сейчас прохожу курс одерски, домашки у меня занимают пол часа со 100% результатом. Всех заковык ее я конечно не знаю.

Если да, то у тебя странные вопросы. Если нет, то разговор у нас не получится

Аяяй, опять тролишь

Статью я читал, с мнением Поллака согласен.

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

Ну хаскель имеет еще одну фичу — ты иногда борешься против него. Вот в Scala такого нет. Конкретный алгоритм может быть императивным если надо, хоть в с книжки Кнута списывай. Функциональный код для малого, ООП для большого.

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

груви — просто никому не нужен.

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

ИМХО, груви — прекрасный язык для тех кто просто «устал» от джавы.

ну груви прекрасно внедряется партизанскими методами. С Грейдлом и с Силениумом например, да... А на скалу пока реакция по острее что ли

.

Объясните что значат эти точки? Часто вижу и в разных контекстах (вроде бы).

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

На некоторых форумах это позволяет поднять тему в актуальные.

Здаетсо шо не так (трололо темы на ДОУ и так в топе)

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

адекватность комментов резко возрастет.

Объясните что значат эти точки?
теперь так удаляют свой коммент.
опцию «удалить» убрали, а редактирование оставили.
вот, простая точка превратилась в трололо))

Зачем было убирать кнопку удалить. В чём смысл сего поступка? Кнопка корректно работала, даже, если на удаляемый коментарий ответили.

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

в идеале, неплохо ещё через сутки дизейблить кнопку «редактировать»

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

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

если лямбды приживутся

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

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

Но по факту верно. Почему то, вместо того, что бы перенимать опыт — джава — фанбои орут «не нужно».

Закостенелость и иннертность интырпрайза сейчас двигают джавой туда — сюда. Видел кучу проэктов, которые как не собирались, так и не собираются переходить на джаву 7 — рисков слишком много...
А замыкания там таки не нужны:
-Если нужны замыкания можна сейчас взять груви, и подключить его к соотвецтвующему проэкту тремя строчками в пом.иксемель и получиш замыкания, дсли, и прочие радости с минимальной разницей в синтаксисе.
-Если в жабу 8 таки добавят лямбды, то на работе это никак не скажется, ибо проэкты будут еще долго продолжать висеть на жабе 6. И если вдруг здуру нужно будет написать какой кусок с лямбдами и дслэм — гораздо проще и безопаснее подключить груви, чем переходить всем аппликейшном на жабу 8.

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

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

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

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

Ага, и поэтому версии нет несовместимы между собой...

Нельзя ли пример обратной несовместимости?

можно ли запустить код с лямбдами на .NET 2.0?

такой взрослый и вроде бы такой опытный, а не понимаете, что такое обратная совместимость :) стыдно :)

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

кстати код откомпилированный в жабе 7, на жвм 6 тоже не запустиш ;-).

Другое дело, что большенства кода написанного для джавы 6, 5, или, там 1.4 можна (почти) без изменений компилировать 7-мой джавой.

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

JDK 7 Incompatibilities in javac, in HotSpot, or Java SE API

но, не пробовал :)

можно :)
как раз 2.0 нормально запустит код и с лямбдами, и с другими новыми фишками шарпа (IL для них не меняется) — главное не юзать нових класов 3.0+ и таргет фреймворк указать 2.0

джаву 7

В основном что фичи Java 7 — смешны, если вам не нужен NIO. switch по строкам, facepalm, 21 век.

груви

И получить вообще убийственно тормознутую скорость выполнения. Пускай. Но самое страшное — динамическая типизация в придачу. До свидания нормальная проверка типов, быстродействие, рефакторинг, completion. И не надо упоминать Groovy++.

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

Сенсация, Java 8 будет глючнее Groovy. Дожили )

А что страшного в динамической типизации?

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

В эпоху TDD ничего страшного в динамической типизации нет. Ну кроме скорости конечно.

В эпоху TDD

Какую эпоху TDD?

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

Т.е. явисты не пишут тесты потому что у них нет проблем из-за ошибок типов?

Работая по TDD Вы пишите тесты будь Вы хоть явист хоть питонист.

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

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

Т.е. явисты не пишут тесты потому что у них нет проблем из-за ошибок типов?

Откуда вы взяли? Мы пишем тесты И у нас нет ошибок типов. Самое главное что мы не пишем тесты для проверок ошибок типов.

вообще-то, проблема ЯП с динамической типизацией не в этом, и обозначается несколько десятилетий :)

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

что и не удивительно, ведь чтение человеком программного кода состоит из частей:
1. читаем, смотрим на данные
2. читаем, смотрим на действия над ними
3. прикидываем в уме как, в каком порядке это выполняется

(3ий пункт отсутствует в декларативных языках)

так вот динамическая типизация приводит к потере информации, в программном коде, о
1. типах данных,

2. допустимости операций над типами.

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

но когда количество типов и действий над ними растет
когда приложение состоит из слоев в том или ином в виде оперирующими схожими по назначению типами

когда типы все более далеки от макро-типов предметной области

тогда и никакое TDD не поможет прочесть и понять — код.

Это главное, в программном коде — читабельность :)

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

Что называется — я очень рад за транслятор, что он объявление
var tmp = ...

tmp.foo();

проверит, и обругает на этапе трансляции.

А мне, человеку, как это прочесть, есть у tmp foo() или нет?

для интерпрайза динамическая типизация — зло и погибель.

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

В основном что фичи Java 7 — смешны, если вам не нужен NIO. switch по строкам, facepalm, 21 век.

А дело то больше не в фичах, дело в багах.

И не надо упоминать Groovy++.

Таки не надо, ибо в 2.0 по умолчанию статическую типизацию добавили.

Сенсация, Java 8 будет глючнее Groovy. Дожили )

Вы неправильно мой комментарий интерпретировали, я не то имел ввиду.

Но по факту верно.

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

вот и считайте.

Почему то, вместо того, что бы перенимать опыт — джава — фанбои орут «не нужно».

вот орут как раз младые ленивцы, которым неохота учить кучу Джава фреймворков.

матёрые джаверы освоят хоть китайский, аби вашi ґрошi

время которое у нас есть это деньги ©

вот и считайте.

Все верно, учиться не надо ;)

Джава фреймворков

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

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

Какие например?

Одно «маленькое» но..Эта вся красота работает исключительно под Windows. А значит, все дорого для заказчика.

Вообще то большая часть этой красоты работает под чем угодно, спасибо Ксамарину.

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

Я разворачивал несколько сайтов под Моно, в том числе ТимЛаб. Всё ок. Порядка ради — все ВебФорм, MVC не проверял.

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

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

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

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

В IT есть очень много упоротых субкультур, но Java-культура одна из таких, в которой наиболее выражено «Если так в Java, значит так и надо». Хотя если бы большинство программистов на Java критиковали Java больше, то она была бы более инновационной и не оставляла конкурентам место.

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

А примеры на лурке не приводили?

О да, но не могу копипастить из-за лексики. Вообщем будучи Java программистом согласен с 7 из 9 пунктов отсюда http://соснули.рф/ Partial классы — бред сумасшедшего. Свойства не нужны когда есть Scala-way unified access

Вообщем будучи Java программистом согласен с 7 из 9 пунктов отсюда http://соснули.рф/

И как это связанно с цитатой которую вы привели?
От себя могу добавить: где плюсовые шаблоны? где указатели? где не виртуальные методы? там ниже был список функциональных фишечек еще куча «где».

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

Кстати, может вы расскажете почему в джаве нет замыканий?

И почему тот недочет который вы приведете в доказательство (если вообще приведете) является недостатком и обязательным для выполнения?

где плюсовые шаблоны?

Это широко сказано, что вам в этой фиче важнее всего?

где указатели?

Надо хорошо поискать

где не виртуальные методы?

Они в рантайме могут стать невиртуальными

но не считаю их необходимыми (при наличии анонимных классов

Все таки отношусь к этому утверждению как к самому большому заблуждения всея Java. Хотя годик назад рассуждал так же. Во-первых — писать постоянно новые интерфесы для a->a, a->a->->a, a->b->a и т.д трата времени. Ведь мог бы быть тип функции и все. То, что функции многу многое уже показано не раз. Во-вторых, даже если сделать тип универсальный тип функции, то нотация анонимного класса громоздка. У разработчика нет мотивации написать что-то через map чем через создание списка и цикл если это займет одинаковое количество места. С другой стороны все бы с удовольствием писали filter(_>10).map(_*2) и улучшали читаемость алгоритмов из-за их обозримости без скроллинга. Ну и цикл надо разбирать что он делает, вместо того чтобы увидеть слово «map»

Это широко сказано, что вам в этой фиче важнее всего?

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

Они в рантайме могут стать невиртуальными

А подробнее.

Во-первых — писать постоянно новые интерфесы для a->a, a->a->->a, a->b->a и т.д трата времени. Ведь мог бы быть тип функции и все.

Что значит новые и постоянно. 1 раз или взять из гуавы или другой либы.

А подробнее.

Насколько мне известно это одна из оптимизаций JVM. Если вы написали лишь одну реализацию метода класса, от него отнаследовались 100500 раз, но не переопределили этот метод, то JVM в любой точке кода захардкодит указатель на метод. А таких методов очень много.

Что значит новые и постоянно. 1 раз или взять из гуавы или другой либы.

Вы же говорили о анонимных классах и интерфейсах. Как низкоуровневый механизм для функций — ок. Но тип «функция» необходим. И как ни как не иначе как в ядре языка или библиотеки классов Java

Кстати, может вы расскажете почему в джаве нет замыканий

Сначала Sun тупили, ибо замыкания бы испугали невинного и наивного Cobol Java программиста. Потом и сейчас хотят сделать позаковыристее чтобы без модификации библиотек лямбды можно было пихать там где есть старые интерфейсы аля Runnable или Comparable. Вон делают, все хорошо

Вон делают, все хорошо

А я то думал что они (замыкания) появились еще в джава 1.1 (ну в 1.5 точно были).

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

И знаете что? Они правы! Это быдлокод — пользоваться анонимными классами и плодить простыни кода. И так будет до тех пор пока не будет короткой нотации лямбд

И так будет до тех пор пока не будет короткой нотации лямбд

Это решается всего за 199 багзов: www.jetbrains.com/...a/buy/index.jsp

Это быдлокод — пользоваться анонимными классами и плодить простыни кода.

Зато эту простыню может прочитать любой джун и ее легко рефакторить.

Это решается всего за 199 багзов

И как же?

Зато эту простыню может прочитать любой джун и ее легко рефакторить.

И лямбды он читал бы еще лучше

Это решается всего за 199 багзов

И как же?

ИДЕА прячет весь «шум», при том таки хорошо (можете попробовать комюнити-эдишн)

Ну а кодогенерация есть и в бесплатных ИДЕ и в текстовых редакторах.

И лямбды он читал бы еще лучше

Угу, например такое: _*_

кодогенерация

Java-way в лучшей форме. Создаем проблему, потом решаем.

Угу, например такое: _*_

Отлично все. Думаю ваша мама тоже считает Java нечитабельной. Программист на почти любом ЯП отлично его читает

Думаю ваша мама тоже считает Java нечитабельной.

От тока мне не приходится разгребать гуано-код за моей матерью. А со всякими там _&^%$+$_#*#$^%$& написанными малолетними гуру приходилось сталкиваться.

Java-way в лучшей форме. Создаем проблему, потом решаем.

И в чем же проблема с кодогенерацией?

малолетними гуру

Вот он ключ. Более молодые используют более прогрессивные подходы. Решение: стать более открытым и почитать книги.

И в чем же проблема с кодогенерацией

В последующем редактировании — раз. В простыне кода — два

Вообщем я думаю вам есть смысл посмотреть en.wikipedia.org/...rogrammer)#Blub

К этому и сводится наша дискуссия

Я пересаживался с C++ на Java, не обнаружил никаких «нехваток»

когда пересел назад на C++ ощущение было, что обе руки левые.

Согласен, что кроме лямбд в списке «соснули» нет ничего реально полезного.

Более того, отсутствие миллиона языковых альтернатив реализации той те фишки создаёт единый стиль программирования. Скажем, как реализуете простой коллбэк ?

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

Я пересаживался с C++ на Java, не обнаружил никаких «нехваток»

Наверное зависит от стиля кодирования. Мне очень не хватало указателей и указателей на функции, но это быстро прошло.

Согласен, что кроме лямбд в списке «соснули» нет ничего реально полезного.

Хм, а для меня как раз лямбды довольно сомнительны, а вот хвостовую рекурсию бы хотелось (но это на любителя — то есть не обязательно)

Хм, а для меня как раз лямбды довольно сомнительны

Как в Java сделать list.filter(_>10).map(_*2).foldLeft(0){(acc,x)=>acc+x} не породив простыню кода?

Или посложнее, но вы будете это читать как Бог уже через неделю

val jobWithMaxSalary = list.groupBy(_.job).map(x=>(x._1,x._2.map(_.salary).sum)).maxBy(_._2)._1?

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

Отнаследоваться от сгенерированного кода в принципе возможно

Можно, но тогда у нас уже два класса и наследование, и все это попадает в рантайм.
Все поля придется делать protected или public явно.

И ещё получаем проблему — обращение к члену в наследнике из предка.

Для примера, кидаем на форму Button с именем ’btnDoSomething’. И лепим к нему обработчик события на клик.

В генерируемом коде получаем что то типа:

partial class Form1 { private void InitializeComponent() { this.btnDoSomething = new System.Windows.Forms.Button(); this.btnDoSomething.Location = new System.Drawing.Point(354, 116); this.btnDoSomething.Name = "btnDoSomething"; this.btnDoSomething.Size = new System.Drawing.Size(75, 23); this.btnDoSomething.Text = "Click Me"; this.btnDoSomething.Click += new System.EventHandler(this.btnDoSomething_Click); } }

А в юзер коде получаем:

public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void btnDoSomething_Click(object sender, EventArgs e) { } }

Получается из сгенерированного имеем доступ к членам (btnDoSomething_Click метод, что позволяет нам используя делегаты прилепить его к событию кнокпи), и наоборот, из нашего кода мы можем написать просто btnDoSomething (просто обратится по имени) — и сделать с нашей кнопкой что угодно. И для этого не нужно тайпкаста, не нужно делать все поля protected или public, как в том случае если бы мы наследовались к примеру от сгенерированного класса.

Можно конечно сказать что эта генерация никому не нужна, но вот к примеру на Андроиде дизайнер UI — генерит xml-ку, которая потом просто в рантайме грузится и по ней конструируются UI объекты, тут конечно тоже есть свои плюсы (можно реюзать удобно xml-ки, логика более отделена), но зато нельзя к кнопке обратится по имени как к btnDoSomething, нужно через специальный метод вытягивать кнопку по имени или id-шке в виде объекты анонимного и кастовать каждый раз в конкретный тип контрола (мало того что каждый раз нужно писать однообразный код и помнить тип контрола, так ещё если поменяешь тип контрола, скажем с Button в MyMegaCustomButton, нужно потом не забывать менять везде касты).

Но это я уже отошел от темы чуть.

В общем, partial class — просто удобная фича для организации кода, как #include в Си, но при этом не такая страшная, ломающая модульность, и сводящая компилятор с ума. Я не думаю что она кому то сильно мешает.

P.S.

Возможности ДОУ по вставке кода в комментарии — печальны.

Возможности ДОУ по вставке кода в комментарии — печальны.

можно юзать пастбин какой нибудь

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

Правда тут ещё проблема, что комментариям в глубине мало места остается по ширине.

А ещё мне лень... :DD

что каждый раз нужно писать однообразный код и помнить тип контрола, так ещё если поменяешь тип контрола, скажем с Button в MyMegaCustomButton, нужно потом не забывать менять везде касты).

Ну зачем так извращаться? В layout можно сделать чтото типа android:onClick="onSomethingClick" а в активити потом просто пишеш public void onSomethingClick(View v) {} и все. Правда если не активити а фрагмент то не прокатит, прийдется листенер вешать

А как насчет поменять — из кода текст на кнопке, ну или на TextView?

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

Чтоб поменять текст в текствью достаточно найти этот текствью по его айди и вызвать у него setText

Ох, как тяжело.
А можно вызвать какой то метод или сетнуть что-то, что есть только у класса Button, но его наследника?

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

Button button = (Button) findViewById(R.id.button_send);

ВебФормы — тоже самое. Декларация отдельно, события отдельно в двух разных файлах.

В принципе, шаблон

«Если так в %технология%, значит так и надо»

универсален )

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

В принципе, шаблон

Но в Java преувеличивают это, потому что часто так и надо. Но уж точно не всегда. Разбить себе лицо ладонью есть где

Оптимальность — да. Но во многом мы научились есть кактус. А именно это отпугивает начинающих разработчиков. Потом они идут на неправильные платформы и удивляются почему «нет этой штуковины как у программистов на Java из соседней комнаты»

Не понял, что отпугивает начинающих. Отсутствие делегатов и перегрузки операторов ??

Не понял, что есть неправильные платформы и кто ест кактус

Не понял, что отпугивает начинающих. Отсутствие делегатов и перегрузки операторов ??

Не понял, что есть неправильные платформы и кто ест кактус

некоторые начинающие разработчики, прочитав пару книжек по Скале\Хаскелю и поиграв с кодом, принимают на веру маркетинговое бла-бла и свято верят в неполноценность Джавы. Переубедить их сложно. Да и не нужно.

А как вам книжки по Scala или Хаскеллю? Что понравилось, что нет?

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

зы: топик про .Net вощето ))

интересовался поверхностно, глубоко не вникал,

Тогда ок

зы: топик про .Net вощето ))

Именно

неполноценность Джавы

Совершенно полноценная платформа. С лямбдами была бы вообще отличной

Совершенно полноценная платформа. С лямбдами была бы вообще отличной

но Скала всё равно учить надо, если есть желание.

Джава не вечна.

Scala — один из немногих ЯП, который действительно правильный

интересовался поверхностно, глубоко не вникал,

простыми они мне не показались.

популярное «не читал но осуждаю»

популярное «не читал но осуждаю»

ага, в подобном споре главное — уесть оппонента.
dou.ua/...=comment#254626

это осуждение?

это осуждение?

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

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

к чему этот флуд?

читайте название темы.

действительно, кончай флудить и почитай сам.

действительно, кончай флудить и почитай сам.

спор в стиле школотизма

как и сама тема

Java 7, Java 8

В полной Ж ?

спор в стиле школотизма

Ну ты сам начал, извини что опустился до твоего уровня

ну в общем, ты в своём стиле.

удачи

Согласен, как обычно воюю с тролями и урезониваю школоту

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

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

щито?

Я говорю за то что мне доводилось видеть в наших около аутсорсах.

Не каждый 23-х летний синьйор без гугла ответит на вопрос в каких случаях используется super в дженериках.

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

Количество классов для какогонибуть базового ИО (в сравнении с паскалем или даже сями) досихпор внушает =).

Количество классов для какогонибуть базового ИО (в сравнении с паскалем или даже сями) досихпор внушает =).

IO фреймворк это стрём, конечно.

только ленивый не придумал ещё своё NIO, NewNIO, NewNewNIO.

очень много старого тряпья.

Как говорится “it is possible to disprove gravity”

Пока Mono не запилит все это, а оно его не запилит, жаба будет жить и процветать

Ну вообщето они запилили почти всё: www.mono-project.com/Compatibility

Смотрим .NET3.0 и изумляемся:
частично: WCF — silverlight 2.0 subset completed
нет: WPF — no plans to implement
нет: WWF — Will implement WWF 4 instead on future versions of Mono.
При чем WWF и WPF то еще ладно. А вот то что из WCF только мелкие части запилены — удручает

Согласен, но со всем остальным всё в порядке.

Кто бы мне на пальцах объяснил про тотальный успех .NET на ОСях от MS

Когда он появился, я помню реляциии от MS — теперь почти все прикладное ПО будет писаться на нем! Ура, наконец-то мы избавим программистов от кошмаров работы с системным уровнем, от С++, без ощутимой потери эффективности выполнения.

И вот, прошли годы и версии, выходит Win 8, и в частности RT, а приложения, которые бы легкой добавкой Metro UI могли работать под Win 8 — где?

Или Win8 RT это такой Хромо ОСъ от MS?

а вы считаете, что это нереально и кроме интерфейса (вьюхи) придётся переписывать ещё что-то?

Кстати, в джаве до сих пор нету вменяемого аналога LINQ.

А еще монад, фвп, ленивости, tco, каррирования, ad-hoc полиморфизма, тайпклассов.

Вы это сейчас на что намекаете ) Но именно в Java это не нужно. Лямбд хватит. Остальное доступно в Scala

Кстати, в джаве до сих пор нету вменяемого аналога LINQ

Не нужно

Зачем? Когда это все есть в скале

Затем, что, Скала и Джава — разные языки. Вы из за одной фичи будете писать модули на разных языках?

А мне и в джаве это не нужно, я просто привел пример

А вы и не пробовали.

Гм. Это ни вы ли мне расказывали, что jQuery фигня и не самый популярный фреймвёрк на js?

Участвовал в сраче в котором дотнетчики говорили что LINQ может оптимизировать выполнение LINQ запросов, а ФВП скалы достаточно прямолинейны — делают то что ты просишь и все. Дотнетчики, правда? Если да, то какого рода оптимизации и над какими объектами.

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

Какая же глупость. Это главная причина, почему я отмораживал проекты на Nhibernate, в пользу EF. Парсить один строковый язык в другой просто убожество. Я начну воспринимать Java как альтернативу C# только с 8й версии, когда лямбды там таки появятся.
Да и вообще какая мне нафиг разница кроссплатформенный язык или нет. Я пришел на работу, мне дали задание, я выполнил его с комфортом, C# мне в этом помог, мне заплатили зарплату. Мне глубоко пофиг что этот код не запутится на Маке, это проблема заказчика, главное что их пока в достатке.
А если приложение клиент серверное, то вопрос о том, что серверная часть должна быть кроссплатформенна вообще не должен стоять.

лямбды «спасут отца русской революции»? Это последний шаг к мировому пожару на крыльях JVM...

лямбды «спасут отца русской революции»? Это последний шаг к мировому пожару на крыльях JVM...

Абизянкам надо шоб блестело, а не шоб работало.

Шоб работало любой сможет сделать. Другой вопрос как сделать. С лямбдами код становится более компактен, читаем и целостен, или это все фигня, главное чтоб работало?

С лямбдами код становится более компактен, читаем и целостен,

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

Если руки кривые...

Помню читал Рихтера, вроде умный мужик, но писал, что properties в C# - зло, т.к. многие не видят отличий между полями, что может привести к печальным последствиям. Поэтому он считает, что лучше бы МС тупо их не делал, как Java. ИМХО бред, почему из за криворуких, пряморукие должны лишаться фич, которые реально приносят немало пользы?

ИМХО бред, почему из за криворуких, пряморукие должны лишаться фич, которые реально приносят немало пользы?

Если проблем не будет, то проблем не будет. Ваш КО. :)

Если руки кривые...

доо. создать классическую циклическую зависимость, которую gc не сможет отрезолвить — проще простого, а вот «поймать» на глаз почти нереально

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

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

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

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

тут да. меня тоже возмущает отсутствие в с# и java нормальных шаблонов (а не тех убогих костылей типа generic) , множественного наследования и препроцессора .... но их «убрали» ибо криворукие видите ли «не справляются»

А почему в JAVA покоцали указатели, а в C# они доступны только в анменеджед? Защита от дурака.

К слову, я был вполне согласен с Рихтером по этому поводу, пока не появились анонимные свойства.

Не троллинг:

А почему в JAVA покоцали указатели, а в C# они доступны только в анменеджед?

Патамушо в Ц№ решили напихать всего-всего не думая о том надо оно или нет.

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

С лямбдами код становится более компактен, читаем и целостен

Во что превращаются «лямбды» на уровне ВМа?

или это все фигня, главное чтоб работало?

Работало и работало эффективно. Эффективно в плане исполнения.

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

Если уж говорить о синтаксическом сахаре, то ИДЕА умеет прекрасно прятать «шум» от САМ (new ClassName{public T methodName(){ ... }})

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

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

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

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

UPD.:

Во что превращаются «лямбды» на уровне ВМа?

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

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

оказывается когда код ссылается на внешний ресурс — то внешний ресурс приходится мокать!

что в этом плохого?

В методе 3 лябды: первая ссылается на ресурс А и Б, вторая на В и Г, третья на А, В, Г и Д. Итого надо замокать абвгд ресурсов от которых зависят лямбды для проверки метода, или же можно замокать сами лямбды и не фиксить тесты когда к зависимостям первой лямбды добавятсо ресурсы Е,П,Р,С,Т.

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

Надо получить на нее ссылку.

А как бы вы покрывали тестами это в js?

Так же само и в C#

Во что превращаются «лямбды» на уровне ВМа?

Классы на лету генерятся, т.е. делается то, что джавист должен делать руками)

И я очень сомневаюсь что использование лямбд сильно повлияет на производительность вашего приложения, мы не драйверы пишем)

Кстати лямбды — это не только делегаты, это еще и деревья выражений — тоже нехилая такая фича

А как бы вы покрывали тестами это в js?

Так же само и в C#

То есть писец как херово.

Классы на лету генерятся, т.е. делается то, что джавист должен делать руками)

В рантайме? Тада писец производительности!

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

И я очень сомневаюсь что использование лямбд сильно повлияет на производительность вашего приложения, мы не драйверы пишем)

Но мы и не сайтики визитки пишем :) Не так ли?

Если ваш код плотно усыпан лямбдами и под нагрузкой == колбасиву в памяти.

деревья выражений

Бегло посмотрел доку. Как оно работает? Не через рефлексию ли? Если да то закапывайте производительность. Если нет, то опишите механизм.

не сайтики визитки

если дексктоп приложение — то какая разница

если дексктоп приложение — то какая разница

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

В рантайме? Тада писец производительности!

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

В компайл конечно. Ну падение производительности сравнимо с использованием интерфейсов, рефлекшена, виртуальных функций, DI, абстракций и вообще ООП в целом) От этого не уйти. Дргое дело когда ради одной записи из базы вытягиваются все (классика жанра :)) ит.д. Вот с этим надо бороться.

Бегло посмотрел доку. Как оно работает? Не через рефлексию ли? Если да то закапывайте производительность. Если нет, то опишите механизм.

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

Ну падение производительности сравнимо с использованием интерфейсов

Какой оверхед у интерфейсов?

виртуальных функций, DI, абстракций и вообще ООП в целом)

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

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

То есть ревлексия, но с другим интерфейсом ... закапывайте (юнлинги/падаваны вам такого навояют шо огого).

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

В Вебе тормоза чаще рождаются из за неправильного понимания фич технологии.

Почитайте хоть как young gen работает уже

Почитайте хоть как young gen работает уже

Перестаньте читать и начните думать: никакое разбитие на поколения вас не спасет от того что ГЦ начал запускаться в 1.5-2 раза чаще на 16 Гб хипа.

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

Вам должно быть известно что желательно профилировать свой код. И если окажется что -server JVM (ой, или компилятор) оптимизировала функцию, то даже смысла говорить о gc или инстансах нет.

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

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

Ну если они старые, то пролезут, все норм

«ой-ой будет создан лишний объект»

Так я говорю не про один, а про 100500 в секунду, это совсем про другое.

Так же и делает и Java внутри Java 2D и Swing и функциональные ЯП.

Так же и делает и Java внутри Java 2D и Swing и функциональные ЯП.

Так теперь вейстленд2 будут на джаве писать?
Суть проста: Некий код написанный с созданием лямбд на каждый чих выполняется 10-15 минут, после простого вынесения лямбд (несколько десятков) в статик переменные 7-10 минут, алгоритм не менялся.

В чем магия?

А потом переписывается на С++ и выполняется 2 минуты.

В чем магия?

А потом переписывается на С++ и выполняется 2 минуты.

Слив засчитан.

Ваш аргумент о ускорении чего-то там — чистый слив ;)

Не через рефлексию ли? Если да то закапывайте производительность.

Самые медленные операци рефлексии — это get value, set value и create instance. Просто прочитать названия членов класса или атрибутов происходит достаточно быстро. В случае же с expression trees, прочитать выражение даже быстрее чем в случае с рефликсией. Единственная ресурсоемкая задача — это метод compile, которые переводит выражение в делегат.

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

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

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

Бугага, это касается всей внутренней логики метода безотносительно лямбды там или нет

Бугага, это касается всей внутренней логики метода безотносительно лямбды там или нет

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

Как протестировать такое:

method(p1, p2) {
lambda1 = _inline_lambda_;
lambda2 = _inline_lambda_;
lambda2(lambda1);
}

?

method(p1, p2) {
lambda1 = new Lambda1(p1); // это мокается и проверяется
lambda2 = new Lambda2(p2); // это мокается и проверяется
lambda2.call(lambda1); // это проверяется 
}

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

Выносишь лямбды в переменные класса

А ниче шо они зависят от параметров метода?

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

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

А если, например, lambda2 = list.map, то есть параметр к lambda1 добавить нельзя?

Суть в том что используя просто ООП код, для тестирования меняете только сами тесты, а при использовании лямбд, чтобы покрыть хорошо тестами надо менять код, и при этом изменении архитектура не всегда улучшится, а само удобство лямбд нивелируется. Помимо того создавая именованные классы вы улучшаете читабельность (имя класса раскрывает суть) без создания доп переменных/полей/методов.

А если, например, lambda2 = list.map, то есть параметр к lambda1 добавить нельзя?

почему это?

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

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

почему это?

Покажите как.

val lambda = (a: Int)(b: Int) = a * b
def m(a: Int, b: List<int>) = b.map(lambda(a))

Если смущает карирование, то оно тривиально реализуется через функцию:

def lambda(a: Int) = (b: Int) => a * b

Внезапно если взять for, if и while, которые составляют алгоритм, то прийдется тестировать их все в совокупности. И строчки метода тоже тестируются в совокупности

«Абизянкам надо шоб блестело, а не шоб работало.»

Вы такими фразами доказываете свою посредственность

Вы такими фразами доказываете свою посредственность

Мдя... Квадрат. Я еще и в старбаксе никогда не был. :(

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

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

Ну серьезно, думаю на форуме вы

От и прекрасненько: перешли на личности :)

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

Как тут уже писали:

лямбды «спасут отца русской революции»? Это последний шаг к мировому пожару на крыльях JVM..

Ну поскольку аргументацию вы предоставляете такую, которая указывает на неосведомленность в вопросе, я так ненавязчиво порекомендовал почитать книги. SICP, CTM would do.

я так ненавязчиво порекомендовал почитать книги. SICP, CTM would do.

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

А вы почитайте что там пишется

Не знаю как в nhibernate а в hibernate есть criteria api, который решает приблизительно те же проблемы что и linq-sql. Ну и например в скале этих SQL DSL-ей жопой жуй, например: squeryl.org/...troduction.html

Я начну воспринимать Java как альтернативу C# только с 8й версии, когда лямбды там таки появятся.

А какое отношение лямбды имеют к linq, и всяким DSL-ям?

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

ты правильно написал про «пока»

А если приложение клиент серверное, то вопрос о том, что серверная часть должна быть кроссплатформенна вообще не должен стоять.

Должен, например я когда то работал в большом банке, и их не устроила политика поддержки MS продуктов, типа win2000 и sql server 2000 задеприкейтили где то в районе 2007-2008 года, и МС пошел в пешее эротическое путешествие вместе со всем VB и C# кодом и индусами koторые его поддерживали, а бюджет на систему, департамент и т.д. распилили джава индусы, при чем джава код перенесся простым копированием джарников.

по вашей ссылке разве не скала и не лямбды?

Скала там есть(я как бы об этом и написал), а лямбд я там не вижу.

не видите или их там нет? :)

g =>
where(g.subjectId === mathId)
compute(avg(g.scoreInPercentage)
это по вашему что?

неужели вы считаете, что жава стала бы хуже, если бы там появились лямбды?

не видите или их там нет? :)
g =>
where(g.subjectId === mathId)
compute(avg(g.scoreInPercentage)

это по вашему что?

Ок, я ошибся, они там есть, и что с того?

неужели вы считаете, что жава стала бы хуже, если бы там появились лямбды?

такого я точно не говорил

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

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

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

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

Это ты что-то нафантазировал.

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

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

А остальное тоже не в тему, опендждк лежит под джпл — иди добавляй какой хочешь блекджек.

Кроссплатформенность к лямбдам отношения особого не имеет

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

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

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

никак это не следует

ну ладно. признаю, что напрямую не следует, но именно это Джава сейчас и имеет

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

Она не станет хуже, дальше некуда, но это не изменит общей игры.

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

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

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

точно так же любой синтаксический сахар ухудшает читаемость кода.

паттерн матчинг, как контраргумент — синтаксический сахар, улучшает читаемость, даже если с ним не сталкивались.

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

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

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

ну никто ведь не заставляет вас так делать

меня нет, ты это другим расскажи

А я видел умников когда пренебрегали лямбдами, 3-5 кратная вложенность циклов, куча методов т д...

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

в Джаве нет функций высших порядков?

есть через внутренние классы и танцы с интерфейсами, либо красиво через либу Functional Java

в Джаве нет функций высших порядков?

А в Ц№?
Еще раз:

Во что превращаются лямбды и делегаты на уровне ВМа?

А в Ц№?

а в c# есть.

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

ну то-есть синтаксически

При чем тут синтаксис? Функции высших порядков — это не про синтаксис.

расскажите мне что это такое.

то-есть если я передаю в функцию другую функцию, как параметр и получаю функцию — это первая функция — это не функция высшего порядка?

ты так можешь и в С сделать, с небольшими хаками))

Телепатирую: Думаю Богдан хочет сказать про внутренности, что кучи выделяемые ВМ

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

Или что-то в этом роде..

Телепатирую: Думаю Богдан хочет сказать про внутренности, что кучи выделяемые ВМ

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

можно проще — он имел ввиду closures как подвид лямбд

closures как подвид лямбд

Здаетсо мне что тут говорили про другие «лямбды». Дайте пожалуйста определение того что вы подразумеваете под лямбдами и замыканиями.

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

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

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

но хотя, возможно, вы имели ввиду что-то другое ?

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

Ерунда какая, лямбда это способ задать замыкание. И не один. Так что замыкание это не обязательно лямбда

The term closure is often mistakenly used to mean anonymous function. This is probably because most languages implementing anonymous functions allow them to form closures and programmers are usually introduced to both concepts at the same time. An anonymous function can be seen as a function literal, while a closure is a function value. These are, however, distinct concepts. A closure retains a reference to the environment at the time it was created (for example, to the current value of a local variable in the enclosing scope) while a generic anonymous function need not do this.

en.wikipedia.org/...mputer_science

попробуйте пофиксить википукию

Зачем мне ее фиксить если она мне не противоречит?

An anonymous function can be seen as a function literal, while a closure is a function value.

А как вы это прочитали? Я так:
Анонимная функция — это синтаксическая конструкция, замыкание —семантическая.

Ибо это определение не совпадает с:

лямбда это анонимная функция

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

Так что замыкание это не обязательно лямбда

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

то-есть если я передаю в функцию другую функцию, как параметр и получаю функцию — это первая функция — это не функция высшего порядка?

Я такого не говорил.

расскажите мне что это такое.

Функция которая принимает и/или возвращает другую функцию. (если просто)

Но это не отменяет того факта что синтаксис тут не причем.

Так препираться можно долго...

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

так может быть всё процедурно писать и вообще отбросить такой синтаксический сахар, как ООП, а то у бедных ньюкамеров голова лопнет

Очень даже, а потом переходить на ФП и декларативное программирование с ростом опыта.

ООП вообще зло,особенно как оно реализовано в 90% случаев. Бедный Алан не знал, что все будет так плохо.

Очень даже, а потом переходить на ФП

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

Так я и не против лямбд =), я против их некорректного использования, когда человека ломает выделить в функцию и он начинает писать анонимной функцией довольно сложную логику. Я много работаю с Haskell и есть несколько либ где так делают, по непонятным для меня причинам, видимо думают, что тот кто использует должен разбираться идеально в их коде.

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

Все хорошо, но есть IO, где царит наглая процедурщина и мир ФП там не существует.

ну вот мы и пришли к тому, что лямбды — это хорошо.

много всего хорошего можно плохо использовать, однако не стоит из-за этого отказываться от этого

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

ну так и нет никаких геймченджеров. всё как приятное дополнение

Linq to NHibernate тоже есть, только им пренебрегают. Linq парсится в лямбды вот и всё отношение.

Linq парсится в лямбды вот и всё отношение.

это где ты такое вычитал?

В методы расширеня с лямбда выражениями для IEnumerable или деревья выражений так понятнее??

И где там про «Linq парсится в лямбды»?

Query expressions. These are expressions like this:
from person in people
where person.Age < 18

select person.Name

These are translated by the C# compiler into “normal” C# 3.0 (i.e. a form which doesn’t use query expressions). Overload resolution etc is applied afterwards, which is absolutely key to being able to use the same query syntax with multiple data types, without the compiler having any knowledge of types such as Queryable. The above expression would be translated into:
people.Where(person => person.Age < 18)

.Select(person => person.Name)

Там с низу другой пример совсем есть:

var q = from x in dc.mytable select x;
IQueryable<tbl_dir_office> q = dc.mytable.Select<tbl_dir_office, tbl_dir_office="">( Expression.Lambda<func<mytable, mytable="">>( exp = Expression.Parameter(typeof(mytable), "x"), new ParameterExpression[] { exp } ) );
Я думаю, тот ответ, у когрого +31 правильнее :)

я уже писал что

В методы расширеня с лямбда выражениями для IEnumerable или деревья выражений

Т.е. зависит от контекста.

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

Я думаю, тот ответ, у когрого +31 правильнее :)

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

Т.е. зависит от контекста.

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

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

Ты дотнетчик? Спорить не надоело?
Прочитай первый абзац

http://msdn.microsoft.com/en-us/library/bb397947.aspx

И че, там где-то написано что «Linq парсится в лямбды»? Самому то не надоело отстаивать столь нелепые фантазии?

Вообще то синтаксис Линка — действительно надслойка над лямбдами.

var result = from a in ar where a > 0 select a * a;

идентично

var result = ar.Where(a => a > 0).Select(a => a * a);

И идентично куску кода который я вывесил выше, т.к. лямбды это всего лишь синтаксический сахар. Вопрос в том на деле «парсится» ли linq в лямбды?

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

Но я поверю что они могли

var result = from a in ar where a > 0 select a * a;

сконвертировать в

var result = ar.queryID(1324224).Where(a => a > 0).Select(a => a * a);

Осталось только выяснить реально ли конвертируют и зачем такое делать

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

Лямбды не вычисляются, они транслируются в обычные анонимные функции, т.е. с лямбдами преобразования получаются: linq -> lambda -> functions, без лямбд linq -> functions. Вопрос, зачем лишнее преобразование. Я уж не говорю что при LINQ -> SQL произвольную лямбду вообще распарсить и замапить непростая проблема.

А вы об этом... Ну это наверное не принципиально. Суть в том что зашить туда SQL они не могут, потому что он может быть создан runtime only, когда будет известен источник данных. Им нужна промежуточная форма, возможно с ключем кеша. Может для унификации они это сделали через лямбды, потому что потом только для них можно писать реализацию

Наверное потому что linq -> lambda сделать проще чем linq -> functions. А преобразование lambda -> functions к тому времени уже было реализовано. Декомпилированный код смотреть нет смысла ибо он отображает конечный результат без промежуточного.

Дык а с чего ты взял что linq напрямую в функции обязательно преобразовывать? Если бы я все это писал то там бы был промежуточный AST слой, в который преобразовываются как лямбды, так и linq и анонимные функции, который не выразим в Ц# коде, и linq логичнее преобразовывать напрямую в него чем в другое строковое представление которым являются лямбды.

Можно и так, надо у MS спрашивать. Я думаю сначала полностью реализовали лямбды, затем LINQ. Причем LINQ должен был бы быть полностью совместим с лямбдами. Поэтому для достижения 100% гарантии, что скомпилирвоанный код одинаков, решили парсить одно в другое. В противном случае была бы вероятность расхождения.

Поэтому для достижения 100% гарантии, что скомпилирвоанный код одинаков, решили парсить одно в другое

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

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

Это откуда и какие расхождения

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

Доказательства я уже привел, теперь пытаюсь объяснить «зачем» — но чувствую в твоем случае это бесполезная трата времени

Да, с такими «доказательствами» и «обьяснениями» действительно бесполезная

Написал мелкую програмку:

class Program
{
static void Main(string[] args)
{
int[] array = { −2, −1 , 0, 1, 2};
var result = from a in array where a > 0 select a * a;
result = array.Where( a => a > 0).Select(a => a * a);
}

}

Скомпилировал и разобрал:

private static void Main(string[] args)
{
int[] array = new int[] { −2, −1, 0, 1, 2 };
IEnumerable<int> result = from a in array
where a > 0
select a * a;
result = from a in array
where a > 0
select a * a;

}

Вывод: таки да — декомпелированный код с Линка и лямбд одинаков.

Nhibernate

Ну да, все дотнетчикам неймется. NHibernate, NAnt

А что такого? Хороший опыт надо перенимать и распостранять.

Это как раз пример того что выше писали. Все джависты идут по пути — если нет в джаве, значит не нужно.

Да, да, а в шарп уже давно добавили checked exceptions.

на уровне языка нет, но есть Querydsl и jOOQ (аналог LINQ к SQL)

на уровне языка нет, но есть Querydsl и jOOQ (аналог LINQ к SQL)
Абизянке пофик как оно работает, для абизянки главная ценность шоб блестело.

Слабувато «вбросив», два рази повторив. Дивись, заберуть «зеленого язика» важкою працею заробленого! )

Слабувато «вбросив», два рази повторив.

А это был не вброс, как не странно. Скорее крик души.

Дивись, заберуть «зеленого язика» важкою працею заробленого! )

А его не за троллинг дают, а как «наказание неугодным пользователям».

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

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

Тiльки москаль працює на Паскаль!

Паскаль интересный язык, кстати. Вроде и низкоуровневый как Си, а с другой стороны понятный как Шарп. Жалко, что слабо распространён.

Простите за оффтоп.

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

Си я тоже пробовал. Ничем не лучше.

И скучаете по Паскалю?

Синтаксически Шарп практически идентичен Джаве, от Паскаля там кроме эвентов и не осталось ничего.

На шарпе я тоже кодил, так что в курсе.

Нет, по Паскалю не скучаю, просто жалко, что технология не распространена.

У вас какая то странная логика.

Вроде и низкоуровневый как Си, а с другой стороны понятный как Шарп.
Отсюда вывод, что Шарп понятнее Си. А чем? Он основан на сишном синтаксисе, а ни разу не на Паскалевском. Что в Шарпе и Паскале общего, чего нет в Си++, что при этом делает его понятнее?
Нет, по Паскалю не скучаю, просто жалко, что технология не распространена.
Да слава Ктулху, что не распостранена. Неудобный и многословный язык.
Отсюда вывод, что Шарп понятнее Си

А разве это не аксиома? Или в шарп порог входа выше, чем в Си++?

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

Примеры?

А разве это не аксиома? Или в шарп порог входа выше, чем в Си++?
Примерно такой же. Шарп унаследовал большую часть низкоуровневых возможностей и добавил своих высокоуровневых. Плюс фреймвёрки.

Вы так и не ответили:

Он основан на сишном синтаксисе, а ни разу не на Паскалевском. Что в Шарпе и Паскале общего, чего нет в Си++, что при этом делает его понятнее?
Примеры?
Любите писать begin и end вместо { и }? О, или веселее: сделайте цикл с не единичным шагом. Хотя нет, совсем весело, выделите память под трёхмерный массив в куче.
Любите писать begin и end вместо { и }?

Бида, бида руки повыкручивали, демоны.

сделайте цикл с не единичным шагом.

Через while.

Бида, бида руки повыкручивали, демоны.
Ага. И такого там много.
Через while.
Даже для примитивнейшей операции нужен костыль.
Вы так и не ответили:
Он основан на сишном синтаксисе, а ни разу не на Паскалевском. Что в Шарпе и Паскале общего, чего нет в Си++, что при этом делает его понятнее?
Что в Шарпе и Паскале общего, чего нет в Си++, что при этом делает его понятнее?

Я не говорил, что синктаксис Паскаля схож синтаксисом С#.

А касательно сложности —
for(;P("\n").R-;P("\ "))for(e=3DC;e-;P("_ "+(*u++/8)%2))P("| "+ (*u/4)%2);
Напиши на Паскале.

Я не говорил, что синктаксис Паскаля схож синтаксисом С#.
И что же в них похожего, что делает их одинаково понятными?
А касательно сложности —
for(;P("\n").R-;P("\ "))for(e=3DC;e-;P("_ "+(*u++/8)%2))P("| "+ (*u/4)%2);
Напиши на Паскале.
Не напишу. Кстати, на Си так не пишут. А ещё это древний баян. Попробуй придумать реалистичный пример.
Кстати, на Си так не пишут.

То есть так на Си написать нельзя?

Можно. Так просто никто не делает. Это высосал из пальца опытный (потому что джун такое не сообразит) С — программист. Думаете эзотерический код нельзя написать на том же Шарпе? Тогда попробуйте каррировать метод с 5 аргументами лямбдами.

Я не говорил, что синктаксис Паскаля схож синтаксисом С#.
И что же в них похожего, что делает их одинаково понятными?
(потому что джун такое не сообразит)

То есть ну совсем на плюсах ховнокода нет? И все возможные легаси цветут и пахнут?

Думаете эзотерический код нельзя написать на том же Шарпе?

Можно, но его там на порядки меньше, почему то...

И что же в них похожего, что делает их одинаково понятными?

Понятными по сравнению с плюсами? Например, работа со строками.

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

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

Пример?

Паскаль:
a := ’Balden’;
b := a;
b := b + a;

Си:
//Так нельзя
char a[7];
a="Balden";

//a не константна, хз что будет
char* a;
a="Hello";
a[1]=’u’;

//b указывает на туже строку, что и а, это ни разу не копия
const char* a, b;
a="Hello";
b=a;

//Нельзя, конкатенация только через функцию
char a[4]="Bal";
char b[3]="den";
char* str;
str=a+b;

По моему Паскаль понятнее.

Если бибизянкам сложнее написать что либо нечитаемое на языке, то это явно достоинство.
Сложнее одно слово написать? Просто анменеджит в популярных учебниках расматриваются сжато, а до Рихтера и тематический статей обезьянки не доходят. А так там можно применить практически полный набор С++ возможностей, хоть указатели, хоть объекты в стек.

Касательно примера — в C — да, а в С++ есть класс string, где конкатинация выглядит почти так же.

а в С++ есть класс string, где крнкатинация выглядит почти так же

Даже для такой примитивной операции пришлось ваять костыль ©.

Ну вот, я и говорю Паскаль легче и понятнее Си++, в работе со строками как минимум.

Даже для такой примитивной операции пришлось ваять костыль ©.
Ерунду говорите. Это не костыль, а тип, используемый по прямому назначению. Выходит ничем Паскаль не приятнее в работе со строками. Ещё примеры?
Выходит ничем Паскаль не приятнее в работе со строками.

Да ну как сказать...

В Паскале стринг — это нативный тип.

А в Си класс стринг — это левая библиотека, которую надо подключать, это не говоря уже о том, что для него есть куча аналогов.

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

В общем для меня Паскаль изучать было на порядок легче, чем Си.

А в Си класс стринг — это левая библиотека, которую надо подключать, это не говоря уже о том, что для него есть куча аналогов.

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

#inculde <string.h>
Таки сложно добраться до этого класса, таки сложно.
А в C# строки, кстати, не нативный тип. Нужно ещё
System.String; Ничего не напоминает?
В общем для меня Паскаль изучать было на порядок легче, чем Си.
В С строки сложнее, но уже в С++ - нет. Да и причём тут изучение. Речь о массовом использовании.

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

А в C# строки, кстати, не нативный тип.

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

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

В си++ такого нет ниразу, куча кода, где строк нет и куча альтернатив, непонятно когда, непонятно кем написанных, разные под каждую платформу, которые дают какой то объект для работы со строками.
Есть. Класс string входит в спецификации C++, а значит является его неотъемлемой частью. А то, что со строками по прежнему можно работать указателями — это уже не проблема плюсов. В Паскале, по мойму, тоже можно.
А то, что со строками по прежнему можно работать указателями — это уже не проблема плюсов.

Эта не проблема, эта — принцип. Тем не менее, одна из первых вещей, которую начинают изучать в си++ - это работа с массивами чаров и как легко там отстрелить себе ноги. Ибо совместимость с Си.
А потом дадут string.

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

Так мы же не об обучении говорим, а о практическом применении. А уж там строки у С++ и Паскаля практически идентичны.

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

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

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

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

Так человек жалеет, что Паскаль — малораспостранённая технология. Меня после пары лет Дельфи это коробит.

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

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

Я не говорил, что Паскаль мощнее.

Я говорил, что Паскаль проще. Как и дотнет, кстати.

И что есть главная массовая технология?

Я говорил, что Паскаль проще. Как и дотнет, кстати.
А я пока не услышал ни одного аргумента, чем он проще. Отсутствием сложных конструкций? Не пойдёт, потому как простые конструкции в С++ таки присутвуют, никто не заставляет работать со строкой как с массивом чаров. Тоже самое относится и к C#.
И что есть главная массовая технология?
Ну это я не подумав написал. Я имею в виду, что Паскаль никоем образом не подходит для решения распостранённых задач больше, чем любой из языков, которые сейчас широко используются. Зато по многим факторам он подходит меньше, или вообще не подходит.
решения распостранённых задач

Для ентерпрайза мог бы не хуже С#.

простые конструкции в С++ таки присутвуют, никто не заставляет работать со строкой как с массивом чаров

Ага, никто не заставляет. Теперь, скажи, что никто не работает.

Возможность есть, значит будут использовать. И не могло её не быть, ведь язык разрабатывали как Си с классами. Это не есть плохо, но как бы для высокоуровневых задач не совсем то.

И вообще скрестили ужа с ежом.
Либо у вас низкоуровневый Си для низкоуровневых задач, либо что то высокоуровневое для высокоуровневых задач — типа джава, дотнет, питон и т п, без таких возможностей отстрела ног.

А я пока не услышал ни одного аргумента, чем он проще.

Ну расскажи, тогда, почему он сложнее. Скобочки писать нельзя? В питоне так вообще — пробелы, но он не стает от этого более неудобным, чем си++. Такие элементы вообще через иде настраиваются. Циклы с шагом? Если нужно можно реализовать. А фор ич так там есть.

Для ентерпрайза мог бы не хуже С#.
У него от силы треть возможностей Шарпа. Собственно Шарп его с виндового дектопа то и спихнул.
Возможность есть, значит будут использовать.
Анменеджит используют? А он есть!
Либо у вас низкоуровневый Си для низкоуровневых задач, либо что то высокоуровневое для высокоуровневых задач — типа джава, дотнет, питон и т п, без таких возможностей отстрела ног.
С — процедурный. Низкоуровневрость задачи не отменяет полезности ООП.
Ну расскажи, тогда, почему он сложнее.
Да не сложнее. Пока ты используешь С++ как С с классами Паскаль (кстати, он с некоторых пор оффициально переименован в Дельфи) такой же. Но с уродливым многословным синтаксисом и костылями, вместо простейших операций.
Но с уродливым многословным синтаксисом

Хоспаде, сколько внимания камим то драным скобочкам.

и костылями, вместо простейших операций.

Ну, примеры? Только, что нибуть не такое неоднозначное, чем паскалевский фор.

У него от силы треть возможностей Шарпа.

Ну не всем подфартило быть придуманными майкрософт.

В конце концов сколько денег вложили в развитие шарпа? И когда его придумали.

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

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

С — процедурный. Низкоуровневрость задачи не отменяет полезности ООП.

Не отменяет. Только на низком уровне ООП как бы ни к чему.

Хоспаде, сколько внимания камим то драным скобочкам.
Там всё излишне многословно program, procedure, function, begin, end etc.
Ну, примеры? Только, что нибуть не такое неоднозначное, чем паскалевский фор.
Ступенчатый массив например.
Не отменяет. Только на низком уровне ООП как бы ни к чему.
Смотря насколько уровень низкий.
Ну не всем подфартило быть придуманными майкрософт.
Погуглите кто такой Хейлсберг, и что он придумал (как в составе Майкрософта, так и до него)
В конце концов сколько денег вложили в развитие шарпа? И когда его придумали.
И чего? Это не отменяет убогости Паскаля относительно Шарпа и Плюсов.
Я ж не говорю, что сейчас надо все проекты писать на Паскале.
Я сказал — жаль, что он не распространнен.
А я не понимаю, почему жаль и кому сейчас он нафиг нужен, с его корявым синтаксисом и покоцанными возможностями.
И как на УГ, полного многословия и костылей, у Паскаля как то слишком долгий срок жизни — он ведь сейчас жив, и на дотнете есть кстати.
Так и Фортран жив, не смотря на ужасающий синтаксис и тучу недостатков. И COBOL тоже жив. А на .net реализованны почти все языки, включая brainfuck. Не показатель.
Там всё излишне многословно program, procedure, function, begin, end etc.

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

В конце концов такое должно решатся контекстным подсказчиком.

Ты полчаса будешь думать, что написать. А потом полтора отлаживать. 5 минут за кот ты все это наберешь они имеют значение?

Так и Фортран жив, не смотря на ужасающий синтаксис и тучу недостатков. И COBOL тоже жив.

Фортран — то страшная вундервафля для гиков, не в тему тут.

Кобол — по тиобе 24 место, а Паскаль — 14, сразу за Лиспом и Руби.
Делфи ХЕ3, кстати 4 месяца назад вышла.

Погуглите кто такой Хейлсберг, и что он придумал (как в составе Майкрософта, так и до него)

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

Ступенчатый массив например.

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

И чего? Это не отменяет убогости Паскаля относительно Шарпа и Плюсов.

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

Анменеджит используют? А он есть!

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

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

А работа с массивами чаров через указатели — это предложение поиграть в футбол на минном поле. Не буш играть — в падаваны не возьмут.

это предложение поиграть в футбол на минном поле
Всегда найдутся те которые считают что в возможность в сишарпе юзать анменеджент код это ок
Всегда найдутся те которые считают что в возможность в сишарпе юзать анменеджент код это ок
Я таких не встречал. Неуправляемые С++ длл подключать в анменеджит — это было, но указателей в Шарповых программах на моей памяти нет.
Хорошо, многословно. ... они имеют значение?
Имеют. Раз пять минут, два пяти минут, сто пять минут. К тому же, не все проектируют до такой степени, что бы оставалось только закодировать.
Фортран — то страшная вундервафля для гиков, не в тему тут.
Фигасе, один из самых популярных высокоуровневых языков (в прошлом) вундервафля для гиков. Ржунимагу.
Делфи ХЕ3, кстати 4 месяца назад вышла.
Новый Фортран тоже недавно вышел, не показатель.
И вот только не надо сейчас про убогие костыли ... есть написанный и отлаженный.
По мне так это вполне примитивная структура. С кучей Паскаль тоже работает «интересно». Трёхмерный массив в куче размещали? Это весело.
Ну, дык если бы Майкрософт не хотела свою джаву, сейчас в Паскале могло бы быть все то чего тебе так не хватает. Возможности шарпа как минимум.
Но Майкрософт захотела свою Джаву, хотя был Паскаль. Более того, они предпочли начать с нуля, когда J++ засудили, хотя могли бы взять тот же Паскаль (его то можно модифицировать как душе угодно). И это уже показатель.
Имеют. Раз пять минут, два пяти минут, сто пять минут. К тому же, не все проектируют до такой степени, что бы оставалось только закодировать.

У меня почему набор и перенабор проги занимает меньшую часть рабочего дня.

И вообще все предъявы к внешнему виду синтаксиса (не к возможностям языка) — это вкусовщина.

Фигасе, один из самых популярных высокоуровневых языков (в прошлом) вундервафля для гиков. Ржунимагу.

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

Но Майкрософт захотела свою Джаву, хотя был Паскаль. Более того, они предпочли начать с нуля, когда J++ засудили, хотя могли бы взять тот же Паскаль (его то можно модифицировать как душе угодно). И это уже показатель.

Они не предпочли начать с нуля. Они предпочли взять J++ и переделать.

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

По мне так это вполне премитивная структура.

Решение через массив указателей тоже вполне примитивно. По мне.

С кучей Паскаль тоже работает «интересно». Трёхмерный массив в куче размещали?

А что с ним? И по сравнению с Си?И нах оно надо?

Фортран создавался для расчетов. И когда он вышел программирование было уделов гиков.
Какая разница, для чего создавался. Главное, что был языком общего назначения. И нет, когда он вышел — программироване было прерогативой высококлассных инжененров/учёных.
Они не предпочли начать с нуля. Они предпочли взять J++ и переделать.
С++ они переделывали. Потому как C# в итоге потерял пару полезных возможностей JAVA и сохранил несколько полезных и вредных возможностей С++.
И то что создавал язык батька Делфи, безусловно никаким показателем не является...
Является батька Дельфи дал Дельфи от ворот поворот, и использовал как основу её главного конкурента.
А что с ним? И по сравнению с Си?И нах оно надо?
А вы попробуйте, это нетривиально.
Вот за что я люблю джаву, так это за то, что из нее не делают монстра.
Не надо трогать ни язык ни платформу.

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

джаву

что из нее не делают монстра

o_O

Куча, куча квадратиков!

Не нашел ничего из этого, что Java при добавлении нормального набора библиотек (которых на Java дохрена и больше) не умеет. Разве что построение десктопных приложений под Win8. Но это в наше время никого не волнует особенно.

Никто не будет писать десктопные приложения на Java, так же, как, например, проектировать распределенные вычислительные системы не на Hadoop или MPI.

Никто не будет писать десктопные приложения на Java

а мы пишем, кстати

У нас вообще discontinued фреймворк — Spring RCP+Swing

Пока MS не сделает .NET кроссплатформенным (не надо про Mono, серьезные компании не доверяли и не будет ему доверять), успех .NET будет полностью зависеть только от успеха платформы MS и остальных продуктов MS. А не от фич, крути, и прочая.

В разработке ПО давно(по меркам ИТотрасли) рулят не математики, не инженеры, а обычные такие экономические и бизнесовые законы.

Тоже и с разговорами о «сортировке», «медленнее в 12 раз»

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

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

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

По Си же как-то Зубинский прошелся:
О величии, могуществе, ужасе и мелочах

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

Насчет .Net согласен- все напрямую зависит от Микрософта. Очень сильная зависимость от платформы. И это самый огромный минус этой платформы перечеркивающий все плюсы и удобства.
Насчет производительности- категорично не согласен. Как я уже говорил, все засит от поставленных задач и средств. Не UI-ем единым живём мы.
Не в языках дело, дело в реализации компилятора под необходимую платформу- и выходном коде, который мы получаем.
И согласитесь если смаштабировать задачу скажем некоего веб сервиса которому для работы необходимо 200 .Net/Java серверов или же 20 серверов работающих на нативным коде — разница существенная

Это просто пример для понимая разницы.

И согласитесь если смаштабировать задачу скажем некоего веб сервиса которому для работы необходимо 200 .Net/Java серверов или же 20 серверов работающих на нативным коде — разница существенная
если стоимость разработки и эксплуатации ПО этих 200 серверов плюс стоимость железа меньше аналогичного нативного кода для 20 серверов
победят 200 серверов .Net/Java
Не в языках дело, дело в реализации компилятора под необходимую платформу- и выходном коде
согласен.
для эмбэдэд решений... и Micro .NET может сыграть :)
вот только стоимость лицензий — очень в минус.

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

Вообщем сказывается еще то, что опенсорс как бы то ни было дружит против MS. У них нет никаких постоянноклепающих Apache, Eclipse foundations или Spring Source. Они постоянно вместе с гугл исподтишка просто закидывают шапками

Пока MS не сделает .NET кроссплатформенным

а зачем? кому это нужно?

давайте не путать
условие наступления какого-то события
и
цели, задачи — поведение агентов участвующих(или могущих участвовать) в создании этого события

вы же когда пишите оператор
if
не ставите вопрос — а какому объекту нужно это условие?

Мечтайте дальше ;-) Для MS-а кроссплатформенность это захват 100% рынка. ;-)

вы телепат, откуда знаете о чем мечтаю? ;)
по моему это вы мечтаете, о 100% захвате рынка MS, если случится указанное событие.
в MS вот только почему-то не хотят 100%го захвата ;)
странные они там.

мне то без разницы, Java или C#, JVM или CLR .NET

Кто такой Зубинский? Он в курсе что на си написаны все более менее качественные продукты от Юникса, Виндовса итп до тех же самых виртуальных машин CLR и JVM?

Последнее время, смотря на то, как развиваются инструменты разработчика- меня все больше и больше волнует вопрос- ЗАЧЕМ? зачем создать настолько «тяжелые» платформы и средства разработки? Чем занимаются разработчики .Net последние 10 лет? Правильно, пытаются успеть выучить или хотябы ознакомиться с новой фичей/фреймворком. Т.е. постоянно в погоне за новыми фичами. В итоге получается учится фичам ради учебы. Насчет Java — все вышеописанное но в намного меньшей степени. Что имеем в итоге? В итоге- огромное количество абстракции, неэффективный исполняемый код, практически полная не переносимость между платформами(в случае с .NET. Mono не в счет). И что самое интересное- армия разработчиков способных в основном формочки шлёпать пытаясь применить новые фичи.

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

Но с другой стороны:
Низкая производительность кода. На днях проводил сравнительное тестирование числодробилок (быстрая сортировка большого объема данных), обработка сигналов. на .Net и С
Разница разительна- управляемый код минимум в 12 раз медленней работает чем неуправляемый.
Потребление ресурсов. Аналогично, управляемому коду требуется намного больше памяти/процессорного времени(что вполнее понятно)
Переносимость.
Портировать .Net на мобильную платформу, андроид например... появляется некий зуд. Конечно покупаем ксамарин- и это нас впринципе должно спасти...но проверить это сложно.

Портирование Си кода делается штатными средствами с небольшими изменения.

На курсах по алгоритмам люди выкладывали свои результаты на разных ЯП. Всякие эзотерические языки сильно тупили, т.е. если решение укладывалось в 100-200 миллисекунд, там там решение занимали секунды, а то и десятки секунд. Но что меня удивило, мэйнстримовые (вроде Java) были раза в 2 (максимум) медленнее, чем С или С++. Конечно, были «таланты», которые на С++ умудрялись писать код, который работал медленнее чем решение на пайтоне, но для себя я сделал вывод что Java и C# не критично медленнее чем С и С++, а синтаксис их проще и приятнее чем С (и тем более С++).

Портирование Си кода делается штатными средствами с небольшими изменения.

Вы делаете мне смешно.

Синтаксис C#/Java подкупает своей простотой бесспорно. Мне очень импонируют C#/Java своей простотой, и когда нужно делать какой либо UI или вебсервис/ вебприложение- выбор очевиден. В моём случае это будет .Net — т.к. я намного больше работал с этим фреймворком, чем с Java. Хотя Java тоже нравится.

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

Вы делаете мне смешно.
Это же отлично, значит Вы знаете намного лучше и больше меня в этом направлении, и мне стоит на что то обратить внимание в портировании Си кода на мобильные платформы. =)
Синтаксис C#/Java подкупает своей простотой бесспорно.
Да какой у них свой синтаксис? Их синтаксис идет от Си++ с его {} class и тп,, у они у всех идет разделение операций ; можно объявлять методы void, int , string, какой у них разный синтаксис?
а синтаксис их проще и приятнее чем С (и тем более С++).
чо за бред ява в основе своей использует синтаксис си++
но для себя я сделал вывод что Java и C# не критично медленнее чем С и С++
да так некритично процентов на 100% как минимум(про яву) в вычислениях с плавающей точкой + в разы большее потребление оперативной памяти, но это конечно же мелочи

А что там у явы с вычислениями с плавающей точкой? Мне думается там идентичный С+±ному машинный код генерируется.

А сам пробовал? Код можно посмотреть?

С++: #include “stdafx.h”
#include <math.h>
#include <iostream>
#include <conio.h>

int _tmain(int argc, _TCHAR* argv[])
{ double result=0;
for (double i=1; i<100000000; i++)
{

result += log10(i*i-cos(i));


}
std::cout<<"Finish"<<result; char="" p;="" std::cin="">>p;
return 0;
}

9 сек у Си++ против 1 минуты на явакода
public static void main(String[] args) {
// TODO code application logic here

double result=0;
System.out.println("start");
for (double i=1; i<100000000; i++)
{

result += Math.log10(i*i-Math.cos(i));


}

System.out.println(result);

}
}

Это все ерунда, там проблема не в вычислениях с плавающей точкой а в разных реализациях тригонометрических функций. В джаве они в какой то момент сделали их значительно медленнее но при этом уменьшив погрешность: bugs.sun.com/...?bug_id=4857011
В любом случае вся тригонометрия в джаве заимплементирована на си, так что к топику это имеет перпендикулярное отношение.

Ты неизличим, поэтому такие как ты пишут приложения которые работает в 100500 раз медленее сишных, и мнепофигу что там сделали в сане и считает она все равно МЕДЛЕННО, сегодня еще сделаю тесты с сортировкой массивов на яве и си++

ы неизличим, поэтому такие как ты пишут приложения которые работает в 100500 раз медленее сишных, и мнепофигу что там сделали в сане и считает она все равно МЕДЛЕННО,
бла-бла-бла-бла
сегодня еще сделаю тесты с сортировкой массивов на яве и си++
Казалось бы, при чем здесь вычисления с плавающей точкой.

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

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

А ява уже применяеться в геймдеве ?

ахахахха интересно на это посмотреть, сколько фпс будет выдавать в 3Д шутере=)

Ну если майнкрафт считать 3-д шутером, то вполне сносно ;-)

Гавно этот ваш кризис. Никакого удовольствия.

аххахаха, потому что он на си++ написан?)

Да хоть шестеренками запаян.

И сколько тысяч синусов в секунду там нужно считать ?

Ну вам виднее (скорее наверное Роману), вы ж у нас хакир, и знаете математику. Вот прикинте, сколько синусов косинусов, и прочих арктангенс2 в сикунду нужно посчитать... например в энгрибердсах. И ударит ли оно по производительности если енгрибердс на яве написать.

Дык энгри бердс даже на джава скрипте работает: chrome.angrybirds.com

Без понятия так как не причастен к казуальному геймдеву

каких тысяч? миллионы в секунду не хотел, для нормального разрешения 1920*1080 и фпс 60 ? при таких параметрах требуется отрисовка 128 миллионов пикселей в секунду

каких тысяч? миллионы в секунду не хотел, для нормального разрешения 1920*1080 и фпс 60 ? при таких параметрах требуется отрисовка 128 миллионов пикселей в секунду
Для энгри бердс ?
Ты случайно не лид девелопер в одной хорошо известной компании со штаб квартирой в нью йорке ?

вообще то я про нормальный шутер: т.е. про крайзис 2

Кризис 2 — это не нормальный шутер, а продукт жизнидеятельности Крайтек.

Крайзис это просто огромный бенчмарк и ничего больше

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

Да нет же, про дотнет. Что вы как маленький...

Та я знаю, я просто пошутить хотел :(

А, ну тогда значит все ок!

ужасную вещь вы тут пишете.

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

А как на счет VS 2012 против Eclipse Juno ? :D

Ты цену предлагаешь сравнить?

Навороты , красотень и рюшечки

А как насчет VS против Idea? Напомню что всякие решарперы и ассист икс разработаны в JetBrains а не MS.

Assist X разработан Tomato Software но по существу Вы правы. VS без R#/Assist X неюзабельна по определению.

нормально ВС юзабельна и сама по себе, но ефект привыкания к более забористой траве никто не отменял, вот и появляется похмелье без решарпера...

VS за столько лет и версий так и не смогла свой intellisense заставить работать по человечески.

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

Eclipse превращается в монстра, хотя реально полезных фич я для себя много лет не нахожу, а багов всё так же много.
А в чем монструозность именно заключается? В самом эклипсе фичи не нужны, его главная цель предоставить хорошую платформу, а плагины уже допишутся сторонними разработчиками.

я имею в виду, что те фичи, которыми я пользуюсь, от версии к версии всё тяжелее и тяжелее

Что значит тяжелее? Помоему с переходом с 3 на 4 еклипс как раз пошустрее стал..

Все ошибки Eclipse легко исправляются переходом на IDEA

Holy war detected :)

ПС: Спалюю квиток в київ на JavaDay і панічно шукаю курси C#

Как говорится — настолько толсто, что даже тонко =)

А конкретно что не понравилось?

Я, кстати, это феерическое видео Мартина умудрился пропустить.

он прото, а не мета )

О, 23-летний синьёр програмящий на хаскеле, кложе, груви, го и никогда не деплоящий ошибок в продакшн подтянулся

че это я 23х летный?!!! уже только «цацкель», кложа уехала к другому разрабу, а на груви я писал раньше, но я тоже рад тебя читать...))

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

А под какое у тебя настроение сегодня? Давай пусть будет Ocaml =)

К счастью для тебя в области окамла я тебя в звиздеже вряд ли подловлю.

Вот незадача, самое я обидное я ж сам себя тоже не подловлю, последняя надежда на тебя была. Изъяны в суждениях выявить.

Не переживай, ты не одинок, таких как ты в интернетах много бродит.

На фрилансе недавно нужно был на беляш переделать, что не так?

Cи- наше всё. =)

Тiльки москаль працює на Паскаль! А ми усi працюємо на C!

Подписаться на комментарии