История изменений
Исправление kaldeon, (текущая версия) :
сложные ООП абстракции
Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.
Сложная абстракция с одной реализацией — это не абстракция, а второстепенная особенность какой-то части системы.
Сложной может быть иерархия зависимостей, но я не могу представить пример, где Го принципиально проигрывает другим языкам в этом отношении.
сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.
Хотя я не могу подтвердить, я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.
Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных «сложных абстракций» в стандартной библиотеке.
В качестве примера могу предложить database/sql.
сложные ООП абстракции на нём строить не получится
На основании каких предпосылок сделан этот вывод? Каких средств недостаточно и есть ли пример ожидаемого результата?
Исправление kaldeon, :
сложные ООП абстракции
Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.
Сложная абстракция с одной реализацией — это не абстракция, а второстепенная особенность какой-то части системы.
Сложной может быть иерархия зависимостей, но я не вижу пример, где Го принципиально проигрывает другим языкам в этом отношении.
сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.
Хотя я не могу подтвердить, я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.
Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных «сложных абстракций» в стандартной библиотеке.
В качестве примера могу предложить database/sql.
сложные ООП абстракции на нём строить не получится
На основании каких предпосылок сделан этот вывод? Каких средств недостаточно и есть ли пример ожидаемого результата?
Исправление kaldeon, :
сложные ООП абстракции
Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.
Сложная абстракция с одной реализацией — это не абстракция, а второстепенная особенность какой-то части системы.
Сложной может быть иерархия зависимостей, но я не вижу в чём Го принципиально может проиграть другим языкам в этом отношении.
сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.
Хотя я не могу подтвердить, я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.
Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных «сложных абстракций» в стандартной библиотеке.
В качестве примера могу предложить database/sql.
сложные ООП абстракции на нём строить не получится
На основании каких предпосылок сделан этот вывод? Каких средств недостаточно и есть ли пример ожидаемого результата?
Исправление kaldeon, :
сложные ООП абстракции
Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.
Сложная абстракция с одной реализацией — это не абстракция, а второстепенная особенность какой-то части системы.
сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.
Хотя я не могу подтвердить, я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.
Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных «сложных абстракций» в стандартной библиотеке.
В качестве примера могу предложить database/sql.
сложные ООП абстракции на нём строить не получится
На основании каких предпосылок сделан этот вывод? Каких средств недостаточно и есть ли пример ожидаемого результата?
Исправление kaldeon, :
сложные ООП абстракции
Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.
Сложная абстракция с одной реализацией — это не абстракция, а второстепенная особенность какой-то части системы.
сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.
Хотя я не могу подтвердить, я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.
Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных «сложных абстракций» в стандартной библиотеке.
сложные ООП абстракции на нём строить не получится
На основании каких предпосылок сделан этот вывод? Каких средств недостаточно и есть ли пример ожидаемого результата?
Исправление kaldeon, :
сложные ООП абстракции
Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.
Сложная абстракция с одной реализацией — это не абстракция, а второстепенная особенность какой-то части системы.
сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.
Я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.
Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных «сложных абстракций» в стандартной библиотеке.
сложные ООП абстракции на нём строить не получится
На основании каких предпосылок сделан этот вывод? Каких средств недостаточно и есть ли пример ожидаемого результата?
Исправление kaldeon, :
сложные ООП абстракции
Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.
Сложная абстракция с одной реализацией — это не абстракция, а второстепенное особенность какой-то части системы.
сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.
Я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.
Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных «сложных абстракций» в стандартной библиотеке.
сложные ООП абстракции на нём строить не получится
На основании каких предпосылок сделан этот вывод? Каких средств недостаточно и есть ли пример ожидаемого результата?
Исправление kaldeon, :
сложные ООП абстракции
Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.
Сложная абстракция с одной реализацией — это не абстракция, а второстепенное особенность какой-то части системы.
сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.
Я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.
Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных «сложных абстракций» в стандартной библиотеке.
сложные ООП абстракции на нём строить не получится
На основании каких предпосылок сделан этот вывод? Каких средств недостаточно и есть ли пример ожидаемого результат?
Исправление kaldeon, :
сложные ООП абстракции
Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.
Сложная абстракция с одной реализацией — это не абстракция, а второстепенное особенность какой-то части системы.
сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.
Я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.
Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных «сложных абстракций» в стандартной библиотеке.
сложные ООП абстракции на нём строить не получится
На основании каких предпосылок сделан этот вывод?
Исходная версия kaldeon, :
сложные ООП абстракции
Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.
Сложная абстракция с одной реализацией — это не абстракция, а второстепенное особенность какой-то части системы.
сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.
Я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.
Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных сложных абстракций в стандартной библиотеке.
сложные ООП абстракции на нём строить не получится
На основании каких предпосылок сделан этот вывод?