Functionality vs. Fastness

A question that language developers have faced for a long time is whether or not to make their language the "does-it-all" or the "does-it-fast" of languages.

On one end of the spectrum are the low-level languages. Think C/C++--the ones with low functionality and high fastness. On the other end is all of the "bloated" languages. Think PHP, Java 6--the ones with high functionality and low fastness. I often find myself swapping between languages on both ends of this spectrum. Up until recently, there hasn't really been a language I've known of that treats the world with both sides of the picture: high functionality and high fastness.

Enter Ruby. Ruby calls itself "a programmer's best friend" for a very good reason. It's insanely functional (one can write a web server gem, odd as it may look, in 6 lines of Ruby code), and also insanely fast. It powers many of the world's famous social networks, and for good reason.

For me, Ruby makes the most sense. Everything I want to do can be done in Ruby in some way. Writing a module to use in other projects is very easy, and then sharing it with the world is even easier. It's the kind of language that encourages expansion; over 71,000 "gems" have been published. From things like cryptography to things like the well-known Rails framework, Ruby plays across the entire gamut.

Things like classes and such are hard to find in the "fast" languages, but come naturally in the "functional" languages. Ruby is what many call "purely" object-oriented; practically everything is represented as an object, and some interesting things come of this behavior. Some projects can be written containing extensions of existing objects, and some major things can be done using one-line changes.

Sure there's still a trade-off between functionality when one uses Ruby (it isn't as fast as some of its counterparts, but it's fast and getting faster), but it's still got much of the "best of both worlds" effect going on.

I'd suggest that you try Ruby if you haven't already. It's interesting to see what has been done and what will continue to happen. Read more, if you're interested. I think it's the perfect combination of both functionality and speed, and is built sanely.

Social Media Blackout: What it is, and why I'm doing it.

Before I get started, welcome to my blog, if you've not already been here before.

---

I've been ruminating for quite some time about my productivity levels and what influences I have in my life, and I've come to a somewhat startling realization. In running some time audits on my workflow, I found that large amounts of time that I thought was being spent doing productive things was actually being wasted on social media sites like Facebook and Twitter. It seems that in addition to directly consuming my time, these social media sites also indirectly affect my performance through an addictive sort of attachment. This is problematic as I would like for my workflow to be as productive as possible and I would like to be able to get a large amount of work done on as many projects as possible. As such, I've decided that such distractions must be removed from my life entirely.

In addition to the (frightening) lack of productivity, I find that social media sites nowadays actually inhibit their users' friendly interactions. Instead of as it is with natural conversation, we find ourselves struggling against our devices to realistically portray our emotions to others. There is no possible way to electronically provide the same experience as talking to someone in person. Without crystal-clear sound and video with no lag, conversations are not the same as in person, and cannot be.

In order to prevent further loss of time, I'm going to be deactivating or removing both my Facebook and Twitter accounts, as well as any other social media accounts that I see as being time-consuming.

---

Now, I'm not getting rid of everything. I'm still keeping my Email address, my Google+ profile, and this Blog as a way of communicating with those who will remain on the other sites. By no means am I intending to completely avoid these sites, however one of the first projects I want to do is to write a Chrome Extension that blocks such sites, an extension that I hope to use extensively (no pun intended). The reason I am retaining the aforementioned accounts is that I believe that Google+ does not inhibit productivity and is actually somewhat helpful, whereas Facebook, Twitter, and such are directly directed at wasting my time. Blogs and Emails allow for communication to be longer and more thought-out before being posted, which enables ideas to steep before they are shared, resulting in a higher-quality throughput.

---

You may disagree with me. That's perfectly fine. I'm okay with people retaining their current online presence, but I hope that everyone realizes that this is a decision I'm making to prevent myself from being unproductive. I believe that I am addicted, one might say, to these social media sites and that I need to distance myself from them in order to be a more effective team member on the projects I'm currently working on and will continue to work on.

---

So, if you want to reach me after I deactivate or remove my accounts, you can email me at <kristofer.rye@gmail.com>. You can talk to me in person, but if you email me there then I can give you more information if you need to communicate more rapidly (i.e. over SMS). You can also "circle" my Google+ Profile, as that will be the only social network that I retain. You'll be able to reach me on GitHub and BitBucket as always.

In the future, I may return to these online sites once I've "de-toxed," in a way. This could be months or years down the road from now.

The planned date for the deletion of these accounts is Monday, 24 March, 2014.

TL;DR: I'm deleting accounts on 24 Mar 2014. Email me at the above address and/or circle my Google+ profile.

---

EDIT 0: I'll be editing this post with updates as progress is made.

EDIT 1: Tumblr is the first to go as of 23:00 tonight (I got tired of waiting). Others will wait for closure (archives must be obtained)

EDIT 2: Twitter is the second to go as of 22:30 tonight (I got tired of waiting).

EDIT 3: I realized that Facebook still has some value. As such, I have decided to keep it, however I am changing my password to an extremely long hexadecimal string and I am storing that in a file somewhere, then deleting all of my Facebook cookies. My plan is to check it only once every week, yet hold it open for the sake of all of the people with whom I communicate over Facebook.

On the topic of jQuery

Many web developers would agree: jQuery does make various backend-related things easier.

An inherent property of things which make various backend-related things easier is loss of direct control over the interactions with the backend. While that may end up being a good thing if the "Man in the Middle" (MitM) is doing everything correctly, if there is a problem with the MitM's way of doing things at some point, the programmer has to either fix the MitM or request that someone else do it for them. This doesn't happen that often, however, because people build their applications around the MitM's. If something breaks, they change their code and that's that.

I tend to avoid any and all interaction with jQuery. Most of the things it simplifies are very simple to do using native JavaScript and hardly any extra work, and the thought of letting someone else do my work is, quite frankly, terrifying. If I can do it in native JavaScript, I will. If I have to write my own wrapper for the backend to simplify my calls in my main code, I'll do that. No problem. Is it a bad thing? No. Of course not. You can easily write things in native JavaScript, and I think of it as a more enlightening experience. You understand what you're doing, and you can change things much more easily.

In the "fancy effects" world, where everyone uses jQuery because of the transitions it has to offer, many people just expect to use the jQuery functions for their transitions and simply cannot live without them. That may work for them in their own projects, but for me it is, as one may expect, definitely not optimal. While I agree that writing them in code without using any previous knowledge is a difficult task, I would disagree that it is stupid not to do it; it is an enlightening experience and gives you much more control.

Other Languages

Over the past couple of weeks, I've found myself increasingly using other languages than my favorite, C.

There are a lot of possible reasons for this, chiefly just curiosity as to just how nice all of these other languages are. For example, my second-latest trial was with Perl. Though variable syntax is weird and scoping is somewhat odd, it works quite remarkably and is quite concise. My latest, the one I just started about ten minutes ago, involves Python. Both languages are scripting languages, yes, which I'm not a huge fan of (because insane performance is what I strive for), but their conciseness and efficiency pique my interest and make me quite happy with them.

A little while ago, I wrote up a couple of things which use JavaScript. JavaScript is nice, if it weren't for how the "classes" are defined. Beyond that, I'm quite interested in it, as it is heavily optimized and can do a lot. I'm not a huge fan of jQuery, however (as anyone who has worked with me knows very well), and so the fact that JavaScript can't do some things is understandable but slightly crippling. But I digress.

I like to do this, so I will: *raises Staff of Judgement*

The following is a list of my preferences of languages in descending order:

Ruby: While everything about Ruby's syntax and general sanity (including the community) is amazingly awesome, the two major things which I seek most greatly are absent in Ruby. Interfacing with system libraries is hard (so things like windowed graphical development are made harder), and performance is an issue. While there are ways to optimize Ruby code, I'd love it if I could run a Ruby application and have it have C-like speed and efficiency. I'm used to my programs being slowed down by I/O speeds, not controlled by them. Ruby's great for quick tools that do lots of work over time and can do advanced sorting and whatnot, which is why I put it at the top here, but in terms of super-performance, it's certainly not the best alternative.

C: As I've said in the past, C is fun, when you're writing stuff that needs to go über-fast and needs to be really simple. When you're getting into the higher-level stuff, though, and the general-purpose things, C gets harder and harder. For example, without writing your own system, C has no real ways of going about simple general purpose "numbers." Ruby has two types that I know of or see most commonly, one being the Fixnum and one being the Float. C has no equivalents, you have uint{8,16,32,64}_t, {, unsigned{, long}}int's, double's, floats, and many many more (including GMP's mp{z,q,f}_t types which simplify it somewhat) number types. There's not really a built-in way to make a number that can both go past the current limits and can also be used as a decimal. C is too technical for that.

Perl: Perl is like Ruby in terms of the "getting-things-done" philosophy, and there are many, many different ways to approach the same problem. Perl is significantly faster than Ruby, as well (it is almost as fast as C). It supports numbers which match the description I described under "C" and can do a lot of stuff. The CPAN is a beautiful thing which contains everything from SDL and OpenGL wrappers to Apache frontends to graphing libraries to power block control libraries. Perl's community is simply unmatched in my opinion, and I can identify with the decisions that they have made.

JavaScript: JavaScript is great for web applications, but I haven't found much of a use beyond that. I use it a lot for Node-Webkit applications, but beyond that, again, I have little use for it. I may look into Node.JS in the future.

LISP: While I can't say I've used it that much, I can say that LISP has not shown much speed. I haven't done benchmarking of many if any of these languages, but I can say that LISP seems slow. It also doesn't have much of an interface with the system like Perl or C does, which makes it not my kind of language as it can only do really nice mathematics. Who knows, maybe in the future I'll begin to like it more and use it.

C is fun.

Over the last few weeks, I've been thinking about other languages. C++ is C with improvements and high-level capability. Java is C++ on 'roids. The "Webdev family" (HTML, CSS, and JavaScript, and everything that generates into it) is somewhat confusing but not the end of the world to use. But when most people think of using C, they think of it as a painful, slow, tedious experience which takes too much effort to maintain and use.

I, however, would beg to differ with those statements. I've numerous GitHub repositories which use C, and most of them are to some level of success. C isn't the kind of language where you have to sit there for hours decoding the error messages so you can fix stuff; it's the kind of language where if something isn't working as expected, you did it wrong. Not to put myself or anyone in this grouping, but it's the kind of language people who are perfect at it--who just get it--use.

The biggest problem for most people is having to think about memory. Most people consider memory to be this evil thing that their higher-level language takes care of for them, and they aren't too concerned with it. When programming in C, however, it is almost always the case that one must use malloc at least somewhere in their code. And that scares most people.

The fun thing about C--I think--is that once you stop being afraid of dealing with memory, and you get an idea of how your computer interprets your code, and what exactly a given line of code will do to the processor or a chunk of memory, and you become familiar--and friendly--with memory, you reach a higher level of understanding and you begin to really enjoy C.

That's one of the reasons I love C so much; it's one of the languages that is so beautiful because of how basic it is. It's not resource-expensive in the least (besides the usually-increased volume of source you must have, but storage these days is cheap so that doesn't matter), and it's so flexible that it can do, quite literally, anything.

That said, people would still argue that it takes too much effort to write C code that works and does a lot of fancy stuff. Perhaps, with their special tools and shit, they get "so much done" and have a "much higher understanding" of what they're doing. They may be right. But for me, and for a lot of other people, C is the best; even with all of those tools out there, a proper C workflow for those people is still more efficient.

Okay, so Evolution Mail and Calendar is Good Software, too

http://projects.gnome.org/evolution/download.shtml

People hate Evolution because it's a bit of an annoyance as far as
performance goes. While the performance issues are a bit of an
annoyance, I can't say it's worse because it has them.

And frankly, it integrates nicely with GNOME and so it isn't too ugly.
You could try it, too.

//Kristofer "four04" Rye

Alpine is good software

https://www.washington.edu/alpine/

Some good software. It's a out-of-your-way little email client, which is nice for me considering that I keep my email open all the time but rarely peek at it. I'd prefer not to get any notifications when I get new email, but rather to check my email and see that I have email. Usually I do that around every five minutes, and this software is nice for that.

Of course, my Windows friends can't run it, because Microsoft doesn't like people being able to compile software, but that's not that much of a problem. I doubt anyone actually follows any of my software recommendations beyond anyone in my group of friends, but it's a fun bit of software and that is all.

// Kristofer Rye [four04]