Ну я конечно соглашусь здесь с нами, но всё равно, когда знаешь уже несколько языков/фреймворков, остальные даются всё легче и легче, ОСОБЕННО когда речь идёт о фичах в разных языках предназначенных для одного и тоже. (А не так что сравнивается assembly и jQuery).
К примеру если взять PHP, Python и Ruby — и скажем вам сейчас надо написать вебприложение. Вы скорее всего начнёте изучать django/rails/{одна из десятков альтернатив для PHP}, и хоть все языки очень разные с разными стеками приложений и утилит, всё равно сами MVC фреймворки очень похожи, просто потому что разрабатывались для одной цели. Поэтому когда нужно будет изучать grails для Groovy, это уже пойдёт гораздо быстрее, вы просто будете узнавать все фичи.
(но за пару дней конечно можно изучить лишь синтаксис, для эффективности требуется время, независимо от языка).
Было бы странно если автор это имел ввиду, приводя в пример Scala, который даже если не учитывать что сам объектно-ориентированный, вдобавок ещё стоит на JVM, которая объектно-ориентирована вообще насквозь.
Опять про Groovy забыли…
Но вообще в голове всё поместится, было бы время и желание. Чем больше языков изучаешь, тем легче это даётся, потому что начинаешь понимать как все языки строятся из фич и что во многих из них очень много этих самых одинаковых фич. А чтобы выучить сам синтаксис — где ставить скобочку а где точку — вообще много времени не надо.
Самое главное поясните: что было решено по поводу того можно ли взять патент на «программный интерфейс»/спецификацию? Насколько я понимаю решили что нельзя и именно поэтому google выиграла?
Может это лишь моё имхо, но действительлно, аргумент про то что синтаксис ({,}, (), etc.) читается хуже чем тоже самое словами (end, begin, sub) — какой-то странный и я его никогда не понимал.
Наоборот, спецсимволы не только занимают гораздо меньше места, но ещё и сильно отличаются по внешнему виду (а значит легче и быстрее могут быть восприняты человеком) от обычных слов. Хотя я и сам начинал с бейсика и паскаля, однако когда попробовал С и увидел насколько легче читается код, (ну и много других достоинств конечно), сразу пересел, и сложно представить что это было из-за «понтов»…
Кому выдать? Клиенту? это не поможет ни чем, ключи с сервера выдаются. Серверу? Ну во-первых если вы уже можете найти этот сервер и каким-то образом повлиять или взломать провайдера то тут с вашими возможностями лучше уж сам сервер взломать. Причём не факт что сервер сверяет время с таймсерверами часто. Может он раз в год смотрит, ведь на текущем оборудовании часы и так сами по себе довольно точно идут.
А можно узнать непосредственно ваш опыт в этом деле? Сколько програм вы продавали, по каким ценам примерно, как шло дело? Интересно на чём основаны эти советы, на собственном опыте или на услышанном.
Исключения бывают разные. Самый простой пример — подключение к сервису в интернете вызвало исключение, поэтому надо вместо ответа от сервиса показать сохранённый результат, чтобы юзер ничего и не заметил. Подключение часто может включать в себя много функций и разной логики, и вместо того чтобы проверять каждую отдельную часть, разработчику легче поставить trycatch вокруг всего блока.
И так во многих программах и фреймворках, исключения используются как более удобный возврат результата, а не из-за катастрофических ошибок. Правильно это или нет, ещё можно пообсуждать (хотя я считаю что правильно), но это реальность, исключения используются в неэкстремальных случаях повсеместно.
Макросы в C++ и макросы в lisp-мире всё-таки не одно и тоже. Насколько я понимаю, в лиспах они гораздо более продуманы, имеют такой же синтаксис как и всё остальное и такой боли не вызывают. Хотя макросы — good или bad всё равно не совсем понятно…
Я ни на чьей стороне, но как часто вы используете мультиметоды (и не могли бы использовать обычные оверлоады) и множественное наследование? (и что сложно было бы достичь простыми интерфейсами или в крайнем случае traitами в каком-нибудь другом языке?) В моей практике может был один случай когда на этом можно было сохранить чуть-чуть времени, но может я просто таких случаев не замечаю потому что не «думаю» в лиспе, не знаю.
Не знаю, это вам решать, хватит или нет )
Я сначала изучу все примеры что тут написали, потом буду думать. Сейчас, без понимания всего это смысла отвечать нету )
Ну вот я и ищу подобные примеры. Можете привести какие-то ссылки или т.д, где показано практически, что могут сделать лисповые макросы чего не могут обычные динамические языки? Те примеры которые я видел реализовывают в лисп фукнционал который в обычных языках и так уже есть…
Хочется поверить в лисп, в нём есть своя красота, своя идея. Но пока практически не вижу никаких преимуществ…
Community имеет огромное значение в программировании, во-первых, качественно, но также и количественно, посколько первое, хоть и не линейно, но следует из второго.
Невозможно знать какую-то платформу на 100 процентов, поэтому очень часто требуется помощь, примеры, форумы, и т.д. Это просто неотъемлемая часть разработки, сохраняющая уйму времени. Это я уже и не говорю о количестве готовых билиотек, и коммьюнити для них (которые тоже важны, сложные библиотеки это вообще как собственные языки). А общаясь с «небольшой группой программистов» всё время будет уходить на поиски багов, написание библиотек и собственноручному экспериментированию с языком, время которое могло быть потрачено на разработку непосредственно самой программы.
Вы можете это хоть как-то конкретизировать? Что конкретно человек лучше понимает, потратив немало времени на изучение лиспа? Многие говорят про подобные успехи лиспа, а когда спрашиваешь в чём же суть, все ни бэ ни мэ. Создаётся впечатление что все преимущества лиспа — в том что тем кому нравится его использовать просто тупо нравится синтаксис… К примеру большинство «особенностей» описанных в этой статье выглядят немного странно когда понимаешь что тоже самое есть и в обычных широкоиспользуемых языках, и часто даже лучше реализовано.
build.gradle — вы весь этот файл вручную написали? Для того чтобы построить проект в котором единственный сервис с единственной функцией? Как-то не очень эффективно, неужели это самый лучший метод?
Просто ваша статья — о производительности. Поэтому когда вы пишете «и сделал два аргументированных замечания:
Initialization vector не используется в режиме ECB (о чем я писал выше)», «5-ый параметр $iv (он же – вектор инициализации) в функции mcrypt_encrypt не к месту — так как он вообще не используется в режиме шифрования ECB» и подобное, нигде не уточняя что именно в этом месте вы решаете уже проблему секьюрности, а не производительности, это сбивает с толку. Но сейчас понятно что вы всё-таки разобрались.
>Первое – не проблема, погуглив дальше, сразу же натыкаешься на режим CBC (Cipher-block chaining).
Каким образом это решает проблему скорости? Вы видите что в коде зря генерируете вектор, потому что он не используется вашим алгоритмом шифрования, и поэтому ваше решение — использовать другой алгоритм шифрования который будет использовать вектор? И это по вашему будет быстрее чтоли?
Хотя криптографически, ECB конечно имеет большие недостатки.
К примеру если взять PHP, Python и Ruby — и скажем вам сейчас надо написать вебприложение. Вы скорее всего начнёте изучать django/rails/{одна из десятков альтернатив для PHP}, и хоть все языки очень разные с разными стеками приложений и утилит, всё равно сами MVC фреймворки очень похожи, просто потому что разрабатывались для одной цели. Поэтому когда нужно будет изучать grails для Groovy, это уже пойдёт гораздо быстрее, вы просто будете узнавать все фичи.
(но за пару дней конечно можно изучить лишь синтаксис, для эффективности требуется время, независимо от языка).
Но вообще в голове всё поместится, было бы время и желание. Чем больше языков изучаешь, тем легче это даётся, потому что начинаешь понимать как все языки строятся из фич и что во многих из них очень много этих самых одинаковых фич. А чтобы выучить сам синтаксис — где ставить скобочку а где точку — вообще много времени не надо.
Наоборот, спецсимволы не только занимают гораздо меньше места, но ещё и сильно отличаются по внешнему виду (а значит легче и быстрее могут быть восприняты человеком) от обычных слов. Хотя я и сам начинал с бейсика и паскаля, однако когда попробовал С и увидел насколько легче читается код, (ну и много других достоинств конечно), сразу пересел, и сложно представить что это было из-за «понтов»…
И так во многих программах и фреймворках, исключения используются как более удобный возврат результата, а не из-за катастрофических ошибок. Правильно это или нет, ещё можно пообсуждать (хотя я считаю что правильно), но это реальность, исключения используются в неэкстремальных случаях повсеместно.
Я сначала изучу все примеры что тут написали, потом буду думать. Сейчас, без понимания всего это смысла отвечать нету )
Хочется поверить в лисп, в нём есть своя красота, своя идея. Но пока практически не вижу никаких преимуществ…
Невозможно знать какую-то платформу на 100 процентов, поэтому очень часто требуется помощь, примеры, форумы, и т.д. Это просто неотъемлемая часть разработки, сохраняющая уйму времени. Это я уже и не говорю о количестве готовых билиотек, и коммьюнити для них (которые тоже важны, сложные библиотеки это вообще как собственные языки). А общаясь с «небольшой группой программистов» всё время будет уходить на поиски багов, написание библиотек и собственноручному экспериментированию с языком, время которое могло быть потрачено на разработку непосредственно самой программы.
Initialization vector не используется в режиме ECB (о чем я писал выше)», «5-ый параметр $iv (он же – вектор инициализации) в функции mcrypt_encrypt не к месту — так как он вообще не используется в режиме шифрования ECB» и подобное, нигде не уточняя что именно в этом месте вы решаете уже проблему секьюрности, а не производительности, это сбивает с толку. Но сейчас понятно что вы всё-таки разобрались.
Каким образом это решает проблему скорости? Вы видите что в коде зря генерируете вектор, потому что он не используется вашим алгоритмом шифрования, и поэтому ваше решение — использовать другой алгоритм шифрования который будет использовать вектор? И это по вашему будет быстрее чтоли?
Хотя криптографически, ECB конечно имеет большие недостатки.