Смартлабу нужен кодер php\mysql

Тимофей Мартынов, ну как бы я программист который делал консъерж сервис визы, инет магазины, работал с рэмблер, киви, занимался интеграцией всей этой херни на сайты… вот как-то так.

просто чтобы подробнее понимали задучу

alex pro, и очень зря! :) В айтишном мире удаленная работа уже несколько лет считается обыденностью. Для дизайнеров, программистов и других творческих специальностей — лучшие условия трудно найти.

Почасовая оплата выгодна, если работать больше или меньше среднестатистического дня. Это очень удобная форма сотрудничества, но требующая хорошей самодисциплины от исполнителя. Хочется работать час и идти отдыхать — пожалуйста; хватает сил на десять часов труда — отлично! Так что тут сам себе устанавливаешь верхний порог в зарплате. Сколько поработаешь — столько и заработаешь. :)

Со школотой отдельная тема, у них свой сегмент.

выгоднее снять квартиру и обустроить ее соответствующим образом «под офис»

если предлагали организовать это полностью за счет компании

не поверишь

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

Интересно, что сказали бы о таком апологеты офисного прозябания… 

Тимофей Мартынов, на не mainstream — людей меньше и они дороже, да и в данной задаче не факт технологическое преимущество перерастет в адекватную финансовую отдачу.

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

Есть много секторов бизнеса — тот же финтех, где ошибка в коде может стоить очень дорого.

meat, чушь у тебя в голове. вероятно частное не было понято.
если говорить в общем — в php даже элементарных дженериков на уровне языка нету. поэтому я молчу о ковариантности и контравариантности. php до системы типов java еще шагать и шагать, а система типов scala и haskell на порядок сложнее. какой нормальный статический анализ получится ?

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

ошибка в коде может стоить очень дорого

php даже элементарных дженериков на уровне языка нету

meat, статический анализ — это образно проверка соответствует ли данный код системе типов языка или нет. если система типов простая — то и проверка простая. нету у тебя дженириков в языке — твой статический анализ не сможет гарантированно обнаружить ошибку когда ты не правильно работаешь с элементами хэш-а/массива. чем сложнее система типов — тем больше гарантий, на уровне scala, haskell успешная компиляция значит что все уже неплохо и проверок там значительно больше.
Чем сложнее система типов языка — тем меньше тестов в случае правильного ее использования. то что php что то умеет из статического анализа я не спорю, но это совсем не много.

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

meat, лаконичность — это когда несколько строк по возможности заменяют простыни, т.е. в языке есть разнообразные инструменты абстракции в том числе встраиваемые DSL (domain specific language), чем меньше строк тем проще валидировать, найти ошибку или менять бизнес логику.

правильные абстракций которые можно повторно использовать очень полезны и сокращают тестирование

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

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

meat, твое определение о DSL в общем виде, а я пишу о embedded DSL — дополняющих основной язык программирования.

Совсем простой и немного притянутый за уши пример: допустим в неком php коде активно используется циклы, но так как операторы циклов в php довольно бедные — кода получается много, для примера в common-lisp есть один из самых мощных операторов циклов loop (http://lisper.ru/pcl/loop-for-black-belts), и более того если loop мало есть библиотека iterate c еще более мощным операторов циклов (https://common-lisp.net/project/iterate/doc/index.html). Можно даже сказать loop и iterate - спец. встраиваемые языки для описания итераций (embedded DSL).

Вернемся к коду, если бы в php был циклический оператор который мог сделать minimizing/maximizing и некую логику за один проход как loop или iterate или возможность определить такой оператор  — это бы сильно сократило наш код.

Применять эти вещи конечно стоит далеко не во всех ситуациях, но сама возможность адаптировать язык под задачу очень полезна.

так как операторы циклов в php довольно бедные — кода получается много

meat,  php-peg - внешний кодогенератор, нужно запустить:
php ./cli.php ExampleParser.peg.inc > ExampleParser.php<br /> а грамматика задается в виде комментария — а не как часть языка со статической проверкой.

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

Существовало 14 различных мессенджеров и возникла идея их всех объединить: в итоге стало 15 мессенджеров

dnmsk, я бы все-таки не обобщал — языки с другим синтаксисом и языки с другой парадигмой.