LINUX.ORG.RU

Чувства неполноценности тред: знает ли кто-нибудь свой стандарт и сдк?

 , ,


2

3

Сабж

Обычно считается, что разработчик должен знать стандарт своего языка, как минимум прочитать. Должен хотя бы поверхностно знать детали реализации тех средств, которыми он пользуется. По крайней мере этому учат в институте, спрашивают на собеседованиях, об этом разговаривают на ЛОРе.

Теперь вопрос на засыпку. Воспользуюсь преимуществом большого и толстого мэйнстрима, вот вам два языка: Java и С++. Хотя борщевиков тоже интересно услышать, у них особая ситуация - неписаные стандарты.

Вопросы:

1) Кто из лоровцев читал и _знает_ свои стандарты? Соответственно, для Java это Java Language Specification и Java Virtual Machine Specificaiton for Java 8 SE Edition, и для С++ это ISO/IEC 14882:2011 C++ International Standard

2) Кто из лоровцев чистал свои сдк, и знает как они работают? Вот так по чесноку, положа ногу на сердце. Соответственно, JDK stable (сейчас JDK8), JDK current (сейчас JDK9) для Java, и STL/Boost/Qt для C++

Я сейчас пытаюсь хотя бы просто по одному разу прочитать JDK9, и это уже чувствуется как титанический труд. Там чуть больше 10 тысяч классов, я успеваю прочитать пару десятков в день, и в памяти остается только самое поверхностное понимание, скорее даже неуловимое послевкусие, как от если на улице случайно пройти мимо восхитительной девушке. Java Language Specification я прочитал раз десять, но все равно находятся места, которые видишь как в первый раз.

Про C++ даже не заикаюсь - его стандарт я даже не пытался запоминать, чтобы схватить лютый баттхерт хватит прочитать пару десятков страниц, и все, оперативная память мозга закончилась.

Но.......

Между тем, я довольно часто встречаю людей, которые выносят мозг знанием детальных подробностей целых кусков SDK.

Хотелось бы услышать тут отзывы этих героических людей. Истории успеха. Какие-то советы, как достичь подобных вершин. Спасибо.

★★★★☆

Звучит как слишком серьёзное отношение к не слишком строгим вещам. Звучит как бессмысленная трата времени.

Deleted
()

Иметь общие представления на уровень или два ниже используемой абстракции нужно. А читать стандарты надо в первую очередь разработчикам инфраструктуры, а остальным по желанию/необходимости.

PolarFox ★★★★★
()

не твое это все, ох не твое

anonymous
()
Ответ на: комментарий от Deleted

Ну вот например, хочешь ты внести исправления в JDK9. Например, предложить сообещству выделить подпроект для работы с жесткими дисками (чисто от фонаря предположил -). Или, например, сделать рефакторинг - а давайте поубираем везде где не надо файналы, задолбали они. Подозреваю/уверен, что это потребует серьезной проработки и обоснования для сообщества влияния на все остальные подсистемы. Например, как скажется убирание файналов на перфомансе. Или как должно быть реорганизовано nio под новую архитектуры работы с дисками. И тут оказывается, что ты вообще не шаришь. EPIC FAIL.

stevejobs ★★★★☆
() автор топика

Я думаю что это overkill. Просто сесть и безумно читать - нечего не запомнишь, структуру не поймешь.

Более оптимально хорошо научиться разбираться в двух вещах - общей картине и теоретических основах. Тогда вы будете просто знать необходимые элементы современного программирования. Вот нужен вам какой-то атомарный счетчик (увы) - вы знаете такое понятие и ищете его в своем ЯП. Нужно знать плюсы и минусы и наиболее вероятную реализацию

vertexua ★★★★★
()
Ответ на: комментарий от stevejobs

Есть люди которые шарят, а от тебя требуется поднять вопрос, выдержать критику знающих людей и с их согласия начать пилить, причем так как они посоветуют

vertexua ★★★★★
()
Ответ на: комментарий от stevejobs

Ну вот например, хочешь ты внести исправления в JDK9. Например, предложить сообещству выделить подпроект для работы с жесткими дисками (чисто от фонаря предположил -). Или, например, сделать рефакторинг - а давайте поубираем везде где не надо файналы, задолбали они. Подозреваю/уверен, что это потребует серьезной проработки и обоснования для сообщества влияния на все остальные подсистемы. Например, как скажется убирание файналов на перфомансе. Или как должно быть реорганизовано nio под новую архитектуры работы с дисками.

Звучит как бессмысленная трата времени.

Да и более того, если я и захочу чем-то подобным заниматься, причём на таком уровне, чтобы говорить ораклу, где они не правы, то уже тогда буду думать и курить их стандарты.

Deleted
()
Ответ на: комментарий от umren

Достает велик из толстой задницы.

anonymous
()
Ответ на: комментарий от vertexua

да, понимание структуры - чуть ли не самое важное. Разматываю структуру последовательно. Начал с lang. Было бы интересно узнать, как именно «climb the source tree», в каком порядке, на что обратить внимание. Например, первое на что натыкаешься - на древнейший (1.4) CharSequence. Начинаешь разматывать. И в этом куске древности внезапно обнаруживается новомодное (1.8) API для стримов, и оказывается что у чарсиквенса юзается интстрим, и его поведение можно даже продебажить с помощью класса Tripwire. По-моему, тут здорово помогла бы документация в стиле «дизайн и эволюция JDK», т.к. структура поддерживает не только своей сутью, но еще и историческими причинами

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от Deleted

когда-нибудь года через два я безусловно попробую устроиться в Oracle хачить JDK. Есть такое имхо, что каждый инфраструктурный разраб в конце концов приходит в разработку ядра своей технологии. Но это очень нескоро. Потому что я пока полный чайник :( Вот пришел просить совета у бородатых батенек на лоре!

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

ядра своей технологии

У меня пока ни одна работа не была совершенно никак связанной с предыдущими.

C/C++/GPGPU/OpenCL -> Java -> Scala/Bash/Python -> Python/C++

И при этом всем были фрилансы на HTML5/JS/CSS

Даже еще ни разу не совпала прикладная область. Если завтра я буду писать код длы подводных лодок на Vala, то меня это не удивит

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)

По крайней мере этому учат в институте, спрашивают на собеседованиях, об этом разговаривают на ЛОРе.

1. В хороших институтах этому не учат.

2. В приличных компаниях собеседования не проводят.

3. О серьезных вещах на ЛОРе не разговаривают.

Иначе ты просто неудачник.

[/thread]

anonymous
()
Ответ на: комментарий от stevejobs

Соглашусь лишь с вертексом, сказав, что это оверкилл. Больше добавить нечего.

Deleted
()

1. Читал и в целом знаю стандарт. Хотя в edge-case'ах приходится почитывать снова.

2. STL/Qt местами читал, при этом как работают знаю (до уровня «почему так, а не иначе» и «что под капотом»). Boost не читал, ибо трешъ, но способы реализации функционала знаю.

Pavval ★★★★★
()

Кто из лоровцев читал и _знает_ свои стандарты?

наизусть? я не знаю. а так вообще читал стандарты C и C++ (старые), + регулярно ознакамливаюсь с обновлениями в новых стандартах.

2) Кто из лоровцев чистал свои сдк, и знает как они работают?

чистал? читал сдк? смысл ускользает от меня. свои сдк — это какие? типа android sdk, win32 sdk, mac os x sdk, directx sdk и т.п.? что имеется ввиду под их чтением?

waker ★★★★★
()

Когда тебе кто-то говорит что каждый X должен обязательно Y — посылай его в известном направлении.

anonymous
()

Для старого паскаля и сишечки я знал стандартные модули и помнил большинство функций и констант. Да что там, я опкодов 86-го асма знал подавляющее большинство, только без этих новомодных 0x0F и 0x66-0x67 расширений. А то говно, на котором я сейчас преимущественно пишу, не заслуживает такого отношения. Куда эффективнее твердо помнить 10-20% вещей, которые ты юзаешь 80-90% времени, а остальные подглядывать в справочнике.

Между тем, я довольно часто встречаю людей, которые выносят мозг знанием детальных подробностей целых кусков SDK.

Выучи тоже пару кусков поинтереснее и шокируй людей при каждом удобном случае. Если задача в показухе, то этим ты решишь свою задачу.

amomymous ★★★
()

Между тем, я довольно часто встречаю людей, которые выносят мозг знанием детальных подробностей целых кусков SDK.

Я тебе могу рассказать много интимных подробностей JDK, но могу совершенно не знать других. Прост потому что приходится иногда отладчиком залезать в самую задницу явы чтобы понять отчего глюки.

Седня например подхватил фееричный дедлок в одном потоке, сделал быстрофикс, но разбираться в каком угаре делалось поведение ReadWriteLock мне лень.

Deleted
()
Ответ на: комментарий от anonymous

Когда тебе кто-то говорит что каждый X должен обязательно Y — посылай его в известном направлении.

Каждый водитель автобуса должен обязательно уметь управлять автобусом. Я не прав?

amomymous ★★★
()

Обычно считается, что разработчик должен знать стандарт своего языка, как минимум прочитать. Должен хотя бы поверхностно знать детали реализации тех средств, которыми он пользуется. По крайней мере этому учат в институте, спрашивают на собеседованиях, об этом разговаривают на ЛОРе.

Не считается это за обычно, не учат этому и не спрашивают на собеседовании. От обычного кодера требуют знание каких-то типичных практических юз кейсов и особенностей ЯП. Знание кусков стандарта это уже уровень выше среднего, копание в деталях реализации ~ хак моде.

mashina ★★★★★
()

Я вот стандарт С11 сейчас читаю

Harald ★★★★★
()
Ответ на: комментарий от vertexua

Просто сесть и безумно читать - нечего не запомнишь, структуру не поймешь.

зато можно узнать много нового :)

Harald ★★★★★
()

Про C++ даже не заикаюсь - его стандарт я даже не пытался запоминать

Кажется, всё немного наоборот, в яве с её JDK мусорного дерьма на порядки больше чем плюсах с STL.

mashina ★★★★★
()

Java, знаю, что они есть (стандарты), просматривал оглавление. JLS за 5 лет пару раз даже открывал по каким то теоретическим вопросам.

Legioner ★★★★★
()

Моя работа тесно связана с компиляторами. Хакаю gcc, clang и open64. Стандарты читаю непрерывно. Не помню при этом ни хрена, всегда лезу в стандарт за каждой мелочью.

anonymous
()

Редко в каком институте учат стандарту. Обычно стандарт - толстенный талмуд, написанный на малопонятном языке. Стандарт либо самостоятельно изучают либо только отрывками самое основное, т.к., к примеру, весь стандарт C++ не влезет в программу ВУЗа, даже если этот C++ будут 5 лет мурыжить по 5 пар в неделю. А вообще я смотрю в стандарты по необходимости и для новых фич. А на собеседованиях не стандарт спрашивают, а как задачу выполнять будешь и что ты раньше писал, в каких проектах участвовал. А вообще тот же стандарт плюсов очень большой и все детали не упомнишь. Не знаю, сам Страуструп его на память знает или нет ;). С практической точки зрения даже не очень глубокое знание того же буста может быть более полезно, чем знание о деталях реализации чего-то малозначимого и практически не применяемого в стандарте. Те же плюсы сверхпереполнены функционалом и возможностями сделать так или сяк одно и тоже, отчего и все его проблемы.

А знание приходит с опытом. Если что-то большое пришлось писать, где кусок стандарта потребовался или стандартных библиотек, то вот тот кусок ты и знаешь досконально. Ну и от гугла никуда не деться для поиска этих частей, которые потребуются.

peregrine ★★★★★
()

JLS начинал, но потом попрыгал по выборочным главам; JVMS выборочные главы, и только когда по работе пришлось.

ii8_ ★★★★
()
Ответ на: комментарий от anonymous

2. В приличных компаниях собеседования не проводят.

Проводят, но в другом формате. Скорее как знакомство. Спрашивают, где работал, что делал (фактически по резюме), задают уточнющие вопросы, но по деталям - ни-ни. Просто потом если выяснится, что ты не можешь делать того, что написал, пнут под зад и всё.

invy ★★★★★
()

Есть сертификация и уровни сертификации - лучше всего изучать стандарт языка по методичкам для экзаменов. Так можно узнать различные тонкости, не залезая в самые дебри.
А language specification это не учебник, а, скорее, настольная книга, к которой можно обратиться, если есть какие-то вопросы и непонятки.

GblGbl ★★★★★
()

Чувак, но это же нудно.

Ну вот я Джоссатиса в туалете читаю, по либке приплюснутой книгу, и оттуда её не выношу. Достаточно знать 20%, остальное по необходимости подглядывать.

Раньше читал всяких Меерсов с Александресками, последнее скорее вредно, чем полезно оказалось.

Вот каждые N лет выходит стандарт, OpenGL например, и красная книжка к нему, ты что будешь зубрить каждые 100500 функций, или наоборот заюзаешь handbook какой (чтоб понять какое подмножество тебе нужно)?

Мне часто проще написать man 3 <чего-то там>, чем зазубривать. Зубрил 1 раз справку из турбо С, чтоб экзамен в институте сдать, благополучно забыл и забанил методу такого зубрения.

nikitos ★★★
()

Аутисты любят зубрить книги целиком

nerdogeek
()

Пишу на С++ около 5 лет.

Стандарт «от корки до корки» не читал, но в целом знаю. Сейчас в процессе прочтения.

std читал на http://www.cplusplus.com/ от начала и до конца.

Qt. Читал и правил исходники.

anonymous
()

1) Кто из лоровцев читал и _знает_ свои стандарты? Соответственно, для Java это Java Language Specification и Java Virtual Machine Specificaiton for Java 8 SE Edition, и для С++ это ISO/IEC 14882:2011 C++ International Standard

Это ненужное знание для прикладного программиста, для него со стандарта сняты сливки в виде учебников. Стандарт имеет смысл смотреть точечно для выяснения каких-то вопросов, явно не описанных в учебниках. Полностью изучать стандарт необходимо только разработчикам компиляторов, анализаторов кода и т.д.

2) Кто из лоровцев чистал свои сдк, и знает как они работают? Вот так по чесноку, положа ногу на сердце. Соответственно, JDK stable (сейчас JDK8), JDK current (сейчас JDK9) для Java, и STL/Boost/Qt для C++

Все, чем часто пользуюсь, знаю как работает изнутри. API часто подглядываю в спеках, ибо забываю.

staseg ★★★★★
()
Ответ на: комментарий от anonymous

Топов собеседуют еще более жестко. Но мы ж тут про программистов говорим, а они все попадают в категорию мелкой обслуги.

anonymous
()

Ни у плюсиков, ни у жабки глубинно не копал. У плюсиков навряд ли докопаюсь, жабку может быть и курну (кое-что пописываю на ней).

Deleted
()
Ответ на: комментарий от Deleted

У крестопоклонников... Такое ощущение, что «уже поздно». Надо было участвовать во всем этом развитии крестов. А то сейчас поклоняться каждому из этапов развития, начиная с 20 лет назад и до сего дня - да это никакого времени не хватит. И наоборот, знакомый кресто-архитектор еще даже не начинал смотреть 11 стандарт.

С жабкой-то проще - если кто-то все еще желает от тебя деталей реализации 1.5, можно глумливо называть их криворукими нищебродами и предлагать переход на 1.8. Криворукие - потому что не писали тесты и оттого не знают что развалится при апгрейде (можно так глумиться почти над кем угодно, тесты никто не пишет), нищеброды - потому что не хватило денег на то, чтобы постоянно тестировать софт на соответствия обновлениям SDK :)

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

Да уж, дядька Страуструп намутил, конечно, изрядно.

Deleted
()

Пишу года 3 на похэпэ, стандартное и не очень помню плохо, всё время смотрю в справочники, в кишки вм не смотрел во избежание фатальных повреждений мозга.

anonymous
()
Ответ на: комментарий от stevejobs

Вот читаешь порой твои посты и думаешь - какой же у тебя засранный, неупорядоченный мозг... 0, гномьи боги!..
Соберись, тряпка, и перестань либеральничать по отношению к своим слабостям.

anonymous
()
Ответ на: комментарий от anonymous

Мы говорим про программистов. Левый мусор с улицы все равно не подойдет на что-то серьезнее мелкой обслуги, а проверенных людей смысла собеседовать нет.

anonymous
()
Ответ на: комментарий от anonymous

Утютюшечки, лошара, пойди и расскажи Гуглу, что не всех программистов надо собеседовать.

anonymous
()
Ответ на: комментарий от anonymous

Так Гугл их и не собеседует, а покупает вместе со стартапами.

А то что корпоративная бюрократия - полная хрень, и так все знают. Офисный планктон быстро адаптируется ее обходить.

anonymous
()
Ответ на: комментарий от anonymous

Тебя, очевидно, никогда со стартапом не покупали. Собеседуют и еще как, в процессе due diligence. Гоняют намного суровее чем на обычном собеседовании. И, да, без гномиков и крышек люков так же не обходится.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.