Often, collaboration on GitHub is restricted to either email and issues or solely issues. While both are very sufficient means of communication, they are not suitable for rapid back-and-forth communication in a chat-like style. Such sentences as "My branch is stable, can I deploy it?" don't need fully-fledged issues nor emails to be sent back and forth, but they are important nonetheless. We do have Google Hangouts and other messaging services, but they're all integrated with larger things and are slower and more general than they could be. Wouldn't it be great if there was a chat service that behaved a lot like GitHub but was more for private chat for the smaller but still important things?
Enter Gitter (currently in beta)
It Integrates
While it is an external messaging service, Gitter integrates very effectively with all sorts of services, including GitHub, BitBucket, Heroku, Jenkins, Travis, Trello, Huboard, and Sprintly. Gitter rooms are built on a per-repository or per-user basis (You can create non-associated rooms if you need to), so keeping chat separated between your projects is very easy. If you need to, you can very easily switch between projects quickly and efficiently.
For example, I'm working on a project with some folks who have integrations with both Heroku and Travis CI, and so every time a commit is pushed, a deploy is performed, or the build status changes, a little notification is displayed in the chat window (Most of this is configurable). This enables fast realization of problems without ever having to leave the Gitter window.
It's Beautiful
Gitter supports GitHub flavored markdown, which means that writing messages in it is just like writing messages on GitHub issues. It supports editing in both "chat mode," where shorter and rapid-fire messages are sent using Enter or Return, and "compose mode," where longer messages are sent using Ctrl+Enter or Return.
On top of that, Gitter has a very beautiful and simple modern design. It's very easy to get started, and it's easy to join and use rooms. Everything flows nicely and everything is where I would expect it to be.
Would I Recommend It?
Absolutely. Not a doubt in my mind. I'd highly recommend that you try it out and use it. It's very helpful.
13 May 2014
DuckDuckGo: A Search Engine Done Right
DuckDuckGo is my favorite search engine for so many reasons. With its new redesign, DuckDuckGo is undergoing a major visual revamp which I hope will draw more new users, because both the fundamental philosophy of DuckDuckGo and its execution are models for a perfect search engine. Google is currently the industry leader, and many have tried and failed to beat Google. DuckDuckGo is one contender, but compared to Bing and Yahoo, DuckDuckGo isn't very significant. Yet.
The problem with Google is that they use extensively-obtained user data to provide context for a user's search terms. Often times, there's more meaning to the search terms than just the words and spaces, there's something behind their use of those words and their searching for a particular thing at any given time. I've used Google off and on for quite some time and I find it to be quite helpful, but I'm not satisfied with it any more.
DuckDuckGo, on the other hand, does not (to my knowledge) use context-based recognition of users' search terms. I find that many of my searches turn out better results on DuckDuckGo than on Google, surprisingly enough. Sometimes, when I'm looking for an answer to a programming question or something like that, DuckDuckGo is a much better search engine for that kind of question. I find that this is often because the first few pages of Google's results are merely Stack Overflow questions relating to my query, and often the answers to those are of such low quality that they are not applicable to my search. DuckDuckGo, on the other hand, always gives me results from sites that are reputable in the area (e.g. W3 for HTML-related stuff).
Another feature that Google lacks that DuckDuckGo users will find incredibly useful is the ability to use other search engines. DuckDuckGo includes a library of so-called "bangs," which are basically words or abbreviations that start with exclamation marks and do various things to the search. For example, the "!gi" bang will forward the search to Google Images, if you prefer to use that. Or, if you're looking for a Wikipedia article, "!w" is available. If you're looking for JSTOR documents, there's "!jstor". If you're looking for documentation, even "!ruby" or "!js" are out there. Bangs redefine searching: the user probably knows what they want to find, and the user is usually right.
So I would highly suggest DuckDuckGo. If you don't already have it set as default in your browser, you can click buttons on their new homepage or you can follow their helpful instructions. Give it a spin. Let me know what you think.
The problem with Google is that they use extensively-obtained user data to provide context for a user's search terms. Often times, there's more meaning to the search terms than just the words and spaces, there's something behind their use of those words and their searching for a particular thing at any given time. I've used Google off and on for quite some time and I find it to be quite helpful, but I'm not satisfied with it any more.
DuckDuckGo, on the other hand, does not (to my knowledge) use context-based recognition of users' search terms. I find that many of my searches turn out better results on DuckDuckGo than on Google, surprisingly enough. Sometimes, when I'm looking for an answer to a programming question or something like that, DuckDuckGo is a much better search engine for that kind of question. I find that this is often because the first few pages of Google's results are merely Stack Overflow questions relating to my query, and often the answers to those are of such low quality that they are not applicable to my search. DuckDuckGo, on the other hand, always gives me results from sites that are reputable in the area (e.g. W3 for HTML-related stuff).
Another feature that Google lacks that DuckDuckGo users will find incredibly useful is the ability to use other search engines. DuckDuckGo includes a library of so-called "bangs," which are basically words or abbreviations that start with exclamation marks and do various things to the search. For example, the "!gi" bang will forward the search to Google Images, if you prefer to use that. Or, if you're looking for a Wikipedia article, "!w" is available. If you're looking for JSTOR documents, there's "!jstor". If you're looking for documentation, even "!ruby" or "!js" are out there. Bangs redefine searching: the user probably knows what they want to find, and the user is usually right.
So I would highly suggest DuckDuckGo. If you don't already have it set as default in your browser, you can click buttons on their new homepage or you can follow their helpful instructions. Give it a spin. Let me know what you think.
28 April 2014
Have You Read It Yet?
Often times, when interacting with my friends and acquaintances on a day-to-day basis, I find myself asking them "Have you seen that [post I shared/post I wrote]?" Unfortunately, this data must be obtained and is a quite obvious sign of trying to gather reach data from the audience. This is problematic because responses can be skewed and do not give that much insight.
An idea I've been thinking a lot about is social media. Often times, there's an interest in seeing which users have seen which content, when, where, and such things as that. Many people--not just corporations but actual users--are interested in understanding who their posts reaches, what kinds of feedback it gets, and such things. This data can be ascertained by measuring the amount of time that a user spends viewing a certain post. A system can be designed to determine whether or not content is visible and then determine the user's response.
Unfortunately, measuring the user's response is difficult. Ideally, it would be as simple as measuring whether or not they interact with the content, however people are becoming increasingly lazy and such behavior is difficult to measure. For example, Google+, Facebook, and Twitter all aggregate content into a centralized page (called the "news feed" or "timeline") to display to the user, and the user generally does not click anything. Therefore, the data needs to measure not only interactions with content but times that a post has been viewed.
Using statistical analysis algorithms which I have neither formed nor found as of yet, the user's post response times can be measured. There are users who simply scroll through their feed until they find something interesting, and it is important to measure which posts they scroll past as well as what causes them to stop. If a post is visible, a timer would be started for that post, and as soon as it became invisible or was accessed, that timer would be stopped. If the user clicked on the content, then that would count as interest in that content and would count as a reach. If the user read through the content (i.e. if it were a text post), then the reach of a post could be measured through post view time.
I plan to toy around with these algorithms soon. Timing post content seems to be the most difficult thing and differentiating attention also. The main problem will be aggregating and processing it in a timely manner and without considerable lag. We'll see where this idea goes.
An idea I've been thinking a lot about is social media. Often times, there's an interest in seeing which users have seen which content, when, where, and such things as that. Many people--not just corporations but actual users--are interested in understanding who their posts reaches, what kinds of feedback it gets, and such things. This data can be ascertained by measuring the amount of time that a user spends viewing a certain post. A system can be designed to determine whether or not content is visible and then determine the user's response.
Unfortunately, measuring the user's response is difficult. Ideally, it would be as simple as measuring whether or not they interact with the content, however people are becoming increasingly lazy and such behavior is difficult to measure. For example, Google+, Facebook, and Twitter all aggregate content into a centralized page (called the "news feed" or "timeline") to display to the user, and the user generally does not click anything. Therefore, the data needs to measure not only interactions with content but times that a post has been viewed.
Using statistical analysis algorithms which I have neither formed nor found as of yet, the user's post response times can be measured. There are users who simply scroll through their feed until they find something interesting, and it is important to measure which posts they scroll past as well as what causes them to stop. If a post is visible, a timer would be started for that post, and as soon as it became invisible or was accessed, that timer would be stopped. If the user clicked on the content, then that would count as interest in that content and would count as a reach. If the user read through the content (i.e. if it were a text post), then the reach of a post could be measured through post view time.
I plan to toy around with these algorithms soon. Timing post content seems to be the most difficult thing and differentiating attention also. The main problem will be aggregating and processing it in a timely manner and without considerable lag. We'll see where this idea goes.
01 April 2014
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.
21 March 2014
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.
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.
18 January 2014
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.
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.
31 December 2013
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.
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.
Subscribe to:
Posts (Atom)