filter(lambda x: is_prime(x), range(2, 10)) -> [2, 3, 5, 7] Раз уж функции это объекты первого класса, то почему бы не: filter(is_prime, range(2, 10)) -> [2, 3, 5, 7] Если нужно вложенный вызов a(b(x)), то это композиция: filter(compose(is_prime, int), ["1", "2", "3"]) -> ["1", "3"] Если вызов метода lambda x: x.what() (тип x это X), то:
filter(X.what, [...]) Если нужно уменьшить количество аргументов функции: lambda x: 5 < x, то это каррирование: filter(curry(int.__le__, 5), range(2, 7)) -> [5, 6] Вообщем безусловно с помощью лямбд можно сделать все, но есть множество способов сделать это красивее и лябмд и генераторов (на мой взгляд).
А что мешает создать конструктор, который возвращает StringBuilder*, а принимает указатель на память. Так извне можно аллоцировать буфер хоть на стеке, хоть на хипе. К тому же это лучше с точки зрения архитектуры - разделить ответственность получения ресурса(выделения памяти) и конструирования объекта.
Красивый проект. А вы пробовали задавать расстояние, в котором частицы взаимодействуют, в зависимости от силы взаимодействия. То есть отсекать все, сила взаимодействия с которыми меньше epsilon.
Недавно на кафедре баз данных TUM я работал над интересной низкоуровневой библиотекой на языке С — tssx, заменяющей в любом приложении взаимодействие через сокеты на быструю передачу данных через разделяемую память. С нашей библиотекой Postgres работает более чем в два раза быстрее, а некоторые программы даже на порядок быстрее. В основе библиотеки лежит трюк с LD_PRELOAD, о котором я и расскажу в этой статье.
Первый обзац, последнее предложение. Похоже написать критикующий комментарий гораздно проще, чем прочесть преамбулу. К тому же если вы достаточно опытен в работе с linux, то по названию итак было очевидно о чем статья.
Я не считаю, что ИИ сможет в полной мере заменить разработчиков ПО в ближайшее время, но -
Кодинг может быть сложным, но мне никогда не требовалось больше двух недель, чтобы разобраться с проблемами в коде. Если освоить синтаксис, логику и методики, то процесс оказывается довольно прямолинейным. Настоящие проблемы обычно связаны с тем, что ПО должно делать. Самое сложное в создании ПО — не написание кода, а создание требований, а требования к ПО по-прежнему определяют люди.
Если ИИ решит проблему быстрее вас, и его внедрение станет достаточно дешевым, а сам он будет надежным, тогда почему не заменить разработчика им. Далеко не все разработчики занимаются проектированием и составлением требований к системе. Разработка и проектирование это разные задачи.
Очень интересная метафора. А почему вы думаете, что для того чтобы язык вас защищал необходимо его сменить? Да, Си зарекомендовал себя как низкоуровневый и всепозволяющий язык, но и Си развивается. Тогда почему бы не двигать его в сторону безопасности(ведь это очевидный плюс), при этом не отбирая свободу.
filter(lambda x: is_prime(x), range(2, 10)) -> [2, 3, 5, 7]
Раз уж функции это объекты первого класса, то почему бы не:filter(is_prime, range(2, 10)) -> [2, 3, 5, 7]
Если нужно вложенный вызов a(b(x)), то это композиция:filter(compose(is_prime, int), ["1", "2", "3"]) -> ["1", "3"]
Если вызов методаlambda x: x.what()(тип x это X), то:filter(X.what, [...])
Если нужно уменьшить количество аргументов функции:lambda x: 5 < x, то это каррирование:filter(curry(int.__le__, 5), range(2, 7)) -> [5, 6]
Вообщем безусловно с помощью лямбд можно сделать все, но есть множество способов сделать это красивее и лябмд и генераторов (на мой взгляд).Способ я не предлагал. Но думаю вы правы в чем-то.
Можно разместить на стеке? - Да
Будет ли это удобно, как при обычном использовании стека? - Нет
А что мешает создать конструктор, который возвращает StringBuilder*, а принимает указатель на память. Так извне можно аллоцировать буфер хоть на стеке, хоть на хипе. К тому же это лучше с точки зрения архитектуры - разделить ответственность получения ресурса(выделения памяти) и конструирования объекта.
Красивый проект.
А вы пробовали задавать расстояние, в котором частицы взаимодействуют, в зависимости от силы взаимодействия. То есть отсекать все, сила взаимодействия с которыми меньше epsilon.
Первый обзац, последнее предложение.
Похоже написать критикующий комментарий гораздно проще, чем прочесть преамбулу.
К тому же если вы достаточно опытен в работе с linux, то по названию итак было очевидно о чем статья.
Я не считаю, что ИИ сможет в полной мере заменить разработчиков ПО в ближайшее время, но -
Если ИИ решит проблему быстрее вас, и его внедрение станет достаточно дешевым, а сам он будет надежным, тогда почему не заменить разработчика им. Далеко не все разработчики занимаются проектированием и составлением требований к системе. Разработка и проектирование это разные задачи.
Очень интересная метафора.
А почему вы думаете, что для того чтобы язык вас защищал необходимо его сменить? Да, Си зарекомендовал себя как низкоуровневый и всепозволяющий язык, но и Си развивается. Тогда почему бы не двигать его в сторону безопасности(ведь это очевидный плюс), при этом не отбирая свободу.