Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

JS1K 2013

Name: Anonymous 2013-03-18 17:49

http://js1k.com/
Post submissions, code golfing, and pointless shitposts ITT.

Name: Rabbi Chaim Goldstein 2013-03-18 17:50

Let me get my Torah ready.

Name: Anonymous 2013-03-18 17:54

Yes, yes, good goyim. Stimulating them to use the language of G-d's chosen, so they can make money for us.

Name: Anonymous 2013-03-18 19:47

Epic bumping of dead threads, bro.

Name: Anonymous 2013-03-18 23:50

http://js1k.com/2013-spring/rules

All submissions must not be bigger than 1k
1k means 1024 bytes. Note that we're not counting in characters. JavaScript uses 16bit unicode values internally. The server will enforce this restriction and reject your submission if you try anyways.

Does that mean you only have 512 characters to work with, or am I missing something?

Name: Anonymous 2013-03-19 0:14

>>5
Idiots haven't heard of UTF-8 or UTF-32 yet?
There's really no valid reason to use UTF-16 for anything, ever.

Name: Anonymous 2013-03-19 0:20

>>6
Backwards compatibility. A lot of popular software was designed before it was obvious that UTF-16 wasn't going to cut it ("why would we ever need more than 64k code-points?"), and they can't switch to UTF-8 without breaking other people's code.

Consider this: If the browser developers could just say "from today onward, Javascript is going to use UTF-8," you wouldn't have to program in Javascript right now.

Name: Anonymous 2013-03-19 0:21

>>6
99% of the world's usage can be served by UTF-16. People that need the space provided by UTF-32 are specialists in their work or people that are going to be learning their country's official language.

Name: Anonymous 2013-03-19 1:29

>>8
100% of the world's usage can be served by UTF-8 and it's simpler than UTF-16. UTF-32 is the simplest to work with, and if you can't afford the space for it, UTF-8 is simpler and takes up less space than UTF-16.

Name: Anonymous 2013-03-19 1:35

>>9
Here is a man who hates UTF-16: http://benlynn.blogspot.ca/2011/02/utf-8-good-utf-16-bad_07.html

Enjoy!

Name: Anonymous 2013-03-19 2:16

>>10
Cool, now I've learned something good.

Name: Anonymous 2013-03-19 8:59

Java is the new COBOL.
JavaScript is the new Perl.

Name: Anonymous 2013-03-19 9:18

JavaScript uses 16bit unicode values internally
[aa][b][i]HAHAHAHAHAHAHAHAH[sup]AHAHAHAHAHAHAHAHAH[sup]AHAHAAHAHAHAHAHAAHAHAHAHAHAHAHAHAHA[/i][/b][/aa]

Name: Anonymous 2013-03-19 9:31

JS's use of utf-16 effectively halves the space made available by DOM storage.

Name: Anonymous 2013-03-19 10:31

>>9
100% of the world's usage can be served by UTF-4 and it's simpler than UTF-8. UTF-32 is the simplest to work with, and if you can't afford the space for it, UTF-4 is simpler and takes up less space than UTF-8.

Name: Anonymous 2013-03-19 12:05

>>15
what is this UTF-4 you speak of?

Name: Anonymous 2013-03-19 15:19

>>15
100% of the world's usage can be served by UTF-2 and it's simpler than UTF-4. UTF-32 is the simplest to work with, and if you can't afford the space for it, UTF-2 is simpler and takes up less space than UTF-4.

>>16
four-bit UTF

Name: Anonymous 2013-03-19 16:29

>>17
200% of the world's usage can be served by UTF-1 and it's simpler than UTF-2. UTF-64 is the simplest to work with, and if you can't afford the space for it, UTF-1 is simpler and takes up less space than UTF-2.

Name: Anonymous 2013-03-19 17:12

>>18
∞% of the world's usage can be served by UTF-0 and it's simpler than UTF-1. UTF-128 is the simplest to work with, and if you can't afford the space for it, UTF-0 is simpler and takes up less space than UTF-1.

Name: Anonymous 2013-03-19 17:22

>>13
the average /prog/ shitposter uses bbcode correctly
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAAHAHAHAHAHAHAHAHAHA

Name: Anonymous 2013-03-19 17:49

>>20
Oh yes, that is so.

Name: Anonymous 2013-03-19 17:52

ASCII dubz

Name: Anonymous 2013-03-19 17:54

>>10
UTF-16 is a variable-length encoding, and hence not much simpler than UTF-8
It is very much simpler handling either 2 or 4-byte characters only, compared to 1, 2, 3, or 4 for UTF-8.
As for the second: consider HTML
HTML is not the only form of text there is.
The encoding is inflexible
In 20+ years only ~10% of the whole code space has been assigned. 1.1M characters is plenty already.
Ugly encoding
Subjective. As if UTF-8's multiple shifts and compares are any better?

Here is someone who has written UTF-8 and UTF-16 codecs, so I have first-hand experience that UTF-8 encoding is more complex than UTF-16.

Name: Anonymous 2013-03-19 18:15

>>23
Here is someone who has written UTF-8 and UTF-16 codecs, so I have first-hand experience that UTF-8 encoding is simpler than UTF-16.

Name: Anonymous 2013-03-19 18:15

Sites like wtfjs.com bring back c64 and Atari memories, when people hacked undocumented hardware features to produce cool effects. And js1k.com is the new demoscene!

JavaScript is truly an assembly language.

Name: Anonymous 2013-03-19 18:20

Sites like wtfsymta.com bring back c64 and Atari memories, when people hacked undocumented hardware features to produce cool effects. And symta1k.com is the new demoscene!

Symta is truly an assembly language.

Name: Anonymous 2013-03-19 18:46

Why would I code-golf JS when I can do it in a better language?
And 1K? Isn't that quite a lot? Is JS really that verbose?

Name: Anonymous 2013-03-19 18:48

>>27
It's actually 0.5K, because the morons running it can't figure out UTF-8.

Name: Anonymous 2013-03-19 18:51

>>28
can you gzip the code?

Name: Anonymous 2013-03-19 19:41

>>29
Only if the decompression algorithm is included in the code

Name: Anonymous 2013-03-19 20:36

>>27
JS is extremely verbose.
JavaShit:
function(x){ return x + 10; }
Scheme:
(lambda (x) (+ x 10))
Haskell:
(+ 10)

Name: Anonymous 2013-03-19 20:49

Symta:
.

Name: Anonymous 2013-03-19 21:06

dubs

Name: Anonymous 2013-03-19 21:27

>>32
Symta: ?+10 or (X=X+10)

Name: Anonymous 2013-03-19 22:33

>>31 that is a silly example.. also function needs a name

Name: Anonymous 2013-03-19 22:40

...verbose = readable? / less need for comments all through the code

Name: Anonymous 2013-03-19 22:52

>>35
function needs a name
HA HA HA, OH WOW!

Name: Anonymous 2013-03-20 1:02

>>37 well, i like to be able to call my functions.. don't you?

Name: Anonymous 2013-03-20 1:16

>>31
ten(X, Y):- Y is X + 10.

Name: L. Arthur Calculus 2013-03-20 1:22

>>38
No, in fact, none of my programs use function names.

Name: Anonymous 2013-03-20 1:45

>>40 i'd be inclined to think that they are both not very complicated, and not very readable... or at least 1/2

Name: Anonymous 2013-03-20 2:07

>>41
Have you read your SICP today?

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2013-03-20 9:04

>>10,23,24
http://clang.llvm.org/doxygen/ConvertUTF_8c_source.html

Converting UTF-16 to UTF-32 is one 53 lines function (somewhat bloated, but it's consistent with the others in this file.)
Converting UTF-8 to UTF-32 is a 58 lines function + 23 lines auxillary function + 256-bytes table + 24-bytes table.

Converting UTF-32 to UTF-16 is one 45 lines function.
Converting UTF-32 to UTF-8 is a 49 lines function + 7 bytes table.

Total code to handle UTF-16: 98 lines of functions
Total code to handle UTF-8: 130 lines of functions + 287 bytes table

Now that there's evidence, we can have no more bitching about the complexity of UTF-16.

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2013-03-20 9:08

Now if your text is mostly ASCII then the 50% data size outweighs the codec complexity, but if it's CJK then you get the additional complexity of UTF-8 plus 50% expansion of the data. Different encodings have their uses.

Name: Anonymous 2013-03-20 13:55

ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS
ADRIA RICHARDS FUCKING SLUT FILTHY JEWESS WHO LOVES NIGGER COCKS

Name: Anonymous 2013-03-20 14:46

>>43
That doesn't say anything at all. The 256-byte table, for instance, is quite clearly in lieu of an integer log2 operation.
You can't make any assumptions based on one single implementation. If you could, based on that logic, if I showed you a system with hardware utf8 conversion but only a Java program for utf16, you'd have to concede that utf8 was better.

IHBT.

Name: Anonymous 2013-03-20 16:24

utf8 has one huge problem: it has O(n) access time, while plain ASCII has O(1)

Name: Anonymous 2013-03-20 16:30

>>47
http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00122.html
The simplest solution is to break the stringbuf into chunks, where each
chunk holds exactly CHUNK_SIZE characters, except for the last chunk
which might have fewer.  To find a character at index i, we scan forward
(i % CHUNK_SIZE) characters from the beginning of chunk[i / CHUNK_SIZE].
Ideally, CHUNK_SIZE is a power of 2, which allows us to use bitwise
operations instead of division.  The number of characters to scan is
bounded by CHUNK_SIZE, and therefore takes O(1) time.

String-set! in general requires us to resize a chunk.  Although chunks
contain a constant number of characters, that of course maps to a
variable number of bytes.  There are various tricks we can do to reduce
the number of reallocations done, but even in the worse case, the time
spent is bounded by CHUNK_SIZE, and thus O(1).

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2013-03-22 4:27

>>46
Even without the table the UTF-8 decode/encode requires more code. It's fundamentally more complex as there are more cases.
You can't make any assumptions based on one single implementation.
This is not an assumption. It is a comparison of a UTF-8 and UTF-16 decode/encode implementation in one project, so the two will have been written in the same style and with the same standards.

if I showed you a system with hardware utf8 conversion but only a Java program for utf16, you'd have to concede that utf8 was better.
Wrong. UTF-8 is better for some applications, UTF-16 for others. UTF-8 evangelism is stupid. That's all.

Name: Anonymous 2013-03-22 9:16

Why use any of the UTF when there's SJIS which is far more efficient for encoding Japanese web pages?
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -