Зачем появляются новые языки программирования? Сколько их и каких на самом деле нужно?

[Sergunka]

Зачем Algol 68 придумали? Могли бы и дальше на Algol 60 писать...

В наше время была присказка - Фортран + ассемблер перешагнул бессмертие. Где этот сейчас Фортран и ассемблер?

[Sergunka]

Написать новый язык не такая уж большая проблема. Главное наверное библиотеки и поддержка абстракций вроде типов, классов(с++) или встроенной много процессорности. А вобощем конечно все равно все в ассемблер конвертирует. Как и у людей, языки разные, мысли теже.

В приличных ВУЗ-ах написать компилятор/интерпретатор к языку это курсовая или дипломная работа. Я к слову сказать соавтор двух языков программирования. У меня дипломник писал лексический анализатор к языку.

[SVK]

В наше время была присказка - Фортран + ассемблер перешагнул бессмертие. Где этот сейчас Фортран и ассемблер?

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

[Flash-04]

На ассемблере? Да ладно.

[SVK]

На ассемблере? Да ладно.

Сам этим занимался, и видел их количество. Наблюдаю за попытками переделки их на «новые технологии» - года с 2005 идет довольно активно. Результатов пока - на уровне статистической погрешности.
Кроме тонн кода на Ассемблере также дружно пашут десятки тонн кода на Коболе; тоже - не поддается новым технологиям

[OtherSide]

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

Логично. Народ называет технологию, а zVlad с умным видом: О! Это я знаю
Интересная игра
...

Начинайте. Я готов.

SignalR с Angular знаете как сдружить?

[zVlad]

Я написал выше: "Я этим не занимался глубоко...".

Судя по вашим россыпям перлов по топикам там и тут, вы ничем не занимались глубоко. Ну кроме, может быть, изучения рекламных проспектов от IBM.
Я знаком с такой породой "специалистов" и всегда старался избавляться от них при первой же возможности.
Фрагменты вашей трудовой боиграфии, которые вы же сами обнародовали на форуме, намекают, что я в этом мнении не одинок.

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

[zVlad]

Условия задачи сформулированными не совсем строго на предмет чем можно пользоваться и на каком диалекте SQL.

Задача простая - создать N записей из ниоткуда. Написать можно десятков разных способов. Кандидат, заявляющий что он знаток SQL, ни бе ни мэ ни кукареку.

Для интервью я пользуюсь "напишете запрос выдающий 12 записей с двумя колонками - начало и конец каждого месяца прошлого года".

Вaм обоим и третьему скажу так.
Я в 1994 году, когда многие из здешних болтунишек еще с восхищение смотрели передaчу АБВГД-ейка, обучал подчиненных мне программистов реляционным базам данных и SQL-ю. Я их "ругал" и "бил указкой по рукам" за "набивания таблиц..." и создавание "N записей из ниоткуда".
Вы все трое (третий знает о ком я) не понимаете сути РЕЛЯЦИОННЫХ БАЗ ДАННЫХ". Вы изучали их в "post SQL" времана по кривым руководствам.
Всем троим задание. Найти книгу Кристофера Дэйта "Руководство к DB2" ("A Guide to DB2" если хотите) и читать по 20 страниц перед сном. По прочтении доложить. Исполняйте.

[Flash-04]

Ы? А что, другие книги не канают, нет?

[zVlad]

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

Тут сразу же напрашивается классический вопрос для интервью - как удалить дубликаты одним sql стейтментом


Sent from my iPhone using Tapatalk Pro

Дети мои. Слушайте и внимайте.

Проблему дубликатов надо заканчивать в момент создания таблицы. Есть такая загогулина во всех RDBMS, называется "unique index". Правильно создавайте их вместе с созданием таблиц и вам не придется ломать голову над "... как тут появляются дубликаты и как их убрать", и ".. как удалить дубликаты одним sql стейтментом". Я бы ушел (убежал) с интервью сo словами мол извините, я не туда попал, если бы мне такой вопрос задали бы на интервью. Слава богу мне это не грозит - я в программисты идти не собираюсь.

[zVlad]

Ы? А что, другие книги не канают, нет?

Эта книга классика. По ней учились не только и не столько те кто работал с DB2 (у IBM документация достаточно хороша), но больше те кто работал с Oracle. Еще в 90-е годы.
Я не знаю книг лучше, no xуже встречались. Да и из высказываний здешних, которые явно не по "A Guide to DB2" знают SQL видно чтO они читали.

[iDesperado]

Вaм обоим и третьему скажу так.
Я в 1994 году, когда многие из здешних болтунишек еще с восхищение смотрели передaчу АБВГД-ейка, обучал подчиненных мне программистов реляционным базам данных и SQL-ю. Я их "ругал" и "бил указкой по рукам" за "набивания таблиц..." и создавание "N записей из ниоткуда".

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

[KinDzaDza]

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

Тут сразу же напрашивается классический вопрос для интервью - как удалить дубликаты одним sql стейтментом


Sent from my iPhone using Tapatalk Pro

Дети мои. Слушайте и внимайте.

Проблему дубликатов надо заканчивать в момент создания таблицы. Есть такая загогулина во всех RDBMS, называется "unique index". Правильно создавайте их вместе с созданием таблиц и вам не придется ломать голову над "... как тут появляются дубликаты и как их убрать", и ".. как удалить дубликаты одним sql стейтментом". Я бы ушел (убежал) с интервью сo словами мол извините, я не туда попал, если бы мне такой вопрос задали бы на интервью. Слава богу мне это не грозит - я в программисты идти не собираюсь.

Ну в принципе ожидаемо, zVlad как всегда сначала вообще ни хрена не понял в чем заключается поставленная задача, потом даже не смотря на разжеванное решение и произнесённые ключевые слова все равно так и не догадался о чем идёт речь. Ну и в финале обгадил все участников, и гордо обьявил себя победителем. Все как в истории про игру в шахматы с голубем.

[zVlad]

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

Тут сразу же напрашивается классический вопрос для интервью - как удалить дубликаты одним sql стейтментом


Sent from my iPhone using Tapatalk Pro

Дети мои. Слушайте и внимайте.

Проблему дубликатов надо заканчивать в момент создания таблицы. Есть такая загогулина во всех RDBMS, называется "unique index". Правильно создавайте их вместе с созданием таблиц и вам не придется ломать голову над "... как тут появляются дубликаты и как их убрать", и ".. как удалить дубликаты одним sql стейтментом". Я бы ушел (убежал) с интервью сo словами мол извините, я не туда попал, если бы мне такой вопрос задали бы на интервью. Слава богу мне это не грозит - я в программисты идти не собираюсь.

Ну в принципе ожидаемо, zVlad как всегда сначала вообще ни хрена не понял в чем заключается поставленная задача, потом даже не смотря на разжеванное решение и произнесённые ключевые слова все равно так и не догадался о чем идёт речь. Ну и в финале обгадил все участников, и гордо обьявил себя победителем. Все как в истории про игру в шахматы с голубем.

Не Вы "ставили задачу", и не Вам подводить итоги.

И еще раз, для самых непонятливых, здесь не обсуждаются персоналитис и не дается оценка им (я не знаю так уж правила, но не удивлюсь что ими это не приветствуется), здесь обсуждаются мысли, высказывания, дела (по их описаниям). Вы выпадаете из этого простого регламента. Как выпадает, например, грыжа.

[zVlad]

Еще раз, для непонятливых.
Я не просил задавать мне задачи по ИТ (хоть я и не против этого, но в другом контексте.
Все началось вот с этого:

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

Логично. Народ называет технологию, а zVlad с умным видом: О! Это я знаю
Интересная игра
...

Тут нет ни слова о задачах на SQL.
То что я откликаюсь говорит лишь о том что я открыт ко многому, кроме драки.
Но некоторые здесь почему то не понимают таких простых вещей как этика дискуссии на форуме.
Я не про грубость, на которую и меня удается спровоцировать, я более глубоких принципов - корректность, логичность и неприкосновенность личности, в смысле делание оценок и навешивания ярлыков, чем часто занимаются в детских садиках и начальных классах школы к окончанию которой большинсво, но увы не все, начинают понимать о неконструктивности такого поведения.

[Flash-04]

Ы? А что, другие книги не канают, нет?

Эта книга классика. По ней учились не только и не столько те кто работал с DB2 (у IBM документация достаточно хороша), но больше те кто работал с Oracle. Еще в 90-е годы.
Я не знаю книг лучше, no xуже встречались. Да и из высказываний здешних, которые явно не по "A Guide to DB2" знают SQL видно чтO они читали.

я не читал эту конкретную, но прежде чем работать с БД пару книжек с теорией по БД таки читал. Давно это было

[zVlad]

Ы? А что, другие книги не канают, нет?

Эта книга классика. По ней учились не только и не столько те кто работал с DB2 (у IBM документация достаточно хороша), но больше те кто работал с Oracle. Еще в 90-е годы.
Я не знаю книг лучше, no xуже встречались. Да и из высказываний здешних, которые явно не по "A Guide to DB2" знают SQL видно чтO они читали.

я не читал эту конкретную, но прежде чем работать с БД пару книжек с теорией по БД таки читал. Давно это было

Интересно когда, какие?

[Flash-04]

уже не помню, увы. Одна была по теории БД вообще. Там рассматривались разные БД, в том числе иерархические, вторая была по dBase IV.

[zVlad]

уже не помню, увы. Одна была по теории БД вообще. Там рассматривались разные БД, в том числе иерархические, вторая была по dBase IV.

А что Вы хотели достичь читая те книжки?
dBase IV - псевдореляционная база.

[KinDzaDza]

Не Вы "ставили задачу", и не Вам подводить итоги.

И еще раз, для самых непонятливых, здесь не обсуждаются персоналитис и не дается оценка им (я не знаю так уж правила, но не удивлюсь что ими это не приветствуется), здесь обсуждаются мысли, высказывания, дела (по их описаниям). Вы выпадаете из этого простого регламента. Как выпадает, например, грыжа.

Я ещё раз могу Вам напомнить, что Вы закусили удила после того, как Вам сказали что Вы не знаете многого что есть в современном ИТ, просто потому что никогда с этим не встречались, работая последние 20+ лет в одной компании на МФ. Я не совсем понимаю, почему констатация такого простого факта Вас так сильно задела?

Вопрос по SQL был интересен тем, что заставляет задуматься а как можно использовать реляционную модель данных для получения такого результата. Кто хоть как-нибудь использовал SQL может сразу вспомнить, что когда делаешь SELECT из более чем одной таблицы и ошибаешься с условиями связи в JOIN / WHERE то часто получаешь несколько дубликатов на каждую ожидаемую единственную запись в результирующей выборке. Вот тут-то и приходит озарение, что надо просто выбрать данные из этой таблицы и любой другой с ровно N записями без всяких условий связи. Ну и остаётся только придумать откуда можно взять N записей для другой таблицы в этом JOIN.

Причём тут уникальные индексы, детские сады и прочие экскурсы в историю написания книжек именно для DB2 остаётся непонятным.
Как можно работать ДБА и не использовать SQL практически каждый день - для меня загадка. Возможно это норма для мира МФ, но что-то я сильно сомневаюсь. У меня нет опыта работы ДБА на МФ, но есть опыт ДБА с Ораклом со всякими сертификатами и прочей лабудой. Кроме того из известных БД я много работал с MSSQL но уже не как ДБА, a с MySQL переодически работаю до сих пор. Про менее известные БД с которыми мне тоже довелось поработать Вы, скорее всего, просто никогда не слышали. При этом я даже и не пытаюсь учить Вас или кого-либо еще как и что делать на МФ или в DB2. Почувствуйте разницу.

[Flash-04]

уже не помню, увы. Одна была по теории БД вообще. Там рассматривались разные БД, в том числе иерархические, вторая была по dBase IV.

А что Вы хотели достичь читая те книжки?
dBase IV - псевдореляционная база.

Как чего? Чтобы, понять принцип работы. Кстати сильно помогло. Как резултат переделал с нуля БД которая была в конторе где я тогда работал и операции с ней стали намного быстрее.

[zVlad]

Не Вы "ставили задачу", и не Вам подводить итоги.

И еще раз, для самых непонятливых, здесь не обсуждаются персоналитис и не дается оценка им (я не знаю так уж правила, но не удивлюсь что ими это не приветствуется), здесь обсуждаются мысли, высказывания, дела (по их описаниям). Вы выпадаете из этого простого регламента. Как выпадает, например, грыжа.

Я ещё раз могу Вам напомнить, что Вы закусили удила после того, как Вам сказали что Вы не знаете многого что есть в современном ИТ, просто потому что никогда с этим не встречались, работая последние 20+ лет в одной компании на МФ. Я не совсем понимаю, почему констатация такого простого факта Вас так сильно задела?

Вопрос по SQL был интересен тем, что заставляет задуматься а как можно использовать реляционную модель данных для получения такого результата. Кто хоть как-нибудь использовал SQL может сразу вспомнить, что когда делаешь SELECT из более чем одной таблицы и ошибаешься с условиями связи в JOIN / WHERE то часто получаешь несколько дубликатов на каждую ожидаемую единственную запись в результирующей выборке. Вот тут-то и приходит озарение, что надо просто выбрать данные из этой таблицы и любой другой с ровно N записями без всяких условий связи. Ну и остаётся только придумать откуда можно взять N записей для другой таблицы в этом JOIN.

Причём тут уникальные индексы, детские сады и прочие экскурсы в историю написания книжек именно для DB2 остаётся непонятным.
Как можно работать ДБА и не использовать SQL практически каждый день - для меня загадка. Возможно это норма для мира МФ, но что-то я сильно сомневаюсь. У меня нет опыта работы ДБА на МФ, но есть опыт ДБА с Ораклом со всякими сертификатами и прочей лабудой. Кроме того из известных БД я много работал с MSSQL но уже не как ДБА, a с MySQL переодически работаю до сих пор. Про менее известные БД с которыми мне тоже довелось поработать Вы, скорее всего, просто никогда не слышали. При этом я даже и не пытаюсь учить Вас или кого-либо еще как и что делать на МФ или в DB2. Почувствуйте разницу.

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

Ну во-первых, я много раз писал о том что даже за последние 20 лет я занимался не только МФ (хоты и этого было бы вполне достачно), но и многим другим. Поэтому и утверждаю что мне известны многие технологии ИТ, кроме каких-нибудь экзотически. Да и на самом МФ многие технологие есть, есть с чем работать что бы не скучать. Так что факт, который Вы констатируете, просто не имеет места быть.
Во-вторых, запросы надо писать без "ошибок с условиями связи в JOIN / WHERE", их надо отлаживать,
В-третьих есть волшебное слово DISTINCT.
В-четвертых, так случилось что я работаю на стыке DB2, Oracle and MS SQL. Репликация и не только. У меня сложились хорошие деловые связи с нашим ДБА (из Москвы) на Оракл, и МС. Я часто ему подсказываю и он часто говорит мне спасибо за подсказки. Он рассказывает мне о своих проблемах в Оракл, и МС и я ему помогаю с ними разбираться. РАссказываю ему прп ДБ2 и он соглашается с тем что многое в ДБ2 сделано лучше чем в Оракл и МС. Но это, как говорится, в пользу бедных. Есть еще один ДБА (англоговорящий) ему что не скажешь - как об стенку горох. Любимая фраза у него "I did manually...".
Да, есть много разных баз данных. Вы слыхали что-нибудь про Adabas? Дисод? IDMS? IMS? SQL/DS? DB2/2? Просто любопытно, ничего другого. Но реляционных баз данных для серьезных применений есть три, Они перечисленны выше. Я считаю себя специалистом только по реляционным. Другие мне не интересны, тем более что БД для меня не являются основой моей ролью на МФ с 2006 года. Правда с 2016 когда ушал на пенсию наша ДБ2 ДБА, ДБ2 вернулось обратно ко мне, с довеском - IDMS, которого я никогда не изучал. Тем менее считается что и это саппортаю, что и в самом деле удается как то.

По теме SQL я готов о многом говорить и помогать разбираться в сколь угодно сложных ситуациях. Но конкретно, а не тонкими намеками на толстые обстоятельства. С кодом в руках. И я не "как-нибудь использовал SQL", а постоянно имею с ним деле с 1993-го года. Включае формальный перерыв с 2006 по 2016 когда использовал ДБ2 и SQL в работе с совершенно другими областями ИТ на МФ.

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

[sp123]

Насчет дубликатов. Вообще-то там был смайлик. Хотя да, это один из расхожих вопросов на интервью. Из серии того, как джавистов заставляют инвертировать бинарные деревья, хотя в реальной жизни это никому не надо.

Что до уникальных ключей и правильных дизайнов… Всё это хорошо, но возможно далеко не всегда. Примеров много. В распределенных базах есть индексы, но они локальные, а таблица раскидана на множество баз по хэш коду. Или вот пример - внутри одной базы таблица partitioned с условием ежедневного drop старой partition; в этом случае глобальный индекс строить нежелательно. Также есть базы или просто распределенные файловые хранилища, где индексов вообще нет в принципе, а SQL есть. Да и в традиционной небольшой RDBMS на одном сервере может возникать проблема чистки мусора, почему нет? Мало ли, ну ошибся кто-то вначале, надо исправить, передизайнить и привести в порядок. Или, к примеру, какая-нибудь staging таблица, куда валятся сырые данные из какой-нибудь кафки - там дубликаты по дизайну в порядке вещей по специфическим причинам. И что, сразу вставать и уходить?


Sent from my iPhone using Tapatalk Pro

[zVlad]

Насчет дубликатов. Вообще-то там был смайлик. Хотя да, это один из расхожих вопросов на интервью. Из серии того, как джавистов заставляют инвертировать бинарные деревья, хотя в реальной жизни это никому не надо.

Что до уникальных ключей и правильных дизайнов… Всё это хорошо, но возможно далеко не всегда. Примеров много. В распределенных базах есть индексы, но они локальные, а таблица раскидана на множество баз по хэш коду. Или вот пример - внутри одной базы таблица partitioned с условием ежедневного drop старой partition; в этом случае глобальный индекс строить нежелательно. Также есть базы или просто распределенные файловые хранилища, где индексов вообще нет в принципе, а SQL есть. Да и в традиционной небольшой RDBMS на одном сервере может возникать проблема чистки мусора, почему нет? Мало ли, ну ошибся кто-то вначале, надо исправить, передизайнить и привести в порядок. Или, к примеру, какая-нибудь staging таблица, куда валятся сырые данные из какой-нибудь кафки - там дубликаты по дизайну в порядке вещей по специфическим причинам. И что, сразу вставать и уходить?


Sent from my iPhone using Tapatalk Pro

Хорошо. Ну и какие проблемы чтобы почистить даннысе, убрать дубликаты. Это можно делать как на SQL так и другими способами.
В SQL для этого используется GROUP BY .... HAVING COUNT(*) > 1

[zVlad]

уже не помню, увы. Одна была по теории БД вообще. Там рассматривались разные БД, в том числе иерархические, вторая была по dBase IV.

А что Вы хотели достичь читая те книжки?
dBase IV - псевдореляционная база.

Как чего? Чтобы, понять принцип работы. Кстати сильно помогло. Как резултат переделал с нуля БД которая была в конторе где я тогда работал и операции с ней стали намного быстрее.

Интересно. А можно поподробнее. Правда интересно, хоть в общих чертах.