Ну потому что перечисления это более примитивная сущность чем варианты. Также потому что некоторые типы все-же должны быть POD, например для работы с бинарными форматами или сетевыми протоколами.
Приведу вот такой пример. Можно отказаться от разнообразных числовых типов (int, short, long, unsigned int, float, double и т.д.) и перейти к единому числовому типу, скажем «numeric». Неограниченной длины, любой точности. Возможно это будет удобно. Но это будет сущность более сложная чем базовые типы, и безусловно, отказ от базовых типов уменьшит хакерскую мощь языка. Но в то же время добавление высокоуровневых вариантов с сохранением низкоуровневых перечислений не только не уменьшит, но и увеличит хакерские возможности языка программирования.
Непонятно стоило ли объединять enum'ы и variant'ы в одну сущность.
ИМХО, стоило эти вещи оставить отдельно: перечисления — как низкоуровневая конструкция, совместимая с int, варианты — как алгебраический тип данных («тип-сумма») со всеми фичами, присущими такому типу.
Комментарии нужны для файлов конфигурации и прочих локальных применений. Сейчас это делается отдельными тегами, что плохо.
Запятые в конце — для простой автоматической генерации списков (не нужно думать последний элемент или нет).
Разные кавычки… не знаю, кавычки существуют всего двух типов, может это и имеет смысл а может и нет.
Шестнадцатеричный вид (0x) это общепринятая вещь. Неплохо бы еще двоичный сразу добавить (0b).
Так что но никакого зоопарка, только все самое необходимое для определения данных.
Вот еше интерсная ссылка: http://json5.org
предложения по расширению формата json в соответствии с синтаксисом ECMAScript 5. Цитата из википедии:
Некоторые нововведения:
Поддерживаются как однострочные //, так и многострочные /* */ комментарии.
Объекты и списки могут иметь запятую после последнего элемента (удобно при копипейсте элементов).
Ключи объекта могут быть без кавычек, если они являются валидными идентификаторами ECMAScript 5.
Строки могут заключаться как в одинарные, так и в двойные кавычки.
Числа могут быть в шестнадцатеричном виде, начинаться или заканчиваться десятичной точкой, включать Infinity, -Infinity, NaN и -NaN, начинаться со знака +.
ИМХО вполне разумные предложения, надо бы чтобы их приняли. Сам по себе формат действительно очень красивый, лучше многословного xml и всех форматов основанных на отступах.
Структура проекта должна быть в нормальном формате — xml, а лучше json. Стандартизирована должна быть основа, каркас. Если какому-то хитровывернутому компилятору или IDE нужно что-то еще — никто не запрещает добавлять свои кастомные теги и атрибуты. Но в целом стандартизация должна быть, чтобы переход между IDE и компилятрами и одновременное использование нескольких IDE и компиляторов было максимально простым и прозрачным. Да, всякие *make — это костыли концептуально родом из 70-х годов, их даже упоминать не стоит.
Тот же M$ в своей студии меняет форматы vcproj (для С++, насчет C# не знаю) каждый раз c выпуском новой студии. Зачем? Неужели структура проекта это что-то такое архи сложное, что не продумать сразу? Структура любого языка программирования как такового будет на порядки сложнее, и ничего — языки проектируются и существуют десятилетиями.
По моему, Visual Studio вообще лучшая IDE.
Я вот с Eclipse недавно плевался… нет классического понятия «файл проекта», файлы исходников где-то толи кэшируются то-ли что, в результате если изменить их снаружи (в текстовом редакторе) то с удивлением можно увидеть что изменения в самом эклипсе не отображаются (или отображаются не сразу).
Вообще я давно уже пришел к выводу, что при разработке нового языка программирования структуру файлов проекта тоже неплохо было бы стандартизировать, чтобы не было зоопарков с разными форматами, средами разработки и т.д.
Простите, а зачем собирать проект на x64? PVS-студио это же статический анализатор, ему вообще никакие компиляторы для работы не требуются. Или проблема в том что он считает все проекты по умолчанию только 64-битными?
А когда там кто нибудь по настоящему погибнет, и остальные захотят назад, вот тогда романтика-то и накроется, и общественное мнение развернется в противоположную сторону. Да еще и засудят за такое.
Я больше скажу: при гарантии возврата интереса к проекту будет гораздо больше. Сейчас это какое-то сектантство, а при гарантии возврата это будет нормальный коммерческий проект.
А вот делать надо было смарт часы не на светящемся и потребляющем энергию экране, а на технологии типа Mirasol. Но нет — современная масс культура видимо предполагает, что люди везде должны «смотреть фильмы», и на часах в том числе, откуда и стремление к классическим технологиям для экранов с максимально качественной цветопередачей. Откуда и смарт-часы, требующие зарядки каждый день.
Смарт-часы нужны, но функционал на них нужно очень тщательно продумывать.
Ну а про MacOSX так и не ответили ни да ни нет :) Можно ли из этого сделать какой-то вывод?
А ведь OSX и Java это пожалуй те технологии где больше всего крутится $$$: яболчная компания приучила своих пользователей за все платить, а java — это банковская сфера, которая всегда с деньгами.
Да, кстати хотел это же написать (кстати интересно чего минусуют). Это, можно сказать, большая тройка десктопных операционных систем (а значит систем на которых разрабатывают софт). И если уж вы взялись за поддержку Линукса, то обойти Макось было бы нарушением вселенского равновесия.
Планируете ли добавить поддержку ObjC, Swift?
Планируете ли добавить поддержку других языков, скажем Java (судя по сайту C# вы поддерживаете)?
Ну и что? В чем проблема завести хотя-бы один 64-битный компьютер специально для такого софта, который уже не существует для x32 но тем ни менее мог бы быть полезен при разработке?
А практическую пользу можно из этого извечь? То есть сделать рут на устройстве без перепрошивки и без риска поставить трояна?
Исходники этой штуки открыты?
Непонятно зачем билет в один конец. Все что можно сделать без человека нужно делать без человека. А можно многое, в том числе доставить на Марс автоматически самособирающуюся из модулей роботизированную базу. Пусть будет несколько десятков беспилотных полетов и только потом один пилотируемый — но чтобы люди прилетели не к разбитому корыту, а в готовый городок с готовой ракетой для возврата на Землю.
Интересно что с этим можно сделать на архитектурном уровне. Возможна ли архитектура интернета, устойчивая в DDoS атакам? Что нибудь децентрализованное?
Приведу вот такой пример. Можно отказаться от разнообразных числовых типов (int, short, long, unsigned int, float, double и т.д.) и перейти к единому числовому типу, скажем «numeric». Неограниченной длины, любой точности. Возможно это будет удобно. Но это будет сущность более сложная чем базовые типы, и безусловно, отказ от базовых типов уменьшит хакерскую мощь языка. Но в то же время добавление высокоуровневых вариантов с сохранением низкоуровневых перечислений не только не уменьшит, но и увеличит хакерские возможности языка программирования.
ИМХО, стоило эти вещи оставить отдельно: перечисления — как низкоуровневая конструкция, совместимая с int, варианты — как алгебраический тип данных («тип-сумма») со всеми фичами, присущими такому типу.
Запятые в конце — для простой автоматической генерации списков (не нужно думать последний элемент или нет).
Разные кавычки… не знаю, кавычки существуют всего двух типов, может это и имеет смысл а может и нет.
Шестнадцатеричный вид (0x) это общепринятая вещь. Неплохо бы еще двоичный сразу добавить (0b).
Так что но никакого зоопарка, только все самое необходимое для определения данных.
предложения по расширению формата json в соответствии с синтаксисом ECMAScript 5. Цитата из википедии:
ИМХО вполне разумные предложения, надо бы чтобы их приняли. Сам по себе формат действительно очень красивый, лучше многословного xml и всех форматов основанных на отступах.
Тот же M$ в своей студии меняет форматы vcproj (для С++, насчет C# не знаю) каждый раз c выпуском новой студии. Зачем? Неужели структура проекта это что-то такое архи сложное, что не продумать сразу? Структура любого языка программирования как такового будет на порядки сложнее, и ничего — языки проектируются и существуют десятилетиями.
Я вот с Eclipse недавно плевался… нет классического понятия «файл проекта», файлы исходников где-то толи кэшируются то-ли что, в результате если изменить их снаружи (в текстовом редакторе) то с удивлением можно увидеть что изменения в самом эклипсе не отображаются (или отображаются не сразу).
Вообще я давно уже пришел к выводу, что при разработке нового языка программирования структуру файлов проекта тоже неплохо было бы стандартизировать, чтобы не было зоопарков с разными форматами, средами разработки и т.д.
Я больше скажу: при гарантии возврата интереса к проекту будет гораздо больше. Сейчас это какое-то сектантство, а при гарантии возврата это будет нормальный коммерческий проект.
Смарт-часы нужны, но функционал на них нужно очень тщательно продумывать.
А ведь OSX и Java это пожалуй те технологии где больше всего крутится $$$: яболчная компания приучила своих пользователей за все платить, а java — это банковская сфера, которая всегда с деньгами.
Планируете ли добавить поддержку ObjC, Swift?
Планируете ли добавить поддержку других языков, скажем Java (судя по сайту C# вы поддерживаете)?
Исходники этой штуки открыты?