хочу язык, состоящий из CPS чуть менее чем полностью. Очень хочу. И вообще странно что его досихпор никто не запилил. Потому что идея сама по себе охуительна хотябы тем что по statetrace'у (дада, трейсится будет именно не stack а state, состояние тобишь) можно будет очень быстро локализовывать причины хотябы потому что для каждого состояния ОЧЕНЬ легко определить, какие данные оно исопльзует. Даже при наличии глобальных переменных. Даже при их умеренном использовании. А еще там вполне нативно на небольшом кол-ве сахара получится объектная модель. И тут самый большой минус. Потому что от ЕБАНУТЫХНАХУЙКАКВЖАВЕ,извиняюсь, иерархий классов (ровно как и от фимозных недопрограммеров) не спасет ничего.
УНЯНЯ. У нас есть немножечко инфы
об этом пользователе. Мы знаем, что он понаписал,
порекомендовал и даже и то и другое сразу.
А ещё у нас есть RSS.
если ты придумал велосипед - значит ты мыслишь в правильном направлении
если ты пишешь велосипед - значит ты учишься правильным вещам
если ты пытаешься использовать тобой же придуманный и написанный велосипед при наличии более качественного ранееизобретенного - значит ты дурак
думая тут о рабочих вопроса внезапно понял смысл "времени разбрасывать камни" и "времени собирать камни" в контексте го. Люди, которые умеют в правильное фусеки и не раз в своих играх видели, как в буквальном смысле разбросанные по доске в начале партии камни собираются в продуманные ансамбли, поймут о чем я.
а знаете, ведь,учитывая состояние наших дорог,бюрократический ад, культуру пидорасов в логистических компаниях и прочий транспортный пиздец, вполне ОЧЕВИДНО что всё бабло стремиться в ДС. И пока это не исправится, в особенности транстпортная составляющая - хрен у нас что будет в регионах нормального.
интересная мысль тут пришла. Суть такова: человеком движут 3 силы - фричество, лень и "рельсы" (следование традициям).
Фричество заставляет человека искать новые подходы, новые шаблоны, но оно закциклено на новизне и неустойчиво вцелом
Суть лени - минимизация. Везде всегда во всем. Поиск пути наименьшего сопротивления. Хорошие в том что она позволяет не "перегореть" и выбирать из имеющихся решений оптимальное
"Рельсы" - это кэш. Выборка из базы уже проверенных когда-то решений, уменьшая рисковать.
а еще жавовские гринтреды by design не гарантируют защиты от создания каким-нибудь неумелым кодером долгого цикла, дедлочащего на себя всю программу, в отличии от эрланга, который может прерывать процесс по таймеру практически на чем угодно(единственный известный мне на данный момент способ все сломать - это матчить 2 оченьоченьбольших специально сформатированных списка, каких в обычной жизни получить достаточно сложно)
Был тут давеча один разговор, в котором в том числе затронулась тема erlangVM vs javaVM. В нем форсился тезис о том что машина эрланга ниразу не уникальна и все то же можно сделать на жаве. В том числе и самое артитектурно значимое - разбиение кода на тысячи легковесных процессов\потоков\какещеономожетназываться.
Если кто не знает, в жаве гринтреды есть незнамосколькодавно. И по реализации они вроде как вполне себе легковестны. Насколько давно там есть неблокирующий ввод-вывод не вкурсе, но дело не столько в нем(хотя и в нем тоже, без повальной асинхронности получится очень мрачно и дедлочно).
Собственно в жаве нет возможности синхронизировать переход с одного потока на другой. Во всяком случае я не знаю как не сильно заморачиваясь реализовать посылку сообщения в мэйлбокс зеленой нитки так чтобы эта самая нитка, ежели она находится в состоянии ожидания сообщения из мэйлбокса, сразу начала выполняться независимо от причуд планировщика и без необходимости пистаь сотни тысяч классов под это дело.
сраные динамические языки развратили мой мозг. Они отучили меня думать капитально, убили во мне зайчатки навыков проектирования сложных приложений. Ведь зачем это делать если можно разбить все на отдельные задачи, решаемые отдельным скриптом, и потом склеить через самую удобную жопу из предоставляемых рантаймом нахаляву.
Цоперайт © 2010-2016 @stiletto.