Автор Тема: Кому можно рекомендовать ББ - в текущем состоянии!  (Прочитано 50302 раз)

DIzer

  • Гость
инициативным разработчикам
это как?
берёшь рашпиль и за дело
понятно - дрочунам?

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
дрочунам?
это, как раз, неинициативные - их всё устраивает

DIzer

  • Гость
дрочунам?
это, как раз, неинициативные - их всё устраивает
не вы не так меня поняли, это те кто берет напильники (дрочевые - они же рашпили) и "дрочат" по поводу и без оного...

Илья Ермаков

  • Sr. Member
  • ****
  • Сообщений: 493
    • Просмотр профиля
Могу смело ББ порекомендовать тем, кого задолбал "мейнстрим" (то есть все обычное)

Я бы не называл "мейнстрим" обычным.
Я под словом "мейнстрим" ощущаю те технологии, которые базируется на чувстве "собственной значимости ИКТ".
Оппозиция же к "мейнстриму" - это любые технологии, построенные "скромно", с минимализмом, чтобы сохранить мозги людям чистыми для реальной работы.
Такие тенденции - всюду: идут лесом сложные СУБД, взамен приходят такие, которые можно сделать за полгода (NoSQL и проч.; посмотрите, например, на lectorium.tv лекции "Яндекса" про СУБД).
Идут лесом J2EE, появляются такие фреймворки, как Play!.
И т.п.


valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Добавлю, что ББ также вполне можно рекомендовать тем у кого рассчетные задачи, причем задачи не ложащиеся 1 в 1 на какой-либо известный метод (то есть взять матлабик и в одну строчку все записать не выйдет). Причем не эпизодические задачи, а постоянные - в этом случае в ББ можно свить вполне уютное гнездо (видимо уютней чем то, что свили в Энергии на PL/I). Единственное что - задачи должны быть не критичны к времени исполнения (то есть постоянный множитель не должен быть критичен), ибо компилятор не оптимизирующий и не оптимальный.

Также, пожалуй, можно порекомендовать тем, кто экспериментирует с алгоритмикой (скажем изобретает очередной улучшизм алгоритма A*) - гнездо также можно свить уютное, где цикл разработки будет короче.

Да, это все при условии, что у людей нет времени, или им не интересно, изучить какой-нибудь "большой" ЯП. То есть не IT-профи.
Y = λf.(λx.f (x x)) (λx.f (x x))

Илья Ермаков

  • Sr. Member
  • ****
  • Сообщений: 493
    • Просмотр профиля
Ещё есть такая задачка:
- получить короткий "круг" от совершенного новичка в программировании до грамотного кадра. На базе мейнстрима максимум, на что хватает ИТ-компаний - это подбирать на старших курсах (в надежде, что хоть что-то заложено на младших). А уложить всю подготовку от "нуля" и до полноценного сотрудника года в два - нереально на базе мейнстрима.
А очень, между прочим, соблазнительно для ИТ-компании - не выискивать на выпуске подходящих, а без особых затрат "вылепить" и уже "прикормить"  в том возрасте, когда он ещё учится и не "загружен житейским геморроем" :)

Однако сегодня для ИТ-компаний этап начального формирования программиста - тайна за семью печатями. "Самозарождение". Остаётся только рыскать в поисках уже "самозародившихся" (самостоятельно или благодаря таки ВУЗу).

У меня есть пример цикла от полного "нуля" до создания реального небольшого приложения (на КП/ББ) ценой в $4000 длиной в год. Это очень способный парень, но в ИТ был совершенно "чист".

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Могу смело ББ порекомендовать тем, кого задолбал "мейнстрим" (то есть все обычное)

Я бы не называл "мейнстрим" обычным.
Я под словом "мейнстрим" ощущаю те технологии, которые базируется на чувстве "собственной значимости ИКТ".
Оппозиция же к "мейнстриму" - это любые технологии, построенные "скромно", с минимализмом, чтобы сохранить мозги людям чистыми для реальной работы.
Эмм.. То есть Scala, Common Lisp и Haskell - это мейнстрим, а вот Си и Java (язык) оппозиция мейнстрму? ;-)

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

Такие тенденции - всюду: идут лесом сложные СУБД, взамен приходят такие, которые можно сделать за полгода (NoSQL и проч.; посмотрите, например, на lectorium.tv лекции "Яндекса" про СУБД).
Идут лесом J2EE, появляются такие фреймворки, как Play!.
При этом и NoSQL и Play! это мейнстрим :-)
У меня ощущение складывается, что ты смешиваешь мейнстрим с ынтырпрайзом :-)
Ынтырпрайз он не базируется на чувстве собственной значимости IT, он базируется на солидных компаниях и их чувстве собственной значимости. Пример - Corba, SAP, J2EE, COM.
Y = λf.(λx.f (x x)) (λx.f (x x))

DIzer

  • Гость
Добавлю, что ББ также вполне можно рекомендовать тем у кого рассчетные задачи, причем задачи не ложащиеся 1 в 1 на какой-либо известный метод (то есть взять матлабик и в одну строчку все записать не выйдет). Причем не эпизодические задачи, а постоянные - в этом случае в ББ можно свить вполне уютное гнездо (видимо уютней чем то, что свили в Энергии на PL/I). Единственное что - задачи должны быть не критичны к времени исполнения (то есть постоянный множитель не должен быть критичен), ибо компилятор не оптимизирующий и не оптимальный.

Также, пожалуй, можно порекомендовать тем, кто экспериментирует с алгоритмикой (скажем изобретает очередной улучшизм алгоритма A*) - гнездо также можно свить уютное, где цикл разработки будет короче.

Да, это все при условии, что у людей нет времени, или им не интересно, изучить какой-нибудь "большой" ЯП. То есть не IT-профи.
т.е.  это эквивалентно
1. дрочунам (людям у который есть постоянный "зуд"  ) от программирования
2. Исследователям ведущим разработки в изолированных областях, не требующих серьезных вычислительных ресурсов, по несчастью, не умеющих программировать вообще (соответственно не знающих иных альтернатив)
так?

Илья Ермаков

  • Sr. Member
  • ****
  • Сообщений: 493
    • Просмотр профиля
Да, со смыслами слов иногда туго.

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

Илья Ермаков

  • Sr. Member
  • ****
  • Сообщений: 493
    • Просмотр профиля
При этом и NoSQL и Play! это мейнстрим :-)
У меня ощущение складывается, что ты смешиваешь мейнстрим с ынтырпрайзом :-)

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

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Я бы не называл "мейнстрим" обычным.
Я под словом "мейнстрим" ощущаю те технологии, которые базируется на чувстве "собственной значимости ИКТ".
Оппозиция же к "мейнстриму" - это любые технологии, построенные "скромно", с минимализмом, чтобы сохранить мозги людям чистыми для реальной работы.
Такие тенденции - всюду: идут лесом сложные СУБД, взамен приходят такие, которые можно сделать за полгода (NoSQL и проч.; посмотрите, например, на lectorium.tv лекции "Яндекса" про СУБД).
Идут лесом J2EE, появляются такие фреймворки, как Play!.
И т.п.

Вы так говорите, будто NoSQL могут заменить сложную SQL СУБД. Это две параллельные ветки, а никак не альтернатива друг другу.
То же касается и остального мэйнстрима.

Илья Ермаков

  • Sr. Member
  • ****
  • Сообщений: 493
    • Просмотр профиля
Нюансов много, но то, что навороченные СУБД не масштабируются, не адаптируются к высокой нагрузке и к нерегулярным, изменчивым данным - це факт.

И никакую РСУБД в крупных проектах теперь не встретишь без ORM (Object-Realtion-Mapping). Но при такой схеме использования РСУБД становится во многом "тупо хранилищем", основная сложная функция, оставляемая за РСУБД - это разные выборки, которые не опишешь императивно (гуляя от ID к ID).
И аутентификация, и многое другое оказывается уровнем выше.

Так что рано или поздно неиспользуемые при ORM-режиме "рудименты" просто "отвалятся".

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

Илья Ермаков

  • Sr. Member
  • ****
  • Сообщений: 493
    • Просмотр профиля
Я, может быть, отбрасываю ряд нюансов, деталей, выражая своё ощущение главной тенденции...
Когда никто даже помыслить не может "жить без СУБД", а ты делаешь "No-СУБД"-решения, просто потому, что не хочешь вляпываться в избыточную сложность чужих СУБД, а потом тройку лет спустя все носятся с воплями "No-SQL, No-SQL", то, наверное, ощущение моё не совсем беспочвенное, а? :)

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Нюансов много, но то, что навороченные СУБД не масштабируются, не адаптируются к высокой нагрузке и к нерегулярным, изменчивым данным - це факт.

А можно конкретнее? Какие именно СУБД вы имеете ввиду?
Что в вашем понимании "масштабирование"?
Что в вашем понимании адаптация к высокой нагрузке?

И что такое нерегулярные изменчивые данные?  ???

Madzi

  • Jr. Member
  • **
  • Сообщений: 86
    • Просмотр профиля
Нюансов много, но то, что навороченные СУБД не масштабируются, не адаптируются к высокой нагрузке и к нерегулярным, изменчивым данным - це факт.

И никакую РСУБД в крупных проектах теперь не встретишь без ORM (Object-Realtion-Mapping). Но при такой схеме использования РСУБД становится во многом "тупо хранилищем", основная сложная функция, оставляемая за РСУБД - это разные выборки, которые не опишешь императивно (гуляя от ID к ID).
И аутентификация, и многое другое оказывается уровнем выше.

Так что рано или поздно неиспользуемые при ORM-режиме "рудименты" просто "отвалятся".

ORM - объективная необходимость, но он сам по себе "гибриден", сложен. Значит, произойдёт некий виток упрощения.
Вы просто не в теме :).
Расскажите IBM, о том что DB/2 не масштабируется, не адаптируется к высокой нагрузке и т.п.

ORM ORM`у рознь. Есть такие, которые полностью абстрагируют приложение от базы, да и сами от базы отстранены (hibernate, например), а есть такие, которые не теряют связь с подлежащей базой (например, iBatis) при этом весь SQL пишется ручками, как и его маппинг на высокоуровневые объекты.

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