스몰 토크의 특징

스몰 토크의 특징

---

모든 기술 출판물과이 사이트에서도 사람들은 항상 OO 언어를 Smalltalk와 비교 합니다. 제 경험은 Java입니다. 스몰 토크가 너무 중요해서 공부해야합니까?

---

스몰 토크는 최초의 객체 지향 (OO) 언어 중 하나였으며 ( Simula 및 Eiffel 같은 다른 언어와 함께 ) OO 의미에서 극도로 "순수"하다고 말할 수 있습니다.

• 모든 것은 객체이고 객체는 메시지 전송을 통해서만 전달됩니다.
• 프리미티브 없음 ( ints, booleans 등 없음)
• 제어 구조가 없습니다 for( while, if등). 불가능 해 보이지만 사실입니다!
• 정적 없음

또한 지금은 일반적인 다른 것들을 개척했습니다.

• 가상 머신 (및 JIT 컴파일)
• 검사를 통한 디버깅
• "핫스왑"실행 코드
• 최신 IDE
• 폐쇄
• 오리 타이핑
• UI 용 MVC (Model-View Controller) 아키텍처
• 테스트 중심 개발 (TDD) 및 애자일 방법론

그리고 스몰 토크와 관련된 다른 것들이 실제로 주류가되지 못했습니다.

• 파일 기반이 아닌 "이미지"기반 시스템.
• 객체 지향 데이터베이스

그리고 Java collections API와 apache-commons collections API가 Smalltalk의 영향을 많이받는 다고 말할 수 있습니다.

스몰 토크 자체를 배워야한다고 말하지는 않겠지 만 이러한 기능의 기본 사항 (현재 다른 많은 언어로 제공됨)에 익숙 하면 확실히 유익합니다.

현재이 언어에 대한 질문은 123 개 뿐이며 , 원래는 제작자 인 Alan Kay가 교육용 언어 (즉, 어린이를 대상으로 함)로 의도 한 것입니다. 더 이상 특별히 많이 사용되지 않습니다. 그것이 사용되지 않는다는 것은 아닙니다. 예를 들어 JPMorgan에는 대규모의 이색 파생 상품 리스크 관리 시스템이 작성되어 있습니다.

---

스몰 토크에는 다음을 포함하여 오늘날 우리 모두가 당연하게 여기고있는 많은 놀라운 혁신이 있습니다.

• 되는 최초의 IDE
• 마우스로 GUI에 대한 프로그래밍 지원 제공 Smalltalk GUI 프로그래밍을 배우면 MVC를 제대로 이해했을 것입니다.
• 매우 잘 작동하는 소수의 강력한 아이디어로 구축 됨
• 스몰 토크 방법은 예기치 않은 동작에 밖으로 충돌하지 않습니다 - 그것은 적응이다 . 이해하지 못하는 객체에 메시지를 보내면 디버거가 나타나서 해당 메소드를 작성하도록 초대합니다. 따라서 점진적 개발에 대한 탁월한 지원을 제공합니다 .
• IDE, 작성중인 앱 및 데이터는 모두 동일한 시스템의 일부이므로 자신 만의 도구를 작성하고 계측을 훨씬 쉽게 디버깅 할 수 있습니다.
• 스몰 토크 의 TDD 툴셋은 여전히 다른 어떤 언어보다 낫 습니다 (아래 참조).
• Squeak Smalltalk는 상당히 많은 최첨단 디자인 연구를했습니다.
  • 형태 적 UI가 - 당신은 "생동감"의 개념을 잘 알고 얻을 수 있습니다
  • 해변 웹 프레임 워크- 연속 서버가 무엇 이며 어떻게 근본적으로 다른지 알아보십시오.
  • Squeak은 OLPC 소프트웨어 (어린이 1 인당 노트북 1 대) 프로젝트 와 긴밀한 관계를 맺고 있지만 아직 세계에 큰 영향을 미칠 수 있습니다.
  • "특성"이 무엇인지 알아보십시오 ...
  • Open Croquet이라는 급진적 3D 몰입 형 환경으로 플레이하십시오 .
• Smalltalk는 더 작고 간단하며 일관된 언어이기 때문에 자체 내장 환경으로 OOP 교육을 시작하기에 훨씬 덜 혼란스러운 곳 입니다. 이 길을가는 사람들은 주류 언어의 모든 지저분한 불일치없이 기본적인 OOP를 배울 수 있기 때문에 더 나은 Java, Ruby 및 C # 프로그래머가됩니다.
• 일부 상용 Smalltalk에는 놀라운 다중 노드 분산 OO 데이터베이스 환경이 있습니다. 젬스톤에 대해 생각하고 있습니다.
• Model-View-Controller와 Model-View-Presenter의 차이점 을 알고 싶습니다 . Dolphin Smalltalk를보세요 ...

오늘날 스몰 토크를 배우는 가장 중요한 이유는 익스트림 프로그래밍과 스크럼이 모두 스몰 토크 커뮤니티에서 발명 되었기 때문입니다. 그리고 스몰 토크에서 경험하는 고도의 인터랙티브 프로그래밍 스타일은 자바로 할 수있는 어떤 것보다 더 간단하고 강력하며 직접적입니다. 또는 C # 또는 Ruby ... 그리고 Smalltalk에서 극단적 인 프로그래밍을 시도하기 전까지는 애자일 메서드가 얼마나 잘 작동하는지 이해할 수 없습니다 . 비슷한 기능 세트를 가진 다른 언어 (주류 언어는 아님)는 거의 없습니다.

... SUnit을 사용하는 데 필요한 TDD가 무엇인지 이해하기 위해. JUnit은 테스트가 실패한 위치를 보여줍니다. SUnit을 사용하면 테스트가 실패한 지점에서 디버거를 클릭하고 실제 개체와 연결 방법을 볼 수 있으므로 디버거에서 코드가 실패한 방법을 확인하고 바로 수정할 수 있습니다.

---

예, 스몰 토크는 매우 중요하므로 공부해야합니다. 왜? 순수하고 단순한 형태로 객체 지향 프로그래밍을 이해할 수 있습니다. 사람들이 잊어 버리는 것은 Smalltalk-80 "Blue Book"이 언어에 전념하는 약 90 페이지에 불과하다는 것입니다. 언어는 그렇게 간단합니다. 나머지 300 페이지는 단일 상속을 사용하는 클래스 기반 객체 지향 언어 설계의 걸작 인 미리 정의 된 클래스 계층에 대해 설명합니다. 객체에 대해 훨씬 더 깊이 이해하게 될 것입니다 (예를 들어, 클래스는 객체이고 메타 클래스가 있습니다. 등등 무한대에 도달 할 수 있습니다 ... 시스템을 유한하게 유지하기 위해 매듭이 조심스럽게 묶여있는 것을 제외하면). Java 또는 C ++와 같은 하이브리드 언어. 스몰 토크는 그 역사뿐만 아니라 단순성 때문에 중요합니다.

• 전체 언어 와 라이브러리를 이해할 수있을 정도로 간단 합니다.

• 논리적 극한까지 밀어 붙인 하나의 아이디어 (객체 만 있으면 됨)를 보여줍니다.

누구나 스몰 토크에서 배울 점이 있습니다!

---

Smalltalk는 최초의 두 OOP 언어 중 하나이며 다른 하나는 Simula-67입니다. 결과적으로 Simula가 개척 한 메서드 호출을 중심으로 정적으로 형식화 된 모델 (C ++, Java, C #이 모두 여기에 속함)과 Smalltalk (Python, Ruby가 여기에 속함 ).

오늘날, 스몰 토크는 그 자체로 특별히 중요하지 않습니다. 일부 사람들은 여전히 ​​그것을 쓰기 위해 그것을 사용하고 있지만 확실히 주류는 아닙니다. 그러나 그것을 배우면 OOP가 어떻게 그리고 왜 진화했는지에 대한 통찰력을 얻을 수 있습니다.

---

I spent about 5 minutes in a presentation at a conference last month on Smalltalk's history and influence. See Image-based development with Smalltalk. One of the more foreign concepts to today's programmers is the "image-based" development. There are some good analogies, including a DBMS and a spreadsheet.

---

Yes. Download the seaside one-click image, start using it with the tutorial from James Foster and you will learn at least:

• how web applications should be build
• how debugging is supposed to work

---

I agree with the others. I'm not sure if it's important per se, but it is COOL (imho).

I love that there are no loops or conditionals in the language. If-then-else is a message sent to a boolean object. Objects of type True do one thing, objects of type False do another. (Yes, True and False are subtypes of Boolean, with a single value each, true and false respectively).

It starts out being kind of counter-intuitive, but it does give you a very interesting, and deep, view of how OO programming should work...

---

Not only was it one of the first, Smalltalk remains to this day a paragon of OO language design. The more popular languages that came later — C++, Java, even Objective-C — all have more primitive object-orientation and are more restrictive than good old Smalltalk. Smalltalk had pervasive first-class objects, great support for runtime introspection, very natural use of duck typing and closures that worked better than I've seen in any non-functional language. I mean, we're talking about a language that had no native control structures (if, while, etc.) but was able to create them out of its object system in a way that worked seamlessly. How cool is that?

I wouldn't recommend Smalltalk for any intensive desktop app development these days (there just isn't a viable implementation IMO), but if you want to see how OO was meant to be and maybe pick up some ideas you can use in your apps, Smalltalk is a great place to look.

---

If you only know one object-oriented language you should consider learning a second and a third and a fourth in order to gain a broader perspective on programming with objects. Learning Smalltalk will stretch your brain because a lot of the familiar concepts we're used to in other languages (e.g. if-then-else, for(;;), while(), etc) are not there in Smalltalk. There are equivalents, obviously, but Smalltalk does things differently, and learning about different ways to do things is always a good idea.

Good luck.

---

I've just started to revive my interest in Smalltalk, and in my opinion, there are a few compelling things that are special about Smalltalk:

• Highly productive development environment
• Built-in support for Agile/Extreme programming methodologies
• "Pure" object model
• Easy to use graphics framework

None of these make it especially useful for people who are not in the software development business. My first exposure to it was when I saw a user interface for an embedded device prototyped on a PC using Smalltalk. This allowed the user interface to be modified and tested very quickly, and when completed, provided the embedded developers an "executable specification" that was far more precise than any document. I'm surprised I haven't seen this technique used far more often than I've observed in my travels during the last 20 years.

Using Smalltalk as a prototyping tool is where my interest lies: I think that given a new problem, different approaches to solving it can be tried and validated very quickly and easily in a Smalltalk environment, and once the desired solution is found it should be relatively mechanical to convert it to Java/C++/C# etc. etc. In fact, for repetitive sorts of things, it might well be possible to use Smalltalk to generate code for parts of the solution in some other target language.

---

The other thing about SmallTalk is that its alumni include Kent Beck and Ward Cunningham. Their work with SmallTalk spawned automated xUnit testing, software design patterns, CRC Cards and other practices which ed into XP/Agile, etc. So it could be argued that SmallTalk has been a major contributor to the modern programming landscape.

---

Just two comments:

1. Smalltalk is not object "oriented", is real objects, only objects and messages in the environment.

2. Smalltalk is not a language, is an environment that has a language (of the same name), but most of the "magic" here is thanks to the environment (the image).

참고URL : https://stackoverflow.com/questions/1821266/what-is-so-special-about-smalltalk