project languages

I think that maybe one of the reason’s I feel like I struggle when trying to think about how to start coding in java or python is that because there isn’t any specific area that they are oriented towards, I have to come up with the idea of what I’m going to do. It’s essentially the problem of writer’s block.

Somehow other languages that have an area that they somehow target are easier for me to deal with, essentially the language itself functions as a sort of writing prompt for me and gives me enough direction in how to think that I can direct my thoughts toward the possibilities of that language.

Languages that are so general purpose that they cause this confusion:

• java
• python
• clojure

Languages whose emphasis gives me direction:

• perl – text processing, system utilities
• awk – text processing
• tcl – gui utilities
• erlang – distributed computing
• prolog – graph problems, logic programming
• javascript (more by it’s limitations than it’s capabilities)

One of the things that I’ve been considering as I continue to evaluate languages is that while the various "messy" languages I’ve mentioned previously, tend to have areas of application where they excel, and that is useful to me in guiding my initial thinking, I worry about whether they are extensible enough to handle the areas outside their areas of advantage. that is, at some point any substantial application will grow past the sweet spot of a languages. at that point, will they still be a better match than the "general purpose" languages that don’t give the initial boost?

blogging

I’ve been thinking about the blog stuff today. It’s been interesting to watch my own reactions to the reactions on i use ugly languages post. I don’t really like the way that I’ve been reacting emotionally. It’s helped me to think about what makes good writing, but it also makes me somewhat depressed because the way that I normally write is not actually conducive to useful reading for people.

Part of it is that I’ve been trying to "journal" and that for me that means writing large amounts of fairly unstructured text. what I really need to do is take those thoughts that I come up from that exercise and then rewrite them into a structured presentation. Basically there is a difference between an online journal and a blog. My writing is mostly an online journal rather than a useful structured presentation. I’ll need to work on that if I want it to be useful to anyone else.

I’m considering making the journal entries private or draft status so they aren’t public. And then the hope is that I can use the information or thoughts that I put in the journal entries to write more useful posts that are actually helpful to people.

There’s almost no way for someone to look at my journal entries and actually glean useful information quickly since they generally lack identifying headers or any other guideposts to the content.

prolog

I’ve been messing around with the blog a fair amount today, so I haven’t made much progress on prolog. I did read some of the book seven languages in seven weeks. I read about 1 day’s worth of the chapter on prolog, and skilled the other 2 days, and then skimmed the chapters on erlang, clojure, and haskell.

I’ve been considering whether the idea of using prolog to implement a type inferencing system. It seems like it would be a pretty decent match. I’m not sure if the parsing necessarily has to be done in prolog, but the symbol recording and resolution seem like they’d be made for its logical inferencing capabilities.

tcl

I’ve mentioned that I feel afraid of trying to do large scale programming with Tcl. but I’m wondering what I could do if I just tried to push it as hard as I could, I wonder what could be achieved using Tcl. Now that Tcl 8.6 has been released, it might be a good time to push Tcl to see what it can do with the new features. The new OO system and tail-call support seem interesting.

Perhaps because Tcl 8.6 was just released a few days ago, I’ve been considering it a lot and wondering how much I could accomplish using it.

I don’t know if it’s a good idea to really hold onto its gui capabilities as a reason to prefer it. The computing landscape is changing so drastically that expecting a cross-platform gui toolkit to be viable, seems like an increasing stretch. Really, given mobile development, the only real cross-platform, cross-device solution, appears to be html/javascript based solutions.

So, the question I find myself asking is, if you take gui out of the equation, what makes Tcl still a compelling language. If i can answer that, I would have a lot more confidence in my analysis of whether or not to use it for projects.

To me, it still feels like tcl brings a lot to the table. In any pc based environment, its command shell like scripting capabilities still seem like a big win. It packages a remarkable amount of capability into a pretty small executable footprint, especially with tclkits and starpacks.

If I knew how to get it to interface easily with c++ code (not just using a c interface) I think I would find it quite compelling. The options I’m aware of are critcl, boost::tcl and boost:tk (i think), and swig. i don’t know about the relative stability levels of those solutions. I think there was also at one point an ffi interface. I don’t know the current status of that.

Especially in the realm of embedded scripting, Tcl has been challenged successfully by Lua, but I think Tcl still remains as a viable candidate, especially where extra functionality is needed in the scripting layer beyond what the Lua core provides.

I think Tcl can be pressed into filling the same application areas that Python or Perl do. I’m not sure it wouldn’t be a struggle in some cases, but it could do it. In addition, it does actually have some advantages over other scripting languages. It is probably the easiest scripting engine to deploy given the tclkit architecture. And given that it can be used in the same application areas as Python and Perl, plus effectively in the embedded arena, it might actually have the widest applicability if one wanted to just focus on one scripting language.

It has areas where the syntax gets annoying, and the list commands have been an anachronism that unfortunately probably cannot be molded into the newer paradigm represented by the dict command without breaking compatibility. However, with some discipline, it is probably capable of dealing with whatever you want to throw at it.

I may have to give it a chance again.