sklogic

16 ms·

121.
by sklogic 10y ago
Just wait for all the boring parts of programming to be automated. Then it is likely thay we'll have enough or more than enough programmers.
122.
by sklogic 10y ago
Yet, this limit is far higher than most people tend to think.
123.
by sklogic 10y ago
You cannot avoid using all those convoluted, unnecessary layers in many cases, even if you really want to. In JVM you're confined right on a top of a horrible pyramid. And in web it's even worse.
124.
by sklogic 10y ago
Thanks, did not notice the XML sources. Looks like it must be possible to produce a decent PDF with some effort.
125.
by sklogic 10y ago
This is among very few exceptions. Most of the books are still proper books (no matter if they're also available as e-books). Most of the stuff people use for learning online is far below a book quality.
126.
by sklogic 10y ago
The funny part here is that in many cases it is still far easier to build stuff from scratch than to glue someone else's poorly documented shit together.
127.
by sklogic 10y ago
Browser as it is now is a stupid and unnecessary abstraction. Even a humble Tcl interpreter running in a sandbox would have been many times better than all that thick client browsers.
128.
by sklogic 10y ago
Documentation should not suffer from frequent changes. It is easy to keep docstrings in sync with the implementation, they should both be visible at the same moment. Also, if 99.9% of all those "web frameworks" just die without a
129.
by sklogic 10y ago
Good luck bypassing the unnecessary layers if your code have to run in a browser . Which is exactly an example of such an unnecessary layer (dozens of layers, actually). And JVM is not any better.
130.
by sklogic 10y ago
They tend to be very different kinds of books. A comprehensive, deep printed textbook vs. what is essentially nothing more than a tutorial or a collection of practical recipes.
131.
by sklogic 10y ago
> more accessible and easily searchable Have not seen more easily searchable documentation than the DEC HELP system. > Many programmers have never bought or own a book related to programming And it's very sad. > - they learned
132.
by sklogic 10y ago
If all the library developers were forced to work 80% of their time offline, things would definitely improve.
133.
by sklogic 10y ago
> Stack Overflow Even in this thread people suggested to write documentation straight there. It is an extremely worrying trend. > how has any webdeveloper has managed to stay sane during the last decade Did any of them really manage
134.
by sklogic 10y ago
Well, I sad "quality" software. There is no quality whatsoever in the web frontend, unfortunately. Piles upon piles of an overengineered convoluted mess, but no "quality" code which can be even distantly compared to the
135.
by sklogic 10y ago
Far better solution is to supply documentation with a library. Also, there are such things as docstrings and literate programming. Also, there are still areas where you can be pretty much on your own and do not use any external libraries.
136.
by sklogic 10y ago
Internet is dark and full of stupidity. It is weird to expect it to feed you with a refined collective wisdom. There are far better places full of knowledge. You know, good ol' libraries.
137.
by sklogic 10y ago
You know, quality software comes with local documentation. Some even with a printed documentation. You do not need internet for those.
138.
by sklogic 10y ago
I would not say coding is more fun today. There is more stuff available, true, but the quality of documentation is abysmal compared to what we used to have before. Also, far more needless layers in between hardware and your code. It is an
139.
by sklogic 10y ago
This is not an assertion, it is a practical observation.
140.
by sklogic 10y ago
By interpreters here I mean this kind: https://news.ycombinator.com/item?id=11755303 I.e., an ad hoc AST-level interpretation, flat VM interpreters, tracing JITs, etc.
141.
by sklogic 10y ago
Yes, you're right - did not even notice MPC in the list, was commenting on Yacc and alike.
142.
by sklogic 10y ago
As I said, in such a case RC would behave even worse.
143.
by sklogic 10y ago
> During that collection your program is running and allocating, but runs out of space, so it grinds to a halt. It's a marginal case that should never happen, just like the case of running out of memory altogether. And RC will behav
144.
by sklogic 10y ago
> You'll eventually sweep That's the key here. Eventually. When it is convenient to do so. You have a very fine grained control over when sweeper process may do its dirty job. It's far more complicated with RC to ensure th
145.
by sklogic 10y ago
> until it does How exactly? > grinds to a halt for several seconds What? Stop-the-world in the realtime collectors is always for a set duration, only to scan the registers and tops of the stacks (if there are any stacks at all, sta
146.
by sklogic 10y ago
Which makes it already far too complicated, more complex than a real time mark&sweep. Especially if there are loop checks - you cannot just empty the queue gradually, it's all or nothing.
147.
by sklogic 10y ago
Why do you even care about the GC epoch length? It does not affect the mutator performance at all. EDIT: actually, it does a bit: the longer the epoch, the better, because at the end of the epoch a short stop-the-world is required to collec
148.
by sklogic 10y ago
Think of all the functional languages, this is the most common memory access pattern there. And C++ and alikes are well known for facilitating hilarious levels of memory fragmentation, no matter how smart your custom allocators are.
149.
by sklogic 10y ago
It is really hard to get real time guarantees with RC - given that time for cleaning up depends on a size of a structure. Just imagine it freeing a 10Gb linked list. Real time pure mark and sweep GCs are easier.
150.
by sklogic 10y ago
Reference counting is never fast. Even on a single core.

More ›