OKKY 및 페이스북 에서  두서없이 작성했던 글을 모아보았습니다.

(정확한 통계가 아니라 제 협소한 경험에 의한 주장이라는 점과 대중화의 정의가 사람마다 다를것이기때문에 그냥 이런 생각도 있구나 하시면 될 거 같습니다.:-) )

유망언어들 중 클래스가 없는 언어들이 있죠.클로저,golang  말입니다. 이 언어들은 클래스의 무용과 그 자체가 가진 복잡함을 단점으로 대비시켜 자기 언어를 광고 하기도 합니다.  맞는 부분도 있지만 대중화에 있어서는 틀렸다고 봅니다. 인간이란 사회적 동물입니다. 어떤것들의 집합,연관성,소속,계층에 대해 인식하는것을 애초부터 자연스럽게 느껴왔죠. 클래스가 그런겁니다. 사람들은 뭔가가 하나에 뭉쳐있다는것 만으로 큰 안정감을 얻게 됩니다. C++ 자바가 대규모 프로젝트에서 계속 사용되는 증거라고 봅니다. 저는 이 안정성에 주목 하였으며 이 특장점 때문에 클래스기반 객체지향언어는 계속 대중성에 있어서 최상위에 위치 할 것입니다.

이 글의 조회수가 높아짐에 따라 스칼라에 대한 안좋은 인식이 생길까 우려스러워 한 마디 추가 합니다.

개인적으로는 스칼라 언어  굉장히 좋아합니다. 그래서 제 블로그에는 수많은 스칼라,AKKA,Play 글이 올려져있습니다. 웹개발에 있어서 스칼라기반  play2  가 스프링 보다 즣은 면이 많다고 생각합니다. Reactive 프로그래밍에 적합합니다.Akka 로 마이크로서비스 구현하는것도 편리하구요.그러나 내가 좋다고 대중적 1,2 등 언어가 될 순 없습니다. 10등 20등 언어면 어떻습니까 내가 우리팀이 좋아하면 쓰는거죠. ㅎㅎ

물론 모든 언어 파라다임은 장단이 있으며 함수형 프로그래밍의 단점이 없는것은 아닙니다.

함수형프로그래밍의 단점1  

함수형프로그래밍의 단점2

@ 아래부터 원글입니다. 
미리 정리해서 쓴 글이 아니라 어떤 글에 대한 반박 형식의 글을 모음집이라 
정리가 잘 안된 점 양해해주세요. 

" list.map( x => User(x.name, format("Y-m-d", x.regdate) ) ) 로해결합니다. "  - notice 님 글 발췌.

스칼라 그러니깐.. 저런 함수형 표현들이 굉장히 깔끔하긴하죠.

그리고 저런표현이 훨씬 좋다고 많이들  광고합니다. 심취하면 notice 님처럼 과격한  글도 쓰는것이구요. 

라인수가 줄어들었으니.. 유지보수가 편해진다. 길게 늘어쓰지 않고, 함수(이름있는) 로 표현하니깐

이게 무엇인지 명확하게 알려줘서 유지보수가 편해진다. 내부적으로 성능을 높이게되면 공짜점심이 생긴

다 등등.. 엄청 좋긴 합니다. 

근데 하나의 함정은 for 문 대신해서 저런 추상층이 높아진 표현은 그 만큼 오류에 대한 복잡도도 증가합니

다.  뭐 그렇다고 "그럼 c 로 짜거나 어셈블리로 짜면 더 단순해서 좋겠네? " 라고 말하실 수 도 있으나, 

제 생각은 보통 사람들이 받아드리는 최적의 추상단계로 "자바" "파이썬" 정도로 생각합니다.(물론 Java 8 

Stream API 도 제외. 그것도 모두가 평범하게 사용되기까지는  10년 있어도 무리라고 봅니다.) 

(저도 함수형 좋아합니다. ^^) 근데 제가 10년넘게 C++ 을 주력언어로 사용하면서 느낀게..  

(C++ 은 10년전부터 함수형 패러다임을 추가하고있음) 

대부분의 개발자들은 혹은 인간은  본능적으로 함수형 패러다임을 어려워합니다. (익숙해지기 오래걸림) 

그냥 for문을 여러줄에 걸쳐서 작성한것을 읽는걸  "함수자"  등을 쓴것보다 더 쉽게 읽는다는 말입니다.

흡사 절차지향적으로 쭈욱 써놓은걸 , 객체지향적 패턴으로 마구 추상화 시켜놓은것보다 

코드리딩이 쉬운것 처럼말이지요.

 ( 객체지향적 코딩이 대중적 인간이 익숙해질수있는 최상점이라고 봄,  SQL 이나 LINQ 등을 양념으로) 

bool is_cool (const Thing& x) { ... }
find_if(begin, end, not1(ptr_fun(is_cool)));

* c++ 은 10년전부터 함수형을 지원했지만..이런 코딩을  일반적으로 실무에서 찾아보기 힘들죠..

  그냥 자기만족 수준. (물론 람다가 최근에 표준이 되어서.. 앞으로는 좀더 많이 쓰이겠지만..) 

내가 notice  님 이전글에서 , 함수형언어가 메이져가 될 가능성은 0%라고 예견했는데...

결국 이유가 단순합니다. 어려워서 입니다.   (단순 Functor 유틸조차 어렵습니다. 포인터,레퍼런스형 따로

있는 바인더,부정자..등등)    좀더 정확히 말하면  C++ 개발자들한테 어려운것을 감수할만큼 강력함을 어

필하는데 실패한거겠지요. (최근 자바8 Stream API 는 성능이라는 공짜점심때문에 더 좋아지긴 했습니다)

아마.. 순수함수형식의 코딩이 어렵지 않게 느껴지는 그룹과  꼭 필요한그룹에서는 사용되겠지요. 

근데 대중적이기는 무리라고 봅니다. 아 클로저는 아예 언급도 안하렴니다.  결국 자바는 쭈욱 갈거라고 생각합니다.(조금씩 차용하며)

(저런 함수형 표현을  쓰지 않더라도 충분함, 오랜기간 크게 사용되지도 않을거라 예견)

(먼가 엄청 강력한걸 어필할수있으면 자연스럽게 , 자바8이 각광받거나 스칼라로 옮겨감)  

대중에게 퍼트리고 싶어하시는 마음 알겠으나 ..그러기 위해서는 그렇게 과격하게 하지말고..

짧게짧게 팁/테크로 올리면.. 대중화까지는 안되더라도 많이들 쓰실겁니다.

( 추가)

혹자는 현재 미국에서는 스칼라가 많이 쓰인다느니..자바,c#,javascript들도 함수형계열 아이디어를

앞다투어 차용하지 않느냐? 다음세대는 함수형 페러다임에 쉽게익숙해질거다.등등

흠흠 얼핏 생각하면 그럴수도있겠습니다만..

근데 함수형패러다임은 아시다시피 요즘 튀어나온거도 아닐뿐더러  최근 스칼라로 코딩하는 데 이상한

우월감을 느끼는 몇몇 수준이하의 사람들처럼 옛날부터 Lisp 등에 자부심을 갖고있는 사람들은

존재했었지요 .근데 lisp / 헤스켈 / 얼랭 은 대증화와는 거리가 멀지요.

최근들어 분산환경이나 멀티코어를 적극적으로 활용해야하는 시대가 되기도 했고 사람이라는게 예전것,

오래된것은 쿨하지 못하다고 생각하는것등이 합쳐지면서 함수형패러다임의 고유의 장점들과

합쳐지면서 각광을 받습니다만..15 년전에 lisp을 처음봤을때부터 느낀게 함수형은 이질적이다라는거죠. 일단 재귀를 생활화한다는것 자체부터 대중과는 거리가 있습니다.

보통어렵다는 C++ 가 훨씬 코드리딩하는데 쉽게 다가왔었습니다.

자바는 더 정제되서 깔끔하구요.  제가  머리가 안좋아서 그럴수도있겠지만 해커와 화가 쓴 그 분

(폴그레이엄) 수준의 개발자가 기준이 될수가 없잖습니까. 고로 여러언어에서 함수형언어의

아이디어는 가져오겠지만 그리고 스칼라를 예로들면  기존에 C++ 의 boost split 보다 훨씬 파서구현에

용이하기때문에 특화되서 사용된다든지, akka  를 사용하는 병렬분산솔 루션이라든지 사용처는

충분히 존재 하겠지만  (물론 여러 대형싸이트에서도 사용중) 그런식의 코드가 대중화되거나

 (c++ 에서 단지 함수자,함수형 헬퍼 들조차 10년지난 아직까지 대중화 되지 않은 사례,템플릿메타프로그

래밍은 말할것도없고) 함수형언어가 객체지향언어를 제치고 메이져가 될꺼라는 생각은 아직 안듭니다.

한 10~20 년후에 어찌될지 굉장히 기대됩니다.  (추가: 10년후에도 여전히 C,C++, 자바, 파이썬, 자바스크립트가 대중언어일거라 예측합니다. Swift  가 강력히 올라갈것이고 그 뒷자리를 스칼라, Go 가 차지) 

(상세 추가 2 : 다른곳에 쓴 댓글을 가져옴) 

스칼라를 쓰면서 단지 제공되는 functor util 쓰는것에 대한 이득만으로 스칼라를 사용하는건 낭비라고

보구요. 말씀대로 강제하진 않지요. 잡종인 이유가 그런회유책이니깐요. (C++ 처럼) 자바도 대략

다 지원하는데 굳이..

결국 C++ 을 제대로 쓰려면 자바등을 공부해야 하는 or  하면 좋은것처럼 스칼라도 제대로 쓰려면

그 실제 철학을 잘알아야 하는데 아시다시피 스칼라는 이름이 나타내는것처럼 추상을 극대화하는것을

쉽게 해주며  언어를 사용하는 사람이 언어내에서 다른언어를 만들수있을 만큼 자유도를 높여주고자하는

철학을 가지고 태어났으며  그것을 이해하고 사용하려면 소위  함수형프로그램의 특성인  상태불변성,일

차/고계함수,클로저, 모나드등 뿐만 아니라 트레잇,  타입을 요리할수있는 능력이 필요하다고 할수있습니다.

일단 저런것에 대한 helloworld 로 간단한  파서를 만들어보는게 가장 빠르겠지요..

굉장히 간결해보이긴 합니다만..

이 모든것들이 많은 대중적인 소프트웨어에서 필요로 하는것 이상인거 같습니다.

 제 짧은 시야로는 저런 자유도가 오히려 부담감으로 다가오면서 객체지향언어와 그 동안 해온

 동적언어만(필요한것은 LINQ  처럼 언어안에 포함및 라이브러리 제공)으로 계속가자 라는 분위기속에  

 점유율은 크게 변동이 없을것이며 더 간단하면서 강력한 이상향의 무기를 기다리며 시대가 흘러가리라

 봅니다.

ps.

다양한언어가 공존해야한다는것을 부정하는글도 아니고 스칼라/클로져를 쓰지말자 혹은 나쁘다라는 글이 아닙니다.

A님: 

솔찍히 댓글을 달까 말까 하다가 걍 달아봅니다. 어짜피 프로그래밍을 잘 알지도 못하는 초보의 멍멍이 소리라고 생각하세요.FP가 재미 없다. 뭐 이건 취향이니 어떻게 할 수가 없어요. FP가 실버불렛도 아니고 FP만 써야 되는 것도 아니니까요. 한가인/김태희/전지현이 자기 취향 아니라고 주장을 한다면 뭐 어쩔수 없는거지요. (FP가 한가인 처럼 이쁘다는 건 절대 아님) 

FP가 어렵다. 이건 조금 논란의 여지가 많다고 생각해요. 저같은 경우 ASM과 C를 먼저 접했고 그담음 VB를 접하고 그다음 C++ 그리고 나서 Java & C# 그다음 Scala & F#이네요. 패러다임이 바뀔때 마다 말 그대로 캐고생을 했던 기억이 납니다. (c++ -> java는 쉬웠던거 같아요 ㅋ) 어렸을때 성질이 속된 말로 멍멍이랑 동급이라 문자 그대로 제 멍청함은 탓하지 않고 키보드 여러번 접어서 화풀이 했습니다. FP가 어려운지 평가하려면 지금 자신의 OOP 지적 수준과 FP에 지적 수준이 동일하진 않더라도 최소한 비슷한 수준은 되야 되겠지요. (지적 수준이 평가잣대가 되기 어렵다면 OOP로 프로그래밍한 시간에 필적하는 시간을 FP에 썻거나요.) OOP는 구루 소리 듣는데 FP는 중급이면서 어렵다고 판단하면 안될것 같아요. 반대로 FP로 구루 소리 들으면서 OOP는 많이 안해보고 학계에 몸담고 있으면서 헤스켈만 왕창해보고 OOP프로그래밍은 해본적도 없으면서 OOP를 까도 안되고요.

FP가 실용적인가? 저는 이 부분은 네라고 말할수 있을것 같습니다. 다만 분야가 어떤 분야인가가 중요하겠죠. 예를 들어 절대 예전 특정 시점의 히스토리를 확인할 필요가 없는 어플리케이션에 오버 엔지니어링을 해서 ES+CQRS를 하면 실용적일까요? 대부분의 FP 입문 책을 보면 이부분을 명확히 언급하고 있습니다. 상태변화가 심각한 문제의 소지를 발생시키지 않는 분야/어플에서는 주저 없이 저는 OOP 언어를 선택할꺼 같습니다. 하지만 병렬/분산 프로그래밍을 해야 한다면 OOP 언어는 안쳐다 볼꺼 같습니다. 제가 싸랑하는 스파크가 이부분을 잘 증명해 주고 있다고 생각합니다.

하마: 

얼핏 보면 교과서적인 말이라 반박하긴 머합니다만.. 좀 더 생각해보면 오류가 있어요. "당신이 OOP를 아는만큼 FP를 알지못하니 비교가 불가능하다." 이건 틀렸습니다. 절대적 노력의 값으로 생각해보면 FP로 처음 시작하는 경우 및 FP로 파라다임을 뼛속까지 바꾸기에는 엄청난 노력이 필요합니다. 왜 FP의 구루가 아닌데도 그걸 알 수 있냐? 경험적으로 이정도면 OOP에서는 충분했는데 FP는 아직 멀었다고 사람들이 몸소 느끼고 있기때문입니다. 굳이 FP를 OOP와 동일한 수준까지 하지 않아도 알 수 있는것이지요. 왜 역사적으로 OOP는 수많은 평범한 사람들이 해왔고 지금도 학원에서 열심히 공부하고 쉽게(?) 취직하여 개발을 하고 있는데 FP로는 그게 가능할까요? 그게 가능했다면 왜 지금까지 순수FP가 대중적으로 쩌리였을까요? 순수 FP는 대형벤더의 도움을 못받았다? 이 핑계는 좀 말이 안된다고 생각하지만 그렇다고 치더라도 좀 궁색하죠. 제 생각엔 filter, fold, reduce, map 류의 함수형도우미(?)들이 각 언어에 차용되어서 사람들이 조금씩 익숙해져가는것은 가능하지만 완전한 파라다임변환으로의 대중이 옮겨가는것은 아예 불가능하다라고 말하고 싶네요.

동시성 얘기도 나와서 말인데.. FP는 광고하죠. 상태가 없으니 동시성프로그래밍에 최선이다라고... 그래서 현재 더 FP가 주목받고 있는 것도 사실입니다. 다만 생각해볼것은 해결해야하는 문제들을 살펴보면 그렇게 동시성 문제가 복잡하게 얽혀있지 않은 문제들이 많다는것이며 ,(즉 자바에서 기존에 제공하는 방식으로도 충분한..굳이 언어파라다임을 바꾸지 않아도 충분한..) 클로저,하스켈을 사용하거나 Scala 를 완전한 FP로 사용하기보다는 그냥 객체지향식으로 사용하면서 Future, Observerble , Akka 같은것을 적용해서 문제를 해결하는 경우가 훨씬 많을 거라는 얘기죠. 즉 순수FP가 동시성 프로그래밍에 더 좋다는 교과서적인 멘트(광고)에 의해 사람들이 그쪽으로 옮겨갈꺼라 생각하는것은 여러 측면에서 매우 순진한 생각이라 봅니다. 

A님: 

승현님이 하시는 이야기에 저는 많은 부분 동의합니다. 제가 FP 신봉자도 아니고요. 분명한 것은 FP가 어렵다고 하는점에는 동의하지 않는 것은 분명합니다. 

승현님께서 분명히 언급 하셨지만 """순수"""라는 말을 FP 붙이셨는데 순수 FP의 정의를 어떻게 잡느냐는 문제도 있습니다. 뭐 잘 아시겠지만요.

개인적으로 대부분의 사람들이 FP로 갈꺼라고 """전혀""" 생각하지 않습니다. 이는 쉽고 어려움의 문제와는 "크게" 상관이 없다고 생각합니다.. 제가 생각할 때 많은 사람이 그 언어를 쓰려면 재밌고 좋고 파워풀하고 등등등은 일급시민이 아니라고 생각해요. 제가 생각할 때 가장 큰 펙터는 잡마켓이라고 생각합니다. 아직도 저는 생생하게 기억나는데 마켓 시장의 크기가 C++ 보다 JAVA가 좀 작을 때 사람들이 커뮤니티에서 논쟁을 많이 했죠. Java의 안좋은 점을 까면서 Java가 성공하지 못할꺼라고 햇었어요. Java가 C++보다 좋고/나쁘고 쉽고/어렵고를 떠나서 Java 마켓이 C++보다 커졌고 그로 인해 나중에 시작하는 사람들은 자바를 배우고 시작을 하는 사람이 많아졌다고 생각합니다. FP 프로그래머가 많아 지려면 개인적으로는 잡마켓이 커지는게 가장 확실한 방법이라고 생각합니다. 그런 점으로 인해 FP 프로그래머가 다수가 될꺼라고 생각하지 않습니다. 

승현님과 생각을 제가 달리하는 부분은 FP가 어렵냐에 대한 부분인 것같은데. 저는 FP가 꼭 모나드/카테고리 이론 등등의 괴수들을 소환하는 것만이 FP라고 생각하지 않습니다.또한 FP를 하기 위해서 꼭 스칼라를 써야할 필요도 없다고 생각해요. 승현님 언급하신것 처럼 C#에 LINQ나 JAVA의 스트림 또는 얼랭에 영향을 받은 Akka등을 쓰는것도 FP를 하는거라고 생각합니다. 어찌됐건 FP가 장점이 있고 지금 쓰는 언어에서 그 FP에 장점을 얻기위해 펑셔날하게 쓰면 FP를 한다고 말해도 된다고 생각합니다. C#이든 JAVA든 언어가 허락하는 범위 내에서 얼마든지 펑셔날하게 짤 수 있고 그로인해 장점을 얻을수 있는데 굳이 순수형 FP로 넘어가서 FP를 해야될 이유도 모르겠고요. 저는 많은 개발자들이 쉽게 LINQ/Stream을 쓰는데 FP가 어렵다고 주장하는게 맞냐는거죠. 어렵다고 주장하는게 모나드/카테고리 이론등등등 이라면 모를까요.

제가 원하는 건 FP == 모냐드 대마왕 이런 선입견이나 좀 더 FP스러운 언어를 써서 FP 해야한다고 생각하는게 없어졌으면 하는 바램입니다. 자신이 쓰는 언어에서 FP를 통해서 장점을 얻을 수 있으면 그렇게 하면 되는거지 굳이 OOP를 버리고 FP만 고집할 필요도 없고요. 제가 FP 공부를 많이 안하고 FP에 대해 앞 뒤 설명도 없고 컨텍스트는 다날리고 FP 까대는 사람들이 많이 보여서 그런 이야기를 했습니다.

하마:

님과 저의 생각은 거의 일치하는거 같습니다. 기준을 달리 바라봤을뿐... 대중화에 대한 조금 다른 시각의 얘기를 추가해보겠습니다. "C#에 LINQ나 JAVA의 스트림 또는 얼랭에 영향을 받은 Akka등" 언급하셨는데 ..저 또한 언급했구요..이런것들 조차 대중들이 모두 자연스럽게 사용하게 되기까지는 얼마나 걸릴지 모릅니다. 단지 현재 SI 시장에서 Java8 을 안쓰기 때문이기 때문에 이런 말을 하는 것은 아니구요. 만약 Java8가 기본이되도 함수형 스타일을 쓸 까에는 조금 회의적이에요. 아시다시피 페이스북상이나 기타 인터넷상에서는 보통 얼리어댑터의 발언이 셉니다. (물론 저런것이 그렇게 얼리는 아니지만요 ㅎㅎ) 하지만 실제 현업에서는 그니깐 대중적으로는 그게 아니거든요. 이유는 저는 현재 Scala, Python 을 주로 사용하지만 C++도 2000년부터 14년간 사용했습니다. 수십만,수백만의 라인수의 솔루션에 참여도 해봤는데.. 아시다시피 C++ 은 예전부터 Functor 같은것을 제공해왔습니다. 함수형아이디어를 차용해왔다는 말이지요. 하지만 실제 프로젝트에서 그렇게 사용하는 경우는 별로 없었습니다. 거의 제가 주도적으로 적용을 했었는데요. 요즘 모던 C++ 이라고 더 강화되긴했는데 실무에서 대중적으로 받아드리기까지는 얼마나 걸릴지 모르겠습니다. 자바나 스칼라에서의 함수형스타일의 대중화도 얼마나 걸릴지 ....오래걸릴거라 유추됩니다. (어려운 모나트,카테고리이론 얘기하는건 아닙니다) 물론 예전과 다르게 요즘은 열풍이라 좀 더 뜨거워지겠지만요 ㅎㅎ 즉 대중은 for 문을 돌리는것에서 map,filter,reduce 를 사용하는것으로 변화하는것 조차 요원한게 실제 현실이 아닌가 하네요.

위키백과  https://ko.wikipedia.org/wiki/%EC%8A%A4%EC%B9%B4%EB%8B%A4) 

스카다 또는 감시 제어 및 데이터 취득(영어: Supervisory Control And Data Acquisition, SCADA)은 일반적으로 산업 제어 시스템(영어: Industrial Control Systems, ICS), 즉 다음과 같은 산업 공정/기반 시설/설비를 바탕으로 한 작업공정을 감시하고 제어하는 컴퓨터 시스템을 말한다.

스카다 시스템은 일반적으로 다음과 같은 구성 요소를 갖는다.

• 인간-기계 인터페이스(영어: Human-Machine Interface, HMI): 기계 제어에 사용되는 데이터를 인간에게 친숙한 형태로 변환하여 보여주는 장치로, 이것을 통해 관리자가 해당 공정을 감시하고 제어하게 된다.
• 감시 (컴퓨터) 시스템: 프로세스와 관련된 자료를 수집하고, 하드웨어 제어를 위한 실질적인 명령을 내린다.
• 원격 단말기(영어: Remote Terminal Unit, RTU): 공정에 설치된 센서와 직접 연결되며, 여기서 나오는 신호를 컴퓨터가 인식할 수 있는 디지털 데이터로 상호 변환하고, 그 데이터를 감시 시스템에 전달한다.
• 프로그래머블 로직 컨트롤러(영어: Programmable Logic Controller, PLC): 실제 현장에 배치되는 기기로서, 특정 용도를 위해 설계된 원격 단말기(RTU)보다 경제적이고 다목적으로 사용이 가능하다.
• 통신 시설: 제어 시스템, 원격 단말기 등 멀리 떨어져 있는 요소들이 서로 통신할 수 있도록 해준다.
• 다양한 공정과 분석적인 기기 장치

감시와 제어의 차이[편집]

스카다 시스템과 분산 제어 시스템(영어: Distributed Control System, DCS)을 혼동하는 경우가 있다. 일반적으로, 스카다 시스템은 작업 공정을 조직화하는 쪽이며, 실시간으로 공정을 제어하지는 않는다. 하지만, 통신 기술의 발달로 인해 거리상의 제약이 적고 안정적이며 레이턴시가 적고 속도도 빠른 통신이 가능해짐에 따라 실시간 제어에 관한 논의는 다소 모호한 상태가 되었다. 즉, 스카다와 DCS의 차이점으로 언급되던 것들도 대부분 시스템 분류에 따른 의미상의 차이만 남게 되었으며, 실질적인 차이는 무시할 수 있을 정도이다. 통신 기술의 발달 덕분에, 두 시스템간의 차이는 사실상 사라지게 될 것이다.

정리하자면,

• DCS는 공정 기반이지만, SCADA는 데이터 취합 기반이다.
• DCS는 공정 주도 방식으로 동작하지만, SCADA는 사건(이벤트) 주도 방식으로 동작한다.
• DCS는 하나의 현장에서 이루어지는 작업들을 처리하는 데에 주로 사용되고, 스카다는 지리적으로 넓게 분산되는 형태의 응용분야에서 선호된다.

SCADA 시스템이 신기술은 아니지만 체크해본다.

IoT 기반의  신개념 주택단지를 만들때 , 거주민이 집에 도착했을때 자동적으로 차고의 문이 열리고 , 전기충전장치가 자동으로 부착되서 충전시켜주고 , 엘리베이터가 내려와서 문이 열려있는 상황을 연출하고 싶을때, 그 엘리베이터나 전력관리 시스템을 관리할때  스카다가 필요하지 않을까?  아직 잘 모르겠다.  

추가로 읽을꺼리를 링크해본다. IoT 와 SCADA 의 콜라보에 대해서 검색해보니 다음과 같은 자료가 있더라~

Smarter SCADA & The Internet of Things

Evolving from SCADA to IoT

SCADA 와 IoT 의 차이점 

http://jinolog.com/programming/2014/01/31/reducing-page-weight.html 펌

<IfModule mod_expires.c>
ExpiresActive On

<FilesMatch "\.(jpg|jpeg|png|gif|svg)$">
ExpiresDefault "access plus 1 month"
</FilesMatch>

</IfModule>

copy file1.css+file2.css file.css   # Windows
cat file1.css file2.css > file.css  # Mac/Linux

위키참조 : 

JIT 컴파일(just-in-time compilation) 또는 동적 번역(dynamic translation)은 프로그램을 실제 실행하는 시점에
기계어로 번역하는 컴파일 기법이다. 이 기법은 프로그램의 실행 속도를 빠르게 하기 위해 사용된다.

초심자들이 JIT 따위 고려하지 않은 어설픈 벤치마크 코드를 짜놓고 "아 Java 구리네   C만세" 이러는 경우가 간혹 있다.

Python :  일반적으로 CPython 을 말하며  .pyc 바이트코드를 생성하고 C 로 구현된 가상머신에서 인터프리팅함.

PyPy    :  .pyc 바이트코드를 meta-tracing  JIT 컴파일 (머신코드로) 하여 사용함. CPython 보다 4~6배 빠르다고함. 

(참고 : http://j.mearie.org/post/5125952364/why-is-pypy-faster-than-cpython)

Java    :  JDK 1.3 이후  trace based  JIT 도입  (참고 : http://d2.naver.com/helloworld/1230 )

Javascript :  V8  (참고 : http://jayconrod.com/posts/51/a-tour-of-v8-full-compiler )

(V8은 자바스크립트를 바이트코드(bytecode)로 컴파일하거나 인터프리트(interpret)하는 대신 실행하기 전 직접적인 기계어(x86, ARM, 또는 MIPS)로 컴파일(compile)하여 성능을 향상시켰다. 추가적인 속도향상을 위해 인라인 캐싱(inline caching)과 같은 최적화 기법을 적용하였다.) 

"자바는 call by value 입니다."

자바는 객체를 가르키는 레퍼런스라는 개념이 있는것이지, 이게 함수의 매개변수로 넘어갈때는 

call by value 로 넘어갑니다. 즉  레퍼런스 그 자체가 deep copy 되어 넘어갑니다.

언어별 정리

C       :  call by value   ( 포인터 그 자체도 매개변수로 넘어갈때 value  복사됨, clone copy 됨 ) 

C++   : call by value    (  "&  레퍼런스"  일 경우 call by reference , 즉 clone copy 하지 않음 )

Java  : call by value   ( 레퍼런스 그 자체도 매개변수로 넘어갈때 value  복사됨, , clone copy 됨 ) 

C#     : call by value    ( "ref"  키워드 붙으면  call by reference , 즉 clone copy 하지 않음 )

Python : call by value ( python은 모두 객체이기때문에, call by object 라 불리지만, 이 글에서는 이해를쉽게하고자  저렇게 말함, 즉 자바의 객체 레퍼런스를 넘기는것과 동일 효과) 

Javascript : call by value ( 자바,파이썬과  동일) 

마지막으로 reference 의 구체적 정의는 각 언어에서 그것을 사용한 놈 마음이기 때문에 

C++ 을 만든 사람은 그것을 어떻게 차용했는지 알아보려면 아래 링크 보시면 됩니다. ~

https://www3.ntu.edu.sg/home/ehchua/programming/cpp/cp4_PointerReference.html\

http://www.stroustrup.com/C++11FAQ.html#rval

http://caffe.berkeleyvision.org/  : Caffe 홈페이지

http://deeplearning4j.org/compare-dl4j-torch7-pylearn.html : DL4J , Torch, Theano , Caffe 비교글 

* 비전에 특화된 머신-비전 라이브러리.

* Caffe와 DL4J는 둘 다 최신의 ConvNets image classification 알고리즘을 제공하지만, 

  Caffe는 GPU paraellism을 제공하지 않는다.

Caffe 는 잘 알려지고 넓게 사용되는 머신-비전 라이브러리이고 , Matlab 의 fast convolutional nets 을 C/C++  로 포팅하였다. Caffe 는 다른 딥러닝 어플리케이션과는 다르게  문자,음성,타임시리즈데이터를 다루고 있지 않다. Deeplearning4j(DL4J) 와 Caffe 는 둘다 convolutional nets 을 통해 이미지 분류를 수행한다. 하지만 Caffe 와 다르게 DL4J 는 parallel GPU 를 지원한다. 따라서  많은 수의 GPU 클러스터 상에서 병렬적으로 더욱 부드럽게 실행될수있다.  

http://www.kosen21.org/work/03_information/0302_gtbReports/file_download1.jsp?bid=0000000761830&filename=170103.pdf&year=2015

안녕하세요 (_._)  

테크란에 너무 어렵거나, 남에 얘기만 써있는거 같아서..기본이되며 항상 마주치는 주제를 써보려합니다.  객체복사에 관한 글입니다. 언어는 현재  만들고있는 프로젝트에 사용된 C++,JAVA, Javascript ,Python 에 추가적으로 Scala 가 될것이구요. 새로운내용은 아니라 , 복습차원에서 글을 쓰고 자료를 찾아 보았습니다.

* 복제/복사 뚜렷한 구분을 하지 않고  혼용하였습니다.  =  , clone ,  copy , duplicate 의 차이는 개발자 맘이고

중요하게 구분해야할것은  깊은복사/얕은복사의 차이점입니다. 

이런저런 이야기 

작년에 JAVA 로 개발을 시작하고 "Effective Java"  라는 책을 읽으면서 , Item 11 항목을  참 어렵게 읽었던 기억이 있습니다. "clone 오버라이드는 신중히 하자"  뭐 이런거였는데요."사족"  즉 뱀의 다리 잖습니까?   쓸데 없이 엄청 주저리주저리 하시는구만 ..하는 생각이 들었습니다.C++ 로 그 동안 객체복사할때는 그냥 그걸 구현하면 된 것들을 JAVA 에서는 희안하게 구속해 놓았구나..(Object 에 이미 존재하다보니, 좀 신경쓰인다고나 할까? 흰 도화지에 그림을 그리고 싶은데 , 이미 테두리가 그려져있는 그림에 색칠만 칠하는 느낌? ) 뭐 안전장치라고도 볼수있고,편의성 제공이라고도 볼수있고,  길잡이라고도 볼수있겠지요. 좀 과한 길잡이 같지만 ㅎㅎ 여기서 잠깐 길에서 벗어나보면 "인터페이스" 도 그렇다고 볼수있겠습니다.  자바에서는 굳이 "인터페이스" 라는 개념을 실제 문법으로 추가하므로써 좀 더 객체지향이라는 목적지에 잘 도착하도록 안내한다고 볼수있습니다. ( 다중상속을 위해 만든것이다? 아닙니다)  

다시 객체복사 경험담으로  돌아와서 ,제가 C++ 로 개발할때는 clone 더미에서 살았습니다. 
굉장히 많은 부분 clone 이 객체에 관여되있고, 신경써왔는데 자바로 개발하면서부터 별로 객체복사에 대해서 신경쓸 일이 많지 않더군요.물론 언어때문이 아닙니다. 만들었던 솔루션의 목적이 다르기 때문인데요. 과거 C++ 로 작업할땐 무엇 때문이었냐 하면  편집기를 만들었었기 때문입니다.

객체복사(Deep)를 하는 이유는 단순히 ,  " 깨끗한 놈은 그냥 놔두고 ,  더럽히고 싶은 닮은 놈을 만들자 "  입니다. "깨끗한 놈을 , 더럽히지 말고 같이 쓰자" 라면 굳이 객체복사를 할 필요는 없습니다. (객체를 가르키는 참조만 복사하면됨) 그럼 깨끗한놈은 놔두고, 더럽히고 싶은놈을 만들고 싶은 경우를 편집기에서 생각해보면,

                                                                       (그림 - 1)

그림 - 1 은 편집기에서 어떤 속성을 탭 형식으로 보여주고 있습니다. 
저 탭이 하나의 객체라고 치면 (가 : 1.34 , 나 : "okky")  같이 깨끗한 객체를 일단 모셔두고,  그 객체를 복사해서  값을 마구 바꿔보다가 (값을 바꾸는건 사용자겠지요) 바꾸기로 마음먹으면 "저장" 을 눌러서  "복사한 객체" 의 내용을 원본에 덮어쓰고 파일 혹은 DB 에 save 하고,  그냥 안바꾸기로 마음먹었으면 "취소" 를 눌러서 그  "복사한 객체" 를 delete 시켜버리면 깔끔해집니다.Undo, Redo 를 위한 Command 패턴에서도 기억되기위한 객체로 복사해놓을수 있구요. 

객체 복제의 모습들 

객체 복제는 크게 3가지 방식으로 이루어집니다.

                                                                (그림 - 1  레퍼런스 복사)

  -   a 레퍼런스는 A 객체를 가르킵니다. 

  -   a 레퍼런스를 복사해서 a-2 레퍼런스를 만듭니다.

  -   a-2 레퍼런스가 A 객체를 더럽히면 a 레퍼런스도 더렵혀진 A 객체를 사용하게됩니다. 

  -   즉 더럽히지 않을꺼란 보장이 되면 이렇게 복사해도 됩니다. 

  -   더렵혀진 값을 사용해도 된다면 이렇게 해도 됩니다.

  -   더렵혀지기 전의 깨끗한 원본이 필요없다면 이렇게 해도 됩니다.                           

                                                                (그림 - 2  앝은 복사)

  -   a 레퍼런스는 A 객체를 가르킵니다. 

  -   A 객체를 복사해서 a-2 레퍼런스를 통해 가르키게 합니다.  

  -   a 레퍼런스가 A 객체의 값 "1" 을 바꾸어도 a-2 레퍼런스에는 영향이 안미칩니다.

  -   a 레퍼런스가 A 객체 "안의" B 객체를 가르키는 레퍼런스를 통해 B 객체의 "Hi" 를 변경하면
      a-2 레퍼런스에 영향을 미칩니다.

  -   A 객체가 기본형으로만 이루어져있다면 이렇게 복제해도 됩니다. (java 에서는 int, float 이런) 

  -   A 객체 안에 다른 객체를 참조하는것이 들어있다면,  (그림 - 2  레퍼런스 복사) 와 같은 운명        
      에 처합니다.

                                                               (그림 - 3  깊은 복사)

  -   a 레퍼런스는 A 객체를 가르킵니다. 

  -   A 객체를 복제 해서 a-2 레퍼런스를 통해 가르키게 합니다.  

   -  A 객체를 복제 할때 B 객체도 같이 복제합니다.  

  -   a 레퍼런스가 A 객체의 값 "1" 을 바꾸어도 a-2 레퍼런스에는 영향이 안미칩니다.

  -   a 레퍼런스가 B 객체의 값 "Hi" 을 바꾸어도 a-2 레퍼런스에는 영향이 안미칩니다.

  -   이렇게 되면 a-2 레퍼런스가 어떤 짓을 해도 , a  레퍼런스가 가르키는 객체들은 순수함을 잃지        

       않게됩니다.

  -   다만 메모리가 더 소비되며, 객체 복제 비용이 듭니다. 

흠흠 점심시간이네요 ㅜㅜ 

아래에 정리 좀 해두고, 점진적으로 마무리 하겠습니다. 

각 언어에서의 복제도 언어별로 이디엄이 있긴하지만 , 괜히 행사코드라든지, 잡다구리한것들에 의해

그 핵심을 놓쳐서는 안됩니다. 중요한건 깊이 복사하느냐 , 앝게 복사하느냐 일 뿐입니다. 

C++ 에서의 객체 복제

이디엄 :  단순 대입  / 복사 생성자 / 대입 연산자 오버로딩 /  ShallowCopy 와 DeepCopy 함수를 만들기

http://soen.kr/lecture/ccpp/cpp3/26-2-2.htm  (복사생성자: 기초 )

http://soen.kr/lecture/ccpp/cpp3/28-3-3.htm  (대입연산자 오버로딩: 기초) 

http://accu.org/index.php/journals/522  (중급)

JAVA 에서의 객체 복제  

이디엄 :  Object.clone , super.clone() / cloneble 인터페이스 / CloneNotSupportedException

기초 : http://javacan.tistory.com/30   

clone() vs 복사생성자 vs 복사팩토리메소드 

http://stackoverflow.com/questions/1106102/clone-vs-copy-constructor-vs-factory-method

http://www.javacodegeeks.com/2014/01/which-is-better-option-cloning-or-copy-constructors.html

JavaScript  에서의 객체 복제 

이디엄: prototype ,  hasOwnProperty 

http://www.nextree.co.kr/p7323/   (프로토타입 이해) 

http://blog.soulserv.net/understanding-object-cloning-in-javascript-part-i/ (얇은복사)

http://heyjavascript.com/4-creative-ways-to-clone-objects/  (객체 복사 방법 4가지) 

Scala  에서의 객체 복제 

- 추천해주실만한 블로그나 글 있으면 댓글로 공유해주세요

Python 에서의 객체복제

http://kkoseul.tistory.com/m/post/53