Let’s say we want to some integers from a file. Well, we can’t use InputStream directly, but we can use FileInputStream, a class which inherits directly from InputStream. Unfortunately, FileInputStream doesn’t do any buffering. So if we want to do a lot of small reads, it may not be very efficient, because each of those reads will turn into a syscall.
Well, that’s no problem; we can use BufferedInputStream. BufferedInputStream extends FilterInputStream, which wraps one input stream in another input stream. In the case of BufferedInputStream, the outer stream does buffering.
However, we still do have a problem. BufferedInputStream doesn’t let us read integers; it only lets us read bytes and arrays of bytes. In order to get something that reads integers, we need another wrapper: DataInputStream.
So far our program looks like this:
FileInputStream fos = new FileInputStream("myfile"); BufferedInputStream bos = new BufferedInputStream(fos, 16384); DataInputStream dos = new DataInputStream(bos); int foo = dos.readInt();
Well, it might be a little verbose, but at least it’s safe, right? We know that whatever operation we call on our InputStream will be well-supported.
Well… not quite. One operation defined by InputStream, mark, is only supported by some InputStreams, and not others. It so happens that FileInputStream doesn’t support it (and will misbehave at runtime if you try to use it). BufferedInputStream does. Our DataInputStream does, but only because it wraps our BufferedInputStream– DataInputStream itself does not support mark.
(read the rest here)
Most computers today, for all of their potential speed, are largely a mistake, based on the provenly unscalable Von Neumann architecture, controlled with one of the most shortsighted languages of all time, x86 assembly. They are almost unfathomably inefficient. Their processors have close to a billion transistors, most of which sit idle while a tiny fraction of a fraction of them perform some operation. Three quarters of a processor may be devoted to the quagmire of cache memory and its demands. All of this brute force horsepower gets stacked in an ever higher tower of babel in the relentless race to perform more sequential calculations per second. If people only know what engineering was required to implement branch prediction and 20 stage deep pipelines… It’s like seeing being the walls of a meat packing plant. You just don’t want to know.
People want to get high paying software jobs, powerfully impact the world for good, and just work 40 hours a week. It doesn’t work like this.
My point is that the syntax is the easy part of learning a new language, just look it up in the manual. It is learning the semantics of the new language and how to use it efficiently to solve your problems which are the major difficulties. How do I structure my solution to best make use of the language and its environment? This is where major rethinks will occur. This is what takes time to learn and understand. Not in what it looks like.
There has been a vehicle anomaly,” Orbital Sciences, the contractor supplying the rocket, said on its Twitter feed. It added later in a statement, “The vehicle suffered a catastrophic failure.
The sad fact is that the sheer number and diversity of languages, tools, frameworks, and platforms available to developers today is incredibly daunting. Of course nobody wants to admit this. Everybody wants to pretend to be a master/mistress of all trades. But the truth is that we all suffer from the stigma of Developaralysis.
- Reading is more important than writing
- code should be a joy to read
- the language should not hide what is happening
- code should do what it seems to do
- Simplicity matters
- a clear semantic model greatly boosts readability
- every “good” feature adds more “bad” weight
- sometimes it is best to leave things out
Why do you think Uber is an “innovation”? It’s simply an unregulated, unsafe and uninsured taxi service. It’s just like those illegal scalpers offering rides in any airport, except with a smartphone app.