LINUX.ORG.RU

История изменений

Исправление 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);

плюс тут в том, что парсить не нужно (но, честно говоря, это указывает на неполноценность языка)