И в гугле.

wicket?

И в гугле.

Ну это само собой. Гугль вообще молодцы. Все что они делают под Java можно брать и использовать.

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

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

А школоло вроде публики с лора быдлокодят на «стандартных решениях» и кричат про неприменимость лиспа (CL), так как там видите ли нету батареек.

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

Vaadin

> Да, хотелось бы перевод. На слух американский не ловлю. :(

suckers...

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

С нуля?

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

Спасибо за рассказ.

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

Гослинг, конечно, утрировал в том смысле, что Ораклу без явы, конечно,не крышка - но завязаны они на неё крепко. Другое дело, что Ларри - человек упёртый (что, кстати, опровергает мнение некоторых аналитиков, что упёртыми бывают исключительно «красноглазики»), и если он твёрдо решит выпилить яву отовсюду - он это сделает, не считаясь убытками. Но я всё же надеюсь, что до такого маразма он ещё не дошёл.

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

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

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

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

Можно ссылочку?

«Велосипеды» - это и есть что-то новое и полезное.

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

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

На конференциях «форум технологий mail.ru» и «yet another conference (yandex)» рассказывали. Поищи видеозаписи.

А прикладной софт полезен только тому, кто его продает.

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

Этот пример можно отобразить на MVC, где A - view, а B - model.

отобрази

особенно интересно, чем будет там класс С

пока что видно лишь плохое проектирование

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

class Animal { public: void copulate(Self another_animal); };

> будет сплош и рядом ms да .net либо много-много форков jre и jdk

.net уже две несовместимых версии - M$.NET и mono. а jdk пока ещё совместимы при переходе *от любой к любой другой*, кроме багов.

> Да не нужен state.

continuation-based фреймворки смотрят на вас как на ...

Это я смотрю на continauation-based фреймоворки как на гавно. Ты думаешь, что если на лиспе (call/cc), так сразу святое? Спроси у archimaga он вроде больше в теме. И в его restas я этого state-говна не видел.

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

Свободная неформальная речь допускает индуктивные заключения. Или ты привык, что все говорят как роботы? Вылазий из своего мирка, и расскажи как твой высер доказывает полезность continuanion-based фреймворков. Свой пойнт я повторю:

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

>«Велосипеды» - это и есть что-то новое и полезное.

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

Во-вторых, я в корне не согласен с твоим утверждением. «Велосипед» на то и называется велосипедом, что делает именно то, что уже существовало и было изобретено до него.
Классический пример в ПО - это лицензионные ограничения. Скажем, существует проприетарная контора, которая хочет добавить с свой продукт некий функционал. И так уж получилось, что до неё уже написана свободная библиотека, реализующая задумку. И GPL не позволяет конторе использовать библиотеку, что вынуждает её на разработку идентичной, но своей, закрытой версии. Тут нет никакого новаторства и полезен результат будет для предельно ограниченного круга лиц (владельцев компании).
Новаторство же за очень редким исключением основывается на уже существующем базисе. Если вернуться к велосипедам, то, скажем, пришла идея дяде Васе приделать в велосипед двигатель. Он купил в магазине готовую конструкцию, «наложил патч двигателя» и появился новый класс транспорта. И вовсе не обязательно для этого было «переписывать» колёса, руль, цепь, сидушку и т.д.
Т.е. как вывод из всего выше, никакой твоей «нужности» в написании велосипедов нет. Новатору гораздо больше пригодятся навыки умения разбираться в чужом коде и применять одни технологии к другим.

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

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

Классический пример в ПО - это лицензионные ограничения.

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

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

Ну дык готовый базис всегда есть. Вопрос в масштабности разработки.

Т.е. как вывод из всего выше, никакой твоей «нужности» в написании велосипедов нет.

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

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

Умения разбираться в коде полезно всем. Новатор на то он и новатор, что бы делать новые объекты с несуществующими ранее характеристиками. По теме очень советую прочитать: http://habrahabr.ru/blogs/development/92303/

>Я не спроста взял это слово в кавычки. Бла-бла-бла

В таком случае я тебя не так понял.

Ну дык готовый базис всегда есть.

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

Новатор на то он и новатор, что бы делать новые объекты с несуществующими ранее характеристиками.

Не совсем так. Я не считаю новаторством, например, создание колбасы длиной в 10 метров, чтобы попасть в какую-ть книгу рекордов.
Я бы сказал суть новаторства в реализации какой-то идеи, которая в свою очередь призвана решить какую-то проблему. И первостепенное значение тут имеет нестандартное мышление и/или нестандартный взгляд на вещи.
Человек может годами ковыряться в какой-то области просто потому, что судьба его туда забросила. Он будет успешно ковыряться в существующих наработках, писать их велосипеды, но не создаст ничего идейно нового.
В альтернативу же этому человек может быть не ахти каким программистом, но смотреть на всё по-другому. Пусть он напишет и не супер-изящную и идеальную реализацию, может какой-ть программист, заброшенный волею судеб в разработку таких велосипедов написал бы лучше, но если идея стоящая, то найдутся те, кто будет ей пользоваться, кто проявит интерес и в итоге многократно улучшит реализацию. Тут главный порог чтобы реализация работала, чтобы продемонстрировать идею на практике.
И прошу понять меня правильно, я вовсе не сторонник быдлокода в стиле «работает и ладно». Это неправильно. Я лишь считаю, что для создания чего-то действительно нового первостепенным играет способность родить идею, решающую проблему, а не изящность реализации этой идеи. Реализацию всегда можно выправить, а идея есть или нет. Другого не дано. Но при этом чем искуснее ты мастер, тем всегда лучше.

По теме очень советую прочитать: http://habrahabr.ru/blogs/development/92303/

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

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

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

/me добавил dizza в список друзей

>> Этот пример можно отобразить на MVC, где A - view, а B - model.

отобрази

Предложение выше уже это делает (A - view, а B - model, controller опущен).

особенно интересно, чем будет там класс С

Кастомной моделью как ни странно.

пока что видно лишь плохое проектирование

И чем же оно плохое? О, великий архитектор. Когда всё просто и логично.

Решение может быть не лучшим для любой задачи, но вполне удобным для некоторых. А заявлять о «плохом проектировании» можно лишь зная задачу. Подобная схема вполне удачно используется в том же Qt (QAbstractItemModel, QAbstractItemView).

и максимум, что я предполагаю у тебя — это необходимость в > class Animal { public: void copulate(Self another_animal); }

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

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

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

>>>Необходимость преобразования типов в ООП - явный признак дурной архитектуры..

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

В некоторых запущенных случаях, видимо, собственный мозг это большее зло.. Попробуй положится на мнение Страуструпа и Гради Буча... Или тут из «окопа кричать ура» легче. И данный пример уровня с притянутыми предположениями: если-вдруг-отсутствуют-исходники - этот пример вообще не нужен.. А может завтра тебе кирпич упадет на голову.

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

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

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

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

> И чем же оно плохое? О, великий архитектор. Когда всё просто и логично.

Тем, что необходимо юзать b->doSmth(), и компилятор не может статически проверить наличие этого метода.

// Капитан Очевидность

А заявлять о «плохом проектировании» можно лишь зная задачу.

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

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

Qt

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

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

это тоже можно отнести к нормальному проектированию, но не юзание кастов в юзерском коде

>> И чем же оно плохое? О, великий архитектор. Когда всё просто и логично.

Тем, что необходимо юзать b->doSmth(), и компилятор не может статически проверить наличие этого метода.

Необходимость вызвана тем, что обобщённая библиотека, в которой реализованы классы A и B не позволяет вызвать это там где мне нужно, но решает много других важных задач. doSmth делаешь работу весьма специфическую и пихать поддержку такой функциональности на уровень класса B ещё более плохое проектирование. Также наследуясь от A, я могу локализовать каст в методе C* getC().

А заявлять о «плохом проектировании» можно лишь зная задачу.

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

Аргументация остаётся на уровне, что это плохо, потому что используются касты. Так почему касты всегда плохо?

Я использую касты там, где они позволяют существенно упростить взаимодействие объектов и уменьшить кол-во сущностей. А используя динамическую информацию о типах, делать это можно безопасно. Так dynamic_cast в теории безопасен (но не работает между DLL), в Qt можно юзать qobject_cast, который ещё более безопасен, или что-нибудь своё, однако это уже проблемы конкретно С++.

кстати, есть еще один вариант — сделать че-то на шаблоннах

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

если хочешь че-то полезное — перестань отмазываться, и опиши задачу полностью

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

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

желательно минимальный рабочий кусок кода вместе с main()

>Вот когда добавят, тогда и можно говорить будет ;) А сейчас приходится извращаться. пример быдлокода на анонимных классах

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

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

Вам не кажется, что предложения исключают друг друга?

Нужен не override а virtual, для сокращения размера таблицы виртуальных функций

Чем он лучше @Override?

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

Самое интересное, что я так именно и думаю. Правда, зачастую речь о бюджете ведут быдломенеджеры, которые не знают, что на этапе поддержки/багофикса тратится 50% бюджета и более, а на планирование надо выделить 30% против 20% на быдлокодирование.

Во портянки-то! По-моему проще с машиной говорить на plain english, короче выйдет