스티브잡스 이후의 tech트랜드는 확실히 하드웨어다. 특히 킥스타터를 보면 덕후덕후하고 기발한 하드웨어들이 줄줄이 올라오고, 상당수의 제품들이 단순히 스타업의 프로토타잎이 아니라 메인스트림의 상품 수준이다. 원인으로 생각해 볼만 한것들은 클라우드 펀딩등으로 자금이 쉽게 제공되고, 잡스횽 덕에 높은 하드웨어적 아름다움에 대한 대중적 심미안이 뜨이고, 마지막으로 제조를 가능하게 하는 신기술(3d printing, cloud computing, etc)이 받혀주는 덕에 이런 트랜드가 이어져 가고 있다. 일하고 있는 A사에서도 CAD, CAE, PLM 을 democratize에 목숨거는 분위기인걸 보면 앞으로 몇 년은 갈 트랜드인것 같다.

원문 http://www.paulgraham.com/hw.html

Y Combinator의 장점 중 하나는 조기에 광범위하게 주목는 것이다. 즉 우리는 다른 사람들에 앞서 트렌드를 본다.  최근 가장 눈에 띈 트렌드 중 하나가 하드웨어 스탓업 많아진것이다. 84 기업 중 7 개가 하드웨어를 만들고 있었다. 대체로 그들은  기존 기업보다 잘하고 있었다.

물론 그들 투자자로부터 저항을 받는다. 투자자들은 하드웨어에 뿌리 깊은 편견을 가지고있다. 그러나 투자자의 아이디어는 후행 지표다. 최고인 창업자는 최고의 투자자보다 미래에 선견지명이있는 것이다. 왜냐하면 최고의 창업자들이 그 미래를 만들어 있기 때문이다.

이 트렌드를 견인하고있는 것은 하나뿐이 아니다. 클라우드 펀딩 사이트들에서는 하드웨어가 무척 잘하고있다. 태블릿의 보급도 태블릿에서 컨트롤 할 수있는 새로운 제품을 만드는 것을 가능하게하고 제품끼리 결합 것조차 가능하게하고있다. 전기 모터도 진화했고, 다양한 종류의 무선 연결도 당연 해지고있다. 이러한 트렌드가 제품을 제조하는 것을 밀고있다.

Arduino (아루두이노은 AVR 마이크로 컨트롤러, 입출력 포트를 갖춘 보드, C 언어 바람 Arduino 언어와의 통합 개발 환경으로 구성된 시스템), 3D 프린팅, 레이저 절단기와 CNC 밀링 머신이보다 쉽게​​ 이용할 수 있도록 이제보다 쉽게​​ 프로토 타입을 생산 가능하게하고있다. 또한, 온라인으로 구입하는 사람들이 늘고있는 것으로 유통 업체도 병목현상을 덜 격는다

내가 할 수있는 질문은, 왜 갑자기 하드웨어 쿨해졌는지이다.  그것은 지금까지도 멋졌어. 실제 물건은 훌륭하다. 물건은 소프트웨어와 같이 급격한 성장을 할 수있는 좋은 방법이 아니었다 뿐이다. 그러나 그 규칙해도 영구적으로 따르지 않는 것 같다. 오래된 일도 아니다. 그것은 1990년대 부터 그렇게 된것이다. 소프트웨어의 장점 것도 일시적인 것이 될지도 모른다. 해커 무리는 하드웨어를 만드는일 사랑하고, 고객 그걸  기꺼이 산다. 그래서 쉽게 하드웨어파는 일이 소프트웨어를 쉽게 파는 일에 가까와지고, 더욱 더 많은 하드웨어 스타트업을 볼수있게 될지도 모른다.

틀린 생각이 실제로 틀려질 때까지 틀린게 아닌것은 처음 보는 일이 아니다. 기업에서 투자자가 창업자로 부터 배움를 얻는 것도 처음이 아니다.

그래서 만약 당신이 하드웨어에 착수하고 생각하고 있다면, 무서워할 필요는 없다.  왜냐하면 당신은 투자자 무리가 당신을 공격하는 것을 걱정하는 것이기 때문이다. 특히 하드웨어의 아이디어를 가지고  Y Combinator (폴그레엄이 참여하는 펀드)에 응모할 때 두려워할 필요는 없다. 왜냐하면 우리는 하드웨어 스타트업에 강한 관심을 가지고 있기 때문이다.

우리는 다음 세대의 Steve Jobs 위한 기회의 방이 있다는 것을 알고있다. 그러나 또한 확실히  그 기회의 방에 <당신 이름> 을 써 넣을 수 있다는 것이다!

OOP든 STL이든 잘 돌면 장땡!

http://stackoverflow.com/questions/1039853/why-is-the-c-stl-is-so-heavily-based-on-templates-and-not-on-interfaces 의 답변 간단 번역

간단히 말하자면, C++ 은 변해왔거든. 70년대 Stroustrup 이 OOP 기능을 넣어 C를 향상시키려고 했어. 근데 시간은 흐르고, 정작 C++ 표준화가 되었을 1998년에는 언어 자체가 더이상 OOP 언어가 아니게 된거지. 다중-패러다임 언어가 되었네. 물론 여전히 OOP를 지원하지만, 튜링-완전한 템플릿 언어가 가세한거야. 이 변화가 컴파일타임 메타프로그래밍을 가능케 하고, 사람들은 generic programming를 발견하지. 그러니까 갑자기 OOP가 그리 중요한 문제가 아니게 된거야. 이런 새 기능을 가지고 간단하고, 짧고, 더 효과적인 코드를 쓸수 있게 됐어

OOP는 만병통치약이 아니야. 깜찍한 생각이지 그리고 그게 처음 만들어진 70년대에는 절차지향 언어에서 꽤 진일보한것었어. 그런데 솔직히 모든면에서 좋아진건 아니란말야. 많은 경우, 엉성하고 줄만길어져 그리고 진정한 재사용가능 코드나 모듈화를 이루지 못했어.

그래서 C++ 커뮤니티가 최근 generic programming에 더 관심을 가지게 된거고 왜 모두들 functional programming 이 똑똑하다는 걸 깨닫기 시작했지. OOP 그 자체로는 별로 아름답지 못하거든.

가상적 OOP화된 STL의 의존 그래프를 그려봐. 얼마나 많은 클래스가 서로 알고 연결될것 같아? 꽤 많은 의존관계가 있겠지. 그 안에서 단지 vector 헤더만  include하는게 가능할까, <iterator>나 <iostream>을 같이 넣지 않고 말야. STL은 이걸 쉽게 만들었어. vector는 각 요소를 정의하는 iterator타잎을 알고 있고 그게 다야. STL 알고리즘은 아무 것도 모르지. 심지어 iterator 헤더도 없이, iterator 를 인자로 받아 들여. 그럼 둘중 어떤게 더 모듈화 된거지?

STL이 Java처럼 OOP룰을 잘 안따를 수 있어. 하지만 OOP가 지향하는 목적을 이룰수 있지않아? 재사용가능성, 낮은 결합도, 모듈화, 자료은닉 같은 것 말야.

원문:
The short answer is "because C++ has moved on". Yes, back in the late 70's, Stroustrup intended to create an upgraded C with OOP capabilities, but that is a long time ago. By the time the language was standardized in 1998, it was no longer an OOP language. It was a multi-paradigm language. It certainly had some support for OOP code, but it also had a turing-complete template language overlaid, it allowed compile-time metaprogramming, and people had discovered generic programming. Suddenly, OOP just didn't seem all that important. Not when we can write simpler, more concise and more efficient code by using techniques available through templates and generic programming.

OOP is not the holy grail. It's a cute idea, and it was quite an improvement over procedural languages back in the 70's when it was invented. But it's honestly not all it's cracked up to be. In many cases it is clumsy and verbose and it doesn't really promote reusable code or modularity.

That is why the C++ community is today far more interested in generic programming, and whyeveryone are finally starting to realize that functional programming is quite clever as well. OOP on its own just isn't a pretty sight.

Try drawing a dependency graph of a hypothetical "OOP-ified" STL. How many classes would have to know about each others? There would be a lot of dependencies. Would you be able to include just thevector header, without also getting iterator or even iostream pulled in? The STL makes this easy. A vector knows about the iterator type it defines, and that's all. The STL algorithms know nothing. They don't even need to include an iterator header, even though they all accept iterators as parameters. Which is more modular then?

The STL may not follow the rules of OOP as Java defines it, but doesn't it achieve the goals of OOP? Doesn't it achieve reusability, low coupling, modularity and encapsulation?

And doesn't it achieve these goals better than an OOP-ified version would?

As for why the STL was adopted into the language, several thnigs happened that led to the STL.

First, templates were added to C++. They were added for much the same reason that generics were added to .NET. It seemed a good idea to be able to write stuff like "containers of a type T" without throwing away type safety. Of course, the implementation they settled on was quite a lot more complex and powerful.

Then people discovered that the template mechanism they had added was even more powerful than expected. And someone started experimenting with using templates to write a more generic library. One inspired by functional programming, and one which used all the new capabilities of C++.

He presented it to the C++ language committee, who took quite a while to grow used to it because it looked so strange and different, but ultimately realized that it worked better than the traditional OOP equivalents they'd have to include otherwise. So they made a few adjustments to it, and adopted it into the standard library.

It wasn't an ideological choice, it wasn't a political choice of "do we want to be OOP or not", but a very pragmatic one. They evaluated the library, and saw that it worked very well.

In any case, both of the reasons you mention for favoring the STL are absolutely essential.

The C++ standard library has to be efficient. If it is less efficient than, say, the equivalent hand-rolled C code, then people would not use it. That would lower productivity, increase the likelihood of bugs, and overall just be a bad idea.

And the STL has to work with primitive types, because primitive types are all you have in C, and they're a major part of both languages. If the STL did not work with native arrays, it would be useless.

Your question has a strong assumption that OOP is "best". I'm curious to hear why. You ask why they "abandoned classical OOP". I'm wondering why they should have stuck with it. Which advantages would it have had?

하드 링크는 동일 물리 공간을 가리키는 두 개의 링크를 만드는 것이고

Link A –> Physical storage

Link B –> 

심볼릭 링크는 한 물리 공간을 가리키는 링크를 하나 만드는 것이다.

Link B –> File A @ physical storage