Обновить
26
ApeCoder@ApeCoder

Разработчик

6
Подписчики
Отправить сообщение
Тут вопрос, это принципиальная сложность или мы просто не доросли в каком-то смысле для решения этой задачи. Я думаю, для любой работающей технологии можно найти предыдущие попытки сделать то же самое, но неудачно.

Можно переходить к хранению градуированно?

— сначала сделать запасной текстовый интерфейс (хоть даже файловую систему виртуальную)
— потом перетаскивать сценарии использования на AST или даже какой-нибдуь semantic tree

Сейчас у нас фактически двойное хранение — у IDE в кешах и в тексте, причем тектовое представление первично. Может быть можно как-то стандартизировать кеши сначала как базу данных с публичным API, потом запретить хранить текст который содержит какую-то информацию не содержащуюся в базе данных, потом в какой-то момент сделать базу данных первичной.
Вроде ж мы про код говорим? Простой поиск выводит на stackoverflow http://stackoverflow.com/questions/523307/semantic-diff-utilities (сам, правда, не пользовался)
Я не знаю точного определения слова «текст» и мне лень смотреть. Но формула как графическое предстваление это не последовательность символов там символы вступают в некоторые геометрические отношения (над/под и т.д.)
> ДУМАЕТ текстом

Можно пруф в контексте программирования? Может я не такой, он я скорее думаю геометрически.
Этот текст конвертируется в пиксели на экране. Если хранить AST то его тоже можно представлять как текст. Или как другие пиксели на экране человеком.

Можно конвертировать также для любых других потребителей, которые любят текст.

Как по мне, так странные приоритеты


Думаю, из стратегическая цель перегнать не VS на винде, а некий кроссплатформ (VS.Code, Xamarin Studio)
Может не в свободное и не в личном, а например, в университете в учебном (см тему поста)
Один из способов разобраться это представить «А как бы делал я на их месте» и проверить предположения
Возможно, чтобы хорошо выбрать Фреймворк надо уметь делать свой — так глубже понимаешь компромиссы и проблемы с которыми столкнутся авторы в будущем
Потому, что все уже сидят в проприетарных чатиках под которые есть инфраструктура. Например чтобы завести фейсбук мессенджер не надо ничего так как аккаунт фейсбука уже есть. А когда все друзья фейсбук мессенджере искать джаббер сервер, выяснять, как там завести логин и перетаскивать всех туда не надо.

Гугловский мессенджер поддерживал jabber, но потом забили (MS к тому времени успел сделать интеграцию через него со своим мессенджером, но она отвалилась)
Мне кажется, это может быть выгодно проигравшим менеджерам подобно тому, как проигравшие компании в битве ОС объединились вокруг Линукса.
А нельзя взять гардеробщицу, которая все знает про номерки И рядом с ней посадить за один комрпьютер специалиста по UX, который все знает про кернинг и визуальные языки и пусть знания гардеробщицы сольются со знаниями UX специалиста?
1) portable не подойдет?
Насколько я знаю, owa работает и на on prem exchange серверах
А редактировать локальным редактором с intellisense и прочими штуками, а выполнять на сервере?
типа такого: https://blogs.msdn.microsoft.com/powershell/2014/11/19/powershell-remote-script-debugging-in-the-ise/
А зачем именно консольный?
Дырка же в том, что пользователь может включить макросы. Какая разница, будет зловредный код написан на VBA или на powershell?
Никакой дыры, если у нас есть возможность заставить cmd выполнять произвольные команды, почему выполнение powershell скриптов это что-то более опасное?
Еще можно насыщать произведения рекламой или наоборот средствами сбора информации. Рекламу правда надо будет сделать трудноизвлекаемой а произведения подешевле чтобы выпускать их побольше. Т.е. блокбастеры постепенно вымрут останутся сериалы которые будут состоять из продуктплейсмета.

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность