오늘도 끄적끄적

느리더라도 꾸준하게

이 글은 자바와 자바스크립트를 혼동하는 사람, 차이점이 궁금한 사람 등을 위하여 쓴 글입니다.
또한 자바스크립트는 다른 언어에 비해 어떤 단점이 있으며 그 단점들을 어떻게 극복해야할지에 대해 다뤄봤습니다.

하고 싶은 말 세 줄 요약.

  1. 자바스크립트 !== 자바(자바 != 자바스크립트), 자바와 자바스크립트는 같지 않다.
    두 언어 간에는 접점이 크지 않고, 자바스크립트는 자바의 인기에 편승할 목적(마케팅 목적)으로 이름을 지은 것 뿐입니다.
  2. 자바 커뮤니티 가서 자바스크립트 질문하거나 자바스크립트 커뮤니티 가서 자바 질문을 하는 건 자제해주세요.
    하지 말라는 건 아닌데 질문자 분께서 원하시는 답(틀린 답을 얻을 수도 있고), 양질의 답을 얻을 가능성, 그리고 빠른 응답을 받기가 힘드실 수 있습니다.
  3. 제발 자바 스크립트(Java Script)라고 적어서 혼란을 초래하지 말아주세요.
    제발 제발 부탁드립니다. 가끔 보면 화(…)가 날 때도 있습니다.
    위와 같이 쓰시는 분들 때문에 이런 혼란이 더 초래되는 것 같습니다.
    새로 배우시는 분들께 잘못된 인식을 심어주는 것도 굉장히 위험하다고 보니 제발 부탁드리겠습니다.

목차

더 읽어보기 »

이 포스트는 제가 다년간 자바스크립트를 설렁 설렁 공부하다 작년 1년동안 빡시게 공부해온 경험을 토대로 작성한 글입니다.
따라서 이 글을 읽으시는 분들께서는 본인과 맞지 않는 부분도 존재할 수 있으니 그 점은 참고하고 적절한 필터링을 하시면 되겠습니다.

목차

들어가기에 앞서

더 읽어보기 »

자알쓰란?

바스크립트 자. (잘 쓰자는 의미도 담겨있다.)
자바스크립트라는 언어 자체는 내 기준에서는 설계 상 미스가 참 많다.
함수 단위의 스코프, 호이스팅, 동적 타입 등등
자바와 같은 깐깐(?)한 언어를 배우고 바라본 자스는 허점 투성이처럼 보였다.
애초에 자바스크립트는 어떠한 프로그램을 만들기 위해서 탄생했다기 보다는
웹 페이지에 입력값에 대한 유효성 검사(데이터가 공란인지 아닌지 등등)와 같은
페이지의 동적 제어가 주된 목적 + 짧은 개발 기간(넷 스케이프 사의 새로운 브라우저에 탑재 예정) 때문에
설계 상에 미스가 있을 수 밖에 없다고 나는 생각된다.
일종의 안전 장치가 없어서 개발자가 일일이 구현해주고, 신경써야 하는 느낌이었다.
그렇다고 해서 자바스크립트를 극혐하거나 그런 것은 아니고 매우 사랑한다.
또한 그 허점을 아는 사람은 허점을 보완해서 요리조리 피해서 잘 쓰겠지만…
잘 모르는 부분들은 잘못 써도 동작이 잘 되기 마련이다.
이는 지금 당장에는 큰 문제가 안 될지 모르겠지만, 추후에 대규모 웹 어플리케이션을 만들거나
직면할 문제로부터 미리 해방시키기 위해 처음부터 좋은 습관을 들여가는 것이 좋다고 생각한다.
그 열 세 번째 시리즈는 클로저를 주제로 진행하겠다.

들어가기 전에

프로그래밍 언어에는 지역 변수란 게 존재한다.
이 지역변수는 변수의 스코프에 의존적이다.
여타 프로그맹 언어에서 변수의 스코프는 {} 블록 단위지만,
자바스크립트의 변수의 스코프는 함수 단위이다. (물론 ES6의 const와 let의 스코프는 블록 단위)

더 읽어보기 »

자알쓰란?

바스크립트 자. (잘 쓰자는 의미도 담겨있다.)
자바스크립트라는 언어 자체는 내 기준에서는 설계 상 미스가 참 많다.
함수 단위의 스코프, 호이스팅, 동적 타입 등등
자바와 같은 깐깐(?)한 언어를 배우고 바라본 자스는 허점 투성이처럼 보였다.
애초에 자바스크립트는 어떠한 프로그램을 만들기 위해서 탄생했다기 보다는
웹 페이지에 입력값에 대한 유효성 검사(데이터가 공란인지 아닌지 등등)와 같은
페이지의 동적 제어가 주된 목적 + 짧은 개발 기간(넷 스케이프 사의 새로운 브라우저에 탑재 예정) 때문에
설계 상에 미스가 있을 수 밖에 없다고 나는 생각된다.
일종의 안전 장치가 없어서 개발자가 일일이 구현해주고, 신경써야 하는 느낌이었다.
그렇다고 해서 자바스크립트를 극혐하거나 그런 것은 아니고 매우 사랑한다.
또한 그 허점을 아는 사람은 허점을 보완해서 요리조리 피해서 잘 쓰겠지만…
잘 모르는 부분들은 잘못 써도 동작이 잘 되기 마련이다.
이는 지금 당장에는 큰 문제가 안 될지 모르겠지만, 추후에 대규모 웹 어플리케이션을 만들거나
직면할 문제로부터 미리 해방시키기 위해 처음부터 좋은 습관을 들여가는 것이 좋다고 생각한다.
이번에는 쉬어가는 타임으로 번외편 격인 JIT 컴파일에 대해 간단히 다뤄보았다.

자바스크립트는 인터스크립트 언어이다?

책을 보면 위와 같이 말하는 경우가 존재한다.
인터스크립트가 뭔데?에서 부터 막힌다면 아래 내용을 봐보자.

더 읽어보기 »

기본적으로 컴퓨터는 기계어(2진수(0과 1)로 이루어진 코드) 밖에 해석하지 못한다.
바보 녀석 ㅎㅎ
왜 10진수가 아닌 2진수를 사용하게 됐는지 궁금한 사람은 컴퓨터에서 2진수, 8진수, 16진수를 쓰게 된 이유를 참고하자.

따라서 우리는 우리가 짠 코드를 기계어로 바꾸는 행위를 해야한다.

우리의 뇌는 이렇게 좋지도 않고, 효율성 측면에서 이러한 행위를 도와주는 도구가 세 가지가 있다.

더 읽어보기 »

여러 책을 보고 혼자서 내린 결론이기 때문에 틀릴 가능성이 있으니 지적해주면 감사하겠습니다 ^^

최초의 컴퓨터는 10진수를 사용했다.

나는 처음부터 2진수를 사용한 줄 알았는데 최초의 컴퓨터인 에니악은 10진수를 사용했다고 한다.
아마도 우리의 손가락이 10개이고 평상시에 연산을 할 때도 10진수를 주로 사용하기 때문에 익숙해서 10진수를 사용했던 게 아닐까?

그럼 왜 컴퓨터는 2진수를 사용하게 됐을까?

더 읽어보기 »

과거에는 1byte가 7bit, 9bit 등등이던 시절이 있다고 하지만 현재는 8비트로 거의 표준이 된 것 같다.
왜일까?
이 포스트는 아래 링크를 참조하여 제 머릿 속을 바탕으로 글을 썼기 때문에 틀린 점이 있다면 댓글로 적어주길 바랍니다~

컴퓨터는 미국에서 개발했다.

따라서 미국 특화(+유럽권과의 통신 등등을 고려하여 유렵권까지 특화)해서 만들었다.
따라서 아시아나 아프리카 등등에는 별로 특화돼있지 않았다. (지금은 많이 완화된 것 같지만…)
1byte의 bit 수를 결정 짓는 결정적인 요인은 아마 ASCII라는 문자 인코딩 때문일 것이다.
ASCII는 미국권 문자를 표현하는 문자 인코딩(문자의 집합)인데 통신을 위한 기호와 특수기호 + 숫자 + 알파벳 대소문자를 표현할 수 있다.
당연히 미국에서 개발했으니 미국에서 쓰이는 문자만 표현하면 되는 것이었다.
이 ASCII를 표현하는데는 7bit(128자)로 충분했고, 이 ASCII를 베이스로 byte(하나의 문자를 담는 단위)가 결정된 게 아닐까 싶다.

더 읽어보기 »

큐는 스택과 반대로 선입선출(FIFO, First In First Out)의 구조를 가지는 자료구조이다.
먼저 들어온 놈이 먼저 나가는 구조이니 입력 순서에 따른 처리를 위한 자료에서 많이 사용한다. (OS의 프로세스 스케쥴링)
스택과 비교해보면 push 대신에 offer, pop 대신에 offer를 메소드를 사용한다.

만들어보자!

기본적으로 큐를 만들어보기 전에 먼저 링크드리스트에 대해 알아야한다.
기존에 스택처럼 생각했을 때 두 가지 데이터를 들고 있어야했다.

  1. 인덱스(몇 번째에 데이터를 삽입하고 뽑아낼지)
  2. 실제 데이터 덩어리
    이 경우에는 데이터를 기존의 스택 크기보다 많이 삽입했을 때만 복사가 이루어졌다.
    하지만 큐의 경우에는 스택과 같이 두 개의 데이터만 들고 있다고 가정했을 때
    데이터를 기존의 스택 크기보다 많이 삽입했을 때만 복사가 이루어지는 건 당연하고,
    데이터를 꺼낼 때 처음 인덱스의 데이터를 꺼내야하는데 그렇게 되면 이가 빠진 것처럼 왼쪽이 비기 때문에 전부 한 칸씩 땡겨야한다.
    즉, 데이터를 삽입/삭제(추출?) 할 때 모두 큰 비용을 들이게 된다.
    따라서 큐를 구현할 때는 스택에서 출발할 게 아니라 링크드리스트에서 출발을 해야한다.
    링크드리스트의 구조 대로 구현하면 삽입/삭제가 용이하기 때문이다.
더 읽어보기 »

List는 데이터를 순차적으로 저장하므로 선형 구조(한 줄로 계속 되며, 데이터가 끊어지지 않음)이다.
또한 여기서 말하는 노드는 하나의 데이터 덩어리라고 보면 될 것 같다.

LinkedList란…?

LinkedList는 스택의 다음과 같은 단점을 극복하고자 만들어졌다.

  • 노드의 끝 부분을 제외한 곳에 데이터 삽입
    스택은 끝 부분에만 데이터를 삽입할 수 있으므로 중간에 데이터를 삽입할 방법이 존재하지 않았다.
    LinkedList는 배열의 이러한 단점을 노드(배열의 각 요소)가 다음 주소지를 알게 함으로써 그 단점을 극복하였다.
더 읽어보기 »
0%