Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → Інше → Тема для розмов
Сторінки Попередня 1 … 197 198 199 200 201 … 721 Наступна
Для відправлення відповіді ви повинні увійти або зареєструватися
людям тре штучний інтелект, щоб робив все за них, а вони могли б тоді насолоджуватись життям, їсти смачненьке та трахатись
Подружка для Трусиків в крові
Подружка для Трусиків в крові
▼NFSW
хто вам сказав, що я люблю жирних? в такому разі я злегкістю можу сказату якусь фігню про вас, тіпа - подружка для Invader'a
Підберіть і мені подружку
гугліть bailey j, з нею сумувати не доведеться
Може це у вас релігійні переконання принципи з приводу остаточної і невідворотної перемоги ООП, хто знає?
Мушу визнати свою упередженість щодо способів програмування і готовий визнати свою некомпетентність у ФП, серед функіональних мов я пробував лише Haskell і F#.
Я впевнений, що ООП не буде останньою стадією розвитку програмування, і вважаю, що ООП не є найкращим серед всіх можливих способів. Але це крок в правильному напрямку, до речі ФП - теж, тільки з іншої сторони. Думаю майбутні способи будуть створюватися таким чином, що повністю успадкують або поглинуть ООП.
І якщо вже на те пішло, перед обговоренням ООП непогано було б дати визначення, щоб знати, без чого не побудувати складну систему.
побудувати складну систему...
Якщо Ви про створення програми, то будь-яку програму можна створити без ООП (як і без ФП), питання тільки в тому, на скільки швидше вона може бути створена з ООП (або з ФП), і тут ООП виграє в більшості випадків.
Якщо Ви про створення архітектури (зв'язків між класами, структурами, інтерфейсами), то тут проблеми:
1) Множинне наслідування. Більшість строго типізованих мов не дозволяють множинне наслідування класів, дозволено множинне наслідування тільки інтерфейсів. Доводиться дописувати ієрархію інтерфейсів, щоб досягнути бажаного результату. Тут виглядає так, наче C++ найкращий варіант.
2) Дженеріки (в C#, Java) і темплейти (в C++). Темплейти взагалі нікуди не годяться, бо вони генерують купу класів, а мають бути одним класом. У дженеріків біда в реалізації (забагато обмежень на типи-параметри). Про це детальніше напишу, коли завершу свій проект (боюсь це буде не скоро).
3) Не достатньо продумані реалізації поліморфізму та інкапсуляції у мовах. Нащадок не може оголосити публічний (public) доступ до успадкованих захищених (protected) методів з тими ж іменем і сигнатурою. Найкращий варіант тут оголосити новий метод і зробити його публічним, а це іноді змушує створювати зайві класи.
Недоліків нині існуючих реалізацій ООП ще багато, але всіх я зараз не згадаю, дуже хочу спати.
Дідько, вигладає так, наче розкритикував ООП, народ подумає, що я тепер захищаю ФП 
по-перше, правильна архітектура великого проекту не залежить від мов програмування ...
Воно то так, але коли діло доходить до програмування, то від обмежень мови програмування нікуди не дінетесь.
це так як знайомий програміст, оперуючи застарілими 4 роки назад фактами про mysql - запевнює всіх що на mysql неможливо великий проект запустити ...
Запевняю Вас, я не з таких, і якщо побачу власну помилку, то привселюдно визнаю це.
чому це фп нічим не краще?
краще - тому що прозоріше,
Під "прозоріше" мається на увазі легкість читання коду ?
На якій такій ФП-мові код зрозуміліший ніж на Java ? (проігноруйте це питання, якщо я щось не правильно зрозумів)
краще - тому що швидше працює,
ну тут залежить від компілятора.
краще - тому що не клепає мізки ні програмісту, ні серверу))
Під час вивчення Haskell'я я клепав собі мізки значно більше ніж при вивченні будь-якої мови ООП.
по-друге, виходячи з вебсокетів та кількості з'єднань - ми плавно переходимо до того що нічого кращого за erlang ще не придумали
хтось може розкричатися що є node.js, але нода програє відразу по декількох параметрах - і меньша кількість зєднань, і проблеми з памяттю, і відсутність решти плюшок erlang-а
ще хтось може згадати про Go - втім erlang залишає позаду і його)по-третє ми говоримо про майбутнє --- як тут не згадати про нейронки -- а у erlang вони з-коробки, як особливість мови програмування))
майбутнє за erlang-ом та його надбудовами - elixir, etc
(звісно, asm та c/c++ нікуди не подінуться)
Ви мене заінтригували, тепер ще й erlang доведеться вивчити.
людям точно не потрібні ще більш гальмівні мови програмування зі ще більш гальмівними конструкціями))
Згідний, мова має дуже швидкою при обробці і достатньо легкою при вивченні, але і має давати великі можливості.
Дідько, вигладає так, наче розкритикував ООП, народ подумає, що я тепер захищаю ФП
Я якраз і хотів, щоб ви його захищали.
А ще мені здається, що у кожного, хто тут відписався, своє поняття про ООП. Добре було б якось дати визначення йому, чи що.
3) Не достатньо продумані реалізації поліморфізму та інкапсуляції у мовах. Нащадок не може оголосити публічний (public) доступ до успадкованих захищених (protected) методів з тими ж іменем і сигнатурою.
У Java можна зробити публічний метод на місці захищеного предківського і в ньому викликати предківський метод.
public class Unprotect
{
public static void main(String args[])
{
System.out.println(new unprotect.B().m());
}
}package unprotect;
public class A
{
protected String m()
{
return "Hello from A!";
}
}package unprotect;
public class B extends A
{
public String m()
{
return super.m();
}
}А от навпаки (зробити успадкований публічний метод приватним чи захищеним) — вже ні, що цілком логічно.
У Java можна зробити публічний метод на місці захищеного предківського і в ньому викликати предківський метод.
Винен, я не правильно висловився.
Нащадок не може оголосити публічний перевизначений (public override) доступ до успадкованих захищених віртуальних (protected virtual) методів з тими ж іменем і сигнатурою.
public class C1
{
protected virtual int Method() { return 0; }
}
public class C2 : C1
{
public override int Method() { return base.Method(); }
}
// Error: Override method cannot change access rights.
221VOLT написав:по-перше, правильна архітектура великого проекту не залежить від мов програмування ...
Воно то так, але коли діло доходить до програмування, то від обмежень мови програмування нікуди не дінетесь.
221VOLT написав:це так як знайомий програміст, оперуючи застарілими 4 роки назад фактами про mysql - запевнює всіх що на mysql неможливо великий проект запустити ...
Запевняю Вас, я не з таких, і якщо побачу власну помилку, то привселюдно визнаю це.
221VOLT написав:чому це фп нічим не краще?
краще - тому що прозоріше,Під "прозоріше" мається на увазі легкість читання коду ?
На якій такій ФП-мові код зрозуміліший ніж на Java ? (проігноруйте це питання, якщо я щось не правильно зрозумів)221VOLT написав:краще - тому що швидше працює,
ну тут залежить від компілятора.
221VOLT написав:краще - тому що не клепає мізки ні програмісту, ні серверу))
Під час вивчення Haskell'я я клепав собі мізки значно більше ніж при вивченні будь-якої мови ООП.
221VOLT написав:по-друге, виходячи з вебсокетів та кількості з'єднань - ми плавно переходимо до того що нічого кращого за erlang ще не придумали
хтось може розкричатися що є node.js, але нода програє відразу по декількох параметрах - і меньша кількість зєднань, і проблеми з памяттю, і відсутність решти плюшок erlang-а
ще хтось може згадати про Go - втім erlang залишає позаду і його)по-третє ми говоримо про майбутнє --- як тут не згадати про нейронки -- а у erlang вони з-коробки, як особливість мови програмування))
майбутнє за erlang-ом та його надбудовами - elixir, etc
(звісно, asm та c/c++ нікуди не подінуться)Ви мене заінтригували, тепер ще й erlang доведеться вивчити.
221VOLT написав:людям точно не потрібні ще більш гальмівні мови програмування зі ще більш гальмівними конструкціями))
Згідний, мова має дуже швидкою при обробці і достатньо легкою при вивченні, але і має давати великі можливості.
я не мав честі писати прогами на Haskell-і, хоча й чув про нього лише хороші речі)
можливо у майбутньому знайду час ознайомитись)
судячи по прикладах https://uk.wikipedia.org/wiki/Haskell ---
така ж лаконічна і прозора мова програмування як і erlang
я з вами згоден - вивчення erlang-а (як напевно і Haskell-а) - трошки клепає мізки,
клепає в силу того, що конструкції абсолютно незвичні, вони реально нові - заставляють мозок пробудити з лінивого сну - фізично відчутно що мозок починає працювати 
оця лаконічність - прозорість - зрозумілість коду erlang-a , haskell-a, ... --- як 9а симфонія Бетховена у порівнянні з ооп-жахом php, java, etc
надлишковість - evil
oop - довше працює - отже - evil
---
приємно спілкуватися з людьми, які визнають що можуть помилятися)
це свідчить що ці люди не зупинили свій ріст, своє навчання))
у першу чергу шукаються переваги а не недоліки - у вас є задача і ви шукаєте набори інструментів, з якими можна цю задачу виконати, далі порівнюєте набори інструментів (аж тут порівнюються переваги і недоліки) які підходять для виконання поставленої задачі, вибираєте один і виконуєте задачу)
---
під прозорістю мається на увазі - маленький код(у порівнянні з ооп-спагетті інших мов програмування), код одним поглядом охоплюється і є повністю зрозумілим, не треба чухати два дні голову над питаннями "як це працює" і "чому це працює інколи отак, а інколи ще інакше"
3) Не достатньо продумані реалізації поліморфізму та інкапсуляції у мовах. Нащадок не може оголосити публічний (public) доступ до успадкованих захищених (protected) методів з тими ж іменем і сигнатурою.
У Java можна зробити публічний метод на місці захищеного предківського і в ньому викликати предківський метод.
public class Unprotect { public static void main(String args[]) { System.out.println(new unprotect.B().m()); } }package unprotect; public class A { protected String m() { return "Hello from A!"; } }package unprotect; public class B extends A { public String m() { return super.m(); } }А от навпаки (зробити успадкований публічний метод приватним чи захищеним) — вже ні, що цілком логічно.
як йдеться у одній пісні Скрябіна -
"нікому тооо не трееебаа, я був ще вчооора таакий малиий!"
серйозно - навіщо ці всі зайві громіздкі конструкції?
ооп у деяких програмістів виглядає як джип у деяких чоловіків (про них ще жартують що вони купили великий автомобіль бо у них дещо інше мааленьке)) а можливо і не жартують а правду говорять - хтозна...)))
function mzzza(){
return "Hello from A!";
}цей ввесь зайвий спагетті-ооп-код виглядає імітацією роботи програміста і імітацією роботи програми)
навіть не просто виглядає, а імітацією і є)
спочатку програміст імітує роботу "йой я за день 2к строчок написав(з яких корисного - строчок 100-200, решта - сміттячко як вище), який я молодець", а далі програма з тим всім сміттячком імітує корисну роботу - пару мілісекунд на виконання корисної роботи, яка вміщається у маленьку частинку від сміттячка, і секунди обробки сміттячка-коду))
через оці ваші ооп ---
ігри і програми які не підвисали на нокії-симбіані 10 років назад ---
при 1х 200-400Мгц процесорі + 64-128Мб оперативки ---
їх аналоги зараз зависають і гальмують на мобілах з 2-4х 2.0+ГГц процесором і 1-4Гб оперативки
це просто позор і катастрофа
жаль що майкрософт купили нокію і знищили як компанію, жаль
симбіан була дуже перспективною ос, не до порівняння з глючними і підвисаючими андроїдами+віндофонами
для симбы теж був свій С++, треба ще вміти писати на ООП
ніби не дурні, а таку фігню несете..
Все фігня.
Не на ООП а парадигмі ООП. І може у проблемах іграшок на сотових і розумних телефонах винна Java?
цей ввесь зайвий спагетті-ооп-код виглядає імітацією роботи програміста і імітацією роботи програми)
Якщо програміст зловживає конструкціями мови програмування, то роботодавець, побачивши його код, буде знати про низьку кваліфікацію такого програміста. І це стосується будь-якої мови (не тільки ОО).
спочатку програміст імітує роботу "йой я за день 2к строчок написав(з яких корисного - строчок 100-200, решта - сміттячко як вище), який я молодець", а далі програма з тим всім сміттячком імітує корисну роботу - пару мілісекунд на виконання корисної роботи, яка вміщається у маленьку частинку від сміттячка, і секунди обробки сміттячка-коду))
Сподіваюсь роботодавці оцінюють програми не кількістю стрічок коду, бо така оцінка може бути не адекватною.
На скільки мені відомо, у більшості компаній (які займаються розробкою ПЗ) є люди, які перевіряють код, щоб він виконувався максимально швидко і використовував мінімум пам'яті, щоб модифікація програми вимагала мінімум часу і зусиль, і щоб доповнення програми займало мінімум часу і давало максимальні можливості.
Десь чув, шо індусам платять за кількість (об'єм) написаного коду 
Х.з, мабуть жартують.
221VOLT написав:цей ввесь зайвий спагетті-ооп-код виглядає імітацією роботи програміста і імітацією роботи програми)
Якщо програміст зловживає конструкціями мови програмування, то роботодавець, побачивши його код, буде знати про низьку кваліфікацію такого програміста. І це стосується будь-якої мови (не тільки ОО).
221VOLT написав:спочатку програміст імітує роботу "йой я за день 2к строчок написав(з яких корисного - строчок 100-200, решта - сміттячко як вище), який я молодець", а далі програма з тим всім сміттячком імітує корисну роботу - пару мілісекунд на виконання корисної роботи, яка вміщається у маленьку частинку від сміттячка, і секунди обробки сміттячка-коду))
Сподіваюсь роботодавці оцінюють програми не кількістю стрічок коду, бо така оцінка може бути не адекватною.
На скільки мені відомо, у більшості компаній (які займаються розробкою ПЗ) є люди, які перевіряють код, щоб він виконувався максимально швидко і використовував мінімум пам'яті, щоб модифікація програми вимагала мінімум часу і зусиль, і щоб доповнення програми займало мінімум часу і давало максимальні можливості.
В більшості компаній намагаються писати код в короткі терміни, тому активно юзають ООП бо менше строк коду. Контроль якості у більшості компаній через це так само низькоякісний, в більшості випадків просто вимагають дотримання стандартів які роблять код таким що читається, про ресурси згадують лиш тоді коли є жорсткі обмеження, наприклад коли пишуть гру на консоль. Тому на консолі гра може виглядати так само якісно і працювати так само швидко як на комп'ютері в четверо потужнішому.
ця вся суперечка за ООП нагадало давню байку