Дженерики обеспечивают дополнительную проверку кода. Чем больше проверок будет выполнять ide/компилятор, а не программист тем выше производительность программиста.
Чем вас например не устраивает generics в составе языка? По мимо всего прочего они выполняют очень важную функцию — не дают запихивать в таблицы, словари, самописные классы объекты не подходящего класса. А нормальная среда разработки укажет на ошибку еще в процессе написания кода. В ином случае разработчику придется тратить время в поисках ошибки во время отладки, а это гораздо дороже по времени.
Зато с новыми фичами вы в ряде случаев можете подсократить количество кода который требуется написать. Или просто не использовать новую фичу, если она вам не подходит.
Как язык может остатся простым, если количество кода написаного на нем будет расти? Появление больших стандартных библиотек практически неизбежно, если на этом языке пишут десятки тысяч людей. Им просто надо как-то координироватся друг с другом, чтобы не писать велосипеды заново.
А ведь именно библиотеки, а не синтаксис языка составляет подавляющую часть сложности языка.
Если под 'языком программирования' подразумевать экосистему, то любой более менее используемый язык стремиться усложняется по мере использования.
Его начинают использовать для какой-либо деятельности. Программы разрастаются. Из них выделяют библиотеки. Самые часто используемые библиотеки становятся стандартными и входят тем самым в 'язык'. Простым 'язык' может оставаться только если не используется.
Ученые используют очень ограниченный набор возможностей языка. Для них язык не становится сложнее или легче с появление рефлексии, так как они ее просто не встретят. Так же с большуй частью нововведений. Ученым они просто не попадутся на глаза и не будут мешать или помогать.
Зато например лямбды упрощают жизнь, хотя и являются довольно сложными для понимания возможностями языка.
Странно. Совсем недавно была статья, насколько все плохо с научным софтом. Софт пишут непрофессионалы в программировании и он не самого высокого качества.
Программы написанные физиками/математиками настолько вылизаны до идеала, так что они не публикуют их в приложении к статьям. Ибо им просто банально стыдно, за написанный код.
Как тогда называть 'язык программирования'? Да и что в него входит? Правила синтаксиса+ набор стандартных библиотек и требований к среде выполнения или что-то еще?
Но это-же отдельный язык 'джава для микроконтроллеров', который чисто 'случайно' совпадает по синтаксису с большой джавой и называется похожим образом.
. Но при этом никак не оговаривается, что нужно это делать средствами языка или компилятора
.
Есть язык, который грубо говоря, оговаривает синтаксис кода. Есть компилятор, который выполняет некоторые действия над простым текстовым файлом и получает исполняемый файл. Если язык имеет средство что-либо делать, то компилятор обязан это реализовывать. Если компилятор реализовывает какую-либо функциональность, то эта функциональность также входит и в язык.
Фичи и синтетический сахар составляет крайне малую долю в сложности языка. Зато удобства они предоставляют не мало. C# вообще уникальный язык — он один из самых молодых, но при этом имеет огромную поддержку за спиной в виде microsoft. Если бы microsoft так же поддерживала какую-нибудь альтернативу С++, то мы бы давно уже имели более удобный язык.
Смотришь на материнскую плату вмещается проц, память, ssd и прочая мелочь, а потом сравниваешь с материнской платой других компов и понимаешь насколько те не рационально используют место. Невозможность что либо заменить жертва миниатюризации.
И как компьютер он очень даже неплох. Легкий, долго живучий, не забивается пылью, хороший корпус, экран. Как офисная машинка лучше целой россыпи конкурентов, которые 1,5-2 раза тяжелее, с TN экранами и дешевым пластиком.
Windows давно стоило пересмотреть инструменты для написания приложений, чтобы разработчики не писали каждый раз велосипеды для установки, обновлений, синхронизации, сохранения состояния при включении/выключении и прочего.
Разговор был, что в sql базах схему надо описывать два раза и вместо того, чтобы решить эту проблему через скажем авто-генерацию вы предлагаете перейти на бд где нет схем.
Да и как можно строить более-менее систему не будучи уверенном, что в любом случае данные будут консистентны? Транзакционность операций с бд очень полезна, так как позволяет в любой момент вывалиться с ошибкой и не загадить при этом бд.
Основная структура приложения практически всегда подразумевает связанность. Как например связь между пользователем и списком ролей вполне однозначна. При удалении роли нужно и проверить всех пользователей. Данные задачи лучше отдать на откуп реляционной базе.
А монга, как выше сказано для данных которым не нужна связанность. В идеале для данных которые бьются на отдельные документы никак не зависимые друг от друга.
Поэтому в идеале все связанные данные лучше бы вынести в реляционную бд, а монге оставить оставшуюся часть. Другое дело, что часто монгу делают единственной бд и начинают решать через нее несвойственные задачи.
У нас Минкомсвязи предлагает нарушить принцип нейтральности.
Главный посыл — предоставление бесплатного доступа к госуслугам конечно правильный, но вот создается прецедент на который можно потом опираться.
Первое преимущество — «единая валюта», нет потерь при конвертации (или потери очень маленькие, в перспективе)
Хм… опять 15 универсальный стандарт…
В мире криптовалют ведь тоже есть проблема единства. Ведь если государство решит использовать какую-то криптовалюту то она естественно выбирает свою. В других денежные средства уже распределены и влезать на поделенный рынок очень не выгодно. Поэтому оно выбирает свою и тут же получает обратно все те недостатки типичной валюты, как то панующий курс и ограниченность по приему.
А ведь именно библиотеки, а не синтаксис языка составляет подавляющую часть сложности языка.
Его начинают использовать для какой-либо деятельности. Программы разрастаются. Из них выделяют библиотеки. Самые часто используемые библиотеки становятся стандартными и входят тем самым в 'язык'. Простым 'язык' может оставаться только если не используется.
Зато например лямбды упрощают жизнь, хотя и являются довольно сложными для понимания возможностями языка.
Есть язык, который грубо говоря, оговаривает синтаксис кода. Есть компилятор, который выполняет некоторые действия над простым текстовым файлом и получает исполняемый файл. Если язык имеет средство что-либо делать, то компилятор обязан это реализовывать. Если компилятор реализовывает какую-либо функциональность, то эта функциональность также входит и в язык.
И как компьютер он очень даже неплох. Легкий, долго живучий, не забивается пылью, хороший корпус, экран. Как офисная машинка лучше целой россыпи конкурентов, которые 1,5-2 раза тяжелее, с TN экранами и дешевым пластиком.
Да и как можно строить более-менее систему не будучи уверенном, что в любом случае данные будут консистентны? Транзакционность операций с бд очень полезна, так как позволяет в любой момент вывалиться с ошибкой и не загадить при этом бд.
А монга, как выше сказано для данных которым не нужна связанность. В идеале для данных которые бьются на отдельные документы никак не зависимые друг от друга.
Поэтому в идеале все связанные данные лучше бы вынести в реляционную бд, а монге оставить оставшуюся часть. Другое дело, что часто монгу делают единственной бд и начинают решать через нее несвойственные задачи.
Главный посыл — предоставление бесплатного доступа к госуслугам конечно правильный, но вот создается прецедент на который можно потом опираться.
Хм… опять 15 универсальный стандарт…
В мире криптовалют ведь тоже есть проблема единства. Ведь если государство решит использовать какую-то криптовалюту то она естественно выбирает свою. В других денежные средства уже распределены и влезать на поделенный рынок очень не выгодно. Поэтому оно выбирает свою и тут же получает обратно все те недостатки типичной валюты, как то панующий курс и ограниченность по приему.