История изменений
Исправление a--, (текущая версия) :
Мне работу работать, а не эстетствовать.
можно И работать, И эстетствовать — правда вот сходу из более-менее приличного я вспомнил только osquery, которая неидеальная, так как сделана на основе sqlite3 с его динамической типизацией головного мозга (или даже чем-то похуже)
Где, кроме find, мне пригодится знание конструкции -size +1M? Нигде.
твое объяснение неполноценности (inferiority) bash+find правильное, но osquery такой неполноценностью для чисел не страдает, и для строк тоже
давай рассмотрим с похожей точки зрения powershell vs. osquery
1. powershell умеет сравнивать через -gt и строки, и числа?
2. powershell умеет сравнивать через -gt другие типы данных?
Нигде.
чисто поспорить: так делают очень часто в языках уровня java; например
MyCollection c2 = c1
.whereSizeMoreThan(100).AND().whereSizeLessThan(200)
.OR().whereSizeMoreThan(300).AND().whereSizeLessThan(400);
либо даже так
MyCollection c2 = c1
.whereSize(+100).AND().whereSize(-200)
.OR().whereSize(+300).AND().whereSize(-400);
плюс тут в том, что парсить не нужно (но, скорее всего, это указывает на неполноценность языка — туда не завезли expression trees, которые имеются в LINQ)
Исправление a--, :
Мне работу работать, а не эстетствовать.
можно И работать, И эстетствовать — правда вот сходу из более-менее приличного я вспомнил только osquery, которая неидеальная, так как сделана на основе sqlite3 с его динамической типизацией головного мозга (или даже чем-то похуже)
Где, кроме find, мне пригодится знание конструкции -size +1M? Нигде.
твое объяснение неполноценности (inferiority) bash+find правильное, но osquery такой неполноценностью для чисел не страдает
давай рассмотрим с похожей точки зрения powershell vs. osquery
1. powershell умеет сравнивать через -gt и строки, и числа?
2. powershell умеет сравнивать через -gt другие типы данных?
Нигде.
чисто поспорить: так делают очень часто в языках уровня java; например
MyCollection c2 = c1
.whereSizeMoreThan(100).AND().whereSizeLessThan(200)
.OR().whereSizeMoreThan(300).AND().whereSizeLessThan(400);
либо даже так
MyCollection c2 = c1
.whereSize(+100).AND().whereSize(-200)
.OR().whereSize(+300).AND().whereSize(-400);
плюс тут в том, что парсить не нужно (но, скорее всего, это указывает на неполноценность языка — туда не завезли expression trees, которые имеются в LINQ)
Исправление a--, :
Мне работу работать, а не эстетствовать.
можно И работать, И эстетствовать — правда вот сходу из более-менее приличного я вспомнил только osquery, которая неидеальная, так как сделана на основе sqlite3 с его динамической типизацией головного мозга (или даже чем-то похуже)
Где, кроме find, мне пригодится знание конструкции -size +1M? Нигде.
твое объяснение неполноценности (inferiority) bash+find правильное, но osquery такой неполноценностью для чисел не страдает
давай рассмотрим с похожей точки зрения powershell vs. osquery
1. powershell умеет сравнивать через -gt и строки, и числа?
2. powershell умеет сравнивать через -gt другие типы данных?
Нигде.
чисто поспорить: так делают очень часто в языках уровня java; например
MyCollection c2 = c1
.whereSizeMoreThan(100).AND().whereSizeLessThan(200)
.OR().whereSizeMoreThan(300).AND().whereSizeLessThan(400);
либо даже так
MyCollection c2 = c1
.whereSize(+100).AND().whereSize(-200)
.OR().whereSize(+300).AND().whereSize(-400);
плюс тут в том, что парсить не нужно (но, честно говоря, это указывает на неполноценность языка — туда не завезли expression trees, которые имеются в LINQ)
Исправление a--, :
Мне работу работать, а не эстетствовать.
можно И работать, И эстетствовать — правда вот сходу из более-менее приличного я вспомнил только osquery, которая неидеальная, так как сделана на основе sqlite3 с его динамической типизацией головного мозга
Где, кроме find, мне пригодится знание конструкции -size +1M? Нигде.
твое объяснение неполноценности (inferiority) bash+find правильное, но osquery такой неполноценностью для чисел не страдает
давай рассмотрим с похожей точки зрения powershell vs. osquery
1. powershell умеет сравнивать через -gt и строки, и числа?
2. powershell умеет сравнивать через -gt другие типы данных?
Нигде.
чисто поспорить: так делают очень часто в языках уровня java; например
MyCollection c2 = c1
.whereSizeMoreThan(100).AND().whereSizeLessThan(200)
.OR().whereSizeMoreThan(300).AND().whereSizeLessThan(400);
либо даже так
MyCollection c2 = c1
.whereSize(+100).AND().whereSize(-200)
.OR().whereSize(+300).AND().whereSize(-400);
плюс тут в том, что парсить не нужно (но, честно говоря, это указывает на неполноценность языка — туда не завезли expression trees, которые имеются в LINQ)
Исправление a--, :
Мне работу работать, а не эстетствовать.
можно И работать, И эстетствовать — правда вот сходу из более-менее приличного я вспомнил только osquery, которая неидеальная, так как сделана на основе sqlite3 с его динамической типизацией головного мозга
Где, кроме find, мне пригодится знание конструкции -size +1M? Нигде.
твое объяснение неполноценности (inferiority) bash+find правильное; давай рассмотрим с этой точки зрения powershell vs. osquery
1. powershell умеет сравнивать через -gt и строки, и числа?
2. powershell умеет сравнивать через -gt другие типы данных?
Нигде.
чисто поспорить: так делают очень часто в языках уровня java; например
MyCollection c2 = c1
.whereSizeMoreThan(100).AND().whereSizeLessThan(200)
.OR().whereSizeMoreThan(300).AND().whereSizeLessThan(400);
либо даже так
MyCollection c2 = c1
.whereSize(+100).AND().whereSize(-200)
.OR().whereSize(+300).AND().whereSize(-400);
плюс тут в том, что парсить не нужно (но, честно говоря, это указывает на неполноценность языка — туда не завезли expression trees, которые имеются в LINQ)
Исправление a--, :
Я не про «хорошо» или «плохо». Мне работу работать, а не эстетствовать.
можно И работать, И эстетствовать — правда вот сходу из более-менее приличного я вспомнил только osquery, которая неидеальная, так как сделана на основе sqlite3 с его динамической типизацией головного мозга
Где, кроме find, мне пригодится знание конструкции -size +1M? Нигде.
твое объяснение неполноценности правильное; давай рассмотрим с этой точки зрения powershell vs. osquery
1. powershell умеет сравнивать через -gt и строки, и числа?
2. powershell умеет сравнивать через -gt другие типы данных?
Нигде.
чисто поспорить: так делают очень часто в языках уровня java; например
MyCollection c2 = c1
.whereSizeMoreThan(100).AND().whereSizeLessThan(200)
.OR().whereSizeMoreThan(300).AND().whereSizeLessThan(400);
либо даже так
MyCollection c2 = c1
.whereSize(+100).AND().whereSize(-200)
.OR().whereSize(+300).AND().whereSize(-400);
плюс тут в том, что парсить не нужно (но, честно говоря, это указывает на неполноценность языка — туда не завезли expression trees, которые имеются в LINQ)
Исправление a--, :
Я не про «хорошо» или «плохо». Мне работу работать, а не эстетствовать.
можно И работать, И эстетствовать — правда вот сходу из более-менее приличного я вспомнил только osquery, которая неидеальная, так как сделана на основе sqlite3 с его динамической типизацией головного мозга
Где, кроме find, мне пригодится знание конструкции -size +1M? Нигде.
твое объяснение неполноценности правильное; давай рассмотрим с этой точки зрения powershell vs. osquery (osquery отнюдь не лучшее, но живое и практичное для определенных применений)
1. powershell умеет сравнивать через -gt и строки, и числа?
2. powershell умеет сравнивать через -gt другие типы данных?
Нигде.
чисто поспорить: так делают очень часто в языках уровня java; например
MyCollection c2 = c1
.whereSizeMoreThan(100).AND().whereSizeLessThan(200)
.OR().whereSizeMoreThan(300).AND().whereSizeLessThan(400);
либо даже так
MyCollection c2 = c1
.whereSize(+100).AND().whereSize(-200)
.OR().whereSize(+300).AND().whereSize(-400);
плюс тут в том, что парсить не нужно (но, честно говоря, это указывает на неполноценность языка — туда не завезли expression trees, которые имеются в LINQ)
Исправление a--, :
Я не про «хорошо» или «плохо». Мне работу работать, а не эстетствовать.
можно И работать, И эстетствовать — правда вот сходу для вспомнил только osquery, которая неидеальная, так как сделана на основе sqlite3 с его динамической типизацией головного мозга
Где, кроме find, мне пригодится знание конструкции -size +1M? Нигде.
твое объяснение неполноценности правильное; давай рассмотрим с этой точки зрения powershell vs. osquery (osquery отнюдь не лучшее, но живое и практичное для определенных применений)
1. powershell умеет сравнивать через -gt и строки, и числа?
2. powershell умеет сравнивать через -gt другие типы данных?
Нигде.
чисто поспорить: так делают очень часто в языках уровня java; например
MyCollection c2 = c1
.whereSizeMoreThan(100).AND().whereSizeLessThan(200)
.OR().whereSizeMoreThan(300).AND().whereSizeLessThan(400);
либо даже так
MyCollection c2 = c1
.whereSize(+100).AND().whereSize(-200)
.OR().whereSize(+300).AND().whereSize(-400);
плюс тут в том, что парсить не нужно (но, честно говоря, это указывает на неполноценность языка — туда не завезли expression trees, которые имеются в LINQ)
Исправление a--, :
Я не про «хорошо» или «плохо». Мне работу работать, а не эстетствовать.
можно И работать, И эстетствовать — правда вот сходу для вспомнил только osquery, которая неидеальная, так как сделана на основе sqlite3 с его динамической типизацией головного мозга
Где, кроме find, мне пригодится знание конструкции -size +1M? Нигде.
твое объяснение неполноценности правильное; давай рассмотрим с этой точки зрения powershell vs. osquery (osquery отнюдь не лучшее, но живое и практичное для определенных применений)
1. powershell умеет сравнивать через -gt и строки, и числа?
2. powershell умеет сравнивать через -gt другие типы данных?
Нигде.
чисто поспорить: так делают очень часто в языках уровня java; например
MyCollection c2 = c1
.whereSizeMoreThan(100).AND().whereSizeLessThan(200)
.OR().whereSizeMoreThan(300).AND().whereSizeLessThan(400);
либо даже так
MyCollection c2 = c1
.whereSize(+100).AND().whereSize(-200)
.OR().whereSize(+300).AND().whereSize(-400);
плюс тут в том, что парсить не нужно (но, честно говоря, это указывает на неполноценность языка — туда не завезли expression trees)
Исходная версия a--, :
Я не про «хорошо» или «плохо». Мне работу работать, а не эстетствовать.
можно И работать, И эстетствовать — правда вот сходу для вспомнил только osquery, которая неидеальная, так как сделана на основе sqlite3 с его динамической типизацией головного мозга
Где, кроме find, мне пригодится знание конструкции -size +1M? Нигде.
твое объяснение неполноценности правильное; давай рассмотрим с этой точки зрения powershell vs. osquery (osquery отнюдь не лучшее, но живое и практичное для определенных применений)
1. powershell умеет сравнивать через -gt и строки, и числа?
2. powershell умеет сравнивать через -gt другие типы данных?
Нигде.
чисто поспорить: так делают очень часто в языках уровня java; например
MyCollection c2 = c1
.whereSizeMoreThan(100).AND().whereSizeLessThan(200)
.OR().whereSizeMoreThan(300).AND().whereSizeLessThan(400);
либо даже так
MyCollection c2 = c1
.whereSize(+100).AND().whereSize(-200)
.OR().whereSize(+300).AND().whereSize(-400);
плюс тут в том, что парсить не нужно (но, честно говоря, это указывает на неполноценность языка)