LINUX.ORG.RU

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


3

2

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

ЗЫ: Немного пьян, так что повествование местами бессвязное.

Перемещено true_admin из talks


Ответ на: комментарий от emulek

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

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

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

В такой формулировке это и есть идиотизм. Я бы не хотел так жить (ИЧСХ, не буду). Полагаю, на работе важно личное взаимодействие с коллегами и рабочая обстановка.

nightingale
()
Ответ на: комментарий от nanoolinux

Но первую версию всё равно же не на хаскеле написали?

а австралопитеки пользовались палками в качестве орудий труда

И к тому же, что на счёт HUGS? Он же на С?

и к тому же, что насчёт Vacietis? он же на CL?

jtootf ★★★★★
()
Ответ на: комментарий от nightingale

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

смысл есть для тех стран, у которых нет нефти. Финляндия например. Они нам каждый день платят, за танкер, который туда-сюда катается с нашей нефтью. Ладно выхлоп, но если прольётся? Это жеж ППЦ будет! С электричеством проще, бросил кабель по заливу, и качай себе с ЛАЭС (ЛАЭС делали в рассчёте на продакшен СССР, а сейчас его(и продакшена, и СССР) тупо нет, потом электричество у нас дешёвое)

Особенно в перспективе, т.к. очевидно, что нефть дешеветь не будет. Больше её не станет.

Полагаю, на работе важно личное взаимодействие с коллегами

нюхаешь, как они пердят? Это да, по всяким скайпам пока невозможно сделать...

и рабочая обстановка.

м... И где же ты живёшь?

emulek
()
Ответ на: комментарий от stevejobs

очередной текстовый редактор написанный на (урезке плюсов, зато со сборщиком мусора)? try again

next_time ★★★★★
()
Ответ на: комментарий от emulek

Это тебе не C++ ООП, которое требует для себя x86 или чего-то подобного. Уродская архитектура x86 потому-то и живее всех живых, потому-что заточена на C++. ФП напротив: пофиг куда разворачивать(потому-что всё равно нужно разворачивать).

Ты так говоришь, как будто в том же С++ невозможно использовать либы скрывающие абстракции «разворачивания». Тем более, что С/С++ код тоже вполне оптимизируется до «степени неузнавания».

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от tailgunner

«Сижу курю хаскель» — хаскель чистый ф-ый ЯП, и далее: «Функциональный подход ближе к решению проблемы, а объектно-ориентированный к имитации действия абстрактной модели.»

ТС явно глаголил о превосходстве ФП над ООП, а названные вами языки главным образом ООП. Ну и, кроме того, как я уже сказал, всё равно на них не написано ни одного действительно крупного проекта (уровня КДЕ или Фотошоп, к примеру). При этом если скала, хотя бы, молодой ЯП, то окамлю 100 лет в обед.

next_time ★★★★★
()
Ответ на: комментарий от Hertz

Go зелёный ещё.

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

next_time ★★★★★
()
Ответ на: комментарий от next_time

ТС явно глаголил о превосходстве ФП над ООП

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

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Там и гибриды бесплатно заряжаются

баран это ты. У тебя логика отсутствует напрочь. Как ты умудрился буквы в слова научится складывать? Или ты раньше нормальным был?

emulek
()
Ответ на: комментарий от emulek

Автомобиль не электричка, да и электричка отдаёт назад совсем не 100% при торможении, а хорошо, если 20(с учётом того, что КПД аккумулятора тоже ниже 50%.

50 процентов уже давно умеют.

Pavval ★★★★★
()
Ответ на: комментарий от emulek

ты не так считаешь Оно «дешевле» в твоей розетке. Но пока оно доберётся до двигателя, оно подорожает в разы.

ЩИТО?

Pavval ★★★★★
()
Ответ на: комментарий от emulek

ФП не просто «разворачивается», а разворачивается в оптимальный для этого железа код.

Громкий хохот в зале, местами переходящий в истерику.

Pavval ★★★★★
()
Ответ на: комментарий от emulek

Это да, по всяким скайпам пока невозможно сделать...

Скайп не удобен. Кроме того, он лично еще и лично мне не удобен (чисто психологически), полагаю и далеко не только мне.

И где же ты живёшь?

Мне не удобно работать дома. У меня дома все обустроено для отдыха. То есть не все, хотелось бы, конечно, много еще чего... Но на работе нужно другое, а это мешает. Дома у меня небольшой стол, теплый свет, кровать, диван, телевизор, шторы на окнах и изначально немного места. Многое отвлекает. Кто побогаче потому обычно и оборудует себе дома «кабинет».

nightingale
()
Ответ на: комментарий от tailgunner

ТС был пьян, неадекватен и нес чушь

абсолютно согласен

Прежде чем цитировать его, посмотри, на что я отвечал.

вы отвечали человеку, который непосредственно оспорил утверждение ТС

впрочем, он же (надеюсь) нас и рассудит.

Pavval , Функциональное программирование должно вытеснить ООП. (комментарий) здесь вы имели в виду чистые ФП ЯП, такие как хаскель или (ФП+ООП) ЯП тоже?

next_time ★★★★★
()
Ответ на: комментарий от next_time

Чистые ФП ЯП. ФП+ООП вполне себе используется и не является уделом маргиналов.

Pavval ★★★★★
()
Ответ на: комментарий от next_time

он же (надеюсь) нас и рассудит.

Я не надеюсь.

Pavval> если ФП такое хорошее, то почему его используют чуть менее, чем нигде?

Pavval> ФП+ООП вполне себе используется

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

ответ был:

Чистые ФП ЯП ФП+ООП вполне себе используется и не является уделом маргиналов.

то есть я был прав

next_time ★★★★★
()
Ответ на: комментарий от DarkEld3r

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

ты не понимаешь: _любой_ плюсовый код будет дважды разименовывать указатель на виртуальный метод. Даже если ты это замаскируешь фантиком. Механизм ООП не изменится.

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

Указатели так и останутся, и внутри там будут те же 4(8) байт информации. Сам компилятор тоже никак не отличит тип foo*(с указателем на foo) от типа foo*, в котором лежит какой-то bar*. Если знаешь, что искать, ты это всегда найдёшь. Смотри, если ты написал клас «вектор», и клас «матрица» производный от «вектор», то тебе для того, что-бы выполнить метод vector->wtf(), который выводит «it is vector», нужно

1. прочитать память/регистр, где лежит сам указатель

2. прочитать память(не регистр), где лежат данные вектора, которые нам не нужны, но всё равно, нам нужно знать адрес VT, который лежит вместе с самим вектором, потому-что в п1 он не лезет (причём сами данные нам не нужны!)

3. прочитать адрес функции полученный из таблицы по адресу из п2, и собственно отдать ей выполнение.

Размер указателя в рантайме предопределён, и равен машинному слову(32/64 бит). Потому указатель не может хранить больше информации, чем то куда он указывает.

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

«разворачивать» нужно только ТАКОЙ механизм ООП. Если-бы new могла-бы выдавать не только указатель, но и что-то другое(XYZ например), то прямо в этом XYZ можно было хранить адрес VT. В этом случае, для вызова функции не нужно было-бы тыкать палочкой в поля класса, достаточно тыкать XYZ. Можно и заинлайтить, если XYZ константа(в смысле «константный указатель», который нельзя двигать и менять его тип, но можно менять данные). А в C++ получается, что константный указатель двигать нельзя, но можно сменить его тип (правда не как угодно, а только по иерархии класса), т.к. тип лежит с данными(частично). Т.е. константный указатель на утку нельзя передвинуть на другую утку(и на другого гуся тоже нельзя), но можно из утки сделать гуся. Бред какой-то по логике.

А всё потому, что C++ это на самом деле набор костылей для PureC, и это было неплохо в 80х (та логика), сейчас логика устарела, и её надо менять. Но не получается.

emulek
()
Ответ на: комментарий от Pavval

50 процентов уже давно умеют.

50% АКБ

50% мотор в качестве генератора

80% преобразователь(выпрямитель+зарядка АКБ) (причём уже второй, AFAIK тиристорный преобразователь может только в одну сторону работать)

получается ровно 20%.

emulek
()
Ответ на: комментарий от Pavval

ты не так считаешь Оно «дешевле» в твоей розетке. Но пока оно доберётся до двигателя, оно подорожает в разы.

ЩИТО?

а ты разве не знал, что в АКБ ёмкостью 100 А*ч нужно подавать 10А совсем не 10часов, а намного дольше(раза так в два)? И что мотор к колесу да, напрямую можно включить, но тогда этот мотор напрямую к АКБ не включишь. Тоже нужно такую электронную «коробку передач», КПД у которой почему-то не 100%.

emulek
()
Ответ на: комментарий от Pavval

ФП не просто «разворачивается», а разворачивается в оптимальный для этого железа код.

Громкий хохот в зале, местами переходящий в истерику.

это теория. Он _может_ разворачиваться. IRL да, до этого пока как до Китая. Раком(исключая x86)

emulek
()
Ответ на: комментарий от nightingale

Скайп не удобен. Кроме того, он лично еще и лично мне не удобен (чисто психологически), полагаю и далеко не только мне.

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

Но на работе нужно другое, а это мешает.

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

emulek
()
Ответ на: комментарий от tailgunner

Pavval> если ФП такое хорошее, то почему его используют чуть менее, чем нигде?

Pavval> ФП+ООП вполне себе используется

ну строго говоря я использую c++11, а это (формально) ФП+ООП. Но только формально, т.к. лично я не вижу смысла в ФП из c++11. Не отрицаю, может кому оно и нужно, и не против данной фичи, но сам не юзаю.

emulek
()
Ответ на: комментарий от emulek

Он _может_ разворачиваться. IRL да, до этого пока как до Китая. Раком(исключая x86)

Ну так ты сразу поясняй. А то без примечаний остается голое 4.2.

Pavval ★★★★★
()
Ответ на: комментарий от emulek

Кому-как, наверное... В принципе фриланс есть, но я так понимаю, там совсем не твой уровень :-) С другой стороны, если ты очень крутой программист, вполне вероятно, какие-то работодатели могут тебе и индивидуальные условия предоставить.

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

nightingale
()
Ответ на: комментарий от Pavval

ещё раз: считаем по разному. Я считаю всё: т.е. если для разгона до x км/ч нужно 1000Дж(из батареи, а вовсе не ½mv²), и в начале в АКБ было 2000Дж, сколько будет в АКБ после разгона до x км/ч и торможении до 0?

А ты наверняка считаешь ½mv² относительно того, что вернулось в виде электричества обратно в контактный провод.

emulek
()
Ответ на: комментарий от nightingale

В принципе фриланс есть, но я так понимаю, там совсем не твой уровень

там _любой_ уровень. Мой и твой тоже есть. Вопрос только в цене.

Лично мне идея работать дома не нравится сама по себе.

наверное ты никогда не ходил регулярно на работу хотя-бы с полгода каждый будний день. Я угадал?

emulek
()

въехал не сразу, но кажется это именно то чего не хватало

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

bhfq ★★★★★
()
Ответ на: комментарий от emulek

наверное ты никогда не ходил регулярно на работу хотя-бы с полгода каждый будний день. Я угадал?

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

nightingale
()
Ответ на: комментарий от nightingale

Да. Но шесть дней в неделю учусь (рядом с домом)

это всё совсем другое. Не объяснить, надо самому зае**ся. Ну и своё жильё(только своё) это тоже не объяснить.

emulek
()
Ответ на: комментарий от true_admin

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

Не знаю какое отношение это имеет к ФП/ООП но если вы спрашиваете: http://youtu.be/AX90oDuwhPk - от лосанжелеса до ньюйорка хватит? ;)

anonymous
()
Ответ на: комментарий от nightingale

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

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

Есть такая знаменитая цитата:

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

anonymous
()
Even if you are not in a position to use Haskell in your programming projects, learning Haskell can make you a better programmer in any language.

    I learned Haskell a couple of years ago, having previously programmed in Python and (many) other languages. Recently, I've been using Python for a project (the choice being determined by both technical and non-technical issues), and find my Python programming style is now heavily influenced (for the better, I hope ;-) by my Haskell programming experience.

    Graham Klyne 

действительно. стоило зайти на их сайт.

anonymous
()
Ответ на: комментарий от anonymous

Современные электромобили
по
безопасности даже уделывают

Это те, в которых аккумуляторы взрываются от удара по днищу?

feofan ★★★★★
()
Ответ на: комментарий от nightingale

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

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

Лично мне идея работать дома не нравится сама по себе.

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

anonymous
()
Ответ на: комментарий от emulek

Все пердишь, жалкий нищеброд из грязной, отсталой, дикой страны третьего мира?

anonymous
()
Ответ на: комментарий от emulek

ты не понимаешь: _любой_ плюсовый код будет дважды разименовывать указатель на виртуальный метод

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

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

Но вообще я подразумевал другое. Ты говорил о списке:

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

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

«разворачивать» нужно только ТАКОЙ механизм ООП.

Во первых, «такой» механизм ООП ведь далеко не только в С++. Или по твоему, в джаве/шарпе, да даже лиспе с его мультиметодами всё лучше?

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

Если что, то я не считаю С++ идеальным. Очень многое мне там не нравится. И наоборот - нравится в хаскеле (хотя я там ещё нуб). Просто с такой аргументацией категорически не согласен.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

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

интересно будет пофтыкать новости про термоядерный Чернобыль. Надеюсь, что он случится не в Этой Стране, а где-нить подальше отсюда...

автомобиль на скорости в 180 километров в час въехал

круто. Особенно учитывая знаменитый источник, откуда ты это не относящееся к теме говно надёргал.

emulek
()
Ответ на: комментарий от DarkEld3r

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

я как раз про полиморфные(только) и говорил.

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

да, есть. Я видел. Но там нет жёстких ограничений на указатели C++, в которых (в рантайме) кроме указателей ничего нет и быть не может.

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

с этим согласен, но при чём тут тогда ООП? Откуда ООП в STL? О чём мы вообще спорим? Я думал, про реализацию ООП в C++. И я говорил о том, что её ты никуда не спрячешь, и она всё равно будет торчать как шило в мешке, своей завязванностью на x86.

Во первых, «такой» механизм ООП ведь далеко не только в С++. Или по твоему, в джаве/шарпе, да даже лиспе с его мультиметодами всё лучше?

лучше. Потому что там new «отдаёт» объект, а не 4 байта указателя на объект. Потому мы можем прикрутить к этому объекту что угодно, и в рантайме в том числе. Если оно нужно можем. А если не нужно — можем отдать тупой указатель, как в сишке. Это вопрос конкретной реализации, что там как и когда отдавать. А вот в C++ operator new отдаёт _только_ 4/8 байт указателя.

Ещё вот такую аналогию придумал: есть ружьё, надо подстрелить утку. Очевидно, нужно сначала зарядить ружьё особым патроном(под утку). Но в C++ ты вынужден _сначала_ навести ружьё на утку, потом зарядить, а _потом_ выстрелить. Очевидно, это совсем нерационально, но ничего не поделаешь, такая семантика C++.

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

угу. Можно. Если задача не нуждается в ООП. А если нуждается, то любой нормальный кодер будет ЭТО ООП юзать, и соответственно завязывать свой код на x86. Потому как другого ООП в C++ нет.

Если что, то я не считаю С++ идеальным.

C++ конечно не идеальный, проблема в том, что ничего другого у нас и нет. Потому и пихают в этот наш C++ всё подряд, постепенно превращая его в такого же уродливого монстра, как x86.

Но ничего не поделаешь, такова жизнь.

emulek
()
Ответ на: комментарий от emulek

И что мотор к колесу да, напрямую можно включить, но тогда этот мотор напрямую к АКБ не включишь. Тоже нужно такую электронную «коробку передач», КПД у которой почему-то не 100%.

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

Waterlaz ★★★★★
()
Ответ на: комментарий от feofan

Это те, в которых аккумуляторы взрываются от удара по днищу?

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

anonymous
()
Ответ на: комментарий от emulek

интересно будет пофтыкать новости про термоядерный Чернобыль. Надеюсь, что он случится не в Этой Стране, а где-нить подальше отсюда...

Килотонны воды и гелия выброшены в атмосферу. Ужас!

круто. Особенно учитывая знаменитый источник, откуда ты это не относящееся к теме говно надёргал.

Поделись другими источниками.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.