• Перевод: Чему я научился за 30 лет программирования
    0
    Например qbasic :) Какой всё-таки замечательный был язык… :)
  • Весь PHP в двух строчках
    0
    Ну вот с точки зрения principle of least surprise чертова куча библиотек под си работает именно с таким соглашением, а это gtk+, mysql, gd и т.д., и если уж говорить о php — то в нём тоже большинство функций работы с массивами принимает первым аргументом массив, большинство функций работы со строками — строку, с регулярками — регулярярное выражение, это и есть то самое ожидаемое для программиста поведение.

    «все функции, принимающие на вход массив(ы) и callback должны иметь callback в одном и том же месте» — а что, в этом топике есть хоть один человек который с этим спорит? Должны, и это место — место второго аргумента по вышеобозначенному вами-же принципу, так как в php первый занят массивом в большинстве функций array_*.

    И за весь наш разговор ни одного аргумента в поддержку вашей позиции я пока не услышал, как собственно и самой позиции, подозреваю что их вообще нет. Адекватный спор — попытка доказать свою точку зрения, а не хамством опровергнуть чужую, поэтому считаю дискуссию закрытой, у меня нет желания приводить свои доводы и получать в ответ аргументы в виде «ну это в натуре бред», я себе не враг.
  • Весь PHP в двух строчках
    0
    Если функция называется array_filter — то первым аргументом она должна принимать массив, это ожидаемое от неё поведение, было-бы как минимум нелогично если-бы preg_replace принимал первым аргументом строку замены, а не шаблон регулярного выражения, str_split количество символов для разбивки строки, а не саму строку и т.п., так как у них в названии это написано:
    массив_фильтровать($массив, $чем_фильтровать);
    строку_разбить($строка, $на_сколько_символов_разбить);
    

    И тон смените, я вам спокойно излагаю свою позицию, а вместо аргументированного ответа получаю какое-то брызганье слюной.
  • Весь PHP в двух строчках
    0
    И что не так с array_filter? Сигнатура такая-же как у array_reduce, да и по логике оно так как должно быть, в объектном стиле это-бы выглядело $array->filter() / $array->reduce(), если рассматривать функцию как первичный аргумент относительно массивов, как в array_map — то тогда и называться они должны наоборот, function_filter_array, function_reduce_array и т.п., ну или в недостижимом идеале — как в других языках — просто filter, просто map, просто reduce, а префикс array_ однозначно указывает что в первую очередь операция производится над массивом, а уже потом какая, как и чем, это как-бы привычное человеческому восприятию соглашение об именовании, вон например в gtk+ — все функции gtk_window_* принимают первым аргументом структуру GtkWindow, что логично, gtk_widget_* соот-но GtkWidget и т.п.
  • Весь PHP в двух строчках
    0
    Это безусловно кривизна, но мотивы оной в документации описаны, array_map принимает несколько массивов, соот-но массив у него вторым параметром потому как может быть ещё и третий, четвертый и т.п., ради этого разработчики php решили испохабить его сигнатуру.
  • Я не знаю ООП
    0
    Так тогда я не понимаю что вас смущает, в объектах первого типа инкапсуляция важна — соот-но нужны геттеры и сеттеры, в объектах второго типа, раз уж они как объекты не используются, ее можно не соблюдать, тобишь для языков которые позволяют прямое обращение к публичным полям данных — использовать их, или например в ди, помимо полноценных объектов, есть структуры — как более легковесный аналог оным, с прямым доступом к данным, и ваши сомнения решаются вообще идеально, нет объекта — нет проблем :)
  • Почему ООП не отстой
    0
    Для языков без поддержки ООП и интерпретируемых языков — это так, с другой стороны компилируемый строго типизованный язык с поддержкой ООП таблицу вызовов может иметь только на этапе компиляции, и в результате переопределённые методы будут вызывать методы потомка, не переопределённые — родителя, так как тип (класс) на этапе компиляции будет известен.

    Так что с одной стороны вы конечно правы, а с другой, если возвращаться к теме нашей дискуссии — если сравнивать например си и ди, как два компилируемых языка, то обе записи, вокруг которых и развернулся спор, будут равнозначны, обе выделяют память, инициализируют данные и предоставляют методы для работы с оными, которые в свою очередь сводятся к передаче контекста (данных объекта/структуры) в функцию обработки оных, GDateTime реализованный в виде объекта тут ничем не проигрывает, даже наоборот — приобретает, тот-же самый полиморфизм.
  • Почему ООП не отстой
    0
    Там где нет нативной поддержки чего-либо — приходится довольствоваться соглашениями. В GTK например вызов gtk_window_new возвращает структуру, из которой, вычислив смещение, можно выцыганить, например, имя окна, что в принципе нарушает инкапсуляцию, однако-же есть соглашение так не делать, а пользоваться для этого функцией (методом) gtk_window_get_title. Или как в старом php или текущем яваскрипте — приватных методов и свойств нет, потому есть соглашение писать имена приватных методов с _, ничто не мешает вызывать их извне, но с точки зрения соглашения их можно вызывать только внутри объекта.

    Ну и в конце концов в тот-же GTK+ работает по тому-же принципу, и если цепочка наследования выглядит как GObject > GtkWidget > GtkBin > GtkWindow — то методы виджета нужно вызывать через gtk_widget_*, а методы окна через gtk_window_* — однако-же никто не спорит что GTK+ — объектно-ориентированная библиотека.

    Так что я повторюсь — это детали реализации ооп для конкретного языка/библиотеки и т.д. и т.п., где-то реализовано больше, где-то меньше, где-то так, где-то иначе.
  • Я не знаю ООП
    0
    На асме очень удобно под gtk+ писать, вызовы те-же, а накладных расходов на них в разы меньше, да и не нужно постоянно вызывать GTK_WIDGET, GTK_WINDOW и т.д. и т.п., можно просто передать указатель, типизации-то нет.
  • Почему ООП не отстой
    0
    И в чем проблема?
    void g_date_time_ext_add_month(GDateTimeExt* datetime, int month) {
      g_date_time_add_month((GDateTime*)datetime, month + 1);
    }
    

    Это уже детали реализации.
  • Я не знаю ООП
    0
    Так в этом и разница, вы не даете полный доступ к полям данных через методы, вы даете полный доступ к результатам работы методов, это могут быть поля данных в одной реализации, обработанные поля данных в наследнике, например, и левая байда из /dev/random в другой реализации, при этом сохраняя общий интерфейс.
  • Почему ООП не отстой
    0
    Хочу напомнить что си вообще не относится к языкам с нативной поддержкой ооп, и обобщённых алгоритмов работы с объектами в нём вообще нет, GObject — частная реализация библиотеки glib, тоже что реализация GDateTime не связан с GObject ровным счётом никакого отношения к нашему разговору не имеет.

    Но таки различие в чём? g_date_time_new — аллокатор, инициализирует данные, размещает их в памяти и возвращает на них ссылку, new DateTime тоже, g_datetime_add_* — работают, принимая первым аргументом контекст выполнения, в time.add* контекст указывается до точки, принципиальная разница где?

    И я таки на всякий случай отнаследую вам вашу структуру
    struct GDateTimeExt {
      struct GDateTime dateTime;
      gboolean extended;
    }
    
    gboolean g_date_time_ext_get_extended(GDateTimeExt* datetime) {
      return datetime.extended;
    }
    
    void g_date_time_ext_set_extended(GDateTimeExt* datetime, gboolean extended) {
      datetime.extended = extended;
    }
    
    int main(int argc, char** argv) {
      GDateTimeExt* datetime = g_date_time_ext_new();
      g_date_time_add_month((GDateTime*)datetime, 1);
      g_date_time_ext_set_extended(datetime, TRUE);
      return 0;
    }
    
  • Почему ООП не отстой
    +1
    И в чем-же тогда его отличия от класса? Даже так, в чем кардинальные отличия двух приведённых мной вариантов?
  • Почему ООП не отстой
    0
    А, ну это безусловно, каждая команда си — это десяток, если не сотня драгоценных ассемблерных инструкций! К тому-же инлайновое переписывание команды printf заново — на си могут счесть говнокодом, а на ассемблере это уникальная, эффективная реализация и устранение внешних зависимостей :)
  • Почему ООП не отстой
    0
    «бозон Хиггса — это непонятная хрень» — а вы разве не согласны? :)
  • Почему ООП не отстой
    0
    Не понял о чем вы — но наверное да :)
  • Почему ООП не отстой
    +2
    Мы-то разговор ведем в ключе того что ленивые программисты придумали мерзкий ооп чтобы кода больше вышло — так что с этой точки зрения самый эффективный код вот:
    	mov eax, источник
    	mov ebx, назначение
    	mov ecx, 10
    loop:
    	dec ecx
    	mov byte [ebx], [eax]
    	inc eax
    	inc ebx
    	cmp ecx, 0
    	jnz loop
    

    строчек — аж целых 10!
  • Почему ООП не отстой
    0
    Вы шутите? Это-же ассемблер, одна инструкция — одна строка, и каждая инструкция — низкоуровневая, для копирования области памяти через индексные регистры их уже нужно 4, да и для вызова процедуры копирования памяти столько-же, так как 3 инструкции — для задания откуда, куда и сколько, которые нужны так или иначе, 300 строк тут — вообще пшик, было-бы желание.
  • Почему ООП не отстой
    +3
    Даже смущаюсь спросить, это
    GDateTime* time = g_datetime_new();
    g_datetime_add_years(time, 1);
    g_datetime_add_months(time, 2);
    g_datetime_add_weeks(time, 3);
    g_datetime_add_days(time, 4);
    

    и это
    DateTime time = new DateTime();
    time.addYears(1);
    time.addMonths(2);
    time.addWeeks(3);
    time.addDays(4);
    

    не кажется вам слегка похожим? Только не приходится каждый раз писать g_datetime_, оно в принципе во всех биндингах gtk+ на объектно-ориентированные языки примерно так и выглядит.
  • Почему ООП не отстой
    0
    А как-же call/ret? В асме тоже есть процедуры :)
  • Почему ООП не отстой
    +6
    Это наверно потому что GTK+ с Glib'ом вместе — объектно-ориентированные? :)
    ООП — парадигма, а не набор операторов языка, и там где есть данные, сгруппированные в единую сущность (в GTK они представлены в виде структур), и методы работы с ними — там присутствует и оно, и все его особенности, и все его плюсы и минусы.

    Но если по порядку — для описания сколько-либо комплексного объекта одной скалярной переменной недостаточно — нужно несколько, хранить их в массиве — неудобно, да и типы у них могут быть разные, соот-но нужна структура, чтобы не было overhead'а при передаче этой структуры внутри кода — её необходимо передавать по ссылке, обрабатывать данные структуры на месте — несерьёзно, нужны функции обработки, передавать каждую порцию данных отдельно — глупо, функции может понадобится ещё одна и придётся менять сигнатуру, поэтому передается ссылка на всю структуру целиком — и вот у нас уже и поля данные, сгруппированные в объект, передающийся по ссылке, с собственными методами.

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

    А на случай если и против процедурного программирования есть претензии — то там тоже все просто, каждый раз один и тот-же кусок кода писать долго и не прикольно, а ещё программы от этого сильно разрастаются — потому вумные дядьки из outer world придумали выносить их в процедуры, в старых бейсиках например использовали goto туда — goto обратно за неимением других вариантов, а уж в си, паскале и их наследниках они из коробки есть.

    Вот так вот по аналогии с процедурным программированием на головы ничего не подозревающих программистов настал ООП, и если в каком-то языке, как в старых бейсках без процедур, его поддержки нет — это ещё не значит что его там нет.
  • Ремонтируем монитор содой!
    +39
    Ну так сода которую не пропитал клей ведь останется просто содой, смысл на неё просто «капнуть»? Или вы рассчитываете на цепную реакцию, один раз капнул — и вся сода в радиусе 10 миль… :)
  • Блокирующие Wi-Fi обои можно будет купить в следующем году
    0
    Ну так вот, эти обои как раз для вас, обклеить всю комнату и подключить как антенну :)
  • Некоторые инженерные практики для улучшения качества web application на PHP
    0
    Тьфу ты блин, забылся в какого года я топике :)
  • Некоторые инженерные практики для улучшения качества web application на PHP
    +1
    Держи, коллега :) piece-framework.com/projects/makegood
  • Доступ к статическим данным
    0
    Помимо
    $object::static_method()

    работает также и
    $string::static_method()

    с именем класса в $string, php же, надо же и так, и сяк… :)
  • Российский программист получил 60 тысяч долларов за найденную уязвимость Chrome
    +3
    60к$ — с вашей предлагаемой зарплатой в 50к — это уже 3 года работы, если не потратить при этом ни копейки, с учётом того что ещё кушать порой надо, ходить не в лохмотьях, проплачивать коммунальные услуги (а это ещё только необходимый минимум) — это уже 4-5 лет.

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

    Так что может эта сумма и недостаточно хороша чтобы её показывали в фильмах про кокаин, и дипломат она целиком не заполнит, однако же если собирать её нужно на протяжении такого времени — кому-то она может показаться недостижимой, и уж безусловно ответить на это «мне вас жаль» — верх хамства. Засим — мне вас жаль.
  • Опубликован стоп-лист зон.РФ и .RU
    0
    тьфу, тоже спросоня не так цитирую,
    из всех известных ему „веселых“ слов

    в общем нового-то он уже ничего не найдет :)
  • Опубликован стоп-лист зон.РФ и .RU
    0
    пользователь начал подбирать домены из всех известных ему

    И от чего его тогда уже «ограждать»? :)
  • Новая технология позволяет убирать случайных «попутчиков» с фотографии
    0
    Новость уже не нова: habrahabr.ru/blogs/image_processing/138361/
  • Что не спрашивать на технических интервью
    +6
    Первый вопрос меня самого повергает в пучину лютой злобы, а на счёт второго — имхо если-бы не «личное» качество, то с ним все было-бы ок, процесс трудоустройства это таки процесс торговли труда на его эквивалент, а в торговле надо уметь показать товар лицом. Другое дело что «личное» ограничивает диапазон качеств, и похвастать знаниями и умениями, действительно полезными в командной разработке — уже нельзя.
  • Отменены таможенные пошлины на процессоры до 32 нм. Российские производители недовольны
    +4
    Ну вроде какие-то процессоры на 180нм тех.процессе наши производители производят, но про это и разговор — 180нм тех.процесс, да ещё и по тем ценам, что их продают — на хрен никому не нужны, даже без налоговых пошлин такие производители как Intel или AMD обходят их по всем параметрам, и даже трофейная линия AMD на 90нм ситуацию имхо не спасет.
  • Отменены таможенные пошлины на процессоры до 32 нм. Российские производители недовольны
    0
    Нету по-моему у AMD тут производства, разве что одним из «российских производителей» вроде как была куплена древняя производственная линия AMD по производству процессоров на базе 90нм тех.процесса, по-крайней мере в новостях это фигурировало, и в контексте новости AMD тут просто сделали крайним :)

    А так имхо любые налоговые льготы что для Intel'а, что для AMD — одинаково убьют на корню все российское процессорное производство, потому как у обоих налаженные высокотехнологичные линии производства, освоенный 32нм тех.процесс и т.п. Впрочем даже без налоговых льгот имхо российским производителям приходится нелегко, очень уж велика разница в технологиях, это как телегу с космолётом сравнивать.
  • Павел Дуров выступил на конференции DLD 2012
    +5
    Так разве ораторские способности не из речи и жестикуляции складываются? Уверен что как минимум 50% apple'овских продаж основывались на сотрясании руками и возгласах «Amazing! Brilliant!» Стива Джобса :)
  • Павел Дуров выступил на конференции DLD 2012
    +6
    По-моему до Джобса ему ещё, мягко говоря, далеко. Тот был оратором хоть куда.
  • Павел Дуров выступил на конференции DLD 2012
    +4
    Ну так, для первого выступления вполне неплохо, словарный запас у него более-менее разнообразный, с «ай спик фром май харт» не сравнить, а то что с интонациями не ахти — так волнуется наверное, только вот паразитное «а» в перерывах между фразами — с момента как я его заметил прошла пара минут — а оно уже сводит меня с ума :) «As you can see on this graph… А!.. more altruistic… A!» :) Еще блин громко так :)
  • Павел Дуров выступил на конференции DLD 2012
    –6
    Да ну, ни скандалов, ни интриг, ни расследований, лучше бы Цукербергу объяснил как ему пришла в голову мысль сделать такую чудесную социальную сеть :)
  • Подводный камень в foreach($items as &$item)
    0
    Вот при работе с встроенными функциями array_map действительно хорош, а при вызове пользовательских идут расходы на смену контекста выполнения, для задачи вроде $a += 2 — это имхо неоправданные траты.
  • Подводный камень в foreach($items as &$item)
    0
    Да это я с extract'ом напортачил, префикс работает только когда указан один из ключей EXTR_PREFIX_*, ну и после префикса еще подчеркивание, соот-но правильно будет так:
    $a_0 = str_repeat('*', 1000);
    
    extract(array_combine(range(1, 1000), array_fill(1, 1000, null)), EXTR_PREFIX_ALL, 'a');
    
    echo memory_get_usage() . '<br />';
    
    for($i = 1; $i < 1000; $i++) {
    	${'a_' . $i} = $a_0;
    }
    
    echo memory_get_usage() . '<br />';
    
    for($i = 1; $i < 1000; $i++) {
    	${'a_' . $i} = str_repeat('*', 1000);
    }
    
    echo memory_get_usage() . '<br />';
    
  • Подводный камень в foreach($items as &$item)
    +1
    Ну php проектировался с одной главной идеей — он должен быть простым языком, понятным всем, а блочные области видимости это довольно таки сложно для понимания новичка.
    P.S. не удивлюсь если лет через 100 на нём разговаривать начнут, вместо теперешнего эсперанто :)