What languages should I consider for my monthly programming analysis articles?

[Sane]

I'm not going to answer your poll, because I don't do programming, but I just wanted to say that this sounds like a great idea. I don't entirely know what you have in mind, or what such an entry would look like, again, because I don't do programming, but it sounds to me like it might get more attention and interest (and sounds suitable as well) to do it in this forum rather than hidden in your journal. Unless you don't want discussion or comments. It just seems that you could write up your thing, and then others could chime in if there were better ways, other related issues, ask questions about your approach and thoughts, etc.

Thanks for the suggestion. I didn't think it would be acceptable to post it in the actual forum, but if it sounds all right to you I'll do just that.

Tomorrow, I think I may actually be able to get started on this. It looks like I'll be doing C, unless I hear a bundle of other opinions in the mean time.

 

[0rthodontist]

It really sounds like you're going nowhere with this. I think you've got the idea that one method is going to be "better" than the other. "It's all relative". There's no difference. Really. Both ideas lend themselves to the same functionality, and they both require the same logic. A class appears differently than a structure being passed around to similar functions, but they are both accomplishing the same task in the same way. They are both means to the same ends. It's like trying to argue a car is better than a bike: sure, one can seem much better than the other, but its all relative to what your needs demand.

Your needs always demand good design. The publish/subscribe pattern is is objectively better for the reusability, maintenance, and readability reasons I mentioned, and has no disadvantages.

 

[Sane]

Now you're just being silly. Of course it has disadvantages. Just to make a point, here's several reasons why an associative array could be the wrong choice, some of which apply to the case that branched this whole discussion.

1) Memory Usage

Defining an associative array requires that memory is allocated to define the association between the key and the value. Retrieving the attribute of a class does not include any unecessary declarations.​

2) Dynamicly Growing Association

In a class, more attributes may be declared as more methods are executed. To allow these variables to be accessed by an associative array, the associative array would need to be updated with each addition of a new variable.​

3) Protecting Against Memory Leaks

If any values inside the associative array are dynamically allocated, extra precautions must be taken to make sure all of the memory is freed after it is not needed.​

4) Repetitive Instances

If the same associative array is being declared in different sections, to be used for the same purposes, it would be much simpler to retrieve the attributes of a class (in the event that the associative array can not be pushed into a function or globalized).​

5) Oversized Declaration

If an associative array needs hundreds (or thousands) of attributes packed into it, it would be grotesque to see it written in code.​

6) Unexpected External Association

In some specific instances, attributes of a class may be titled by previous input into the class's methods. Then this data will need to be retrieved by using the same input (or key). To do so with an associative array, would require the value of each key to be a pointer to the attribute in the class, which requires that you have a way to get access to the address of the variable you don't know the location of in the first place. You would need to go out of your way to resolve this, or the class would need to know the user requires this functionality.​

7) Promoting Readability

Rather than declaring these potentially monstrous arrays that will need to be changed to conform with code updates, one can just grab the attributes of the class. This is much more readable, and manipulatable.​

All in all, there's nothing wrong with grabbing the attributes of a class dynamically. In fact, I find it to be the better alternative. It's more readable, and it only requires a simple expression resolution and hash. No slower than an associative array. And without the unecessary prerequisites and post-condition assertions.

Have I made my point yet?

 

[0rthodontist]

1) Memory Usage

Defining an associative array requires that memory is allocated to define the association between the key and the value. Retrieving the attribute of a class does not include any unecessary declarations.​

In this case, 8 memory addresses are stored. That's about 32 bytes. (I can't wait to hear you press the point that no, it's not 32 bytes, it's actually 97 bytes! In that case I'll have to agree that 97 bytes is far too much overhead and not feasible unless you have a workstation.)

(not a word about memory needed to store variable names as strings) (oops)

2) Dynamicly Growing Association

In a class, more attributes may be declared as more methods are executed. To allow these variables to be accessed by an associative array, the associative array would need to be updated with each addition of a new variable.​

This is known as the "subscribe" operation. What's your trouble with it, too much processing time? You're right, string parsing is much faster than writing a memory address to an array.

3) Protecting Against Memory Leaks

If any values inside the associative array are dynamically allocated, extra precautions must be taken to make sure all of the memory is freed after it is not needed.​

Yes, this might be a problem if Javascript didn't use garbage collection.

4) Repetitive Instances

If the same associative array is being declared in different sections, to be used for the same purposes, it would be much simpler to retrieve the attributes of a class (in the event that the associative array can not be pushed into a function or globalized).​

Do you have a good reason in mind why you might not be able to increase the scope of a variable in javascript to do what you want?

5) Oversized Declaration

If an associative array needs hundreds (or thousands) of attributes packed into it, it would be grotesque to see it written in code.​

As I explained (and you would know if you had looked up publish/subscribe) each object has a subscribe operation, typically in its constructor, that adds itself to the array. The function will then notify all subscribed objects (in this case giving them a message to hide themselves) when some event happens. The array is not written out.

6) Unexpected External Association

In some specific instances, attributes of a class may be titled by previous input into the class's methods. Then this data will need to be retrieved by using the same input (or key). To do so with an associative array, would require the value of each key to be a pointer to the attribute in the class, which requires that you have a way to get access to the address of the variable you don't know the location of in the first place. You would need to go out of your way to resolve this, or the class would need to know the user requires this functionality.​

Once you understand how publish/subscribe works, you will not have this confusion.

7) Promoting Readability

Rather than declaring these potentially monstrous arrays that will need to be changed to conform with code updates, one can just grab the attributes of the class. This is much more readable, and manipulatable.​

Again, if you had bothered to learn what "publish/subscribe" is, you would not have said this.

-----------------------

Probably the most important reason to use the publish/subscribe design pattern is that you can give your variables readable names, instead of "panel1" "panel2" etc. This eases programming, debugging, and everything else.

Although, the other advantages I mentioned are also important, especially in larger projects.

 

[Sane]

Oh my god. You can't be serious. >_>

If I have some free time tomorrow, I'll show you the differences, by making one program with and one without. I'm not sure if it would be worth it, you seem waaay too heart-set on whatever you've been taught.

@_@

 

[0rthodontist]

Before you try something like that, you might, as I suggested, actually look up the publish/subscribe pattern, because you've shown me that you don't know how it works. Here's a place to start:
http://en.wikipedia.org/wiki/Observer_pattern

 

[chroot]

You're right, string parsing is much faster than writing a memory address to an array.

You're kidding, right?

- Warren

 

[mgiddy911]

Well since you can't do Java I'd rather see Python, Idk if i can change my vote or not..
And also in response to the post about programming an associative array being monstrous if the array needed to be large, Couldn't an Array list do the same, and grow to be what ever size was necessary, the code would be a lot easier(in my opinion) to read

 

[0rthodontist]

You're kidding, right?

- Warren

Yes, I was kidding.

 

[0rthodontist]

By the way, on rereading that post of mine I think it was kind of mean, for which I'm sorry.

 

[-Job-]

I would be very surprised if you could refer to variables by their string representations in Java.

You can if you code for it. It's not available by default. The difference is that, in Java, Compiling and Running are separate processes. In interpreted languages they're done at the same time, so its possible to give a program access to its own Symbol Table, for example, which will be used as reflection.
Whether or not it's good design depends on how you use it, like anything else. Reflection is very powerful and i think you'll change your mind when you start to use it more often (assuming you're not).
In C#, a non-interpreted language, which can either run on a VM or compile natively, reflection is available, which makes it pretty much like a Java with reflection (it's very close to Java).
One use of this is to connect XML portions of a program with the actual code. For example, in ASP.NET there is a set of available Web Controls, such as a DropDownList, TextBox, etc. Or you can create your own Custom Controls. These controls are placed in a page just like any HTML control, such as:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="Default" %>
<html>
<body>
	<form runat="server">
		<input id="RegularHtmlControl" type="text" />
		<asp:DropDownList ID="MyASPWebControl" runat="server" OnSelectedIndexChanged="MyEventHandler" />
	</form>
</body>
</html>

Each page has a code file behind, in this case a C# file called Default.aspx.cs. The important part is

OnSelectedIndexChanged="MyEventHandler"

Which assigns an eventhandler to the SelectIndexChanged event. At runtime what happens is that the aspx page is parsed, the DropDownList control is rendered into HTML and, using reflection, the event handler "MyEventHandler", defined on the code side, is registered with the control.
Reflection can be used in this way to combine XML and Compiled code, for example.

 

[Hurkyl]

You can do this in Java? How?
...
I would be very surprised if you could refer to variables by their string representations in Java.

See java.lang.reflect.

 

[Hurkyl]

One use of this is to connect XML portions of a program with the actual code. For example, in ASP.NET there is a set of available Web Controls, such as a DropDownList, TextBox, etc. Or you can create your own Custom Controls. These controls are placed in a page just like any HTML control, such as:

You can do that with java. Have you heard of J2EE, and JSPs?

 

[Hurkyl]

Did you think I was saying anything other?

Well... yes. Your complaint seems to change with every post.

What if you decided you wanted more descriptive names for your panels than "panel1," maybe something self documenting like "headerpanel"?

If you were working on a project that allowed you to give names like that, then obviously one would write HidePanel to be able to work with those names. Duh. It almost sounds like you're arguing just for the sake of arguing.

This is an excellent programming practice which is completely incompatible with code referring to its own variables names as strings.

Um... "headerpanel" is a string, you know.

What if you wanted to do two different things?

Are you seriously objecting to HidePanel because the only thing it does is hide panels?

This is (to a first approximation) the publish/subscribe design pattern.

A good design pattern applied to the wrong problem is a bad programming practice.

The publish/subscribe pattern is is objectively better for the reusability, maintenance, and readability reasons I mentioned, and has no disadvantages.

Do you seriously think that:

(1) Designing, debugging, and maintaining your pub/sub architecture.
(2) Creating and documenting a panel hiding topic.
(3) Designing, debugging, and maintaining a panel hider object.
(4) Creating the panel hider, and subscribing to the topic.
(5) Every time you create a panel:
(5a) Connecting to the panel hiding topic.
(5b) Registering this panel.
(6) Every time you destroy a panel:
(6a) Connecting to the panel hiding topic.
(6b) Unregistering this panel.
(7) Every time you want to hide a panel:
(7a) Connecting to the panel hiding topic.
(7b) Publishing the name of the panel to the topic.

(I'm not even sure there is a way to do 6 reliably)

is easier to maintain and read, and has no disadvantages over:

(1) Designing, debugging, and maintaining a function that hides panels.
(2) Every time you want to hide a panel:
(2a) Pass the name of your panel to the function?


Certainly there will be situations where doing this via pub/sub would be desirable. But it baffles me that you think pub/sub would commonly be the right way to accomplish this task, let alone always.


(and besides, if you were using any sort of pub/sub architecture, I would expect HidePanel to be the function called by the object that consumes the hiding messages to actually hide the panel)

Yes, this might be a problem if Javascript didn't use garbage collection.

You can't garbage collect it unless you remember to unsubscribe, so that it's entry has been removed from the associative array.

 

[-Job-]

You can do that with java. Have you heard of J2EE, and JSPs?

Yes, i have. But the idea of a server application running on a VM doesn't excite me. Other than that it's fine, and it's very close to ASP.NET/C# (which i admit copies a lot from Java), but Java's portability in this case is not particularly useful. I'm not aware of a compiler for Java that compiles into native machine code, rather than VM code. I would imagine there would be one around.
It would be nice, after coding in Java, to be able to decide whether i want my program to run on the VM or not.

 

[Hurkyl]

I'm not aware of a compiler for Java that compiles into native machine code

See http://en.wikipedia.org/wiki/Just-in-time_compilation

Sun's HotSpot VM (the one that comes with JDK 5.0, I believe) does this by default. (I don't know how long it's had this capability) The javadocs call it an "Adaptive compiler".


Oh! The wikipedia page suggests that .NET is doing this too.

Java's portability in this case is not particularly useful.

Are you sure? Maybe it would be more clear if I knew the exact circumstance you're imagining.

In the case I'm imagining, nonportability means you're locked into a particular architecture when it comes time to upgrade, and extra headaches if your network isn't homogeneous.

 

[-Job-]

I mean that the JSP or J2EE server application is running only at the server. There's not much point in having a portable application if it's only running in a single location.
Maybe it's nice to be able to move from a Windows to a Linux server environment, but it's not something that's going to happen a lot, and not worth the overhead of the VM, i don't think.

.NET uses JIT compilation, I didn't know this was available for Java. Java certainly gets a lot of credit from me for pretty much defining a lot of today's standards and technologies.

 

[0rthodontist]

You said a lot of stuff, Hurkyl. Thank you for pointing out that Java feature; I had no idea Java could do that. However besides that I would like to reply only to this comment, because it seems pretty far from what I thought this conversation was about and I want to make sure that we're even talking about the same thing:

If you were working on a project that allowed you to give names like that, then obviously one would write HidePanel to be able to work with those names. Duh. It almost sounds like you're arguing just for the sake of arguing.

I'm talking about the following code:

function HidePanel(i){
	this["Panel" + i].style.visibility = 'hidden';
}

How would you rewrite this to work with descriptive panel names? Something like

function HidePanel(str){
	this[str].style.visibility = 'hidden';
}

?
But then you're allowing yourself to have an argument which is not numeric. Why not simply write

function HidePanel(pan){
	pan.style.visibility = 'hidden';
}

?

More specifically, what I am objecting to about the function as written with a numeric argument is that it forces all panels to adhere to the naming scheme "panel1" "panel2" panel3" etc. I have been describing reasons why this is not a good idea. If the panels are not restricted to this naming scheme, then you would use something like a publish/subscribe framework in order to write the function with a numeric argument.

Does this clarify things?

 

[-Job-]

Any of the variations you suggested are acceptable. But if you wanted to keep a numeric parameter (for whatever reason) you could still do:

Panels = ["Panel1", "MyPanel", "AnotherPanel", "Panel-5"];
function HidePanel(i){
	this[Panels[1]].style.visibility = 'hidden';
}

The original idea was to avoid the switch statement. I' was thinking HidePanel would be a function of some object. This object would have its own Panels which we don't really care to expose to other objects, for encapsulation, so we don't have access to their names or references.

 

[Hurkyl]

How would you rewrite this to work with descriptive panel names? Something like

function HidePanel(str){
	this[str].style.visibility = 'hidden';
}

?

That's exactly what I was thinking.

But then you're allowing yourself to have an argument which is not numeric.

Actually, nonnumeric arguments were already allowed; -Job-'s original code snippet could be invoked as HidePanel("header"), and the panel named panelheader would be hidden.


As for passing the name of the panel versus an actual reference to the panel... I would ask the people who would be using the function what they prefer. (And I must admit... in this context I would probably prefer to pass by name, especially if I didn't know any javascript)

If the panels are not restricted to this naming scheme, then you would use something like a publish/subscribe framework in order to write the function with a numeric argument.

I don't see how pub/sub is applicable to this at all.

 

[Sane]

Wow, has this ever gone off-topic. And at 4 for 4 currently in the poll, I guess I should just wait until there is a larger sample of votes before considering what language to use.

"And now we play the waiting game."

 

[robphy]

If the topics and examples aren't too hard or too specific, it might be good to see both... by you doing one language and having someone else show the equivalent code in the other language.

...just a thought
...and a bump to get someone to possibly break the tie.

 

[Sane]

If the topics and examples aren't too hard or too specific, it might be good to see both... by you doing one language and having someone else show the equivalent code in the other language.

I did, at one point, consider this. However, I also realized that different programming languages, especially those as contrasting in approach of design as Python and C, will require different approaches to piecing together the code. It would apply constraints on the effectiveness of the programming to force myself to program each piece in two (or more) substantially different programming languages.

 

[CRGreathouse]

First, I think that your idea is a good one, Sane.

Second, I don't see any reason you should limit yourself to a single language: write one article in C++, and the next in something else. (If a particular design works well in two languages you could do them in parallel as robphy suggests.)

 

[Sane]

First, I think that your idea is a good one, Sane.

Second, I don't see any reason you should limit yourself to a single language: write one article in C++, and the next in something else. (If a particular design works well in two languages you could do them in parallel as robphy suggests.)

That seems viable. One thing I wanted to try is have each article build up the foundation for an entire project. If I were to change languages, it would have to be at the end of every topic change. Another goal was to provide a medium to learn the language well, and see what can be done. So, yet again, changing languages would have to be gradually done between every 2 or 3 articles.

I like the idea! I'm considering it, since different programming languages have different advantages for every project. I can see myself switching between PHP, Python, C and maybe even some specifics such as SDL, CherryPy, WinSock, and the Win32API. This way, I'm not limiting what people can expect.

I'm thinking this will start to be planned out in greater detail and structure, before the new year. Then I may start writing, depending on the circumstances, by January or February.