Мне нужно было с аудиокарты данные получать, делать преобразование Фурье, совершать какие-то манипуляции с составляющими, делать обратное преобразование и выдавать обратно на аудиокарту — и все это с минимальной задержкой
Эквалайзер?
В Фортране, если я правильно помню, есть быстрые библиотечные реализации дискретных FFT (Intel FC).
и сделал все на Дельфи
Так если на Дельфи написано, то все равно через Win интерфейс идет работа. Не напрямую же с аппаратурой.
а то и на готовые семисегментные сборки. Да только вот же незадача — это выглядит уже совсем не так… осовремененно и оттого попсово выглядит, я бы сказал.
Вы странные вещи говорите.
Если отложить в сторону «какой кому синтаксис нравится». Чем тот же Си лучше Фортрана при работе с периферией?
Я имею в виду — все равно все через библиотеки внешние идет. И нет никакой разницы — подключить библиотеку к Си или к Фортрану.
Нужно вам, например, с драйвером пообщаться в Win32. Вы вызываете DeviceIoControl из kernel32.dll. Какая разница, lib со stub'ами к Си прилинковать или к Фортрану?
«верифицировать исправление ошибки» (== доказать ее исправление),
«верифицировать» != «доказать» в данном контексте. Доказать могу я, разработчик. Мол, смотри, раньше делали так и так и получали AV, теперь — все чисто, а в коде это выглядит вот так и так. Таки мобразом, я доказал исправление ошибки. (да и слово «исправление» можетозначать незаврешенный процес — в таком случае я докажу, что я исправлял ошибку, т.е. доказал исправление, т.к. «исправление» имеет 2 смысла) А тестировщик может verify, т.е. подтвердить, что это действительно так, что процесс завершен.
«verify» имеет коннотацию «провести собственное исследование-тестирование и подтвердить, что ошибка исправлена», а «подтвердить исправление» — нет. По крайне мере, мое чувство языка мне так подсказывает.
А тут соглашусь. «Ошибка» — гораздо более узкое и конкретное понятие.
Мне, напротив, кажется, что «ошибка» — более широкое понятие. Например, опечатка в сообщении — ошибка, а отказ в обслуживании — результат bug'а. (он же — логическая ошибка, например).
Слово «Верификация» в русском языке есть уж минимум полсотни лет (а скорее всего и больше) и корни у него латинские, а не англоязычные.
Так lexx2real именно о «верифаить» сказал.
Язык свой надо лучше знать, тогда вместо калькирования всех незнакомых слов внезапно окажется, что у половины из них есть вполне благозвучные и подходящие аналоги.
У половины. Именно.
А «верифаить», на мой взгляд — это исключительно от безграмотности, а не от того, что много ИТ-терминов кальки, с чем я и не спорю…
Не обязательно от безграмотности. Тут вопрос привычки тоже играет большую роль. Как я указывал выше, основной язык в IT сфере — английский, множество статей, документации, обсуждения на форумах ведутся на английском. Поневоле какие-то слова «впечатываются». Кто-то, как я, например, работает к тому же в англоязычном коллективе, это еще сильнее усугубляет проблему.
Плюс, что еще важнее — у некоторых слов есть _коннотация_. И это очень, очень важно. Например, то же «верифаить», являясь по сути безграмотной калькой, тянет за собой незримый абзац смысла — о процессе тестирования, о том, как кооперируются разработчики и тестировщики и пр. А слово «подтвердить», являясь точным аналогом, тем не менее коннотации не имеет. Безграмотное «поверифаить исправление ошибки» не то же самое что и «подтвердить исправление ошибки», хотя перевод-то точный. Да даже «ошибка» и «баг» не одно и то же. (коннотация разная).
Это не проверить в данном контексте, это — подтвердить.
Конечно, всем все понятно, но блин. Ваш чекинг и верифаинг это что-то.
Был СССР, была своя русская терминология.
Отладка.
Забой (backspace кто не в курсе).
Математический адрес.
И так далее. Что-то нам осталось с тех пор — переменная, массив, отладка и т.д. А то, что появилось позже, особенно связанное с процессом разработки ПО — калька. Ныне основным языком является английский, терминология английская. Это печально, но вот так есть.
Здравый смысл у каждого свой — и это прекрасно. Именно из того, что люди неодинаковы и получаются команды, а не набор взаимозаменяемых элементов.
Здесь обычная ошибка — вы путаете интеллектуальный творческий процесс и рутину. Какими бы интеллектуальными и самостоятельными мы ни были, мы все равно все моем руки перед едой и вытираем ноги перед входом. Обязательно. И отмазка «я не буду вытирать ноги, потому что я личность» не к месту. Команда получается из разносторонних людей, т.к. они могут работать с разными проблемами, по-разному смотреть на них. А не потому, что часть команды — обязательные люди, а часть — как бог на душу положит.
Тут все просто — либо есть правила, и они соблюдаются, либо мы наслаждаемся тем, как тестеры и разрабы играют тасками в пинг-понг. Ну, кому что нравится.
Инструкции могут работать, пока их немного, пока они просты, как инструкция по заполнению багрепорта, которая по сути своей — чеклист, позволяющий не забыть, какие данные надо указать
Я говорил именно об этой инструкции.
Слово «всегда» вообще выглядит неуместным, когда речь идет о сколько-то интеллектуальной человеческой деятельности… и далее по тексту
См. выше тезис номер 1 про «я — личность». Заполнение тасков — интеллектуальная, но не творческая деятельность.
Кстати, точное следование инструкциям, даже в высшей степени разумным, называется «итальянская забастовка».
Не совсем так. Итальянская забастовка — это когда делается только то, что есть в инструкции, и на грамм больше. Обязанность следовать инструкции, описывающий минимум, не итальянская забастовка.
Извините, как случайно-то? Я правильно понял (сам не в теме, извините; просто заинтересовало), что нам нужно вычислить хеш, на выходе которого мы и получаем, условно, нужную строку? И вдруг, совершенно случайно, на очередном раунде, имеем на выходе нужную красивую строчку?
Эквалайзер?
В Фортране, если я правильно помню, есть быстрые библиотечные реализации дискретных FFT (Intel FC).
Так если на Дельфи написано, то все равно через Win интерфейс идет работа. Не напрямую же с аппаратурой.
Можно заменить другим.
100 лет назад, когда писал на фортране, связка ассемблер+фортран+линкер вполне работала.
Речь же не о написании драйверов.
Какой именно части? Что вам кажется неудобным?
Естественно. Win — не rtos.
Отнюдь.
Я имею в виду не средства, встроенные в язык, а способ записи;
Верно.
Если отложить в сторону «какой кому синтаксис нравится». Чем тот же Си лучше Фортрана при работе с периферией?
Я имею в виду — все равно все через библиотеки внешние идет. И нет никакой разницы — подключить библиотеку к Си или к Фортрану.
Нужно вам, например, с драйвером пообщаться в Win32. Вы вызываете DeviceIoControl из kernel32.dll. Какая разница, lib со stub'ами к Си прилинковать или к Фортрану?
Вполне сродни приведению через нетипизированный указатель в других языках.
Это понятно. Всему свое место.
Надо. Это по-своему хорошее средство, если не злоупотреблять.
Например?
«верифицировать» != «доказать» в данном контексте. Доказать могу я, разработчик. Мол, смотри, раньше делали так и так и получали AV, теперь — все чисто, а в коде это выглядит вот так и так. Таки мобразом, я доказал исправление ошибки. (да и слово «исправление» можетозначать незаврешенный процес — в таком случае я докажу, что я исправлял ошибку, т.е. доказал исправление, т.к. «исправление» имеет 2 смысла) А тестировщик может verify, т.е. подтвердить, что это действительно так, что процесс завершен.
«verify» имеет коннотацию «провести собственное исследование-тестирование и подтвердить, что ошибка исправлена», а «подтвердить исправление» — нет. По крайне мере, мое чувство языка мне так подсказывает.
Мне, напротив, кажется, что «ошибка» — более широкое понятие. Например, опечатка в сообщении — ошибка, а отказ в обслуживании — результат bug'а. (он же — логическая ошибка, например).
Так lexx2real именно о «верифаить» сказал.
У половины. Именно.
Не обязательно от безграмотности. Тут вопрос привычки тоже играет большую роль. Как я указывал выше, основной язык в IT сфере — английский, множество статей, документации, обсуждения на форумах ведутся на английском. Поневоле какие-то слова «впечатываются». Кто-то, как я, например, работает к тому же в англоязычном коллективе, это еще сильнее усугубляет проблему.
Плюс, что еще важнее — у некоторых слов есть _коннотация_. И это очень, очень важно. Например, то же «верифаить», являясь по сути безграмотной калькой, тянет за собой незримый абзац смысла — о процессе тестирования, о том, как кооперируются разработчики и тестировщики и пр. А слово «подтвердить», являясь точным аналогом, тем не менее коннотации не имеет. Безграмотное «поверифаить исправление ошибки» не то же самое что и «подтвердить исправление ошибки», хотя перевод-то точный. Да даже «ошибка» и «баг» не одно и то же. (коннотация разная).
http://habrahabr.ru/post/241955/#comment_8100713
Был СССР, была своя русская терминология.
Отладка.
Забой (backspace кто не в курсе).
Математический адрес.
И так далее. Что-то нам осталось с тех пор — переменная, массив, отладка и т.д. А то, что появилось позже, особенно связанное с процессом разработки ПО — калька. Ныне основным языком является английский, терминология английская. Это печально, но вот так есть.
Здесь обычная ошибка — вы путаете интеллектуальный творческий процесс и рутину. Какими бы интеллектуальными и самостоятельными мы ни были, мы все равно все моем руки перед едой и вытираем ноги перед входом. Обязательно. И отмазка «я не буду вытирать ноги, потому что я личность» не к месту. Команда получается из разносторонних людей, т.к. они могут работать с разными проблемами, по-разному смотреть на них. А не потому, что часть команды — обязательные люди, а часть — как бог на душу положит.
Тут все просто — либо есть правила, и они соблюдаются, либо мы наслаждаемся тем, как тестеры и разрабы играют тасками в пинг-понг. Ну, кому что нравится.
Я говорил именно об этой инструкции.
См. выше тезис номер 1 про «я — личность». Заполнение тасков — интеллектуальная, но не творческая деятельность.
Не совсем так. Итальянская забастовка — это когда делается только то, что есть в инструкции, и на грамм больше. Обязанность следовать инструкции, описывающий минимум, не итальянская забастовка.