Cuttings

Java Almost Requires An IDE

noreply@blogger.com (X) — Thu, 04 Jan 2018 15:22:00 +0000

An IDE as an-almost compulsory requirement is not a particularly desirable language trait.

I use PyCharm and Sublime Text all the time, but I like that I don't need them to program well. And the following is why I'm not particularly attracted to Java:

The consensus seems to be that Java was designed to be used with an IDE. Many design choices made the language overly verbose under the assumption that the IDE will generate code for you.

A few concrete examples:

You are expected to make all fields private and use them via accessors(yea, I know, in OOP you should externalize as least as possible - but in Java even structish classes are expected to use the property convention), but there is no nice property syntax. The assumption is that the IDE will generate getters and setters for your, and automatically fold them to hide the clutter.

Want to iterate over a loop? You'll need to create a for loopa with the full type of the iterator object and all that other verbose glue. Again - the IDE will do that for you.

Ridiculously long package names. (unconfirmed - I think I read somewhere that the original idea was to make them look like reversed domain names so that javac can reverse them and grab packages from the internet). Doesn't matter - just use the classes, and the IDE will add the imports for you(asking you to choose between several options if it can't decide by itself). ...

I personally write Java with Vim. I use the javacomplete2 plugin both for autocompletion and for import insertion. It can also generate getters and setters, but I tend to prefer to use Lombok, a library that uses annotation metaprogramming to magic away lots of glue code.

Genuinely Technical Modesty

noreply@blogger.com (X) — Tue, 02 Jan 2018 14:04:00 +0000

For all his technical knowledge knowledge and abilities, Richard Hipp sure is humble:

Richard Hipp: Yeah, and plus I wouldn't know how to do that. One of the reasons people really like working with this is we are a 100% engineering shop. There's no sales talk. When you talk to somebody at our company, you're getting direct no-nonsense talk with an engineer; you're not talking to sales people. And that's different. And that's not to knock the sales aspect of things. I understand that, and you have to do that in a lot of occasions, and those people work really hard, but we're just doing it a little bit differently.

You mentioned, maybe it was during the break, you quoted something from the article about how people tell me I could have made a lot of money on this if I had any business sense. And I believe them, I probably could have. By hiring some sales people, I could probably make a lot of money, get rich. But you know what, we make enough. It's not a lot. I'm driving a 10-year-old Civic, but that's fine. That's all I need.

You know, everybody - I'm getting off-topic - has this threshold where they get enough money. When you have nothing, you wanna make money, everybody wants that. But at some point you get enough money, so "Okay, now I have enough money, now other things become more important. Family, free time, working in the community, charities... Whatever." And that threshold is different for different people. Some people, they don't reach that threshold until they get into the billions, other people reach it at a few tens of thousands. Me and the people that are on the team, our thresholds are kind of low, so we're okay.

To Know C

noreply@blogger.com (X) — Sun, 17 Dec 2017 03:00:00 +0000

On those who know C, and those who actually don't.

A Redditor writes:

You'd be surprised at how people simply don't understand or know the basics of the language. We rather focus on how well the candidate knows the basics. Pointers are key and you should know how to use them like the back of your hand. Being able to use C data structures like structs, enums, etc. are also vital. Being able to manipulate data at both the byte level and the bit level (do you understand bit masking, bitwise logic, etc.).

When we conduct interviews, we don't focus on the algorithms or data structures that you see in higher level languages because that gets rather difficult in a language like C. We will ask things like do you know how to reverse an array or find content in strings as these require you to fundamentally understand memory, pointers, etc. and they aren't necessarily difficult algorithms. We do ask questions that try to see how well someone knows some of the tricks that you see in C, like doing multiplication/division by 2 using bit shifting, checking if a number of even or odd by bit checking instead of using modulo, etc.

Beyond the language itself, you also have to have a good understanding of how the code interacts with the OS. A big one is do you understand stack vs. heap? We may ask how you would write a function that returns an array (many candidates will try to create an array on the stack in the function which obviously doesn't work vs. using the heap or creating it on the stack in the calling function). Do you understand the basics of how functions are called and the implications of that (i.e. buffer overflows leading to security vulnerabilities)? A lot of OS basics are important to us, like understanding paging and the memory hierarchy. ...

Basically, and I think you can tell, is that we want our C developers to be more than someone who can write a C program and compile it. We want someone who understands what every line of code in the program is doing and how that program interacts with the OS and the hardware. This takes a lot of knowledge and is a lot different than higher level programming languages where such information isn’t as important as knowing how to apply the tools of the language. [...]

Sketch, Draft, Craft

noreply@blogger.com (X) — Sat, 16 Dec 2017 04:58:00 +0000

Craftsmen of the arts (digital or analogue) do experiment.

For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.

Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you've already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that's not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

Paul Graham, Hackers and Painters

When Defying Simplicity

noreply@blogger.com (X) — Sat, 16 Dec 2017 04:22:00 +0000

Of the obviousness of deficiencies in simple/complicated designs.

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

- Charles Antony Richard Hoare, 'The Emperor's Old Clothes', via the 1980 ACM Turing Award Lecture

The above proposition also applies to other domains of craft practice.

The Breakings of Julia

noreply@blogger.com (X) — Fri, 15 Dec 2017 05:20:00 +0000

The low-level diving tinkerability of Julia.

Haven't explored Julia, but this is an interesting point to consider:

I read about Julia a while back, and thought it sounded cool, but not like something I urgently needed. Julia is a dynamic language with great performance. That's nice, I thought, but I've already invested a lot of time putting a Ferrari engine into my VW Beetle — why would I buy a new car? Besides, nowadays a number of platforms — Java HotSpot, PyPy, and asm.js, to name a few — claim to offer "C performance" from a language other than C.

Only later did I realize what makes Julia different from all the others. Julia breaks down the second wall — the wall between your high-level code and native assembly. Not only can you write code with the performance of C in Julia, you can take a peek behind the curtain of any function into its LLVM Intermediate Representation as well as its generated assembly code — all within the REPL. [...]

Bam — you can go from writing a one-line function to inspecting its LLVM-optimized X86 assembler code in about 20 seconds.

So forget the stuff you may have read about Julia's type system, multiple dispatch and homoiconi-whatever. That stuff is cool (I guess), but if you're like me, the real benefit is being able to go from the first prototype all the way to balls-to-the-wall multi-core SIMD performance optimizations without ever leaving the Julia environment.

The Python Paradox

noreply@blogger.com (X) — Thu, 14 Dec 2017 17:14:00 +0000

The paradox: those who get the better job learn the things they don't need for it.

Mind you: this article was written in 2004. Python was only version 2.4 then:

I didn't mean by this that Java programmers are dumb. I meant that Python programmers are smart. It's a lot of work to learn a new programming language. And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job.

Innocent Until Proven Guilty

noreply@blogger.com (X) — Tue, 12 Dec 2017 15:28:00 +0000

On the need to prove guilt, and of being innocent until proven otherwise.

Even in the very few instances where the accused has intrusted his defender with a full confession of his crime, we hold it to be clear that he may still be lawfully defended. The guilt of which he may be conscious, and which he may have so disclosed, he has still a right to see distinctly proved upon him by legal evidence. To suborn wretches to the commission of perjury, or procure the absence of witnesses by bribes, is to commit a separate and execrable crime; to tamper with the purity of the judges, is still more odious: But there is no reason why any party should not, by fair and animated arguments, demonstrate the insufficiency of that testimony, on which alone a righteous judgment can be pronounced to his destruction. Human beings are never to be run down, like beasts of prey, without respect to the laws of the chase. If society must make a sacrifice of any one of its members, let it proceed according to general rules, upon known principles, and with clear proof of necessity: let us carve him as a feast fit for the gods, not hew him as a carcase for the hounds. Reversing the paradox above cited from Paley, we should not despair of finding strong arguments in support of another, and maintain that it is desirable that guilty men should sometimes escape, by the operation of these general rules, which form the only security for innocence.

- Sydney Smith, The Edinburgh Review: Or Critical Journal

The Song of Java Braces

noreply@blogger.com (X) — Fri, 08 Dec 2017 00:15:00 +0000

When coders become song lyricists.

Someone presents a notoriously right-braced Java code.

The folks at Programmer Humor then decide to sing:

When first I saw the brace, I was petrified!
Kept thinking, who would ever try to put them on the side?!
But then I spent so many nights, thinking how your program's wrong,
My beard grew long, found out how Python gets along
But now you're back, with no stack trace
I just walked in to find you here, looking for that edge case
I should have wrote much better docs
I should have made sure my mem was freed
If I'd have known for just one second you'd be maintaining after me
Go on now go, Stack Overflow
Just sign up now, 'cause you need to get to know,
Weren't you the one who wrote code this weird?
Didja think I'd accept it, Didja think this PR'd get cleared?
Oh no, not I. You will revise.
The one thing I can say for sure, is this code won't comply,
We've got a great style guide,
Examples of how you should write,
You will revise, you will revise

In addition:

And so your brace, is in outer space
I just compiled your code with a sad look upon my face

A Reputation Without Oil

noreply@blogger.com (X) — Wed, 06 Dec 2017 17:45:00 +0000

On advocates known to be frank, honest and sound.

Perhaps the most valuable thing the lawyer brings into the courtroom when he is an advocate is his reputation. His reputation for candor and soundness is worth three points in his brief and a marvelous opening for his oral argument. If his reputation is bad, I don't care what he says or how he says it — he is climbing a glass mountain in shoes covered with oil.
- Hon. Charles D. Breitel

Declarative, Imperative, Functional Sandwiches

noreply@blogger.com (X) — Sun, 03 Dec 2017 04:08:00 +0000

Programming paradigms and sandwiches.

From Reddit:

Declarative programming says, "Make me a sandwich."

Imperative programming says, "Get peanut butter. Get a knife. Get bread. Scoop peanut butter using the knife. Spread peanut butter knife over bread."

Functional programming says (and here the analogy breaks down a little), "Transform a closed jar of peanut butter into an open jar of peanut butter. Transform the open jar of peanut butter and a knife into a knife with peanut butter on it. Transform the knife and a slice of bread into a sandwich."

SQL: WHERE vs HAVING

noreply@blogger.com (X) — Sat, 02 Dec 2017 07:02:00 +0000

SQL's WHERE/HAVING can be a bit unintuitive.

See Stack Overflow:

WHERE clause introduces a condition on individual rows; HAVING clause introduces a condition on aggregations, i.e. results of selection where a single result, such as count, average, min, max, or sum, has been produced from multiple rows. Your query calls for a second kind of condition (i.e. a condition on an aggregation) hence HAVING works correctly.

As a rule of thumb, use WHERE before GROUP BY and HAVING after GROUP BY. It is a rather primitive rule, but it is useful in more than 90% of the cases.

Choice - of Pandas and SQL

noreply@blogger.com (X) — Sat, 02 Dec 2017 06:54:00 +0000

As to when to use Pandas, regular SQL or SQLite.

Says Reddit:

You can do queries and aggregations in both SQL and Python's Pandas.

If your datasets are small and transient, and you only need to manipulate them in memory as part of your program, use Pandas. Pandas can be thought of as a DSL that extends Python's array type by adding a DataFrame object.

If your datasets are large (or potentially large) and persistent, do it in a proper SQL database. You will will have an easier time scaling up, and it opens the doors to functionality and performance optimizations you would not have had otherwise (e.g. indexing, query optimizations, nested queries, partitions, etc.).

If your datasets are small but persistent, use an in-between solution like SQLite.

Debugging: Twice As Hard As Writing Code

noreply@blogger.com (X) — Mon, 02 Jan 2017 16:35:00 +0000

Been experiencing this quite a bit. Glad I'm in that "not smart enough" category.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

– Brian W. Kernighan, co-author of The C Programming Language and the "K" in "AWK"

Inverting (vs Zipping) Dictionary Values and Items

noreply@blogger.com (X) — Thu, 06 Oct 2016 13:23:00 +0000

On the inversion of a dictionary's key/values.

David Beazley wrote, in Item 1.8 of Python Cookbook 3 ("Calculating with Dictionaries"):

In order to perform useful calculations on the dictionary contents, it is often useful to invert the keys and values of the dictionary using zip().
min_price = min(zip(prices.values(), prices.keys()))
...
The solution involving zip() solves the problem by "inverting" the dictionary into a sequence of (value, key) pairs.

Observations

The above plagued me for a while until I finally 'got' it. Here's how I'd explain it instead:

zip() does not actually 'invert' the dictionary. It only creates an iterable zip object.
To actually make a dictionary from the zip object, apply dict() to it.
The zip object merely preserves the order of its arguments; i.e. you get the 'inverted' dictionary because the above code uses values-keys (rather than keys-values). Example:

prices = {
 'ACME': 45.23,
 'AAPL': 612.78,
 'IBM': 205.55,
 'HPQ': 37.20,
 'FB': 10.75
}

zipped_not_dict = zip(prices.values(), prices.keys())
zipped_dict = dict(zip(prices.values(), prices.keys()))

print(prices.values(), prices.keys(), sep="\n")
print("---------------------------") 
print(zipped_not_dict, zipped_dict, sorted(zipped_dict), sep="\n")

...which outputs:

dict_values([205.55, 45.23, 37.2, 10.75, 612.78])
dict_keys(['IBM', 'ACME', 'HPQ', 'FB', 'AAPL'])
---------------------------
<zip object at 0x0133B148>
{10.75: 'FB', 205.55: 'IBM', 45.23: 'ACME', 612.78: 'AAPL', 37.2: 'HPQ'}
[10.75, 37.2, 45.23, 205.55, 612.78]

Alternative

Another Pythonic way to invert key-values is by dictionary comprehension:


reversed_key_value_dict = {v:k for k, v in dict_name.items()}

Refunctin' Blocks

noreply@blogger.com (X) — Mon, 11 Jul 2016 18:58:00 +0000

From Refunct.

Refunct is simple: you give grassy verdure life to tiles, jump on red buttons, and slide through pipes, and do little more than that.

Yet overall, Refunct looks and feels beautiful: the game and (especially) its music strongly convey serenity. Notwithstanding its less-ambitious goals, I'd definitely take more of Refunct.

SublimeREPL's Slow Printing/Freezing - A Solution

noreply@blogger.com (X) — Mon, 11 Jul 2016 14:33:00 +0000

Sublime Text 3 may freeze if you use print long outputs via SublimeREPL. I'm not quite sure why.

I face this issue often, as I prefer to use the interpreter in Sublime Text (so as to avoid IDLE). Thankfully, someone on Github has deduced its potential cause and a solution:

"...It appears sublimeREPL buffers everything that it needs to print before updating the screen. This seems to be done one symbol at a time, and can cause performance issues with long strings. To change this functionality, go to the main plugin file (Packages\SublimeREPL\sublimerepl.py) and find the function handle_repl_output() in the ReplView class."

I don't understand Sublime Text's code base, but I tested his suggestions today, which works perfectly with Python 3 once you amend it to use range() instead of xrange() (as the latter has been deprecated).

Here's the modified code, to help anyone else out:



    def handle_repl_output(self):
        """Returns new data from Repl and bool indicating if Repl is still
           working"""
        if self.repl.apiv2:            
            try:
                while True:
                    packet = self._repl_reader.queue.get_nowait()
                    if packet is None:
                        return False

                    self.handle_repl_packet(packet)

            except queue.Empty:
                return True
           
        else:
            try:
                packet = self._repl_reader.queue.get_nowait()
                if packet is None:
                    return False
                for _ in range(1000):
                    try:
                        packet += self._repl_reader.queue.get_nowait()
                    except queue.Empty: break

                self.handle_repl_packet(packet)
                return True

            except queue.Empty:
                return True

The changes I see: A single if clause is added above try; an entire else clause is added after. Restoration requires only that you remove those, which is a fairly simple task.

As he further suggests, to improve the text speed, scroll down to def update_view_loop(self), then update as follows: sublime.set_timeout(self.update_view_loop, 1).

The Lawgiving Coder

noreply@blogger.com (X) — Sat, 09 Jul 2016 12:25:00 +0000

Coders as creators of universes and law.

Said Joseph Weizenbaum in In Computer Power and Human Reason:

...The computer programmer is a creator of universes for which he alone is the lawgiver. Universes of virtually unlimited complexity can be created in the form of computer programs. Moreover, and this is a crucial point, systems so formulated and elaborated act out their programmed scripts. They compliantly obey their laws and vividly exhibit their obedient behaviour. No playwright, no stage director, no emperor, however powerful, has ever exercised such absolute authority to arrange a stage or field of battle and to command such unswervingly dutiful actors or troops.

Tifa Funk - Interlude Solo ("Tifa's Theme" by Tetrimino)

noreply@blogger.com (X) — Sat, 12 Mar 2016 07:19:00 +0000

My transcription of the piano interlude from "Tifa Funk".

The solo starts from 2:01.

The original piece is actually rather melancholic; this one has a jazzy/airy feel. I like it. (And I especially adore the transition between the B (b4) to A (b5) chords.)

Title	"Tifa Funk"
Source	YouTube
Play Type	Cover
Played By	Tetrimino
Tempo	136.75
Tuning	Standard E
Transcribed	12.03.2016 / 2:25 AM



e-12h17p12----12---12----|----------------------|-----------------------
B----------15---------15-|----------------------|-----------------------
G------------------------|--14--12-10-12-----10-|--12h14p12-----10------
D------------------------|----------------12----|-----------12-----12---
A------------------------|----------------------|-----------------------
E------------------------|----------------------|-----------------------

e----------------------------------/13-13~-----------|------------------
B-------------------------13-15-13--13-13~-----------|------------------
G-12--10-12-14---12-13-14------------------13/14--12-|------------------
D----------------------------------------------------|------------------
A----------------------------------------------------|------------------
E----------------------------------------------------|------------------


e----------------------------------------------------------------------
B-------15-13----------------------------------------------------------
G-12-14-------14-------------------------------------------------------
D----------------12/15--17------------10----11h12----------------------
A-------------------------------10-12----12-------11h12-8----8h10---8--
E---------------------------------------------------------10-----------


e---------------------------------------------------------------------
B---------------------8-------------6-------6----6/8----10~-----------
G-------------------7---9-10----5-7---7-5-7-5--6--------10~-----------
D----------------10----------------------------7----------------------
A-------5-8-7---------------------------------------------------------
E---5-8---------------------------------------------------------------
 

e-------------------------------------|--10---------------------------
B--10-10-10-10-8----------------5-----|-----8h10--8----8--------------
G--10-10-10-10--------7-6---------7---|-------------10---10------8----
D-------------------8-------5-7-------|----------------------12--8----
A-------------------------------------|-------------------------------
E-------------------------------------|-------------------------------



e--------10--10---10------------------|----10---8---------------------
B--------10--10-------10--------------|----10---8----10----12-10~-----
G-----8------------------10----10--12-|-10-----------10----12-10~-----
D-5-8-7---------------------12--------|-----------10----12------------
A-------------------------------------|-------------------------------
E-------------------------------------|-------------------------------


e--------------------------------13----13-15-16-13-16-17-20-17-20-22--
B--------------------13----13-15----15--------------------------------
G--------10-10-12-14----14--------------------------------------------
D--10-12--------------------------------------------------------------
A---------------------------------------------------------------------
E---------------------------------------------------------------------

Rather Be (Alexa Goddard's Version)

noreply@blogger.com (X) — Sat, 05 Mar 2016 11:42:00 +0000

My tab of Alexa Goddard's acoustic cover of Clean Bandit's "Rather Be".

Some points:

I've only highlighted the notes/chords. Listen to the cover for the comping/strumming patterns.
In the chorus, the comp accents don't fall on the 4/4 beats, and there's no real transition between the D#m7 and EM7 chords.

Title	"Rather Be"
Source	YouTube
Play Type	Cover
Played By	Alexa Goddard
Tuning	Standard E
Transcribed	05.03.2016 / 11:59PM


INTRO/CHORUS


   G#m7
e-------------------------------------------7--|-----------------------
B--11h12--h14-----11-------7h9--p7----------7--|-----------------------
G--11-------------11-------8---------8------8--|-----------------------
D--11h13----------11-------9---------9------9--|---C#m7-----D#m7-------
A--11-------------9--------7---------9---------|-----------------------
E------------------------------------7---------|-----------------------


BRIDGE

e----------------------------|-----------------------------|
B---------4--/5----4----/5---|---------4--/5----4----------|
G---------6--------4----/6---|---------6--------4----------|
D--EM7----5--------4----/7---|--EM7----5--------4----4-----|
A---------6-------------(7)--|---------6-------------4-----|
E------------------4---------|------------------4----2-----|


CHORUS
                            x3
e----------------------------|--------------------------------|---------
B-----------------------11---|-------------------------11-----|---------
G-----------------------9----|-------------------------11-----|---------
D--G#m7-----D#m7--EM7---11---|---G#m7-----D#m7--EM7----11-----|---C#m7--
A-----------------------10---|-------------------------9------|---------
E----------------------------|--------------------------------|---------


ENDING CHORD (after last C#m7)

e---0~--------|
B---0~--------|
G---1~--------|
D---2~--------|
A-------------|
E---2---------|

Eye to Eye (Jonathan Young's Version)

noreply@blogger.com (X) — Sun, 07 Feb 2016 18:09:00 +0000

My transcription of Jonathan Young's cover of "Eye to Eye".

This song is originally from A Goofy Movie.

My tab isn't a verbatim reproduction; I've only highlighted the important notes.

Title	"Eye to Eye"
Source	YouTube
Play Type	Cover
Played By	Jonathan Young
Tuning	Drop D
Transcribed	07.02.2016


[PART A]
                                          x8
e------------------------------------------|
B------------------------------------------|
G------------------------------------------|
D---------0-0----0-0--------0-0--x-0-x-0---|
A--2----2-0-0----0-0-2----2-0-0--x-0-x-0-2-|
D--2----2------------2----2--------------2-|


VERSE - Follows [Part A], with rhythmic variations

BRIDGE                  

                        
                        
e-------|-----|--------|
B-------|-----|--------|
G-------|-----|--------|
D-----2-|-----|---2-2--|
A--0--0-|-[A]-|-0-0-4--|
D--0----|-----|-0------|




CHORUS 

   I used '.' to reflect the extended A5
   while the B5 is just one beat
--------------------------------|
--------------------------------|
--------------------------------|
-6-2-4----6-4-2.4--6-2-4------0-|
-4-0-2-2--4-2-0.2--4-0-2-2--0-0-|
-------2-----------------2--0---|



VERSE 2: Almost like Part A. Mostly rhythmic variations, and 
a hammer-on transition lick on the low strings - not transcribing.

BRIDGE -> CHORUS 

CHORUS TO SOLO

For the first time ever~~~ We're seein it~~~ 
e--------------------------------------------
B--------------------------------------------
G--------------------------------------------
D---------------------------2----------------
A-0-------------------------0----------------
D-0------------------------------------------

Eye to eye~~        Eye to eye
------------------------------------------------
------------------------------------------------
------------2-----------------------------------
------------0-----------------------------------
----------------------------2-------------------
----------------------------2-------------------

SOLO - [Not transcribed]


SOLO TO BRIDGE KEY CHANGE 

(replace bar 4 of chorus)   If you're ever lonely       Stop
e-------------------------|-----------------------------------
B-------------------------|-----------------------------------
G-------------------------|-----------------------------------
D-2~---4~-----------------|---------------------7~------------
A-0~---2~-----------------|---------------------5~------2-----
D-------------------------|-----------------------------2-----


Play [Part A] again



BRIDGE         KEY CHANGE CHORUS           
KEY CHANGE 

e------------|----------------------------|
B------------|----------------------------|
G------------|----------------------------|
D---2-4--6~--|-8-4-6----6-8-4.6--8-4-6----|
A-0-0-2--4~--|-6-2-4-4--4-6-2.4--6-2-4-4--|
D-0----------|-------4-----------------4--|
             |
             | Alternative chord:
            A|-1---
            D|-1---
    

 ENDING - 


--------------------------------------------------------
--------------------------------------------------------
--------------------------------------------------------
------------2-x-x-x--2-2--------2-2-------x-2-x-2-------
-2-----4--4-2-x-x-x--2-2--4---4-2-2-x-x-x-x-2-x-2-4-4---
-2-----4--4---------------4---4-------------------4-4---

Prayers Like Magic

noreply@blogger.com (X) — Sun, 24 Jan 2016 10:07:00 +0000

Your prayers to court are, in a way, akin to incantations:

They're purposefully-designed.
They must be cast (drafted) a specific way, and by the right spells (rules of court).
Succeed, and a specific relief is bestowed, to 'cure' a man of his legal ailments.
Fail, and nothing happens. (Or that which should not magically be summoned, is.)

Information versus Knowledge

noreply@blogger.com (X) — Sun, 24 Jan 2016 02:13:00 +0000

Information on an item of knowledge is not knowledge of the subject matter itself:

"...It's interesting to see that he makes a distinction between knowledge and meta-knowledge, calling the latter "information." It's also interesting to see that since 1775 the second kind of knowledge (meta-knowledge, that is) has increased almost exponentially as compared with the first kind. Some people lament this. I believe that it is an inevitable byproduct of the growth of knowledge of the first kind, and therefore not to be lamented, but to be better understood than it is even now."

Creators And Their Gems (Polished or Otherwise)

noreply@blogger.com (X) — Sun, 03 Jan 2016 05:31:00 +0000

Not all work will turn out gems.

Says a Redditor:

Prince is infamous for creating huge amounts of stuff and just shelving it too.

Answers another Redditor:

Most professional writers/musicians do this. In fact I would wager all writers that are known for consistently putting out great songs only do this. It's the only way to put out amazing work consistently. No one, and I mean no one actually only writes great songs every time. There's a lot of bad ideas in that process that will never see the light of day and never even be spoken of outside of fellow writers/musicians and friends because those songs just weren't good enough.

The hard part is being consistent over many years and powering through the many poor outcomes so that you get to the one great outcome, and rinse and repeat. The people who can do that without burning out are the ones who make it to the tippity top.

What's funny is you'll have one-hit wonders where they power through the poor outcomes, get their first great outcome, and don't realize that's the process required to make many hits, and they just put out every idea they create afterwards and wonder why only one or two songs did really well and they can't seem to make it happen with their other songs and get discouraged.

They think these amazing musicians never make bad music, but that's just not the case. They make bad music all the time, but they never show anyone. They only release the greats, and so they are constantly working and writing song after song, waiting for that one great idea to come about.

No one, not even Michael Jackson, writes a good song every time. I would wager all my possessions that if all of his unreleased songs were in fact released, most of them would be mediocre or disappointing (but still very interesting to hear). Those songs aren't meant to be heard by anyone except for him and whoever may have worked on them, and people they showed that they trusted asking for feedback. Otherwise he would have released them.

Emails and English Weather

noreply@blogger.com (X) — Mon, 21 Dec 2015 14:08:00 +0000

The English sure love their weather.

I'm reading some emails from an English firm of solicitors.

Despite the formal contents, almost every email of theirs ends with a description of the weather. E.g:

"...Trust you are keeping well from wet and rainy London"
"...Kind regards from a very hot London"