Комментарии 52
Полностью согласен с вами!) Очень хорошие аргументы!))
сonspiracy theory - теория заговора, а вовсе не "теория конспирации". переводите аккуратнее.
Вы намекаете на то, что статья переводная?
Он не намекает, он утверждает. Теоретически, использование оборота «теория конспирации» возможно, как англицизм и в русском тексте, но «теория заговора» во всяком случае — правильный вариант.
В моем блоге нет и не будет украденных, переделанных либо переведенных статей.
Никто Вас в этом не обвиняет, просто "теория конспирации" по-русски, это не правильно. Правильно "теория заговора"
Зачем писать новые статьи, если уже есть готовые старые :)
Оба решения содержат один дефект метод сортировки массива должен быть статическим. Иначе придётся делать как-то так:
Это раз. Во-вторых, решение с getName() неудачное даже не из-за лишнего уровня вызова функций. getName() не обрабатывает некорректные значения параметров (по всей логике, допустимы только 0 и 1, а на самом деле нет). Да и ещё решение в таком виде провоцирует программиста рассыпать магические числа в местах вызова всех этих функций.
Person arr[] = new Person[10];
...
arr[0].sort(arr);
Это раз. Во-вторых, решение с getName() неудачное даже не из-за лишнего уровня вызова функций. getName() не обрабатывает некорректные значения параметров (по всей логике, допустимы только 0 и 1, а на самом деле нет). Да и ещё решение в таком виде провоцирует программиста рассыпать магические числа в местах вызова всех этих функций.
1. Методы сортировки не являются частью класса Person.
2. Проверки отсутствуют для того, чтобы не утяжелять пример.
Насчет магических чисел: пример действительно может показаться странным. Но с другой стороны, адресация полей объекта через индексы - это обычная практика. Например, такой способ доступа к полям используется в базах данных. Другой пример -
class Vector {
double x,y,z;
void set(int index, double value);
double get(int index);
}
В С++, С# для этого часто используют operator []. Очень удобно получается
Именно аналогия с сортировкой строк в базах данных может подтолкнуть к правильному ответу.
2. Проверки отсутствуют для того, чтобы не утяжелять пример.
Насчет магических чисел: пример действительно может показаться странным. Но с другой стороны, адресация полей объекта через индексы - это обычная практика. Например, такой способ доступа к полям используется в базах данных. Другой пример -
class Vector {
double x,y,z;
void set(int index, double value);
double get(int index);
}
В С++, С# для этого часто используют operator []. Очень удобно получается
Именно аналогия с сортировкой строк в базах данных может подтолкнуть к правильному ответу.
Пока программисты Java занимаются открытиями(изобретениями) в Perl все уже давным давно сделано(библиотеки кода) и работает ;)
У вас есть достаточный опыт работы с обеими языками или просто словами бросаетесь? Я в дискуссии о языках не вступаю, вы чувствуете что вы не в тему?
А кто вступал?
Мой опыт с Java небольшой (пару раз нужно было подправить кое-что и расширить функционал (было лет 7-8 назад)).
С Perl > 15 лет (периодически пишу скрипты, для себя). Дома хранятся письма от Larry ещё с прошлого века (http://www.wall.org/~larry).
Меня "до глубины души" поразила фраза: "Java - это такой особенный язык, разработчики которого очень продуманно подошли к проблеме разработки стандартных библиотек." :)
В Perl, который появился, когда разработчики Java были ещё студентами(или школьниками) уже существовал : http://cpan.perl.org и ни кто не превозносил это как супер свойство языка, а как само собой разумеющееся. :) Так что тут не вопрос о холиварах, а о глупом PR в целом неплохого языка.
Мой опыт с Java небольшой (пару раз нужно было подправить кое-что и расширить функционал (было лет 7-8 назад)).
С Perl > 15 лет (периодически пишу скрипты, для себя). Дома хранятся письма от Larry ещё с прошлого века (http://www.wall.org/~larry).
Меня "до глубины души" поразила фраза: "Java - это такой особенный язык, разработчики которого очень продуманно подошли к проблеме разработки стандартных библиотек." :)
В Perl, который появился, когда разработчики Java были ещё студентами(или школьниками) уже существовал : http://cpan.perl.org и ни кто не превозносил это как супер свойство языка, а как само собой разумеющееся. :) Так что тут не вопрос о холиварах, а о глупом PR в целом неплохого языка.
Ну вычеркните Java, впишите Perl и опубликуйте. Не в языке же дело.
Что и откуда вычеркнуть? :)
Прочтите внимательно мои сообщения...
Обидно когда неплохому, в целом, языку делается PR глупыми методами, это все рано что писать, наш автомобиль самый крутой потому что у него есть место для запасного колеса(у всех приличных машин оно есть по умолчанию)...
удачи :)
Прочтите внимательно мои сообщения...
Обидно когда неплохому, в целом, языку делается PR глупыми методами, это все рано что писать, наш автомобиль самый крутой потому что у него есть место для запасного колеса(у всех приличных машин оно есть по умолчанию)...
удачи :)
Не увидел в статье никакого пиара Java. Да и нафиг тут жабу пиарить?, тут вроде люди самостоятельные тусуются, свой выбор сделали.
2 winzard, согласен с вами 2 руками, большинство тут вполне самостоятельные(за исключением некоторых "подростков"), а кто в теме, прекрасно знают Java, Perl и все их + и -(как и не собираются холиварить на эти темы).
Своей репликой, я пытался только чуть заострить, что ОГРОМНЫЕ плюсы, Java не только из-за того, что у него есть готовые библиотеки("это такой особенный язык"). Такие библиотеки есть у многих языков. Хотя их наличие, в большинстве случаев, есть + языку. :)
Своей репликой, я пытался только чуть заострить, что ОГРОМНЫЕ плюсы, Java не только из-за того, что у него есть готовые библиотеки("это такой особенный язык"). Такие библиотеки есть у многих языков. Хотя их наличие, в большинстве случаев, есть + языку. :)
Второй пример аргумент не состоятельнее. Во-первых, можно и самому сортировку за NlogN написать (а в некоторых случаях и за N). Во-вторых, библиотечная функция сортировки иногда имеет свойство работать гораздо медленнее своей даже при одинаковых асимптотиках.
Использование шаблонов судьба подмастерья, мастер сам создает шаблоны.
6 причин чтобы не использовать стандартные библиотеки.
1. Штампованное колесо содержит ошибку во всех своих экземплярах. Примеры? - отзыв десятков тысяч машин при нахождении ошибки конструктора, патчи для ОС и браузеров на безопасность и т.д. При этом пользователь всегда на шаг отстает от злоумышленника, так как появляются шаблоны для использования ошибок - эксплойты ;-)
На практике практически никто не вычитывает чужой код перед его применением, и то что тысячи использует и использовали этот код до тебя не гарантирует отсутсвие в нем критических ошибок/ Пример - недавний случай с openssl http://deathoxy.habrahabr.ru/blog/42298.html
2. Свой код быстрее универсального.
3. Собственный код поддерживать дешевле, ненадо вычитывать изменения писанные сторонними разработчиками. Новые версии открытых библиотек зачастую несовместимы с предыдущими версиями. Изменения внесенные в стандартные библиотеке приводят к переписыванию своего кода.
4. Понимание чужого кода зависит только от опыта "вычитки", так как полет фантазии другого человека не стандартизируем.
5. Пример Вы удачный привели, в стандартной библиотеке - не стандатизированные интерфейсы - довод в пользу своего кода. ;-) В своем коде стандартизацию провести проще, чем подстраиваться под "историческую" традицию стандартных библиотек.
6. Я лучше знаю в чем я нуждаюсь ;-) Порой проще реализовать идею самому, чем костылями прикручивать стандартные средства.
ЗЫ. Я ни в коем разе не против стандартизованных библиотек, шаблонов, фреймворков и т.д. Это действительно ускоряет разработку, если разработчик ее использующий знает все тонкости работы этой библиотеки и досконально понимает ее код. Много ли людей при изучении библиотек уходят дальше ознакомления с описанием вызова функций и процедур? ;-)
То есть идея проста: нужен управляемый код? - нет места черным ящикам в нем!
6 причин чтобы не использовать стандартные библиотеки.
1. Штампованное колесо содержит ошибку во всех своих экземплярах. Примеры? - отзыв десятков тысяч машин при нахождении ошибки конструктора, патчи для ОС и браузеров на безопасность и т.д. При этом пользователь всегда на шаг отстает от злоумышленника, так как появляются шаблоны для использования ошибок - эксплойты ;-)
На практике практически никто не вычитывает чужой код перед его применением, и то что тысячи использует и использовали этот код до тебя не гарантирует отсутсвие в нем критических ошибок/ Пример - недавний случай с openssl http://deathoxy.habrahabr.ru/blog/42298.html
2. Свой код быстрее универсального.
3. Собственный код поддерживать дешевле, ненадо вычитывать изменения писанные сторонними разработчиками. Новые версии открытых библиотек зачастую несовместимы с предыдущими версиями. Изменения внесенные в стандартные библиотеке приводят к переписыванию своего кода.
4. Понимание чужого кода зависит только от опыта "вычитки", так как полет фантазии другого человека не стандартизируем.
5. Пример Вы удачный привели, в стандартной библиотеке - не стандатизированные интерфейсы - довод в пользу своего кода. ;-) В своем коде стандартизацию провести проще, чем подстраиваться под "историческую" традицию стандартных библиотек.
6. Я лучше знаю в чем я нуждаюсь ;-) Порой проще реализовать идею самому, чем костылями прикручивать стандартные средства.
ЗЫ. Я ни в коем разе не против стандартизованных библиотек, шаблонов, фреймворков и т.д. Это действительно ускоряет разработку, если разработчик ее использующий знает все тонкости работы этой библиотеки и досконально понимает ее код. Много ли людей при изучении библиотек уходят дальше ознакомления с описанием вызова функций и процедур? ;-)
То есть идея проста: нужен управляемый код? - нет места черным ящикам в нем!
Согласен, что эти пункты являются предметами для дискуссий. Для всех правил всегда найдутся исключения. Теперь еще раз по порядку.
1. Согласен, что если стоит вопрос безопасности, нужно осторожно выбирать существующие решения. Лучше 10 багов в своё коде, которые никому не известны, чем 1 баг, о котором знает каждая домохозяйка.
2. Я бы скорее сказал, что специализированный код часто быстрее универсального. Но то, что самописный код будет быстрее - это еще большой вопрос.
3. Здесь нужно помнить, что существуют мажорные и минорные изменения в библиотеках. Мажорные приводят к изменению интерфейсов, а минорные - к изменению реализации. Такая схема разработки поддерживается во многих java проектах. Соответственно, в случае если найден баг реализации, то он фиксится разработчиками библиотеки сразу в нескольких мажорных ветках. Безопасно апгрейдиться можно только на последнюю минорную ветку библиотеки.
4. Не совсем понял смысла фразы :)
5. Пример относился не к стандартным библиотекам. javax.xml.parsers.* - это стандарт, а httpclient - это нестандартная внешняя библиотека.
6. Согласен, я тоже часто так поступаю. Но обычно, если мне требуется создать новый серьезный функционал, то я потрачу полдня на поиск хорошей существующей библиотеки и только в случае неудачи буду писать всё сам.
Про черные ящики - я тоже за opensource :)
1. Согласен, что если стоит вопрос безопасности, нужно осторожно выбирать существующие решения. Лучше 10 багов в своё коде, которые никому не известны, чем 1 баг, о котором знает каждая домохозяйка.
2. Я бы скорее сказал, что специализированный код часто быстрее универсального. Но то, что самописный код будет быстрее - это еще большой вопрос.
3. Здесь нужно помнить, что существуют мажорные и минорные изменения в библиотеках. Мажорные приводят к изменению интерфейсов, а минорные - к изменению реализации. Такая схема разработки поддерживается во многих java проектах. Соответственно, в случае если найден баг реализации, то он фиксится разработчиками библиотеки сразу в нескольких мажорных ветках. Безопасно апгрейдиться можно только на последнюю минорную ветку библиотеки.
4. Не совсем понял смысла фразы :)
5. Пример относился не к стандартным библиотекам. javax.xml.parsers.* - это стандарт, а httpclient - это нестандартная внешняя библиотека.
6. Согласен, я тоже часто так поступаю. Но обычно, если мне требуется создать новый серьезный функционал, то я потрачу полдня на поиск хорошей существующей библиотеки и только в случае неудачи буду писать всё сам.
Про черные ящики - я тоже за opensource :)
4. При изучении иностранных языков, ровно как и при изучении родной литературы есть такое понятие как - начитанность, то есть не стоит ждать от человека прочитавшего букварь, что он поймет "Войну и мир". В случае разбора чужого кода это также верно. Чем больше опыт вычитки чужого кода, тем проще разбираться.
с остальным согласен ;-)
с остальным согласен ;-)
плюс не забывайте - Java это язык, в котором один раз написал - и работает везде (коенчно это не всегда так, если брать J2ME и т.д.), но ваша библиотека или код - может к примеру быстро работать на Windows и ужасно медленно работать на юниксах или маках. Так может пусть JVM будет решать как лучше на текущей системе делать сортировку или поиск - чем ваш "универсальный" код ?
и еще, один умный человек на писал (толи из IBM толи еще от куда)
Любая новая строчка кода - потенциально приводит к ошибке, есть даже статистика, на сколько строчек кода в среднем приходится ошибок, дак зачем увеличивать эти строчки кода,для получения новых ошибок ?
Любая новая строчка кода - потенциально приводит к ошибке, есть даже статистика, на сколько строчек кода в среднем приходится ошибок, дак зачем увеличивать эти строчки кода,для получения новых ошибок ?
Молодец!
Если так рассуждать... что ж вы пишете(надеюсь вы программист) на языке высокого уровня? Пишите все на асме, все будете разрабатывать сами. Забудьте про апп сервера, порталы и т.д. и все просто будет летать.
Такие тезисы годов 80х(примерно) кода начали появляться более высокоуровневые языки, когда старики ругали молодежь за использование с, паскаля ...
Допустим вы разработали библиотеку, почему бы ей не поделиться, чтобы ктото заново не изобретал велосипед, а сел и поехал на вашем?
Ваши рассуждения мне кажутся как минимум странными...
Такие тезисы годов 80х(примерно) кода начали появляться более высокоуровневые языки, когда старики ругали молодежь за использование с, паскаля ...
Допустим вы разработали библиотеку, почему бы ей не поделиться, чтобы ктото заново не изобретал велосипед, а сел и поехал на вашем?
Ваши рассуждения мне кажутся как минимум странными...
Пишу я действительно на языках высокого уровня. Когда то давно писал на Delphi - все наверно знакомы с приколами над дельфистами: "Где найти компонент?" =)
Я не говорил, что использование библиотек плохо, я говорил про то, что надо понимать что Вы используете, сколькими бы людьми до вас это не использовалось.
Насчет "Допустим вы разработали библиотеку, почему бы ей не поделиться..." - лицензионные и коммерческие ограничения играют свою роль. Закрытый код, даже написанный и разработанный мной - принадлежит заказчику, а не мне ;-)
Я не говорил, что использование библиотек плохо, я говорил про то, что надо понимать что Вы используете, сколькими бы людьми до вас это не использовалось.
Насчет "Допустим вы разработали библиотеку, почему бы ей не поделиться..." - лицензионные и коммерческие ограничения играют свою роль. Закрытый код, даже написанный и разработанный мной - принадлежит заказчику, а не мне ;-)
А на чем вы пишете если не секрет? Вы используете библиотеки которые не входят в стандартный набор языка? и почему?
Сейчас все больше PL/SQL оракловый, ну и по мелочи - php, xml, xslt и т.д.
Использую я библиотеки и стандартные, и собственной разработки. Но предпочитаю быть в курсе чего делается в библиотечке и чего от нее ждать.
Использую я библиотеки и стандартные, и собственной разработки. Но предпочитаю быть в курсе чего делается в библиотечке и чего от нее ждать.
Что то пропала охота с вами спорить. Я давно пишу на java, ее огромный плюс что задачи которые я решаю решал уже ктото до меня. Это громадное количество фреймворков (struts, spring, hibernate, ...), всяческих библиотек кастомных тэгов, библиотек (apache.commons). Как минимум глупо было бы все это не использовать, а тупо переписывать. Еще не факт что у вас получится лучше. Те люди который писали эти библиотеки "собаку съели" на этом деле, и у них больше опыта в этой тематике чем у вас.
После ухода 1-2 сотрудников, в головах которых содержатся основные знания об этом самописном коде ваши колёса превратятся в тыквы. Возможно, заодно с проектами.
Оформление и документирование самописного кода на уровне, достаточном для безболезненной потери его автора выливается в такую копеечку, что умеющие считать люди десять раз подумают и погуглят, прежде чем решатся на самостоятельную реализацию колеса.
Стандартные библиотеки отлаживаются и используются большим числом людей, чем вы можете надеяться со своими собственными разработками.
А если кому-то лень разбираться с чужим колесом так он и своё сделает коряво.
Оформление и документирование самописного кода на уровне, достаточном для безболезненной потери его автора выливается в такую копеечку, что умеющие считать люди десять раз подумают и погуглят, прежде чем решатся на самостоятельную реализацию колеса.
Стандартные библиотеки отлаживаются и используются большим числом людей, чем вы можете надеяться со своими собственными разработками.
А если кому-то лень разбираться с чужим колесом так он и своё сделает коряво.
Видите ли, даже использование сторонних стандартизированных библиотек, не дает никакой гарантии, что Вам будет проще разбираться в этом коде. Первое правило заказчика - требовать подробную документацию на продукт, без этого заказчик обречен постоянно платить за доработки и исправления ошибок. Документирование краегольный камень всех серьезных разработок, и разработчиков надо постоянно пинать чтобы они комментировали свой код. Если нехотите отвлекать сотрудников от генерации кода - заведите технического писателя, это гораздо дешевле, чем недокументировать код вообще. ;-)
А насчет стандартных библиотек, я знаю несколько серьезных контор, которые отказались от использования сторонних библиотек по юридическим причинам (банально не устраивает лицензия распространения и использования чужого кода), и тут волей-неволей приходится изобретать свои колеса.
Да и как я уже говорил, отладка и использование кода большим числом людей не дает никаких гарантий отностельно качества кода ;-) opensource он тоже разный бывает. Если вы посмотрите на наиболее популярные опенсоурс продукты и библиотеки, то в большинстве своем увидете - тех же 1-2 разработчиков которые ведут весь проект, и уход их из проекта чаще приводит к смерти продукта, а не его развития другими.
А насчет стандартных библиотек, я знаю несколько серьезных контор, которые отказались от использования сторонних библиотек по юридическим причинам (банально не устраивает лицензия распространения и использования чужого кода), и тут волей-неволей приходится изобретать свои колеса.
Да и как я уже говорил, отладка и использование кода большим числом людей не дает никаких гарантий отностельно качества кода ;-) opensource он тоже разный бывает. Если вы посмотрите на наиболее популярные опенсоурс продукты и библиотеки, то в большинстве своем увидете - тех же 1-2 разработчиков которые ведут весь проект, и уход их из проекта чаще приводит к смерти продукта, а не его развития другими.
Вы говорите о гарантиях, я о вероятности.
Да, документирование краеугольный камень. В случае сторонней стандартизированной библиотеки эта работа уже проделана. В случае популярной библиотеки про неё даже книги написаны.
Проблемы лицензирования относятся к самописному коду в той же мере, что и к публичному права на разработанный код могли уйти к заказчику. Изобретать индивидуальный велосипед для каждого заказчика? Дороговато. Завышать стоимость прочих работ, чтобы скрыть от заказчика наработки, которые планируется использовать в других проектах?
"Отладка и использование кода большим числом людей не дает никаких гарантий отностельно качества кода" гарантий не даёт, но вероятность заметно повышает. Помимо устранения собственных ошибок библиотеки, обычно учитывается масса чужих.
Если разработчики бросают серьёзный проект, и тот умирает либо появляется альтернативная библиотека, либо проект был несерьёзным и вы изначально сделали неверный выбор.
Кстати, о сотрудниках (в скобках замечу, что найти технического писателя обычно сложнее, чем библиотеку). Использование сторонних библиотек выгодно не только заказчику/работодателю, но и самому разработчику. Что лучше пять лет разрабатывать очередной велосипед и, уволившись, осознать, что твои знания о com.geocities.world.wide.selpro.podsobka.reportgen никому не нужны, или быть уверенным в том, что со своими знаниями и опытом сможешь найти работу без каких-либо проблем?
Да, документирование краеугольный камень. В случае сторонней стандартизированной библиотеки эта работа уже проделана. В случае популярной библиотеки про неё даже книги написаны.
Проблемы лицензирования относятся к самописному коду в той же мере, что и к публичному права на разработанный код могли уйти к заказчику. Изобретать индивидуальный велосипед для каждого заказчика? Дороговато. Завышать стоимость прочих работ, чтобы скрыть от заказчика наработки, которые планируется использовать в других проектах?
"Отладка и использование кода большим числом людей не дает никаких гарантий отностельно качества кода" гарантий не даёт, но вероятность заметно повышает. Помимо устранения собственных ошибок библиотеки, обычно учитывается масса чужих.
Если разработчики бросают серьёзный проект, и тот умирает либо появляется альтернативная библиотека, либо проект был несерьёзным и вы изначально сделали неверный выбор.
Кстати, о сотрудниках (в скобках замечу, что найти технического писателя обычно сложнее, чем библиотеку). Использование сторонних библиотек выгодно не только заказчику/работодателю, но и самому разработчику. Что лучше пять лет разрабатывать очередной велосипед и, уволившись, осознать, что твои знания о com.geocities.world.wide.selpro.podsobka.reportgen никому не нужны, или быть уверенным в том, что со своими знаниями и опытом сможешь найти работу без каких-либо проблем?
НЛО прилетело и опубликовало эту надпись здесь
1) JAVA это другой язык, и использование стандартных библиотек является основной идиологией этого языка. Все библиотеки которые идут в наборе а JAVA'ой полностью проверены и оттестированы, плюс они open Source.
2) свой код не быстрее и не уверсальнее, не хочу спорить надо этим долго, это приходит с опытом
3) свой код поддерживать не дешевле, но я говорю тут только о тех библиотеках которые входят в пакет SDK, на счет кода сторонних разработчиков спорно, все зависит от того что за проект и что за библиотека. Я к примеру в проекта использую библиотеку SNMP4J - это работа с SNMP протоколом, написание своей библиотеки займет ужасно много времени, чем я буду бодаться с глюками разработчиков этой библиотеки...
4) понимие чужого кода вообще ни от чего не зависит, чужой код можно без проблем понимать, но видеть его ужасность, и иметь большое желание все переделать, и нету гарантии, что потом другой человек не сделает так же. А если в команде работает 20 человек ? то что делать ? всем объяснять хитрость кода ? или надо иметь библиотеку - которая будет безошибочно работать. Или если проект в миллионы строчек, и где-то ошибка - то помойму проще искать ошибку в своем коде, и исключать ошибки в стандартных библиотеках, чем искать ошибку и в своих библиотеках и в своем коде и логике.
6) вы не знаете в чем вы нуждаетесь, пока не станете Архитектором проектов, или хотя бы Senior Java Developer, т.к. это приходит с опытом, и через два года вы можете полностью поменять свой взгляд на вещи.
2) свой код не быстрее и не уверсальнее, не хочу спорить надо этим долго, это приходит с опытом
3) свой код поддерживать не дешевле, но я говорю тут только о тех библиотеках которые входят в пакет SDK, на счет кода сторонних разработчиков спорно, все зависит от того что за проект и что за библиотека. Я к примеру в проекта использую библиотеку SNMP4J - это работа с SNMP протоколом, написание своей библиотеки займет ужасно много времени, чем я буду бодаться с глюками разработчиков этой библиотеки...
4) понимие чужого кода вообще ни от чего не зависит, чужой код можно без проблем понимать, но видеть его ужасность, и иметь большое желание все переделать, и нету гарантии, что потом другой человек не сделает так же. А если в команде работает 20 человек ? то что делать ? всем объяснять хитрость кода ? или надо иметь библиотеку - которая будет безошибочно работать. Или если проект в миллионы строчек, и где-то ошибка - то помойму проще искать ошибку в своем коде, и исключать ошибки в стандартных библиотеках, чем искать ошибку и в своих библиотеках и в своем коде и логике.
6) вы не знаете в чем вы нуждаетесь, пока не станете Архитектором проектов, или хотя бы Senior Java Developer, т.к. это приходит с опытом, и через два года вы можете полностью поменять свой взгляд на вещи.
Для несогласных со вторым аргументом не так давно тут был PHP-шный топик, в котором самописные методы поиска по массиву сравнивались с встроенной функцией. Встроенная работала в разы быстрее, потому что использовала более низкоуровневое представление данных, нежели используемое в языке.
Каждому джависту, желающему переизобретать колесо, предлагается подумать, готов ли он при необходимости переписать своё творение на C или ассемблере.
Каждому джависту, желающему переизобретать колесо, предлагается подумать, готов ли он при необходимости переписать своё творение на C или ассемблере.
"изобретение новых колёс" ^%_%^
Есть ещё одна группа людей, которые будут их изобретать. Просто потомучто они не хотят делать так, как делают все, им хочется всегда чего-то нового. Они руководствуются правилом.
Лучше изобрету 100 велосипедов и 1 что-то новое, чем изучу 200 велосипедов.
Может и глупо, но помоему очень правильно.
Есть ещё одна группа людей, которые будут их изобретать. Просто потомучто они не хотят делать так, как делают все, им хочется всегда чего-то нового. Они руководствуются правилом.
Лучше изобрету 100 велосипедов и 1 что-то новое, чем изучу 200 велосипедов.
Может и глупо, но помоему очень правильно.
НЛО прилетело и опубликовало эту надпись здесь
Просто сейчас стало модно писать самому и потом гордиться этим. Сам так грешу порой. И катятся, действительно, медленней. Другое дело, если нужно написать что-то, что не вписывается в рамки стандартной задачи, но включает ее.
Ваше колесо вообще не покатится. функция mySort написана неправильно. Так как есть, она не будет сортировать последний элемент массива.
Потому что по логике должно быть
for (int k = 0; k <= persons.length - 2; k++) {
а не
for (int k = 0; k < persons.length - 2; k++) {
Потому что по логике должно быть
for (int k = 0; k <= persons.length - 2; k++) {
а не
for (int k = 0; k < persons.length - 2; k++) {
а разве кто-то пишет свои функции работы с массивами.. Тут есть размытая грань. Скажем функция для массива - велосипедда и кто будет их писать опять же, а удачный форум или блог - нечто новое. А вот класс авторизации велосипед..? ох уж этот ваш велосипед..
Вот сейчас собираюсь воспользоваться Acts_as_authenticated (rails), интересно что из этого получится, т.к. плагин подглючивает. Учиться на чужих ошибках наверно надо как-то не так:)
пс
Простите если здесь только про java говорят:)
Вот сейчас собираюсь воспользоваться Acts_as_authenticated (rails), интересно что из этого получится, т.к. плагин подглючивает. Учиться на чужих ошибках наверно надо как-то не так:)
пс
Простите если здесь только про java говорят:)
А мы как раз разговаривали о том, что на собеседовании часто спрашивают алгоритмы сортировок, оказалось некоторые опытные программеры вообще о них не знают, т.к. пользовались уже готовыми функциями всегда...
Помоему знание конкретно алгоритмов или умение написать хороший алгоритм в современном программировании в принципе ничто.. Куда важнее понимание ООП, знание среды программирования, особенностей ОС, т.е. того, что к алгоритмам врядли можно отнести, а скорее к некой энциклопедической информации (опыту проще говоря). Теория, алгоритмы - это одно, практика, пожалуй, другое (это что относится к собеседованию). И если и говорить о необходимости велосипедов, то только высокоуровневых на мой взгляд.
В конце 90-х, когда набирал сотрудников в отдел разработок давал анкету из 10 вопросов от "Что такое DOS" - до "отсортируйте массив". До собеседования не доходила примерно половина.
Год назад 1Сника искал на сложный проект, заставлял написать сортировку массива любым методом на любом языке. Шоке-Шоке.
Налицо "Одебиливание". Никто не то чтобы не хочет изобретать колес. По-моему сейчас уже 90% тупо не могут их изобрести..
Статистика - 2 из 10 набросали алгоритм..
Год назад 1Сника искал на сложный проект, заставлял написать сортировку массива любым методом на любом языке. Шоке-Шоке.
Налицо "Одебиливание". Никто не то чтобы не хочет изобретать колес. По-моему сейчас уже 90% тупо не могут их изобрести..
Статистика - 2 из 10 набросали алгоритм..
Не хочу сказать, что не разделяю точку зрения автора, однако ради полноты описания приведу контраргументы.
1. В некоторых случаях время на поиск/изучение/овладение оказывается больше, нежели на собственную имплементацию. Пример: Hibernate vs Сustom JDBC ORM.
2. Сторонние библиотеки также имеют ошибки. Одно дело, если мы говорим об отлаженном rt или apache, другое - если мы полагаемся на разработки Васи Пупкина. Собственные ошибки исправить намного быстрее и проще, нежели ошибки сторонних производителей. Иногда приходится прибегать к workarounds. Мой экспириенс в использовании графических библиотек к Java типа Substance, SwingX и Scenegraph - хождение по мукам: сыро и глючно. Проект оброс большим количеством подпорок (workarounds).
3. Как правило библиотеки предоставляют широкий функционал для покрытия разного рода задач. А зачастую в проекте требуется решить лишь одну задачу. Приходится интегрировать всю библиотеку. Пример: для чтения файла с веба лучше использовать обычный URLConnection, нежели вставлять Apache HttpClient.
4. Кострость библиотек. Собственный код проще "заточить" под решение определенной задачи, и сделать его эффективней. Пример: для своей клиентсерверной апликации я написал свой RMI фреймворк, который может работать в реальном времени на интернет коннекшнах через прокси, и вообще абстрагируется от транспорта. Сериализованные объекты оптимизированны и занимают несколько байт.
5. Зависимости. Многие библиотеки, типа apache, таскают с собой огромный ряд зависимостей. Усложняется интеграция. Пример: для интеграции Apache HttpClient требуется apache-commons, apache-logging, etc...
Так что - выбирай, но осторожно.
1. В некоторых случаях время на поиск/изучение/овладение оказывается больше, нежели на собственную имплементацию. Пример: Hibernate vs Сustom JDBC ORM.
2. Сторонние библиотеки также имеют ошибки. Одно дело, если мы говорим об отлаженном rt или apache, другое - если мы полагаемся на разработки Васи Пупкина. Собственные ошибки исправить намного быстрее и проще, нежели ошибки сторонних производителей. Иногда приходится прибегать к workarounds. Мой экспириенс в использовании графических библиотек к Java типа Substance, SwingX и Scenegraph - хождение по мукам: сыро и глючно. Проект оброс большим количеством подпорок (workarounds).
3. Как правило библиотеки предоставляют широкий функционал для покрытия разного рода задач. А зачастую в проекте требуется решить лишь одну задачу. Приходится интегрировать всю библиотеку. Пример: для чтения файла с веба лучше использовать обычный URLConnection, нежели вставлять Apache HttpClient.
4. Кострость библиотек. Собственный код проще "заточить" под решение определенной задачи, и сделать его эффективней. Пример: для своей клиентсерверной апликации я написал свой RMI фреймворк, который может работать в реальном времени на интернет коннекшнах через прокси, и вообще абстрагируется от транспорта. Сериализованные объекты оптимизированны и занимают несколько байт.
5. Зависимости. Многие библиотеки, типа apache, таскают с собой огромный ряд зависимостей. Усложняется интеграция. Пример: для интеграции Apache HttpClient требуется apache-commons, apache-logging, etc...
Так что - выбирай, но осторожно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не изобретайте колёса! 6 причин от Java мастера пользоваться существующими.