KR
> Если бы первобытный человек изъяснялся формально, дисциплина программирования была бы не нужна.
Почему так?
Почему так?
Это шутка
Size: a a a
2020 May 08
CC
Понял
ИЧ
ИИ хорош тем, что о нем можно часами рассуждать безо всякой практической пользы :)
А мне вот интереснее, почему уже немодно проектировать выскоуровневые ЯП. Новые многочисленные улучшенные варианты C/C++, Go и проч. это и близко не уровень стареньких APL, SETL, SNOBOL, Prolog... А ведь это тоже скромный, но путь к автоматизации программирования.
А мне вот интереснее, почему уже немодно проектировать выскоуровневые ЯП. Новые многочисленные улучшенные варианты C/C++, Go и проч. это и близко не уровень стареньких APL, SETL, SNOBOL, Prolog... А ведь это тоже скромный, но путь к автоматизации программирования.
Go появился как ответ на потребности микросервисной разработки:
1. минимальный latency
2. минимальный порог входа, решающий проблему с кадрами
3. скорость разработки быстрых и маленьких программ, сродни классам в ООП
В свою очередь микросервисы появились как ответ на рост сложности релизного цикла с ростом команды.
Высокие абстракции в коде уже не нужны, их роль выполняют паттерны проектирования распределенных систем, на основе контейнеров, это - sidecar, ambassador, adapter и далее.
1. минимальный latency
2. минимальный порог входа, решающий проблему с кадрами
3. скорость разработки быстрых и маленьких программ, сродни классам в ООП
В свою очередь микросервисы появились как ответ на рост сложности релизного цикла с ростом команды.
Высокие абстракции в коде уже не нужны, их роль выполняют паттерны проектирования распределенных систем, на основе контейнеров, это - sidecar, ambassador, adapter и далее.
МБ
Go появился как ответ на потребности микросервисной разработки:
1. минимальный latency
2. минимальный порог входа, решающий проблему с кадрами
3. скорость разработки быстрых и маленьких программ, сродни классам в ООП
В свою очередь микросервисы появились как ответ на рост сложности релизного цикла с ростом команды.
Высокие абстракции в коде уже не нужны, их роль выполняют паттерны проектирования распределенных систем, на основе контейнеров, это - sidecar, ambassador, adapter и далее.
1. минимальный latency
2. минимальный порог входа, решающий проблему с кадрами
3. скорость разработки быстрых и маленьких программ, сродни классам в ООП
В свою очередь микросервисы появились как ответ на рост сложности релизного цикла с ростом команды.
Высокие абстракции в коде уже не нужны, их роль выполняют паттерны проектирования распределенных систем, на основе контейнеров, это - sidecar, ambassador, adapter и далее.
Танненбаум одобряет :) Но с другой стороны, это открывает нишу языков для описания систем микросервисов. Компиляция в сети взаимодейстаий?
ИЧ
Танненбаум одобряет :) Но с другой стороны, это открывает нишу языков для описания систем микросервисов. Компиляция в сети взаимодейстаий?
правильно, эту мысль я и хотел донести, что язык затрагивает весь процесс разработки и нужно смотреть шире
KR
Танненбаум одобряет :) Но с другой стороны, это открывает нишу языков для описания систем микросервисов. Компиляция в сети взаимодейстаий?
Кстати, если кому интересно, хорошее введение в сети взаимодействия в __Fernández, Maribel (2009). "Interaction-Based Models of Computation". Models of Computation: An Introduction to Computability Theory. Springer Science & Business Media. pp. 107–130.
В zlib отличный pdf
В zlib отличный pdf
KR
Интересно, кстати, есть ли работы, связывающие interaction nets и теорию кос? А теорию групп?
МБ
Интересно, кстати, есть ли работы, связывающие interaction nets и теорию кос? А теорию групп?
Там те же самые категории, что и для тензоров
А
Go появился как ответ на потребности микросервисной разработки:
1. минимальный latency
2. минимальный порог входа, решающий проблему с кадрами
3. скорость разработки быстрых и маленьких программ, сродни классам в ООП
В свою очередь микросервисы появились как ответ на рост сложности релизного цикла с ростом команды.
Высокие абстракции в коде уже не нужны, их роль выполняют паттерны проектирования распределенных систем, на основе контейнеров, это - sidecar, ambassador, adapter и далее.
1. минимальный latency
2. минимальный порог входа, решающий проблему с кадрами
3. скорость разработки быстрых и маленьких программ, сродни классам в ООП
В свою очередь микросервисы появились как ответ на рост сложности релизного цикла с ростом команды.
Высокие абстракции в коде уже не нужны, их роль выполняют паттерны проектирования распределенных систем, на основе контейнеров, это - sidecar, ambassador, adapter и далее.
высокие абстракции нужны
А
"высокие" - это те, на самом деле старые и знакомые (в том числе и в императивных языках) абстракции, которые уменьшают количество копипасты в разы
А
собственно то самое, что хотят в Go2 сделать
p
Go появился как ответ на потребности микросервисной разработки:
1. минимальный latency
2. минимальный порог входа, решающий проблему с кадрами
3. скорость разработки быстрых и маленьких программ, сродни классам в ООП
В свою очередь микросервисы появились как ответ на рост сложности релизного цикла с ростом команды.
Высокие абстракции в коде уже не нужны, их роль выполняют паттерны проектирования распределенных систем, на основе контейнеров, это - sidecar, ambassador, adapter и далее.
1. минимальный latency
2. минимальный порог входа, решающий проблему с кадрами
3. скорость разработки быстрых и маленьких программ, сродни классам в ООП
В свою очередь микросервисы появились как ответ на рост сложности релизного цикла с ростом команды.
Высокие абстракции в коде уже не нужны, их роль выполняют паттерны проектирования распределенных систем, на основе контейнеров, это - sidecar, ambassador, adapter и далее.
Высокие абстракции нужны иначе написание кода превратится в Ctrl+C, Ctrl+V. У меня тут гифка завалялась на этот случай.
ИЧ
В теории борьба с копипастой звучит замечательно, но на практике не всегда оправдывает себя. Тем более в рамках программы на тысячу строк. Правда остаётся потребность в библиотеках и фреймворка, для которых абстракция уже критична.
p
В теории борьба с копипастой звучит замечательно, но на практике не всегда оправдывает себя. Тем более в рамках программы на тысячу строк. Правда остаётся потребность в библиотеках и фреймворка, для которых абстракция уже критична.
Разве это не замечательно вместо программы на 1000 строк написать аналогичную на 800 строк?
C
Интересно, кстати, есть ли работы, связывающие interaction nets и теорию кос? А теорию групп?
А где это применяют программисты?
ИЧ
Разве это не замечательно вместо программы на 1000 строк написать аналогичную на 800 строк?
Неа. Если программу усложнить, придётся писать документацию. Но я не имею ввиду дженерики. Они конечно полезны без вопросов. Правда не оч понимаю почему их нет.
p
Неа. Если программу усложнить, придётся писать документацию. Но я не имею ввиду дженерики. Они конечно полезны без вопросов. Правда не оч понимаю почему их нет.
Ну если усложнять то да. А если упрощать нет. Вы же читали статью про сложность простоты на Хабре?
ИЧ
Ну если усложнять то да. А если упрощать нет. Вы же читали статью про сложность простоты на Хабре?
Да. Но Go для долгой разработке крупных продуктов. А не про скриптики на коленке. язык всё равно нужно нормально изучить.
А
Неа. Если программу усложнить, придётся писать документацию. Но я не имею ввиду дженерики. Они конечно полезны без вопросов. Правда не оч понимаю почему их нет.
Из-за простоты языка программа усложняется