Не, ну в принципе в метаданных процедуры скорее всего есть все что нужно, я это просто к тому, что это а) это не слишком просто, б) не является частью стандарта SQL-92, и в) все это можно узнать только у базы, путем выполнения запроса. То есть просто парсер тут ничего не даст, по внешнему виду вызова процедуры ничего не видно.
Идете в любой интернет-магазин, или скажем на Яндекс Маркет, открываете раздел маршрутизаторов или wi-fi, включаете галочку «USB-порт», и смотрите длинный список оборудования, к которому можно подключать диски. Там будут и NAS, и модемы, и медиа-плееры, и много чего еще.
И эти вопросы отпадают сами собой.
Эти люди — покупатели обычных магазинов, порты там открыты — потому что производитель прошляпил, поменялось это много лет назад — у меня первый такой домашний аппарат был еще в 2009 кажется.
А можно показать конкретно, что именно вы поняли неоднозначно? Дело в том, что приведенные примеры (скажем, фразу про символ / для деления) реальными проблемами не являются.
Ну то есть я понимаю вашу цель сделать хороший перевод, и сам всегда старался поступать также, но на практике переводы именно таких документов, как спецификация языка — дело совершенно лишнее. В первую очередь — по причине их устаревания.
То есть, если компания Оракл не заказывает вам перевод каждой очередной версии спецификации языка, причем в идеале — еще до ее выпуска, т.е. синхронно с оригиналом, то эта благородная деятельность вероятно останется неблагодарной и никем не оцененной.
Не совсем так. Оператор — это все-таки как правило +, -, * и т.п. А инструкция — это например if/switch. Но присваивание тоже называют и инструкцией и оператором.
На мой взгляд, то о чем тут говорится (по крайней мере приведенные примеры) — это мелкие и не слишком существенные вещи. И обычно не вызывающие проблем для понимания.
В спецификации Java есть вещи намного более сложные, типа memory model например.
Ну и наконец, присоединюсь к комментарию ниже — на русские переводы вообще не стоит рассчитывать. Если ты программист и профессионал — ты обязан читать в оригинале, потому что имеющийся перевод все равно устареет максимум через пару лет (появление Java 8 сделало многие документы практически бесполезными, с Java 9 похоже предстоит все тоже самое).
А если ты начинающий — тебе спецификация языка не особенно и нужна, как правило. Не в первую очередь.
Поддержу. 2-3 летний проект, частично сделанный на версии 2008 этого инструмента, постоянно возникало желание все выбросить, и переписать заново.
К уже сказанному могу добавить следующее:
— ужасно неудобно работать с чужим проектом. Найти что-либо, понять, где формируется скажем значение какой-то колонки — практически не реально. Это означает нулевую сопровождаемость написанного.
— с не DVCS он тоже плохо стыкуется. Попробуйте понять, что изменилось в вашем проекте между ревизиями.
— если у вас изменились метаданые в какой-то из таблиц, проект зачастую просто перестает работать. Даже если на уровне SQL все осталось совместимо (т.е. мы не меняли скажем тип с varchar на int). Бороться с этим ужасно муторно.
Есть кстати некий проект, где предлагается писать пакеты SSIS на F#. В виде кода. Частично поддерживается импорт готовых проектов, сделанных в VS.
Не знаю, что там в версии 2014, а 2008 однозначно никому бы не посоветовал. Я пробовать переписывать куски на Java + Camel — обычно получалось значительно проще, понятнее, и как правило быстрее.
Ну, если вас 2 устраивает, то версия 2.7 есть, в этом плане все более-менее хорошо. А с учетом того, что доступна вся инфраструктура Java, я бы даже сказал, что очень хорошо. Для некоторых задач. Я когда-то применял внутри Weblogic — и остался более чем доволен.
Вы пропустили gradle? Серьезно? А в остальном — да, это некоторые из реальных недостатков (ну, их можно считать такими).
1. По умолчаню — никак. А вообще примерно как в Java, можно написать аннотацию Immutable, т.е. по сути — на уровне обработки AST где-то достигается. Встроено в язык.
2. В принципе. средства расширения языка (включая и лямбды сюда же) вполне позволяют например написать свой цикл until, имея только лямбды. Не задумывался об этом, но подозреваю, что можно сделать вполне пригодное что-то.
3. Простой запрос гуглю отвечает ссылкой http://groovy-lang.org/semantics.html#_object_destructuring_with_multiple_assignment, которая показывает, что это тоже одна из возможностей расширения языка. Т.е. есть multi assignment, и можно кое-какие методы объекту дописать, чтобы он деструктурировался. Не блестяще наверное, но напомню — этому языку уже лет 10.
4. По-моему также, как в Java. Тип T можно узнать, он сохраняется в байткоде, но скажем так — не слишком прямолинейно это делается. Я подозреваю, большинство программистов про этот способ не слышали. TypeToken например погуглите, это из guava. Type erasure тут сильно мешает, и язык мало что может с этим сделать (разве что нарушив совместимость с Java на уровне байткода, что мы видим на примере скалы).
Знаете, за последние лет 10 наверное, я ни разу не встречал такого проекта, где бы я не мог обосновать руководству или заказчику, что надо писать на таком-то инструменте.
Т.е. было такое, когда заказчик скажем говорит — у нас куплены Oracle и Weblogic, делаем на них (версии такие-то). Но при этом спокойно можно было параллельно брать любой другой инструмент, который повышает вашу производительность или качество кода. Вменяемый заказчик — только за такое.
Сейчас вот на моем бывшем проекте, откуда я ушел, пытаются переписывать на котлин. Я бы этого не стал делать (не потому что язык плох, а скорее потому, что основные проблемы лежат не в той в плоскости, чтобы их решал другой язык разработки), но опять же — заказчику все равно, ты разработчик — ты и выбирай инструмент. Если он бесплатен и хоть более-менее распространен — как правило всем кроме вас это до лампочки.
Знаете, я в прошлой статье про котлин прокомментировал в том же духе — так мне минусов понаставили. Причем аргументировали один раз — что производительность groovy плохая (а подтвердить при этом ничем не удосужились). А по сути тут вопрос ровно тот же встает — а чем это лучше groovy? Который не просто появился давно, но и распространен весьма широко (как сам по себе, так и в виде gradle например, и не только), и большую часть ровно этих же преимуществ имеет (ну кроме компиляции в JS, пожалуй).
Я прекрасно понимаю, что это библиотека. Я в общем-то просто прокомментировал вот эту фразу:
>На Java нет даже близко ничего подобного
Это все-таки не совсем верно. Есть многое, хотя и не совсем таким же образом реализованное. Тот же ломбок, к примеру.
Ну и сделать такое можно далеко не в любом языке, и вообще говоря, когда не было лямбд, сделать такое в Java было практически нельзя (либо было чрезвычайно неудобно пользоваться).
Т.е. мысль-то моя простая — если язык позволяет сделать библиотекой то, что в другом языке требует изменений компилятора — это хороший, годный язык. Ну, типа лиспа :)
В общем случае — нельзя. Хранимая процедура может возвращать результат как select, а может и нет. Узнать вы это можете — но только при выполнении.
А вы уверены, что не потеряете при этом всю расширенную функциональность конкретной реализации?
Идете в любой интернет-магазин, или скажем на Яндекс Маркет, открываете раздел маршрутизаторов или wi-fi, включаете галочку «USB-порт», и смотрите длинный список оборудования, к которому можно подключать диски. Там будут и NAS, и модемы, и медиа-плееры, и много чего еще.
И эти вопросы отпадают сами собой.
Эти люди — покупатели обычных магазинов, порты там открыты — потому что производитель прошляпил, поменялось это много лет назад — у меня первый такой домашний аппарат был еще в 2009 кажется.
Ну то есть я понимаю вашу цель сделать хороший перевод, и сам всегда старался поступать также, но на практике переводы именно таких документов, как спецификация языка — дело совершенно лишнее. В первую очередь — по причине их устаревания.
То есть, если компания Оракл не заказывает вам перевод каждой очередной версии спецификации языка, причем в идеале — еще до ее выпуска, т.е. синхронно с оригиналом, то эта благородная деятельность вероятно останется неблагодарной и никем не оцененной.
На мой взгляд, то о чем тут говорится (по крайней мере приведенные примеры) — это мелкие и не слишком существенные вещи. И обычно не вызывающие проблем для понимания.
В спецификации Java есть вещи намного более сложные, типа memory model например.
Ну и наконец, присоединюсь к комментарию ниже — на русские переводы вообще не стоит рассчитывать. Если ты программист и профессионал — ты обязан читать в оригинале, потому что имеющийся перевод все равно устареет максимум через пару лет (появление Java 8 сделало многие документы практически бесполезными, с Java 9 похоже предстоит все тоже самое).
А если ты начинающий — тебе спецификация языка не особенно и нужна, как правило. Не в первую очередь.
К уже сказанному могу добавить следующее:
— ужасно неудобно работать с чужим проектом. Найти что-либо, понять, где формируется скажем значение какой-то колонки — практически не реально. Это означает нулевую сопровождаемость написанного.
— с не DVCS он тоже плохо стыкуется. Попробуйте понять, что изменилось в вашем проекте между ревизиями.
— если у вас изменились метаданые в какой-то из таблиц, проект зачастую просто перестает работать. Даже если на уровне SQL все осталось совместимо (т.е. мы не меняли скажем тип с varchar на int). Бороться с этим ужасно муторно.
Есть кстати некий проект, где предлагается писать пакеты SSIS на F#. В виде кода. Частично поддерживается импорт готовых проектов, сделанных в VS.
Не знаю, что там в версии 2014, а 2008 однозначно никому бы не посоветовал. Я пробовать переписывать куски на Java + Camel — обычно получалось значительно проще, понятнее, и как правило быстрее.
1. По умолчаню — никак. А вообще примерно как в Java, можно написать аннотацию Immutable, т.е. по сути — на уровне обработки AST где-то достигается. Встроено в язык.
2. В принципе. средства расширения языка (включая и лямбды сюда же) вполне позволяют например написать свой цикл until, имея только лямбды. Не задумывался об этом, но подозреваю, что можно сделать вполне пригодное что-то.
3. Простой запрос гуглю отвечает ссылкой http://groovy-lang.org/semantics.html#_object_destructuring_with_multiple_assignment, которая показывает, что это тоже одна из возможностей расширения языка. Т.е. есть multi assignment, и можно кое-какие методы объекту дописать, чтобы он деструктурировался. Не блестяще наверное, но напомню — этому языку уже лет 10.
4. По-моему также, как в Java. Тип T можно узнать, он сохраняется в байткоде, но скажем так — не слишком прямолинейно это делается. Я подозреваю, большинство программистов про этот способ не слышали. TypeToken например погуглите, это из guava. Type erasure тут сильно мешает, и язык мало что может с этим сделать (разве что нарушив совместимость с Java на уровне байткода, что мы видим на примере скалы).
Ну и все-таки, размеры кода сильно сократились в итоге, что позволило его быстрее писать и легче читать.
Т.е. было такое, когда заказчик скажем говорит — у нас куплены Oracle и Weblogic, делаем на них (версии такие-то). Но при этом спокойно можно было параллельно брать любой другой инструмент, который повышает вашу производительность или качество кода. Вменяемый заказчик — только за такое.
Сейчас вот на моем бывшем проекте, откуда я ушел, пытаются переписывать на котлин. Я бы этого не стал делать (не потому что язык плох, а скорее потому, что основные проблемы лежат не в той в плоскости, чтобы их решал другой язык разработки), но опять же — заказчику все равно, ты разработчик — ты и выбирай инструмент. Если он бесплатен и хоть более-менее распространен — как правило всем кроме вас это до лампочки.
P.S. Мне тоже `` напоминает кое-что из того, что хотелось бы забыть.
>На Java нет даже близко ничего подобного
Это все-таки не совсем верно. Есть многое, хотя и не совсем таким же образом реализованное. Тот же ломбок, к примеру.
Ну и сделать такое можно далеко не в любом языке, и вообще говоря, когда не было лямбд, сделать такое в Java было практически нельзя (либо было чрезвычайно неудобно пользоваться).
Т.е. мысль-то моя простая — если язык позволяет сделать библиотекой то, что в другом языке требует изменений компилятора — это хороший, годный язык. Ну, типа лиспа :)