Tag Archives: Language

Go 언어 사용 감상 – Generic이 없다는 것…

새로운 언어를 공부할 때 언어별 특성에 따라 다른 접근방법을 사용해야한다.
요즘은 Go언어로 뭘좀 해 보려고 했는데…

언어의 특성 때문에 yaml의 설계마저도 달라져야 한다는 것을 알게 됐다.
(내가 너무 자바스타일로 구조를 잡는건지도 모르겠다

간단한 빌드 툴을 만들면서 아래와 같은 형태의 제네릭 리스트를 yaml로 만들었는데

  • DockerWork
    • Dockerimage
    • Dockerrepo
    • Dockerfile

당연하다는 듯이 제네릭?오브젝트리스트? 형태로 만들어 버렸다.
Go언어를 잘 못해서 그런것일 수도 있는데 뭔가 만들기가 난감하다.
제네릭이 필요했는데 Go언어에는 그게 없었다.
커뮤니티 검색도 좀 해봤는데 generic 지원을 요청하는 이슈가 많았지만
고언어에는 그게 필요없다~ 라는 의견으로 마무리

강타입에 정적타입이면서 generic이 없다니…

위의 문제를 해결할 때
자바 – 제네릭,
파이썬 – 오브젝트리스트
C언어 – !!노개다
Go언어 – !!노가다
아마 다른언어는 다 비슷한 스타일일거다.

Go언어는 C언어에 가까운 해결방법을 찾으라는 것 같다.
python처럼 is type체크를 하고 형변환 없이 사용할 수 있다면 또 모르겠는데..
그게 아니니 더 난감하다.

뭔가 편하고 깔끔한 방법이 있는데 못 찾는건지.. 아마 없을 것 같다.
덕타이핑과 인터페이스 ifelse 떡칠이 답일 것 같다.

말 나온김에 덕타이핑도…
Duck typeing 덕분에 발생하는 복잡함

다음과 같은 코드가 있다면

type Writer interface {
Write(p []byte) (n int, err error)
}


자바할 때 처럼 이 인터페이스의 이름을 찾는다면?
나올수도 있고 안 나올수도 있다.

덕타이핑이라고

구현체 사이에 의존관계가 없기 때문에 레퍼런스 검색이 힘들다
동일한 패턴의 인터페이스를 몽땅 검색해야 되는데
자바 개발을 하던 습관이 남아서 그런지 좀 난감하다.

장점일 수도 있고.. 단점일 수도 있는 이 부분..
상속이 없는 것도 덕타이핑의 일부 특성이라고 봐야할 것 같다

기본 문법도 쉽고 간단한 코드를 만들기도 쉽지만
언어 자체가 쉽다?? 글쎄….
데이터 구조를 다루기 힘든 언어인지 익숙해지지 않아서인지…

고 언어 후기

  • 간단한 코드를 짜기는 쉬울 것 같다.
  • 실행 속도가 빠르다? 글쎄…
  • 실행파일을 만들어서 설치하기 쉽다

[도서] 해커와 화가 – 비아웹?? 창업자의 글 모음

비아웹.. 야후에 팔렸다는데 잘 모르겠다.
비싸게 팔렸겠지?

성공한 벤처기업인이라 그런지… 아니면 이런 사람이라 성공한 사업가가 될 수 있었던건지.. 
경제인의 시야를 가지고 있다. 공돌이가 아닌

근원적인 가치를 부로 정의하고 영어로는 wealth라고 썼을래나..
money,화폐,돈과 구분해서 생각할 줄 아는

나는 에너지와 혁신을 경제발전의 근원?으로 보고 있었는데 나만 그런건 아니었나 싶다.
미국에는 이런 생각을 가진 사람이 많은건가

리습

  1. 조건문conditional – if then else
  2. 함수의 타입function type – 함수도 변수처럼 타입
  3. 재귀 recursion
  4. 동적 타이핑 dynamic typing – 모든변수는 궁극적으로 포인터, 변수가 아니라 값, 변수 할당은포인터 자체를 복사
  5. 가비지 컬렉션 garbage collection
  6. 표현으로 이루어진 프로그램 
  7. 심볼 타입 symbol type – 문자열을 가리키는 포인터
  8. 심볼과 상수의 트리를 이용하는 코드를 위한 표기 방식 notation 
  9. 언어 전체를 계속 사용할 수 있음 – 읽는시간, 컴파일하는시간, 실행시간에 대한 구분이 없어서 동시에 실행 가능

매크로.. 뭔지 이해가..

리습존니짱. 개좋아.

lisp계열 clojure는 몇번이나 도전을 했는데… 중도포기의 연속..

요즘 시간을 내서 작은 모듈이라도 만들어보려고 하는데 잘 될까?

코틀린Kotlin에서 자바 인터페이스 getter 처리

문제의 getter를 포함한 UserDetails 인터페이스

interface UserDetails {
  fun getUsername(): String
}

자바에서의 처리

public class User implements UserDetails {
  @Getter
  private String username;
}

코틀린Kotlin에서의 처리

1.

class User : UserDetails {
  constructor(username:String){
    this.username = username
  }
  override fun getUsername() = username
  val username: String = getUsername
  @JvmName("getUsername_") get() = username
}

2.

class User : UserDetails {
  constructor(username: String){
    this.username = username  
  }
  private val username: String
  override fun getUsername() = username
}

3. 이게 제일 깔끔하고 알아보기 편하다.

class User(val username: String) : UserDetails {
  override fun getUsername() = username
}

상황에 따라 1,2번을 써야하는 경우가 있기는 할까

Kotlin 한 6개월 사용후기

문법적으로 기존 언어에 비해 많이 이질적이지 않고 받아들일만 했다.

구글에서 안드로이드 공식언어로 지정, 인텔리J의 젯브레인에서 개발, 스프링 진영에서도 지원된다고 하고…

별 문제가 없을 줄 알았는데… 이게 웬걸

  • JPA Entity 설계가 안되는건 아닌데 힘들었다.
    data class로 설계한다고도 하던데…. 기본값을 일일이 지정해줘야하는것도 불편하고… 이건 빠르게 포기하고 domain 모듈은 자바로 변경해서 작업해가지고 뭐가 더 안되는지도 모르겠다.
  • QueryDSL 안된다. 안됐었다. 지금은 모르겠다.
  • Validation. 힘들었지만 하긴했다. 다 되긴되더라
    @Field.NotNull
    val name:String
  • Annotation 넣을때.. 안되는건 아닌데 뭔가 괴상하다.
    이런형태에서 @Annotations(arrayOf(Annotation, Annotation))
    이것도 지원되기 시작 @Annotations([Annotation, Annotation])
  • Gradle kotlin 버전과 intellij plugin 버전이 안맞으면 아예 먹통이 된다.

이래저래 몇번 쓰다보니 익숙해지긴 했다.

위의 과정에서 제대로 된 해결책을 찾기가 힘들다는게 문제..

그리고 자꾸 변한다는것도 문제랄까… 좋아지니까 좋은건가

객체지향의 기본 구조 .. to_string — from_string …..되면 좋겠다.

toString의 구현… 객체지향 언어에는 보통 다 존재하는 이 메서드…

사람이 인지할 수 있는것은 어떤 패턴… 그림으로는 의미를 나타내기 힘들기 때문에 toImage보다는 toString를 사용하는 것 같다.
객체지향 언어에서는 struct(구조체)의 역할을 대신하기도 하니까.. 데이터를 담고있는 객체의 toString의 역할은 더욱 중요하다. 객체의 중요한 데이터를 모두 뽑아내 보여주는 역할….

사람이 뭔가를 인식하는 것은 결국에는 문자열이기 때문에… 디버깅시에도 중요하게 사용된다.

toString를 사용하는 경우는 보통 두가지다.
1. 객체내의 중요 데이터를 보여주는 역할
2. 객체내의 모든 데이터를 보여주는 역할…

1번은 보통… 데이터 출력시에 사용되고… 일반적으로 이 구현을 사용한다.
2번은 이클립스나 롬복을 이용해 자동으로 생성된 코드일 경우….

fromString의 구현을 위해서는 1번과 2번을 구분할 필요가 있다.
1번은 완성되지 않은 형태의 데이터를 출력하게 되고 2번은 객체 복원을 위한 객체스트링이 된다.
2번은 직렬화랑 비슷한 개념이 될까…? (같은건가? 직려로하 그 자체인가? 개념이 좀 부족한듯..차후 추가변경) 현재 객체 생성 및 구현시에 막무가내로 사용되고 있는 toString포멧의 표준화가 좀 필요할 것 같다. json형태의 출력이라던가….

이 부분에 대한 표준이 잘 잡히게 되면 언어간 제한없이 더 쉽게 RPC콜이 가능해질 것 같다.
아니면 그냥 이것들을 구현해놓고 상속해서 사용하게 하면… 간단하게 RPC를 만들 수 있지 않을까… 뭐 그렇다고 이걸 만들 시간은 없고 이미 RPC프레임워크들이 많아서 그냥 갖다쓸거지만