ты же не будешь под web на котлин писать, или java?

а почему, собственно, нет?)

разве на котлине и на джаве пишется только под андроид?)

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

зачем джава если есть kotlin

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

ну как бы спринг бут есть, с котлином все ок

ноги вроде у всех целы

мне нечего добавить )

я тебя не понял - то ли это наброс, то ли это попытка критики

Грубо говоря https://en.wikipedia.org/wiki/Digital_asset_management контора специализируется на оцифровании всяких штук (от архивных документов, до насекомых).

Оу, бери язык с нативными variant type (aka sum type), подозреваю что в этой тематике огромное количество кейсов при разработке

ты же не будешь под web на котлин писать, или java?

речь далеко не про web. я уже сказал общее направление. это DAM. т.е. обработка и хранение огромного потока цифровой информации. метатеги, Linked Data. но это все очень общее.

это не просто бложик или цмс

я тебя не понял - то ли это наброс, то ли это попытка критики

отнюдь

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

что сейчас есть

приходи с ТЗ ))

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

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

Оу, бери язык с нативными variant type (aka sum type), подозреваю что в этой тематике огромное количество кейсов при разработке

посмотрю в эту сторону, спасибо.

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

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

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

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

мб там пхпшники, как Фесор)

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

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

и дело далеко не в языке

бери java... на рынке полезен )

ну вот я уже услышал мнение, что зачем java если есть kotlin и я согласен с этим

короче общую тендецию я уже услышал.

ну вот я уже услышал мнение, что зачем java если есть kotlin и я согласен с этим

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

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

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

боже я же не говорю что выбирается

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

моя цель услышать фидбэк

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

м, так ведь у котлина и джавы полный интероп, не?

моя цель услышать фидбэк

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

ну вот я уже услышал мнение, что зачем java если есть kotlin и я согласен с этим

я тоже посоветую язык с адекватными типами и возможности по ним генерить всякую инфу например для rpc(теже http клиенты к апишке)

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

но можно и elixir…

Хотя я конечно забыл упомянуть специфику проекта. всякие бигдаты на пхп лабать - путь в никуда скорее всего :)

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

Хотя я конечно забыл упомянуть специфику проекта. всякие бигдаты на пхп лабать - путь в никуда скорее всего :)

что-то, что будет больше 20к строк делать на пыхе - сомнительная идея как мне кажется

сидел и думал что такое P of EAA... понапридумывали же)

ну вроде это сокращение известное, не?

это ж фаулеровской книги название, да?

это ж фаулеровской книги название, да?

ага

да паттерны ентерпрайз приложений

вроде известное

ой... не смог дочитать эту книгу :)

так это ж справочник

хз чёт не пересекался даже особо. Ну или внимания не обращал

да, это же справочник

так это ж справочник

да. вечно засыпал :)

так это ж справочник

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

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

ну если гофа осилили не уснув, то с этой должно со свистом пройти)

.NET Core збс, сисярп форева

ну если гофа осилили не уснув, то с этой должно со свистом пройти)

а эт ваще для какого уровня книга?)

а эт ваще для какого уровня книга?)

Когда наступает смирение)

Но на самом деле если не открывал, самое время начать)

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

Есть вопрос для обсуждения. Тут на работе подняли тему, что взять для нового проекта (продукта как хотят менеджера). Есть ребята топящие за полное ФП, есть которые за полный ООП, а есть которые за всякое другое (я лично предлагал попробовать Kotlin) Хотелось бы услышать краткий обзор или авторитетное мнение. Команда в основном бывшие пхпшники. но есть ряд людей которые писали на erlang, а сейчас пишут фронт на Elm. Вот хотелось бы услышать просто ряд мнений без фанатизма с примерами языков. Вот пример языков которые предлагали: Elixir, Closure, Scala, Java, PHP, Go, Python и всякое другое. Пишу не для вброса или еще чего-нибудь, просто хотелось с агрегировать ряд мнений и коротких фидбеков. т.к. сам проект еще на стадии глубокого обсуждения и тяжело понять даже масштабы.

Поправьте если я ошибаюсь, но ключевая позиция фп - это работа с данными в иммутабельном виде а ключевая позиция ооп - когда данные представляют собой живой граф объектов. То есть, с ооп, когда отдельная функция получает какой-то глубокий объект этого графа то она может сохранить этот объект в замыкании и со временем свободно обновлять поля этого объекта и актуальные изменения увидят все другие функции которые также хранят ссылку на этот объект. А подход иммутабельности и отсуствия сайдэффектов в фп предполагает что мы должны вернуть новый объект после его изменения но помимо этого также должны рекурсивно заменить всех родителей новыми объектами (потому что у них нужно изменить поле ссылающееся на новый объект ребенка) а это добавляет неудобств в при появлении циклических ссылок друг на друга потому что их нужно хранить через айдишники на эти объекты (иначе будут рекурсивно пересоздаваться все связанные по ссылке объекты и результате получим что чуть ли не весь граф объектов будет пересоздан заново). Например в мессенджере когда есть объект юзера со списком чат-комнат и каждая такая чат-комната ссылается на объект юзера и также на объект самой комнаты то с ооп мы можем просто хранить эти объекты в виде вложенных объектов и ссылок и удобно получить например список чатов юзера user.chatRooms.map(cr=>cr.room)а с фп придется дополнительно джойнить данные получая каждый объект чата по его айдишнику из глобального хеша user.chatRoomsIds.map(id=>globalHash.get(id)).map(roomUser=>globalHash.get(roomUser.roomId))что добавляет некоторой неясности в код. А когда функция захочет обратиться к более глубоким объектам по цепочке то код с фп становится еще сложнее Например есть приложение с кучей вложенных сущностей - юзер может создавать папки, внутри папок проекты, внутри проектов задачи и к задачам может создавать подзадачи то функция которая получает объект подзадачи и ей нужно вычислить приоритет на основе приоритета папки в которой эта подзадача находится то ей по сути нужно будет от объекта задачи добраться до объекта папки через все промежуточные объекты. И если в ооп это можно записать просто и наглядно subtask.task.project.folder.priorityто с иммутабельным подходом нужно будет вытаскивать каждый промежуточный объект из глобального хеша и код становится совсем не наглядным globalHash.get(globalHash.get(globalHash.get(subtask.taskId).projectId).folderId).priorityИ в реальных приложениях код бизнес-логики будет сплошь и рядом увешан кодом постоянного вытаскивания нужных объектов по их айдишникам из хеша и в итоге превращается в ненаглядную лапшу.

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

Дарте

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

> есть понимание ооп Это что?)

> есть понимание ооп Это что?)

это мое субъективное суждение.

это мое субъективное суждение.

Так делись

незачем.

Поправьте если я ошибаюсь, но ключевая позиция фп - это работа с данными в иммутабельном виде а ключевая позиция ооп - когда данные представляют собой живой граф объектов. То есть, с ооп, когда отдельная функция получает какой-то глубокий объект этого графа то она может сохранить этот объект в замыкании и со временем свободно обновлять поля этого объекта и актуальные изменения увидят все другие функции которые также хранят ссылку на этот объект. А подход иммутабельности и отсуствия сайдэффектов в фп предполагает что мы должны вернуть новый объект после его изменения но помимо этого также должны рекурсивно заменить всех родителей новыми объектами (потому что у них нужно изменить поле ссылающееся на новый объект ребенка) а это добавляет неудобств в при появлении циклических ссылок друг на друга потому что их нужно хранить через айдишники на эти объекты (иначе будут рекурсивно пересоздаваться все связанные по ссылке объекты и результате получим что чуть ли не весь граф объектов будет пересоздан заново). Например в мессенджере когда есть объект юзера со списком чат-комнат и каждая такая чат-комната ссылается на объект юзера и также на объект самой комнаты то с ооп мы можем просто хранить эти объекты в виде вложенных объектов и ссылок и удобно получить например список чатов юзера user.chatRooms.map(cr=>cr.room)а с фп придется дополнительно джойнить данные получая каждый объект чата по его айдишнику из глобального хеша user.chatRoomsIds.map(id=>globalHash.get(id)).map(roomUser=>globalHash.get(roomUser.roomId))что добавляет некоторой неясности в код. А когда функция захочет обратиться к более глубоким объектам по цепочке то код с фп становится еще сложнее Например есть приложение с кучей вложенных сущностей - юзер может создавать папки, внутри папок проекты, внутри проектов задачи и к задачам может создавать подзадачи то функция которая получает объект подзадачи и ей нужно вычислить приоритет на основе приоритета папки в которой эта подзадача находится то ей по сути нужно будет от объекта задачи добраться до объекта папки через все промежуточные объекты. И если в ооп это можно записать просто и наглядно subtask.task.project.folder.priorityто с иммутабельным подходом нужно будет вытаскивать каждый промежуточный объект из глобального хеша и код становится совсем не наглядным globalHash.get(globalHash.get(globalHash.get(subtask.taskId).projectId).folderId).priorityИ в реальных приложениях код бизнес-логики будет сплошь и рядом увешан кодом постоянного вытаскивания нужных объектов по их айдишникам из хеша и в итоге превращается в ненаглядную лапшу.

ну вот я пока не пробовал ФП в качестве бизнес приложения. и я хочу занятся в ближайшем будущем, чтобы понять эти тонкости. насчет `subtask.task.project.folder.priority` -- это не совсем про ооп. это скорее про структуры какие-то.

Поправьте если я ошибаюсь, но ключевая позиция фп - это работа с данными в иммутабельном виде а ключевая позиция ооп - когда данные представляют собой живой граф объектов. То есть, с ооп, когда отдельная функция получает какой-то глубокий объект этого графа то она может сохранить этот объект в замыкании и со временем свободно обновлять поля этого объекта и актуальные изменения увидят все другие функции которые также хранят ссылку на этот объект. А подход иммутабельности и отсуствия сайдэффектов в фп предполагает что мы должны вернуть новый объект после его изменения но помимо этого также должны рекурсивно заменить всех родителей новыми объектами (потому что у них нужно изменить поле ссылающееся на новый объект ребенка) а это добавляет неудобств в при появлении циклических ссылок друг на друга потому что их нужно хранить через айдишники на эти объекты (иначе будут рекурсивно пересоздаваться все связанные по ссылке объекты и результате получим что чуть ли не весь граф объектов будет пересоздан заново). Например в мессенджере когда есть объект юзера со списком чат-комнат и каждая такая чат-комната ссылается на объект юзера и также на объект самой комнаты то с ооп мы можем просто хранить эти объекты в виде вложенных объектов и ссылок и удобно получить например список чатов юзера user.chatRooms.map(cr=>cr.room)а с фп придется дополнительно джойнить данные получая каждый объект чата по его айдишнику из глобального хеша user.chatRoomsIds.map(id=>globalHash.get(id)).map(roomUser=>globalHash.get(roomUser.roomId))что добавляет некоторой неясности в код. А когда функция захочет обратиться к более глубоким объектам по цепочке то код с фп становится еще сложнее Например есть приложение с кучей вложенных сущностей - юзер может создавать папки, внутри папок проекты, внутри проектов задачи и к задачам может создавать подзадачи то функция которая получает объект подзадачи и ей нужно вычислить приоритет на основе приоритета папки в которой эта подзадача находится то ей по сути нужно будет от объекта задачи добраться до объекта папки через все промежуточные объекты. И если в ооп это можно записать просто и наглядно subtask.task.project.folder.priorityто с иммутабельным подходом нужно будет вытаскивать каждый промежуточный объект из глобального хеша и код становится совсем не наглядным globalHash.get(globalHash.get(globalHash.get(subtask.taskId).projectId).folderId).priorityИ в реальных приложениях код бизнес-логики будет сплошь и рядом увешан кодом постоянного вытаскивания нужных объектов по их айдишникам из хеша и в итоге превращается в ненаглядную лапшу.

Получите распишитесь

https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/

https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/

А где пост на который ссыляется автор в начале? Хотел сначала его прочитать, но не могу найти

Хз, hackernews принёс через минуту после вопроса тут

ну не знаю, ООП на мой вкус прикольнее

ооп это то, не знаю что?) Да, оч прикольно

каждый раз открывается с разной стороны

и все время с непонятно, какой

ну не знаю, ООП на мой вкус прикольнее

Извинись

Извинись

ты либо в тренде, либо уходи

ты либо в тренде, либо уходи

Дык в тренде фп, не?

извинения в тренде и в треде

забаню

забаню

Ок, соре Ооп рулит

да не , я не за ооп, а за наброс

но за ооп тож можно забанить, ящитаю