프로그래밍 언어에서 가장 큰 디자인 결함은 무엇입니까? [닫은]

모든 프로그래밍 언어는 다른 언어와 마찬가지로 단일 언어만으로는 완벽하지 않기 때문에 설계상의 결함이 있습니다. 프로그래밍 언어에서 어떤 디자인 결함이 프로그래머로서의 역사를 통해 가장 귀찮게 했습니까?

특정 언어를 위해 설계된 것이 아니기 때문에 언어가 "나쁜"경우에는 디자인 결함이 아니라 디자인 의 특징 이므로 언어의 성가심을 나열하지 마십시오. 언어가 설계된 언어에 적합하지 않은 경우, 이는 디자인의 결함입니다. 구현 관련 사항과 중요 사항도 포함되지 않습니다.

나의 큰 성가심 중 하나는 switchC 파생 언어의 사례가 사용을 잊어 버린 경우 다음 사례로 넘어가는 방식 break입니다. 나는 이것이 매우 낮은 수준의 코드 (예 : Duff 's Device ) 에서 유용 하지만 일반적으로 응용 프로그램 수준 코드에는 부적절하며 일반적인 코딩 오류 소스라는 것을 이해합니다.

나는 1995 년에 처음으로 Java의 세부 사항에 대해 읽었을 때, switch성명서 에 대한 부분에 도달했을 때 그들이 기본 추락 행동을 유지했다는 것에 매우 실망했다. 이것은 다른 이름 switch으로 영화 롭게 goto됩니다.

나는 C 파생 언어에서 =할당과 ==평등 테스트에 사용하는 것을 정말 좋아하지 않았습니다 . 혼란과 오류의 가능성이 너무 높습니다. 그리고 ===Javascript로 시작하지 마십시오 .

:=할당과 =평등 테스트에 더 좋을 것 입니다. 의미는 오늘날과 정확히 동일 할 수 있습니다. 여기서 할당은 값을 생성하는 표현식입니다.

추가 와 문자열 연결을+ 위해 Javascript에서 선택 하는 것은 끔찍한 실수였습니다. 값은 형식이 지정되지 않으므로 각 피연산자의 정확한 내용에 따라 추가 또는 연결 여부를 결정하는 비잔틴 규칙이 발생합니다 .+

처음 $에는 문자열 연결 과 같은 완전히 새로운 연산자를 도입하는 것이 쉬웠을 것 입니다.

JSLint 등을 사용하지 않으면 Javascript가 기본적으로 전역 문제이며, 버그의 원인이되는 경우가 많습니다.

C와 C ++의 전처리 기는 방대한 kludge이며, 체처럼 누출되는 추상화를 생성하고, 쥐의 #ifdef문장을 통해 스파게티 코드를 장려하며 , ALL_CAPS그 한계를 극복하기 위해 끔찍한 읽을 수없는 이름이 필요합니다 . 이러한 문제의 근본 원인은 구문 또는 의미 수준이 아닌 텍스트 수준에서 작동한다는 것입니다. 다양한 사용 사례를 위해 실제 언어 기능으로 대체되어야합니다. 다음은 C ++, C99 또는 비공식이지만 사실상 표준 확장 으로 해결되는 몇 가지 예입니다 .

• #include 실제 모듈 시스템으로 교체해야합니다.

• 인라인 함수 및 템플릿 / 일반은 대부분의 함수 호출 사용 사례를 대체 할 수 있습니다.

• 이러한 상수를 선언하는 데 일종의 매니페스트 / 컴파일 타임 상수 기능을 사용할 수 있습니다. D의 enum 확장은 여기서 잘 작동합니다.

• 실제 구문 트리 수준 매크로는 많은 기타 사용 사례를 해결할 수 있습니다.

• 코드 믹스 유스 케이스에 문자열 믹스 인 을 사용할 수 있습니다.

• static if또는 version명령문을 조건부 컴파일에 사용할 수 있습니다.

수백 개의 언어로 수백 개의 실수를 나열 할 수 있지만 IMO는 언어 설계 관점에서 유용한 연습이 아닙니다.

왜?

한 언어에서 실수가 된 것이 다른 언어에서는 실수가 아니기 때문입니다. 예를 들어 :

• C를 관리되는 (즉, 가비지 수집 된) 언어로 만들거나 기본 유형을 묶는 것은 반 휴대형 저수준 언어로서의 유용성을 제한합니다.
• C 스타일 메모리 관리를 Java에 추가하면 (예 : 성능 문제를 해결하기 위해) 깨뜨릴 수 있습니다.

이 있는 역사적 맥락이 배워야 할 교훈은,하지만 수업은 거의 명확한, 그리고 그들을 이해하는 당신은 기술적 인 장단점을 이해해야 ...합니다. 예를 들어 번거로운 Java 제네릭 구현은 이전 버전과의 호환성을 유지하기 위해 비즈니스 요구 사항 을 재정 의 한 결과입니다 .

IMO, 새로운 언어 디자인에 대해 진지하게 생각한다면 실제로 는 광범위한 기존 언어를 사용 하고 (역사를 연구) 실수가 무엇인지 스스로 생각해야합니다. 또한 이러한 각 언어는 특정 요구 사항을 충족시키기 위해 특정 역사적 맥락에서 설계되었다는 점을 명심해야합니다.

배워야 할 일반적인 교훈이 있다면 "메타"수준입니다.

• 모든 목적에 이상적인 프로그래밍 언어를 설계 할 수는 없습니다.
• 실수를 피할 수는 없습니다. 특히 뒤에서 볼 때 특히 그렇습니다.
• 귀하의 언어 사용자를 위해 많은 실수를 고치기가 어렵습니다.
• 대상 고객의 배경과 기술을 고려해야합니다. 즉, 기존 프로그래머.
• 모두를 기쁘게 할 수는 없습니다.

C and C ++ : 아무것도 의미 하지 않는 모든 정수 유형 .

특히 char. 텍스트입니까 아니면 작은 정수입니까? 텍스트 인 경우 "ANSI"문자입니까, 아니면 UTF-8 코드 단위입니까? 정수인 경우 부호가 있거나 부호가 없습니까?

int "네이티브"크기의 정수로 의도되었지만 64 비트 시스템에서는 그렇지 않습니다.

long보다 크거나 같지 않을 수 있습니다 int. 포인터의 크기 일 수도 있고 아닐 수도 있습니다. 컴파일러 작성자가 32 비트인지 64 비트인지에 대해 거의 임의의 결정입니다.

1970 년대의 언어. 유니 코드 이전. 64 비트 컴퓨터 이전.

null.

발명가 토니 호 아레 (Tony Hoare)는 이를 "십억 달러의 실수"라고 부릅니다 .

ALGOL은 60 년대에 소개되었으며 오늘날 가장 일반적으로 사용되는 프로그래밍 언어로 존재합니다.

OCaml 및 Haskell과 같은 언어에서 사용되는 더 나은 대안은 아마도 입니다. 일반적으로 객체 참조는 명시 적 표시가없는 한 null / empty / 존재하지 않을 수 없습니다.

(토니는 겸허 한 태도를 보였지만 거의 모든 사람이 같은 실수를 저지른 것 같습니다.

PHP를 디자인 한 사람들은 일반 키보드를 사용하지 않았고 콜막 키보드를 사용하지 않는다는 느낌이 들었습니다.

저는 PHP 개발자입니다. PHP는 입력하기가 재미 있지 않습니다.

Who::in::their::right::mind::would::do::this()? ::연산자 들고 이동하고 두 개의 키 누름을 필요로한다. 에너지 낭비 야

비록->이->-> 아무-> 더 낫다. 또한 두 심볼 사이에 시프트가있는 세 번의 키 누름이 필요합니다.

$last = $we.$have.$the.$dumb.'$'.$character. 달러 기호는 엄청나게 사용되며 키보드 상단까지의 어워드 스트레치와 Shift 키 누름이 필요합니다.

입력 속도가 훨씬 빠른 키를 사용하도록 PHP를 설계 할 수없는 이유는 무엇입니까? 왜 we.do.this()vars가 단일 키 누르기 만 필요하거나 전혀 아님 (JavaScript) 키로 시작 하지 못하고 모든 var를 미리 정의해야합니까 (어쨌든 E_STRICT를 위해 해야하는 것처럼)!

나는 타이피스트가 느리지 않습니다. 그러나 이것은 단지 절름발이 디자인 선택입니다.

asp.net 내 데스크탑 기반 양식 사용 .

그것은 항상 퍼지를 느꼈고 웹이 실제로 작동하는 방식이나 방식에 들어갔습니다. 고맙게도 asp.net-mvc는 같은 방식으로 고통받지 않지만 Ruby 등의 영감을 얻었습니다.

나에게 그것은 표준 라이브러리에서 PHP 의 이름 지정 및 인수 순서 규칙이 절대적으로 부족합니다.

하지만 JASS 참조 된 개체 후 무효 참조의 필요성이 제거 / 출시 된 (또는 참조가 누출 것이다 메모리의 여러 바이트가 손실됩니다) 더 심각한이지만, JASS 단일 목적의 언어이기 때문에, 그 중요하지 않습니다.

내가 직면 한 가장 큰 디자인 결함은 파이썬이 파이썬 3.x와 같이 처음부터 설계되지 않았다는 것입니다.

C에서 배열 붕괴 및 결과적으로 C ++.

Java의 기본 유형.

그것들은 모든 것이 자손이라는 원칙을 깨뜨 렸는데 java.lang.Object, 이는 이론적 관점에서 언어 사양의 추가 복잡성을 초래하고 실제적인 관점에서 컬렉션의 사용을 매우 지루하게 만듭니다.

오토 박싱 (Autoboxing)은 실제 단점을 완화하는 데 도움이되었지만 사양을 더욱 복잡하게 만들고 큰 뚱뚱한 바나나 스킨을 도입하는 비용으로 이제 간단한 산술 연산에서 null 포인터 예외를 얻을 수 있습니다.

나는 Perl을 가장 잘 알고 있으므로 그것을 고를 것이다.

펄은 많은 아이디어를 시도했다. 일부는 좋았습니다. 일부는 나빴다. 일부는 독창적이며 합당한 이유로 널리 복사되지 않았습니다.

하나는 컨텍스트 라는 개념입니다. 모든 함수 호출은 목록 또는 스칼라 컨텍스트에서 발생하며 각 컨텍스트에서 완전히 다른 작업을 수행 할 수 있습니다. http://use.perl.org/~btilly/journal/36756 에서 지적했듯이 이것은 모든 API를 복잡하게 만들고 종종 Perl 코드에서 미묘한 디자인 문제를 유발합니다.

다음은 구문과 데이터 유형을 완전히 묶는 아이디어입니다. 이는 객체가 다른 데이터 유형으로 가장 할 수 있도록하는 넥타이의 발명으로 이어집니다. (과부하를 사용해도 동일한 효과를 얻을 수 있지만 Perl에서는 타이가 더 일반적입니다.)

여러 언어로 인한 또 다른 일반적인 실수는 어휘보다는 동적 범위 지정을 제공하는 것입니다. 이 설계 결정을 나중에 되 돌리는 것은 어렵고 오래 지속되는 사마귀로 이어집니다. Perl에서 이러한 사마귀에 대한 일반적인 설명은 http://perl.plover.com/FAQs/Namespaces.html 입니다. 이것은 Perl이 our변수와 static변수를 추가하기 전에 작성되었습니다 .

사람들은 정적 입력과 동적 입력에 대해 합의에 동의하지 않습니다. 나는 개인적으로 다이나믹 한 타이핑을 좋아합니다. 그러나 오타를 잡을 수 있도록 충분한 구조를 갖추는 것이 중요합니다. Perl 5는이 작업을 엄격히 수행합니다. 그러나 Perl 1-4는 이것을 잘못 알고 있습니다. 다른 여러 언어에는 엄격한 것과 동일한 기능을하는 린트 체커가 있습니다. 보푸라기 검사를 시행하는 것이 좋다면 가능합니다.

더 나쁜 아이디어 (많은 아이디어)를 찾고 있다면 PHP를 배우고 그 역사를 연구하십시오. 내가 가장 좋아하는 과거의 실수 (많은 보안 허점으로 인해 수정되었습니다)는 기본적으로 양식 매개 변수를 전달하여 변수를 설정할 수 있도록 기본 설정되어있었습니다. 그러나 그것은 유일한 실수와는 거리가 멀다.

코드 블록 및 객체 리터럴에 대한 JavaScript 모호성.

  {a:b}

코드 블록 일 수 있으며, 여기서 a레이블과 b표현식입니다. 또는 a값을 가진 속성으로 객체를 정의 할 수 있습니다.b

FORTRAN으로 돌아가고 공백은 둔감합니다.

그것은 사양을 만회했다. 이 END카드는 7-72 ​​열에서 'E', 'N'및 'D'의 순서로 카드로 정의되어야하며 적절한 "END"카드가 아닌 다른 비 공백이 없습니다. 열과 다른 것.

그것은 쉬운 구문 혼동을 초래했다. DO 100 I = 1, 10는 루프 제어문 이었지만 DO 100 I = 1. 10, 변수 1.1에 값 1.1을 할당 한 명령문이었습니다 DO10I. (변수를 선언하지 않고 만들 수 있다는 사실, 첫 글자에 따른 유형)에 기여했습니다. 다른 언어와 달리 공백을 사용하여 명확성을 기하기 위해 토큰을 분리 할 방법이 없었습니다.

또한 다른 사람들이 정말 혼란스러운 코드를 작성할 수있게했습니다. FORTRAN의이 기능이 다시는 복제되지 않은 이유가 있습니다.

BASIC의 가장 큰 문제 중 하나는 초기 환경을 넘어 언어를 확장 할 수있는 잘 정의 된 방법이 없다는 것인데, 이는 완전히 호환되지 않는 구현들 (그리고 표준화에서 거의 관련이없는 사후 시도)을 초래합니다.

거의 모든 언어는 미친 프로그래머가 범용으로 사용하게됩니다. 미친 아이디어가 떠오를 경우 처음에는 일반적인 용도로 계획하는 것이 좋습니다.

나는 DSL (도메인 특정 언어)을 믿고 언어에서 내가 중요하게 생각하는 것은 DSL을 정의 할 수 있는지 여부입니다.

Lisp에는 매크로가 있습니다. 대부분의 사람들이 나처럼 이것을 좋은 것으로 간주합니다.

C와 C ++에는 매크로가 있습니다. 사람들은 그것에 대해 불평하지만 DSL을 정의하는 데 사용할 수있었습니다.

자바에서는 그것들이 빠져 있었고 (따라서 C #에서는) 미결 한 것으로 선언되었습니다. 물론 그것은 당신이 지능을 가질 수있게하지만, 나에게 그것은 단지 oeuvre 입니다. DSL을 수행하려면 직접 확장해야합니다. 그것은 고통스럽고 코드를 적게 사용하여 훨씬 더 많은 것을 할 수 있지만 나쁜 프로그래머처럼 보이게합니다.

모든 언어로 된 진술 . 그들은 표현으로 할 수없는 일을하지 않으며 많은 일을하지 못하게합니다. ?:삼항 연산자 의 존재는 그 주위를 돌아 다니려고 시도하는 한 예일뿐입니다. JavaScript에서는 특히 성가시다.

// With statements:
node.listen(function(arg) {
  var result;
  if (arg) {
    result = 'yes';
  } else {
    result = 'no';
  }
  return result;
})

// Without:
node.listen(function(arg) if (arg) 'yes' else 'no')

저에게는 C에서 파생 된 모든 언어를 괴롭히는 것이 디자인 문제입니다. 즉, " dangling else " 입니다 . 이 문법 문제는 C ++에서 해결되었지만 Java 및 C #으로 수행되었습니다.

지금까지의 모든 대답은 많은 주류 언어의 단일 실패를 지적한다고 생각합니다.

이전 버전과의 호환성에 영향을주지 않고 핵심 언어를 변경할 수있는 방법이 없습니다.

이것이 해결되면 다른 모든 그립을 거의 해결할 수 있습니다.

편집하다.

이것은 서로 다른 네임 스페이스를 사용하여 라이브러리에서 해결할 수 있으며 언어의 대부분의 핵심에 대해 비슷한 것을 수행 할 수 있지만 여러 컴파일러 / 통역을 지원해야 할 수도 있습니다.

궁극적으로 나는 완전히 만족스러운 방법으로 그것을 해결하는 방법을 모른다고 생각하지만 해결책이 존재하지 않거나 더 이상 할 수 없다는 것을 의미하지는 않습니다.

Java의 자동 정수 산술 오버 플로우

Java와 C # 모두 제네릭을 추가하면서 이전 버전과의 호환성을 유지하려는 요구로 인해 유형 시스템에 성가신 문제가 있습니다. Java는 제네릭과 배열을 혼합하는 것을 좋아하지 않습니다. C #에서는 값 형식을 범위로 사용할 수 없으므로 유용한 서명을 허용하지 않습니다.

후자의 예로써,

public static T Parse <T> (Type <T> 유형, 문자열 str) 여기서 T : Enum

공용 정적 객체 구문 분석 (유형, 문자열 str)

MyEnum e = Enum.Parse (typeof (MyEnum), str);

MyEnum e = (MyEnum) Enum.Parse (typeof (MyEnum), str);

tl; dr : 버전 1을 게시 한 후가 아니라 유형 시스템 설계를 시작할 때 파라 메트릭 다형성에 대해 생각하십시오.

나는 화를 내기 위해 자신을 열어 놓은 것처럼 느껴지지만 C ++에서 참조로 일반 오래된 데이터 유형을 전달하는 기능이 정말로 싫어합니다. 나는 복잡한 유형을 참조로 전달하는 것이 약간 싫어. 함수를보고 있다면 :

void foo()
{
    int a = 8;
    bar(a);
}

호출 지점부터는 bar완전히 다른 파일로 정의 될 수있는 다음과 같은 방법을 알 수 없습니다.

void bar(int& a)
{
    a++;
}

어떤 사람들은 이와 같은 일을하는 것이 나쁜 소프트웨어 디자인 일 뿐이고 언어를 비난하지는 않을 것이라고 주장 할 수도 있지만, 그 언어로 인해 처음부터 이것을 할 수있는 것은 마음에 들지 않습니다. 포인터 사용 및 호출

bar(&a);

훨씬 더 읽기 쉽습니다.

바꾸다

COBOL을 배울 때 ALTER 문 은 여전히 ​​표준의 일부였습니다. 간단히 말해서이 명령문을 사용하면 런타임 동안 프로 시저 호출을 수정할 수 있습니다.

위험하지 않은 코드 부분에이 문장을 넣을 수 있으며 나머지 프로그램의 흐름을 완전히 바꿀 가능성이 있습니다. 여러 ALTER 문을 사용하면 어느 시점에서 프로그램이 무엇을했는지 알기가 거의 불가능합니다.

저의 대학 강사는 매우 강조하면서 어떤 프로그램에서라도 그 진술을 본다면 자동으로 우리를 끌어들일 것이라고 말했습니다.

프로그래밍 언어의 최악의 죄는 잘 정의되어 있지 않습니다. 내가 기억하는 경우는 C ++이며 그 기원은 다음과 같습니다.

1. 다음 책이나 예제를 통해 프로그램을 컴파일하고 실행할 수 없도록 잘못 정의되어 있습니다.
2. 하나의 컴파일러와 OS에서 컴파일하고 실행하도록 프로그램을 조정 한 후에는 컴파일러 나 플랫폼을 전환 한 경우 다시 시작해야합니다.

내가 기억 하듯 이 C ++를 C만큼 전문적으로 신뢰할 수 있도록 C ++을 충분히 정의 하는 데 약 10 년이 걸렸 습니다.

내가 생각하는 다른 것 (다른 대답으로 가야합니까?)은 일반적인 작업을 수행하는 "최상의"방법을 두 가지 이상 가지고 있습니다. (다시) C ++, Perl 및 Ruby의 경우입니다.

C ++의 클래스는 언어에서 일종의 강제 디자인 패턴입니다.

런타임에 구조체와 클래스 사이에는 실질적인 차이가 없으며 "정보 숨기기"의 실제 프로그래밍 이점이 무엇인지 이해하는 것이 혼란 스럽습니다.

나는 그것을 위해 하향 투표 할 것이지만, 어쨌든 C ++ 컴파일러는이 언어를 작성하기가 너무 어려워 괴물처럼 느껴집니다.

모든 언어에는 결점이 있지만, 일단 당신이 그들에 대해 알고 있다면 귀찮은 것은 없습니다. 이 쌍을 제외하고 :

복잡한 API와 결합 된 복잡한 구문

이것은 특히 Objective-C와 같은 언어에 해당됩니다. 구문은 매우 복잡 할뿐만 아니라 API는 다음과 같은 함수 이름을 사용합니다.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

나는 명백하고 모호하지 않은 것이지만 이것은 우스운 일입니다. xcode로 앉을 때마다 n00b와 같은 느낌이 들며 정말 실망 스럽습니다.

1. C로 서명 된 문자-수학자들이 작은 물건을 많이 모을 수 있도록 고안된 가증
2. 이야기를 사용할 필요가없고 수식을위한 충분한 공간 이없는 수학자에게 다시 의미 론적 내용을 전달하기 위해 사례 사용
3. 기본 방언에서하자 / 일반 과제 대 과제 할당-여기에 관련된 수학자가 없습니다.