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

[Sane]

I'm considering starting a journal, where every month I post an article that analyzes some aspect of programming subjectively. The article will consider a problem, analyze it in depth, and delve into a solution with snippets. All the while, it will hopefully teach readers about some more advanced theoretical concepts in programming, given that the reader has the fundamental basics of the language covered. Simultaneously, the article will explain the code to those that are just beginning to learn the language and implicitely define any vital terminology and mathematical concepts above the level of Calculus.

I am not claiming, in the slightest, that I am one of the top programmers here. I definitely don't believe that. However, I know I have information that I can share and hopefully help others with.

If you like my idea, and would honestly like to see it in action... I need your genuine response to this idea. I really don't feel like wasting my time because a couple of people thing it's "neat" or "useful". If people feel they could benefit from this, please let me know! I'd be more than happy to help some people out with this monthly food.

I have attached a poll at the top for the language which you think I should consider writing the articles for. I have considered the languages Python and C, because I think I may enjoy writing it more. Doing a language like PHP would consider practical applications of these programs, more than it would actually incorporate theoretical concepts of mathematics and computer science. This, unfortunately, strays away from the purpose of these articles. You can find documentation for languages like PHP anywhere, that's not the point of this.

C and Python can both be looked at very closely. C is the industries' most commonly used language two years consecutively, and a vital language for any person interested in programming, to know. I'd also expect more people here to know it than any other language.

Python, although the more lesser acknolweded, is the steam train of programming. You can never stop finding useful imports or ways to approach a problem. A while ago, I posted on another forum "500 ways to program numbers 1 to 10", a thread where the main goal was to come up with as many ways to output the numbers 1 to 10 in a programming language of your choice. About 80 of those posts were by me, and almost every one was written in Python, approaching the problem differently and uniquely each time.

The advantage of Python over C is we can also dive into more concepts like object-oriented programming with inheritence, metaclasses, functions that modify themselves, and the list goes on. I'm just a bit iffy about doing Python because I'm afraid not as many will tune in or benefit from the endeavour.

Please do tell me what you honestly think.

- Sane

 

[0rthodontist]

Sounds like a good idea! I'd like to see Common Lisp. You've got more interesting language features with that than with most anything else. Haskell is prettier but not as powerful . Besides, the world needs more functional programmers.

 

[Sane]

Well, the problem with choosing an understudied and underused language like Lisp or Haskell, is not as many people will be able to draw the information as easily from the article. Examples will not do them any justice. As well, readers would have a more difficult time applying what they've learned, and even finding the article online in the first place. I doubt many people go looking around for articles written in Haskell or Lisp.

But do consider, that C is a functional programming language. Although it can synthetically behave as an object-oriented language, it is indeed functional.

 

[0rthodontist]

A functional programming language is one in which every function is well-defined given its inputs--every function is a mathematical function of its inputs. Haskell is a pure functional programming language. C is not a functional programming language. Technically Lisp is also not a functional programming language, but it shares many features with pure functional programming.

Lisp is an incredibly well-studied language, maybe the most well-studied language, having been around far longer than all but one language in current use, and having traditionally been used in largely academic settings. Lisp is very different from most other languages, and that alone makes it worth studying.

If you ask me, inspiring one programmer to use Lisp is better than drilling 5 programmers in C.

 

[Hurkyl]

As much as I like category theory, it's hard to imagine wanting to programming in it. :tongue:

I agree that it's weird to hear C called a functional language -- that said, you can do functional programming in it.

Interestingly, the C++ template mechanism is purely functional, and the STL encourages functional approaches to problems. (unfortunately, you still have to go to third-party libraries to get all the useful primitives you'd want)

 

[Sane]

I know C is not used as an example for representing functional programming languages, but it can deliver the same behaviour in some respects. For example, you could program Python's map function in C, by using function pointers, which replicates a higher order function. However... it's not intentened to be as functional as certain languages like APL or Haskell.

 

[mgiddy911]

I would absolutely love to see this in Java, I am interested n learning mathematical programing in Java for applications to Physics and Math

 

[-Job-]

It sounds like a good idea. I think a language that has some interesting features is Javascript.
One of my favorites is eval(str), which evaluates and runs a string of code.
An object's methods and properties are indexed by name, so you have true reflection. For example, you can do:

MyObj.MyMethod(param1)

or you can do:

MyObj["MyMethod"](param1)

So you can turn this:

function HidePanel(i){
	switch(i){
		case 1:
			this.Panel1.style.visibility = 'hidden';
			break;
		case 2:
			this.Panel2.style.visibility = 'hidden';
			break;
		case 3:
			this.Panel3.style.visibility = 'hidden';
			break;
		case 4:
			this.Panel4.style.visibility = 'hidden';
			break;
		case 5:
			this.Panel5.style.visibility = 'hidden';
			break;
		case 6:
			this.Panel6.style.visibility = 'hidden';
			break;
		case 7:
			this.Panel7.style.visibility = 'hidden';
			break;
	}
}

Into this:

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

You can also store functions in variables and pass them around, for example:

Alert = function(){
	alert('hello world');
}
//you can assign to event handlers
//the following sets an object's click to alert 'hello world'
MyObj.onclick = Alert;
//you can call it whenever
Alert();
//you can pass it along as a parameter to some other function
function CallFunction(func){
	func();
}
CallFunction(Alert);

All of these features allow you to compress your code, for example, or do some interesting recursive or self-writing functions.

I would be more willing to read something about Python for example, than C or Java since of these 3 Python is the one i haven't used.

 

[Sane]

I would absolutely love to see this in Java, I am interested n learning mathematical programing in Java for applications to Physics and Math

Unfortunately, I've never actually bothered to look at Java myself. Haven't liked what I've seen. :yuck:

It sounds like a good idea. I think a language that has some interesting features is Javascript.

...

All of these features allow you to compress your code, for example, or do some interesting recursive or self-writing functions.

I would be more willing to read something about Python for example, than C or Java since of these 3 Python is the one i haven't used.

That's the beauty of a high level language. You'll see these ideas to be even more apparent in Python. You've noticed the desired intentions of a good high level language: elegance, clarity, and simplicity. That is what Python is all about.

The high-level language aspect of Javascript would not be a good reason to look at it, since javascript is used as a means to an end, not an end in itself. We use it for applications in dynamic webpage content manipulation, when the alternatives are either impossible or irrational. Nothing more. It's not going to be a language I use to talk about implementing crytography or BSTs in. That's the equivilent of trying to use your lawn mower, in order to clear snow from your driveway. :uhh:

Furthermore, wouldn't it be better for this to be a language that you already know? You should realize that this isn't a tutorial for the language itself. It's about learning how to combine computer science with advanced mathematics (and some Physics, if I have the time). You would want knowledge of the language first. This is why I'm leaning a bit more towards C.

 

[0rthodontist]

Into this:

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

What if you change the name of one of the panels?

 

[Sane]

What if you change the name of one of the panels?

What if you delete one of the functions from the program?

It's all relative. If you're going to change the names of the panels, then the program has to be changed with it. Hopefully, whoever's mantaining the website's design will know enough to keep it in the format expected by the javascript. Otherwise, it's not going to be changed.

 

[-Job-]

Exactly, besides, if i change the names around then the original code is not going to work any better either anyway.

Sane, whatever you write if it's well written i'll read it, i can read about anything in CS. Share the knowledge :).

 

[robphy]

I like Python.
For the tasks that I use it for, it's often cleaner than a comparable program in C and in Java, and less cryptic than Perl. When augmented with the http://www.vpython.org" ) is bundled with VPython, efficient matrix and array operations are optimized.

 

[0rthodontist]

Well, what if you remove a panel? I very much like the ability of a compiler (or interpreter) to detect when I'm trying to refer to a name that doesn't exist.

 

[Sane]

@0rthodontist : In that case, Mozilla will throw an informative warning in the top right corner (red alert icon). Internet Explorer will just say something's wrong in the bottom left corner (yellow alert icon).

@-Job- : I hope it can be well written. I have some good ideas of how to go about organizing this all, and what to talk about. I am already starting to write things down in my mind. Hopefully this can go well.

 

[nmtim]

I like Python too. Its OO is much cleaner and more complete than C++, and not just type-oriented.

Sane, I don't know if I would find your proposed column beneficial, rather than, in your words, neat or useful (I guess I don't see the distinction). That's kind of like trying to know if you like apples or if they're good for you without ever eating one.

Why not give it a try? If you've got something to contribute, you'll probably find an audience. I don't know how many physicists make their way down here, but in my experience, most physicists would be well served by seeing some more computational concepts.

Tim

 

[0rthodontist]

@0rthodontist : In that case, Mozilla will throw an informative warning in the top right corner (red alert icon). Internet Explorer will just say something's wrong in the bottom left corner (yellow alert icon).

But when will it throw the warning? I would be pretty surprised if it can detect the missing panel before it actually causes a runtime error.

 

[Hurkyl]

I would be pretty surprised if it can detect the missing panel before it actually causes a runtime error.

And you wouldn't want it to try -- part of the point of javascript is that you can generate pages on the fly, so a perfectly reasonable timeline would look like:

(1) Write a function that manipulates a panel
(2) Create the panel
(3) Invoke the function


edit: Thinking about it some more, I notice that the kind of error you describe is essentially the same thing that leads to a null pointer exception. Surely you're okay with those being runtime errors?

 

[-Job-]

But when will it throw the warning? I would be pretty surprised if it can detect the missing panel before it actually causes a runtime error.

Since there's no compiler for Javascript (interpreted language), you detect errors by running. Instead of compiling, you run your code in FireFox, for example. The exception is thrown at runtime.
Javascript is probably the least debug-friendly language though.

EDIT: I agree with Hurkyll as well.

 

[Sane]

@0rthodontist : I don't even get the point you're trying to make ...

@nmtim : Yes. Understandable. The distinction for me between "useful and nice" and "beneficial", would be the latter requires the reader to make use of the information and benefit, whereas the former only implies that it could be possible.

 

[0rthodontist]

The point I am making is that there's a good reason you can't do something like that in other languages like Java. You're using an array of panels--without declaring the array. If you or anyone else ever changes any of the variable names, even if they do a full refactor for that variable name, the program will fail to work. If any of the variable names get deleted, the program will fail to work. If you want to give a new panel a name, it better be of the form paneln, or your function won't work on it. If you want to make a new function that works in the same way on a different set of panels, you'll have to make up a new name for those panels, like secondpaneln, and they all have to have that name. It's better--conceptually cleaner, less liable to bugs, and more readable--to just put a bunch of panels in an array and have your function loop through the array.

 

[Sane]

You can replicate the same behaviour in any language. Even C and Java ... That idea isn't javascript exclusive buddy. Besides, your definition of "bad" gets much worse when you get into even higher levels like Python, for instance.

 

[Hurkyl]

0rthodontist: you seem to be bouncing around between several different points. :tongue: Did you think to interpret -Job-'s example as being for illustrative purposes?

without declaring the array

The array, here, is the associative array of the properties of this; it's declared by the language, so you don't have to do it automatically.

If any of the variable names get deleted, the program will fail to work.

But it won't be HidePanel's fault. HidePanel uses reflection to reference things, and it can only reference what it's instructed, at run-time to reference. That is one of the major benefits of reflection, actually: as long as the project sticks to its naming convention, HidePanel does not need to be altered to keep up with design changes. (such as the addition or removal of panels, the introduction and removal of new types of objects that might have panels, et cetera)

If you want to make a new function that works in the same way on a different set of panels, you'll have to make up a new name for those panels, like secondpaneln, and they all have to have that name.

Why wouldn't you use the same function for both sets?

 

[Moonbear]

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.

 

[0rthodontist]

The array, here, is the associative array of the properties of this; it's declared by the language, so you don't have to do it automatically.

Did you think I was saying anything other? My point is that in Javascript you don't have to use an actual array, but it is bad practice not to.

But it won't be HidePanel's fault. HidePanel uses reflection to reference things, and it can only reference what it's instructed, at run-time to reference. That is one of the major benefits of reflection, actually: as long as the project sticks to its naming convention, HidePanel does not need to be altered to keep up with design changes. (such as the addition or removal of panels, the introduction and removal of new types of objects that might have panels, et cetera)

It would not need to keep up with design changes either if it keeps an array of the panels it's supposed to act on--simply add to the constructors a note that registers with the function. This is (to a first approximation) the publish/subscribe design pattern. And then, changing your "naming conventions" by removing a panel or adding a new one, will not break the code.

Why wouldn't you use the same function for both sets?

What if you wanted to do two different things? Or what if you wanted to do X to panel1, panel2, and panel5, and to do Y to panel3, panel4, and panel6? The "reflective" code doesn't look nearly as nice, with its own special cases, but the publish/subscribe design pattern doesn't even blink. Should you rename all your variables so that they are contiguous, so that your "reflective" code can handle them with loops? This isn't even possible sometimes and when it is possible (which is when the function dependencies of your panels can be represented as an interval graph) it's mindless busywork.

What if you decided you wanted more descriptive names for your panels than "panel1," maybe something self documenting like "headerpanel"? This is an excellent programming practice which is completely incompatible with code referring to its own variables names as strings.

 

[0rthodontist]

You can replicate the same behaviour in any language. Even C and Java ... That idea isn't javascript exclusive buddy. Besides, your definition of "bad" gets much worse when you get into even higher levels like Python, for instance.

You can do this in Java? How?

 

[Sane]

Associative array, hash table, or a custom wrapper around an object "get attribute" function (if such exists in Java). There are other ways too, to synthesize the exact same functionality.

 

[0rthodontist]

Yes, you can do it with an array, which is what I have been talking about as the much better alternative. I would be very surprised if you could refer to variables by their string representations in Java.

 

[Sane]

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.

 

[-Job-]

My point is that in Javascript you don't have to use an actual array, but it is bad practice not to.

Java and Javascripts are different environments. In Javascript you do what you can to shorten your code to speed up both the loading time and interpreter time. You can even benefit from your code being cryptic, because it makes it less likely to be stolen or reused.

In Javascript this issue comes up very often, it's good design against efficiency. I favor good design whever possible and use something like Jasob to optimize the code.

 

[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.​

:rofl: 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.

@_@