Programming languages

[Paul C. Anagnostopoulos]

My favorite part of computing is discussing programming languages (well, and machine architectures). So I thought I start a thread on random programming language features and related chit-chat. Toss in whatever you feel like.

A couple of items to start things off:

Perl is totally ridiculous. What are the $, @, % symbols, and what are they called?

Why does every language have 13 different kinds of strings for different purposes? Do the designers forget about escape sequences when they want a new feature? If you want a block text string for text messages, you don't need to invent a new kind of triple-quoted string!

It is absurd to use whitespace for structuring programs. Python go home!

~~ Paul

[volant]

I'm glad I don't have to program in C++ no more, yay for DarkBASIC!

[Paul C. Anagnostopoulos]

I found my year with C++ to be an unpleasant experience. How many meanings can you assign to the keyword virtual?

~~ Paul

[El Greco]

mov ax, word ptr [16bit_Asm]
movsx eax, ax
mov dword ptr [El_Greco], eax

[Zep]

You know as well as I do, Paul, that DCL is the only programming language...

[Stimpson J. Cat]

I think C++ is pretty cool. Once you get used to classes, and understand the language well enough to understand what is, and is not, efficient, it is a wonderful language for numerical programming.

Right now I am working on a set of classes for integrating networks of oscillators. The object oriented capabilities of C++ allow me to write my code in a general way, that will allow any sort of oscillator I want to be added to the network, along with any topology and coupling scheme I might need. At the same time, then control C++ gives over things like memory management, and mathematical operations, allows me to achieve a level of performance that would simply be impossible with any other object oriented programming language.

In fact, I think the reason C++ takes so much flak, is because people don't realize its strengths. Sure, it is not designed from the ground up as an object oriented language, so hard-core object oriented types are going to prefer languages that are. Likewise, C gurus often complain about things like overhead in C++, when the fact is that usually such overhead is the result of sloppy programming, rather than any flaw in the language. When used properly, C++ can be used to write generic algorithms which are just as fast as specialized algorithms in C.

Basically, if you need the kind of power and speed that a language like C gives you, and also want the advantages of an object oriented language, then I think that C++ is the way to go.


Dr. Stupid

[Paul C. Anagnostopoulos]

Well Zep, DCL is one fine language. :D All I ask from a "decent" programming language is real strings, hash tables, and syntax that isn't too atrocious. So much for C.

Stimpy, my objections to C++ are mostly concerned with the informality of the language and the sloppiness of the implementation of the concepts. I'm just a crotchety language formalist at heart, I guess. Comes from learning software engineering in the '70s. I agree that it's efficient when you understand what you're doing. I was trying to write a precompiler for C++ to make writing lots of classes easier (for a bioinformatics system), but the butchered semantics of virtual classes, automatically generated methods, and the inheritance mechanism made it nearly impossible. I prefer languages like SmallTalk, Common Lisp, and Ruby that have better-integrated and more formal object systems.

Of course, I grew up without objects, so often I wonder why I need them at all.

http://www.geocities.com/tablizer/oopbad.htm

But never let it be said that I don't put my programming time where my big mouth is. Come January, my new language, Gossip, should be ready for prime time coding. Who says everyone can't have their own personal language? Shall I foist it on the world?

~~ Paul

[Paul C. Anagnostopoulos]

Two atrocious bits of syntax from C that have found their way into other perfectly good languages:

The equal sign (=) for assignment. Come on! The world uses the equal sign for equality. Of course, this one isn't C's fault.

A leading zero for an octal number (0123). Excuse me for wanting leading zeroes on some decimal numbers. Lazy bastages.

~~ Paul

[mindless]

im interested to hear what your views are on Java.

[Paul C. Anagnostopoulos]

I don't know Java. Amazing in this day and age, I know.

~~ Paul

[69dodge]

Originally posted by Paul C. Anagnostopoulos
Come January, my new language, Gossip, should be ready for prime time coding. Who says everyone can't have their own personal language? Shall I foist it on the world?Sure.

What's it like?

[Zep]

Originally posted by Paul C. Anagnostopoulos
Well Zep, DCL is one fine language. :D All I ask from a "decent" programming language is real strings, hash tables, and syntax that isn't too atrocious. So much for C.

Of course, I grew up without objects, so often I wonder why I need them at all.

http://www.geocities.com/tablizer/oopbad.htm

But never let it be said that I don't put my programming time where my big mouth is. Come January, my new language, Gossip, should be ready for prime time coding. Who says everyone can't have their own personal language? Shall I foist it on the world?

~~ Paul Heh heh! I grew up on Pascal, etc, as well. And COBOL, Fortran, Algol, PL/1, Snobol, Simula, etc, etc.

My own experience is that I believe that the vast majority of programming tasks even today do not require objects and their associated messiness. Most programming tasks are still mind-numbingly boring and simple and can be done in a few lines of plain code in a simple programming language that is written in a few minutes, tested in under an hour, and gets compiled into a tiny executable. Using objects and classes and all that is like using a Ferarri racing car to pull a plow - a fine tool but the WRONG tool for those common jobs.
{end-sermon}

Hey, send me a sample of Gossip! It might be very interesting!

[Neutron Jack]

Perl is totally ridiculous. What are the $, @, % symbols, and what are they called?Translation: I haven't bothered to spend ten minutes learning Perl, but I've decided that it's ridiculous.

[Cecil]

I'm fond of esoteric programming languages, especially Brainf*ck.

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<< This code displays "Hello World".

Brain**** is essentially an 8-instruction Turing-complete language. You have an array of bytes, and a pointer, initialized to the first byte of the array.

> increments the pointer.
< decrements the pointer.
+ increments the byte at the pointer.
- decrements the byte at the pointer.
. outputs the byte at the pointer
, inputs a byte and stores it at the pointer.
[ jumps past the matching ] if the byte at the pointer is 0.
] jumps to the matching [.

It's tons of fun to play around with.

http://en2.wikipedia.org/wiki/Hello_world_program_in_esoteric_languages has a great list of hello world programs in various esoteric languages; googling the name of the language along with "esoteric" will usually turn up a description of it.

Malbolge is worth a look; it's designed to be inhumanly difficult to use, and in fact no human has ever written a program unaided. The only program in existence is (=<`$9]7<5YXz7wT.3,+O/o'K%$H"'~D|#z@b=`{^Lx8%$Xmrkpohm-kNi;
gsedcba`_^]\[ZYXWVUTSRQPONMLKJIHGFEDCBA@?>=<;:9876543s+O<oLm
It displays "HEllO WORld" and was generated by a beam search algorithm. See http://www.acooke.org/andrew/writing/malbolge.html for details

Piet is also pretty interesting. Code is in the form of a square GIF image, and the colour values of each pixel or bounded area form instructions.

[69dodge]

Originally posted by Cecil
I'm fond of esoteric programming languages, especially Brainf*ck.

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<< This code displays "Hello World".No, just "Hello ".

(It has only six periods, none within a bracket loop, so how can it print more than that number of characters?)

[El Greco]

What I find amazing with users of HLLs, is that they often don't know what an 'object' is. Only a small percentage of HLL programmers understand what's exactly going on in memory when you create an object. And the concept of class is also vaguely understood.

[Zep]

Originally posted by El Greco
What I find amazing with users of HLLs, is that they often don't know what an 'object' is. Only a small percentage of HLL programmers understand what's exactly going on in memory when you create an object. And the concept of class is also vaguely understood. It doesn't matter to them - all that hype about the advantages of classes, etc, goes right over their heads. They just want to know how to make the next killer app or killer game more HOOO-AH!! Never mind that it's way bloatier than the current version... BUY MORE MEMORY & BUY MORE GRUNT will fix any problems! :)

[Wudang]

REXX (http://rexx.hursley.ibm.com) Fantastic language. When Mike developed it, he wrote the user guide first then forced the language to work the way it was described. It's so quick to knock out really good stuff. The parse instruction alone makes it worth while. You can get a free implementation for DOS/windows boxes.
For comparison, I've worked with COBOL, assembler, PL/AS, PL/I, korn shell, C++, pascal and others. They are the moon, Rexx is the sun.

[arcticpenguin]

Originally posted by Neutron Jack
Translation: I haven't bothered to spend ten minutes learning Perl, but I've decided that it's ridiculous.
I've spent quite a bit more than 10 minutes on it, and it is ridiculous. The language is inconsistent. The scientific programming community is turning to python.

[Paul C. Anagnostopoulos]

Neutron Jack said:Translation: I haven't bothered to spend ten minutes learning Perl, but I've decided that it's ridiculous.
You have no idea how much time I have or have not spent learning Perl. Now I ask you again: What are the $, @, % symbols, and what are they called? When I ask what they are, I'm not asking what they do; I know that. I'm asking what kind of entity they are.

El Greco said:What I find amazing with users of HLLs, is that they often don't know what an 'object' is. Only a small percentage of HLL programmers understand what's exactly going on in memory when you create an object. And the concept of class is also vaguely understood.
I don't think programmers are taught how machine works any more, are they?

Penguin said:I've spent quite a bit more than 10 minutes on it, and it is ridiculous. The language is inconsistent. The scientific programming community is turning to python.
Oh Lord. The next Mars probe will fail because a space gets dropped and changes the entire meaning of the program.

~~ Paul

[Cecil]

Originally posted by 69dodge
No, just "Hello ".

(It has only six periods, none within a bracket loop, so how can it print more than that number of characters?) Oops. I accidentally dropped the second line. It should be:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<
+++++++++++++++.>.+++.------.--------.>+.>.

:D

[Paul C. Anagnostopoulos]

69dodge asked:What's it [Gossip] like?
Well, it's pretty idiosyncratic. I haven't done much commercial programming for about five years. Everything I've done is for my work or friends, and it's all written in TAWK. TAWK is an enhanced AWK produced by Thompson Automation, which is defunct now, I think. It has a lot of features from other languages, including Perl. It's claim to fame is that it's compiled, not interpreted, and is vaguely efficient for a "scripting language."

I've extended TAWK with lots of additional library functions, but always fooled around with the idea of writing my own language on top of it. So I did. Gossip's syntax is sort of a blend of Pascal and C. It has flexible strings, enhanced patterns in which whitespace is ignored, all my favorite operators and looping constructs. arrays indexed by strings, multiple-value returns, and other goodies. And, of course, a neat library of functions, including a printf() replacement called format(), a la Common Lisp format.

It's missing lots of things because TAWK won't support them. For example, if I wrote a language from scratch, it would be an expression language: every construct is an expression that returns values. It also has no condition system, since TAWK has no captability for that. It has no objects, mostly because I'm not much of an object guy. However, if I did write a language from scratch, I'd probably make it pure object-oriented. Go figure.

Hey, if Jules can write Jovial, I can write Gossip!

Edited to add: I forgot to mention that Gossip has a full macro facility a la IBM Assembler H. There are two types of programmers: Those who write hairy macros and those who don't.

~~ Paul

[Mike]

Originally posted by Paul C. Anagnostopoulos
You have no idea how much time I have or have not spent learning Perl. Now I ask you again: What are the $, @, % symbols, and what are they called? When I ask what they are, I'm not asking what they do; I know that. I'm asking what kind of entity they are.

~~ Paul

In perl, they are called sigils.

http://dictionary.reference.com/search?q=sigil

So I guess they are a magicial entity.

[Paul C. Anagnostopoulos]

Yes, magical character is a good term. To quote Programming Perl, by Wall et al:... these types of variables are also preceded by funny characters.

~~ Paul

[jnelso99]

The best computer language that I know of is one with which I can get a job.

I've used C, C++, VB, TCL, and Java in a professional context, and C# on my own. Each one has its place, but I like C++ best, even though it has those nasty pointers in it (which still throw me for a loop every now and then). TCL is/was evil.

My view on OO is that if the app needs it, use it. If it doesn't need it, don't use it. I find that the use of classes tend to make the app easier for me to understand as a developer, especially if the app is a large-scale distributed app or complex 3d app.

[a_unique_person]

I have been programming for many years, also. Turbo-pascal, Delphi, Cobol, Rexx, Assembler (IBM), CLIST, ABAP, C, Basic, Shell Script, AWK.

One thing that annoys me no end is the loop. I cannot see any need for it, and it is often the cause of bugs. While reading up on functional languages, I was introduced to the concept of applying a function to an array of data. Makes much more sense to me. Iterating over an array is just monkey work.

OO is a good idea that has been badly thought out. Like I asked in the Database debunking thread, why hierarchical? The relational database still rules, the OO DB has died the inevitable death. This is because the OO abstraction of the hierarchy has been proven to be a dead one for any ongoing, developing information system. You get a hierarchy set in concrete, then you cannot change it. (Not without having to go through a lot of pain. I now know what they mean by "refactoring".

Relational, with it's denormalised data, can cope with any new addition to the scope of it's data, without having to junk the whole thing and rebuild everything, or have to depend on more and more pointers in alternate trees having to be built.

I have to go with the idea behind the dbdebunk web site, that the data should be dealt with first, after that comes the programming.

SQL was a good first attempt at a data programming language, but it is flawed. I look forward to seeing what they can do with the next generation data language, D, which is described in The Third Manifesto, http://www.thethirdmanifesto.com The product Dataphor is supposed to be based on that. http://www.dataphor.com. I have just downloaded the public beta, so I have not had a chance to see if it is worth it or not.

[Paul C. Anagnostopoulos]

AUP said:One thing that annoys me no end is the loop. I cannot see any need for it, and it is often the cause of bugs. While reading up on functional languages, I was introduced to the concept of applying a function to an array of data. Makes much more sense to me. Iterating over an array is just monkey work.
It would be interesting to see some sort of study comparing loop programming with functional programming. Functional programming may sometimes win with fewer bugs, but how often will it win with efficiency?

Also, check out a large, complex loop, perhaps nested, and then code it functionally. Not necessarily easier.

~~ Paul

[roger]

hmm, speaking only from my own experience, I can't remember many bugs that I've written due to mismanaging loops. I do use the STL functional calls when appropriate and when I think of it (for_each), but I've never found loops to be a great stumbling block (compared to things like pointers, which I now try to eschew as much as possible).

[a_unique_person]

I think that pointers are just another case of a loop, really.

As for complex loops, I think it is better to select the data up front that you wish to work on, using, say, SQL, then just apply the function to the resulting set.

[a_unique_person]

That is, what we really need is the concept of the table at a programming level.

[epepke]

Originally posted by arcticpenguin

I've spent quite a bit more than 10 minutes on it, and it is ridiculous. The language is inconsistent. The scientific programming community is turning to python.

:con2: Perl is a hacking language. I find it hard to imagine it being used in scientific computing, but there are things it excels at.

[epepke]

Originally posted by Paul C. Anagnostopoulos
AUP said:
It would be interesting to see some sort of study comparing loop programming with functional programming. Functional programming may sometimes win with fewer bugs, but how often will it win with efficiency?

Quite a lot of the time, actually. The Scheme standard requires tail recursion to work without using any extra memory, and many other functional languages have also adopted this idea.

Properly compiled functional code, using continuations rather than the stack, actually looks a lot more like tight assembly language than does C.

Of course, nobody cares, but still.

[a_unique_person]

Originally posted by epepke



Of course, nobody cares, but still.

I care. I just want to learn a new programming language I can stick to. One that removes a lot of the inconsistencies of procedural programming. And has a built in abstraction for the relational database model.

[Samus]

mindless: im interested to hear what your views are on Java. I don't know if this was directed at Paul, or everyone, so I'll respond. :)

I program in Java for a living. I happen to like it. In addition to being fairly simple to pick up (especially coming off of C++), they have published their API in a very simple, easy-to-browse format on the web. And, by formatting your class and method comments correctly, you too can generate HTML API documentation in one step. That is such a big deal to me, especially working on a project with a bunch of other programmers, because I don't have to wade through code to find the method name I'm looking for and its parameters.

I do wish Java had multiple inheritance, though. I've also heard about performance concerns about Java because you're not compiling your code into machine language. However, for any of the programming I've done, the non-GUI stuff runs seemingly just as fast as it would if I wrote it in C/C++. The GUI has a bit of lag time, depending on your computer's horsepower.

I have also done a bit of work in REXX, and I really liked it. Very easy to learn, quick, and the parsing capabilities are excellent.

[Paul C. Anagnostopoulos]

Epepke said:
Of course, nobody cares, but still.
Sure we care, man! Scheme is great. I don't think the problem is lots of function calls, but rather the way large data sets are handled.

AUP said:
I care. I just want to learn a new programming language I can stick to. One that removes a lot of the inconsistencies of procedural programming. And has a built in abstraction for the relational database model.
Try Scheme and/or Common Lisp.

~~ Paul

[ceptimus]

Whatever happened to Modular 2?

I wrote some quite big programs in FORTH at one time. Surprisingly easy once I got into it, but it configured my mind to work in reverse polish logic - which was bad for everyday life.

I like C now - I suppose I'm just used to it. I use the additional features of C++ sometimes, but I could happily live without them.

[epepke]

Originally posted by Paul C. Anagnostopoulos

Sure we care, man! Scheme is great. I don't think the problem is lots of function calls, but rather the way large data sets are handled.

I find a lot of people hate Scheme. I like it, but part of the reason for that is that I wrote an embedded Scheme for cinematic adventure game logic.

My "nobody cares" comment refers to the substantial prejudice against LISP-like languages back from the days when they really were poorly written and slow.

[epepke]

Originally posted by Stimpson J. Cat
Basically, if you need the kind of power and speed that a language like C gives you, and also want the advantages of an object oriented language, then I think that C++ is the way to go.

Objective C, on the other hand, is much more of a real O-O language along the lines of Smalltalk and still has C in it. It also has lightweight syntax and doesn't try to find fifteen thousand uses for the &.

But of course, in the industry, Objective C is mostly Mac and UN*X.

[Peskanov]

AUP,


I have to go with the idea behind the dbdebunk web site, that the data should be dealt with first, after that comes the programming.

SQL was a good first attempt at a data programming language, but it is flawed. I look forward to seeing what they can do with the next generation data language, D, which is described in The Third Manifesto, http://www.thethirdmanifesto.com The product Dataphor is supposed to be based on that. http://www.dataphor.com. I have just downloaded the public beta, so I have not had a chance to see if it is worth it or not.


I found your views very interesting. I have been arguing with most friends about how much I dislike OO programming, and how SQL, which is the total oposite, seems so clean, understable and powerful instead.
It's interesting to see that from the so-called 4th an 5th generation languages, only SQL seems to have an important impact in todays's computing world.

As a games programmer I see how OO forces the programmers to repeat tons of code everywhere. Usually OO defenders says this is bad design. I can't believe it anymore, OO programs always grows terribly fast, transforming in spaguetty in very few time.
In the other hand, looking games code, many times I think:
"How good would be to have all this data normalized and just say:
SELECT Targets FROM Agents, Terrain WHERE Agents.Type=ORC AND Agents.Sector=Terrain.Sector AND Terrain.SelectedByUser=TRUE
,instead of the horrible mess we have there."

Certainly I have to take a look at D.
I was looking prolog and mercury a bit, but while they provide the functionality of SQL (and are of general purpose) they lack that clear sintax.

[Paul C. Anagnostopoulos]

Ceptimus asked:
Whatever happened to Modular 2?
Modula 2. Too formal. Turns people off.

Epepke said:
My "nobody cares" comment refers to the substantial prejudice against LISP-like languages back from the days when they really were poorly written and slow.
Ah, right. It wasn't just the slowness, but also the lack of syntax. People love syntax. "Oh my, how am I ever going to balance all those parens?" Uh, get a pprogram editor.

If I was forced to eliminate all programming languages but one, Lisp would stay.

~~ Paul

[!Xx+-Rational-+xX!]

We have to forget about programming languages for a little! Woo-woos are trying to destroy science in the paranoral forum go defend it or else what we knew as science will turn into a bunch of *********** fairy tales!

[a_unique_person]

Maybe a programming editor does balance them, but I find it is conducive to good programming to be able to read an expression and understand it without having to balance all the brackets, even with the help of a computer.

[a_unique_person]

Originally posted by Peskanov
AUP,


In the other hand, looking games code, many times I think:
"How good would be to have all this data normalized and just say:
SELECT Targets FROM Agents, Terrain WHERE Agents.Type=ORC AND Agents.Sector=Terrain.Sector AND Terrain.SelectedByUser=TRUE
,instead of the horrible mess we have there."

Certainly I have to take a look at D.
I was looking prolog and mercury a bit, but while they provide the functionality of SQL (and are of general purpose) they lack that clear sintax.

I am with you 100% on this. I believe it is inherent in the hierarchical inheritance scheme of things in all OO programming languages that the inheritance means of reusing code must degenerate into uselessness.

[Paul C. Anagnostopoulos]

AUP said:
Maybe a programming editor does balance them, but I find it is conducive to good programming to be able to read an expression and understand it without having to balance all the brackets, even with the help of a computer.
As with any language, you get used to Lisp syntax pretty quickly. After all, the code you read has been balanced and indented to convey its structure.

~~ Paul

[Paul C. Anagnostopoulos]

If you like formal, incredibly verbose, theory-laden languages, then Eiffel might be your thing. Here is a function to do integer division by successive subtraction:


quotient (n, divisor: INTEGER): INTEGER is
require
non_negative_n: n >= 0
positive_divisor: divisor > 0
local
remainder: INTEGER

do
from remainder := n
invariant reversible: n = Result * divisor + remainder
variant decreasing_remainder: remainder
until remainder < divisor
loop
remainder := remainder - divisor
Result := Result + 1
end --loop

ensure
Result * divisor <= n and n < (Result+1) * divisor
end --quotient


How do I preserve indentation?

~~ Paul

[Leif Roar]

Originally posted by Peskanov
AUP,



I found your views very interesting. I have been arguing with most friends about how much I dislike OO programming, and how SQL, which is the total oposite, seems so clean, understable and powerful instead.

[SNIP]

In the other hand, looking games code, many times I think:
"How good would be to have all this data normalized and just say:
SELECT Targets FROM Agents, Terrain WHERE Agents.Type=ORC AND Agents.Sector=Terrain.Sector AND Terrain.SelectedByUser=TRUE
,instead of the horrible mess we have there."


However, SQL isn't a programming language, but a data query language. That really makes a huge difference. It's also very easy to write woefully ineficcent SQL calls - and even simple SQL calls have a fairly substantial overhead (at least for things such as games programming where CPU time is a limited resource.)

It would of course be nice to have integrated support for SQL in a language, but since just about any programming language that needs it have SQL libraries or other ways of making SQL calls, it doesn't really seem all that useful.

In my personal view, the best designed computer language I've seen is without doubt Ada95. It's easily as large as C++, but the various parts of the language just falls into a cohesive whole in a way that C++, to put it mildly, does not.

At work I have to settle for Java which is ... okay. It's got a base design that's decent and competently put together, but suffers from the messy C-like syntax and some rather haphazardly put together standard libraries.

[roger]

How do I preserve indentation?

~~ Paul [/B]Wrap it with code blocks. Meaning bracket code bracket to start, and bracket /code bracket to end - like the quote function


loop
do something
end loop

[Wudang]

Originally posted by a_unique_person
Maybe a programming editor does balance them, but I find it is conducive to good programming to be able to read an expression and understand it without having to balance all the brackets, even with the help of a computer.

Well I admit a degree of wimpishness here. I like pretty coloured editors as they help with assembler syntax, my SQL gets pretty hairy when it gets time to close the brackets on a 4-way union, and it's saved my ass quite a few times when I've had a horribly complicated string in rexx where I'm parsing quote marks.
And in my currrent job I have to use COBOL. What kind of language treats a . as an implied END-IF or END-PERFORM?

[roger]

Originally posted by Paul C. Anagnostopoulos
If you like formal, incredibly verbose, theory-laden languages, then Eiffel might be your thing. Here is a function to do integer division by successive subtraction:Actually, that looks a lot like what I do in C++ anyway:


int foo (int a, double b)
{
ASSERT (a > 0);
ASSERT (a < 5);
ASSERT (b > 1);
ASSERT (b <= 3.1415);

int d = calculate something

ASSERT (d < 4);
return d;
}



People who work with me sometimes start out by rolling their eyes, but you'd be surprised at how few bugs I have, and how easy it is to show somebody that they are passing incorrect stuff to me.

them: your code blew up.
me: <sigh> show me.
them: look
me:that's not a crash, that's an assert
them: huh
me: you passed in a parameter out of range.
them: oh...

Of course as much as possible I try to avoid using built in types but there are tradeoffs.

[Peskanov]

Leif Roar,


However, SQL isn't a programming language, but a data query language. That really makes a huge difference. It's also very easy to write woefully ineficcent SQL calls - and even simple SQL calls have a fairly substantial overhead (at least for things such as games programming where CPU time is a limited resource.)


Of course, I know. What it's interesting about SQL is how organizing your data on a given form (relational database), you are able to operate all of it with elegant and powerful sentences.
Yes, SQL it's not computationally complete, but this is not the question. The language AUP mentioned, D4, is computationally complete and uses the same data model (and includes the SELECT instruction).
Other languages I know like Prolog or Mercury (a form of prolog) also allow to operate on databases in a very natural way. Prolog is computationally complete as far as I know.

About the speed, yes it's true, but IMO this is always the cost of abstraction. It's common in all high level languages, like perl or prolog or python. There are exceptions but this is the norm I think.
In the other hand, the efficiency depends largely on the implementation of the language. Modern LISP is much more efficient than the initial versions. OCamel, a derivate of LISP usually appears as one of the fastest languages in most benchmarks.


It would of course be nice to have integrated support for SQL in a language, but since just about any programming language that needs it have SQL libraries or other ways of making SQL calls, it doesn't really seem all that useful.


In an utopic world, we would have one language to program nearly all. I am quite used to make programs using 2,3 or 4 languages, but it's a question of necesity, not preference. My current project uses C,Asm,Forth and Python.
As I said in my first post here, usually I am thinking how simply and readable my code could be using more powerful languages.


In my personal view, the best designed computer language I've seen is without doubt Ada95. It's easily as large as C++, but the various parts of the language just falls into a cohesive whole in a way that C++, to put it mildly, does not.


I have not seen much Ada, but I remenber it as a quite verbose language.
In general, I don't like micromanagement, I prefer to have big dose of implicit information in my code if this keeps it readable.

[Peskanov]

Roger, this is defensive programming as it best. :)
Finding the real code between all those asserts has to be difficult :D

[Paul C. Anagnostopoulos]

Thanks, Roger.

I like assertions, too. In my little home-brewed language, Gossip, I have an ASSERT statement:

assert pc_ok: pc <= *dir_seq;

It even requires a unique tag id (pc_ok) like Eiffel does.

However, Eiffel requires you to use a lot of that verbosity. Okay, I guess, if you like that sort of thing.

Peskanov said:
Finding the real code between all those asserts has to be difficult.

Nowhere near as difficult as trying to find the real code between all the silly comments people put in their files.

~~ Paul

[roger]

Originally posted by Peskanov
Roger, this is defensive programming as it best. :)
Finding the real code between all those asserts has to be difficult :D Perhaps, but I caught 2 bugs just between the time of posting that comment and this one due to my adding an enum value but not accounting for it in all my code :D

[roger]

Originally posted by Paul C. Anagnostopoulos
It even requires a unique tag id (pc_ok) like Eiffel does.What is the point/use of the tag id? (I've never used Eiffel).

[Leif Roar]

Originally posted by Peskanov
Leif Roar,
I have not seen much Ada, but I remenber it as a quite verbose language.
In general, I don't like micromanagement, I prefer to have big dose of implicit information in my code if this keeps it readable.

Is Ada95 verbose? Yes and no. It's designed from the philosophy that programs are read much more often than they are written, and that clarity of code should therefore be more important than writing speed. You have to be very explicit in your declarations - all variables has to be declared in a separate declaration block before you can use them, for instance. However, certain features of the language tend to let the code be written more concisely than other, similar languages.

Here's an an Ada95 version of the "program" earlier. Note that we need to declare D before the "begin" statement, and that we don't need the assert statements as they are implicit in the use of subtypes.


package AdaDemo is
type My_Integer is range 1 .. 4;
type My_Radian is range 1.0 .. 3.1415;
type My_Result is range Integer'First .. 3;

function Foo (My_Integer: in A; My_Radian: in B) return My_Result;
end AdaDemo;

package body AdaDemo is
function Foo (My_Integer: in A; My_Radian: in B) return My_Result is
D : My_Result := 0;
begin
D := Calculate Something...
return D;
end Foo;
end AdaDemo;

[roger]

I've done a lot of programming in Ada83. I made a lot of use of the range and subtype features of the language, and for the most part liked them a lot. However, the strong typing was often very annoying. A lot of time, you shouldn't be mixing types, but a lot of times you should. For example, in that very code snippet, there is no transparent way that you can get your integer result from a My_Integer and My_Radian type. I.e. you can't write

MyResult f = A * B

because A and B are different types. So now you have to cast them. And I find, at least in the kind of work I do, avionics simulations and geographic mapping, that I endlessly have to mix types.

For example, my map displays 30 degs of longitude, and I want to split it into 4 sections. How many degrees per section? Opps, gotta cast using the ada model.

Generally, navigation code ends up looking pretty messy if you ended up carefully typing things in Ada.

A concrete example, from problems I face everyday in my code: how do you represent angles?


type Angle is range 0.0 .. 360;
type Angle is range -180.0 .. 180.0
type Angle is range -180 .. 179.999999;



The fact is, all of these representations and more may make sense in 1 program.

Generally, I have found that trying to solve these issues by blindly making use of this feature you end up with just as much messy code as by not strongly typing your variables.

These days, if I want an angle, I have a class that looks like this:


class Angle
{
public:
friend const Angle Degrees (Scalar deg);
friend const Angle Radians (Scalar rad);

Scalar Degrees () const {return radians * RadToDeg;}
Scalar Radians () const {return radians;}

friend const Angle operator+ (const Angle& lhs, const Angle& rhs);
friend Scalar sin (const Angle& angle);
...etc
void Normalize180 ();
void Normalize360 ();
private:
Angle ();
};



The constuctor is private, so you can't write code like
Angle A; // compile error
A = 3; // compile error

because who knows what 3 means. Degrees? Radians?

Angle A = Degrees (3);

Angle B = A + Radians (0.14537);
double f = sin (A);


May sound like overkill, but given that I deal with angles, distances, speeds, etc, all day, I have a small collection of classes that let me write things like:


Speed d = Meters (390) / seconds (3.1);

cout << "speed: " << d.MilesPerHour () << "mph";
cout << "speed: " << d.FurlongsPerFortnight () << "fpf"; // joke


(all calculation and storage is done in MKS units, so it ends up being very efficient - conversions only done during input and output, if necessary).

[Peskanov]

Paul,


Nowhere near as difficult as trying to find the real code between all the silly comments people put in their files.


Well, I prefer functions and variables with well choosen names, better than redundant commentaries, or even worse, obsolete commentaries abandoned in the code!

But I find that usually programs lack documentation at module level. I often have to look the code of a module because the interface is not clear enough, even if it is my code :D

[Peskanov]

Leif Roar, seeing your example, it's clear that Ada is not my language. Too bureaucratic for me.
I imagine this language is good for big teams; being so complete in the description of everything is harder to make silly errors.
But don't fool ourselves; when a programmer has a tendency to code fast, there is no language that can stop him to commit lots of errors.
For example, a careless programmer could use

type My_Integer is range 0 .. 0x7fffffff;

doing copy-paste of it in every function.
Even ASSERTs can be a source of errors if you don't take care. I have had errors that I overlooked thinking: "This function has to be OK, if not the ASSERT would jump"; but the ASSERT would be badly states and would not work at all!

That's the reason I am starting to like languages that express more actions with less code. IMO, in general less code mean less bugs, and more easy to find.

[Leif Roar]

Originally posted by Peskanov
Leif Roar, seeing your example, it's clear that Ada is not my language. Too bureaucratic for me.
I imagine this language is good for big teams; being so complete in the description of everything is harder to make silly errors.


Well, the fields where Ada95 is considered to be particularly well suited is for very large projects and for programs that are safety critical (aviation, train control systems and so on - although such safety critical code are generally written in a subset of the whole language.)


But don't fool ourselves; when a programmer has a tendency to code fast, there is no language that can stop him to commit lots of errors.


Of course not, but there are still languages that prevent more errors than others. There are several common C/C++ errors that simply can't happen in Ada95 - the notorious buffer-overflow, for instance (Well, actually it can happen in Ada95 as well, but only if you've explicitly turned off range checking for that part of the code.) or this error: if( (a == 1) && (b = 2))

[/B]
For example, a careless programmer could use

type My_Integer is range 0 .. 0x7fffffff;

doing copy-paste of it in every function.
[/B]

I don't quite see what error you are getting at here.


Even ASSERTs can be a source of errors if you don't take care. I have had errors that I overlooked thinking: "This function has to be OK, if not the ASSERT would jump"; but the ASSERT would be badly states and would not work at all!


*g* Another annoying culprit is errors in error-handling or logging code.


That's the reason I am starting to like languages that express more actions with less code. IMO, in general less code mean less bugs, and more easy to find.

Well, I think it's more correct to say that languages with more statements are more likely to mean more bugs, but all in all I don't think Ada95 creates code with more statements than C or C++, rather the opposite.

[jayrev]

Originally posted by Paul C. Anagnostopoulos
If you like formal, incredibly verbose, theory-laden languages, then Eiffel might be your thing.

Eiffel does have one strength...its exception handling mechanism is...well...exceptional!

Bertrand Meyer, the creator of Eiffel, is very much an OO theoritician. And he's very opinionated as well.

The language, and Meyer's book "Object Oriented Software Construction" are great for learning OO concepts. But I have yet to see an Eiffel compiler that was usable. Meyer's company has much newer products that may be better now, but when I was using them (5 or 6 years ago) they were horrible.

[Leif Roar]

Originally posted by roger
I've done a lot of programming in Ada83. I made a lot of use of the range and subtype features of the language, and for the most part liked them a lot. However, the strong typing was often very annoying. A lot of time, you shouldn't be mixing types, but a lot of times you should.


Yes, I'll admit that sometimes it's annoying having to cast - especially when multiplying with an integer type.

[B]
For example, in that very code snippet, there is no transparent way that you can get your integer result from a My_Integer and My_Radian type. I.e. you can't write

MyResult f = A * B

because A and B are different types. So now you have to cast them.


In Ada95 you can declare the multiplication function like this: function "*" (Left: My_Integer; Right: My_Radian) return My_Result


[B]
[SNIP]
May sound like overkill, but given that I deal with angles, distances, speeds, etc, all day, I have a small collection of classes that let me write things like:


Speed d = Meters (390) / seconds (3.1);

cout << "speed: " << d.MilesPerHour () << "mph";
cout << "speed: " << d.FurlongsPerFortnight () << "fpf"; // joke


(all calculation and storage is done in MKS units, so it ends up being very efficient - conversions only done during input and output, if necessary).

It's been a while since I did anything in Ada95, so I'm not going to try writing a suggestion, but with the OO additions to the language since Ada83, code like your angles and SI unit example is possible to write - if not possible to write and use in exactly the same manner.

Edited to add: Others seems to have done so already, though: http://www.dmitry-kazakov.de/ada/units.htm

[a_unique_person]

Originally posted by Wudang


Well I admit a degree of wimpishness here. I like pretty coloured editors as they help with assembler syntax, my SQL gets pretty hairy when it gets time to close the brackets on a 4-way union, and it's saved my ass quite a few times when I've had a horribly complicated string in rexx where I'm parsing quote marks.
And in my currrent job I have to use COBOL. What kind of language treats a . as an implied END-IF or END-PERFORM?

ABAP?

[a_unique_person]

Originally posted by Leif Roar


However, SQL isn't a programming language, but a data query language. That really makes a huge difference. It's also very easy to write woefully ineficcent SQL calls - and even simple SQL calls have a fairly substantial overhead (at least for things such as games programming where CPU time is a limited resource.)

It would of course be nice to have integrated support for SQL in a language, but since just about any programming language that needs it have SQL libraries or other ways of making SQL calls, it doesn't really seem all that useful.


I think that in these days of multi-gigahertz desktop computers, where most of the graphics work is done in the video card, a little inefficiency is well worth it.

SQL was really just a first attempt at a data language. That is why "The Third Manifesto" has come up with a language called "D".

The Eiffel and C code, which has asserts, etc, in the code, is not necessary with a data driven language. That is, when you define the data type, you also define it's domain. No need for any asserts, checks etc. It is all done for you by the database.

[Peskanov]

I think that in these days of multi-gigahertz desktop computers, where most of the graphics work is done in the video card, a little inefficiency is well worth it.


I feel that with the upcomming commercialization of massive multiprocessing (in my opinion is only question of time) some aproaches to programming outside OO could get more popular. Prolog comes to mind, but what I am seeing in D looks also looks really atractive in that scenario. Database operations are usually very parallelizable.

[roger]

I haven't looked at D, but in general AUP's comments have seemed to be coming from left field *to me*, who does no database operations in his day to day programming. I'm doing things like drawing 2D or 3D widgets on a screen, calculating the trajectory of a dropped bomb, computing position based on several sensor inputs, etc. In these situations I don't see how having a queryable database is going to keep me from needing asserts, exception handling, pointers, etc. I can't imagine using a database in these situations.

Am I missing the point, and D is a general-purpose language?

[Paul C. Anagnostopoulos]

Roger asked:
What is the point/use of the tag id? (I've never used Eiffel).

Nothing clever. It's just so that when an assertion fails, the error message can include the unique tag id.

Compile-time typing is for wimps. Languages should be dynamically typed. A union is just a hack to get around compile-time typing. :D

~~ Paul

[Paul C. Anagnostopoulos]

What is it with people and parens in their code? First we have people separating argument lists from function names, so they look like they're not related:

foo (bar)


Then we have people putting spaces after open parens and before close parens:

x := y * ( a + b )

Do you do that in an sentence ( like this )?

Come on people. Get with the paren program!

~~ Paul

[roger]

Originally posted by Paul C. Anagnostopoulos
What is it with people and parens in their code? First we have people separating argument lists from function names, so they look like they're not related:

foo (bar)


Then we have people putting spaces after open parens and before close parens:

x := y * ( a + b )

Do you do that in an sentence ( like this )?


No, nor do I butt them up against my words(just like this).

I paren code just like in English.

I had a person who would paren like this:

int foo( int a ,int b ) const

It just drives me batty. Not because it is different from how I do it (I can deal with different indentation schemes, brace placements, etc), but because it interferes with how I normally parse parens and white space, honed over 30+ years of reading English.

[roger]

Since were riffing on the stupidity of other peoples code, how about hungarian notation? I hate it. Hate it.

* code should obscure types as much as possible (imo)

* if you program defensively, and use lint or such, you don't have to rely on a human reader to make sure an arithmetic statement is correct, and that you are passing the correct type of arguments.

* if you choose to change the type of the variable, you shouldn't have to rename that variable every place it occurs!!!

I kind of see the point when working in C, which doesn't afford much type protection, but even C++ gives enough protection that you don't need it.


And how about the stupidity of not capitalizing the first character of a function name, but capitalizing subsequent characters:

function doSomethingInteresting ()

instead of

function DoSomethingInteresting ()

[Paul C. Anagnostopoulos]

I agree, Roger, that Smalltalk-esque capitalization is dopey.

So what's up with case-sensitive languages? Patently ridiculous! Is there some great semantic difference between a capitalized and lowercase word in English? No, there isn't. The trouble now is that all the OO languages are using lowercase names for variables and capitalized names for class/type names. Some even require it. Totally absurd!

And what's up with uppercase macro names in C? Who thought that up?

But none of it is quite as absurd as a case-sensitive file system. But that's a different thread.

~~ Paul

[Janus]

Originally posted by Paul C. Anagnostopoulos
So what's up with case-sensitive languages? Patently ridiculous! Is there some great semantic difference between a capitalized and lowercase word in English? No, there isn't. The trouble now is that all the OO languages are using lowercase names for variables and capitalized names for class/type names. Some even require it. Totally absurd!


Nothing annoys me more than people who want to make code resemble English as much as possible. It only muddys clear code. You don't reason in mathematics by trying to convert it to English do you?

[evildave]

C all the way.

C++ has a few extra things that are nice:

Constructors/destructors, and exceptions. The inline keyword and added const int types is also handy. Some of the namespacing stuff (in classes and in file scope) are also very, very handy.

The rest is syntactical sugar coating I can live without.

I'm perfectly happy with typing ClassName_Function( ClassName* self, ... ), and instance->vtab->Function() for myself. A class in C is not much different from a class in C++, except it's trivial to use from other languages, since you have total control over its rules, and you don't run into as many quirky difference with different compilers.

Java is evil. C++ with no preprocessor, no pointers. A language without a preprocessor/macro system built in is a sad, sad thing.

I *like* macros.

[a_unique_person]

Originally posted by Paul C. Anagnostopoulos

But none of it is quite as absurd as a case-sensitive file system. But that's a different thread.

~~ Paul

I take that as a pat on the back for Bill Gates? I think the C designers just thought they could save a few CPU cycles if they made the filing system case sensitive. It serves no usefull purpose whatsoever.

I found a very interesting book on BCPL in the library once, which C was based on. It had many good points, half of which C discarded.

Finally, I hate the "Used Car Salesman" hype that was always associated with C and Unix. I worked on IBM mainframes, and while there was plenty about them I didn't like, there was also a lot of good points about them that Unix was sadly lacking, and is only now just implementing. I used to hate the error messages in MVS, till I saw the Unix error messages, then I realised that the IBM way was far superior.

[Peskanov]

Paul, you surely would hate my code to death;

I use lots of spaces

uiVertices = BuildSubmesh_Square ( &Bound, Center.iX, Center.iY, Center.iZ);

I use all caps for macros, defines, and types

#define SELECPOLYS_SIZE (MAX_SELEC_POLYS * sizeof(@POLYGON))

I align equations

Call.pVertex = Terrain.pVertex;
Call.pPolygonDst = Terrain_pSelecPolys;
Call.pVertexDst = Terrain_pSelecVertex;
Call.pVertexMarks = pVertexMarks;
(oops, it does not work here, just imagine all those "= Terrain_..." are aligned).

And I use a notation similar to the Hungarian one.

I found that I read my code faster that way; also it helps me a lot when debugging.
What can I say? I started to format my code that way only 3 years ago, but now I find annoying having to look more than 2 seconds a page of code to find anything. This format allows me to look through the code quite fast

[Peskanov]

Roger,


I'm doing things like drawing 2D or 3D widgets on a screen, calculating the trajectory of a dropped bomb, computing position based on several sensor inputs, etc. In these situations I don't see how having a queryable database is going to keep me from needing asserts, exception handling, pointers, etc. I can't imagine using a database in these situations.


Maybe...I would not request database structures for a program which calculate a table of sinus. Or in the case of critical real time applications.
However, when your program is large you have big chances of getting benefit from databases.
A possible example related to sensors: issuing an order to all the tanks which pertain to sector A, are full of Gas and have presion of X milibars.
This kind of filtering of information is very well expressed in database languages.

About pointers: the same nature of a database makes pointers useless. The memory position of any data is irrelevant, and that's one of the good points!
The need of error managing is independent of the language, but in a database there are fewer errors to control (for example, no need to control pointers).


Am I missing the point, and D is a general-purpose language?


I am reading the manual from the link AUP posted, and it certainly looks so.

What do you say AUP?

[Wudang]

Originally posted by a_unique_person
I used to hate the error messages in MVS, till I saw the Unix error messages, then I realised that the IBM way was far superior.

Amen. Most of my career has been MVS with a few years on Unix and NT. It seems a drag having to look up VSAM macro return codes until you find yourself unable to do that sort of thing and get error messages no better than "Wow, man. Heavy sh*t!". And to drag it back to languages - assembler actually helped enforce the 0 is good, 4 is a warning etc convention for return codes because the Branch instruction is 4 bytes long so you could
B *+4(15)
B OK
B WARNING
B WTF
etc. On the other hand, I've lost track of the number of times I've had to explain to people that BR 14,14 is valid and why it's valid. One of the joys of the internet is that now I can just give people the
URL (http://www.research.ibm.com/journal/rd/464/schwarz.html)

[a_unique_person]

Originally posted by Peskanov



I am reading the manual from the link AUP posted, and it certainly looks so.

What do you say AUP?

I think you are better at demangling a techie manual than I am. I have been trying to find the actual manual that teaches me what they are actually doing. I know they have based it on D. But the doco is so dry and technical, the headings for it are so misleading, that I don't know where to start. Plus I downloaded their new beta and it wouldn't even start. Don't you hate it when a beta won't even fire up?

[a_unique_person]

Originally posted by Wudang


Amen. Most of my career has been MVS with a few years on Unix and NT. It seems a drag having to look up VSAM macro return codes until you find yourself unable to do that sort of thing and get error messages no better than "Wow, man. Heavy sh*t!". And to drag it back to languages - assembler actually helped enforce the 0 is good, 4 is a warning etc convention for return codes because the Branch instruction is 4 bytes long so you could
B *+4(15)
B OK
B WARNING
B WTF
etc. On the other hand, I've lost track of the number of times I've had to explain to people that BR 14,14 is valid and why it's valid. One of the joys of the internet is that now I can just give people the
URL (http://www.research.ibm.com/journal/rd/464/schwarz.html)

"Kernel Panic". The person that created that error message is soon to burn in hell, or reincarnate as a snail.

I used to wonder why the "Formatted dump" was called that, till I saw a Unix dump. I had the formatted dump worked out in a few months, and spent the next five years telling people why their program had crashed.

And I still hate the "C" hubris. I read that dammed C manual, with all it's exhortations to convince me that this was the ultimate programming language. C is C. It is a wonderful advance to create the universal assembler. But that is all it is. All that "C" hype was copied direct from the BCPL manual, but BCPL was better.

[Paul C. Anagnostopoulos]

Janus said:Nothing annoys me more than people who want to make code resemble English as much as possible. It only muddys clear code. You don't reason in mathematics by trying to convert it to English do you?
I'm not trying to make code resemble English. I think that capitalization should not convey semantics for various reasons, one of them being that it's not done in natural languages. Another is that it's prone to errors. Another is that we're not used to noticing capitalization when we read. I mean, come on:

Point point = new Point(...)


EvilDave said:
A language without a preprocessor/macro system built in is a sad, sad thing.
Yes, but C's macro facility is about as sad as you can get and still call it macros. Now Gossip, she has real macros!

Peskanov said:
I use lots of spaces.
So do I. I just use them in the right places. :D
I use all caps for macros, defines, and types.
Yagh.
I align equations.
Absolutely, me too.

~~ Paul

[ceptimus]

Part of the Amiga OS was in BCPL. Occasionally, you had to flip the words around when passing pointers, as the BCPL pointers were stored the opposite way around compared to the C ones.

[roger]

Originally posted by Peskanov

I use all caps for macros, defines, and types
Why? What does it buy you? What problems are you solving or trying to avoid by using this?

You've never seen the code below. Tell me which is the type, which the variable, which is the class:

int foo;
int foo [MaxSize];
Point x;
x = Origin + Size (4, 5);

It's true in my code that you can't tell whether Origin is a constant, a global, etc, but I pretty much write code so you shouldn't have to worry about that. I loathe side effects, global data, etc. Within the context of real code, it'll be clear, almost always, what Origin is. If the behavior of the code depends on Origin being a constant or variable, then you had better have written the code so it is obvious, and not dependent on some unknown capitalization scheme.

With that said, I don't get burned up about the all capitals issue, but I don't really get it, andjust find it makes code harder to read.

What does bother me is when programmers use capitalization to denote something that is not expressed in the language itself. Because everyone uses different standards, and many people are inconsistant, you can't rely on these assumptions. I deeply mistrust code that uses things like spacing, capitalization, etc, to convey design information. Of course, with C, what choice do you have :)
I align equations
Used to do that, but lacking an editor that does it automatically I escew it. There is a lot to be said for making code readable, but there is also a lot to be said about not making formatting decisions that require you to constantly fiddle with code. I could go either way on this issue.


And I use a notation similar to the Hungarian one.Similar. Not identical? So somebody else who reads your code has to guess at your meaning? And adopt your style when making modifications?

I'm really not as polemical as I probably sound - I could happily read and deal with your formatting, though I choose to do things differently.

My opinions have been largely formed from the book Code Complete. He spends a lot of time talking about making code readable, but bases it whenever possible on empirical studies.

If a block of code requires you to scroll to see it all, then it's too big to comprehend. there will be a bug in it. So don't format your code that way.

I.e.

int result = some_function
(longnameA,
longnameB,
longnameC);


is prettier than


int result = some_function (longnameA, longnameB, longnameC);


but chances are most every time you read the code block this resides in you are trying to read/understand the block, not verify the parameters being passed in. So accept lack of readability for this function call so you achieve readability for the entire block.

Just an example. I use both formats, depending on context.

[roger]

Originally posted by Peskanov
However, when your program is large you have big chances of getting benefit from databases.
A possible example related to sensors: issuing an order to all the tanks which pertain to sector A, are full of Gas and have presion of X milibars.
This kind of filtering of information is very well expressed in database languages.

Okay, I can see that there is a programming paradigm that I need to investigate.

However.

When I've been forced to work with databases in the past (things like SQL calls from C) I've hated it. Hated it. Why? Because all a database is is a huge repository of global variables. When/where was a value modified? Who can tell? You have to read every line of code to find out.

Maybe that is just a symptom of the code I was working with, and there are good ways to limit scope, and the code i used failed that. But from what I saw, as long as you can get a reference to the database, you can pretty much do what you want with it. Given that I spend so much effort in my code basically erecting firewalls between data so it becomes obvious who has access to what and when, I hate the idea of stuffing things in databases just so queries are easier. I do allow that I may be completely misinterpeting what you are talking about.

[epepke]

Originally posted by roger

Why? What does it buy you? What problems are you solving or trying to avoid by using this?

I don't know what it buys him, but what it buys me is that many macros do not guarantee that their arguments will only be evaluated a single time, so it makes it easy to spot/avoid some errors.

[epepke]

Originally posted by roger
When I've been forced to work with databases in the past (things like SQL calls from C) I've hated it. Hated it. Why? Because all a database is is a huge repository of global variables. When/where was a value modified? Who can tell? You have to read every line of code to find out.

My last full-time job involved heavy use of Oracle 9i in a fairly large and critical Enterprise setting. I got to groove pretty well with Oracle after a while. However, there are some problems.

First, the speed of a query is highly dependent upon its structure. It was not difficult by simple things, such as rearranging the terms of a query, to make a factor of 100 speed difference. Part of this is due to bad implementation of the database engine; I wish Oracle would hire some LISP programmers and compiler writers to do some optimizations.

Second, date-tracked tables, used extensively in Oracle Apps, are hellacious. Many times you want to select only for joined rows that have a date-tracked item that overlaps a period (often a pay period of a week or two weeks). but don't really care what exactly is in that row. This gives the impression of "duplicate" rows in the final result. There is a way of getting around this with a subselection, but it's slow. In some cases you can also use DISTINCT, but it's also slow. We found that it was actually faster and more effective in most cases to do the query that produces duplicates, ship that all to the middle tier, and get rid of the duplicates there.

Don't get me started on flexfields. Powerful, but more spaghetti-like than GOTO-only BASIC with line numbers.

[roger]

Originally posted by epepke


I don't know what it buys him, but what it buys me is that many macros do not guarantee that their arguments will only be evaluated a single time, so it makes it easy to spot/avoid some errors. Yes, I see the point when using C style defines which are just inline code. But then any macro that evaluates a parameter more than once shouldn't be written or used :)

[Paul C. Anagnostopoulos]

Epepke said:
I don't know what it buys him, but what it buys me is that many macros do not guarantee that their arguments will only be evaluated a single time, so it makes it easy to spot/avoid some errors.
Then tell the macro writers to fix their macros! Of course, that is sometimes difficult with the puny, pathetic, girlie macro facility in C.

~~ Paul

[epepke]

Originally posted by roger
Yes, I see the point when using C style defines which are just inline code. But then any macro that evaluates a parameter more than once shouldn't be written or used :)

Grassahoppa, the world is a very different place when you have to deal with existing code.

In any event, there are three multiple-evaluation macros which I would absolutely defend even for ab initio work: MIN, MAX, and ABS.

[Peskanov]

Roger,

Why? What does it buy you? What problems are you solving or trying to avoid by using this?


This was the oficial nomenclature in a company I worked. I found it ugly, but also I found it useful when debugging.
Most debuggers does not allow macro debug, or consulting the value of a define value.
It was very annoying try to enter in a funtion to find it was a macro, etc...When I see a word with capital letters I know the only thing I can do is enter in assembler mode.

About formating the text, I ike to do it when I am not in a hurry. Usually, I think a lot before coding; I guess I am a slow coder. The time I spend typing is marginal comparing with planning and debugging/fixing/retouching/document/CVS...

About hungarian notation, I like to recognize pointers and numbers at firts sight, and also know the size of the numbers (8,16,32 bits); specially in structures.
This is relevant to my work because I have heavy interaction between ASM and C.
So we use some prefixes in variables, this is the reason I say we use (in my company) a similar notation (prefixing C variables), but that's all.
About block formatting I use the same format as you, but we are not formal about that.


When I've been forced to work with databases in the past (things like SQL calls from C) I've hated it. Hated it. Why? Because all a database is is a huge repository of global variables. When/where was a value modified? Who can tell? You have to read every line of code to find out.


The difference between Global/Local is arbitrary in any language. For the OS, all data is "local" and dissapears when the aplication closes.
About modifying the data, the same happens in C, although it provides the modifier "const" for function parameters, to improve security. I am usually to lazy to use it although I know I should.
IMO the scope of data is a politic question which pertain to the ingeneer of the program. If the language provides tools to enforce this use, cool, but I don't find it so important.
In C you also have the added problem of data overwriting. A mad pointer can cause a failure in the other extreme of the program!
In both cases (C and SQL) the size of the problem depends on the architecture of the code and the tools avalaible for tracking the error.
Just my 2 cents...

[epepke]

Originally posted by Peskanov
About hungarian notation, I like to recognize pointers and numbers at firts sight, and also know the size of the numbers (8,16,32 bits); specially in structures.

Well, Hungarian notation was really big in the development of the WIN32 API, and that shows a lot of its faults. Namely, identifiers named with one type inevitably got changed to another type, but the identifier names stayed the same.

[a_unique_person]

Originally posted by epepke


Well, Hungarian notation was really big in the development of the WIN32 API, and that shows a lot of its faults. Namely, identifiers named with one type inevitably got changed to another type, but the identifier names stayed the same.

One of the basic rules of data representation. Don't make the key have an attribute in it. When the attribute changes, you have screwed the key.

[Paul C. Anagnostopoulos]

Epepke said:
In any event, there are three multiple-evaluation macros which I would absolutely defend even for ab initio work: MIN, MAX, and ABS.
If there is no way to avoid the side-effect problem in the macros, then make them functions.

For that matter, why the heck aren't they built-in functions anyway? Then the compiler could inline them and everyone would be happy.

~~ Paul

[patoco12]

Originally posted by Zep
Heh heh! I grew up on Pascal, etc, as well. And COBOL, Fortran, Algol, PL/1, Snobol, Simula, etc, etc.

Ach, you just brought back some PL/1 nightmares. Thanks.

[epepke]

Originally posted by Paul C. Anagnostopoulos

If there is no way to avoid the side-effect problem in the macros, then make them functions.

Functions that automatically make use of mixed-mode arithmetic? It isn't going to happen in C. You could do all the combinations with C++ with a page of code, but it's easy to do with macros, and it works fine.

[epepke]

Originally posted by patoco12

Ach, you just brought back some PL/1 nightmares. Thanks.

On the other hand, I miss SNOBOL. Sure, the control was even worse than FORTRAN II, but having a function return both a value and success or failure all of the time was an amazing idea. And the ability to do context-free grammars right in the language and hokey up even context-sensitive grammars was great.

[Paul C. Anagnostopoulos]

Epepke said:
Functions that automatically make use of mixed-mode arithmetic? It isn't going to happen in C. You could do all the combinations with C++ with a page of code, but it's easy to do with macros, and it works fine.
Yes, I suppose. Silly strong typing.

In college, a friend and I proved that any program could be written as a single statement in Snobol, with multiple executions.

Speaking of returning a value and a status, what is it with functions returning a single value? Who decided a single value was a good idea? Is there something special about one value?

~~ Paul

[a_unique_person]

Originally posted by Paul C. Anagnostopoulos

Yes, I suppose. Silly strong typing.

In college, a friend and I proved that any program could be written as a single statement in Snobol, with multiple executions.

Speaking of returning a value and a status, what is it with functions returning a single value? Who decided a single value was a good idea? Is there something special about one value?

~~ Paul

This is where you get O'Caml coming into the picture. Strong typing is used, but it also does it's own type inference. So, rather than writing a macro, you still have to write the code to handle mixed arithmetic. But you then have the code inside the language, removing the hassle of side effects.

[epepke]

Originally posted by Paul C. Anagnostopoulos

Yes, I suppose. Silly strong typing.

In college, a friend and I proved that any program could be written as a single statement in Snobol, with multiple executions.

Speaking of returning a value and a status, what is it with functions returning a single value? Who decided a single value was a good idea? Is there something special about one value?

Two words: stacks and recursion. I've been doing assembly language since about 1975, and I've seen the evolution of processors, which tends to lag five to ten years behind software development but ironically also influences it. The CDC mainframes didn't have native support for stacks at all; commonplace practice was to replace the first word of a subroutine with a jump to the return location. The CDC mainframes also has a 60-bit word with 6-bit characters, the origin of the Pascal "alfa" type.

In the late 1970's, there were two things pushing processor development: C and LISP. When I got to MIT in 1978, LISP was all the rage, but it was mostly stack-based, because that's the easiest way to do recursion. Also, C, which lacked a program-wide typing mechanism, had functions return integers. At about the same time, processors like the Z-80 came out that had nice, fast stack optimization mechanisms, so people used them.

Also, about that time, people started to figure out that there was a much better way to do recursion: the continuation mechanism as used by Scheme and to some extent other LISPs. However, this was conceptually difficult to use. Also, compiler writers started getting good at optimization, and they wanted homogeneous registers.

This led to the RISC developments of the late 1980's, which came to little, because the bastard descendents of the 4004, through Intel, had already come to dominate. Now, only Macheads and people who do scientific computing use RISC. Yet ironically, RISC architectures are much better suited for the continuation mechanism.

Of course, if one is just writing interpreters, it matters little what the architecture is, but at some point, someone wants to compile and have linked and shared libraries and all that stuff.

[69dodge]

Originally posted by epepke
Functions that automatically make use of mixed-mode arithmetic? It isn't going to happen in C. You could do all the combinations with C++ with a page of code, but it's easy to do with macros, and it works fine.Standard C++ comes with min() and max() template functions declared in the &lt;algorithm&gt; header:<blockquote>template<class T> const T& min(const T& a, const T& b);
template<class T> const T& max(const T& a, const T& b);</blockquote>They are no doubt defined as inline in practice, so they're just as fast as macros, but like all functions they evaluate their arguments only once.

[epepke]

Originally posted by 69dodge
Standard C++ comes with min() and max() template functions declared in the &lt;algorithm&gt; header:<blockquote>template<class T> const T& min(const T& a, const T& b);
template<class T> const T& max(const T& a, const T& b);</blockquote>They are no doubt defined as inline in practice, so they're just as fast as macros, but like all functions they evaluate their arguments only once.

Nice.

i'll remember that if I ever get a job or commision where standard C++ can be assumed.

[Yahweh]

I just thought this image was appropriate...

http://216.218.248.155/datastore/ed/b0/b/edb0990945152e3901045583faed700b.jpg