Форум 'Философия программирования' на RSDN.RU

Object.equals

Fri, 10 Feb 2012 09:54:26 GMT

Задача (Java): Определить класс EqualToTheObject, экземпляр которого ссылается на экземпляр класса Object, и переопределяет equals таким образом, что equals возвращает true тогда и только тогда, когда его аргумент является тем же экземпляром класса Object, на который ссылается this, или экземпляром класса EqualToTheObject ссылающегося на тот же экземпляр класса Object, на который ссылается this.

Отношение эквивалентности должно является рефлексивным, симметричным и транзитивным, но симметричным его похоже на Java сделать не удастся. То есть задача непротиворечива, но отсутствие мультиметодов делает ее решение невозможным.

Аналогично для .NET.

Если так, то вся эта сраная единая Java/.NET иерархия классов ущербна в самом своем корне.

самый простой язык программирования.

Fri, 10 Feb 2012 08:02:54 GMT

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

достаточно иметь IF, GOTO и LABEL? что-то еще?

Будущее программирования - обсудим?

Tue, 07 Feb 2012 22:09:41 GMT

http://ajc.su/koding/budushhee-programmirovaniya/

[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]

Как будет выглядеть программирование через 10-20 лет? В канун нового года самое время пофилософствовать о будущем нашей индустрии. Мы находимся на пороге значительных изменений в деле написания программ, по сравнению с которыми нынешние, 2011 года, техники и идеи будут выглядеть примитивными. Изменения будут происходить в нескольких важных областях: инструментария и инфраструктуры, языков и систем типов, систем времени исполнения.
...

Что-то не так с головой

Mon, 06 Feb 2012 09:44:46 GMT

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

А что если предположить, что баг не должно быть вообще? Почему человек не может думать без ошибок? В чем причина ошибок?

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

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

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

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

*Под абстракцией понимается выделение существенного.

Тюринг-полные ли шаблоны C++?

Sat, 04 Feb 2012 10:02:51 GMT

Здравствуйте, catbert, Вы писали:

C>Тем не менее, шаблоны не "плохи". Они чудесно выполняют свою главную функцию (поддержка обобщенного программирования), да еще и Тюринг-полны. Но в реалиях .НЕТ-а, имхо, более оптимальным выбором метапрограммирования являются макросы+генерики.

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

Но вот макросы + генерики это хорошая комбинация, но как оказалось еще не совсем совершенная, если мы не можем использовать аргументы типа T в самих макросах, тут нужно еще промежуточное решение.

05.02.12 03:18: Ветка выделена из темы чем плохи шаблоны? — VladD2

05.02.12 03:19: Перенесено модератором из 'Nemerle' — VladD2

Иерархия геометрических фигур

Thu, 02 Feb 2012 13:18:36 GMT

В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?

Кол-во скриптов на странице

Thu, 02 Feb 2012 12:25:10 GMT

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

вообще какие есть критерии на размер загружаемых скриптов на страницу?

Что такое полиморфизм?

Wed, 01 Feb 2012 21:53:40 GMT

Только начинаю касаться ООП.
Подскажите, а что такое Полиморфизм. Ну вообще не догоняю. Если лучше на примере, можно и пример, просто и примитивный.
Везде какой то бред написан, нихрена не пойму.
Вот что такое Инкапсуляция, Наследование — это понятно. Это я вижу где приминить можно, где воспользоваться и т.д. А вот Полиморфизм вообще никуда не упирается.

Наводит на определённые размышления. [hate]javacript[/hate]

Wed, 01 Feb 2012 03:12:35 GMT

http://www.codeproject.com/Articles/321716/The-New-Emperors-Clothes-Abuse-of-Web-Technology

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

[Firefox] Битва за память

Wed, 01 Feb 2012 02:42:16 GMT

Интересный доклад о том, как команда MemShrink борется за уменьшение отъедаемой лисичкой памяти

Notes on Reducing Firefox’s Memory Consumption
http://blog.mozilla.com/nnethercote/2012/01/17/notes-on-reducing-firefoxs-memory-consumption/

Особенно порадовали примеры безбашенных запросов памяти типа 1МБ+2байта и профилировщик памяти SQLite, который сам по себе удваивает отжираемую SQLite-ом память.

Так все-таки, что же не так с ООП?

Sun, 29 Jan 2012 11:42:12 GMT

Коллеги,
хочу в отдельной теме высказаться в продолжение топика Что-то нетак с ООП

Я думаю, что главная проблема ООП совсем не в ООП, а в людях, которые некогда превратили его в религию. Даже в университете, как я помню, наc учили в духе, что ООП — это Единственный Истинный Путь (как любил говорить один художник: "Ein Volk, ein Reich, ein Führer"). Отсюда и проблемы. Когда же к ООП относятся просто как к ещё одному инструменту из арсенала разработчика, таких проблем не возникает.

Только, вот, это беда не только ООП — это беда нашей индустрии вообще. Периодически появляются какие-то мессии в виде отдельных людей или корпораций, которые начинают двигать очередную модную идею или технологию, провозглашая её спасением от всех наших бед (в какой уж раз!) и будущим разработки программного обеспечения. Если этот посыл подхватывается массами, то проблемы гарантированы: много людей начнет следовать новым идеям, не понимая их до конца, и тем яростнее их отстаивая, чем примитивнее их понимание. Сколько таких религий уже было и прошло! ООБД ("реляционные СУБД умрут!"), разный веб ("десктопные приложения умрут!"), виртуальные машины ("нативный код умрёт!"), разные новые языки ("С++ умрёт!") и платформы ("вообще все умрут...").

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

Вот сейчас, например, такой "модной фишкой" является agile и scrum. Подчас его пытаются силой натянуть на те проекты, где он совсем не нужен, как тот презерватив на глобус. Опять же, проблема не в agile, проблема в тех, кто слишком уверовал в его чудодейственную силу.

Проблема в людях.

Фундаментальный постулат программирования

Sat, 28 Jan 2012 12:18:53 GMT

Здравствуйте!

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

а) Последовательность (инструкции выполняются в определенной последовательности)
б) Ветвление, развилки (конструкции if-else, switch)
в) Повтор (циклы любого рода)

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

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

Заранее благодарен

Дмитрий Писаренко

Пишем опердень (краткое руководство)

Fri, 27 Jan 2012 23:39:55 GMT

:p.
Знакомьтесь: опердень, от слов "операционный день" — система автоматизации банка. Очень сложная и запутанная штука, кстати. Что надо знать, чтобы написать настоящую опердень? Это целая традиция программирования.

:p.
Во-первых, для того, чтобы написать её, требуется оператор безусловного перехода "goto". В языках Алгол, Фортран и M$ Visual Basic он так и назывался: "goto". В более современных языках он называется "trycatch" — теперь это *так* называется.

:p.
Во-вторых, подлинная, настоящая опердень требует глобальных переменных. Без них создать её не удастся. "Не боги горшки обжигают". Попросту не удастся. Так вот, в далёком прошлом, когда программы были маленькими, а компьютеры большими, они так и назывались: перем^bнныя общ^bга пользованнiа, они же глобальные. Переменные. Сегодня это называется "поля в объектах". Те же глобальные переменные, только для ограниченного числа подпрограмм (процедур, функций: теперь это *так* называется).

:p.
В-третьих, истинная опердень требует указателей. Совершенно необходимо, чтобы все данные были свалены в общую кучу с доступом через указатели — это традиция программирования. Раньше это так и называлось: "указатели", но пользоваться ими обжигатели горшков не могли, поэтому указатели заменили на ссылки (не забыв и пустые ссылки). Другая обёртка, но смысл тот же.

:p.
В-четвёртых, опердень недостижима без смешения кода и данных. И наоборот, достижима исключительно посредством смешения кода (и данных). Раньше всё так и было: смешение кода и данных, а сегодня это выглядит как доступ к объектам по ссылке и вызов функций (методов классов) для работы с данными в объектах, вызванных по ссылке, когда эти функции получают ссылки на данные, через которые они же и вызваны (по ссылке: если вы не зарыдали на этом месте, то вы сможете написать опердень — хотя для настоящего программирования вы, безусловно, потеряны... но кого это волнует?)

:p.
В-пятых, и это самое важное, опердень недостижима без наследования. Поскольку заказчик постоянно меняет требования, вначале он хочет пулемёт, затем тачанку, затем танк... надо просто "унаследовать" тачанку от пулемёта, а затем танк — от тачанки. При этом не забыть перемешать не только код (и данные), но и указатели внутри данных, чтобы тачанка ссылалась на пулемёт, пулемёт ссылался на танк, танк ссылался на пулемёт, пулемёт ссылался на танк, и танк — на тачанку.

:p.
И последнее: не должно быть никакого предварительного связывания. А с типами данных будет разбираться сама опердень, она большая и сложная. Иначе танк может не взлететь, а это очень опасно. Так что всё то, что раньше называлось "оверлейные модули", сегодня называется "полиморфизм", "инкапсуляция", "наследование" и "объектно-ориентированное программирование". Как стало известно из новейших археологических изысканий, традиция идёт от языка Алгол-58.

Mind map - buzzword or ...?

Thu, 26 Jan 2012 06:05:16 GMT

Приветствую, коллеги!

Вот в инетах много шумят по поводу карт памяти/ума/разума aka mind maps.
Но шум все больше сводится к продаже книг и тренингов, а примеры карт, которые я видел, сводятся к банальной классификации (т.е. просто составлению многоуровневого списка, но в прикольной графической форме).
Т.е. все это выглядит очередной серебряной пулей и банальным разводиловом, особенно учитывая то, что сам термин "Mind map" зарегистрирован в качестве торговой марки автором книг по сабжу.

Так вот, это просто очередной buzzword, или кто-нибудь в реальной работе успешно пользуется этими картами (если это не работа тренером по использованию этих самых карт, ессно)?
Поделитесь своими соображениями и опытом.

Что почитать по javascript?

Mon, 23 Jan 2012 11:02:26 GMT

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

Фантазии на тему повторного использования в ООП...

Mon, 23 Jan 2012 02:09:56 GMT

...Или умный copy/past.

Предположим, что имеется следующая структура классов:

public class X
{
    public void Method() {}
    public void AnotherMethod() {}
}

public class Y
{
    public void Method() {}
    public void AnotherMethod() {}
}

public class B
{
    private X x;

    public B(X x) { this.x = x; }

    public void Method() { x.Method(); }
    public void AnotherMethod() {}
}

public class C
{
    private Y y;

    public C(Y y) { this.y = y; }

    public void Method() { y.Method(); }
    public void AnotherMethod() {}
}

public class A
{
    private B b;
    private C c;

    private string name;
    private string anotherName;
    private int count;
    private int anotherCount;

    public A(B b, C c, string name, string anotherName, int count, int anotherCount)
    {
        this.b = b;
        this.c = c;
        this.name = name;
        this.anotherName = anotherName;
        this.count = count;
        this.anotherCount = anotherCount;
    }

    public void ImportantMethod()
    {
        b.Method();

        this.name = "Some message...";
        this.count = 1234;

        c.Method();
    }

    public void AnotherImportantMethod()
    {
        b.AnotherMethod();

        this.anotherName = "Some another message...";
        this.anotherCount = 1357;

        c.AnotherMethod();
    }
}

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

Тулза в новых исходниках создаст следующее:

public class A
{
    private string name;
    private int count;

    public A(..., string name, int count)
    {
        ...
        this.name = name;
        this.count = count;
    }

    public void ImportantMethod()
    {
        ...

        this.name = "Some message...";
        this.count = 1234;

        ...
    }
}

Далее для каждого ипользуемого в методе класса тулза предложит на выбор:
1. Создать интерфейс по этому классу
2. Cоздать используемый класс вместе с используемыми методами

public class BServer // Первый вариант
{
    void Method();
}

public class C // Второй вариант
{
    public C(...) { ... }

    public void Method() { ... }
}

public class A
{
    private BServer b;
    private C c;

    private string name;
    private int count;

    public A(BServer b, C c, string name, int count)
    {
        this.b = b;
        this.c = c;
        this.name = name;
        this.count = count;
    }

    public void ImportantMethod()
    {
        b.Method();

        this.name = "Some message...";
        this.count = 1234;

        c.Method();
    }
}

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

И так далее по рекурсии...

Соответственно, если после этого мы укажем тулзе, что хотим повторно использовать метод AnotherImportantMethod из класса A, она проделает всю ту же работу, только для новых исходников будет использовать уже ранее скопированные. Т.е. в данном примере мы получим практически первоначальные классы A, B, C и так далее зависимые:

public class BServer
{
    void Method();
    void AnotherMethod();
}

public class C
{
    public C(...) { ... }

    public void Method() { ... }
    public void AnotherMethod() {}
}

public class A
{
    private BServer b;
    private C c;

    private string name;
    private string anotherName;
    private int count;
    private int anotherCount;

    public A(BServer b, C c, string name, string anotherName, int count, int anotherCount)
    {
        this.b = b;
        this.c = c;
        this.name = name;
        this.anotherName = anotherName;
        this.count = count;
        this.anotherCount = anotherCount;
    }

    public void ImportantMethod()
    {
        b.Method();

        this.name = "Some message...";
        this.count = 1234;

        c.Method();
    }

    public void AnotherImportantMethod()
    {
        b.AnotherMethod();

        this.anotherName = "Some another message...";
        this.anotherCount = 1357;

        c.AnotherMethod();
    }
}

Найдет ли подобная тулза применение?

Баланс клиента: хранить или вычислять

Thu, 19 Jan 2012 13:44:50 GMT

Вот есть у нак таблица Карты.
И есть таблица ОперацииПоКартам, в которой есть дата и сумма операции

Вот задался вопросом о получении баланса по карте.
Как лучше? сделать поле Balance в таблице Карты и изменять его после каждой операции или же динамически вычеслять баланс на основании операций?

Java vs. C#

Wed, 18 Jan 2012 16:47:22 GMT

То, что C# вышел из Java — несомненно.
То, что дальше они развивались в одном и том же направлении до поры до времени — тоже. И дженерики, и аннотации (атрибуты) появились и там и здесь (пусть и есть отличия в деталях). Кто ввел раньше, кто позже — не в этом суть.

А вот дальше — стоп. C# полез в ФП, а Java — нет.

Почему ?

Основная ниша-то у них общая есть — серверное программирование. Пусть есть и другие ниши, но их роль все равно меньше.

Что-то нетак с ООП

Wed, 18 Jan 2012 11:20:23 GMT

Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ООП. Складывается впечатление, что ООП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

GoingNative 2012

Tue, 17 Jan 2012 00:16:28 GMT

Думал сначала в С++ запостить, но раз уж это даже на LtU есть (с пометкой "For those of you who don't hate C++" ), решил сюда

Day 1 (Theme: C++11 Today)
• Opening Keynote: C++11 Style (Bjarne Stroustrup, TAMU)
• Threads and Shared Variables in C++11 (Hans Boehm, Hewlett-Packard)
• STL11 – Magic && Secrets (Stephan T. Lavavej, Microsoft)
• Variadic Templates are Funadic (Andrei Alexandrescu, Facebook)
• Panel: The Importance of Being Native (Andrei Alexandrescu, Hans Boehm, Bjarne Stroustrup, Herb Sutter)

Day 2 (Theme: C++11 Today and Tomorrow)
• C++11, VC++11 and Beyond (Herb Sutter, Microsoft)
• C++11 and Clang (Chandler Garruth, Google)
• Static If I Had a Hammer (Andrei Alexandrescu, Facebook)
• A Concept Design for C++ (Bjarne Stroustrup and Andrew Sutton, TAMU)
• Panel: Ask Us Anything! (all speakers)

http://channel9.msdn.com/Events/GoingNative/GoingNative-2012

Главный рулез в том, что все это будет транслироваться в инете, так что необязательно ехать в Редмонд