Конференцию PHP Central Europe отменили из-за того, что среди выступающих не оказалось женщин

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

Конференцию PHP Central Europe отменили из-за того, что среди выступающих не оказалось женщин

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

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

Так нетипизированный язык же, в том же котлине будет очевидно:

fun main() {
    val fruitRepository = FruitRepository(
            Fruit(type = "apple", price = 1.99.toBigDecimal()),
            Fruit(type = "orange", price = 2.99.toBigDecimal()),
            Fruit(type = "grape", price = 44.95.toBigDecimal())
    )

    val price = fruitRepository.findFruitPriceByType("apple")

    println(price ?: "priceless")
}

data class Fruit(val type: String, val price: BigDecimal)

class FruitRepository(vararg fruits: Fruit) {

    private val index = fruits.map { it.type to it }.toMap()

    fun findFruitByType(type: String): Fruit? = index[type]

    fun findFruitPriceByType(type: String): BigDecimal? = findFruitByType(type)?.price
}

Не морочьте мне голову со своим функциональным программированием

[deleted]

Аудио через Bluetooth: максимально подробно о профилях, кодеках и устройствах

В итоге приходится использовать a2dp+мирофон ноута, потому что качество звука hsp слишком низкое. Патч для линукса — это интересное решение, но так с ходу не могу найти в гугле куда смотреть, посоветуете? Я правильно понял, что только FastStream позволяет решить этот задачу?

Аудио через Bluetooth: максимально подробно о профилях, кодеках и устройствах

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

10 принципов объектно-ориентированного программирования, о которых должен знать каждый разработчик

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

10 принципов объектно-ориентированного программирования, о которых должен знать каждый разработчик

Да, почему-то очень любят использовать связь прямоугольник-квардрат как иллюстрацию наследования, хотя это очень плохой пример и (подумав) такой код никогда в реальной жизни не напишешь. Мало того, что очень сложно выбрать, кто от кого наследуется, так еще и сразу начинают лезть несоответствия вроде того, что описал Frintezza93. Из за этого обычно не рекомендуют наследоваться от реализаций, но только от специально подготовленных астрактных классов или еще лучше реализовывать интерфейсы типа Figure с метдами вроде area() и дргуих.

Почему язык Go плох для НЕумных программистов

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

Функциональная обработка ошибок в Kotlin с помощью Arrow

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

inline fun <R> tryOrNull(block: () -> R?): R? = try {
    block()
} catch (e: Exception) {
    null
}

fun aaa() {
    listOf(1, 2, 3).mapNotNull { tryOrNull { it / 0 } }
}

Функциональная обработка ошибок в Kotlin с помощью Arrow

Нет, не тоже самое. Вы просто проглотили исключение. В Try же exception есть и в конце статьи написано как оно может быть обработано.

ну да, если его надо обработать выше, надо просто этот же код написать выше, в чем тут проблема-то? и `try` надо только в одном месте написать.

цепочку из монад с дальнейшей обработкой

вызов метдов с `try-catch` это разве не цепочка с обработкой? в чем профит-то?
Усложнение всё-таки должно быть чем-то оправдано, того, что я увидел в статье явно не хватает, чтобы взять это в использование в каких-то реальных кейзах, которые я использую. Я использую цепочки обработки для коллекций, например, там понятно, что мы получаем, декларативность, скрываем не относящийся к происходящему и повторяющийся код, а тут что? Заменили один механизм из коробки на другой из библиотеки, при этом декларативности особенной или переиспользования или понятности не получили, только усложнение и дополнительные зависимости.

Функциональная обработка ошибок в Kotlin с помощью Arrow

Честно говоря, совершенно не убедительно. Профита не видно. Какой смысл оборачивать в Try всё подряд, если тоже самое делает обычный try-catch и поддержка nullability, типа

fun makeRequest(request: String): List<Any>? = try {
    listOf()
} catch (e: Exception) {
    null
}

fun main(args: Array<String>) {
    makeRequest("body")?.let { 
        it.map { it.toString() } 
    } ?: emptyList()
}

тоже самое, только из коробки, без доп-оберток и матчинг эксепшена по типу

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

Простота — это красота.

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

Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC

я это все к тому, что намного интереснее было бы посмотреть на транслятор, чем на парсер

Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC

мы ведь тут говорим и запуске шейдеров, а не о скриптовании

Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC

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

Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC

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

Разработчик! Прекрати считать себя недостаточно хорошим специалистом, это неправда

чиф архитектом в кроссовере называют сеньоров, так что речь как раз о них

Разработчик! Прекрати считать себя недостаточно хорошим специалистом, это неправда

Было бы ради любопытства интересно взглянуть на вакансию в дефолтсити, где бы предлагали $100к в год сеньору.

Как это сделано: пишем «Сапера» за 4 минуты

Хотя за 4 минуты такое конечно не напишешь, но качество кода очень похоже на то, что пытались написать именно за 4.